Как стать автором
Обновить

Комментарии 13

Забыли упомянуть важный момент. Для MySQL есть Galera Cluster (или он же в виде Percona XtraDB Cluster), который даёт честный мульти-мастер (с ограничениями на размер транзакций, должны влезать в оперативку, но для большинства случаев этого хватает). Мульти-мастер бывает нужен редко. А вот возможность переключать нагрузку между базами простым L3 балансировщиком типа haproxy, не боясь потерять/отменить какие-то транзакции - это просто прекрасно. Ну и при потери сетевой связности меньшая часть кластера просто перестаёт принимать запросы, не надо никаких костылей для STONITH прикручивать.

Лучше тогда все-таки про group replication вспомнить, так как galera это тоже сложное стороннее решение. А group replication уже в ядре СУБД.

К слову в postgres можно тоже всё решать балансировщиками, которых ещё и несколько на выбор.

Воу, а я и не знал про такое. Будем смотреть.

https://www.percona.com/blog/battle-for-synchronous-replication-in-mysql-galera-vs-group-replication/ - это, конечно, блог перконы, но некоторые аргументы выглядят разумно. Простота State Transfers, например.

в postgres можно тоже всё решать балансировщиками, которых ещё и несколько на выбор

Да, но это дополнительная сложность и ещё одно место, где что-то может пойти не так. Если нет выделенного DBA, который будет со всем этим хозяйством разбираться, то хочется, чтобы оно просто работало.

Статья оставила странное впечатление. Особенно спорный пункт про горизонтальное и вертикальное масштабирование. Postgres прекрасно позволяет добавлять инстансы и производить с них чтение.

Именно поэтому про масштабирование написано в разделе Спорные и ситуативные факторы ;)

А так конечно и MySQL и PgSQL прекрасно масштабируются горизонтально, но вот про вертикальное масштабирования - я бы сказал что MySQL будет лучше работать (производительность выше) на многопроцессорных системах ибо у нее из коробки есть поддержка NUMA, но и это спорное утверждение нуждающееся в доказательствах через тесты на конкретно Ваших нагрузках и кейсах.

как раз проблем с вертикальным масштабированием у PostgreSQL нет. Просто правим конфигу устанавливая нужные объемы памяти .

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

Количество запросов в Гугле не показатель популярности. В свое время по mysql было написано большое количество туториалов, новички гуглят эти статьи и поднимают статистику, прошаренные ребята (использующие pgsql) гуглят меньше.

Куда репрезентабельнее было бы количество вакансий, где требуется знание pgsql. Я полагаю что в вакансиях слова MsSQL, Oracle и PostgreSQL будут встречаться на порядок чаще чем MySQL.

Стоит заметить, что, к сожалению, самый популярный стек, включающий PHP, Apache MySQL, является очень популярным как раз среди не очень развитых разработчиков. А ещё если по чему-то задают, то это также может означать, что доки не так хороши или сама технология - запутанная с кучей неявных вещей.

нечувствительна к регистру

Почему это достоинство? Если БД чувствительна к регистру - есть способы реализовать нечувствительность к регистру для нужных полей. А вот обратное уже не верно.

позволяет включать неагрегированные столбцы в SELECT, который использует предложение GROUP BY

Сомнительное достоинство

Ошибки в статье.
1) Mysql может быть как нечувствительна к регистру _ci // case ignore
пример:

CREATE TABLE `table1` ( ... `name` TEXT NULL DEFAULT NULL COLLATE 'utf8_general_ci', ... ) COLLATE='utf8_general_ci' ENGINE=InnoDB;

Так и чувствительна к регистру, если использовать COLLATE='utf8_general' без _ci
Все настраивается прозрачно, как на всю базу, так и на каждую колонку в отдельности.

https://mysql.rjweb.org/utf8mb4_collations.html

2) ошибка в статье про OUTER JOIN - Mysql позволяет использовать явно, ниже уже написали.
3) так-же про лицензии, не совсем ошибка, но в mySQL есть платная Enterprise лицензия.
Некоторые штуки, например, приличный бекап больших баз, РЕПЛИКАЦИЯ качественная,и прочее, требующиеся для баз больше 1ТБ , доступны из коробки только с этой лицензией.
Если коммюнити лицензия, придется пользоваться сторонними средствами репликаций и бекапов.

MySQL также не поддерживает стандартные для SQL вещи, как ... или «OUTER JOIN».

Странно, как может не быть OUTER JOIN.

Сходил посмотреть доку - там пишут что есть OUTER, да я и сам писал запросы на MySQL с OUTER JOIN.

https://dev.mysql.com/doc/refman/8.0/en/join.html

позволяет включать неагрегированные столбцы в SELECT, который использует предложение GROUP BY

кстати, такое поведение зависит от настройки sql_mode и отсутствия в ней режима ONLY_FULL_GROUP_BY. причем в 8-ой версии mysql этот режим включен по умолчанию, поэтому движок будет ругаться на "nonaggregated column" в списке столбцов запроса.

Зарегистрируйтесь на Хабре, чтобы оставить комментарий