Postgres 9.1 vs Mysql 5.6 InnoDB?

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

OLTP или OLAP: OLTP

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

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

Ответ 2

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

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

• отсроченные ограничения
• проверить ограничения (MySQL 8.0.16 добавил их, MariaDB 10.2 их имеет)

• full outer join
  MySQL молча использует inner join с некоторыми вариациями синтаксиса:
  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)
• параллельное создание индекса (начиная с Postgres 11)
• пользовательские типы данных (включая проверочные ограничения)
• материализованные взгляды
• пользовательские агрегаты
• пользовательские оконные функции
• правильный boolean тип данных
  _{(любое выражение, которое может быть преобразовано в ненулевое число как "true", не является правильным логическим типом)}

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

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

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

Ответ 3

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

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

Ответ 4

Вот некоторые эталоны, использующие эти точные версии:

http://posulliv.github.io/2012/06/29/mysql-postgres-bench/

Мое предположение заключалось в том, что MySQL был на 30% быстрее для простых задач и на 500% медленнее для более сложных запросов, вероятно, из-за оптимизатора запросов.

Ответ 5

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