Компания
950,36
рейтинг
27 января 2015 в 18:21

Разработка → PostgreSQL vs MySQL



В преддверии своего доклада на конференции PGCONF.RUSSIA 2015 я поделюсь некоторыми наблюдениями о важных различиях между СУБД MySQL и PostgreSQL. Этот материал будет полезен всем тем, кого уже не устраивают возможности и особенности MySQL, а также тем, кто делает первые шаги в Postgres. Конечно, не стоит рассматривать этот пост как исчерпывающий список различий, но для принятия решения в пользу той или иной СУБД его будет вполне достаточно.

Репликация


Тема моего доклада «Асинхронная репликация без цензуры, или почему PostgreSQL завоюет мир», и репликация одна из самых больных тем для нагруженных проектов использующих MySQL. Проблем много — корректность работы, стабильность работы, производительность — и на первый взгляд они выглядят несвязанными. Если же посмотреть в историческом контексте, то мы получаем интересный вывод: MySQL репликация имеет столько проблем потому, что она не была продумана, а точкой невозврата была поддержка storage engine (подключаемых движков) без ответов на вопросы «как быть с журналом?» и «как различным storage engine участвовать в репликации». В 2004 году в PostgreSQL рассылке пользователь пытался «найти» storage engine в исходном коде PostgreSQL и сильно удивился, что их нет. В процессе дискуссии кто-то предложил добавить эту возможность PostgreSQL, и один из разработчиков ответил «Ребята, если мы так сделаем, у нас будут проблемы с репликацией и с транзакциями между движками».

The problem is that many storage management systems… often do their own WAL and PITR. Some do their own buffer management, locking and replication/load management too. So, as you say, its hard say where an interface should be
abstracted.
ссылка на это письмо в postgresql mailing list

Прошло более 10 лет, и что мы видим? В MySQL есть раздражающие проблемы с транзакциями между таблицами разных storage engine и у MySQL проблемы с репликацией. За эти десять лет у PostgreSQL появились подключаемые типы данных и индексы, а также есть репликация — т. е. преимущество MySQL было нивелировано, в то время как архитектурные проблемы MySQL остались и мешают жить. В MySQL 5.7 попытались решить проблему производительности репликации, распараллелив её. Поскольку проект на работе очень чувствителен к производительности репликации в силу своего масштаба, я попытался протестировать, стало ли лучше. Я нашёл, что параллельная репликация в 5.7 работает медленней однопоточной в 5.5, и лишь в отдельных случаях — примерно также. Если вы сейчас используете MySQL 5.5 и хотите перейти на более свежую версию, то учтите, что для высоконагруженных проектов миграция невозможна, поскольку репликация просто перестанет успевать выполняться.

После доклада на highload, в Oracle приняли к сведению разработанный мной тест и сообщили, что попытаются исправить проблему; недавно мне даже написали, что смогли увидеть параллелизм на своих тестах, и выслали настройки. Если не ошибаюсь, при 16 потоках появилось незначительное ускорение по сравнению с однопоточной версией. К сожалению, до сих пор не повторил свои тесты на предоставленных настройках — в частности потому, что с такими результатами наши проблемы всё равно остаются актуальными.

Точные причины такой регрессии производительности неизвестны. Было несколько предположений — например, Кристиан Нельсен, один из разработчиков MariaDB, у себя в блоге писал о том, что могут быть проблемы с перфоманс-схемой, с синхронизацией тредов. Из-за этого наблюдается регрессия в 40%, которая видна на обычных тестах. Oracle-разработчики это опровергают, и меня даже убедили, что её нет, видимо, я вижу какую-то другую проблему (и сколько же их всего?).

В MySQL репликации проблемы со storage engine усугубляются выбранным уровнем репликации — они логические, в то время как в PostgreSQL — физические. В принципе, у логической репликации есть свои преимущества, она позволяет сделать больше всяких интересных штук, об этом в докладе я тоже упомяну. Но PostgreSQL даже в рамках своей физической репликации уже сводит все эти преимущества на нет. Иными словами, почти все, что есть в MySQL, уже можно сделать и в PostgreSQL (либо будет можно в ближайшем будущем).

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

В MySQL ситуация другая. У нас есть отдельный журнал InnoDB и журнал репликации, и нужно коммитить и туда, и туда. А это two-phase commit между журналами, который по определению работает медленно. То есть мы не можем просто взять и сказать, что мы повторяем транзакцию из InnoDB-журнала — приходится разбираться, что за запрос, запускать его заново. Если даже это логическая репликация, на уровне строчек, то эти строчки нужно искать в индексе. И мало того, что приходится сделать большое количество работы, чтобы выполнить запрос — он при этом снова будет писаться в свой InnoDB-журнал уже на реплике, что для производительности явно нехорошо.

В PostgreSQL в этом смысле архитектура на порядок продуманней и лучше реализована. Недавно в нём анонсировали возможность под названием Logical Decoding — которая позволяет сделать всякие интересные штуки, которые очень тяжело сделать в рамках физического журнала. В PostgreSQL это надстройка сверху, logical decoding позволяет работать с физическим журналом так, будто он логический. Именно эта функциональность скоро уберёт все преимущества MySQL репликации, кроме, возможно, размера журнала — statement-based репликация MySQL будет выигрывать — но у statement-based репликации MySQL есть совершенно дикие проблемы в самых неожиданных местах, и не стоит считать её хорошим решением (про это всё я тоже буду говорить в докладе).

Кроме того, для PostgreSQL есть триггерная репликация — это Tungsten, который позволяет делать то же самое. Триггерная репликация работает следующим образом: ставятся триггеры, они заполняют таблицы или пишут файлы, результат отправляется на реплику и там применяется. Именно через Tungsten, насколько я знаю, делают миграцию из MySQL в PostgreSQL и наоборот. В MySQL же логическая репликация работает прямо на уровне движка, и другой ее сделать сейчас уже нельзя.

Документация


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

Например, так «выстрелила» компания Percona: они вели MySQL Performance Blog, и в этом блоге было множество статей, в которых рассматривались отдельные моменты эксплуатации MySQL. Это принесло бешеную популярность, привело клиентов в консалтинг, позволило привлечь ресурсы для запуска разработки собственного форка Percona-Server. Существование и востребованность MySQL Performance Blog доказывают, что официальной документации просто недостаточно.

У PostgreSQL фактически все ответы есть в документации. С другой стороны, я слышал много критики при сравнении документации PostgreSQL со «взрослой» Oracle. Но это, на самом деле, очень важный показатель. MySQL с взрослым Oracle никто не пытается сравнивать вообще — это было бы смешно и нелепо — а PostgreSQL уже начинают сравнивать вполне серьезно, PostgreSQL-коммьюнити эту критику слышит и работает над улучшением продукта. Это говорит о том, что он по своим возможностям и производительности начинает конкурировать со столь мощной системой как Oracle, на которой работают мобильные операторы и банки, в то время как MySQL остаётся сидеть в нише веб-сайтов. И проекты-гиганты, доросшие до большого количества данных и пользователей, хлебают горе с MySQL большой ложкой, постоянно упираясь в его ограничения и архитектурные проблемы, которые невозможно исправить, затратив разумное количество сил и времени.

Примером таких крупных проектов на PostgreSQL является 1C: PostgreSQL идёт как опция вместо Microsoft SQL, а Microsoft SQL действительно фантастическая СУБД, одна из самых мощных. PostgreSQL может заместить MS SQL, а попытка заместить его MySQL… давайте опустим завесу жалости над этой сценой, как писал Марк Твен.

Стандарты


PostgreSQL соответствует стандартам SQL-92, SQL-98, SQL-2003 (реализованы все его разумные части) и уже работает над SQL-2011. Это очень круто. Для сравнения, MySQL не поддерживает даже SQL-92. Кто-то скажет, что в MySQL такая цель просто не ставилась разработчиками. Но нужно понимать, что разница между версиями стандарта заключается не в мелких изменениях — это новые функциональные возможности. То есть в тот момент, когда MySQL говорил: «Мы не будем следовать стандарту», они не просто вносили какие-то мелкие различия, из-за которых MySQL тяжело поддержать, они еще закрывали дорогу к реализации многих нужных и важных возможностей. Там до сих пор нет нормально оптимизатора. То, что там называется оптимизацией, в PostgreSQL называется «парсер» плюс нормализации. В MySQL это лишь план выполнения запросов, без разделения. И MySQL к поддержке стандартов придут еще очень нескоро, поскольку на них давит груз обратной совместимости. Да, они хотят, но лет через пять, может, что-нибудь у них появится. В PostgreSQL есть уже все и сейчас.

Производительность и сложность администрирования


С точки зрения простоты администрирования сравнение не в пользу PostgreSQL. MySQL администрировать гораздо проще. И не потому, что в этом смысле он лучше продуман, а просто гораздо меньше умеет делать. Соответственно, и настраивать его проще.

У MySQL есть проблема со сложными запросами. Например, MySQL не умеет спускать группировку в отдельные части union all. Разница между двумя запросами — на нашем примере группировка по отдельным таблицам и union all сверху работала в 15 раз быстрее, чем union all и потом группировка, хотя оптимизатор должен оба запроса приводить в одинаковый, эффективный план выполнения запроса. Нам придется делать генерацию таких запросов руками — т. е. тратить время разработчиков на то, что должна делать база.

«Простота» MySQL вытекает, как можно увидеть выше, из крайне бедных возможностей — MySQL работает просто хуже и требует больше времени и усилий во время разработки. В противоположность этому, у PostrgreSQL есть гистограммы и нормальный оптимизатор, и он выполнит такие запросы эффективно. Но если есть гистограммы, значит, есть их настройки — как минимум bucket size. Про настройки нужно знать и в отдельных случаях их менять — следовательно, нужно понимать, что это за настройка, за что она отвечает, уметь распознавать такие ситуации, увидеть выбрать оптимальные параметры.

Изредка случается, что умелость PostrgreSQL может помешать, а не помочь. В 95% случаев все хорошо работает — лучше, чем MySQL, — а какой-то один дурацкий запрос работает гораздо медленнее. Или всё работает хорошо, а потом внезапно (с точки зрения пользователя) по мере роста проекта некоторые запросы стали работать плохо (стало больше данных, стал выбираться другой план выполнения запроса). Скорее всего, для исправления достаточно запустить analyze или немножко покрутить настройки. Но нужно знать, что делать и как это делать. Как минимум, нужно прочитать документацию PostgreSQL на эту тему, а читать документацию почему-то не любят. Может потому, что в MySQL от неё мало помощи? :)

Подчеркну, что PostgreSQL в этом смысле не хуже, просто он позволяет отложить проблемы, а MySQL сразу их вываливает и приходится тратить время и деньги на их решение. В этом смысле MySQL работает всегда стабильно плохо, и еще на этапе разработки люди эти особенности учитывают: делают все максимально простым способом. Это относится только к производительности, точнее, к способам её достижения и к её прогнозируемости. В плане корректности и удобства PostgreSQL на голову выше MySQL.

Так что же выбрать?


Чтобы определиться с выбором между MySQL и PostgreSQL для конкретного проекта, прежде всего нужно ответить на другие вопросы.

Во-первых, какой опыт есть у команды? Если вся команда имеет 10 лет опыта работы с MySQL и нужно запуститься как можно быстрее, то не факт, что стоит менять знакомый инструмент на незнакомый. Но если сроки не критичны, то стоит попробовать PostgreSQL.

Во-вторых, нужно не забывать про проблемы эксплуатации. Если у вас не высоконагруженный проект, то с точки зрения производительности разницы между этими двумя СУБД нет. Зато у PostgreSQL есть другое важное преимущество: он более строгий, делает больше проверок за вас, дает меньше возможности ошибиться, и это в перспективе огромное преимущество. Например, в MySQL приходится писать собственные инструменты для верификации обычной ссылочной целостности базы. И даже с этим могут быть проблемы. В этом смысле PostgreSQL инструмент более мощный, более гибкий, разрабатывать на нем приятнее. Но это во многом зависит от опыта разработчика.

Подводя итог: если у вас простенький интернет-магазин, нет денег на админа, нет серьезных амбиций перерасти в большой проект и есть опыт работы с MySQL — то берите MySQL. Если предполагаете, что проект будет популярным, если он большой, его будет тяжело переписать, если в нём сложная логика и связи между таблицами — возьмите PostgreSQL. Даже из коробки он у вас будет работать, поможет в разработке, сэкономит время, и вам проще будет расти.
Автор: @zabivator

Комментарии (169)

  • +50
    MySQL не выгораживаю, но как-то однобоко написано. Выглядит как сравнение <имя порошка> против «Обычный стиральный порошок» в рекламе.
    • 0
      Странно, я ведь упомянул преимущества MySQL — более простое администрирование, как минимум…
      • +34
        Ну, к слову сказать, вы это выставили так, что если чуть перефразировать то получится примерно следующее-
        «MySQL легче администрировать, потому что он тупой» :)
        • 0
          Я не знаю, что такое «тупой» в отношении СУБД.
          Я не говорил «тупой», я говорил «имеет меньше возможностей» и «практически не имеет оптимизатора».
          • +5
            Просто вы поинтересовались у bitfroster, почему он не заметил плюсов MySQL в статье. Я их тоже не заметил, а указанный вами абзац на плюс не тянет.
            Со словом «тупой» я может быть и переборщил :)
            • +6
              К сожалению, у MySQL в сравнении с PostgreSQL очень мало плюсов, и их становится всё меньше.
              • +9
                В таком случае заголовок статьи вводит читателя в заблуждение) Обычно в сравнении двух продуктов даются сильные и слабые стороны как одного, так и второго.
                А здесь, как верно заметил автор ветки — все как в рекламе порошка) Сравним обычный и наш, наш делает все, а ваш просто стирает :)
                • +23
                  Простите, но «мой» порошок — это как раз MySQL.
                  Я над ним работал в Percona, занимался как раз репликацией.
                  Я с ним вожусь в Mail.Ru Target, постоянно, и помогаю коллегам.

                  PostgreSQL для меня знаком гораздо меньше, я в нём энтузиаст, а не серьёзный пользователь (мелкие личные проекты не в счёт).

                  И, к сожалению, я вынужден констатировать, что причин выбирать MySQL для новых проектов практически не осталось.
                  Хотя MySQL — мой хлеб.
                  • +5
                    Это не очень конструктивный диалог, который ничем хорошим не закончится. Давайте остановимся и разойдемся чай пить :)
                    • +8
                      :)
                  • 0
                    > причин выбирать MySQL для новых проектов практически не осталось

                    Простой контрпример: попробуйте разработать массовую CMS а-ля WordPress на PostgreSQL… Ее же потом более 99% пользователей на типовой хостинг даже поставить не смогу из-за отсутствия поддержки PosgreSQL. Так что верно сказано — у MySQL своя ниша. По этой же причине на MySQL крайне удобно учить молодых разработчиков.
                    • +7
                      Только вот этих молодых разработчиков потом, в любых проектах связанных с DB и крупнее, чем «сайт визитка на одной страничке с гостевой книгой» приходится брать на любые должности, максимально удалённые от DBA, из-за того, что MySQL у них из головы уже ничем не выбить.

                      Как показывает практика, на этапах подготовки DBA, архитектора баз данных или программиста в проекте с DB, гораздо лучше взять человека не знакомого с базами данных и обучить его работе с DB с нуля на примере PostgreSQL, Oracle или (прости господи) MSSQL, чем взять кого-то, кто уже начал знакомство с базами данных на примере mysql и его клонов.
                      • +2
                        Это зависит от того кого берете. Бывают кадры не хотят учится +Х лет определенных технологий
                        • 0
                          Совершенно верно. Просто по опыту заметил, что нежелание учится чему-то другому после mysql возникает гораздо раньше, чем накопится +X лет опыта работы с технологиями. Причина этого в тексте обозначена — mysql слишком не любит следовать общим стандартам.
                      • 0
                        А чем вас MS SQL пугает так? Приличная СУБД с широким функционалом. Я, в принципе, одинаково хорошо отношусь ко всем трём. Оракл совсем молодец но стоит просто адски за ядро, но поначалу можно мило поиграться с экспрессом и набить навыки. МС подешевше, умеет почти все тоже самое (в моей внутренней иерархии PL SQL занимает более высокое положение чем обычный SQL) + маркетинговые фишки типа БИ. Ну и слон который не стоит ничего, но при должной дрессировке умеет все (Отбросим AG и прочие дорогие штуки, нахаляву такого не бывает).
                        В общем ИМХО все молодцы и никакого ужас-ужас тут нет.
                        А MySQL регулярно вижу в связках с пхп. Логика на пхп, данные в мускуле. Когда спрашиваешь у разработчика зачем так было делать, в ответ лишь молчание, а в пустых глазах можно увидеть лишь одинокий нейрон бессильно бьющийся о теменную кость.
                    • +1
                      Справедливости ради, когда VPS давно сравнялся по цене с виртуальным хостингом, это уже выглядит как проблемы типовых хостингов, а не проблемы для пользователей.

                      Кстати, в WordPress поддержка Postgres подключается всего лишь плагином. Что бы что-то подобное реализовать в движке, который будет ориентироваться на возможности Postgres, придётся с нуля переписать движок для MySQL.

                      Одни только каскадные триггеры золотого стоят. А GIST/GIN индексы, hstore, а теперь ещё и подключилась тяжёлая артиллерия JSONB — сама мысль поддерживать совместимость с MySQL доставляет страдания.
                  • 0
                    Я с ним вожусь в Mail.Ru Target

                    Прочитал сначала как «Я с ним вожусь в Mail.Ru Agent» и уже хотел завести диалог на эту тему, но для достоверности всё же перечитал.
      • +3
        Более просто администрирование? Ты издеваешься да? :) Сейчас репликация в PostgreSQL настраивается проще чем в MySQL. Так-как PostgreSQL позволяет взять и отреплицировать живую базу штатной тулзой, а MySQL нет. Приходится использовать LVM.
      • 0
        По поводу баз много всего есть везде =)

        Если вкратце о выборе нужно начинать с простых вопросов
        1) Объем данных сколько их ТБ или ГБ
        2) Как часто данные меняются? (или это read only)

        дальше идут пункты по порядку наверное что были в статье
  • +5
    «Например, в MySQL приходится писать собственные инструменты для верификации обычной ссылочной целостности базы.»
    Вы это серьёзно?
    • 0
      На полном серьёзе. Один из наших демонов, работающий как slave к MySQL, мониторит ссылочную целостность (ему без неё слишком грустно) и выводит специальную админку, в которой показывает висячие ссылки.

      Крайне печально, что приходится так с этим жить, но альтернатива — просто битая база и проблемы пользователей.

      В PostgreSQL практически все наши хотелки описываются через constraints общего вида.
      • +1
        Один из наших демонов, работающий как slave к MySQL, мониторит ссылочную целостность

        Можно чуть подробнее, что именно делает ваш демон?

        В PostgreSQL практически все наши хотелки описываются через constraints общего вида.

        Если речь идёт о CHECK, то это проверка не ссылочной целостности, а данных. При желании отлично решается через триггеры.
        Всё остальное (not null, unique, foreign keys) реализовано в MySQL в рамках стандарта SQL-92.
        • 0
          Можно чуть подробнее, что именно делает ваш демон?

          Демон подбирает баннеры рекламной системы Таргет

          Если речь идёт о CHECK, то это проверка не ссылочной целостности, а данных.

          Да, пожалуй, так будет корректней выразиться

          Всё остальное (not null, unique, foreign keys) реализовано в MySQL в рамках стандарта SQL-92.

          Не в MySQL, а в InnoDB. И таких базовых проверок явно недостаточно.
          • +6
            Демон подбирает баннеры рекламной системы Таргет

            И какое это имеет отношение к ссылочной целостности?

            Не в MySQL, а в InnoDB. И таких базовых проверок явно недостаточно.

            То что в InnoDB в данном контексте это очевидно, думаю.
            Не очевидно, каких именно проверок ссылочной целостности не хватает в Мускуле для полного счастья?
            • +7
              И какое это имеет отношение к ссылочной целостности?

              Демон работает как slave к MySQL и держит в памяти копию данных
              Данные — рекламные кампании, баннеры, деньги на счету рекламодателей, и ещё кучу разных данных.
              Он не может загрузить таргетинги, например, если в таргетингах кривая косвенная ссылка на баннер или кампанию — т.е. демон обнаруживает неконсистентность данных, и в такой ситуации рапортует о ней.

              Демон был бы сильно проще, если бы эти проверки делала СУБД, и ДО вставки данных в базу, а не ПОСЛЕ

              То что в InnoDB в данном контексте это очевидно, думаю

              Совершенно неочевидно. До, кажется, 5.6 в InnoDB не было полнотекстового поиска, а в 5.6 уже есть регрессия производительности репликации, потому многие сидят на 5.5

              Не очевидно, каких именно проверок ссылочной целостности не хватает в Мускуле для полного счастья?

              Например, у нас в таблицах есть поля вида linked_object_type, linked_object_id — это называется table inheritance (между прочим, в postgresql он есть «из коробки», а в mysql его приходится эмулировать) — когда таблица связана не с одной таблицей, а с некоторых заданным множеством таблиц, некоторые такой полиморфизм на уровне таблиц.
              Нам это нужно, это бизнес-требование.

              Без поддержки table inheritance и constraint'ов общего вида проверять валидность таких ссылок можно лишь на уровне приложения, а это очень неудобно.
              • +2
                Он не может загрузить таргетинги, например, если в таргетингах кривая косвенная ссылка на баннер или кампанию — т.е. демон обнаруживает неконсистентность данных, и в такой ситуации рапортует о ней.

                Вангую, что это не проблема проверки ссылочной целостности на уровне БД (foreign key запретили что ли?), а проблема рассинхрона данных в БД и их копии в памяти, из-за которой и пришлось городить костыли. К выбору MySQL/PostgreSQL никакого отношения не имеющая. Поправьте меня, если ошибаюсь.

                Совершенно неочевидно. До, кажется, 5.6 в InnoDB не было полнотекстового поиска, а в 5.6 уже есть регрессия производительности репликации, потому многие сидят на 5.5

                Мы обсуждали ссылочную целостность. Отсюда и контекст. При чём тут полнотекстовый поиск? Да и вообще для этих задач из опенсорса есть Solr/Elasticsearch/Sphinx. Всё остальное — зло.

                Без поддержки table inheritance и constraint'ов общего вида проверять валидность таких ссылок можно лишь на уровне приложения, а это очень неудобно.

                Начнём с того, что PostgreSQL изначально была Object-Relational DB. И её по фичам невозможно сравнивать с классической RDBMS.
                Во-вторых, вопрос был в том, что именно из sql constraints (за исключением check) реализовано в PostgreSQL и отсутствует в MySQL или же реализовано «не достаточно»?
                • +7
                  Вангую, что это не проблема проверки ссылочной целостности на уровне БД (foreign key запретили что ли?), а проблема рассинхрона данных в БД и их копии в памяти, из-за которой и пришлось городить костыли. К выбору MySQL/PostgreSQL никакого отношения не имеющая. Поправьте меня, если ошибаюсь.

                  Вы ошибаетесь. Подробней читайте тут: habrahabr.ru/company/mailru/blog/219015/

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

                  Мы обсуждали ссылочную целостность. Отсюда и контекст. При чём тут полнотекстовый поиск? Да и вообще для этих задач из опенсорса есть Solr/Elasticsearch/Sphinx. Всё остальное — зло.

                  Затем, что проекты сидящие на 5.5 часто используют одновременно MyISAM таблицы для полнотекстового поиска и InnoDB таблицы для всего остального. А между движками, увы, с транзациями все плохо, про constraint'ы я вообще молчу.

                  Начнём с того, что PostgreSQL изначально была Object-Relational DB. И её по фичам невозможно сравнивать с классической RDBMS.
                  Во-вторых, вопрос был в том, что именно из sql constraints (за исключением check) реализовано в PostgreSQL и отсутствует в MySQL или же реализовано «не достаточно»?

                  Я уже сказал что — constraint'ы общего вида, или «ограничения ссылочной целостности общего вида».
                  Это совершенно чёткий термин.
                  Например, тут описан: citforum.ru/database/advanced_intro/54.shtml
                  Да, тот самый пресловутый CHECK, без которого в сложных проектах жизнь становится горькой
                  • +5
                    Вы ошибаетесь. Подробней читайте тут: habrahabr.ru/company/mailru/blog/219015/

                    Если я всё правильно понял из статьи, то там прямо говорится, что Бегун запилил свой libslave, занимающийся разбором бинлога, под свои узкопрофильные задачи, и что проверка консистентности данных проводится демоном потому что «Заметим, что на этапе первоначальной выборки данных их неконсистентность не говорит о том, что ошибки присутствуют в базе — просто это такая особенность процесса загрузки данных. Такая неконсистентность будет исправлена далее демоном при дочитывании данных. А вот если после этого в них есть какие-то несоответствия — тогда уже да, тогда это база.»

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

                    dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html
                    Бажное(зарепорчено?)/не использовалось вообще/сливало данные в бинлог до проверки (зарепорчено?)?

                    Затем, что проекты сидящие на 5.5 часто используют одновременно MyISAM таблицы для полнотекстового поиска и InnoDB таблицы для всего остального.

                    Низкопроизводительный костыль, нет?

                    Да, тот самый пресловутый CHECK, без которого в сложных проектах жизнь становится горькой

                    CHECK отсутствует, но легко реализуем через триггеры.
                    Остальные «constraint'ы общего вида» в MySQL присутствуют из коробки и вполне работоспособны.
                    dev.mysql.com/doc/refman/5.6/en/create-table.html
                    • +2
                      Если я всё правильно понял из статьи, то там прямо говорится, что Бегун запилил свой libslave, занимающийся разбором бинлога, под свои узкопрофильные задачи, и что проверка консистентности данных проводится демоном потому что «Заметим, что на этапе первоначальной выборки данных их неконсистентность не говорит о том, что ошибки присутствуют в базе — просто это такая особенность процесса загрузки данных. Такая неконсистентность будет исправлена далее демоном при дочитывании данных. А вот если после этого в них есть какие-то несоответствия — тогда уже да, тогда это база.»

                      Вас удовлетворит, если я скажу, что все проблемы с целостностью данных которые встречались нам были связаны с ошибками приложения-писателя, и ни разу не было проблем, связанных с libslave?

                      Моя претензия к СУБД ровно в одном: из-за отсутствия CHECK мы не можем поймать такие ошибки на этапе записи, и нам приходится их ловить пост-фактум.

                      dev.mysql.com/doc/refman/5.6/en/create-table-foreign-keys.html
                      Бажное(зарепорчено?)/не использовалось вообще/сливало данные в бинлог до проверки (зарепорчено?)?

                      Отсутствие table inheritance и constraint'ов общего вида — это не баг, а отсутствие функциональности.

                      Низкопроизводительный костыль, нет?

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

                      CHECK отсутствует, но легко реализуем через триггеры.
                      Остальные «constraint'ы общего вида» в MySQL присутствуют из коробки и вполне работоспособны.
                      dev.mysql.com/doc/refman/5.6/en/create-table.html

                      Триггеры часто запрещены безопасниками.
                      • +1
                        Байка про foreign keys в MySQL: иногда данные по каким-то причинам нельзя стереть. Falls и ни туды ни сюды.
                        Зато можно переименовать таблицу, удалить не нужное, и переименовать обратно.
                        И ключики поднимутся и все будет как раньше… Мистика.
                      • +2
                        Вас удовлетворит, если я скажу, что все проблемы с целостностью данных которые встречались нам были связаны с ошибками приложения-писателя, и ни разу не было проблем, связанных с libslave?

                        Ну тут не в удовлетворении дело… :) Меня просто интересуют сложные ситуации на продакшене. Вот и докапываюсь, откуда ноги растут, наступившие и победившие грабли.
                        По поводу CHECK я понял. Хоть это и не имеет отношения конкретно к ссылочной целостности, но мы точки на i расставили. Спасибо.
                        • 0
                          Ну тут не в удовлетворении дело… :) Меня просто интересуют сложные ситуации на продакшене. Вот и докапываюсь, откуда ноги растут, наступившие и победившие грабли.

                          Печально, что вы меня почти не слушали, и вместо попыток понять пытались мне объяснить, что я ошибся

                          По поводу CHECK я понял. Хоть это и не имеет отношения конкретно к ссылочной целостности, но мы точки на i расставили. Спасибо.

                          Конечно, имеет. table inheritance для поддержания ссылочной целостности требует CHECK, а его нет.
                      • +1
                        Триггеры часто запрещены безопасниками.

                        Ух, а можно узнать почему? В своем проектике активно использую, например для updated_at, какие могут быть проблемы?
                        • –1
                          можно попробовать почитать этот пост тома кайта на тему «почему тригеров лучше не использовать» www.tkyte.blogspot.ru/2006/09/classic-example-of-why-i-despise.html
                          • +1
                            Какой-то не многословный этот Том…
                            Triggers are so abused — and used so inappropriately, I'd rather live without them.

                            Аргументов я не увидел, ну возможно кто-то злоупотребляет, есть вещи которые невозможно или почти невозможно сделать без триггеров без переноса логики в приложение.
                            • 0
                              В комментах он говорит подробней.
    • 0
      Берете две таблицы. Одну делаете в MyISAM, а вторую в InnoDB. А теперь попробуйте сделать foreign key банальный.
      • 0
        foreign key в myisam нет по-определению.
        • 0
          Я в курсе. Но фигни это никак не отменяет.
          • +3
            Фигня — это предлагать сделать foreign key на двигле, который foreign key не поддерживает и говорить при этом «фигня» )))
            • +8
              Фигня это РСУБД не поддерживающая foreign key :]
              • +1
                «Фигня» — это использование MyISAM в 2015м году.
  • +20
    Картинка в начале статьи однозначно зачетная.
    • +4
      К сожалению, примерно так сейчас выглядит положение MySQL в сравнении с PostgreSQL.
      Исключение — гиперогромные проекты, вроде Facebook, в которых MySQL (точнее, InnoDB) используется как B-Tree хранилище по ключу.

      Но это очень специальный и очень особенный случай, на него не следует смотреть почти никогда.

      К тому же, с появлением движка sophia в tarantool ситуация становится гораздо неоднозначней — не будет ли sophia лучше, чем MySQL?
      • +1
        Исключение — гиперогромные проекты, вроде Facebook, в которых MySQL (точнее, InnoDB) используется как B-Tree хранилище по ключу.


        Мне кажется для этого наверное лучше было бы использовать тот же Redis?
        И использование MySQL тут чисто историческое?
        • –1
          При чем тут Redis? В Редисе нет деревьев. В тоже время, я очень сомневаюсь, что фейсбук использует MySQL только для того, чтобы костыльно и с огромным оверхедом на ненужные вещи получить доступ к структуре данных, которая пишется за неделю и занимает тысячу строк кода. И более того, она у них уже написана и называется RocksDB.
          • 0
            B-Tree хранилище по ключу

            Слово «ключ» меня смутило. Мне показалось, что они B-Tree деревья по ключу хранят.
          • 0
            Хотя вот сейчас полез проверять и не нашел 100% подтверждения, что в RocksDB b-tree, в код лезть пока лень, но на всякий случай не полагайтесь на это мое заявление.
            • 0
              Смотрите мой комментарий ниже про B-Tree
          • 0
            которая пишется за неделю и занимает тысячу строк кода

            Это неправда. Задам два простых вопроса: насколько консервативен алгоритм объединения страниц в вашей версии «на тысячу строчек кода» и как у вас дела c Point-In-Time-Recovery?

            Давайте я просто покажу вам метрики из InnoDB
            oleg@x200:~/mrg/mysql-5.5.39/storage/innobase
            ➜ sloccount {btr,page}/* 2>&1 | grep ansic
            14506 top_dir ansic=14506
            ansic: 14506 (100.00%)


            15 тысяч строчек кода. Это без блокировок, транзакций и журнала. Просто B-Tree дерево.
            MySQL 5.5.39
            • 0
              Я сам реализовывал B-tree и знаю, что это алгоритм не на 15 тысяч строк и близко. В InnoDB оно может столько занимать потому, что старается быть пуленепробиваемо надежным, с точки зрения любых ошибок и отказа питания в любой момент времени. Я не говорю, что это плохо, но это очень дорого. В принципе, если это именно то, что нужно Фейсбуку, то на остальной оверхед можно подзабить, по сравнению с тем количеством disk IO, которое надо сделать при каждом обновлении таблицы. Тогда да, взять готовый код, жертвуя относительно небольшим дополнительным оверхедом выглядит разумно.
              • +1
                Боюсь, вы не понимаете всей проблематики и просто не тестировали ваш код под серьёзной нагрузкой — потому и не столкнулись с проблемами.
                • 0
                  Я делал чисто академическую реализацию алгоритма B-tree. На database scale могут быть проблемы другого уровня сложности — спорить не буду.
          • 0
            Оставлю тут пруфы для будущих поколений (2010 год, но концептуально врядли что-то поменялось):

            We use MySQL primarily as very reliable way of storing bits on disk… We use it as a key-value system deployed across thousands of machines.

            www.infoq.com/presentations/Scale-at-Facebook (30:50)
        • +3
          На конференции HighLoad частенько появляются личности из FaceBook. Их можно пораспрашивать как они допиливали напильниками и обстукивали «барсиками» MySQL чтобы он нормально работал. В процессе желательно поить коньяком. Можно нарваться на вспышки неконтролируемой агрессии.
  • +19
    Из забытого в статье: благодаря хорошему журналу, у PostgreSQL полностью транзакционный DDL (data definition language) — т.е. можно в транзакциях менять схему данных, и эти изменения буду транзакционными.
    MySQL о таком даже мечтать не смеет, к сожалению.
    • +6
      Всегда было интересно как в проектах на mysql без этого работают миграции?
      • +3
        Мучительно. С остановкой записи, либо через триггеры (при помощи percona-toolkit)
        • 0
          Это Вы сейчас хотите сказать, что постгрес не останавливает запись при альтерах на таблицы?
          • +3
            Зависит от конкретного альтера, но чаще нет, чем да.
        • 0
          Так там даже проблема не в том что запись надо останавливать а в том что миграция в середине внезапно по причине кривых рук программиста зафейлилась и все. Ни вперед ни назад не перемотать.
          • 0
            Это вообще боль. Ещё внезапно у Oracle нетранзакционный DDL. После Postgres как ушат ледяной воды на голову.
  • +1
    Интересно, а мульти-мастер репликацию от Galare в Percona кластере кто-нибудь недавно тестировал под нагрузкой? Поделиться опытом…
    • +1
      Это семисинхронная репликация, со всеми плюсами и минусами.
      Я лично практически не видел проектов, где действительно нужен мульти-мастер.
      • 0
        Это по крайней мере очень удобно. Например мы используем Cassandra и я прям не могу нарадоваться тому что не надо думать где мастер, где слейв, что будет если ляжет мастер или вообще произойдет split brain.
      • +1
        На многих гос-проектах всегда требуют сделать защиту от потери данных, если с ЦОДом что-то случится и синхронная репликация, даже не обязательно мульти-мастер, оч. проста и удобна. Это конечно глупо гонять данные на другой ЦОД и ждать ответа, но если по нагрузке проблем нет, то юзать можно.
    • +1
      Используем.

      Плюсы:
      — простая процедура ввода новых нод
      — никаких телодвижений при выходе из строя какой-либо ноды (главное, чтобы рабочих было не менее трех)

      Минусы:
      — приложение нужно учить писать только в одну ноду, иначе под нагрузкой вы столкнетесь с банальной потерей записей.

  • +2
    Как по Вашему, является ли серьезным недостатком PostgreSQL отсутствие кластерных индексов?
    На этом сайте написано что они есть в планах. Не знаете случайно, как долго ждать?)
    • +2
      Кластерные индексы — интересная тема. Да, в отдельных случаях они ускоряют запросы.
      В PostgreSQL есть www.postgresql.org/docs/9.3/static/sql-cluster.html- не кластерные индексы, конечно, но позволяет достичь схожих результатов
      • +1
        Этот самый «кластерный индекс» в постгресе не поддерживает обновления данных и на практике портит оптимизатора запросов (некоторые запросы вместо работы по индексам делают full table scan). То есть фактически его нет.

        При этом с MySQL в условиях, когда памяти сильно меньше горячих данных, только кластерный индекс спасает производительность хоть сколько-то больших выборок по диапазону в primary key. Это реальный кейс многих высоконагруженных проектов, и в них постгрес непригоден. По мелочи, бывает полезно, что в InnoDB primary индекс содержит данные.

        С другой стороны, на мой взгляд, на этом исчерпываются ключевые преимущества MySQL перед Postgres. Впрочем, говорят, репликация в mysql гораздо более адекватная (благодаря galera), и актеры
        • 0
          «кластерный индекс» — это как попытка выйграть на спичках при кешировании строк страницами хранилища
    • +2
      Большая тема, давно думаем над этим. Существующий принцип хранения данных в постгресе (плоский heap + индексы ссылающиеся на физическую позицию в heap) не очень сочетается с кластерными индексами. По-идее нужно идти в сторону pluggable storage engines, как их лучше реализовать. Опять же, путь MySQL, когда storage enigne это почти пол-СУБД, чреват тем, что не будет достаточно ресурсов их все поддерживать. Поэтому думаем в сторону какого-то компромиссного варианта.
      • +2
        А материализованные представления используют тот же принцип хранения?
        Мне кажется было бы интересно держать таблицу в привычном виде, и иметь возможность создавать к ней несколько автообновляемых кластеризованных материальных представлений. Хотя может я думаю не в том направлении)
        • +2
          Да, матвьюхи хранятся так же, как и таблицы. На матвьюхах можно получить те же преимущества, которые даёт команда CLUSTER просто указав в порождающем запросе ORDER BY. Но есть вопрос к обновлению матвьюх, пока что они у нас рефрешатся вручную. Автоматическое обновление только в планах. Но даже если оно будет, то оно будет нарушать упорядоченность данных в таблице, подобно тому как сейчас DML операторы постепенно нарушают результат команда CLUSTER.
  • +2
    Раз уж затронули 1с, спрошу: способен ли PostgreSQL реализовать честный master-master и горизонтально масштабироваться добавлением серверов с БД?

    Т.е. есть, скажем, кластер терминалов с серверной частью 1С на каждом + несколько серверов постгреса с мастер-мастер к которым обращаются терминалки?
    • +3
      Покажите, пожалуйста, мне систему, в который сделан и работает честный master-master.
      Это миф. Нету таких. Или практически нету. Или до первого развала кластера или полной остановки при падении одного из узлов.

      Я не специалист в 1С, но вы ТОЧНО уверен, что на терминалах стоит своя версия СУБД и что там мастер-мастер между терминалами и базой?
      Насколько мне известно, база одна, а терминалы и все остальные — клиенты к ней.
      • +3
        Автор статьи рассказывает какая шикарная репликация в PostgreSQL, я спрашиваю как её применять на практике в очень востребованном кейсе.

        Одна БД + пачка терминалов это просто.
        • +3
          Одна БД + пачка терминалов это просто.

          В этом сценарии нету репликации. Есть одна штука база, и к ней куча клиентов.

          Для репликации нужно два сервера с базой данных и репликация между ними.
          • +1
            Спасибо, я знаю что нужно более одного сервера.
            Так как сделать мастер-мастер для 1С на PostgreSQL?

            image

            Если PostgreSQL не умеет так, что он может предложить для масштабирования 1С?
            • +2
              Если PostgreSQL не умеет так, что он может предложить для масштабирования 1С?

              Умеет. Называется BDR — bidirectional replication.
              • 0
                BDR который available for immediate end-user deployment as a small patch on top of PostgreSQL 9.4 plus an extension module?

                В то время как последняя стабильная версия для 1С это 9.2.1?
                • +3
                  Что не мешает использовать PostgreSQL в 1С, немало пользователей.

                  Я немножко не понял ваши возражения — а что, разве MySQL поддерживается 1С?
                  Я именно MySQL с PostgreSQL сравниваю.
                  Для PostgreSQL есть версия 1С, я нигде не утверждал, что она лучше MS SQL сервера — но она существует в природе, она используется.
                  Версии на базе MySQL не существует в природе.

                  Ровно это я хотел сказать, и ровно это и было сказано :)
                • +4
                  Будем говорить прямо: та поддержка PostgreSQL, которая есть на данный момент в 1C, по-сути своей является экспериментальной. То, что она в таком состоянии зависла на много лет – другой вопрос. Но выдам небольшой обнадёживающий инсайд: 1С собирается скоро исправиться в этом плане. Производительность вырастет и геммороя станет значительно меньше.
                  • +1
                    1С наконец то будет работать с родным PgSQL? Или все также только с патченой версии с сайта?
                    • 0
                      С родным, на который установлен 1Совский extension.
                      • 0
                        Яростно плюсую!
                  • 0
                    Они наконец забудут эту тему с case-insensitive?
      • 0
        Поддержу: мультимастер на РСУБД, только если синхронный. Иначе возможна потеря целостности и транзакционности. Ту же транзакционность обеспечивает какой либо GlobalTransactionManager.
        А асинхронный мультимастер на связанных данных — в общем случае просто невозможен (хотя в принципе можно придумать асинхронную мультимастерность путем связного партиционирования связанных данны, но это очень частный случай). И как после брейнсплита востанавливаться после транзакций?
  • +2
    Tungsten — эт что-то не то.

    ! londiste (из skytools) — pgfoundry.org/projects/skytools

    // еще можно slony и bucardo
  • +20
    Из больших преимуществ PostgreSQL лично для меня:

    1. JSONB — позволяет убрать пару сотен каких-то тухлых колонок (в 90% случаев NULL) схлопнув их в одну-две по смыслу и при этом иметь возможность эффективного поиска по ним в случае необходимости (индексы там наложить)
    2. Range Types — никаких больше колонок planned_worktime_start и planned_worktime_end и пляски с операторами сравнения для нахождения других строк, у которых интервал, задаваемый этими колонками пересекается с этой строков. Всё необходимое уже есть (включая constraints, про которые обещали рассказать в соседнем топике).
    3. Прочие нативные типы: interval, cidr и другие, со встроенными методами работы с ними.
    4. Массивы — жуткое нарушение 1-й нормальной формы, но когда всё, что необходимо — это сохранить несколько строчек, то горождение отдельной таблицы с перспективой JOIN'а с ней выглядит совсем непривлекательно.
    5. И самое главное — то, что наш инструмент поддерживает всё это из коробки. А мы работаем на Ruby on Rails. А рельсы ну просто обожают PostgreSQL. JSONB превращается в объект типа Hash, tsrange превращается в объект типа Range с границами в виде объектов DateTime, массив становится массивом. И обратно! Это просто возмутительно прекрасно! MySQL такой любви со стороны разработчиков фреймворка почему-то не испытывает.
    • +10
      + PostGIS
    • +1
      >Массивы — жуткое нарушение 1-й нормальной формы

      Это далеко не всегда так, и Дейт об этом пишет. С первой нормальной формой все не так однозначно. Даже значения-реляции вполне допустимы в реляционной модели, массив лишь их частный случай.
    • 0
      жуткое нарушение 1-й нормальной формы

      И ещё огромный буст к производительности, если использовать GIST индекс.
      т.е. у меня на сайте постоянная задача искать по тегам (есть картинка и у неё до сотен тегов, а картинок под пол-ляма), так вот GIST по array позволяет ускорить поиск в 10-20 раз. Даже если сравнивать не с many-to-many а с одним JOIN (для ускорения, я сначала находил id тегов, и потом уже делал тупо join с промежуточной таблицей).
    • 0
      + ещё на днях познакомился с NOTIFY/LISTEN. Очень прикольная фича, которая может внезапно выручить.
  • +8
    Я тут удивился. Вы правда считаете Microsoft SQL — фантастической СУБД? Можно поинтересоваться в чем она является фантастической?
    • +6
      Например, офигенный оптимизатор: citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.98.9460 богатые типы данных, очень классные интерактивные инструменты анализа производительности, широкая поддержка стандартов

      Microsoft Windows — ужасная платформа, а вот Microsoft SQL Server цены нет.
      • +1
        В плане анализа и оптимизатора, имхо, оракл по-прежнему лидер.
        • 0
          Вы не поверите, в Oracle тот же самый алгоритм — Cascades
          • +1
            Я бы с радостью протестировал высоконагруженный сервер MSSQL и его скопированный с Oracle механизм оптимизатора (который в Oracle, если я ничего не путаю появился лет на 10 раньше) на архитектуре IBM Power или на PC архитектуре под *nix, но к сожалению, не могу этого сделать, потому как MSSQL не предоставляет возможности выбора платформы. А хороших серверов DB на плохих платформах (если брать вашу оценку) не бывает, по определению.
      • +2
        Но в итоге, эта связка очень медленная. Вот если бы MS SQL работал не только на Windows тогда бы можно было бы не перекладывать «особенности» Windows на MS SQL, а так это жутко.
  • +4
    Можно я замолвлю слово о MySQL?

    Подключаемые системы хранения данных — это прекрасно. Вот скажем нужно мне запихнуть в базу терабайт-другой логов. Активируем TokuDB, импортируем данные — и опа, вместо терабайта у нас 100 гигабайт занятого дискового пространства и возможность выполнять простенькие SQL запросы… ну скажем не более чем за минуту. И всё это — без танцев с бубнами вокруг Hadoop-шмадуп, Spark-шмарк.

    Или вот работает у меня сайт на Друпале… и пришли ко мне органы… и сказали мне органы: «Да хранить тебе логи доступа в табличке accesslog в течение 3 лет». И прикинул я, что три года по гигабайту на месяц — это Терабайтище. Но ведь accesslog работает только на запись, так что выполнил я команду ALTER TABLE accesslog ENGINE=ARCHIVE и вскинул под козырёк: «Будетъ сдѣлано!»
    • +3
      wiki.postgresql.org/wiki/Foreign_data_wrappers
      wiki.postgresql.org/wiki/Foreign_data_wrappers#Tycoon_FDW

      и
      !!! отличный пример как всё расширяется: multicorn.org/
      • 0
        Ну я ж просил без геморроя ;-)
        • +2
          А где геморрой то тут? )
    • 0
      а теперь попробуйте не простенькие запросы :) для аналитики mysql и postgresql, например, слабо подходят
      • 0
        А если учесть наличие оконных функций?
        • +1
          На больших объемах (больше 1Тб) уже не помогает. Мы после постгри перешли на hp vertica.
    • 0
      А потом захотел сделать выборку по индексу из двух полей (например код ответа и дата, которые используется для сортировки) — а хрен там, Archive такое не поддерживает, приходится ставить индекс только на одно поле (код ответа) и получать почти full scan.
  • +7
    Я помню лет 10 назад в MySQL появилась первая репликация. Сделана она была через пересылку SQL запроса на соседний сервер. После этого я забыл про MySQL.
    10 лет прошло, а я смотрю ничего и не изменилось.
  • +5
    Я понял, какой правильный ответ на твой пост, Олег :). А ответ такой: ждем такого же поста с разжевыванием недостатков PostgreSQL через несколько лет :).

    Ибо MySQL пользуются почти все и его недостатки хорошо изучены и известны. А PostgreSQL ты даже сам особо не пробовал, так что твои рассуждения — это какая-то теория, без применения к практике.
    • +1
      Сообщение в ключе «я не хочу слезать со своей отсталой технологии», извиняюсб, не сдержался
      • +3
        Не могу согласиться с утверждением, что MySQL «отсталая технология» по сравнению с продуктом X (не важно, что сюда подставлять, PostgreSQL, Tarantool, etc...). У MySQL есть своя ниша — «в идеале» это веб-сервера. То есть, MySQL очень прост в настройки и неприхотлив в эксплуатации, и умеет примерно ничего сверхсложного, зато умеет это быстро и достаточно надежно при условии использования InnoDB. В основном MySQL заточен на максимальную производительность простых запросов и в меньшей степени на то, чтобы эффективно исполнять запросы сложные. То, что Олег вообще использует statement-based однопоточную репликацию в мускуле и она еле справляется — это скорее проблема неверно выбранного инструмента именно для этой задачи.
        • +1
          В основном MySQL заточен на максимальную производительность простых запросов и в меньшей степени на то, чтобы эффективно исполнять запросы сложные

          Ну а что такое простые запросы? Селект по праймари кею, т.е. мускуль с иннодиби умеет это делать значительно лучше не только постгреса (что не очень важно), но и редиса и т.д.?

          Иначе, какой смысл использовать продукт А, ежели он обрезанная версия продукта Б, за те же деньги?
          • +2
            Часто бывает важно в вебе:

            1) дешевый коннект
            2) запросы по PK как на SQL, так и на HandlerSocket-слоях очень быстрые
            3) запросы с выборкой по индексу с лимитом и ордер бай
            4) простенькие группировки по индексированным полям

            Иногда бывает полезно:
            1) очень быстрый фулл скан таблиц (MyISAM), с возможностью писать/читать напрямую в дата-файлы, что дает еще 5-ти кратный прирост скорости (таблица на 1 млн строк и размером 30 Мб сканируется за 15 мс)
            2) очень компактное хранение данных в MyISAM и надежное при условии append-only

            Примеров больше, но это вроде бы основное :)
            • +5
              Есть ощущение что вы используете реляционную субд как любой другой nosql K-V.

              В статье как раз мнение, что постгрес это нечто интересней и сложней.
              • 0
                У меня из статьи и комментариев сложилось ощущение, что использовать реляционную субд как nosql K-V — это:
                1. нередко актуально
                2. одна из тех областей, где MySQL выглядит наиболее выигрышно на фоне PostgreSQL

                А так — да, PostgreSQL интересней и сложней.
                • 0
                  Key-Value, где вы его увидели в MySQL?
                  • 0
                    InnoDB — изначально K-V, а всё остальное уже поверх.
                    Есть несколько реализаций NoSQL протокола для InnoDB, позволяющие добиться повышения производительности на порядок за счёт существенного урезания функциональности.

                    • +1
                      Но смысл ведь не во внутренней структуре, а в коробочном наборе инструментов, которые доступны разработчику.
                      • 0
                        Смысл именно во внутренней структуре, поскольку иначе — хороших результатов не добиться никакими инструментами, доступными разработчику. А если разработчику связать руки, то можно долго вздыхать, что дело не делается.
            • +1
              1) дешевый коннект

              Проблема PHP который «должен умирать». С другими языками таки проблем нету, так как коннекты не закрываются.

              очень быстрый фулл скан таблиц

              Postgres вполне можно настроить на это (он адаптируется в зависимости от задачи).

              очень компактное хранение данных

              В posttgres так же всё достаточно компактно, а главное нету проблемы с «append-only». :)
              • 0
                1. Ну и pgbouncer ещё же есть
                • 0
                  Много чего есть, тот же pgpool. Но это надо отдельно подымать.
                  • 0
                    Ну т.е. претензия только в том, что сама постгря не предоставляет это из коробки, а не в том, что решения не существует.
                    • 0
                      Главное решение, это не использовать PHP. :)
    • +3
      С удовольствием!
      Прогресс — непрерывное поступательное движение вперёд.

      И да, опыт использования для мелких проектов есть, функциональную часть я имел возможность оценить
      Касательно нагруженных проектов — пока опыта нет, к сожалению, но надеюсь, что скоро приобрету :)
      • 0
        Касательно нагруженных проектов — пока опыта нет, к сожалению, но надеюсь, что скоро приобрету

        Тогда самое интересное у вас еще впереди :)
  • +3
    Не совсем согласен с автором по поводу пункта «Документация». Точнее как — быть может документация на сайте MySQL и правда уступает документации PostgreSQL (хотя это весьма спорное утверждение), но вот в принципе в интернетах информационных ресурсов по MySQL в десятки раз больше чем по PostgreSQL. Взять хотя бы stackoverflow — 298,085 тредов против 35,063.

    Ещё не указан один из весомейших на мой взгляд плюсов PostgreSQL — это PL/SQL. В MySQL-е с этим все очень и очень плохо, и сами разработчики не стесняются признаваться в этом. К этому же пункту можно отнести специализированные геоиндексы, JSONB и т.п.

    И отсюда по-моему не совсем правильный вывод в финале статьи. Я бы сказал так — если вы точно, знаете, что собираетесь использовать все эти специализированные фичи (в особенности PL/SQL), то выбор в пользу PostgreSQL — однозначен. В остальных случаях — выбор в пользу того, с какой из БД больше всего знакома команда. И про «серьезные амбиции» и «большой проект» — считаю вообще не аргумент. Опыт таких гигантов как Google, Facebook, VK, twitter, badoo показал, что на MySQL можно более чем успешно разрабатывать вполне себе «большие проекты».

    P.S. К слову, коль в статье была упомянута percona с их собственными тулами, то помимо их решений так же есть весьма неплохие патчи от Google code.google.com/p/google-mysql/.
    • +5
      Взять хотя бы stackoverflow — 298,085 тредов против 35,063.
      Мне кажется это не показатель. Во всяком случае не однозначный показатель со смыслом «больше — лучше».

      Сравнение количества вопросов по двум технологиям А (по которой вопросов больше) и Б (по которой вопросов меньше) на SO всегда можно обосновать кучей противоречивых причин:
      1) А просто популярнее Б и имеет большее комьюнити
      2) У А более активное и дружественное комьюнити
      3) У А плохая документация
      4) В А гораздо проще сделать неочевидную ошибку, которая требует помощи извне
      5) У Б комьюнити и более опытных разработчиков, которые лучше умеют самостоятельно решить проблему (на основе документации, кода, опыта) и потому не задают простых вопросов
      6) Официальные ресурсы А предлагают задавать вопросы именно на SO (а не, например, форуме технологии А)


      В общем, вариантов много, а правды нет )
    • +2
      Опыт таких гигантов как Google, Facebook, VK, twitter, badoo показал, что на MySQL можно более чем успешно разрабатывать вполне себе «большие проекты».

      Построить можно, но насколько это удобно? Почти все эти гиганты перепиливали mysql в доль и поперёк. VK так вообще очень специфично MySQL использует. А стали они юзать mysql так как в тот момент это было достаточно хорошее свободное решение, а у postgres было много болячек и недостатков. С начала 2000x много всего поменялось.
    • +3
      Гиганты, в своей области, правы. Все красивости PostgreSQL «из коробки» типа репликации и транзакций для них только минус: всё равно а) работают, и всегда будут работать, несколько не так как они хотят, и б) у них есть ресурсы чтоб реализовать то, что им надо из этого списка, самим. Поэтому берут InnoDB (в виде MySQL) и «обвешивают» сами чем им надо. Да, несколько напоминает «фатальный недостаток: not invented here», но тут это, по-моему, как раз из серии «гиганты могут себе позволить».
  • +1
    Ох, еще бы pgAdmin (особенно под никсы) был таким же прекрасным как сам Постгрес :)
    • +1
      А в чём проблема?
      Исходники есть. В популярных дистрибутивах идёт в репозиториях.
      К примеру, Archlinux:

      [desktop] ~ $ yaourt -Si pgadmin3
      Репозиторий           : community
      Название              : pgadmin3
      Версия                : 1.20.0-1
      Описание              : Comprehensive design and management interface for PostgreSQL
      Архитектура           : x86_64
      URL                   : http://www.pgadmin.org
      Лицензии              : custom
      Группы                : Нет
      Предоставляет         : Нет
      Зависит от            : wxgtk2.8  postgresql-libs  libxslt
      Дополнительно         : Нет
      Конфликтует с         : Нет
      Заменяет              : Нет
      Будет загружено :   2,82 MiB
      Установленный размер:  13,63 MiB
      Сборщик               : Sergej Pupykin <pupykin.s+arch@gmail.com>
      Дата сборки           : Чт 25 дек 2014 20:49:50
      Проверен : MD5  SHA256  Подпись
      

    • +3
      Не сочтите за рекламу, но 0xDBE наше все :)
    • 0
      Ну, в целом он весьма неплох и на *nix и на OS X. Ему бы GUI только немного причесать, по моему мнению. А что вас не устраивает?
    • +1
      О да, про него разработчики постоянно забывают.
      Ох эти мерцания диалоговых окон…
      Кстати, во многом именно из-за pgAdmin, PostgreSQL воспринимается как динозавр
  • 0
    Оффтоп-вопрос пользователеям PostgreSQL.

    Какое-то время назад смотрели возможность настроить Master-Slave репликацию, что бы с каких-то Slave'ов можно было в realtime производить чтения и тем самым разгрузить master'a. После чтения документации остановились на потоковой репликации
    ( www.postgresql.org/docs/9.1/static/warm-standby.html#STREAMING-REPLICATION )

    Может быть выбор не самый лучший и можете посоветовать что-либо более подходящее для read-only slave'ов в PostgreSQL?
  • +1
    А нет ощущения, что MySQL вы широко используете в продакшене, и поэтому на его грабли натыкаетесь постоянно, а PostgreSQL — нет, и поэтому его грабли вы просто еще не знаете?
    • 0
      Ну, коллеги в мыле используют, с ними постоянно общаемся.
      У PostgreSQL проблемы есть, но они не в генетике, как у MySQL
    • 0
      Я использую и то и то. Поверьте это не так. Что-то сложное делать на MySQL упаси боже. Начинаются такие танцы с бубном…
  • 0
    Подскажите существует ли в PostgreSQL или MySQL репликация уровня датацентров?

    Когда я 4-ре года назад пробовал MySQL Мастер-Мультимастер репликацию, то это всё были с подводными камнями.

    Конечно было бы интересно, что бы реплицировались данные не полностью на все сервера. Например есть 4-е датацентра и по 5-ть серверов в каждом. Желательно, что бы данные были на 2-х серверах (там где была запись) и на хотябы на одном в двух других датацентрах.
    Если датацентр упал, то он сам отключается (split brain). А на других будет самостоятельно репликация запускаться, что бы данные были на 3-х независимых серверах.
    • 0
      Мультимастер плохо сочетается с реалиционной моделью. Более менее нормальный мультимастер возможен в key-value хранилищах, т.е. лучше Redis я пока ничего не видел. В остальных случаях это либо псевдо мультимастер либо куча минусов.

      То что вы описали, походит на псевдо мультмастер и его вполне можно сделать (и мы на одной из работ делали) через pg slony.
    • +1
      Коробочные решения есть для MySQL, но в виде отдельных продуктов. Mature third-party: www.continuent.com/, galeracluster.com/products/ Достаточно молодой от Oracle: www.mysql.com/products/enterprise/fabric.html И ещё вот: mysqlhighavailability.com/5-7-5-labs-multi-source-replication/ И руками ещё люди делают.

      Про подводные камни, точнее про то, как всё сделать и камней не задеть, есть хорошая книжка «MySQL High Availability».
  • 0
    Про администрирование не правда. Когда проект более менее мускл надо тюнить и постгрес тоже, При той же настройке репликации. К сожалению, прочитав статью, сложно сказать, что объективное сравнение и раскрыты все стороны обоих БД. Сам больше знаком с мускл, сейчас работаю с постгрес, Сам пытаюсь сравнить и понять, какую БД я использовал бы в следующем проекте с нуля, пока ответа нет (Опустим моменты с PostGIS и специализированными штуками, когда ответ очевиден)
    • 0
      Наличие hstore, arrays, json в 90% делает ответ простым. Сейчас почти в любом мало мальском проекте это будут полезные штуки. Ну и без PostGIS в Postgres есть типы point и gist индексы по ним (с быстрым поиском ближайшего и прочего).
  • –1
    > Асинхронная репликация без цензуры, или почему PostgreSQL завоюет мир
    > Прошло более 10 лет, и что мы видим?
    Прошло более 10 лет, и мы видим, что большинство сайтов работает на мускуле, а постгр — удел хипстеров от программирования…
    • +5
      Потому что для большинства сайтов хватает и мускуля, а когда приходит время программировать — его хватать перестаёт.
    • 0
      Большинство хостеров поддерживают PHP+MySQL. Поэтому большинство сайтов на них и работает.
  • +2
    Спасибо за интересную статью! Есть еще весьма существенные различия по функционалу между PostgreSQL и MySQL, не отмеченные выше — также не в пользу MySQL.

    У PostgreSQL есть некоторые свои нюансы, например, если нужно много UPSERT/MERGE, придется написать свой генератор кода хранимых процедур. Или использовать в качестве такого генератора руки. Но в общем и целом, все это несущественные неудобства, с которыми вполне можно жить.
  • +2
    Я просто оставлю это здесь.
    • +2
      Это чудесно :)

      Redis и MongoDB не нужны, потому что Постгрес проще, удобнее и быстрее. Если бы Ruby был написан на хранимках в Постгресе, он работал бы в три раза быстрее и не падал. Ноду пришлось писать на V8, потому что джаваскриптеры не поняли лицензию Постгреса, а Erlang появился, потому что кто-то просто не умеет пользоваться триггерами и хранимками. K&R после создания C пришлось писать UNIX, потому что они хотели, конечно, написать Постгрес, но ему было не на чем запускаться. C++0X появился только для того, чтобы умные люди перестали писать на C и перешли на Постгрес. Разработка файловых систем нового поколения часто тормозится (особенно ZFS), потому что люди понимают, что с какой стороны не подходи и что не делай, а из-за требований нормальной транзакционности все равно получается Постгрес! Сам Постгрес написан на хранимках Постгреса, мейкфайл выполнен в виде дампа Постгреса, и собирается Постгрес Постгресом.
  • +2
    Странно написано. Ничуть не выгораживаю PG. Скажем так: в определенной специфике его использования я знаю как оно работает в итоге лучше разработчиков ;), а с MySQL знаком довольно таки поверхностно. Но уж прямо какой то откровенный наезд на MySQL.
    По мне так ничем они друг от друга не отличаются. Ни каких вот прямо технологических прорывов ни у того ни у другого нет. Да где то одно реализовано лучше «master-slave репликация» или например in-memory движок хранения. Где то хуже, например SELECT count(*) FROM large_table.

    По мне так основное отличае в том что MySQL более «прогрессивные» ребята: вм нужен Update OR Insert? Щас мы забацаем вам UPSERT и пофиг что нет такого пока в SQL стандартах. Правда при смене релизов такая «проактивность» иногда выходит боком.

    Ребята из PG более консервативны, следуют стандартам языка, то что MySQL «наговнокодят» за месяц и выкатят новую фичу, тут будут писать пару тройку лет с кучей ревью и переписок в почте, это даже тупо по количеству версий видно.

    Хорошо это или плохо зависит от вашего проекта. Если у вас небольшой сайтик то наверное плохо, нужную вам фичу вы будете ждать годами, прикручивать велосипеды. Таже самая хваленая репликация выросла из откровенного костыля, ну и на мой взгляд, до сих пор выглядит как нечто инородное.
    А если у вас БД на пару десятков терр, хитровывернутые клиенты, оптимизированные до уровня эксплуатации особенностей реализации, и сама процедура обновления даже хотфиксного билда превращается в эпопею сроком на несколько месяцев, то консервативность именно, то что вам нужно.
    • 0
      Описание недостатков MySQL напоминает описание недостатков PHP: там что-то сбоку прилепили, тут что-то впилили, здесь фичу вставили, о целостности и «канонiчности» не заботятся почти совсем. В итоге, чтоб понять как оно устроено и как работает, нужно «пофичурно» знать когда и зачем что делали. Но для тех, кто любит, — это не препятствие;-)

      Кроме того, ну имеем мы «наготу InnoDB, частично прикрытую стандартом SQL92». С ростом актуальности для некоторых вопроса «а зачем нам в проекте нужна именно реляционная БД с репликацией и транзакциями из коробки» им всё больше требуется не столько SQL, сколько InnoDB.

      Получаем, что «сферический» Postgres лучше всего подходит, как некоторые скажут, «для прототипирования» — для случаев, когда нагрузка не важна, а когда дело доходит до highload'а и от проекта уже точно ясно что хотят, и есть людские ресурсы, то неплохо бы переделать всё под InnoDB потому что в InnoDB «нет ничего лишнего», а чего недостаёт, можно дописать самим. Другое дело, что далеко не каждый проект доходит до стадии highload'а.
      • +2
        Насчет highload не соглашусь. Highload для всех разный. У кого-то это база несколько десятков гиг и 100500 запросов клиентов в секунду. Или пару тысяч клиентов, но каждый должен быть отработан за миллисекунду.

        Бывает Хайлоад и когда клиентов мало и база не шибко большая, вот только запросы с листингом на пару страниц текста с парой тройкой JOIN между таблицами фактов.

        А бывает Highload когда клиентов пару десятков, но сама база террабайты. Где нельзя просто накатить хотфикс, потому что в случае чего даже восстановление недельного снапшота займет день-другой. Тут уже не прокатит «накатить фикс минорный» или «быстро запдейтить базейку, так как вместе с очень ожидаемым вами бакфиксом мы еще пару совсем не опасных фич прикрутили».

        Так что «сферический» это только если с дефолтовыми настройками. У нас слон работает на очень тяжелом Highload c «мультимастером на пару десятков терр.

        Лично мое мнение такое — что выбирать разница не большая. Если все, кроме нагрузки вас в вашем PostgreSQL или MySQL устраивает. Если все советы из серии „20 способов увеличить производительность PostgreSQL / MySQL“ вы выполнили, то не имеет смысл смотреть в сторону оппонента, скорее используемая вашим приложением схема работы с реляционной БД неправильная или вообще вам не подходит реляционная модель, и стоит обратить внимание на модные NoSQL.
  • 0
    К сожалению, сжатие данных у Postgresql проигрывает TokuDB.
    TokuDB экономит кучу места на SSD, от него не уйти.
  • –1
    Еще одним преимуществом MySQL перед PostgreSQL является возможность использовать «REPLACE INTO».
    • +2
      REPLACE зло — он пытается сделать DELETE для существующей записи
  • 0
    Выставить выбор engines (которые как раз прекрасно выбираются «под задачу») как минус — это честно говоря несколько неожиданно.

    Упомянутый Tungsten — я правильно понимаю, что имеется в виду 3d party программа tungsten replicator? Не, она прекрасна что бы гонять данные из одной базы в другую онлайн. Но выставлять ее как фишку Postgre — несколько странно.

    Вообще вопросов к статье довольно много, даже куда больше, чем имеет смысл задавать. Тема избитая, холиварная, но в данном случае поданная однобоко.
  • 0
    Для меня БД не цель, а средство, но были проблемы:

    PostreSQL уже научился синхронизировать две базы, доступные для записи? Или по-прежнему только в одну можно писать, из прочих только читать?

    > PostgreSQL соответствует стандартам SQL-92, SQL-98, SQL-2003 (реализованы все его разумные части) и уже работает над SQL-2011. Это очень круто.

    И какой из них предписывает использовать «bytea» вместо «BLOB»? ;)
    • 0
      > PostreSQL уже научился синхронизировать две базы, доступные для записи?

      Не поверите: 2ndquadrant.com/en/resources/bdr

      И bytea не синоним BLOB.
      • +1
        > Не поверите: 2ndquadrant.com/en/resources/bdr

        Не верю: BDR has been developed by 2ndQuadrant, is open source and fully supported for 2ndQuadrant Support customers

        Это о какой версии Postgresql тут речь?

        > И bytea не синоним BLOB.

        Так как же называется BLOB в Postgresql? И по какому из SQL-92, SQL-98, SQL-2003 или SQL-2011 это так?
  • 0
    Я не являюсь экспертом по РСУБД (по ходу работы приходилось использовать и MySQL, и Postgres, и Oracle, но без особо глубокого погружения), поэтому мое мнение можно не принимать во внимание. Однако поделюсь. :)
    1) MySQL не нужен.
    2) PostgreSQL наступает на пятки «взрослому» Oracle, целый ряд задач для которых лет 10 назад у Oracle не было альтернатив, сегодня очень хорошо можно решать с помощью Postgres. На одном из оракловых проектов на предыдущем месте работы интенсивно использовались DBLINK-и — полезная штука, было бы очень круто, если бы Postgres таким тоже обзавелся (или он уже?.. я давно не интересовался вопросом).
    3) Oracle конечно монстр, но от него жутко пахнет нафталином. В частности, язык хранимых процедур PL/SQL — «привет из 60-х». :)
    • +2
      • 0
        Спасибо!
    • 0
      PL/SQL в определенных ситуациях позволяет нереально оптимизировать работу с данными
    • +1
      Окститесь, молодой человек.
      Pl/sql может все что надо и не надо. Я не знаю СУБД которые без привлечения внешки чисто на своём ядре могли бы такое вытворять, а до синтаксиса докапываться это уже даже не знаю как обозвать. В общем нехорошо такие вещи писать.
  • +1
    zabivator Почему не добавили опрос?
  • 0
    peter.eisentraut.org/blog/2015/03/03/the-history-of-replication-in-postgresql/

    немного истории для обобщения и введения в дальнейшее рассмотрение
  • +1
    Полностью поддерживаю автора данной статьи. Я сейчас MySQL забыл как страшный сон(ну не совсем забыл поддерживать приходится:)). В свое время был биллинг на нем, со включенным аккаутингом просто все валилось при 2500 пользователей онлайн. Что только не пытались предпринять, какие оптимизации только не делали. Конечно существуют проекты типа UTM5, но там сам биллинг выполняет роль базы иначе все бы это полегло.
    Сейчас даже для самых маленьких проектов использую только Postgres и чем дольше пользуюсь тем больше его начинаю любить. :).

    Честно скажу даже не думал что возникают какие то сложности при переходе. В смысле моральных причин. Я просто взял и начал работать с Postgres-ом, для себя сказал — «это просто другая СУБД».

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.

Самое читаемое Разработка