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

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

ЗЫ. а фулскан, в оракле, он и индекса может быть ...
26 дек 07, 18:51    [5100756]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
DocAl
Member

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

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

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

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

Откуда: iBase.ru
Сообщений: 30237
попробуем еще раз:
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.

в дополнение, ссылка на хелп по виндовой функции ReadFileScatter.
http://msdn2.microsoft.com/en-us/library/aa365469.aspx

т.е. грубо говоря, Scattered read это чтение данных в непоследовательно расположенные блоки памяти.

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

я так понял, что НГ уже начался :-)

FB не может не использовать кэш оси. он не умеет его НЕ использовать, и не умеет использовать. Просто когда FB читает файл БД, кэш ОС при этом НЕ выключен. Собственно, все.

И я не зря привел скорость дискового io на select count, который идет мимо кэша FB (а не мимо файлового кэша операционки) - никаких проблем с производительностью тут нет.

p.s. у Yaffil есть парамер сервера WIN32_DISABLE_FILE_CACHE, который позволяет отключить файловый кэш ОС при работе с БД (это была экспериментальная опция). Однако, в данном случае на производительность сильно влияет совпадение размеров страницы и размера кластера ФС. То есть, такое отключение кэша ОС может дать прирост производительности в определенных случаях, но в основном оно ухудшает производительность, т.к. у FB/YA/IB нет префетча (если я правильно помню).
26 дек 07, 19:30    [5100849]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
2kdv

вы надсмехуиваетесь надо мне !?
на пальчиках: мулти блочное чтение потому и завется мултиблочным что одной командой достает несколько последовательно лежащих блока, имеенно от того такое чтение гораздо быстрее. вы там следите за мыслью, попробуйте сконцентрироватся еще на пару секунд. теперь, куда читает, правильно в RAM, как там располагая ? правильно scattered, от того еще одно название такого чтения scattered. не поверите, но те бусурмане, что вы процитировали именно это и написали :)

по ReadFileScatter, потрясающе, вы же нашли команду которую наверника FB и юзает, там же прямо и пишут: The file handle must be created with the GENERIC_READ right, and the FILE_FLAG_OVERLAPPED and FILE_FLAG_NO_BUFFERING flags.

ну не может FB применяя scattered read использовать кеш оси, т.к. это по сути команда железяки...
26 дек 07, 22:03    [5101071]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

Yo.!
теперь, куда читает, правильно в RAM

Ну и смысл тогда в нем, если оно все равно забивает RAM? "RAM может и на
более полезные вещи расходоваться." В кваку погонять, например.

Posted via ActualForum NNTP Server 1.4

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

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

kdv wrote:
> многопоточный. на уровне одного коннекта - нет. и это нормально.
> прошу назвать многопоточных клиентов, которые позволяют реально
> многопоточно работать с сокетом коннекта.

А это неважно, умеет ли кто. Ибо практически никто, кроме FB не
поддерживает множественные транзакции в одном коннекте. И свое, одно из
немногих, преимущество FB опять же использует слабо, не давая
возможности в разных потоках использовать одно подключение (пока еще.
Можек к 2010 научится).

Posted via ActualForum NNTP Server 1.4

27 дек 07, 09:27    [5101613]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

zhouck
Можек к 2010 научится).

Вряд ли. Для этого нужен как минимум принципиально новый сетевой протокол.

Posted via ActualForum NNTP Server 1.4

27 дек 07, 09:37    [5101642]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30237
Yo
вы надсмехуиваетесь надо мне !?

нет, просто терминологию поправляю.

FB не использует readfilescatter.
27 дек 07, 10:35    [5101992]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
Dimitry Sibiryakov

Yo.!
теперь, куда читает, правильно в RAM

Ну и смысл тогда в нем, если оно все равно забивает RAM? "RAM может и на
более полезные вещи расходоваться." В кваку погонять, например.
Posted via ActualForum NNTP Server 1.4

гы-гы, я тоже им говорил чего это они дедовскими способами польщуются, надо ж прямо в мозг читать
про мультиблочное чтение и вымывание кеша в кратце можно тут почитать:
http://oradba.com.ru/tuning/optimizer/articles/a2_srchintellcbo/page9.shtml

2kdv

зашибись, вообще нет мультиблочного чтения. ну что же, теперь осталось выяснить есть ли если такое чтение в mysql.
27 дек 07, 10:57    [5102165]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

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

так Влад же сразу сказал - никто не говорит что FB это Оракл.
а по мультиблочному чтению - цитата по ссылке:

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

Упрощенный алгоритм кэширования ввода/вывода и эффект "очистки"

ничего нового, я говорил, что меры против такого эффекта были приняты в IB 6, семь лет назад.

собственно, технологии можно обсуждать, пробовать, и т.д. Но не всегда какие-то технологические изыски будучи примененными могут дать ожидаемый эффект. Если же мы разбираем какие-то технологические особенности Firebird - кэш, сортировки, SMP и т.д. - то в отрыве от сервера целиком их рассматривать бесполезно.
Например, в Yaffil в отношении IB 6 и FB 1 было применено много изменений - оптимизатор, алгоритмы работы со страницами, оптимизированные участки кода, и т.п. В сумме это давало иногда шокирующие результаты для людей, работавших прежде с IB 5 - их система, переведенная на Yaffil, начинала работать в 5-7 раз быстрее!
Но каждое отдельное такое изменение могло улучшать работу сервера всего на 3-4%.

И, не забывайте, что Firebird отлично масштабируется по объему задачи - от встраиваемого движка в однопользовательские приложения, до обработки баз в 100-150 гиг при ~500 одновременных пользователях.

Конечно, привыкшим к Oracle странно видеть отсутствие в FB тонких настроек типа экстентов, индексов, кэша и др. Но в FB пока в этом нет необходимости.

Разработчики FB, в свою очередь, не сидят на месте, а постоянно работают над улучшением оптимизатора, ввода-вывода, и т.п.
27 дек 07, 11:54    [5102625]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
2kdv
подозреваю вы уже в курсе моего отношения к "мерам" практически всех областей FB. может оно и "отлично маштабируется" относительно фокспро, но вот на фоне того же mysql выглядит бледно, при том что mysql явно не самый продвинутый представительь опен соурса. за 5-6 лет что я тут ошиваюсь mysql обзавелся нормальным в архитектурном плане MVCC (с раздельным UNDO, не нуждающимся в сборке мусора), адекватными для версионника уровнями изолированости, нормальным буферным кешем, кешем для планов, нормальным REDO, оптимизатор научился вложеным запросам и т.п. FB же за это время даже вопиющие баги так и невыпрямил, не говоря о заметных архитектурных (кэш, стоимостный оптимизатор, read comitted)

короче полазил по mysql, выглядит что там есть все зачатки, но непосредственно scattered read не используется, есть некий read-ahead, который почему-то ReadFileScatter не использует (причем в исходниках красуется комент "ReadFileScatter ?" ).
27 дек 07, 16:31    [5104315]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30237
вопрос в том, в каком движке MySQL все перечисленные прелести есть, каковы они на самом деле (а не по прочтению документации), и какой движок наиболее популярен. Так вот, тут, насколько я в курсе, Вас ждут удручающие открытия.
На текущий момент MySQL Firebird-у не конкурент. И наоборот. То есть, до сих пор для веба используется MySQL 3.x, а в клиент-серверных бизнес-решениях - наоборот, Firebird а не MySQL. Кроме того, новая лицензия MySQL серьезно подкосила его рынок. Для коммерческих решений теперь его просто боятся использовать. Если Вы не в курсе - извините.
Кроме того, еще в 2005 году Evans Data оценила рынок OpenSource RDBMS для MySQL и Firebird пополам - по 40 %.

Yo
даже вопиющие баги так и невыпрямил

какие именно? особенно супротив MySQL.

Yo
MVCC (с раздельным UNDO, не нуждающимся в сборке мусора),

сильно сомневаюсь... можно ссылочку? не InnoDB часом, который купил Oracle?
27 дек 07, 23:19    [5105474]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
спешу вас разочаровать, разберитесь чего считал Evans, дайте источник, методику и т.п. как они считали ?? что считали ?? коню ясно, что свалили в кучу десктопные, серверные и встроеные субд, а считали небойсь по sourceforge.
тут forrester research посчитал бизнес решения в Enterprise, я не вижу там FB ...
по багам FB и GPL я устал повторятся ... просто попробуйте заучить что GPL код нельзя купить, GPL код можно использовать в комерческих целях не раскрывая свой закрытый код. мало того можно спиздить GPL код конкурента добавить пару своих закрытых утилит и ПРОДАВАТЬ в своей коробке (Oracle Linux)
28 дек 07, 00:25    [5105570]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
kdv
Member

Откуда: iBase.ru
Сообщений: 30237
автор
forrester research

форрестер - проплаченное говно. я про это писал тут, про отчет 2006 года:

http://interbase.blogspot.com/2006/06/forrester-vs-firebird.html

кстати, FB в отчете 2006 года упоминается, а в 2007 - нет. Весьма странно, что не делает чести Forrester, т.к. Firebird используется наравне с MySQL, я Вас уверяю.

Yo
по багам FB и GPL я устал повторятся

устал не устал - мне пофиг. я списка не видел. Наверняка списка не видели и hvlad и de - ведущие разработчики Firebird. Конечно, это здорово, пописывать про "баги" тут и там, авось разработчики чего-нибудь где-нибудь прочитают. Да?

Yo
GPL код можно использовать в комерческих целях не раскрывая свой закрытый код

да это все я знаю. gpl код можно продавать на дисках, расписанных под хохлому. я про РАСПРОСТРАНЯЕМЫЕ приложения. А не про используемые внутри компаний, где GPL по барабану.
28 дек 07, 00:35    [5105579]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Yo.!
Guest
я тоже не в восторге от имениных аналистов, но тут хотя бы понятно откуда и как высосаны цифры. а по большому счету согласен с аналистом и по поводу leaderless (даже на фоне mysql) и по поводу mission critical (лог транзакций, smp), что за собой тянет small ...

баги тут: https://www.sql.ru/forum/actualthread.aspx?tid=191005&pg=2#1650676

по GPL: не вижу проблемы скачать субд с сайта производителя с последними апдейтами и тыкнуть в 2 инстолятора если я выбрал и заплатил за продукт. если вы про десктопные проги, там встроеные субд бодаются - совсем другая опера.
28 дек 07, 01:40    [5105653]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

Yo.!
баги тут:

Ах, не смешите уже народ, выдавая своих тараканов за багов...

Posted via ActualForum NNTP Server 1.4

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

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

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

Dimitry
Yo.
баги тут:

DS> Ах, не смешите уже народ, выдавая своих тараканов за багов...
забей.
человек болен.

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

Posted via ActualForum NNTP Server 1.4

28 дек 07, 11:55    [5106810]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

Мимопроходящий
забей.
человек болен.

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

Posted via ActualForum NNTP Server 1.4

28 дек 07, 12:03    [5106859]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
alex_k
Member

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

какой-нибудь неприличный флуд страниц этак на пять...

странно это читать на 25ой странице флуда :)
28 дек 07, 12:49    [5107236]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

alex_k
странно это читать на 25ой странице флуда :)

Там флуд уже несвежий, а тут как раз ящик флеймогонки подвезли.

Posted via ActualForum NNTP Server 1.4

28 дек 07, 12:55    [5107281]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

Yo.!
полазил по mysql, выглядит что там есть все зачатки

Мускуль может сколь угодно гордиться своими зачатками, распродавая их по
частям Ларри или Биллу, но его судьба уже предрешена: руководство FF
мудро и дальновидно (а главное - злобно) забросило в тыл Джима Старки.

Posted via ActualForum NNTP Server 1.4

28 дек 07, 13:11    [5107374]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
leonbn
Member

Откуда: СПб
Сообщений: 522
Что бы не говорили hvlad и Dimitry Sibiryakov у МайСКюЛь есть дока, коя полностью отсутствует у ФБ. Соответственно, все про MyQL мы узнаем из доки, а про ФБ пытаемся домыслить со слов вышеуказанных товарищей!!!
29 дек 07, 00:48    [5109903]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

leonbn

Соответственно, все про MyQL мы узнаем из доки

Да, с этим я согласен. Именно из доки к нему я узнал о туче багов и
ограничений.

Posted via ActualForum NNTP Server 1.4

29 дек 07, 08:19    [5110106]     Ответить | Цитировать Сообщить модератору
 Re: MySQL vs Firebird  [new]
Dimitry Sibiryakov
Member

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

Dimitry Sibiryakov
Именно из доки

Хотя нет - вру. О непригодности к серьезной эксплуатации - действительно
из доки. А про баги - на левом сайте.

Posted via ActualForum NNTP Server 1.4

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