PostgreSQL 8.0

> СУБД с Дельфинчиком задрав штаны бегут реализовывать всякие хранимые процедуры

А ты не знаешь? Клиенты стоят в очереди и платят бабло за реализацию
этих фич. Но тут мы наталкиваемся на новый вопрос: а зачем??? Ведь есть
столько прекрасных субд, типа PostgreSQL 8.0, в которых всё это уже
давно есть! И вот здесь мы и вернёмся к поднятому уже вопросу: какую
жертву производительности вы готовы принести за право иметь все фичи
больших субд? Клиенты, оплачивающие разработку mysql не готовы к той
жертве, которую им предлагает команда постгрес, Они верят, что
полнофункциональные субд могут и должны показывать лучшую
производительность.

> А ты не знаешь? Клиенты стоят в очереди и платят бабло за реализацию этих фич. Но тут мы наталкиваемся на новый вопрос: а зачем??? Ведь есть столько прекрасных субд, типа PostgreSQL 8.0, в которых всё это уже давно есть!

Переезд с одной СУБД на другую сравним с стихийным бедствием. Не каждый готов на это пойти.

> И вот здесь мы и вернёмся к поднятому уже вопросу: какую жертву производительности вы готовы принести за право иметь все фичи больших субд?

О, давай вернёмся. Итак, было два неотвеченных вопроса:

1) какой смысл давать ссылки на результаты теста, выполненного криворуким автором (который свою криворукость в списке рассылки даже и признал)?

2) где есть независимые бенчмарки с участием PostgreSQL и InnoDB движка MySQL?

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

Угу, типа команда MySQL сначала утверждала, что они не реализовывают фичи, т.к. они тормозят процесс (из старого мануала мыскля --- reasons not to use foreign key constraints: http://webdocs.math.univ-rennes1.fr/MySQL/mysql-3.23.52/manual_Broken_Foreign... )

А потом, когда над ними стали уже очень открыто смеяться, они сделали вид, что открыли Философский Камень: смогли реализовать Фичи, не пожертвовав Скоростью.

Вопрос: когда они врали --- раньше или теперь?

> Вопрос: когда они врали --- раньше или теперь?

Они абсолютно честны. Долгие годы, в то время как остальные добавляли
тонны сомнительного качества фич, команда mysql оттачивала свою субд
на предмет безукоризненного исполнения её основных обязанностей:
хранения и отдачи данных. И они достигли в этом почти совершенства.
Если с такой же тщательностью, и так же виртуозно они реализуют
оставшиеся "фантики",,, они в итоге станут лидерами на рынке, который
очень вяло пытается штурмовать постгрес. На мой взгляд, допустимое
падение производительности для субд класса постгресс относительно
mysql - 50-70% (а не 10-40 раз). И команда mysql покажет, что это возможно.

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

А что касается бенчмарков, то их в принципе проделывают исключительно
только лохи ;) Ты не знал? Человек чего-то не знает, и решается провести
эксперемент с замерами производительности. Или вариант 2: человек знает,
что его система хуже, но хочет подать её в лучшем свете (а ля Микрософт).
Так что, увы, при всём желании... ;)

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

> Типа, ура? Постгрес почти дотянул по фичам до 7-го оракла 7-летней давности? Тока 7-й оракл просто летает на 7-летнем железе.

к стати резонно - что если не мытьем, так катанием какая то компания разработчиков (GPL или не GPL, не важно) реализует 1:1 функциональность какой то версии Оракла или другой конкретной базы - то это совсем автоматически не будет означать, что их база будет настолько же эффективной, функционал - это одно, а реалии - другое .. сложность современных СУБД сравнима со сложностью современных самолетов, только летают они по-разному ..

>Если с такой же тщательностью, и так же виртуозно они реализуют оставшиеся "фантики",,, они в итоге станут лидерами на рынке, который очень вяло пытается штурмовать постгрес. На мой взгляд, допустимое падение производительности для субд класса постгресс относительно mysql - 50-70% (а не 10-40 раз). И команда mysql покажет, что это возможно.

Ну а сейчас я ждал PG8 из-за небольших прилаг - если писать людям автоматизацию пары бухгалтеров и пары кадровиков, то не обязательно они будут держать СУБД на Линуксе. А вообще-то, мне подход MySQL кажется лучшим (ведь он интенсивный). А Постгрес не сосет - он работает там, где другие ломаются :) (в основном, из-за денег)

А проповедники mysql пробовали postgresql на рельных соответствующих задачах ? А то тесты разные бывают:
http://benchw.sourceforge.net/benchw_results_open3.html
И вобщем не забывайте еще есть скорость разработки и обычно она дороже железа.

В догонку:

Почему MySQL AB изменил лицензию на клиентскую библиотеку MySQL с LGPL на GPL?

...

LGPL лицензия для MySQL клиента облегчала возможность для организаций распространять коммерческое программное обеспечение, не способствуя FLOSS сообществу и не выплачивая деньги MySQL AB, для дальнейшего финансирования развития продукта. Короче говоря - они не участвовали в справедливом обмене.

http://www.cyberdot.ru/articles/top_7_mysql_licensing_questions.html

ИМХО, Вобщем перспективы у MySQL AB с ее двойной лицензией и политикой не очень. А темпы развития postgresql в последнее время очень радуют, и это в том числе заслуга "прагматичной" BSDL.

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

... и не верят в то, что в некоторых случаях необходимо писать запросы вида "select * from a, (select * from b group by xxx) c where a.id=c.id" :-)

1. MySQL и Postrges изначально ориентированы на разные задачи в тех рамках, что решаются в СУБД.

2. Тот, кто хорошо знает Оракл, едва ли будет "осваивать" какую либо другую базу.

3. Применение только Оракла не всегда оправдано, именно поэтому существуют такие системы, как My и Post.

4. Пример абсолютной монополизации -- Micros~1. Показательно, что их реализация SQL-базы пока в обсуждении не участвовала :)

5. Итог: базы разные нужны, а вот специалисты в _своей_ области нужны _хорошие_ и лучше :) Тогда и систем для прикладников будет больше и работать в них приятней будет. Не этого ли всем нам нужно?

:)

PS От себя: Вроде летом сообщалось, что управление в Постгресс сменилось. Они ессно взяли курс на четкий план развития проекта. И придерживаются пока этого плана, что пользователям этой базы идет только на пользу. А вот на сколько этот курс стратегически точен, только время и практика использования покажет. А для учета этих вводных факторов есть обратная связь с разработчиками. Вот теперь все :)

> ачем бенчмарки ? все и так знают круче mysql простеньких запросах без транзакций никого нет

sqlite?

> Типа, ура? Постгрес почти дотянул по фичам до 7-го оракла 7-летней давности?

Типа, ура! Мысклеписателям-то, по самым оптимистичным оценкам, ещё 7 лет тянуть! ;

>... и не верят в то, что в некоторых случаях необходимо писать >запросы вида "select * from a, (select * from b group by xxx) c >where a.id=c.id" :-)

Для отсталых от жизни, сообщаю: такие запросы появились в MySQL 4.1.0
А на дворе уже 4.1.9 стабильная версия.

> Они абсолютно честны. Долгие годы, в то время как остальные добавляли тонны сомнительного качества фич, команда mysql оттачивала свою субд на предмет безукоризненного исполнения её основных обязанностей: хранения и отдачи данных.

Так и запишем: врали они раньше, когда утверждали, что фичи *обязательно* приведут к резкому падению производительности. А сейчас более-менее научились программировать и прочитали пару-другую книжек по теории реляционных СУБД и чего-то там сляпали.

> На мой взгляд, допустимое падение производительности для субд класса постгресс относительно mysql - 50-70% (а не 10-40 раз).

Не говоря уже о том, что пока программисты MySQL учились программировать, на рынке появилась замечательная СУБД SQLite, которая делает MySQL в их нише по всем параметрам:

1) Удобнее в администрировании

2) Значительно *быстрее*: http://sqlite.org/speed.html

3) Уже реализует кучу "фантиков" (например: триггеры), которые гениальные программисты MySQL всё никак написать не могут.

4) Поставляется по умолчанию с новой версией PHP. А клиент MySQL, из-за плясок с лицензированием, больше не поставляется.

> сложность современных СУБД сравнима со сложностью современных самолетов, только летают они по-разному ..

Угу, только разработчики современных самолётов как правило не врут, что "наш самолёт всегда летает в 10-15 раз быстрее конкурентов" --- засмеют.

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

так что надо внимательно читать. если про тюнинг ничего не сказано то это как в тесте мс где самба слила. ессно все было неподкрученное.

зы. а доки у мускуля сливают идущим с постгри просто неимоверно. да и управление юзерам в постгри тоже лучше

Ну вопервых, как правильно сказали - где бенчмарки с использованием InnoDB, а во вторых - обеспечение целостности еще и использование триггеров подразумевает, а для удобства их использования развитый встроенный язык нужен... Так вот в чем вопрос - где у MySQL триггеры и что там за встроенный язык используется? =)

> 2. Тот, кто хорошо знает Оракл, едва ли будет "осваивать" какую либо другую базу.

> 3. Применение только Оракла не всегда оправдано, именно поэтому существуют такие системы, как My и Post.

эти пункты противоречат друг другу

PS я взялся за MySQL хорошо зная Oracle, т.к. маленький размер базы иногда гораздо важнее (ora8.1 - 1 cd (+ проблема с Р4), ora9 - 3 cd, mysql4.1 - 35 MB)

> более-менее научились программировать и прочитали пару-другую книжек по теории реляционных СУБД

в исходниках есть ссылка на 3й том русской редакции Д.Кнута

а Вы ее читали? или хотя бы какого цвета учебник?

>>pаспораллелить ERP имхо не реально

Ну да конечно откудова такие выводы?

www.erp5.org

-- А мы убежали и от postgre , mysql и теперь сидим на Zope и очень довольны Ж))

>> более-менее научились программировать и прочитали пару-другую книжек по теории реляционных СУБД

> В исходниках есть ссылка на 3й том русской редакции Д.Кнута. А Вы ее читали? или хотя бы какого цвета учебник?

> vadiml (*) (20.01.2005 12:42:33)

Браво! Даже не дежурный "респект", а именно так. А то чем меньше в голове, тем больше гонору: "что-то сляпали", притом, что сами и исходников не видали...

А новость однозначно хорошая, давно ждал, не было времени с бетой играться. Что до споров MySQL vs Postgres, то к чему?

Один гаечный ключ никогда не подойдейт ко всем гайкам. Хранить (и смотреть) логи прокси, ИМХО, лучше в "мускуле". Нужны хранимки/триггера - ставьте "постгрес". Главное, что есть выбор.

> А мы убежали и от postgre , mysql и теперь > сидим на Zope и очень довольны Ж))

именно Zope или все же Gadfly?

> именно Zope или все же Gadfly?

Скорее всего имеется ввиду ZODB.

Вот ещё одно сравнение PostgreSQL и SQLite: http://www.sergeant.org/sqlite_vs_pgsync.html (сдесь постгрес оттюнен).

Там ниже написано, что в mysql не было проверки внешних ключей при загрузке. Этим все и объясняется.

> в исходниках есть ссылка на 3й том русской редакции Д.Кнута

именно русской? то есть тупые шведо-финны сдались и наняли русских программистов? тогда у мыскля ещё есть шанс.

> или хотя бы какого цвета учебник?

свежее издание --- белого. ;

> PS я взялся за MySQL хорошо зная Oracle, т.к. маленький размер базы иногда гораздо важнее (ora8.1 - 1 cd (+ проблема с Р4), ora9 - 3 cd, mysql4.1 - 35 MB)

у PostgreSQL инсталляция ещё меньше --- ftp://ftp.ru.postgresql.org/pub/unix/database/pgsql/win32/ виндовый инсталлятор в 17 Мб, ftp://ftp.ru.postgresql.org/pub/unix/database/pgsql/src/8.0.0/ исходники в 10 Мб.

Не говоря уже о том что есть встраиваемые Firebird и SQLite.

Так почему был выбран именно мыскль? Или, другими словами, какого цвета Оракл?

А что там у PostgreSQL 8 с проблемой утечки памяти. В предыдущих версиях была кажется такая проблема. Я не спец по PG (на мускле сижу), но интересуюсь развитием PG.

> В предыдущих версиях была кажется такая проблема.

Народная мудрость гласит: когда кажется --- креститься нужно.

> Я не спец по PG (на мускле сижу),

на мускле --- не самое страшное, главное на героин не подсядь.

to onz Уверен ли ты? "Хранить (и смотреть) логи прокси, ИМХО, лучше в мускуле"

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

>> 2. Тот, кто хорошо знает Оракл, едва ли будет "осваивать" какую либо другую базу.

>> 3. Применение только Оракла не всегда оправдано, именно поэтому существуют такие системы, как My и Post.

> эти пункты противоречат друг другу

Разверну. Если я действительно крутой спец по Ораклу, я буду сидеть на серьезных системах (иначе неинтересно или халтура). А там некогда страдать фигней, в них хватает проблем :) Кстати, есть два типа специалистов, хорошо знающих оракл -- проектировщики и dba. Работы по горло и работы высокооплачиваемой. Нафиг заниматься чем-то другим?

Когда проблема из кисельных таблиц дорастает до решения уровня сиквельной базы, руководство решается проконсультироваться на эту тему у спецов. Дипломированный спец, оценивая задачу, расписывает, как все будет сухо и комфортно под ораклом. Когда узнаются требуемые материальные затраты, вариант большей частью автоматически отпадает :)

Человек, который волен сам решить, какую субд взять, не являясь специалистом оаркла, выберет мускул, постгресс или вообще маленький и мягкий сиквел. Хотя в идеологической непоследовательности создателей оракл врядли можно упрекнуть, всем было бы плохо, если бы они стали монополистами. И раз практика -- критерий истины, и раз существуют другие СУБД -- значит полет нормальный :) Что ненужно -- умирает само по себе.

Когда холмс объяснил ватсону последовательность шагов, тот воскликнул, что это же само собой разумеющееся. :)

> вырастут потребности - вырастет база гигов до 20 - захочется Oracle...

Гм. Недавно завершили проект, построенный на связке с Постгресом, так у нас объем только первоначальных данных зашкалил за 12 Гигов (планируемый рабочий объем на порядок больше). Никакого желания переходить на Оракл нет.

К вопросу о скорости Постгреса - на этапе разработки использовали в качестве сервера следующую конфигурацию: Atlon XP 1600 с 256 метрами памяти под управлением Debian (Woody, ядро Linux - 2.4.18) с постгресом версии 7.2. При сдаче разработки в промышленную эксплуатацию выделили под постгресс двухголовый Зеон с 1,5 Гб памяти и установленным постгресом 7.4, работающим под Mandrake 10.1 (ядро Linux - 2.6). В результате безо всякого тюнинга постгреса скорость первоначального наполнения базы выросла в 11 раз. Показательно, не правда ли?

> наполнения базы выросла в 11 раз. Показательно, не правда ли?

Показательно здесь только то, как здорово оптимизировали ядро 2.6
для работы с бд. Именно оно выдаёт эти разы преимущества.

> Там ниже написано, что в mysql не было проверки внешних ключей при загрузке. Этим все и объясняется.

Да ладно. В конце концов, что такое 2.5 дня на загрузку данных?
Ерунда ;)

> Показательно здесь только то, как здорово оптимизировали ядро 2.6 для работы с бд. Именно оно выдаёт эти разы преимущества.

Угу, и при оптимизации ядра OSDL очень плотно сотрудничает с разработчиками PostgreSQL. А вот ананимусов с LOR не спрашивает почему-то... ;

> Да ладно. В конце концов, что такое 2.5 дня на загрузку данных?Ерунда ;)

Ты же само сверху согласилось, что все бенчмарки --- для лохов? Чего опять развонялось?

А передергивать зачем? Broken_Foreign в mysql так нигде и не реализован по причине изложенной в мануале. То что мускульцы сумели реализовать КАКИЕ-ТО фичи, не пожертвовав скоростью, ни в коем случае не отменяет вышесказанного. Где они врали?

> Broken_Foreign в mysql так нигде и не реализован по причине изложенной в мануале.

Здрасте приехали. Внешние ключи реализованы в InnoDB и в Светлом Будущем обещаются для всех типов мысклёвых таблиц. А этот пункт из мануала, что характерно, сразу выкинули, как только их реализовали!

> То что мускульцы сумели реализовать КАКИЕ-ТО фичи, не пожертвовав скоростью, ни в коем случае не отменяет вышесказанного. Где они врали?

Для альтернативно одарённых повторю: пока мысклеписатели не могли реализовать какие-то фичи, они говорили "эти фичи всегда тормозят процесс". Потом их реализовали и говорят уже что "эти фичи не тормозят процесс, мы их клёво реализовали". Два этих утверждения истинными быть не могут, значит где-то врали. Понятно?

> Два этих утверждения истинными быть не могут

Легко. Просто ты слаб в логике вдобавок ко всем твоим другим проблемам ;)
Поскольку эти фичи не были реализованы самой командой mysql, их выводы
строились исключительно на анализе сторонних разработок - того же
постгреса, к примеру. И до тех пор, пока команда mysql не имела идей
как реализовать эти фичи без серьёзной потери производительности, она
не реализовала их, не желая слепо копировать чужую отстойную технологию.
Как только своя качественная технология созрела, они стали претворять в жизнь.

Кто просил тесты mysql/innodb vs postgresql?
Вот короткий, но показательный тест:

Wall clock time in seconds
Test InnoDB PostgreSQL 7.1.1
Insert of 100 000 rows, copied from a table 1.96 9
Sum of an integer column from a join of 100 000 rows 0.58 7

Источник: http://www.innodb.com/bench.php

InnoDB не родная реализация бэкенда для мускуля. Его мускульцы скоммуниздили вместе с реализацией foreign keys. Причем скорость мускуля на InnoDB значительно ниже, чем на MyISAM. Чё-то я не видел бенчей где-бы сравнивалась скорость мускуля на InnoDB с чем нибудь еще.

:) Идем на этот источник и чего мы там видим? "Results from a test with MySQL/InnoDB-3.23.39 and PostgreSQL-7.1.1." угу. больше года назад тестили (см. версии).

Далее: "Both databases were configured with a 24 MB buffer pool (called shared cache in PostgreSQL) and a 4 MB log buffer" Угу. У постгресса 4 мегабайта на лог. При 100000 записей за транзакцию. Причем неизвестно какого размера. Прямо круть, какой авторитетный тест.

"мы выпили фанты и тормознули конкуррента".

Проблемы были с разрастанием файлов, в которых хранятся индексы. Уже давно fixed :-)

InnoDB уже такая же родная реализиция как и MyISAM.
Команда InnoDB работает сейчас совместно с командой MySQL.

Ок. предлагаю провести совместный бенчмарк
используя TPC-C тест от OSDL (http://sourceforge.net/projects/osdldbt/).
Я берусь настроить и сконфигурить MySQL 4.0.23.
Есть желающие сделать тоже самое с PostgreSQL ?
условия и выбор сервера обсуждаемы.

Скорее всего имеется ввиду ZODB - Именно

> предлагаю провести совместный бенчмарк используя TPC-C тест от OSDL (http://sourceforge.net/projects/osdldbt/). Я берусь настроить и сконфигурить MySQL 4.0.23. Есть желающие сделать тоже самое с PostgreSQL ?

готов поучаствовать...