Postgres 9,1 против Mysql 5,6 InnoDB?

Question

Простой вопрос - что лучше для базы данных среднего / большого размера с требованием совместимости с ACID в 2012 году.

Я прочитал все (ну, большинство) о MySQL vs pgSQL, но большинство этих постов относятсядо версии 4,5.1 и 7,8 соответственно и довольно устарели (2008, 2009).Уже почти 2012 год, так что, я думаю, мы могли бы попытаться по-новому взглянуть на проблему.

По сути, я хотел бы знать, есть ли что-то в PostgreSQL, которое перевешивает простоту использования, доступность и большую базу знаний / знаний для MySQL.

Является ли оптимизатор запросов MySQL по-прежнему глупым?Это все еще очень медленно на очень сложных запросах?

Ударь меня!:)

PS.И не посылай мне очки или вики.Я ищу несколько конкретных пунктов, а не обзор + я доверяю StackOverflow больше, чем какой-то случайной странице с «умным парнем», сияющим его светом.

Приложение

Размер проекта : скажем, система заказов с примерно 10-100 заказов в день на одну учетную запись, пару тысяч учетных записей, в конечном итоге каждая может иметь от нескольких сотен до нескольких тысяч пользователей.

Лучшена : быть перспективным и гибким, когда дело доходит до растущих и меняющихся требований.Производительность также важна для поддержания низких затрат в отделе оборудованияТакже наличие квалифицированной рабочей силы будет фактором.

OLTP или OLAP : OLTP

Answer 1

PostgreSQL намного более продвинут, когда дело доходит до функций SQL.

Вещи, которые MySQL до сих пор не имеет (и PostgreSQL имеет):

• Отложенные ограничения
• проверка ограничений (MySQL 8.0. 16 добавил их, MariaDB 10.2 имеет их)

• полное внешнее соединение
  MySQL молча использует внутреннее соединение с некоторыми вариациями синтаксиса:
  https://rextester.com/ADME43793
  

• боковые соединения

• регулярные выражения не работают с UTF-8 (исправлено с MySQL 8.0 )
• регулярные выражения не поддерживают замену или подстроку (Представлено с MySQL 8.0 )
• табличные функции (select * from my_function())
• общие табличные выражения (Представлено с MySQL 8.0 )
• рекурсивные запросы (Представлено с MySQL 8.0 )
• записываемые CTE
• оконные функции (Представлено с MySQL 8.0 )
• индекс на основе функций
• частичный индекс
• статистика нескольких столбцов
• полнотекстовый поиск по транзакционным таблицам (MySQL 5.6 поддерживает это)
• ГИС-функции на транзакционных таблицах
• КРОМЕ или оператор INTERSECT
• вы не можете использовать временную таблицу дважды в одной и той же инструкции выбора
• вы не можете использовать изменяемую таблицу (обновить / удалить / вставить) в дополнительном выборе

• вы не можете создать представление, которое использует производную таблицу (возможно, начиная с MySQL 8.0)

   create view x as select * from (select * from y);
  

• согласованность чтения на уровне операторов. Например, необходимо:
  update foo set x = y, y = x или
  update foo set a = b, a = a + 100
• транзакционный DDL
• DDL триггеры
• исключающие ограничения
• хранилище ключей / значений
• Индексирование полных документов JSON
• типы диапазонов
• доменов
• массивы (включая индексы для массивов)
• ролей (групп) для управления привилегиями пользователя (MariaDB имеет их , Представлено с MySQL 8.0 )
• параллельные запросы (начиная с Postgres 9,6 )
• пользовательские типы данных (включая проверочные ограничения)
• материализованные представления
• пользовательские агрегаты
• функции пользовательских окон
• правильный boolean тип данных
  _{(обработка любого выражения, которое может быть преобразовано в ненулевое число как "истина", не правильный логический тип)}

Когда дело доходит до пространственных / ГИС-функций, Postgres с PostGIS также обладают гораздо большими возможностями. Здесь - хорошее сравнение.

Не уверен, что вы называете "простота использования", но есть несколько современных функций SQL , которые я бы не хотел пропустить (CTE, оконные функции), которые бы определяли для меня "простоту использования".

Теперь, PostgreSQL не совершенен и, вероятно, самая неприятная вещь может быть, чтобы настроить ужасный процесс VACUUM для тяжелой базы данных записи.

Answer 2

Оптимизатор запросов MySQL все еще глуп? Это все еще супер медленно очень сложные запросы?

Все оптимизаторы запросов иногда глупы. PostgreSQL менее глуп в большинстве случаев. Некоторые из последних функций PostgreSQL SQL (оконные функции, рекурсивные запросы WITH и т. Д.) Очень мощные, но если у вас тупой ORM, они могут быть недоступны для использования.

Размер проекта: скажем, система заказов примерно 10-100 заказов / день на счет, пару тысяч счетов, в конце концов, каждый может иметь от нескольких сотен до нескольких тысяч пользователей.

Звучит не так уж и много - в пределах досягаемости большой коробки.

Лучше: быть перспективным и гибким, когда дело доходит до роста и меняющиеся требования.

PostgreSQL имеет сильную команду разработчиков с расширенным сообществом участников. Политика выпуска является строгой, с исправлениями только в точечных выпусках. Всегда следите за последним выпуском 9.1.x для исправления ошибок.

В прошлом MySQL несколько более спокойно относился к номерам версий. Это может измениться с ответственным Oracle. Я не знаком с политикой различных вилок.

Производительность также важна для поддержания низких затрат в отделе оборудования.

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

Также наличие квалифицированной рабочей силы будет фактором.

Это ваше ключевое решение. Если у вас есть команда опытных хакеров Perl + PostgreSQL, сидящих без дела, используйте это. Если ваши люди знают Lisp и MySQL, используйте это.

OLTP или OLAP: OLTP

PostgreSQL всегда был силен в OLTP.

Моя личная точка зрения заключается в том, что список рассылки PostgreSQL полон вежливых, полезных, знающих людей. У вас есть прямой контакт с пользователями с базами данных Terabyte и хакерами, которые создали основные части кода. Качество поддержки действительно отличное.

Answer 3

В качестве дополнения к @ a_horse_with_no_name answer я хочу назвать некоторые особенности, которые мне так нравятся в PostgreSQL:

• массивы данных типа ;
• расширение hstore - очень полезно для хранения key->value данных, возможно создание индекса по столбцам этого типа;
• различные языковые расширения -Я нахожу Python очень полезным, когда дело доходит до неструктурированной обработки данных; синтаксис
• distinct on - я думаю, что это должен быть компонент ANSI SQL, он выглядит очень естественным для меня (в отличие от группы MySQL по синтаксису);
• составные типы;
• типы записей;
• наследование ;
• Функции версии 9.3:
  • боковые объединения - одна вещь, которую мне не хватает в SQL Server (где он называется external / cross apply );
  • собственная поддержка JSON ;
  • DDL триггеры ;
  • рекурсивные , материализованные , обновляемые просмотров;

Answer 4

PostgreSQL является более зрелой базой данных, имеет более длинную историю, более совместим с ANSI SQL, ее оптимизатор запросов значительно лучше. MySQL имеет разные механизмы хранения, такие как MyISAM, InnoDB, in-memory, все они несовместимы в том смысле, что SQL-запрос, выполняющийся на одном движке, может вызвать синтаксическую ошибку при выполнении на другом движке. Хранимые процедуры лучше в PostgreSQL.