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

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

DocAl
Я, наверное, плохо читать по-английски

Да нет, читалка тут ни при чем. Тут проблемы с базовой логикой. Объясняю
медленно, на пальцах:
Вот коннект выдает запрос с необходимостью сортировки. Сервер всасывает
результат запроса в ОЗУ и начинает сортировать.
А вот два коннекта выдают запросы с необходимостью сортировки. Оба
результата всасываются в ОЗУ и начинают сортироваться.
Вопрос: какое ограничение во втором случае выгоднее - на каждый коннект
в отдельности или общее?

Posted via ActualForum NNTP Server 1.4

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

Откуда: Оккупирую западный берег
Сообщений: 10472
Dimitry Sibiryakov
Вопрос: какое ограничение во втором случае выгоднее - на каждый коннект
в отдельности или общее?
Posted via ActualForum NNTP Server 1.4
Конечно, общее. Примерно из тех же соображений, по которым у современных многоядерных процессоров общий кэш, а не раздельный.
24 дек 07, 12:14    [5087336]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
автор
Внимание, вопрос: когда чаще будет не хватать этого буфера, когда он один общий, или когда их 400 маленьких под каждое подключение?
Блин, я разжёвываю тут прописные истины, уж либо раскройте хитрые трюки, позволяющие обойти эту ситуацию в фаербёрде, либо признайте уже, что с масштабированием всё плохо. Не корову чай проигрываем.


да какую, блин, ситуацию надо обходить? Сортировки возникают не так часто, если говорить о сортировках, когда план запроса начинается с PLAN SORT, и серверу требуется доп. место для сортировки результата.
не хватает памяти - сортируется на диске. Причем например под виндами в temp-файлах, для которых ОС сама отводит дополнительную память и оптимизирует доступ.
Общего буфера сортировки нет. в Супере всего-лишь это считается общим куском памяти, где могут находиться блоки разных сортируемых запросов.

Но вообще это все фигня, потому что "масштабирование" и "сортировка" на мой взгляд вообще никак не связаны.

Ты уже утомил этими своими попытками доказать что "в FB все плохо". "Ну как же, у вас ведь там вот так, и вот эдак, а это ведь...". У каждого сервера есть свои недостатки. И разработчики с этими недостатками борются. И уж поверь, ни сортировка, ни Классик недостатками не являются.
24 дек 07, 12:21    [5087386]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
автор
Примерно из тех же соображений, по которым у современных многоядерных процессоров общий кэш, а не раздельный.

смотря какой кэш. см. сравнения по производительности использования общего кэша у Intel и у AMD. Так вот - не все там просто.

Вообще, конечно, пипец - такое впечатление что ты услышав об одной технологии пытаешься прилепить ее в другую область.
24 дек 07, 12:24    [5087415]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

Откуда: Оккупирую западный берег
Сообщений: 10472
kdv
автор
Внимание, вопрос: когда чаще будет не хватать этого буфера, когда он один общий, или когда их 400 маленьких под каждое подключение?
Блин, я разжёвываю тут прописные истины, уж либо раскройте хитрые трюки, позволяющие обойти эту ситуацию в фаербёрде, либо признайте уже, что с масштабированием всё плохо. Не корову чай проигрываем.


да какую, блин, ситуацию надо обходить? Сортировки возникают не так часто, если говорить о сортировках, когда план запроса начинается с PLAN SORT, и серверу требуется доп. место для сортировки результата.
не хватает памяти - сортируется на диске. Причем например под виндами в temp-файлах, для которых ОС сама отводит дополнительную память и оптимизирует доступ.
Общего буфера сортировки нет. в Супере всего-лишь это считается общим куском памяти, где могут находиться блоки разных сортируемых запросов.

Но вообще это все фигня, потому что "масштабирование" и "сортировка" на мой взгляд вообще никак не связаны.

Ты уже утомил этими своими попытками доказать что "в FB все плохо". "Ну как же, у вас ведь там вот так, и вот эдак, а это ведь...". У каждого сервера есть свои недостатки. И разработчики с этими недостатками борются. И уж поверь, ни сортировка, ни Классик недостатками не являются.

Сортировки возникают тогда, когда они возникают. Где-то редко, где-то часто. Где-то вообще все запросы -- это SELECT * FROM tblname, что ж теперь, считать csv файл идеально масштабируемым решением для СУБД?
И я не говорю, что в фаербёрде ВСЁ плохо, только лишь, что с масштабированием всё плохо. И, в общем-то, не только говорю, но и последовательно подтверждаю это цитатами из документации.
В итоге-то пришли к тому, что лучше всего фаербёрд работает с небольшим количеством соединений , которые работают с небольшим количеством независимых данных.
Потому как в какую сторону не крути нагрузку -- упираемся в ограничения.
Суперсервер -- более продвинутый, вроде бы, вариант, но без SMP, когда уже даже в ноутбуках пошли ставить двухядерники, кому он сдался такой? Так, legacy решения на legacy железе... Причём даже не серверном.
Классическая же схема была неплоха для ваксов, но на нынешний день это, да, привет из каменного века. Хорошо работает с одним соединением, чем их больше -- тем больше искусственный дефицит памяти и необходимость "редко сортировать".

Ну не согласны -- так покажите, в каком направлении оно хотя бы как-то масштабируется? И не "вот у них там работает", а как его заставить работать, когда "у них там" нагрузка вырастет хотя бы в 10 раз?
24 дек 07, 12:42    [5087524]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Локшин Марк
Member

Откуда: Воронеж
Сообщений: 3155
Dimitry Sibiryakov
А вот два коннекта выдают запросы с необходимостью сортировки. Оба
результата всасываются в ОЗУ и начинают сортироваться.
Вопрос: какое ограничение во втором случае выгоднее - на каждый коннект
в отдельности или общее?

Только не нужно всех убеждать, что единый кэш для всех потоков в СУБД это тоже самое, что и кэш файловой системы. Хотя бы потому, что файловая система ничего не знает о структуре данных, в отличие от той же СУБД. Не говоря уже про то, что записать/прочитать что-то в памяти явно быстрее чем гонять те же куски памяти туда-сюда между процессами дергая функции WinAPI.
24 дек 07, 12:43    [5087531]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Мимопроходящий
Member

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

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

DocAl
D> Блин, я разжёвываю тут прописные истины
кому?
мусье мого серверов написал?
DocAl
И я не говорю, что в фаербёрде ВСЁ плохо,
только лишь, что с масштабированием всё плохо.
ты его щупал за вымя?
ну а фули тогда звонишь?
пустозвонство сплошное...

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

Posted via ActualForum NNTP Server 1.4

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

Откуда: Оккупирую западный берег
Сообщений: 10472
МП, ты б по делу написал сначала, потом бы других в пустозвонстве обвинял.
Суперсервер нормально масштабируется по процессорам?
Классическая архитектура не жрёт немеряно памяти для нормальной работы со многими соединениями?
24 дек 07, 13:10    [5087725]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

DocAl

Классическая архитектура не жрёт немеряно памяти для нормальной работы
со многими соединениями?

Нет, не жрет. А должна?

Posted via ActualForum NNTP Server 1.4

24 дек 07, 13:12    [5087735]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Мимопроходящий
Member

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

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

DocAl
D> Классическая архитектура не жрёт немеряно
D> памяти для нормальной работы со многими соединениями?
немеряно не жрет.
нормально работает.
об чём тебе пытаются поведать те, кто реально пользует FB CS.

ps: а учить разработчиков сервера "как надо по-правильному", право же не стоит.

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

Posted via ActualForum NNTP Server 1.4

24 дек 07, 13:14    [5087749]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
FreemanZAV
Member

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

Классическая архитектура не жрёт немеряно памяти для нормальной работы со многими соединениями?

Посмотрел сейчас статистику. 4.6 гига на 160 коннектов. Это примерно 30 метров на коннект.
Может, конечно и многовато. Но это только и всего (с). Других проблем нет.
24 дек 07, 13:32    [5087897]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

Классическая архитектура не жрёт немеряно памяти для нормальной работы со многими соединениями?

Посмотрел сейчас статистику. 4.6 гига на 160 коннектов. Это примерно 30 метров на коннект.
Может, конечно и многовато. Но это только и всего (с). Других проблем нет.
Всё ж таки, этим 4.6 гигам можно было найти и получше применение. Даже в качестве файлового кэша, если фаербёрд так на него полагается.
24 дек 07, 13:37    [5087937]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

DocAl

Всё ж таки, этим 4.6 гигам можно было найти и получше применение.

Кваку погонять?

Posted via ActualForum NNTP Server 1.4

24 дек 07, 13:42    [5087966]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
softwarer
Member

Откуда: 127.0.0.1
Сообщений: 67463
Блог
FreemanZAV
Посмотрел сейчас статистику. 4.6 гига на 160 коннектов. Это примерно 30 метров на коннект.

Это действительно многовато, имхо, хотя конечно надо смотреть, что за база и что за коннекты. Цифра, которую я обычно вспоминаю - восьмигиговый сервер, обслуживающий ~ 750 коннектов с типичной смешанной нагрузкой (OLTP + отчеты) (Oracle).
24 дек 07, 13:50    [5088026]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
hvlad
DocAl
Тоже, небось, теоретики писали?
Вот один из рассказов практиков


апупеть 290779 иранзакций за 32 часа, это ж более 2х транзакций в секунду, мда впечатляющая цифра.
24 дек 07, 14:03    [5088110]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

DocAl

Всё ж таки, этим 4.6 гигам можно было найти и получше применение.

Кваку погонять?
Posted via ActualForum NNTP Server 1.4
Да нет, вполне себе рабочее применение. 5 гиговую базу вообще целиком в кэш всосать можно было бы.
Опять же, что делать, если потребуется не 160 соединений, а 600?
Всё ж таки, более 16 гигов за простую возможность сортировать 30-ти метровую выборку в памяти -- совсем перебор.
24 дек 07, 14:15    [5088171]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Мимопроходящий
Member

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

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

DocAl
D> Всё ж таки, более 16 гигов за простую возможность
D> сортировать 30-ти метровую выборку в памяти -- совсем перебор.
достал ты этим детским лепетом про сортировку...
ей Богу!

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

Posted via ActualForum NNTP Server 1.4

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

Откуда: Оккупирую западный берег
Сообщений: 10472
Ок, хрен с ней, с сортировкой. Выборка по индексу. Индекс где хранится?
24 дек 07, 14:26    [5088244]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Мимопроходящий
Member

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

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

DocAl
D> Ок, хрен с ней, с сортировкой.
D> Выборка по индексу. Индекс где хранится?
не поверишь...
в базе!

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

Posted via ActualForum NNTP Server 1.4

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

Откуда: Оккупирую западный берег
Сообщений: 10472
Обычно, если запрос использует индекс, этот индекс загружается в специально отведённый буфер, где и производятся все необходимые манипуляции. Я не могу ручаться, т.к., с имеющейся документацией, выяснить это можно только ковыряясь в коде, но считаю весьма вероятным, что эти буфера также никак не пересекаются.
24 дек 07, 14:55    [5088490]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
DocAI
И, в общем-то, не только говорю, но и последовательно подтверждаю это цитатами из документации.


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

DocAI
В итоге-то пришли к тому, что лучше всего фаербёрд работает с небольшим количеством соединений , которые работают с небольшим количеством независимых данных.


кто пришел, и к кому? ты вот за свои слова про "небольшие" отвечаешь? что значит "небольшие" - 1000? 15 сантиметров?

честное слово, редко такие граждане, но встречаются. Прямо почти ЧАЛ из соседних топиков. Ты ему одно - он тебе вообще про другое, и знай свое талдычит...
24 дек 07, 15:59    [5089089]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30253
DocAI
Обычно, если запрос использует индекс, этот индекс загружается в специально отведённый буфер, где и производятся все необходимые манипуляции. Я не могу ручаться, т.к., с имеющейся документацией, выяснить это можно только ковыряясь в коде, но считаю весьма вероятным, что эти буфера также никак не пересекаются.


слушай, ну достал ты. я понимаю, когда сервер можно критиковать за какое-то нестандартное поведение в SQL, или совсем явные плюхи. НО КРИТИКОВАТЬ ПО ДОКУМЕНТАЦИИ, ТЕОРЕТИЗИРУЯ - это что-то новое. Тем более не могу тебя понять - тебе кто-то на мозоль наступил? Что ты к FB приколебался? А InterBase тебе нравится? Там суперсервер масштабируется на SMP. А ?

Тебя не устраивает производительность FB на конкретной системе? Нет? Тогда что у тебя чешется?
24 дек 07, 16:05    [5089135]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

kdv
Прямо почти ЧАЛ из соседних топиков.

Ну так не зря же у него ник ДочАл...

Posted via ActualForum NNTP Server 1.4

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

Откуда: Оккупирую западный берег
Сообщений: 10472
Бл., зае.ли. Нравится вам неху.вый стократный оверхед по памяти -- ешьте, других-то нахрена подписывать?! И ещё басни рассказывают про линейное масштабирование!
24 дек 07, 16:48    [5089470]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Мимопроходящий
Member

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

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

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

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

Posted via ActualForum NNTP Server 1.4

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