Добро пожаловать в форум, Guest  >>   Войти | Регистрация | Поиск | Правила | В избранное | Подписаться
Все форумы / Сравнение СУБД Новый топик    Ответить
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 19 20 21 22 23 [24] 25 26 27 28 .. 31   вперед  Ctrl
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30244
Yo
как я понял вы согласны что "несчастные" 2 транзакции показаные на стенде ничего не доказывают

нет, не согласен.
еще раз ссылка:
http://www.avarda.ru/testdrive2007.htm

это не тест tpc. и откуда было взято 2 транзакции в секунду - я не знаю.

В процессе демонстрации работы розничной сети в системе AVARDA.RetailNetwork осуществлялось более 28834,75 транзакций в мин. Интенсивность добавления записей составляла более 411261,77 зап./мин.

то есть 480 бизнес-транзакций в секунду.
25 дек 07, 11:41    [5092236]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30244
Yo
нормальность - понятие размытое, например фокспрошники считают нормальным отсутствие ACID, а у ораклойдов попадание в кеш на OLTP нагрузке менее чем 98% считается катострофой.


ACID есть, кэш есть. что еще?

Yo
а тотальное отсутсвие кеша ...

где отсутствие?
25 дек 07, 11:43    [5092253]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
hvlad
И как SMP может помочь уменьшить расход памяти на сотню одновременных сортировок ?
SMP -- никак, а вот отсутствие общего буфера сортировки заставляет закладываться на эту сотню одновременных сортировок, и, либо резать выделенные буфера для каждого соединения, заставляя производить сортировку во временных файлах чаще, чем это было бы нужно, либо рассчитывать на то, что "этого не может быть, потому что не может быть никогда", поднимать ограничение выше того значения, которое физически может обеспечить система, с риском загнать её в race conditions.
25 дек 07, 11:45    [5092258]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
kdv
Yo
а тотальное отсутсвие кеша ...

где отсутствие?
Он есть, но такой маленький, что в него ничего не попадает, тем самым обеспечивается отсутствие двойной буферизации.
25 дек 07, 11:46    [5092273]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11551
DocAl
hvlad
Ну, и в чём проблемы классика с сортировкой ? И как SMP может помочь уменьшить расход памяти на сотню одновременных сортировок ?

Это просто разные аспекты проблемы масштабируемости.
Я задал конкретный вопрос, хотелось бы услышать конкретный ответ.

DocAl
Если ответственно подходить к выбору СУБД для решения задачи, следует учитывать эти аспекты, в том плане, чтобы понимать, что можно будет сделать, когда нагрузка на СУБД возрастёт в 10 раз, как по процессору, так и по количеству соединений.
Вода.

DocAl
По процессору суперсервер пролетает сразу: лучшее, что можно сделать, поставить топовый геймерский P4EE двухлетней давности и, собственно, всё, упираешься в потолок. Не исключаю, что возможна гибридная схема, т.е. возможность запустить несколько инстансов, по количеству ядер в системе, суперсервера, относящихся друг к другу как классические сервера. Но, во-первых, это, всё ж таки, те ещё костыли, а во-вторых, до недавнего поста kdv вопросы масштабируемости суперсервера старательно обходились стороной. Так что, может быть, такой возможности и нет.
СУБД намного более ограниченны IO подсистемой, чем CPU, это раз.
Несколько инстансов - можно, это два.
Ничего нигде не обходилось - просто пережёвывать не вкусно, это три.

DocAl
Зато расхваливалась масштабируемость классической схемы, мол, всё линейно, все работают с сотнями соединений (назывались цифры до 400) и у всех всё зашибись.
Люди пользуются, работают, реальная система удовлетворяет реальным требованиям - что ещё нужно ?

DocAl
Ну, я, в общем-то, не спорю, что классическая схема может быть достаточно успешна для различных отчётов, когда есть несколько (не сотни!) соединений, хорошо кушающих процессор, но на сотнях процессов оверхед по памяти растёт до невероятных значений!
Та ты шо ?!

DocAl
Вон даже пример привели, на 160 соединений отожралось 4,6 гига оперативы, и это ещё без учёта файлового кэша, на который так рассчитывает Firebird! Да, было сказано, мол, всего-то каких-то 4,6 гига, делов-то, но это, вообще-то, дохрена! И либо ограничение на сортировку зарезано на 30 метрах, либо эта цифра может улететь ещё дальше!
Опять вывод не основанный на реальности.

DocAl
И да, я считаю, что 4,6 гига памяти за возможность сортировать 30метровые выборки -- это много!
Причём тут одно к другому ?

DocAl
Да, классика может работать и при большом количестве соединений, и даже, формально, с линейной масштабируемостью по процам, но если сказать только это -- это относительно честный способ обмануть.
Тебе перечислить кол-во обманов в статейках мс\оракл\выберитретьегосам ?
В чём обман-то ? Что ФБ не Оракл ? Так этого никто не говорит, он лучше :)

PS merry x-mas
PPS don't worry, be happy (c)
25 дек 07, 12:06    [5092441]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11551
DocAl
hvlad
И как SMP может помочь уменьшить расход памяти на сотню одновременных сортировок ?
SMP -- никак, а вот отсутствие общего буфера сортировки заставляет закладываться на эту сотню одновременных сортировок, и, либо резать выделенные буфера для каждого соединения, заставляя производить сортировку во временных файлах чаще, чем это было бы нужно, либо рассчитывать на то, что "этого не может быть, потому что не может быть никогда", поднимать ограничение выше того значения, которое физически может обеспечить система, с риском загнать её в race conditions.
Так. Что такое "общий буфер сортировки" ?
Ты сам, лично и персонально, мерял скорость сортировки объёмом 5, 10, 20, 1000 МБ ?
Т.е. - ты понимаешь о чём говоришь, или где ?
Я переписывал сортировку в FB 2.1, так что имею кое-какое мнение на этот счёт
25 дек 07, 12:11    [5092480]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
hvlad
Тебе перечислить кол-во обманов в статейках мс\оракл\выберитретьегосам ?
В чём обман-то ? Что ФБ не Оракл ? Так этого никто не говорит, он лучше :)

PS merry x-mas
PPS don't worry, be happy (c)
Я чего-т не понял, я тут с маркетоидами разговариваю, разве? Чего врать-то, не корову проигрываем, и не рекламную статью пишем, чай.
PS. И тебя туда же.
25 дек 07, 12:11    [5092484]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

Откуда:
Сообщений: 54772

DocAl

Я чего-т не понял, я тут с маркетоидами разговариваю, разве?

Ну так сам в технические детали лезть отказываешься...
Таки опиши, как можно сортировать два разных датасета в одном
сортировочном буфере без деления его надвое.

Posted via ActualForum NNTP Server 1.4

25 дек 07, 12:28    [5092656]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
kdv

В процессе демонстрации работы розничной сети в системе AVARDA.RetailNetwork осуществлялось более 28834,75 транзакций в мин. Интенсивность добавления записей составляла более 411261,77 зап./мин.

то есть 480 бизнес-транзакций в секунду.

480 это все сервера всех филлиалов, головной сервер развил скорость аж две tps. но даже если бы 480 - что это доказывает !?

kdv

СУБД намного более ограниченны IO подсистемой, чем CPU, это раз.

вот имено, в первую очередь отсутствие единого кеша приводит к пожиранию и/о, а во вторую расход CPU на парсинг sql. к стате а где хранятся разобраные планы sql, они вообще в fb кешируются ?
25 дек 07, 13:16    [5093179]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
kdv

СУБД намного более ограниченны IO подсистемой, чем CPU, это раз.

сори это были слова hvlad
25 дек 07, 13:18    [5093200]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
zhouck
Member

Откуда:
Сообщений: 359

> вот имено, в первую очередь отсутствие единого кеша приводит к пожиранию
> и/о, а во вторую расход CPU на парсинг sql. к стате а где хранятся
> разобраные планы sql, они вообще в fb кешируются ?

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

Posted via ActualForum NNTP Server 1.4

25 дек 07, 13:29    [5093303]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Yo.!
hvlad

СУБД намного более ограниченны IO подсистемой, чем CPU, это раз.

вот имено, в первую очередь отсутствие единого кеша приводит к пожиранию и/о, а во вторую расход CPU на парсинг sql. к стате а где хранятся разобраные планы sql, они вообще в fb кешируются ?
Единый кеш у классика есть - ФС.
Планы системных запросов, процедур и триггеров кешируются.

Кстати, кеширование всего и вся не есть абсолютное благо. ASA, например, оптимизирует все запросы (кроме элементарнейших) при каждом выполнении и очень этому рад.
25 дек 07, 15:50    [5094527]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11551
DocAl
hvlad
Тебе перечислить кол-во обманов в статейках мс\оракл\выберитретьегосам ?
В чём обман-то ? Что ФБ не Оракл ? Так этого никто не говорит, он лучше :)
Я чего-т не понял, я тут с маркетоидами разговариваю, разве? Чего врать-то, не корову проигрываем, и не рекламную статью пишем, чай.
А кто врёт-то ? Поосторожнее на поворотах, однако...
25 дек 07, 15:53    [5094559]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30244
автор
И еще клиент для работы не многопоточный

многопоточный. на уровне одного коннекта - нет. и это нормально.
прошу назвать многопоточных клиентов, которые позволяют реально многопоточно работать с сокетом коннекта.
25 дек 07, 16:12    [5094745]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
hvlad
Yo.!
hvlad

СУБД намного более ограниченны IO подсистемой, чем CPU, это раз.

вот имено, в первую очередь отсутствие единого кеша приводит к пожиранию и/о, а во вторую расход CPU на парсинг sql. к стате а где хранятся разобраные планы sql, они вообще в fb кешируются ?
Единый кеш у классика есть - ФС.
Планы системных запросов, процедур и триггеров кешируются.

гы-гы, а что за связь и/о c кешем субд ? думаю не открою вам америку - нормальный стоимостный оптимизатор должен решить применить фулскан (читай scatered read) или взять из кеша. если у субд нет своего кеша и соответственно инфы чего там в кеше, она будет вынуждена долбать фулсканом scatered read котрый проходит мимо кеша оси. хотя у FB со стоимостным оптимизатором беда ... в полне вероятно, что единый кеш не спасет ситуацию.

ЗЫ. дык, потому ASA и позиционируется как субд рабочих групп ...
25 дек 07, 19:33    [5096022]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
>связь и/о c кешем субд
звиняюсь нужно читать "связь и/о субд c кешем оси"
25 дек 07, 19:35    [5096028]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Yo.!
hvlad
Yo.!
hvlad

СУБД намного более ограниченны IO подсистемой, чем CPU, это раз.

вот имено, в первую очередь отсутствие единого кеша приводит к пожиранию и/о, а во вторую расход CPU на парсинг sql. к стате а где хранятся разобраные планы sql, они вообще в fb кешируются ?
Единый кеш у классика есть - ФС.
Планы системных запросов, процедур и триггеров кешируются.

гы-гы, а что за связь и/о c кешем субд ?
Считай, что кеш ОСи есть кеш второго уровня для СУБД.

Yo.!
думаю не открою вам америку - нормальный стоимостный оптимизатор должен решить применить фулскан (читай scatered read) или взять из кеша. если у субд нет своего кеша и соответственно инфы чего там в кеше, она будет вынуждена долбать фулсканом scatered read котрый проходит мимо кеша оси. хотя у FB со стоимостным оптимизатором беда ... в полне вероятно, что единый кеш не спасет ситуацию.
Если СУБД кеширует планы запросов, то вменяемый оптимизатор не будет учитывать состояние кеша в момент препарирования. Ибо оно будет сильно отличаться в момент выполнения.
Фуллскан и scatered read - это два термина если не из разных предметных областей, то как минимум из разных аспектов.
У мсье есть опыт реализации кеша чего-либо или всё как обычно ?

Yo.!
ЗЫ. дык, потому ASA и позиционируется как субд рабочих групп ...
Я не собираюсь обсуждать ASA. Просто упомянул достаточно жизненную альтернативу тотальному кешированию планов запросов.
26 дек 07, 00:10    [5096450]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
hvlad
Считай, что кеш ОСи есть кеш второго уровня для СУБД.

не вижу пользы, тем более что наиболее вероятно при подходе FB на кеш оси памяти не останется.

hvlad

Если СУБД кеширует планы запросов, то вменяемый оптимизатор не будет учитывать состояние кеша в момент препарирования. Ибо оно будет сильно отличаться в момент выполнения.

ужос, где ж вы такие "вменяемые" видели ? в оракле например автоматом кешируются маленькие таблицы (кажется все, что менее 2% от кеша), планы запросов пересматриваются по десяткам причин, наверника и по причине попадания таблицы в кеш пересмотрится.

hvlad

Фуллскан и scatered read - это два термина если не из разных предметных областей, то как минимум из разных аспектов.

и связи между ними вы не прослеживаете, да ? а мне например не известны варианты в оракле когда может получится scatered read без фуллскана ...

hvlad

У мсье есть опыт реализации кеша чего-либо или всё как обычно ?

мусье имеет хотя бы базовые понятия о вменяемом оптимизаторе, чего достаточно, чтоб аргументировано судить о кривизне подхода FB.
не имея данных о проценте блоков индекса в кеше, без инфы о таблицах закрепленых в кеше и так не лучший в индустрии оптимизатор FB вынужден или надеятся, что нужные данные закешировала ось (что глупо) или долбать scatered read на каждый чих, что естественно ведет к перекосу в i/o
26 дек 07, 14:52    [5099252]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
Yo.!
оракле например автоматом кешируются маленькие таблицы (кажется все, что менее 2% от кеша)...по причине попадания таблицы в кеш пересмотрится

А ежели она только в момент препарирования махонькая, а во время пути таблица может и подрасти (с).
26 дек 07, 15:22    [5099465]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
FreemanZAV

А ежели она только в момент препарирования махонькая, а во время пути таблица может и подрасти (с).

дык, подрастет - вылетит из кеша, за собой утащит все планы с этой табличкой, не вижу проблемы ...
26 дек 07, 15:31    [5099558]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
Yo.!
вылетит из кеша

Перед или во время выполнения запроса?
26 дек 07, 15:34    [5099579]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11551
Ты что хочешь мне доказать ?
а) что в FB не оракловый оптимизатор ?
б) что архитектура классика имеет свои накладные расходы ?
в) что ты ни хрена не понимаешь в произносимых тобой терминах ?

Согласен по всем пунктам

PS Собственно, я очередной раз убедился в бессмысленности бесед с Ё и возобновляю его игнорирование.
26 дек 07, 17:18    [5100287]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11551
hvlad
Ты что хочешь мне доказать ?
Это было к Ё
26 дек 07, 17:47    [5100503]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30244
ликбез:

1. Scattered Read (рассредоточенное чтение)
например тут:
http://www.dba-oracle.com/m_db_file_scattered.htm

A scattered read is usually a multiblock read. It can occur for a fast full scan (of an index) in addition to a full table scan.
The db file scattered read wait event identifies that a full table scan is occurring.
When performing a full table scan into the buffer cache, the blocks read are read into memory locations that are not physically adjacent to each other.

Such reads are called scattered read calls, because the blocks are scattered throughout memory.

2. Fullscan - обычно имеется в виду чтение таблицы без индексов, перебором страниц данных. в IB/FB в отношении таблиц Fullscan это NATURAL (в PLAN).

Итак. Scattered read может возникать при fullscan.

Таким образом, на мой взгляд фраза Yo
Yo
нормальный стоимостный оптимизатор должен решить применить фулскан (читай scatered read) или взять из кеша.

практически лишена смысла.

Потому что, нормальный даже не оптимизатор, а подсистема кэша, не должна вытеснять кэш, если обнаруживается fullscan. То есть, fullscan не должен забивать кэш. По идее. Если выполняется один раз. Если читаемый объем больше кэша. И т.д.

Так вот. Еще в IB 6 (семь лет назад) например select count и любой natural (читай fullscan) НЕ приводит к "вышибанию" кэша.
26 дек 07, 17:58    [5100566]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30244
добавлю, что в монопольном режиме select count в FB/IB дает дисковый io равный макс скорости дискового обмена, например как при копировании файла (40-50 мб/сек на простых sata).
26 дек 07, 18:09    [5100604]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 19 20 21 22 23 [24] 25 26 27 28 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить