Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Уважаемые коллеги! Прошу помочь вспомнить и упорядочить сравнительные характеристики Firebird, MySQL и PostgreSQL (современных версий). Без священных войн, без флеймов - просто аргументы, желательно по следующим направлениям: 1) Почему эти серверы находятся в разных нишах (находятся ли)? 2) Преимущества и недостатки реализации серверной логики (языки, хп, инструменты разработчика) 3) Преимущества и недостатки разработки десктопных приложения (компоненты и их качество, совместимость с популярными средами разработки) 4) Любые другие моменты, которые кажутся важными. Если кто то готов написать 1-2 абзаца на тему "Почему мы выбрали Firebird для разработки приложения NNN", будет очень хорошо - можете присылать на [EMAIL PROTECTED] Если кто-то может взвешенно, но конкретно сравнить Firebird c коммерческими приложениями (Oracle, MS SQL, etc), например, в какой-то конкретнйо области, то пишите тоже. С Interbase сравнивать не надо, материала достаточно :) С уважением, Алексей Ковязин
Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry пишет: Вот скажите мне - через что работают с MSSQL из Delphi ? Через что хотят, через то и работают. ADO, BDE, ODBC и т.п. Но в целом кажется гораздо меньше заморачиваются по "родным" компонентам "прямого" доступа.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Добрый день, Alexey! Вы писали от Thu, 14 Sep 2006 03:53:30 -0700: AK> Прошу помочь вспомнить и упорядочить AK> сравнительные характеристики Firebird, MySQL AK> и PostgreSQL (современных версий). AK> 4) Любые другие моменты, которые AK> кажутся важными. Может не совсем по теме, но 0.Функционал имеет не первостепенную роль при выборе БД 1. Один из самых важных моментов влияющих на распространенность FB это его отсутствие в стандартных дистрибутивах Linux и FreeBSD с нормально документацией 2.Отсутствие поддержки FB в качестве основной БД для распространенных демонов Unix, например почтовиков 3. Отсутствие поддержки FB в стандартных СМS для WEB сайтов В целом FB 2.0 по функционалу во многих вопросах выглядит лучше чем MySQL и PostgreSQL для многих задач. Все упирается в фору по времени, которую получили на момент взрывообразного роста интернет MYSQL и в меньшей части PostgreSQL. По анализу продаваемого на Softkey.ru ПО, работающего с БД, для малого бизнеса и домашнего пользования, FB уверенно опережает MYSQL и PostgreSQL в разы по распространнености, Из этого можно сделать вывод о том, что на платформе Windows для desktop приложений, FB имеет большую распространненость чем на Unix подобных системах. С Уважением, Константин Зайцев.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Konstantin! Konstantin Zaitcev wrote: По анализу продаваемого на Softkey.ru ПО, работающего с БД, для малого бизнеса и домашнего пользования, FB уверенно опережает MYSQL и PostgreSQL в разы по распространнености, Из этого можно сделать вывод о том, что на платформе Windows для desktop приложений, FB имеет большую распространненость чем на Unix подобных системах. и по моим данным IB/FB на Windows - 70%, на разных Unix - 30%. то же самое можно сказать по числу downloads дистрибутивов. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, All! сравнительные характеристики Firebird, MySQL и PostgreSQL (современных версий). Без кстати, я на sql.ru постил буквально вчера или позавчера. MySQL теперь четко определил в коммерческой лицензии когда нужно покупать MySQL. http://www.mysql.com/company/legal/licensing/commercial-license.html если раньше можно было написать закрытую софтину, и сказать клиенту - скачай MySQL сам, то теперь - шиш. Коммерческая лицензия приобретается разработчиком, продавцом или клиентом, в случаях: - Selling software that requires customers to install MySQL themselves on their own machines. - If you include the MySQL server with an application that is not licensed under the GPL or GPL-compatible license, you need a commercial license for the MySQL server. - If you develop and distribute a commercial application and as part of utilizing your application, the end-user must download a copy of MySQL; for each derivative work, you (or, in some cases, your end-user) need a commercial license for the MySQL server and/or MySQL client libraries. и даже хуже - дальше там текст про аналогичное использование драйверов для MySQL. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Dmitri Kuzmenko said the following on 14.09.2006 15:08: > MySQL теперь четко определил в коммерческой лицензии > когда нужно покупать MySQL. Да, они там могут писать все что угодно... > http://www.mysql.com/company/legal/licensing/commercial-license.html > > если раньше можно было написать закрытую софтину, > и сказать клиенту - скачай MySQL сам, то теперь - шиш. ...но пока MySQL доступен и под GPL я точно так же могу писать закрытую софтину, если только я не линкую ее с клиентской библиотекой от MySQL. Причем меня может устроить клиентская библиотека от MySQL 4.0.x - которая была еще под LGPL, т.е. по условиям лицензии мне достаточно указать где-нибудь в readme что я использую эту библиотеку. Кроме того я могу реализовать протокол mysql самомтоятельно, или купить у сторонних разработчиков вроде http://crlab.com/ При этом коммерческая лицензия на сам MySQL не нужна. Но все вышесказанное, конечно, не отменяет того что MySQL - редкостный отстой ;-) -- Oleg
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
В FB (как и в IB) самым ценным (в смысле идей) по сей день является физическая структра БД, транзакционный движок и ещё кое что из jdr. Тому кто это заложил в IB - мега респект. Увы больше ничего качественно нового создано небыло. Медленная но уверенная эволюция. -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Oleg! Oleg Deribas wrote: MySQL теперь четко определил в коммерческой лицензии когда нужно покупать MySQL. Да, они там могут писать все что угодно... ты прав. они авторы, имеют право писать все что угодно. ...но пока MySQL доступен и под GPL я точно так же могу писать закрытую софтину, если только я не линкую ее с клиентской библиотекой от MySQL. забей. про линковку уже они не говорят. Если твоя прога не GPL и она МОЖЕТ работать с MySQL, то или ты или твой клиент должен покупать MySQL. Причем меня может устроить клиентская библиотека от MySQL 4.0.x - которая была еще под LGPL, т.е. по условиям лицензии мне достаточно уже поздно. мне начать материться по поводу "не читают" и тут? :-) Бесплатным оставлен MySQL 3.22.19 (или как его там). Выше все подчиняется новым правилам. Кроме того я могу реализовать протокол mysql самомтоятельно, реализуй. это не отменяет того, что твоя программа может работать с MySQL. Формулировки изменились. или купить у сторонних разработчиков вроде http://crlab.com/ При этом коммерческая лицензия на сам MySQL не нужна. прежде чем придумывать, лучше изучить все имеющиеся тонкости. crlab если не распространяет свои дрова под gpl, должен тебя обязать купить драйвер к mysql. И вообще, нет там уже слов кроме "использует". Если твоя софтина коммерческая и РАБОТАЕТ с MySQL - все, ты ОБЯЗАН для конкретной установки купить коммерческий MySQL. Или не ты, а твой клиент. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Так, понятно что MySQL уже не совсем Open Source из-за лицензионных вопросов. Но что с PostgreSQL? Про 1С интересная информация, но по пунктам 1-3 есть какие то мысли? Или просто любые мысли по сравнению? С уважением, Алексей Ковязин
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitri Kuzmenko wrote: забей. про линковку уже они не говорят. Если твоя прога не GPL и она МОЖЕТ работать с MySQL, то или ты или твой клиент должен покупать MySQL. Если твоя софтина коммерческая и РАБОТАЕТ с MySQL - все, ты ОБЯЗАН для конкретной установки купить коммерческий MySQL. Или не ты, а твой клиент. Оба предложения касаются *только* распространяемого софта. Если я свой софт использую у себя (пусть даже и в коммерческих целях), то никому я ничего не должен. -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexey Kovyazin wrote: > Так, понятно что MySQL уже не совсем Open Source из-за лицензионных вопросов. Очень даже Open Source :-) Просто надо понимать ограничения. Но что с PostgreSQL? Начиная с версии 8 - хороший сервер. Уступает нам лишь в распространенности в бизнес-сфере и в некоторых технических аспектах. По функциональности сильно превосходит. -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
"Dmitry Lendel" ... > А что мешает сделать лучше, кроме времени, сил и денег? Тут мало причин ? :))) -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
> распространенности в бизнес-сфере и в некоторых технических аспектах. По О технических аспектах можно подробнее :-)
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
"Dmitry Lendel" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > Достаточно. :-)) Я было подумал, что может есть еще причины. Например, код > тоскливый, концептуальные ошибки или что-то еще. > Дмитрий В дополнение к этим. И код у FB местами крайне тоскливый и концептуальных косяков хватает :-(.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello,
Dmitri Kuzmenko said the following on 14.09.2006 19:33:
>> ...но пока MySQL доступен и под GPL я точно так же могу писать закрытую
>> софтину, если только я не линкую ее с клиентской библиотекой от MySQL.
>
> забей. про линковку уже они не говорят. Если твоя прога не GPL
> и она МОЖЕТ работать с MySQL, то или ты или твой клиент
> должен покупать MySQL.
>
>> Причем меня может устроить клиентская библиотека от MySQL 4.0.x -
>> которая была еще под LGPL, т.е. по условиям лицензии мне достаточно
>
> уже поздно. мне начать материться по поводу "не читают" и тут? :-)
> Бесплатным оставлен MySQL 3.22.19 (или как его там). Выше все
> подчиняется новым правилам.
Это не я не читаю, это ты не читаешь ;)
MySQL доступен под _двумя_ лицензиями. Что они там пишут в коммерческой
лицензии или как они трактуют биб..., вернее GPL - это их проблемы. Но
MySQL _можно_ использовать на условиях GPL, и именно на этих условиях он
входит в многочисленные дистрибутивы linux. Т.е. мне достаточно
выполнять условия GPL, все остальное - это домыслы.
Читаем FAQ: http://www.gnu.org/licenses/gpl-faq.html#GPLInProprietarySystem
If people were to distribute GPL-covered software calling it "part of" a
system that users know is partly proprietary, users might be uncertain
of their rights regarding the GPL-covered software. But if they know
that what they have received is a free program plus another program,
side by side, their rights will be clear.
Т.е. я не распространяю MySQL как часть моей системы ("part of"), и я не
использую в своей программе GPL-ные библиотеки MySQL.
>> или купить
>> у сторонних разработчиков вроде http://crlab.com/
>> При этом коммерческая лицензия на сам MySQL не нужна.
>
> прежде чем придумывать, лучше изучить все имеющиеся
> тонкости. crlab если не распространяет свои дрова под
> gpl, должен тебя обязать купить драйвер к mysql.
Нет. Они продают свои собственные драйверы, причем это значительно
дешевле чем коммерческая лицензия на MySQL. Для MySQL это невыгодно,
конечно, но сделать они ничего с этим не могут. Мало того - это их
сертифицированный партнер:
http://solutions.mysql.com/solutions/item.php?id=248
> И вообще, нет там уже слов кроме "использует".
> Если твоя софтина коммерческая и РАБОТАЕТ с MySQL -
> все, ты ОБЯЗАН для конкретной установки купить
> коммерческий MySQL. Или не ты, а твой клиент.
Да, именно так сделан их сайт. Чтобы внушить читающему неизбежность
покупки коммерческой лицензии... ;-)
Но как только они перестанут распространять свой продукт под GPL, его
тут же не будет ни в одном дистрибутиве линукса - и этим они только
нанесут удар по собственному бизнесу ;)
--
Oleg
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
hi "Oleg Deribas" > Да, именно так сделан их сайт. Чтобы внушить читающему неизбежность > покупки коммерческой лицензии... ;-) > Но как только они перестанут распространять свой продукт под GPL, его > тут же не будет ни в одном дистрибутиве линукса - и этим они только > нанесут удар по собственному бизнесу ;) Все правильно у них есть GPL лицензия но еще есть LGPL (для версии 3.чегото там), но лично я почемуто не стремлюсь распространять весь свой код под GPL. А она заразная, т.е. смысл послания их сайта не то что бы купите их лицензию а то что или дарито свой код или купите наш. WBR Evgeny Putilin.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Oleg Deribas пишет: Это не я не читаю, это ты не читаешь ;) Нет, это ты не понял. Это просто анти-PR акция. Ход, практикуемый адвокатами или обвинителями в судах с присяжными - выдать какую-либо информацию, которую может и не пришьют к делу, но осадочек в умах присяжных останется, который потом может повлиять на решение при сомнениях :)
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Alexander Goldun said the following on 15.09.2006 13:15: >> Это не я не читаю, это ты не читаешь ;) > > Нет, это ты не понял. Это просто анти-PR акция. Ход, практикуемый > адвокатами или обвинителями в судах с присяжными - выдать какую-либо > информацию, которую может и не пришьют к делу, но осадочек в умах > присяжных останется, который потом может повлиять на решение при > сомнениях :) Так ведь я примерно то же самое написал, но немного другими словами ;-) -- Oleg
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Начиная с версии 8 - хороший сервер. У них по прежнему на подключение процесс создаётся типа как в нашем классике?
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
sasha wrote: У них по прежнему на подключение процесс создаётся типа как в нашем классике? Да. Только у них буферный кеш общий между процессами. -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitri Kuzmenko пишет: Поэтому впечатление такое, что поскольку ликвидировать мифы об IB/FB невозможно, нужно просто запускать похожие факты-мифы о других серверах. Про платность MySQL под GNU - из того же разряда? ;)
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
> > Про cooperative vs background gc > > слыхивал ? А про IB6 ? За FB2 уже не спрашиваю ;))) > > Так в IB вроде сразу два типа - и кооперативная и фоновая. > Собственно я выступаю ни за ту, ни за другую сборку. > Нужно нечто промежуточное - кооперативный поиск мусора и > фоновая чистка. А что такое background gc по-твоему ? > >>Автоматический sweep как таковой не нужен. > > > > Та ты шо ?! А OIT вверх продвигать кто будет ? Jim ? Так он в MySQL ушёл > > ;))) > > Можно предложит вариант с перерасчётом при commit, но отложенно > в мусорщике. Ты понимаешь причины застревания OIT ? А механизм его сдвига после застревания ? > > А про sweep_interval мы тоже не слыхивали ? > > sweep_interval - однозначно кривое решение проблемы. ИМХО. Никто не запрещает выставить его в 0 > >>Но например автоматическое обновление статистики индексов реально нужно. > > Причём тут это к сборке мусора ? > > При том что задача в целом аналогична сборке мусора. И требуются > примерно аналогичные решения. Я тупой и не вижу аналогий > Кстати, проблема устаревания статистики > как то не вызывает резонанс у общественности. Ибо статистика пока слабо пользуется оптимизатором. Вот когда будут гистограммы, тогда можно будет озаботиться и об этом > >>А кстати TIP урезается снизу иди нет? > > > > Первая внятная мысль :) Пока нет. Но будет. Позже. Ибо не самое критичное. > > Если при snapshot делается копия не всей TIP, то действительно не критично. А с какой стати делать копию всего TIP ? А что такое OIT и накуя он нужён ? -- Хорсун Влад PS сабж восстановил чтобы было понятно, о чём мы говорим :)))
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: А что такое background gc по-твоему ? По моему это когда фоновый поток периодически проверяет все данные на предмет мусора. Можно предложит вариант с перерасчётом при commit, но отложенно в мусорщике. Ты понимаешь причины застревания OIT ? А механизм его сдвига после застревания ? Блин, у меня дикий своппинг в мозгу - вспомнить всё :-0 Застревает как я понимаю если сделат rollback. Чтобы сдивинуть потом нужно в TIP пометить эту транзакцию как commited, но при условии что версии из rollback транзакции почищены. Это всё в свою очередь возможно если нет работающих snapshot транзакций запущенных _до_ старта rollback транзакции. Вот какая хренотень. Получается что основная проблема - это сборка версий старой rollback транзакции. Для этого надо пробегать все таблицы базы... либо Вообщем я пока пас :-| При том что задача в целом аналогична сборке мусора. И требуются примерно аналогичные решения. Я тупой и не вижу аналогий Ну вместе со свипом пересчитывать статистику. Ибо статистика пока слабо пользуется оптимизатором. Достаточно чтобы похерить план :-) Основная проблема - пустая база создаётся из скрипта и бросается на произвол судьбы юзерам. -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Alexander! Alexander Goldun wrote: Поэтому впечатление такое, что поскольку ликвидировать мифы об IB/FB невозможно, нужно просто запускать похожие факты-мифы о других серверах. Про платность MySQL под GNU - из того же разряда? ;) не gnu, а gpl. и не платность под gpl, и т.п. И вообще, сказал А, говори Б. есть как минимум несколько вариантов 1. распространение gpl-приложений с gpl MySQL 2. распространение не-gpl приложений, использующих MySQL 3. разработка приложений внутри компании, работающих с MySQL ... разумеется, что платность относится ко второму случаю. p.s. вопрос надо рассматривать целиком, а не частями. также по фактам одной части не надо утверждать что этот факт распространяется на все остальные случаи. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Alexey! Alexey Popov wrote: Ну вместе со свипом пересчитывать статистику. это разные задачи. несовместимые. -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitri Kuzmenko пишет: Поэтому впечатление такое, что поскольку ликвидировать мифы об IB/FB невозможно, нужно просто запускать похожие факты-мифы о других серверах. Про платность MySQL под GNU - из того же разряда? ;) не gnu, а gpl. и не платность под gpl, и т.п. И вообще, сказал А, говори Б. Да мне MySQL с его лицензией побоку. Я с ним сталкиваюсь только на хостинге либо в приходящих резюме с перлами типа "Разрабатываю в свободное время программу бухучета типа 1с на Delphi+MySQL 3" :) Я просто сопоставил твою активность в форумах на эту тему и предложение запуска факто-мифов P.S. А вообще, конечно, MySQL напирает. Огромная армия "веб-мастеров" переквалифицируясь с написания гостевых книг на системы учета тянет за собой этот самый чудо-сервер, ибо других не знают. Ладно бы еще PostgreSQL... Хотя сведения о MySQL у меня застыли на 3-й версии. Может с 5-й он и правда так крут, каким пытается казаться?
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
> > А что такое background gc по-твоему ? > > По моему это когда фоновый поток периодически > проверяет все данные на предмет мусора. Не угадал > >>Можно предложит вариант с перерасчётом при commit, но отложенно > >>в мусорщике. > > > > > > Ты понимаешь причины застревания OIT ? А механизм его сдвига после > > застревания ? > > Блин, у меня дикий своппинг в мозгу - вспомнить всё :-0 Зачем тогда эта беседа ? > Застревает как я понимаю если сделат rollback. Не каждый rollback к этому приводит. > Чтобы сдивинуть > потом нужно в TIP пометить эту транзакцию как commited, но Не нужно > при условии что версии из rollback транзакции почищены. Тут правильно > Это всё в свою очередь возможно если нет работающих > snapshot транзакций запущенных _до_ старта rollback > транзакции. Вот какая хренотень. OIT не бывает выше OAT, так что это не в кассу > Получается что основная проблема - это сборка версий > старой rollback транзакции. Для этого надо пробегать > все таблицы базы... либо Вообщем я пока пас :-| Никаких либо - нужно читать всю БД, чем свип и занимается > >>При том что задача в целом аналогична сборке мусора. И требуются > >>примерно аналогичные решения. > > > > > > Я тупой и не вижу аналогий > > Ну вместе со свипом пересчитывать статистику. Статистика индекса - это значения всех ключей. Свип не читает все индексы. Он даже не читает все версии всех записей. Так что - аналогия только в фоновом выполнении. Но тогда можно сказать, что обновлять статистику можно по-аналогии с cache_writer > > Ибо статистика пока слабо пользуется оптимизатором. > > Достаточно чтобы похерить план :-) > Основная проблема - пустая база создаётся из скрипта и > бросается на произвол судьбы юзерам. Maitenance со встроенным в ОС планировщиком не судьба делать ? И никакого призвола со стороны юзеров :) -- Хорсун Влад PS Насчёт произвола юзеров из кода FB : /** * * g d s _ $ c r e a t e _ d a t a b a s e * ** * * Functional description * Create a nice, squeeky clean database, uncorrupted by user data. * **/ ... /** * * g d s _ $ a t t a c h _ d a t a b a s e * ** * * Functional description * Attach a moldy, grungy, old database * sullied by user data. * **/ :)))
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Прошу помочь вспомнить и упорядочить сравнительные характеристики Firebird, MySQL и PostgreSQL (современных версий). Без священных войн, без флеймов - просто аргументы, желательно по следующим а флейм-то развелся конкретный...
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Alexander! Alexander Goldun wrote: Я просто сопоставил твою активность в форумах на эту тему и предложение запуска факто-мифов а, это никак не связано. просто я считаю, что разработчик хоть чуточку должен разбираться в лицензиях используемого софта. Например, я в IBAnalyst хотел вставить тулбар. мне посоветовали ToolBar2000. А он оказался платным для коммерческого использования. Соответственно, от предложения пришлось отказаться :-) P.S. А вообще, конечно, MySQL напирает. Огромная армия "веб-мастеров" переквалифицируясь с написания гостевых книг на системы учета тянет за собой этот самый чудо-сервер, ибо других не знают. Ладно бы еще если на 3-ей версии, то ничего хорошего не получится. PostgreSQL... Хотя сведения о MySQL у меня застыли на 3-й версии. Может с 5-й он и правда так крут, каким пытается казаться? вряд-ли. надо будет забабахать свое сравнение? :-) -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
O6opoTeHb wrote: Прошу помочь вспомнить и упорядочить сравнительные характеристики Firebird, MySQL и PostgreSQL (современных версий). Без священных войн, без флеймов - просто аргументы, желательно по следующим а флейм-то развелся конкретный... Дык. Воинствующие ламеры подтянулись. Подожди, скоро нуллом начнут размахивать и крушить им всё направо и налево. -- Regards. Ded.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
священных войн, без флеймов - просто аргументы, желательно по следующим а флейм-то развелся конкретный... Дык. Воинствующие ламеры подтянулись. Подожди, скоро нуллом начнут размахивать и крушить им всё направо и налево. ОФФ: крушить... интересно... нада буит с воздушки попробовать винт битый расстрелять... антиресна жышь..:)
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun wrote: Хотя сведения о MySQL у меня застыли на 3-й версии. Может с 5-й он и правда так крут, каким пытается казаться? С точки зрения функциональности, 5-ка - это сильный шаг вперед. Хотя часть нововведений работает скорее "для галочки" - тормозно, глючно или с интересными ограничениями. А вот с точки зрения производительности ядра, все еще менее весело. 4-ка на большой нагрузке (разговор про движок InnoDB, базу размером много больше ОЗУ и отнюдь не read-only операции) работает неудовлетворительно, 5-ку сейчас на той же задаче пытаемся оценить параллельно с PG8 и FB2. Будут результаты - отпишусь. -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun писал(а): > > Вот скажите мне - через что работают с > > MSSQL из Delphi ? > > Через что хотят, через то и работают. ADO, BDE, ODBC и т.п. Но в целом > кажется гораздо меньше заморачиваются по "родным" компонентам "прямого" > доступа. Вот и я абсолютно о том же. Но у нас упорно - это типа у нас "нативе", а это у нас "как у вас". Первое у нас быстрее и все такое. Интересно - откуда конкретно такая уверенность? И это продолжается до сих пор. При этом на этом поле у нас есть (была?) реальная фора - здесь я во многом верю Котляревскому, но елки палки - несколько транзакций через ADO можно было делать еще в 2001 году, несколько открытых активных рекордсетов - по жизни. Нет, мы этого знать не хотим и не будем на это опираться. Что там у нас в MSSQL? MARS в 2005-ом?. Какая охная технология! И так далее и тому подобное. Коваленко Дмитрий.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry wrote: Вот и я абсолютно о том же. Но у нас упорно - это типа у нас "нативе", а это у нас "как у вас". Первое у нас быстрее и все такое. Интересно - откуда конкретно такая уверенность? И это продолжается до сих пор. Кто-то ограничивает чьи-то возможности? Тебя держат за руки и заставляют пользовать IBX? Хто? Скажи, я ему в глаз плюну. -- Regards. Ded.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: Застревает как я понимаю если сделат rollback. Не каждый rollback к этому приводит. Ну да, который не писал, тот переделывается в commit, но в IB6 этого не было вроде. Получается что основная проблема - это сборка версий старой rollback транзакции. Для этого надо пробегать все таблицы базы... либо Вообщем я пока пас :-| Никаких либо - нужно читать всю БД, чем свип и занимается Вот это больше всего и напрягает. Особенно в связи с тенденцией роста размеров баз. Варианты есть. Ну например хранить незакоммиченные версии во отдельном месте или даже в памяти. Как кстати savepoints работают? Основная проблема - пустая база создаётся из скрипта и бросается на произвол судьбы юзерам. Maitenance со встроенным в ОС планировщиком не судьба делать ? И никакого призвола со стороны юзеров :) Не катит для тиражируемого софта. Да и ось м.б. - 98 -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Ded писал(а): > > Вот и я абсолютно о том же. Но у нас > > упорно - это типа у нас "нативе", а это у > > нас "как у вас". Первое у нас быстрее и > > все такое. Интересно - откуда конкретно > > такая уверенность? И это продолжается > > до сих пор. > > Кто-то ограничивает чьи-то возможности? Тебя держат за руки и > заставляют пользовать IBX? Хто? Скажи, я ему в глаз плюну. Меня никто ни за что не держит. Но когда речь заходит о том что бы писать приложения совместимые с MSSQL и FB - я какого только бреда не видел. Даже не припомню, чтобы хотя бы посоветовали посмотреть в сторону ODBC - нет, давайте будем городить городульки над ADO и VCL-ными компонентами. Они же у нас нативные! Ты где нибуть видел, что бы IB/FB хоть кто-то попытался целенаправлено оторвать от связки с Delphi? Подсказать какие мысли возникают в связи с последним? Тут только и остается подумать - что слава тебе Билли, что появилась .NET на которой у сервера появилась хоть какая-та возможность жить своей жизнью, а не в качестве чьего-то довеска. Коваленко Дмитрий.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
"Alexey Popov" ... > > > > Horsun Vlad wrote: > > >>Застревает как я понимаю если сделат rollback. > > > > > > Не каждый rollback к этому приводит. > > Ну да, который не писал, тот переделывается в commit, но > в IB6 этого не было вроде. Опять мимо. Ты хоть что-нибудь читал по теме ? > > Никаких либо - нужно читать всю БД, чем свип и занимается > > Вот это больше всего и напрягает. Особенно в связи с тенденцией > роста размеров баз. > Варианты есть. Да, есть. К 3-ке они будут рассматриваться пристальнее > Ну например хранить незакоммиченные версии во отдельном > месте И шо ? > или даже в памяти. Думаем о восстановлении после краша, и отметаем этот вариант > Как кстати savepoints работают? Была статья и не одна. Например на ibase.ru и в ibdeveloper > > Maitenance со встроенным в ОС планировщиком не судьба делать ? > > И никакого призвола со стороны юзеров :) > > Не катит для тиражируемого софта. Да и ось м.б. - 98 Тиражируемый софт может : а) пользовать тот, который встроен даже в win98 б) ставить свой простейший планировщик -- Хорсун Влад PS мне начинает это надоедать...
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry wrote: Меня никто ни за что не держит. Но когда речь заходит о том что бы писать приложения совместимые с MSSQL и FB - я Имхо в приложениях, задача которых - быть совместимыми и с MSSQL и с FB, какие компоненты пользовать - ну просто последняя спица в колеснице. Концептуально сервера совершенно разные, их объединяет полтора десятка операторов с похожим синтаксисом. Тут сама логика реализации систем разная, а компоненты - дело десятое. Ты где нибуть видел, что бы IB/FB хоть кто-то попытался целенаправлено оторвать от связки с Delphi? Серёжа Мереуца, как мне кажется, про Дельфи вспоминает только всвязи с заходом в какую-нить конфу. На Ц люди ваяют, на жабе. На всяких там перлах-питонах и прочей гадости... -- Regards. Ded.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Evgeny Putilin писал(а): > > Ты где нибуть видел, что бы IB/FB хоть > > кто-то попытался целенаправлено > > оторвать от связки с Delphi? > Дим ты тут о чем? вообщето некоторые не первый год пользуются Java + FB вов > всех извращеных связях. Но почемуто Delphi+FB больше. Жень, у меня тоже толпа покупателей провайдера только ради использования в связке с MSSQL. Но эти маньяки - не показатель. Коваленко Дмитрий.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
"Ded" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > Серёжа Мереуца, как мне кажется, про Дельфи вспоминает только всвязи > с заходом в какую-нить конфу. На Ц люди ваяют, на жабе. На всяких там > перлах-питонах и прочей гадости... Ребята, я тут чего тему как-то потерял. МЫ ТУТ ВООБЩЕ ЧЕГО ОБСУЖДАЕМ? "Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты" - собственно по предмету будут высказывания или будем философией заниматься?!
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry пишет: Ты где нибуть видел, что бы IB/FB хоть кто-то попытался целенаправлено оторвать от связки с Delphi? Мы утилиты обслуживания/репликации своей системы на Python-е лабаем. ;-)
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, Alexey! Alexey Popov wrote: Ну да, который не писал, тот переделывается в commit, но в IB6 этого не было вроде. мда. это БЫЛО изначально. Варианты есть. Ну например хранить незакоммиченные версии во отдельном месте или даже в памяти. и при чем тут sweep? Алекс, разговор с тобой очень сильно похож на диалог - кастрюлю на огонь поставил? - там провод оторвался - какой провод? то есть что ни возьми - ну практически все не в кассу. Как кстати savepoints работают? прочитай: www.ibase.ru/devinfo/savepoints.htm еще см. какой-то номер ibdeveloper.com Maitenance со встроенным в ОС планировщиком не судьба делать ? И никакого призвола со стороны юзеров :) Не катит для тиражируемого софта. Да и ось м.б. - 98 почему же не катит? У Ораклов и Микрософтов катит, а тебе - не катит? -- Dmitri Kouzmenko, www.ibase.ru, (495) 953-13-34
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Oleg LOA wrote: Ребята, я тут чего тему как-то потерял. МЫ ТУТ ВООБЩЕ ЧЕГО ОБСУЖДАЕМ? "Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты" - собственно по предмету будут высказывания или будем философией заниматься?! Дык этта. Димка, если я правильно его понял, в число слабых мест FB по сравнению с обычными серверами ;) включил то, что с ним подавляющее большинство работают через нативные компоненты и с помощью Дельфей. А я ему говорю - да и хрен с ним, каждый дрочить как он хочить (С). Наличие нативных компонент не является слабиной, поскольку через ненативные тоже никто не запрещает. Не вижу тут слабого места. Так что упрёк не принимаю, отвечал в контексте предмета обсуждения. А ход мыслей нашего объектно ориентированного собрата ;) мне тоже не совсем в данном случае ясен. И во многих других случаях тоже, но это уже моё личное горе, которое обсуждать и вправду не имеет смысла :-D -- Regards. Ded.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry пишет: Через что хотят, через то и работают. ADO, BDE, ODBC и т.п. Но в целом кажется гораздо меньше заморачиваются по "родным" компонентам "прямого" доступа. Вот и я абсолютно о том же. Но у нас упорно - это типа у нас "нативе", а это у нас "как у вас". Первое у нас быстрее и все такое. Интересно - откуда конкретно такая уверенность? И это продолжается до сих пор. Есть такое. Дед, конечно, прав, кто как хочет, так и... Но вот свежайший пример навскидку: http://sql.ru/forum/actualthread.aspx?tid=340299#3159886 Все советуют native. Все рассказывают про какие-то лишние тормоза, как будто дополнительные микросекунды на вызов могут сказаться при разработке массовых бизнес-приложений. Но напомни, плиз, если я скачаю дистрибутив FB, там в комплекте будут ODBC и OLE DB драйверы? Судя по http://ibase.ru/components.htm - нет, не будут. Вижу там 5 разных драйверов ODBC, 3 штуки OLE DB. А оно надо - так много? Заморачиваться, выбирать, пробовать. "Ах, еще и платить надо?" У PG8 в этом плане проще и понятнее. ODBC драйвер в дистрибутиве есть. OLEDB есть. Хоть про второй инсталлятор и предупреждает честно, что он еще сырой, но тем не менее он есть и понятна политика: он, очевидно, будет и в дальнейшем. И не надо ничего искать и выбирать. А такое разнообразие одних только ODBC драйверов наводит на мысль, что это не от хорошей жизни. Чисто интуитивно напрашивается мысль: пишут все кому не лень, потому что не устроило то, что нашли. А были бы эти драйвера в комплекте, многие и не заморачивались бы больше ничем. А про Delphi мысль непонятна. Что значит оторвать? Оторвать то, может, и легко, только не забывай, что FB своей популярностью в основном обязан именно Delphi. По крайней мере в России.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
"Vladimir A.Bakhvaloff" ... > Одна надежда: может всё-таки объясните в итоге разговора... ;) Собственно только поэтому я и поддерживаю эту "беседу" -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun писал(а): > Kovalenko Dmitry пишет: > >> Через что хотят, через то и работают. ADO, BDE, ODBC и т.п. Но в целом > >> кажется гораздо меньше заморачиваются по "родным" компонентам "прямого" > >> доступа. > > > Все советуют native > > А такое > разнообразие одних только ODBC драйверов наводит на мысль, что это не от > хорошей жизни. Чисто интуитивно напрашивается мысль: пишут все кому не > лень, потому что не устроило то, что нашли. А были бы эти драйвера в > комплекте, многие и не заморачивались бы больше ничем. Да хрен с ним, с разнообразием. Оно вообщем-то уже устаканившееся. Нужно расставить приоритеты (У Кузьменко, слава богу, с этим все нормально). А еще желательно указавать дату, когда продукт последний раз обновлялся - с OLEDB тут вообще все просто ZStyle в начале 2004, SIBProvider - в середине 2003. Вартона вообще выкинуть из списка. Я уважаю его IBO, но я так ни разу и не увидел этот его OLEDB-провайдер в живую. Насчет поставки компонент в составе сервера. Я помню эта тема мусировалась в контексте Yaffil. Дальше дело не пошло. Может мы были жадными, может это просто ... никому не надо было - это уже не важно. Есть мысли по этой теме ? - давайте обсудим 14 октября. Хотя обсждать, конечно, нужно еще и с "владельцами" самого FB. > А про Delphi мысль непонятна. Что значит оторвать? Оторвать то, может, и > легко, только не забывай, что FB своей популярностью в основном обязан > именно Delphi. По крайней мере в России. Я знаю о ней и ценю её. Но тут в этой ветке уже говорилось о вполне реальных ассоциациях которую эта популярность вызывает. Поэтому, думаю, даже те, кто юзает FB для серьезных проектов, и не используют Delphi, как-то не очень афишируют это. Хотя чего казалось бы - видишь в сети урода, который поливает FB - ну потрать пять минут, ответь чудаку. Скорее всего я все утрирую. Можете меня, за это, бросить в терновый куст :))) Все, завязываю. Прошу прощения, если кого-то сильно задел. Коваленко Дмитрий.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
"Kovalenko Dmitry" <[EMAIL PROTECTED]> wrote in message news:[EMAIL PROTECTED] > > сервера. Я помню эта тема мусировалась > в контексте Yaffil. Дальше дело не пошло. На фирменных дисках дятла есть Gemini ODBC ;-)
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: Не каждый rollback к этому приводит. Ну да, который не писал, тот переделывается в commit, но в IB6 этого не было вроде. Опять мимо. Ты хоть что-нибудь читал по теме ? Ещё попытка - вроде бы по дефлоту версии сперва в памяти хранятся а не пишутся на диск? Вот это больше всего и напрягает. Особенно в связи с тенденцией роста размеров баз. Варианты есть. Да, есть. К 3-ке они будут рассматриваться пристальнее Вот это особо мне интересно. Какие есть варианты чтобы отказаться от свипа? Ну например хранить незакоммиченные версии во отдельном месте И шо ? Во время коммита сносить их в физичекий файл. Правда тут проблема устойчивости этой операции. Т.е. в файл пишем только последнюю закоммиченную версии, а все остальные версии храним в памяти или во временных файлах. Кстати, вроде бы примерно так оракл работает? Как кстати savepoints работают? Была статья и не одна. Например на ibase.ru и в ibdeveloper Я както сорцы на эту тему читал. Версии складируют в память. Откат сэйвпойта не создаёт версий. Тиражируемый софт может : а) пользовать тот, который встроен даже в win98 б) ставить свой простейший планировщик Нах эти извраты с планировщиками. Проще забить. -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Kovalenko Dmitry пишет: Ты где нибуть видел, что бы IB/FB хоть кто-то попытался целенаправлено оторвать от связки с Delphi? Иногда пытаются, правда, сомневаюсь, что целенаправленно. Тому в подтверждение, что различные CMS вовсю включают FB в списки поддерживаемых серверов. Сам я мечтаю перенести сайт организации на динамическую основу, но совершенно не хочу устанавливать и разбираться MySQL, который, и порой только который, поддерживает подавляющее их большинство, ибо FB есть. А зоопарк на сервере разводить не желаю пока не возникнет в этом необходимости (я не хостер, а потому нефиг). По теме, к сожалению, ничего сказать не смогу, т.к. мне не приходилось никогда работать ни с чем кроме Interbase/FB (не тыкать в меня пальцами!) А по сему сравнивать на основании личного опыта не имею возможности. -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
> >>>Не каждый rollback к этому приводит. > >> > >>Ну да, который не писал, тот переделывается в commit, но > >>в IB6 этого не было вроде. > > > Опять мимо. Ты хоть что-нибудь читал по теме ? > > Ещё попытка - вроде бы по дефлоту версии сперва в памяти хранятся > а не пишутся на диск? Нет > >> Вот это больше всего и напрягает. Особенно в связи с тенденцией > >>роста размеров баз. > >> Варианты есть. > > > > Да, есть. К 3-ке они будут рассматриваться пристальнее > > Вот это особо мне интересно. Какие есть варианты чтобы отказаться > от свипа? Не отказаться, а сделать его ещё быстрее > >> Ну например хранить незакоммиченные версии во отдельном > >>месте > > > > > > И шо ? > > Во время коммита сносить их в физичекий файл. Правда тут проблема > устойчивости этой операции. Т.е. в файл пишем только последнюю > закоммиченную версии, а все остальные версии храним в памяти или > во временных файлах. Ты о тр-циях слыхивал ? А о том, что их может быть более 1-ой одновременно ? А о том, что каждой из них нужно видеть своё состояние БД ? А о отдельных процессах классика в курсе ? Которые не видят память друг-друга > Кстати, вроде бы примерно так оракл работает? Не знаю, но уверен что не так > >>Как кстати savepoints работают? > > > > Была статья и не одна. Например на ibase.ru и в ibdeveloper > > Я както сорцы на эту тему читал. Версии складируют в память. Откат > сэйвпойта не создаёт версий. Не дочитал ты. Чти ibdeveloper, я там писал > > Тиражируемый софт может : > > а) пользовать тот, который встроен даже в win98 > > б) ставить свой простейший планировщик > > Нах эти извраты с планировщиками. Проще забить. Тогда об чём вопрос был ? -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: Во время коммита сносить их в физичекий файл. Правда тут проблема устойчивости этой операции. Т.е. в файл пишем только последнюю закоммиченную версии, а все остальные версии храним в памяти или во временных файлах. Ты о тр-циях слыхивал ? А о том, что их может быть более 1-ой одновременно ? А о том, что каждой из них нужно видеть своё состояние БД ? А о отдельных процессах классика в курсе ? Которые не видят память друг-друга Так вычисление версии записи для данной транзакции останется таким же. Разница только в том что одна версия (самая актуальная) в файле, а все остальные в памяти. При сносе сервера остаются только версии из файла. Основная проблема тут обеспечить надёжность коммита и не зависнуть при массовых обновлениях. Классик - в печку. Но и для него можно также версии хранить во временном файле доступному всем процессам. -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexey Popov пишет: Классик - в печку. Знак восклицания не стоит осмысленно или пропущен по недогляду? Понимаю (читай "надеюсь"), что в пылу сие произнесено, но все же... гм... Меня бы задело. -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
"Alexey Popov" ... > > > > Horsun Vlad wrote: > > >>Во время коммита сносить их в физичекий файл. Правда тут проблема > >>устойчивости этой операции. Т.е. в файл пишем только последнюю > >>закоммиченную версии, а все остальные версии храним в памяти или > >>во временных файлах. > > > > > > Ты о тр-циях слыхивал ? А о том, что их может быть более 1-ой > > одновременно ? А о том, что каждой из них нужно видеть своё состояние БД ? > > А о отдельных процессах классика в курсе ? Которые не видят память друг-друга > > Так вычисление версии записи для данной транзакции останется таким же. > Разница только в том что одна версия (самая актуальная) в файле, а все > остальные в памяти. Для кого актуальная ? > При сносе сервера остаются только версии из файла. > Основная проблема тут обеспечить надёжность коммита и не зависнуть > при массовых обновлениях. > Классик - в печку. Но и для него можно также версии хранить во временном > файле доступному всем процессам. Чем вр.файл отличается от основного ? -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: Так вычисление версии записи для данной транзакции останется таким же. Разница только в том что одна версия (самая актуальная) в файле, а все остальные в памяти. Для кого актуальная ? Самая последняя закоммиченная. Т.е. так которая должна быть в базе при сносе сервера. При этом не хранить указатели на предыдущие версии. Классик - в печку. Но и для него можно также версии хранить во временном файле доступному всем процессам. Чем вр.файл отличается от основного ? Тем что версии не разманы по всему файлу бд. И могут чистится по коммитам без свипа. -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
> >> Так вычисление версии записи для данной транзакции останется таким же. > >>Разница только в том что одна версия (самая актуальная) в файле, а все > >>остальные в памяти. > > > > > > Для кого актуальная ? > > Самая последняя закоммиченная. Т.е. так которая должна быть в базе > при сносе сервера. При этом не хранить указатели на предыдущие > версии. Не, так не пойдёт. Распиши что и как сохранять на примере с 3-мя тр-циями, каждой из которых видна своя версия > >> Классик - в печку. Но и для него можно также версии хранить во временном > >>файле доступному всем процессам. > > > > > > Чем вр.файл отличается от основного ? > > Тем что версии не разманы по всему файлу бд. И могут чистится > по коммитам без свипа. А с какой стати они не будут размазаны по вр.файлу ? Или для каждой тр-ции и каждой таблицы - свой файл ? Сборка мусора удаляет не только старые версии записей, она также удаляет ненужные блобы и ключи индексов -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Всем привет! К сожалению, тема вышла за пределы взвешенного разговора и перешла к самопоyтованию и выпячиванию своих комплексов. Давайте будем обсуждать идеи в соответтсвующих темах - создавайте и обсуждайте. Да, есть много верных замечаний - ну давайте над ними и работать. Для начала я бы предложил всем участникам и "хотетелям" сброситься по бутылочке хорошего пива в фонд Firebird - по 50 рублей сюда http://www.ibase.ru/fbfunds.htm Еще чуток и мы сможем нанять хорошего дизайнера (не Лебедева, но и не "коленочника", не отличающего table от css ) и сделать промосайт для Firebird. Вот это реальное дело, которое повысит визибилити Firebird и будет положительно влиять на увеличение рынка труда и оценку умений связанных с разработкой Firebird-based application. Вот небось сидите, откупорили Крушовице и киваете, вместо того чтобы Firebird помочь. С уважением, Алексей Ковязин
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexey Kovyazin wrote: К сожалению, тема вышла за пределы взвешенного разговора и перешла к самопоyтованию и выпячиванию своих комплексов. А можно я тоже немножко свои комплексы повыпячиваю и поофтоплю? Не, ну я немножко совсем и у меня уавжытельные причины: уже почти пятница, я слегка бухой и мало-мало расстроеный. Можно, да? Спасибо. Итак к вопросу о медленном backup/restore на FB: Сегодня решил попробовать проапгрейдить базу постгрес, перенеся ее со старого и дряхлого Pg 7.4 на 8.0, дабы уйти наконец от старого ба... то есть фичи этого сервера, напрочь отказывавшегося использовать индекс при объединении таблиц по полям разных типов. Для чего перво-наперво решил сделать этот самый бэкап. Запустил, как умный, pg_dump на машине и стал заниматься своими делами, периодически поглядывая "а не завершилось ли". И не то чтоб во мне вообще ничего не шевельнулось на тему "а хватит ли места", нет, мысль такая конешно возникала, но я, гадкий ламер, изнеженый файрбердом, как-то привык, что бэкап базы занимает места по крайней мере не больше самой базы - поэтому по дури своей решил, что уж в > 15G скрипт-то влезть обязан. Поэтому gzipать его на лету не стал, понадеявшись на здравый смысл. Ха!!! Реальная жизнь - лучшее лекарство от излишнего оптимизма: свободное место на винте все-таки закончилось раньше, чем завершился pg_dump. Сильно удивленный таким к себе неуважением, он сказал что-то типа "не получилось записать в файл: 5!=7" и обиженно прекратился, оставив меня с обгрызком бэкапа и нулем свободных байт в /home/mike. Ну да ладно, речь-то собственно не об этом, это так, лирика и мое криворучье. Речь о том, что с момента начала бэкапа до момента его облома прошло примерно часа четыре-пять. А потом еще столько же - на бэкап с загзипливанием "на лету". Сколько займет накатывание данных из погзипленного файла на "новый" сервер - пока неизвестно, сей эксперимент еще пока только в самом начале пути и результаты его будут анализироваться утром. Но одно лично мне ясно - пусть порвут меня на лоскутки коллеги-постргескюлисты, но слово "быстро" по отношению к этому процессу имхо даже _рядом не лежало_.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Fynda wrote: > я слегка бухой и мало-мало расстроеный Надо было в баню идти :-) слово "быстро" по отношению к этому процессу имхо даже _рядом не лежало_ Ты рассмотрел логический бекап, он у PGSQL и MySQL действительно тормозной. Но у них есть и "более другие" способы. Например, у PG: http://www.postgresql.org/docs/8.1/interactive/backup-online.html -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexey Kovyazin wrote: > Давайте будем обсуждать идеи в > соответтсвующих темах - создавайте и > обсуждайте. > по 50 рублей сюда > и сделать промосайт для Firebird. Мне кажется, что полтинник, как и промосайт, делу не поможет. The Bat - почти на каждом компе, MS Exchange - не у всех. Функциональность разная, суть же почти одинакова. Так вот, создание программы, которая объеденит функции вышеназванных и будет использовать FB в качестве хранилища, вытащит FB на новый уровень.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
"Dmitry Yemanov" ... > > Fynda wrote: > > > > я слегка бухой и мало-мало расстроеный > > Надо было в баню идти :-) > > > слово "быстро" по отношению к этому процессу имхо даже _рядом не лежало_ > > Ты рассмотрел логический бекап, он у PGSQL и MySQL действительно > тормозной. Но у них есть и "более другие" способы. Например, у PG: > http://www.postgresql.org/docs/8.1/interactive/backup-online.html Мигрировать с 7.4 на 8.1 он позволяет ? -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: Мигрировать с 7.4 на 8.1 он позволяет ? Это несколько другая задача, ее AFAIK ни одна СУБД не решает "быстрым" бекапом, про который шла речь выше. -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitry Yemanov wrote: > я слегка бухой и мало-мало расстроеный Надо было в баню идти :-) Мну не мог, по причинным объективам. слово "быстро" по отношению к этому процессу имхо даже _рядом не лежало_ Ты рассмотрел логический бекап, он у PGSQL и MySQL действительно тормозной. Но у них есть и "более другие" способы. Например, у PG: http://www.postgresql.org/docs/8.1/interactive/backup-online.html Это я видел (хотя до сих пор не использую - каюсь), но боюсь что при переходе с одной мажорной версии на другую такое не прокатит - формат-то у базы наверняка поменялся за это время. Так что приходится скриптами на всякий случай, через вот такие тормоза и грабли :( . PS. Кстати, раз уж пошла такая пьянка - а создание redo-лога в каком-либо виде в fb вообще планируется?
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad wrote: Самая последняя закоммиченная. Т.е. так которая должна быть в базе при сносе сервера. При этом не хранить указатели на предыдущие версии. Не, так не пойдёт. Распиши что и как сохранять на примере с 3-мя тр-циями, каждой из которых видна своя версия Стартует первая транзакция и обновляет запись. Версия пишется в память. Стартует вторая транзакция делает селект. Как обычно. Первая транзакция коммитится. При этом запись из файла переносится в память, а из памяти пишется на диск. и т.д. Чем вр.файл отличается от основного ? Тем что версии не разманы по всему файлу бд. И могут чистится по коммитам без свипа. А с какой стати они не будут размазаны по вр.файлу ? Или для каждой тр-ции и каждой таблицы - свой файл ? Количество версии обычно должно быть намного меньше чем обычных записей в БД. Поэтому для аналоги свипа достаточно будет обработать этот временный файл небольших размеров. Сборка мусора удаляет не только старые версии записей, она также удаляет ненужные блобы и ключи индексов С индексами конечно есть проблема. Сейчас версии тоже вставляются в индекс. Если их не вставлять то надо как решить проблему выборки незакоммиченных версий. -- --- Home Page http://ok.novgorod.net/ap ---
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
> Стартует первая транзакция и обновляет запись. Версия пишется в память. > Стартует вторая транзакция делает селект. Как обычно. А если она делает апдейт ? А если она в другом процессе классика ? > Первая транзакция коммитится. При этом запись из файла переносится > в память, а из памяти пишется на диск. > и т.д. Какого файла ? Выше ничего про это нет > Количество версии обычно должно быть намного меньше чем обычных > записей в БД. Откуда такое предположение ? > Поэтому для аналоги свипа достаточно будет обработать > этот временный файл небольших размеров. Нет, ибо см. ниже > > Сборка мусора удаляет не только старые > > версии записей, она также удаляет ненужные блобы и ключи индексов > > С индексами конечно есть проблема. Сейчас версии тоже вставляются в индекс. > Если их не вставлять то надо как решить проблему выборки незакоммиченных > версий. Вот реши для начала, и потом поговорим :) -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Eugene пишет: Классик - в печку. Руки прочь от классика! Классик должен вымереть - это тупиковая ветвь эволюции. SS надо до ума доводить. Сам ты тупиковая ветвь. Чего наехали на человека? Назовите навскидку еще несколько серверов БД, у которых кэш между коннектами не шарится. Если у SS будет нормальное распараллеливание, то классик скорее всего вымрет.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
"Alexander Goldun" ... > > Eugene пишет: > > Классик - в печку. > >>> Руки прочь от классика! > >> Классик должен вымереть - это тупиковая ветвь эволюции. SS надо > >> до ума доводить. > > > > Сам ты тупиковая ветвь. > > Чего наехали на человека? Он первый начал :) > Назовите навскидку еще несколько серверов БД, > у которых кэш между коннектами не шарится. Причём тут кеш к архитектуре ? Ну будет он шариться и шо ? Ты сразу полюбишь классик ? Так он и так шарится - через кеш FS :))) > Если у SS будет нормальное > распараллеливание, то классик скорее всего вымрет. Не вымрет. Хотя бы потому, что это полуготовое кластерное решение -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun wrote: Чего наехали на человека? Назовите навскидку еще несколько серверов БД, у которых кэш между коннектами не шарится. Если у SS будет нормальное распараллеливание, то классик скорее всего вымрет. Надеюсь, я таки вымру раньше. У классика, окромя распараллеливания, есть ещё одно интересное свойство - умирать в случае чего скромненько, не утягивая за собой остатние полторы сотни коннектов. И никакое увеличение борзодействия меня лично не заставит забыть об этой маленькой радости. А также он имеет реальные перспективы для работы в кластерах. После соответсвующей доводки напильником. Такшта кто там тупик и кто быстрее вымрет на фоне бурного развития возможностей железа параллельно с развитием тормознутости осей и сложности задач, это мы ещё будем посмотреть. -- Regards. Ded.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun wrote: у которых кэш между коннектами не шарится Кролики - это не только ценный мех (с) А независимый кеш - отнюдь не обязательный атрибут классика, в общем случае. Из преимуществ классика можно назвать лучшую защиту от сбоев и потенциальную кластеризуемость. -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun пишет: Eugene пишет: Классик - в печку. Руки прочь от классика! Классик должен вымереть - это тупиковая ветвь эволюции. SS надо до ума доводить. Сам ты тупиковая ветвь. Чего наехали на человека? Назовите навскидку еще несколько серверов БД, у которых кэш между коннектами не шарится. Если у SS будет нормальное распараллеливание, то классик скорее всего вымрет. А с точки зрения сетевой безопасности порождающиеся под чутким надзором xinetd экземпляры классика мне наиболее симпатичны, чем постоянно существующий в одном экземпляре суперсервер. -- Regards, Ovchinnikov Vasily ova at tkvc ru
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
DY> Кролики - это не только ценный мех (с) А независимый кеш - отнюдь не DY> обязательный атрибут классика, в общем случае. Из преимуществ классика DY> можно назвать лучшую защиту от сбоев и потенциальную кластеризуемость. хм, в сегодняшнем варианте все-таки на первое место надо вынести возможность использования нескольких процессоров. А не одного как SS. А кэш да, заменяется увеличением оперативки, а защита от сбоев... Так не сбоит он ;). А если что, то сам он и поднимется. -- С уважением Кочмин Александр
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Horsun Vlad пишет: Назовите навскидку еще несколько серверов БД, у которых кэш между коннектами не шарится. Причём тут кеш к архитектуре ? Может и ни при чем. Но такая вот особенность в FB CS имеется. Ну будет он шариться и шо ? Ты сразу полюбишь классик ? Не сразу, а медленно и постепенно :) Так он и так шарится - через кеш FS :))) А мог бы шариться еще эффективнее и умнее. Со всякими там новомодными методиками вытеснения страниц, с опцией cache warming для особых эстетов и т.п. Кстати, если рассматривать потенциальную возможность того, что в FB будет шифрование, то в таком варианте кэш FS ну никак не поможет. Если у SS будет нормальное распараллеливание, то классик скорее всего вымрет. Не вымрет. Хотя бы потому, что это полуготовое кластерное решение Ну, в общем-то с таким вариантом и с доводом надежности не поспоришь. Да собственно против архитектуры я ничего не имею. Я имел в виду именно сочетание распараллеливания и общего кэша.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Alexander Goldun wrote: всякими там новомодными методиками вытеснения страниц Которые постгрес который год тасует в попытках убежать от патентного права :-) -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Dmitry Yemanov пишет: всякими там новомодными методиками вытеснения страниц Которые постгрес который год тасует в попытках убежать от патентного права :-) Тяжелый случай. Способ потребления кислорода человеком под названием "дыхание" случайно никто еще не запатентовал? Надо бы подсуетиться...
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
"Alexander Goldun" ... > > Horsun Vlad пишет: > > >> Назовите навскидку еще несколько серверов БД, > >> у которых кэш между коннектами не шарится. > > > > Причём тут кеш к архитектуре ? > > Может и ни при чем. Но такая вот особенность в FB CS имеется. Дык - мало ли у него ещё особенностей. Но выбрал ты именно эту :) > > Ну будет он шариться и шо ? Ты сразу полюбишь классик ? > > Не сразу, а медленно и постепенно :) Ага, так и запишем ;) > > Так он и так шарится - через кеш FS :))) > > А мог бы шариться еще эффективнее и умнее. Эффективнее - между разными процессами, по сравнению с центральным управлением ? Не факт - накладные расходы на межпроцессную синхронизацию могут съесть все остальные полученные выгоды > Со всякими там новомодными методиками вытеснения страниц, Ты плохо думаешь о современных FS :) > с опцией cache warming для особых эстетов и т.п. Эстеты пока отдыхают :) > Кстати, если рассматривать потенциальную возможность того, что в > FB будет шифрование, то в таком варианте кэш FS ну никак не поможет. Это зависит от накладных расходов на шифрование. Которое, между прочим, опционально. Я не большой любитель классика, да и гемору он нам конечно прибавляет, но у него есть достаточное кол-во плюсов чтобы его не выкидывать -- Хорсун Влад
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Eugene wrote: > "Alexey Popov" <[EMAIL PROTECTED]> wrote in > message news:[EMAIL PROTECTED] > > > Классик - в печку. > > Руки прочь от классика! Вот что говорит по этому поводу Jim Starkey http://www.firebirdnews.org/?p=715. Он говорит, что если все останется как есть, то капец FB, и что его типа задавят
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
freemanzav wrote: > Вот что говорит по этому поводу Jim Starkey Не читайте на ночь советских газет (с) Он говорит, что если все останется как есть, то капец FB, и что его типа задавят Уход от "останется как есть" не есть "смерть классику", даже в его интерпретации. -- Дмитрий Еманов
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hi "Alexey Kovyazin" > реализации серверной логики (языки, хп, > инструменты разработчика) Лично ткнувшись носом, вараинтк ак в тригере прерать выполнения запроса, в котором он исполнаяется http://forums.mysql.com/read.php?99,43881,94952#msg-94952 И тутже http://forums.mysql.com/read.php?99,99214,99300#msg-99300 Т.е. мелочей коотрые могут подпортить жизнь много :-) WBR Evgeny Putilin.
Re: Сравнение Firebird, MysQL и PostgreSQL - аргументы и факты
Hello, freemanzav! You wrote on Mon, 02 Oct 2006 22:24:21 -0700: f> Вот что говорит по этому поводу Jim Starkey f> http://www.firebirdnews.org/?p=715. Это ведь не сегодня (и не вчера) сделанное открытие. И выводы сделаны не совсем в тему. Удач -- Alexander A. Venikov, Tobolsk, Russia Real e-mail address is venixtntobru
