Postgres vs MySQL (holywar)

0

2

Приветствую глубокоуважаемого Олла.

Подскажите url СВЕЖЕГО русскоязычного сравнения PostgreSQL и MySQL ? Что выбрать лучше для высоконагруженных проектов? Сам я рекомендовал было Postgres но наши разработчики послали меня фсат. Мол MySQL ведет такая крупная корпорация как Oracle и он будет улучшаться. Показывал обзоры, но меня ткнули в то что обзоры 1-2 годичной давности и за эти 1-2 года все изменилось.

Лично меня MySQL раздражает, надо аргументированно переубедить или меня или руководство. Основные раздражающие пункты:
1. Замороченная репликация, делающаяся через копию бинарей в момент table lock.
Не понимаю почему не опуститься до примитива: Сдампить в sql, удалить базу, создать на мастере/слейве две пустых базы и явно укзать что они синхронизированы а там сделатиь импорт из sql. И так для каждой базы в отдельности по очереди.
2.Сэкспортировал 2Gb базу в sql файл. База была в формате MyISAM и решил я ее импортировать в InnoDB формат. Поменял в sql дампе формат MyISAM на InnoDB и запустил. 31 Час это крутится, импортировано 3.7Gb. В параллель устав ждать 30 часов запустил импорт MyISAM формата - за 1 час 15 минут уже 5Gb. Не ожидал такой засады от innoDB. В итоге ужасная производительность хранилища позволяющего делать неблокирующий дамп. В MyISAM во время бэкапа таблицы лочатся что не есть хорошо для бэкапа 2Gb базы.
3. Отсутствуют пакеты Cluster версии для Debian/Ubuntu.

В итоге все же прикручу шнурками бинарный дистр MySQL Cluster и посмотрю производительность кластерного хранилища и как там у него с блокировками во время бэкапа базы (mysqldump)

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

Ссылка

←	Debian и кластерный MySQL

Организовать временный хостинг в полевых условиях

→

31 Час это крутится, импортировано 3.7Gb

ОЧЕНЬ кривые настройки innodb. Конечно, втягивается innodb дамп много медленнее, но не до такой степени. Я с дефолтовыми настройками 4Гб (с тонной индексов) втягивал 5 часов 40 минут: innodb. myisam. прозводительность. ку-ку.

Тоже (по моим запросам) непозволительно много, но 31 час на 2Гб — это безумие какое-то :)

…

А PostgreSQL я пока так и не осилил. Чисто с точки зрения администрирования и обслуживания что-то инопланетное. Скорее на ту же MongoDB перейду, чем на Postgre :)

~~KRoN73~~ ★★★★★
(28.01.12 23:25:37 MSK)

Ответ на: комментарий от KRoN73 28.01.12 23:25:37 MSK

вполне удобно, если привыкнуть. Другое дело когда есть и MySQL и PgSQL. Начинаешь вместо DESCRIBE использовать \d в MySQL

xpahos ★★★★★
(29.01.12 00:05:04 MSK)

Ответ на: комментарий от xpahos 29.01.12 00:05:04 MSK

Начинаешь вместо DESCRIBE использовать \d в MySQL

Я всё равно cli только для запросов и explain использую :) Работа со структурой в 99% случаев в phpMyAdmin :)

вполне удобно, если привыкнуть

Да в работе разницы принципиальной не должно быть. SQL есть SQL. Да и в администрировании, если втянешься. Вопрос именно во входном барьере. В результате у меня на сервере postgresql стоит уже лет 6…7, но до сих пор так и не используется :)

~~KRoN73~~ ★★★★★
(29.01.12 00:24:14 MSK)

Ссылка

Что лучше — сильно зависит от проекта. Есть классная книга по postgresql:

PostgreSQL 9.0 High Performance (Gregory Smith)

http://books.google.ru/books?id=gCi3cQAACAAJ&dq=postgresql high performan...

советую ознакомится. Книга есть на либрусеке.

Для небольших вебпроектов, а также для всяких складских бд считается, что mysql быстрее. Для классической работы с бд быстрее будет postgresql.

soomrack ★★★★★
(29.01.12 00:27:52 MSK)

Ссылка

Зависит от сложности запросов

namezys ★★★★
(29.01.12 00:50:01 MSK)

Ссылка

У нас база постгре на 60 Гб поднимается около 2 часов

namezys ★★★★
(29.01.12 00:51:21 MSK)

Я работал NDB кластером. Не советую трогать это Г - почитайте сначала их оф форум - половина постов про креши, половина про тормоза.

Из замеченного мной:
1) Оптимизатор в NDB не умеет использовать статистику, планы запросов выбираются согласно положения звезд и константны для любых значений параметров в запросе(то есть видно что статистика не работает).
2) Джойн крайне медленный. Запрос вида

select t1.f1,t2.f2 FROM t1 LEFT JOIN t2 ON t1.id=t2.id WHERE ...

в 4 раза медленнее чем

select t1.f1,t3.f2 FROM t1 LEFT JOIN (select * from t2) t3 ON t1.id=t3.id WHERE ...

В версии 7.2 которая еще devel, некоторые виды джойнов ускорены, однако LEFT JOIN быстрее не стал в нашем кейсе.
3) Тяжелый update запрос несколько раз вызывал креш sql ноды.
4) Общая проблема mysql - только NL тип джойна, никакими там merge join/hash join и не пахнет. 5) Совершенно грустное количество информации по эксплейну, немного спасает профайлинг запросов, но после постгреса - только негативные эмоции.

ventilator ★★★
(29.01.12 01:50:20 MSK)

Хоть как то это может работать только когда хранилище таблиц - MEMORY. Как только данные лежат на диске, производительность вообще ужасна. При этом в итоге постгрес на тех же данных, при прогретом кеше показывает производительность выше чем 6 таких же машин, на которых развернут ndb кластер с хранением данных исключительно в RAM.

ventilator ★★★
(29.01.12 02:01:40 MSK)

Ссылка

Ответ на: комментарий от ventilator 29.01.12 01:50:20 MSK

В версии 7.2 которая еще devel, некоторые виды джойнов ускорены, однако LEFT JOIN быстрее не стал в нашем кейсе.
3) Тяжелый update запрос несколько раз вызывал креш sql ноды.
4) Общая проблема mysql - только NL тип джойна, никакими там merge join/hash join и не пахнет. 5) Совершенно грустное количество информации по эксплейну, немного спасает профайлинг запросов, но после постгреса - только негативные эмоции.

Спасибо за аргументированное мнение. Значит «Не буду трогать даже длинной палкой». Спасибо что сэкономили мне массу времени. Вот не знаю еще стоит ли репликацию master/master в MySQL настраивать? На случай экстренных работ с SQL. Геморройная репликация. Лет 5 назад работал с Postgres и отложилось что репликацию там можно прямо на ходу делать, не останавливая сервер - версионность дает о себе знать. В MySQL какие то шаманские пляски с бинарными файлами баз.

n0mad ★★★
(29.01.12 03:20:16 MSK) автор топика

Ответ на: комментарий от namezys 29.01.12 00:51:21 MSK

У нас база постгре на 60 Гб поднимается около 2 часов

Что в данном случае понимается под «поднимается» ?

n0mad ★★★
(29.01.12 03:27:11 MSK) автор топика

Ответ на: комментарий от n0mad 29.01.12 03:20:16 MSK

В mysql тоже версионность есть в innodb. Вот только там statement репликация, когда на слейв шлется просто лог запросов. Для репликации пляски с бинарными файлами не обязательны - делаете дамп на мастере с CHANGE MASTER TO информацией (смотрите флаги mysqldump), а потом просто льете его на слейв и стартуете там репликацию. Минус в том что если у вас база большая то дамп идет долго, потом заливка его тоже долгая. Но в целом да, мне репликация показалась ужасно кривой. Вроде лет 5 назад в постгресе своей репликации не было, только внешние решения, сейчас же есть отличный нативный master-slave в синхронном и асинхронном режиме.

Про скорость загрузки в постгрес - обычно для импорта данных используется COPY, и этот метод льет данные минуя sql движек, то есть очень быстро, кроме того pg_restore давно умеет работать в несколько потоков. Потому залить 60гигов можно гораздо быстрее. Mysql тоже умеет LOAD FROM .. однако почему то это не используется mysqdump-ом при экспорте данных.

ventilator ★★★
(29.01.12 04:50:44 MSK)

Ответ на: комментарий от n0mad 29.01.12 03:20:16 MSK

master-master я бы вообще не стал использовать, потому как после split-brain руками восстанавливать базу совсем не хочется. Мультимастер в самом деле в продакшн лучше не ставить.

ventilator ★★★
(29.01.12 04:56:22 MSK)