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

Откуда: iBase.ru
Сообщений: 30285
автор
Бл., зае.ли. Нравится вам неху.вый стократный оверхед по памяти -- ешьте, других-то нахрена подписывать?! И ещё басни рассказывают про линейное масштабирование!


кстати, почему "подписывать"? тебя никто на FB не звал. И вообще никто за уши не тянет, никого. Не нравится - не надо, не пользуй. Маркетингого трепа, как у других СУБД, нет. Да, классик - старая архитектура. Но - да, она вполне нормально работает во многих реальных системах.
В чем проблема-то? "Вроде все ничего, только вот нос не нравится" ?
24 дек 07, 17:22    [5089725]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
kdv

т.е. ты - ресторанный критик, который судит о ресторане по меню?


вообще большинство тухлятину определяют по запаху и пробывать значительной части в голову не приходит ...
почему бы нормально не парировать техническим языком возможность маштабируемости с таким подходом, а не пытатся методами ЧАЛа матом и оскорблениями заглушить очевидный косяк архитектуры ?
24 дек 07, 17:28    [5089775]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32907

Привет, Yo.!!
Ты пишешь:

Yo.!
очевидный косяк архитектуры
йоу, поведай миру, в чем косяк классической архитектуры?
ты ж собаку съел в теоретических изысканиях нимоверной ширины.
остальные лохи тебе и в подмётки не годятся...

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.4

24 дек 07, 17:32    [5089805]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
со стороны
Guest
Мимопроходящий


DocAl
стократный оверхед по памяти

и снова пустопорожний звон...
--
With best regards, Мимопроходящий.

Почитал-почитал данный топик и не увидел от тебя (МП) ни одного конкретного факта, ссылки или просто логичного заключения.
Так что "пустопорожний звон" исходит как раз от тебя, в отличие от Docal-а, который не реагируя на многочисленные провокации и нервные окрики, все же приводит аргументы, в том числе и из док-и. Не хотите ввязываться в дискусию - не надо, только грубость и наезд основной признак отсутствия аргументов. Лучше промолчи - иногда полезней будет для дела (того же файрберда, который от таких "защитников" только проигрывает).

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

P.S. А файрберд хорошая СУБД, но для своего класса задач.
24 дек 07, 18:27    [5090084]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30285
Yo
бы нормально не парировать техническим языком возможность маштабируемости с таким подходом

мля. дискуссия -то какая?

DocAI: я слышал, тут говно и здесь говно.
kdv: нет, вот примеры реальных систем, все нормально.
Yo: почему бы не парировать техническим языком?

да как вас еще парировать-то. уж и примеры привели, и домыслы развеяли - нет, все не нравится.

объясняю в последний раз: да, классическая архитектура имеет недостаток в виде раздельного кэша. Но пока этот недостаток чисто теоретический. На практике масштабируемость классика на SMP вполне нормальная, и удовлетворяет пользователей реальных систем. Эта масштабируемость ничуть не хуже чем масштабируемость суперсервера-SMP InterBase 7.5/2007 (примеры которой тоже есть, реальные).
Разработчики FB планируют изменить нынешний классик, и в конце-концов сделать суперсервер-SMP.
Но пока масштабируемость и производительность классика вполне нормально позволяют строить производительные промышленные системы. А не какие то там "с небольшим ....". Хотя критериев "небольшого" я от DocAI так и не услышал, из чего делаю вывод что ему кроме как потрындеть больше ничего не надо.

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

p.s. по AVARDA - по поводу "несчастные 2 транзакции в секунду". Эта тест-система имитирует реальную работу людей. В ускоренном режиме. Ускорять этот режим до запредельных у тестеров задача не стояла. Все равно оператор 2 документа в секунду не сделает.
24 дек 07, 18:29    [5090089]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30285
автор
Почитал-почитал данный топик и не увидел от тебя (МП) ни одного конкретного факта, ссылки или просто логичного заключения.


МП не трогай, у него тоже система на классике, и он не видит нужды дублировать мои примеры.

автор
Так что "пустопорожний звон" исходит как раз от тебя, в отличие от Docal-а, который не реагируя на многочисленные провокации и нервные окрики, все же приводит аргументы, в том числе и из док-и.

это как раз и есть пустопорожний звон, "из доки" путем теоретизирования. на теорию ему дают практические ответы, но он невменяем.
24 дек 07, 18:31    [5090103]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Мимопроходящий
Member

Откуда: бурятский тундрюк, эсквайр
Сообщений: 32907

Привет, со!
Ты пишешь:

со
сс> Почитал-почитал данный топик и не увидел от тебя (МП) ни одного конкретного факта

гюльчатай, открой личико. (С)

--
With best regards, Мимопроходящий.

Posted via ActualForum NNTP Server 1.4

24 дек 07, 18:32    [5090105]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11574
DocAl
Dimitry Sibiryakov

Ну а теперь еще попробуй подумать: как может помочь общий буфер
сортировке результатов запроса, которые у каждого коннекта свои.

Да запросто: если io диска на три порядка медленнее, чем io памяти (что для случайного доступа вполне реально), то последовательно отсортировав результаты 400 запросов в памяти, мы получим 2,5 кратный прирост. В самом плохом случае, если для сортировки каждого запроса требуются суммарный объём всех 400 маленьких буферов. Если же мы рассчитываем на кэш файловой системы, то, как минимум, мы имеем проблему двойной буферизации.
IO сортировки большей частью последовательный. В FB 2.1 ;)
Двойной буферизации практически нет ни в классике (у каждого процесса маленький кеш), ни при сортировке (там вообще нет буферизации кроме как в ФС)
24 дек 07, 18:38    [5090122]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30285
и еще обращаю внимание:

когда я упомянул что "критик, который судит ресторан по меню", сразу начались выпады вроде:

Yo
вообще большинство тухлятину определяют по запаху


"со стороны"
воспитывать официанта или просить убрать запах с кухни нет времени и желания.


то есть, не быв в ресторане и не читав меню (а я под этим имею в виду хоть какой реальный опыт, а не рассматривание ресторана в бинокль), вы уже сразу пишете про "тухлятину" и "запах в кухне"?

Это называется нормальный способ ведения дискуссии?
24 дек 07, 18:39    [5090123]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11574
Yo.!
апупеть 290779 иранзакций за 32 часа, это ж более 2х транзакций в секунду, мда впечатляющая цифра.
Учимся читать то, что написано, а не то, что хочется видеть (написано, кстати, одним абзацем выше числа 290779):

http://avarda.ru/main_softool2006_results.htm
В процессе проведения нагрузочного тестирования осуществлялось более 5000 транзакций в мин. Интенсивность добавления записей составляла более 14000 зап./мин.
Это было тестирование 2006 года на одном далеко не самом дорогом сервере (насколько я помню).

http://www.avarda.ru/testdrive2007.htm
В процессе демонстрации работы розничной сети в системе AVARDA.RetailNetwork осуществлялось более 28834,75 транзакций в мин. Интенсивность добавления записей составляла более 411261,77 зап./мин.
А это - 2007 год, 10 серверов
(насколько я понимаю часть из них обслуживала филиалы, т.е. не все имели одинаковую\максимальную нагрузку).
24 дек 07, 18:47    [5090144]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11574
DocAl
Всё ж таки, более 16 гигов за простую возможность сортировать 30-ти метровую выборку в памяти -- совсем перебор.
Не понято - откуда такие числа ?
24 дек 07, 18:52    [5090158]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11574
DocAl
Обычно, если запрос использует индекс, этот индекс загружается в специально отведённый буфер, где и производятся все необходимые манипуляции. Я не могу ручаться, т.к., с имеющейся документацией, выяснить это можно только ковыряясь в коде, но считаю весьма вероятным, что эти буфера также никак не пересекаются.
С кем\чем не пересекаются ?
Индексы, как и все остальные данные СУБД, хранятся по-странично. Читаются, есс-но, только нужные страницы.
Индексы в FB, кстати, очень компактны.
24 дек 07, 18:55    [5090171]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
kdv

да как вас еще парировать-то. уж и примеры привели, и домыслы развеяли - нет, все не нравится.

я например не вижу аргументов, как я понял вы согласны что "несчастные" 2 транзакции показаные на стенде ничего не доказывают, то же самое не доказывают 5000/min - т.к. нет кода, нет инфо о сервере, несчем сравнить. к тому же тут же прозвучавшие 14К инсертов на фоне сотен тысяч полноценных tpc-c транзакций на самых слабеньньких однопроцесорных серверах лидеров тоже ничего не доказывают.

kdv

Но пока масштабируемость и производительность классика вполне нормально позволяют строить производительные промышленные системы.

нормальность - понятие размытое, например фокспрошники считают нормальным отсутствие ACID, а у ораклойдов попадание в кеш на OLTP нагрузке менее чем 98% считается катострофой. а тотальное отсутсвие кеша ...
24 дек 07, 20:29    [5090441]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11574
Yo.!
к тому же тут же прозвучавшие 14К инсертов на фоне сотен тысяч полноценных tpc-c транзакций на самых слабеньньких однопроцесорных серверах лидеров тоже ничего не доказывают.
Пример можно "сотен тысяч полноценных tpc-c транзакций на самых слабеньньких однопроцесорных серверах" ?
Ещё рекомендую ознакомиться с содержимым любой из 5-ти tpc-c тр-ций и сравнить с бизнес-логикой любой реальной системы учёта.
24 дек 07, 22:50    [5090828]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
hvlad

Двойной буферизации практически нет ни в классике (у каждого процесса маленький кеш), ни при сортировке (там вообще нет буферизации кроме как в ФС)

Как минимум, двойная буферизация идёт в кэше файловой системы и в маленьких кэшах процессов. Кстати, если процессов сотни, и они однотипны -- очень даже вероятно, что и в этих маленьких кэшах данные пересекаются.
По поводу отсутствия буферизации сортировки, не понял, к чему тогда в конфиге параметры SortMemBlockSize и SortMemUpperLimit?
24 дек 07, 23:11    [5090892]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
kdv

то есть, не быв в ресторане и не читав меню (а я под этим имею в виду хоть какой реальный опыт, а не рассматривание ресторана в бинокль)
А я под чтением меню имею в виду чтение документации. В данном ресторане, меню просто отсутствует. Правда, можно поглядеть некоторые накладные на доставку продуктов, завещание давно умершего предыдущего владельца и мемуары работавших в похожем ресторане. Ещё можно найти отдельные страницы из поваренной книги. Если попробовать поинтересоваться составом блюда у официантов, получаешь лаконичные и информативные ответы: "пока никто не жаловался", "а вы не жуйте, вы так проглатывайте", "это не таракан, это изюм" и "там всё написано, читать не умеешь?". Иногда с кухни выглядывает шеф-повар и может дать какие-то внятные ответы, но обычно он занят, да и то верно, не его это работа, меню объяснять.
24 дек 07, 23:24    [5090925]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
hvlad
Пример можно "сотен тысяч полноценных tpc-c транзакций на самых слабеньньких однопроцесорных серверах" ?


OK, не секунду, а минуту

hvlad

Ещё рекомендую ознакомиться с содержимым любой из 5-ти tpc-c тр-ций и сравнить с бизнес-логикой любой реальной системы учёта.

че то у вас с логикой ... вам говорят 14К тупых инсертах в минуту против сотен тысяч хоть и простеньких но транзакций с бизнес логикой.
24 дек 07, 23:29    [5090933]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
hvlad
DocAl
Обычно, если запрос использует индекс, этот индекс загружается в специально отведённый буфер, где и производятся все необходимые манипуляции. Я не могу ручаться, т.к., с имеющейся документацией, выяснить это можно только ковыряясь в коде, но считаю весьма вероятным, что эти буфера также никак не пересекаются.
С кем\чем не пересекаются ?
Индексы, как и все остальные данные СУБД, хранятся по-странично. Читаются, есс-но, только нужные страницы.
Индексы в FB, кстати, очень компактны.
Я имею в виду, нет общего буфера для индексов, т.е. если на сервере работает 100 параллельных сессий, выполняющих один и тот же запрос, использующий индекс, то в памяти лежит 101 копия этого индекса, если, конечно, влазит. Собственно, я тут уже повторяюсь, просто Мимопроходящий данные демонстративно не сортирует, вот и привёл другой пример, может быть, он хотя бы выборки по индексам использует.
24 дек 07, 23:31    [5090939]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11574
DocAl
hvlad

Двойной буферизации практически нет ни в классике (у каждого процесса маленький кеш), ни при сортировке (там вообще нет буферизации кроме как в ФС)

Как минимум, двойная буферизация идёт в кэше файловой системы и в маленьких кэшах процессов. Кстати, если процессов сотни, и они однотипны -- очень даже вероятно, что и в этих маленьких кэшах данные пересекаются.
Это обычно мало по сравнению с объёмом кеша ФС.
И я написал - "практически нет", а не "совершенно нет" :)

DocAl
По поводу отсутствия буферизации сортировки, не понял, к чему тогда в конфиге параметры SortMemBlockSize и SortMemUpperLimit?
Так может нужно было сначала спросить (в профильном форуме), а уже потом делать далеко идущие выводы ?
Пр-во для внешней сортировки в FB начинается в памяти и продолжается во временных файлах на диске при необходимости.
Т.е. мелкие сортировки не пойдут на диск вообще.

SortMemUpperLimit - общий лимит на объём памяти, выделяемой под внешние сортировки.
Есс-но у каждой сортировки память своя собственная, но лимит у них общий.

SortMemBlockSize - какими кусками выделяется память под внешнюю сортировку.
24 дек 07, 23:36    [5090950]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
hvlad

SortMemUpperLimit - общий лимит на объём памяти, выделяемой под внешние сортировки.
Есс-но у каждой сортировки память своя собственная, но лимит у них общий.

вынужден снова процитировать firebird.conf, который меня отправили читать
firebrd.conf

# The maximum amount of memory to be allocated by the in-memory
# sorting module.
#
# For Classic servers, this setting is defaulted to 8 MB.
# Although it can be increased, the value applies to each client
# connection/server instance and thus consumes a lot of memory.
#
# Type: integer
#
#SortMemUpperLimit = 67108864

Т.о., если я понимаю суть этого комментария правильно, для того, чтобы сортировать в памяти выборки в 20Мб, и, при этом, работать с сотней параллельных соединений, нужно пожертвовать двумя гигами оперативки, верно?
24 дек 07, 23:44    [5090958]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11574
DocAl
Т.о., если я понимаю суть этого комментария правильно, для того, чтобы сортировать в памяти выборки в 20Мб, и, при этом, работать с сотней параллельных соединений, нужно пожертвовать двумя гигами оперативки, верно?
Нет. В памяти они будут занимать SortMemUpperLimit. Для того этот пар-р и введён. Укажешь 2ГБ - будет занимать макс. 2ГБ. Укажешь 0 - всё сразу пойдёт на диск.

Я уже не говорю о том, что в реальной жизни запустить 100 одновременных сортировок - это нужно хорошо постараться...
24 дек 07, 23:57    [5090986]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11574
DocAl
Т.о., если я понимаю суть этого комментария правильно, для того, чтобы сортировать в памяти выборки в 20Мб, и, при этом, работать с сотней параллельных соединений, нужно пожертвовать двумя гигами оперативки, верно?
А, ты о классике говоришь. В классике будет занято макс. SortMemUpperLimit * кол-во сортировок, т.е. в твоём случае - 100*8 = 800 МБ.
В супере - SortMemUpperLimit, не зависимо от кол-ва сортировок.
25 дек 07, 00:01    [5090998]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
hvlad
А, ты о классике говоришь. В классике будет занято макс. SortMemUpperLimit * кол-во сортировок, т.е. в твоём случае - 100*8 = 800 МБ.
В супере - SortMemUpperLimit, не зависимо от кол-ва сортировок.
Суперсервер-то пока без SMP... По крайней мере, так сказано на firebirdsql.org, и вопросы масштабирования именно суперсервера в этой теме как-то умалчиваются, рассказывается только про линейную масштабируемость классики.
25 дек 07, 00:06    [5091012]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11574
DocAl
hvlad
А, ты о классике говоришь. В классике будет занято макс. SortMemUpperLimit * кол-во сортировок, т.е. в твоём случае - 100*8 = 800 МБ.
В супере - SortMemUpperLimit, не зависимо от кол-ва сортировок.
Суперсервер-то пока без SMP... По крайней мере, так сказано на firebirdsql.org, и вопросы масштабирования именно суперсервера в этой теме как-то умалчиваются, рассказывается только про линейную масштабируемость классики.
Ну, и в чём проблемы классика с сортировкой ? И как SMP может помочь уменьшить расход памяти на сотню одновременных сортировок ?
25 дек 07, 00:31    [5091067]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
hvlad
DocAl
hvlad
А, ты о классике говоришь. В классике будет занято макс. SortMemUpperLimit * кол-во сортировок, т.е. в твоём случае - 100*8 = 800 МБ.
В супере - SortMemUpperLimit, не зависимо от кол-ва сортировок.
Суперсервер-то пока без SMP... По крайней мере, так сказано на firebirdsql.org, и вопросы масштабирования именно суперсервера в этой теме как-то умалчиваются, рассказывается только про линейную масштабируемость классики.
Ну, и в чём проблемы классика с сортировкой ? И как SMP может помочь уменьшить расход памяти на сотню одновременных сортировок ?

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

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

Зато расхваливалась масштабируемость классической схемы, мол, всё линейно, все работают с сотнями соединений (назывались цифры до 400) и у всех всё зашибись. Ну, я, в общем-то, не спорю, что классическая схема может быть достаточно успешна для различных отчётов, когда есть несколько (не сотни!) соединений, хорошо кушающих процессор, но на сотнях процессов оверхед по памяти растёт до невероятных значений! Вон даже пример привели, на 160 соединений отожралось 4,6 гига оперативы, и это ещё без учёта файлового кэша, на который так рассчитывает Firebird! Да, было сказано, мол, всего-то каких-то 4,6 гига, делов-то, но это, вообще-то, дохрена! И либо ограничение на сортировку зарезано на 30 метрах, либо эта цифра может улететь ещё дальше! И да, я считаю, что 4,6 гига памяти за возможность сортировать 30метровые выборки -- это много! Да, классика может работать и при большом количестве соединений, и даже, формально, с линейной масштабируемостью по процам, но если сказать только это -- это относительно честный способ обмануть.
25 дек 07, 11:40    [5092228]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 18 19 20 21 22 [23] 24 25 26 27 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить