Comments 34
MySQL - это минное поле. У неё куча очень странных особенностей, которые могут вставить нож в спину в самый неожиданный момент.
Из особо прекрасного: https://www.percona.com/blog/what-if-mysqls-repeatable-reads-cause-you-to-lose-money/
Ну и, строго говоря, MySQL не является SQL СУБД.
Ну и, строго говоря, MySQL не является SQL СУБД.
Очень интересно почему, можете раскрыть мысль?
С моей точки зрения, SQL СУБД должна соответствовать хоть одному SQL-стандарту.
Должен быть не только похожий синтаксис, но и поведение.
К примеру, запрос:
UPDATE foo SET a = b, b = a WHERE id = 42должен внутри выражений брать значения исходного кортежа, то есть поменять значения полей a и bместами. В MySQL же в обе колонки попадёт исходное значение b.
Про особенное виденье уровней изоляции транзакций уже было выше.
Все эти особенности в MySQL документированы и переведены в категорию фичей, но от этого как-то не легче.
А что есть в мире субд полностью поддерживающая весь ansi??
https://docs.oracle.com/database/121/SQLRF/ap_standard_sql003.htm#SQLRF55516
Вот например список исключений для оракла, там несколько листов
А еще оптимизатор запросов у mysql по сравнение с pg - младенец, я знаю тысячи способов завести mysql за угол или оптимизировать запрос и 99% из них не работают и не имеют смысла в пг.
Вообще уже давно нет ни одной причины брать MySQL кроме страха.
PS когда то я услышал фразу "PG это база данных, а MySQL это хер с гвоздями", сначала она мне показалась странной, но теперь, я моуг привести пару сотен случаев почему она на 100% правдива.
Так может вы нам пост напишете.
Я б почитал почему MySQL это хер с гвоздями. :)
Хм, идея интересная, подумаю в апреле. Беда в том что когда я говорю, что знаю сотни случаев, я не преувеличиваю, тут явно надо взять какой то срез а потом просто остановиться, а я так не умею, поэтом обычно выливатся в заготовок статьи а потом жуть страдания и прокрастинация (
То есть, например проблемы с типами данных на примерах я легко опишу, но вот для описание тупости оптимизатора запросов, нужно будет серьезную доказательную базу создать.
Но, предложение все же интересное, хотя мб сначала напишу про float математику, а то только выбрался из кучи кода, в котором разрабы очень много наивных предположений про float сделали
Ну как, получилось подумать?
Поддерживаю вопрос. Многие ругают MySQL
Но детальных кейсов, часто я не видел.
Лет 7 назад, работая в стартапе, стартап выбрал PostgreSQL как базу данных, потому что с ней работают профессионалы. Критериев больше особо не было.
Я видел террабайтные базы данных на MySQL которые себя чувствовали комфортно.
Не то чтобы я защищаю mysql, но интересна конкретика. Спасибо
Все еще ждем!
По запросу в гугл "habr postgresql mysql" можно найти многолетнюю историю превосходства postgresql. Но пункт 1 из статьи остается неизменным. )
Несмотря на свои продвинутые функции и возможности, PostgreSQL еще не достигла того же уровня популярности и широкого использования, что и MySQL.
сравнение карьерного самосвала и башенного крана
Типы данных: PostgreSQL поддерживает более широкий спектр современных типов данных, включая массивы, hstore (хранилище типа “ключ-значение”) и JSONB (бинарный JSON), которые обеспечивают более гибкие и эффективные возможности хранения данных. С другой стороны, MySQL имеет ограниченный набор типов данных и ориентирован на более простые веб-приложения.
Данный абзац заставляет думать, что указанные типы данных в MySQL отсутствуют. И если относительно первых двух это верно, то насчёт бинарного JSON - увы, неверно. MySQL хранит данные в поле типа JSON именно в бинарном виде. Простейшим доказательством чего (не считая чтения документации, конечно) может быть пересортировка свойств в объекте по алфавиту. Иными словами, то, что в MySQL обозначено как JSON, является аналогом Постгрессовского JSONB. А вот если надо сохранять данные так, как делает Постгресс в типе данных JSON, то для этого в MySQL придётся использовать тип данных TEXT.
Данный абзац заставляет думать, что указанные типы данных в MySQL отсутствуют.
А можно в MySQL вообще писать расширения, и добавлять свои типы? В постгресе можно, и PostGIS тому пример.
Насколько я быстро смог загуглить — нет, вроде нельзя. И в принципе, как по мне, один этот пункт перекрывает многие, если не все другие преимущества, касающиеся именно типов.
Я бы кстати тоже высказался так: с моей точки зрения сегодня нет никаких причин использовать MySQL, кроме одной: вы его хорошо знаете, и уже на нем работаете. То есть у вас легаси система, которую нет смысла портировать.
с моей точки зрения сегодня нет никаких причин использовать MySQL, кроме одной: вы его хорошо знаете, и уже на нем работаете
Есть ещё одна возможная причина. Порог входа для MySQL на порядок ниже. То есть он хорошо подходит для самого первого, "с нуля", знакомства. Правда, при условии, что в нём по максимуму отключены lamer-friendly расширения, и особенно - ONLY_FULL_GROUP_BY SQL Made. Иначе потом с него спрыгнуть будет тяжко.
он хорошо подходит для самого первого, "с нуля", знакомства.
Выглядит, как совет "Сначала покатайся на вазовской классике, когда научишься, купи нормальную машину".
Порог входа для MySQL на порядок ниже.
Ну, мне конечно сложно оценить, потому что у меня не с нуля ни разу, но PostgreSQL я ставил именно ничего не зная о нем, скачал дистриб, распаковал, запустил, работает. Настройки потом конечно менять надо кое-какие, но у меня и ребенок это может сделать, если что (проверено). То есть, порог входа в PostgreSQL сегодня настолько низкий, что куда уже ниже и зачем — не очень понятно. И так легко все.
Ну все же есть и ещё одна причина - средняя скорость отклика по больнице. Мускуль несколько быстрее, особенно на интенсивных чтениях, MyISAM быстрее чем InnoDb, xtraDb, даже внутри самого мускуля, без Постгре.. инмемори хранение .. появилось в Постгре? не следил давно, ибо всё что попадается последнее время - проекты на Мускуле (Мария, Перкона..).
Да, Постргес сильнее и богаче, как по типам данных, по встроенным функциям, индексированию и имеет возможность дополняться.. но, надо помнить что за всё надо платить. И плата тут одна - ресурсы сервера процы, память.
И это ещё одна причина предпочтения Мускулю: меньшие требования к ресурсам (дешевле сервер банально) для одних и тех же объемов и нагрузок. И кмк, совокупность (а не легкость начала и простота входа) и является определяющим фактором приоритетов выбора.
В статье довольно много голословных пунктов по поводу преимуществ mysql без примеров, при этом большинство из них противоречат моему опыту(хотя я не ДБА).
Из личного опыта:
в постгресе гораздо богаче синтаксис и проще писать сложные запросы(в mySQL отсуствуют иногда довольно базовые вещи для базы данных, например -full outer join)
оптимизатор в постгресе работает лучше, при переезде многие запросы без индексов стали работать быстрее без каких-либо глобальных изменений в них(те же джоины на некоторых таблицах стали выполняться быстрее без индексов, очень интересно почему)
больше актульаных материалов, некоторые проблемы проще гуглятся на постгресе, для mysql нахожу много ответов для версии 5.7(которая прямо уступает соврменному mysql). Также довольного много соврменных книг, статей по внутрянке PostgreSQL.
Из своего опыта не вижу ситуации когда я бы предпочел MySQL для нового проекта .
PG в РФ сейчас это в том числе и кровавый интерпрайз, а МусКул - это ламповое до сих пор.
Эх, жалко нет конкретных кейсов. Вот не могу я понять при выборе БД для проекта, какая лучше подойдет.
К примеру- postgresql медленнее. Насколько? Если на 10% есть ли смысл? Если скорость повысится масштабированием, есть ли смысл?
Единственное, что знаю- в постгресе есть встроенный формат для работы с json, иногда это удобнее (хотя и не критически). Так же знаю что есть разница в работе с широтой долготой, не помню в какой-то из баз есть поддержка. Но опять же, это не критический фактор.
Перефразируя- если это не какой-то проект с миллиардами записей, которых меньше 1%, а обычный энтерпрайз, то есть ли разница? За 9 лет опыта пока что не увидел проектов, что однозначно можно было сказать, вот тут постгрес лучше, а вот тут мускул.
Или нужно сильно, прямо очень сильно поднять экспертизу конкретно и в мускуле, и в постгресе, по сути стать архитектором бд, что бы явно видеть разницу?
Когда случится переезд в PGSQL (не если, а когда), будет очень больно переносить хотя бы даже схему:
Возьмём, к примеру, обычные целочисленные типы. Что вообще значит аргумент M у целочисленного типа? Впрочем, в родительской СУБД это объяснение есть. И что хочу сказать: является очень хорошим подспорьем для пользователей забить вообще на оптимизацию в плане storage. Зачем думать, надо ли SMALLINT вместо INT, если можно просто INT(2), ведь да?
Но дело даже не в этом.
create table a (a bigint not null);Казалось бы, легко и непринуждённо переносится дампом в постгрес (и да, есть вполне годная техника на mysqldump, позволяющая импортировать данные методом COPY, что в постгресе сильно ускоряет процесс миграции). А вот и нет:
$ mysqldump --compat=postgresql test
CREATE TABLE "a" (
"a" bigint(20) NOT NULL
);
$Откуда там этот M взялся? Он несовместим с PostgreSQL. Он и с ANSI несовместим. Вот и всё. Все целочисленные типы (и, наверняка, не только они) представят шанс повеселиться конкретно в этом месте.
Отдельно хочется напомнить про обилие режимов работы. Вот только, боюсь, если включить сразу какой-нибудь не нативный режим совместимости, то и смысл в этой, с позволения сказать, СУБД пропадает. Кстати, @MaxRokatansky что там насчёт недостатка постгреса по части "сложности настройки"? Как насчёт включить в рассматриваемую сложность не только my.cnf vs. postgresql.conf, но и присыпать это всё рантайм-конфигами, причём, с учётом того, как эти рантайм-конфиги сказываются в целом на последующем поведении (например, у mysql-подобных некоторые рантайм-конфиги влияют на DDL, что, в свою очередь делает такую настройку независимой от текущих параметров сессии)?
Впрочем, не всё так радужно и в PostgreSQL.
Например, CREATE ... IF NOT EXISTS совсем не обязательно не упадёт. Более того, разработчики знают об этом, но, поскольку там у руля Том Лейн, совершенно не считают необходимым поправить хотя бы документацию. Рекомендуемый способ лечения -- ADVISORY LOCKS (WAT?)
Или, например, Эррера так и не смог заставить партиционированные индексы следовать за своими таблицами-партициями в тот же самый tablespace. Воз и ныне там, лет 7 уже прошло, если не ошибаюсь. Эррера пытался аргументировать, мол, ребяты, надо лечить. Но ему быстро насовали полное лукошко, после чего, я так понимаю, он просто сдался.
Или, например, ON CONFLICT (arbiter) для партиционированных таблиц работает крайне странно. К примеру, список таблиц определяется еще на этапе планирования, было бы неплохо заглянуть в эти таблицы и поискать арбитр там, но... поскольку у руля Том Лейн, мы будем сыпать сообщениями вида
begin;
create table b(a int, b int) partition by list (a);
create table b_1 partition of b for values in (0);
alter table b_1 add constraint b_1_pk primary key (a);
create table b_2 partition of b for values in (1);
alter table b_2 add constraint b_2_pk primary key (a);
insert into b(a, b) values (1, 1);
insert into b(a, b) values (1, 3) on conflict (a) do nothing ;-- [42P10] ERROR: there is no unique or exclusion constraint matching the ON CONFLICT specification
несмотря на то, что арбитра в самом крайнем случае можно еще раз проверить у собственно таблицы, которая зареджектила вставку.
К примеру- postgresql медленнее. Насколько? Если на 10% есть ли смысл?
ИМХО попытка оценить разницу производительности в процентах не имеет особого смысла. Вернее может быть и имеет, но для каких-то конкретных операций, а не для СУБД в целом.
В моей практике: среднее время отклика GRPC микросервиса на ГО в районе 5-50 микросекунд в зависимости от сложности бизнес-логики обработки данных. А среднее время чтения из БД на практике в районе 50 микросекунд (одиночные выборки по ключу) до 500 миллисекунд (полсекунды, Карл) при составных запросах, особенно с предобработкой (т.к. обработка на клиенте м.б. даже дольше из-за сырой пересылки)..
То есть экономия 10% на обработке запроса может целый спектр задач перевести из разряда "медленно" в "Терпимо", а из "хорошо" даже и в "отлично".. я бы не был столь категоричен.
"Postgresql поддерживает мульти-мастер репликацию" - в каком месте, интересно?
"Mysql поддерживает в основном master-slave" А как же Galera кластер?
Не знаю что тут сказать. Но в многопоточных приложениях postgresql лупит всё известные мне БД в одни ворота. В сорок потоков с интервалом между одной записью в в сорок таблиц со средним объектом в 20 кило jsonb с двумя индексами на таблицу. И держать время записи в 7 миллисекунды. Плюс репликация на слейве десяти таблиц с историей под полмиллиона записей с нуля за десять секунд это нечто.
В отличие от этого, опции по управлению транзакциями в MySQL более ограничены.
Там нет управления уровнями изоляции транзакций, атомарных операций и сейвпоинтов?
Думаю наиболее интересный пример сравнения/миграции между этими СУБД это Uber. На хабре есть описание.
Когда-то лет 11 назад довелось писать библиотеку-расширение для MySQL: когда я изучил интерфейс взаимодействия между расширениями и самой СУБД, я был подвален и разочарован — он создал ощущение на коленке придуманной внутренней архитектуры. Возможно это только интерфейс взаимодействия так одебилен в угоду плагинописателям, тогда это одно, но если и для своих внутренних нужд СУБД использует такие poor-designed структуры и способы представления даных, то это грустно.
Если мне не изменяет память то MySQL AB купила Sun Microsystems которую поглатила Oracle.
Postgres не может восстановить конкретную БД на конкретный момент времени. Только весь кластер. Или только на момент бекапа.
MySQL может.
Рукалицо!
Сравнение MySQL и PostgreSQL в 2023 году