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

Откуда: Оккупирую западный берег
Сообщений: 10472
А на каком железе, в какой операционной системе предполагается разместить СУБД?
22 дек 07, 05:41    [5083627]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
arax83
Member

Откуда: Красноярск
Сообщений: 2
Железо планируется не шибко крутое - Pentium D 2.8GHz CPU (Dual Core), 2Gb RAM, 2x250Gb 7200rpm IDE HDD RAID 1.
Так как это арендуемый сервер - ОС ставим под нужды проектируемой системы. То есть какое надо - такое и поставим, но не Windows
22 дек 07, 16:35    [5084146]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
Ну, мне тут так и не сказали, что там с масштабируемостью у фаербёрда, хрен его знает, как он будет на двухядернике себя вести.
22 дек 07, 18:16    [5084258]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
S.G.
Member

Откуда: cartoon network
Сообщений: 30611
DocAl
Ну, мне тут так и не сказали, что там с масштабируемостью у фаербёрда, хрен его знает, как он будет на двухядернике себя вести.
Воспользовавшись поиском... ;)
здесь
здесь
22 дек 07, 20:38    [5084377]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
S.G.
DocAl
Ну, мне тут так и не сказали, что там с масштабируемостью у фаербёрда, хрен его знает, как он будет на двухядернике себя вести.
Воспользовавшись поиском... ;)
здесь
здесь
Насколько я понимаю эту "классическую" архитектуру, на каждое подключение в ней создаётся отдельный процесс, все буфера у каждого процесса отдельные. Возможно, во времена ваксов это было адекватное решение, но сейчас декларировать это решение, как "линейно масштабирующеесе"... Извините, так линейно масштабироваться может и акцесс.
23 дек 07, 05:14    [5084684]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30275
автор
Извините, так линейно масштабироваться может и акцесс.

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

автор
Железо планируется не шибко крутое


мой декстоп и то круче.
23 дек 07, 07:44    [5084701]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

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

Нет, ну серьёзно, такую "линейно масштабирующуюся систему" из чего хочешь сварганить можно, хоть экземпляры экселя запускай: пожалста, вот вам супер-система для SMP, памяти, правда, не напасёшься, и io проседает по любому чиху, но зато как масштабируется по процессорам!
Архитектура классическая, только немножко из каменного века и для современных условий малопригодная. Собственно, где она применима-то? Оптимальные условия: мало соединений, работающих с небольшим объёмом независимых данных... Как-то не фонтан для СУБД.
kdv
автор
Железо планируется не шибко крутое

мой декстоп и то круче.

Тем не менее, двухядерник. По классической масштабируемости я выше написал, про суперсерверную как-то очень скромно молчат... Как бы вообще на P4 не пришлось откатываться.
23 дек 07, 09:49    [5084728]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30275
автор
Архитектура классическая, только немножко из каменного века и для современных условий малопригодная. Собственно, где она применима-то? Оптимальные условия: мало соединений, работающих с небольшим объёмом независимых данных... Как-то не фонтан для СУБД.


мсье теоретик? или просто не в курсе реальных применений классика? тогда чего трындеть?
средние базы от 5 до 100 гиг, количество одновременных пользователей - до 400. Это не лимиты, это СРЕДНИЕ данные по реальным системам.
23 дек 07, 17:28    [5085197]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
А что делают ваши пользователи с этими сотнями гигабайт и, в лучшем случае, единицами мегабайт кэша?
23 дек 07, 18:49    [5085336]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
kdv
автор
Архитектура классическая, только немножко из каменного века и для современных условий малопригодная. Собственно, где она применима-то? Оптимальные условия: мало соединений, работающих с небольшим объёмом независимых данных... Как-то не фонтан для СУБД.


мсье теоретик? или просто не в курсе реальных применений классика? тогда чего трындеть?
средние базы от 5 до 100 гиг, количество одновременных пользователей - до 400. Это не лимиты, это СРЕДНИЕ данные по реальным системам.

http://firebirdsql.org/manual/qsg2-classic-or-super.html

Classic modeSuperserver mode
Processes Creates a separate process for every client connection each with its own cache. Less resource use if the number of connections is low.A single process serves all connections using threads to handle requests. Shared cache space. More efficient if the number of simultaneous connections grows.
Multiprocessor SMP (symmetrical multi-processor) support. Better performance in case of a small number of connections that do not influence each other.No SMP support. On multi-processor Windows machines performance can even drop dramatically as the OS switches the process between CPUs. To prevent this set the CpuAffinityMask parameter in the configuration file firebird.conf.


Тоже, небось, теоретики писали?
23 дек 07, 18:57    [5085354]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
гы-гы, сейчас и фокспрошники подтянутся с рассказами о банковских блингах на dbf и осуждением ненавистных теоретиков которым зачем-то нужен ACID. Чую будет весело
23 дек 07, 19:39    [5085442]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11564
DocAl
А что делают ваши пользователи с этими сотнями гигабайт и, в лучшем случае, единицами мегабайт кэша?
Кеширует файловая система.
Удивил ?
23 дек 07, 22:11    [5085770]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
hvlad
Member

Откуда:
Сообщений: 11564
DocAl
Тоже, небось, теоретики писали?
Вот один из рассказов практиков
23 дек 07, 22:18    [5085785]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30275
DocAI
Тоже, небось, теоретики писали?


Вы к чему претензии-то предъявляете, я не понял? Да, у FB сейчас так как написано.
И да, Classic вполне удовлетворяет людей на вполне приличной нагрузке, которую я изложил.
Вы усомнились - я ответил. Вы теоретизируете - я вам даю общую информацию по практическим системам. Надо более конкретно - крупный банк, классик, 150 одновременных пользователей, база 10 гиг. Известная AVARDA, масса внедрений, база под 100 гиг, пользователей около 100 (см. у них на сайте в т.ч. о тестовом стенде инфу). Еще надо? Я не виноват, что люди спокойно используют FB Classic, и не ходят сюда чтобы послушать ваши теоретизирования о том, что Classic "не может нормально работать" (утрирую, т.к. это почти то же самое что высказывания про малое число коннектов и небольшие базы).

Если Вы под нормальным числом коннектов имеете в виду 800 и выше, а нормальный размер базы - 500 гиг и выше - да, пока ни FB ни IB в таких задачах не блещут, но, как бы, и не собирались.

Хотите еще примеров? смотрите сюда:
http://www.firebirdsql.org/devel/doc/papers/html/paper-fbent.html#who-uses-sampl

а то вы как то читаете однобоко. Там же как раз и про классик и про сервер.

А то пока дискуссия выглядит так
X: мы тут собираемся FB поставить...
DocAI: я слышал, что у FB херово с тем и с этим...

может, пора прекратить этот испорченный телефон?
24 дек 07, 00:44    [5086110]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
hvlad
DocAl
А что делают ваши пользователи с этими сотнями гигабайт и, в лучшем случае, единицами мегабайт кэша?
Кеширует файловая система.
Удивил ?
И как, хорошо помогает в сортировке, например? Также хорошо, как нормальный общий кэш СУБД?
24 дек 07, 07:28    [5086232]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
DocAl
hvlad
DocAl
А что делают ваши пользователи с этими сотнями гигабайт и, в лучшем случае, единицами мегабайт кэша?
Кеширует файловая система.
Удивил ?
И как, хорошо помогает в сортировке, например? Также хорошо, как нормальный общий кэш СУБД?

А проверить? Вот ещё один пример из реальной жизни
24 дек 07, 09:39    [5086414]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

DocAl

И как, хорошо помогает в сортировке, например? Также хорошо, как
нормальный общий кэш СУБД?

А каким местом общий кэш может помочь сортировке? Она производится в ОЗУ
если его хватает.

Posted via ActualForum NNTP Server 1.4

24 дек 07, 10:09    [5086541]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

DocAl

И как, хорошо помогает в сортировке, например? Также хорошо, как
нормальный общий кэш СУБД?

А каким местом общий кэш может помочь сортировке? Она производится в ОЗУ
если его хватает.
Posted via ActualForum NNTP Server 1.4
Ну, вообще, конечно, сортировка ведётся скорее в буфере, чем в кэше, но, т.к. в документации (назовём это так) речь идёт исключительно о кэше, я предположил, что в данной среде оба понятия называют одним словом.
Полагаю, я описываю типичное поведение СУБД в случае, если требуется провести сортировку: если данные, которые требуется отсортировать, умещаются в буфере, отведённом под эти цели, сортировка производится в нём, если нет -- используется временное хранилище на жёстком диске. Названия хранилища могут отличаться, суть одна: существенно большее время доступа к данным, особенно в плане случайного доступа.
Внимание, вопрос: когда чаще будет не хватать этого буфера, когда он один общий, или когда их 400 маленьких под каждое подключение?
Блин, я разжёвываю тут прописные истины, уж либо раскройте хитрые трюки, позволяющие обойти эту ситуацию в фаербёрде, либо признайте уже, что с масштабированием всё плохо. Не корову чай проигрываем.
24 дек 07, 10:29    [5086638]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

DocAl

т.к. в документации (назовём это так) речь идёт исключительно о кэше, я
предположил...

Нууу... Это общее свойство людей: все попытки оправдаться начинаются со
слов "я предположил", "я думал"...
Сортировка в ОЗУ настраивается совсем другими параметрами и к кэшу
данных никаким образом не относится. Сортировка на диске опять же
подпадает под файловый кэш ОСи, который чаще всего эффективнее кэша СУБД.
DocAl

Внимание, вопрос: когда чаще будет не хватать этого буфера, когда он
один общий, или когда их 400 маленьких под каждое подключение?

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

RTFM Firebird.conf

Posted via ActualForum NNTP Server 1.4

24 дек 07, 10:48    [5086729]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Gluk (Kazan)
Member

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

DocAl

И как, хорошо помогает в сортировке, например? Также хорошо, как
нормальный общий кэш СУБД?

А каким местом общий кэш может помочь сортировке? Она производится в ОЗУ
если его хватает.
Posted via ActualForum NNTP Server 1.4


Или "на лентах", если ОЗУ не хватает
24 дек 07, 11:10    [5086889]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

# In-memory sorting module
#
# The amount of memory allocated for each sort block.
#
# Type: integer
#
#SortMemBlockSize = 1048576

#
# 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

Ась? Я, наверное, плохо читать по-английски, но я это понимайть так, как описайть выше.
Dimitry Sibiryakov

Сортировка на диске опять же
подпадает под файловый кэш ОСи, который чаще всего эффективнее кэша СУБД.

зелен виноград...
24 дек 07, 11:12    [5086906]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Gluk (Kazan)
Member

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

DocAl
раскройте хитрые трюки

RTFM Firebird.conf


Партизаны колоца не хотели :)
24 дек 07, 11:14    [5086917]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

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

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

Откуда: Оккупирую западный берег
Сообщений: 10472
Gluk (Kazan)
Dimitry Sibiryakov

DocAl
раскройте хитрые трюки

RTFM Firebird.conf

Партизаны колоца не хотели :)
Да блин, писец хитрый трюк, заставили качать дистриб фаербёрда, чтобы прочитать на английском то же самое, что я сам только что писал на русском...
Видимо, демонстрировали основной аргумент: малый размер дистрибутива.
24 дек 07, 11:25    [5086981]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
FreemanZAV
Member

Откуда:
Сообщений: 2434
DocAl
Если же мы рассчитываем на кэш файловой системы, то, как минимум, мы имеем проблему двойной буферизаци

А вот нифига. Нужно не только читать по-английски, но и понимать.
24 дек 07, 11:27    [5086993]     Ответить | Цитировать Сообщить модератору
Топик располагается на нескольких страницах: Ctrl  назад   1 .. 16 17 18 19 20 [21] 22 23 24 25 .. 31   вперед  Ctrl
Все форумы / Сравнение СУБД Ответить