Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
pkarklin
Опять один словесный понос. Меряться когда будем?


Да ты я как погляжу не уймешся.
Облегчим снова тебе многократно задачу.
Может уже твоей квалификации хватит сделать просто копи-паст...

Конечно тут трафик не меряли побайтно. Хотя задача трафико нагружаемая на 100%.
И разница с твоей любимой базой данной в 40 раз ...

Как ты думаешь, почему ?
(Сразу говорю, всем желающим предлагаю оптимизировать MS SQL код на свое усмотрение)
13 май 16, 00:09    [19167041]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
mayton
Member

Откуда: loopback
Сообщений: 53042
Модератор: Коллеги прошу спокойствия. А то буду топик прикрывать
13 май 16, 00:19    [19167052]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
stop,

А там камменты можно оставлять? Что-то не вижи ни одного. Пиар ресурса здесь не приветствуется. По сути и не вникая особо в подробности - есть проблемы с проектированием, ибо пришлось такой лапшекод на транзакте нарисовать.

Ты не там ищешь серебряную пулю.
13 май 16, 00:22    [19167059]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
mayton
Модератор: Коллеги прошу спокойствия. А то буду топик прикрывать


Дело не в топике, а в одном его участнике. Его и надо "прикрывать". Практического толку от него голимый ноль. Один самопиар.
13 май 16, 00:23    [19167061]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
pkarklin
mayton
Модератор: Коллеги прошу спокойствия. А то буду топик прикрывать


Дело не в топике, а в одном его участнике. Его и надо "прикрывать". Практического толку от него голимый ноль. Один самопиар.
да прикрыть то много ума не надо...
не нравится - ну не надо читать и вешать ярлыки типа "говнокода"
у меня вот сейчас на нечто подобное собираются переходить, я хочу например хоть какую-то пользу увидеть
13 май 16, 00:27    [19167068]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
SergSuper
я хочу например хоть какую-то пользу увидеть


Дык я с этого и начал! Предложил провести тестирование. Площадку готов предоставить. Но получаю в ответ кучу лапшекода. Доколе?
13 май 16, 00:29    [19167071]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
2 pkarklin
Ну вот, мой бан спасет твою репутацию. Это верно.
Ссылку я не хотел приводить, просто ты ее выпросил.

PS:
А ты наверное думал что ядро и бородатые протоколы передачи MS SQL дают
+50 фрагов к скорости переключения p-n-p переходов на транзисторах в процессоре
и еще плюс 100 фрагов к скорости света при передачи по сети.
А оно вот оно как Михалыч. Несколько десятков тысяч комменариев иерархией noSql база данных
через АДО выгружает в 40к раз (ну ладно в 10 раз учитывая непревзойденный профессионализм, упорство и супер-пупер-мега оптимизации от мастер-гуру (я надеюс)) быстрее.

А ну прости. Я вспомнил что ты там чтото говорил про плюсики в дереве и особый код который обеспечит порционную загрузку через ajax дабы не прогинать могучий сервер.
13 май 16, 00:29    [19167073]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
SergSuper,

Ну, ты видел последний (я надеюсь) пост...
13 май 16, 00:31    [19167075]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
pkarklin
SergSuper,

Ну, ты видел последний (я надеюсь) пост...


Зачем ты начинал этот пост если не хотел отстоять свою точку зрения ?
Я вроде тебе целенаправленный бенчмарк на счет трафика между прочим по сабжу прислал,
за который готов ответить за каждую цифру
и ты опять в кусты.

В чем смысл тогда твоих дифирамбов. Я например с MS SQL
11+ лет знаком с тех пор как мне всучили его сертификаты.
Но у меня есть альтернативная точка зрения на его эффективность в определенных
ограниченных условиях. А у тебя к сожалению ограниченный и однобокий взгляд на
развитие систем управления базами данных. Увы. Как говорится, ниначем не настаиваю.
13 май 16, 00:36    [19167083]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
stop,

автор
Зачем ты начинал этот пост если не хотел отстоять свою точку зрения ?
Я вроде тебе целенаправленный бенчмарк на счет трафика между прочим по сабжу прислал,
за который готов ответить за каждую цифру
и ты опять в кусты.

Мне казалось, я раз несколько повторил вопрос про решаемую задачу, а не про то, как ты ее решил.
автор
В чем смысл тогда твоих дифирамбов. Я например с MS SQL
11+ лет знаком с тех пор как мне всучили его сертификаты.

Везет, же. У меня вот нет сертификатов. С MS SQL знаком (да не может быть) уже лет 20ть...
автор
Но у меня есть альтернативная точка зрения на его эффективность в определенных
ограниченных условиях

Жаль, что она не применима на практике. Тынцы на работающие решения, а не собственный ресур приветствуются!
автор
А у тебя к сожалению ограниченный и однобокий взгляд на
развитие систем управления базами данных.

Это да. Он, так сказать, классическйий. Вся "новизна", как правило, на практике оказывается шелухой. Но у некоторых еще есть возможность это опровергнуть. Приведя, опять же, тынцы на промышленные работающие решения.
13 май 16, 00:47    [19167096]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
20 шт
Member

Откуда: Сообщений: 412780
Сообщений: 1186
pkarklin,

вполне очевидно, что ты снова не вписываешься в формат обсуждения. Может, дашь людям завершить его?
13 май 16, 00:50    [19167103]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
20 шт
Может, дашь людям завершить его?


Давай я это буду решать сам?!
13 май 16, 00:52    [19167109]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
pkarklin
stop,
Мне казалось, я раз несколько повторил вопрос про решаемую задачу, а не про то, как ты ее решил.


По моей ссылке вроде есть.
автор
Код моделирует ленту сообщений новостного сайта.
Комментарии в древовидной структуре.


Дальше по коду все вроде понятно.
К каждой странице 1000 комментариев иерархией. (10*10*10)

Дальше вроде как должен разбираться с MS SQL

pkarklin
Приведя, опять же, тынцы на промышленные работающие решения.


Google, Facebook, Twitter у которых noSql базы данных на полную катушку
используются, подходят ? Или считается промышленным только Склад-Бухгалтерия, с 10 бухами на борту одновременно.
13 май 16, 00:53    [19167110]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
20 шт
Member

Откуда: Сообщений: 412780
Сообщений: 1186
pkarklin
20 шт
Может, дашь людям завершить его?


Давай я это буду решать сам?!

Ну реши, пожалуйста, и смойся.
13 май 16, 00:56    [19167115]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
stop
Google, Facebook, Twitter у которых noSql базы данных на полную катушку


Господи... Если Google чего-нить не покажет в поисковой выдаче, то это никто не заметит, если в лицокниге или твитере пропадет пост, то никто не будет обрывать телефон службы поддержки банка, что у меня списали деньги, но операция не прошла.

Когда ты начнешь разделять системы, реализующие "бантики" и системы, где тебя за копейку тебя удушат, возможно ты повзрослеешь.
13 май 16, 00:57    [19167116]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
pkarklin
stop
Google, Facebook, Twitter у которых noSql базы данных на полную катушку


Господи... Если Google чего-нить не покажет в поисковой выдаче, то это никто не заметит, если в лицокниге или твитере пропадет пост, то никто не будет обрывать телефон службы поддержки банка, что у меня списали деньги, но операция не прошла.

Когда ты начнешь разделять системы, реализующие "бантики" и системы, где тебя за копейку тебя удушат, возможно ты повзрослеешь.


Днипра поддерживает три вида транзакций (ReadCommited, RepeatableRead, Snapshot),
поддерживает все четыре буквы ACID и поддерживает транзакционный лог, по которому можно, например, откатить даже закомиченные транзакции на определенную дату.

Реляционная модель данных, не имеет никакого прямого отношения к надежности хранения данных с технической точки зрения.
Просто так исторически сложилось, что почти все реляционки держат этот стандарт ACID. Но тормознутые они не потому что они надежные, а потому что они во-первых древние, код у них с душком как и влюбом бородатом проекте,
во-вторых модель данных оставляет желать лучшего (компактность иерархических представлений обсуждали, а ведь это только верхушка айсберга).
13 май 16, 01:04    [19167120]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67530
Блог
asphix
Несколько удалённых офисов, ширина канала до сервера баз данных - (sic!) 128 кбит/с.

Пользователей сколько? Два или две тысячи?

P.S. Ох как страшно. У меня в своё время были каналы 9600 бит/с.

asphix
Изначально планируется клиент на Delphi. Вопрос в выборе СУБД (MySQL, PostgreSQL, etc..) и в выборе технологии коннекта (ADO, FireDAC, etc..)

Вопрос в выборе архитектуры и качественной реализации. Что же до СУБД и технологий коннекта, то:

- СУБД надо выбрать так, чтобы хватало серверных возможностей (ну или приписывать свой AS)
- пары СУБД/способ доступа в принципе не помешает протестировать на процент хлама в сетевом протоколе, но по сравнению с влиянием архитектуры разница вряд ли окажется принципиальной.
13 май 16, 01:13    [19167124]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
stop,

автор
Днипра поддерживает три вида транзакций (ReadCommited, RepeatableRead, Snapshot),

Когда будет Serializable - приходи. Oracle с собой не забудь захватить...
автор
Реляционная модель данных, не имеет никакого прямого отношения к надежности хранения данных с технической точки зрения.
Просто так исторически сложилось, что почти все реляционки держат этот стандарт ACID.

Действительно не имеет. Странно, что ты вообще об этом упомянул. Держут их, далеко не все.
автор
Но тормознутые они не потому что они надежные, а потому что они во-первых древние, код у них с душком как и влюбом бородатом проекте,
во-вторых модель данных оставляет желать лучшего (компактность иерархических представлений обсуждали, а ведь это только верхушка айсберга).

Видишь ли, в чем дело. Тебе опять придеться напомнить, что ты решаешь задачи вида сферического коня в вакууме в однопользовательском режиме, т.е. не имеющие практического смысла. Ты потрудись, найди в этом разделе приводимые мной показатели нагрузки реальных систем. Когда ты на примерно такой уровень выйдешь хоть на 5ть минут - приходи.
13 май 16, 01:13    [19167125]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
pkarklin
stop,
автор
Днипра поддерживает три вида транзакций (ReadCommited, RepeatableRead, Snapshot),

Когда будет Serializable - приходи. Oracle с собой не забудь захватить...


Внезапно, но Snapshot это и есть Serializable.

pkarklin
stop,
Видишь ли, в чем дело. Тебе опять придеться напомнить, что ты решаешь задачи вида сферического коня в вакууме в однопользовательском режиме, т.е. не имеющие практического смысла. Ты потрудись, найди в этом разделе приводимые мной показатели нагрузки реальных систем. Когда ты на примерно такой уровень выйдешь хоть на 5ть минут - приходи.


Так это я тебе и пытаюсь донести. Никаких реальных нагруженных приложений на реляционке не получится.
Их удел - слабонагруженные системы с развесистыми отчетными подсистемами. Все что в сторону, уже начинаются кеширующие сервера и прочьи пляски с бубном.
13 май 16, 01:19    [19167135]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
pkarklin
Member

Откуда: Москва (Муром)
Сообщений: 74930
stop,

автор
Внезапно, но Snapshot это и есть Serializable.

Не говори это никому, ладно?
автор
Так это я тебе и пытаюсь донести. Никаких реальных нагруженных приложений на реляционке не получится.

Ну как же ты можешь это до меня довести, если ты рядом не столят ни с одной нагруженной транзакционной системой. Гугл, твитер и и же с ним к ним не относятся.
автор
Их удел - слабонагруженные системы с развесистыми отчетными подсистемами. Все что в сторону, уже начинаются кеширующие сервера и прочьи пляски с бубном.

Я не хочу снова повторять слова, которые вызывают оправданный гнев модераторов, но ты опять пишешь много слов, не имеющих смысловой нагрузки. Т.е. ты говоришь о том, о чем у тебя просто нет представления.
13 май 16, 01:28    [19167142]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
stop
Никаких реальных нагруженных приложений на реляционке не получится.
я так понимаю процессинг пластиковых карт - это слабонагруженная система, действительно виза, мастеркард всякий, несерьезно
а что такое тогда реально нагруженные? можно конечно назвать Google, Facebook, Twitter, но такие системы единичны, масштаб фирм такой что можно и специализированные базы себе написать, т.е. совсем не показатель
что остается тогда?
13 май 16, 01:33    [19167145]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
SergSuper
stop
Никаких реальных нагруженных приложений на реляционке не получится.
я так понимаю процессинг пластиковых карт - это слабонагруженная система, действительно виза, мастеркард всякий, несерьезно
а что такое тогда реально нагруженные? можно конечно назвать Google, Facebook, Twitter, но такие системы единичны, масштаб фирм такой что можно и специализированные базы себе написать, т.е. совсем не показатель
что остается тогда?


Ну разные базы бывают.
Например скаченый размер этого форума, в районе 56 гигабайт.
При средней длине слова в русском языке 8 символов, можно посчитать что чтобы проиндексировать только этот сайт,
нужно выполнить около 7 миллиардов запросов за три-четыре часа, чтобы построить индекс.

И это не Google и не Facebook и сервер посредственный, ноутбук.

А Виза и Мастеркард - ооочень дорогое железо, которого много, плюс денормализированые данные, плюс куча специальных костыльных фишек типа блокировки сумм на картах, плюс двухфазные коммиты (а не всегда честные транзакции), плюс процессинг сумм карт в одной системе, ведение данных карт уже в другой. Короче всеравно процессить в реалтайм не такто всё и просто да и нагрузки там я бы не сказал что астрономические.
13 май 16, 01:49    [19167150]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
stop
Member [заблокирован]

Откуда: blog.pikosec.com
Сообщений: 405
pkarklin
stop,

автор
Внезапно, но Snapshot это и есть Serializable.

Не говори это никому, ладно?


Я понял о чем ты говоришь.
Мой Snapshot в Днипре равен Serializable в MS SQL.
По сути он блокирует коммиты на время чтения, чем делает снапшот базы данных,
плюс делает блокировки тех данных, которые прочитал, во избежания перезаписи их другими транзакциями после завершения текущей.
13 май 16, 01:59    [19167157]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
SergSuper
Member

Откуда: SPb
Сообщений: 5488
stop
SergSuper
пропущено...
я так понимаю процессинг пластиковых карт - это слабонагруженная система, действительно виза, мастеркард всякий, несерьезно
а что такое тогда реально нагруженные? можно конечно назвать Google, Facebook, Twitter, но такие системы единичны, масштаб фирм такой что можно и специализированные базы себе написать, т.е. совсем не показатель
что остается тогда?


Ну разные базы бывают.
Например скаченый размер этого форума, в районе 56 гигабайт.
При средней длине слова в русском языке 8 символов, можно посчитать что чтобы проиндексировать только этот сайт,
нужно выполнить около 7 миллиардов запросов за три-четыре часа, чтобы построить индекс.

И это не Google и не Facebook и сервер посредственный, ноутбук.

А Виза и Мастеркард - ооочень дорогое железо, которого много, плюс денормализированые данные, плюс куча специальных костыльных фишек типа блокировки сумм на картах, плюс двухфазные коммиты (а не всегда честные транзакции), плюс процессинг сумм карт в одной системе, ведение данных карт уже в другой. Короче всеравно процессить в реалтайм не такто всё и просто да и нагрузки там я бы не сказал что астрономические.

sql.ru реально работает, тормознутости не наблюдаю
тоже самое касается и процессинга, что в самой визе, что в процесингах банков, не думаю что например Уралсиб покупал ооочень дорогое железо, а процессинги делали себе банки и поменьше

ну хорошо, нагрузки там неастрономические, а где тогда они серьезные?
13 май 16, 10:59    [19167863]     Ответить | Цитировать Сообщить модератору
 Re: Выбор СУБД для медленного канала  [new]
Зимаргл
Guest
Пробегала статья сравнения трафика постгрес с ораклом. Что разница в трафике вдвое.

Погуглил, похоже в mssql компрессии TDS нет. Хм.
13 май 16, 11:17    [19167953]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 2 3 4 [5] 6 7   вперед  Ctrl      все
Все форумы / Сравнение СУБД Ответить