Postgres 9.1 vs Mysql 5.6 InnoDB?

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

Я прочитал все (а самое главное) о mySQL vs pgSQL, но большинство из этих сообщений относятся к версиям 4.5.1 и 7.8 соответственно и довольно датированы (2008,2009). Его почти 2012 теперь так, я думаю, мы могли бы попытаться взглянуть на этот вопрос.

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

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

Убей меня!:)

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

Добавление

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

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

OLTP или OLAP: OLTP

ОТВЕТЫ

Ответ 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:

Ответ 4

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

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

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

Ответ 5

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