Mysql vs postgresql vs: Сравнение MySQL и PostgreSQL

Содержание

Сравнение MySQL и PostgreSQL | Losst

Реляционные базы данных использовались на протяжении длительного времени. Они стали популярными благодаря системам управления, которые реализуют реляционную модель настолько хорошо, что она является наилучшим способом работы с данными, особенно для критически важных приложений и служб.

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

Содержание статьи:

Системы управления базами данных

Базы данных предназначены для структурированного хранения и быстрого доступа к различным данным. Каждая база данных, кроме самих данных, должна иметь определенную модель работы, по которой будет выполняться обработка данных. Для управления базами данных используются СУБД или системы управления базами данных, именно к таким программам относятся MySQL и Postgresql.

Реляционные системы управления базами данных позволяют размещать данные в таблицах, связывая строки из разных таблиц и, таким образом, связывая разные, объединенные логически данные. Перед тем, как вы сможете сохранять данные, необходимо создать таблицы определенного размера и указать тип данных для каждого столбца. Столбы представляют поля данных, а сами данные размещены в строках. Обе системы управления базами данных, и MySQL vs Postgresql принадлежат к реляционным. Дальше мы рассмотрим подробнее чем отличаются обе программы. А теперь перейдем к более детальному рассмотрению.

Краткая история

MySQL

Разработка MySQL началась еще в 90х годах. Первый внутренний выпуск базы данных состоялся в 1995 году. За это время разработкой программы занимались несколько компаний. Разработка была начата шведской компанией MySQL AB, которую приобрела Sun Microsystems, которая, собственно перешла в собственность Oracle. На данный момент, начиная с 2010 года, разработкой занимается Oracle.

Postgresql

Разработка Postrgresql началась в далеком 1986 году в стенах Калифорнийского университета Беркли. Разработка длилась почти восемь лет, затем проект разделился на две части коммерческую базу данных IIlustra и полностью свободный проект Postrgesql, который разрабатывается энтузиастами.

Хранение данных

MySQL

MySQL — это реляционная база данных, для хранения данных в таблицах используются различные движки, но работа с движками спрятана в самой системе. На синтаксис запросов и их выполнение движок не влияет. Поддерживаются такие основные движки MyISAM, InnoDB, MEMORY, Berkeley DB. Они отличаются между собой способом записи данных на диск, а также методами считывания.

Postgresql

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

Стандарт SQL

Независимо от используемой системы управления базами данных, SQL — это стандартизированный язык выполнения запросов. И он поддерживается всеми решениями, даже MySQL или Postgresql. Стандарт SQL был разработан в 1986 году и за это время уже вышло нескольких версий.

MySQL

MySQL поддерживает далеко не все новые возможности стандарта SQL. Разработчики выбрали именно этот путь развития, чтобы сохранить MySQL простым для использования. Компания пытается соответствовать стандартам, но не в ущерб простоте. Если какая-то возможность может улучшить удобство, то разработчики могут реализовать ее в виде своего расширения не обращая внимания на стандарт.

Postgresql

Postgresql — это проект с открытым исходным кодом, он разрабатывается командой энтузиастов, и разработчики пытаются максимально соответствовать стандарту SQL и реализуют все самые новые стандарты. Но все это приводит к ущербу простоты. Postgresql очень сложный и из-за этого он не настолько популярен как MySQL.

Возможности обработки

Из предыдущего пункта выплывают и другие отличия postgresql от mysql, это возможности обработки данных и ограничения. Естественно, соответствие более новым стандартам дает более новые возможности.

MySQL

При выполнении запроса MySQL загружает весь ответ сервера в память клиента, при больших объемах данных это может быть не совсем удобно. В основном по функциям Postgresql превосходит Mysql, дальше рассмотрим в каких именно.

Postgresql

Postgresql поддерживает использование курсоров для перемещения по полученным данным. Вы получаете только указатель, весь ответ хранится в памяти сервера баз данных. Этот указатель можно сохранять между сеансами. Здесь поддерживается построение индексов сразу для нескольких столбцов таблицы. Кроме того, индексы могут быть различных типов, кроме hash и b-tree доступны GiST и SP-GiST для работы с городами, GIN для поиска по тексту, BRIN и Bloom.

Postgresql поддерживает регулярные выражения в запросах, рекурсивных запросов и наследования таблиц. Но тут есть несколько ограничений, например, вы можете добавить новое поле только в конец таблицы.

Производительность

Базы данных должны обязательно быть оптимизированы для окружения, в котором вы будете работать. Исторически так сложилось что MySQL ориентировалась на максимальную производительность, а Postgresql разрабатывалась как база данных с большим количеством настроек и максимально соответствующую стандарту. Но со временем Postgresql получил много улучшений и оптимизаций.

MySQL

В большинстве случаев для организации работы с базой данных в MySQL используется таблица InnoDB, эта таблица представляет из себя B-дерево с индексами. Индексы позволяют очень быстро получить данные из диска, и для этого будет нужно меньше дисковых операций. Но сканирование дерева требует нахождения двух индексов, а это уже медленно. Все это значит что MySQL будет быстрее Postgresql только при использовании первичного ключа.

Postgresql

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

В целом PostgreSQL работает быстрее, за исключениям использования первичных ключей. Давайте рассмотрим несколько тестов с различными операциями:

Типы данных

Один из основных моментов обоих баз данных это поддерживаемые типы данных, которые вы можете использовать. Поскольку оба решения пытаются соответствовать синтаксису SQL, то они имеют похожие наборы, но все же кое-чем отличаются.

MySQL

MySQL поддерживает такие типы данных:

TINYINT: очень маленькое целое.;
SMALLINT: маленькое целое;
MEDIUMINT: целое среднего размера;
INT: целое нормального размера;
BIGINT: большое целое;
FLOAT: знаковое число с плавающей запятой одинарной точности;
DOUBLE, DOUBLE PRECISION, REAL: знаковое число с плавающей запятой двойной точности
DECIMAL, NUMERIC: знаковое число с плавающей запятой;
DATE: дата;
DATETIME: комбинация даты и времени;
TIMESTAMP: отметка времени;
TIME: время;
YEAR: год в формате YY или YYYY;
CHAR: строка фиксированного размера, дополняемая справа пробелами до максимальной длины;
VARCHAR: строка переменной длины;
TINYBLOB, TINYTEXT: двоичные или текстовые данные максимальной длиной 255 символов;
BLOB, TEXT: двоичные или текстовые данные максимальной длиной 65535 символов;
MEDIUMBLOB, MEDIUMTEXT: текст или двоичные данные;
LONGBLOB, LONGTEXT: текст или двоичные максимальной данные длиной 4294967295 символов;
ENUM: перечисление;
SET: множества.

Postgresql

Поддерживаемые типы полей в Postgresql достаточно сильно отличаются, но позволяют записывать точно те же данные:

bigint: знаковое 8-байтовое целое;
bigserial: автоматически увеличиваемое 8-байтовое целое;
bit: двоичная строка фиксированной длины;
bit varying: двоичная строка переменной длины;
boolean: флаг;
box: прямоугольник на плоскости;
byte: бинарные данные;
character varying: строка символов фиксированной длины;
character: строка символов переменной длины;
cidr: сетевой адрес IPv4 или IPv6;
circle: круг на плоскости;
date: дата в календаре;
double precision: число с плавающей запятой двойной точности;
inet: адрес интернет IPv4 или IPv6;
integer: знаковое 4-байтное целое число;
interval: временной промежуток;
line: бесконечная прямая на плоскости;
lseg: отрезок на плоскости;
macaddr: MAC-адрес;
money: денежная величина;
path: геометрический путь на плоскости;
point: геометрическая точка на плоскости;
polygon: многоугольник на плоскости;
real: число с плавающей точкой одинарной точности;
smallint: двухбайтовое целое число;
serial: автоматически увеличиваемое четырехбитное целое число;
text: строка символов переменной длины;
time: время суток;
timestamp: дата и время;
tsquery: запрос текстового поиска;
tsvector: документ текстового поиска;
uuid: уникальный идентификатор;
xml: XML-данные.

Как видите, типов данных в Postgresql больше и они более разнообразны, есть свои типы полей для определенных видов данных, которых нет MySQL. Отличие MySQL от Postgresql очевидно.

Разработка

Оба проекта имеют открытый исходный код, но развиваются по-разному. Развитие MySQL нравится далеко не всем. И в этом сравнение mysql и postgresql дает много отличий.

MySQL

База данных MySQL разрабатывается компанией Oracle и ходят слухи, что компания намерено тормозит развитие движка. Было создано очень много форков проекта, в том числе форк MariaDB от разработчика оригинальной MySQL. Но все же развитие остается медленным.

Postgresql

Как было сказано в начале статьи разработка началась в университете Беркли. Затем перешла в коммерческую компанию. Сейчас программа разрабатывается независимой группой программистов и советом нескольких компаний. Новые версии выпускаются достаточно активно и получают все новые и новые функции.

Выводы

В этой статье мы выполнили сравнение mysql и postgresql, рассмотрели основные отличия обоих систем управления базами данных и попытались понять что лучше postgresql или mysql. В общем результате лучшим по возможностях получается Postgresql, но он сложен и не везде его можно применять. MySQL проще, но не поддерживает некоторых интересных функций. А какую базу данных вы выберите для своего проекта? Почему именно ее? Напишите в комментариях!

На завершение видео с описанием возможностей и перспектив Postgresql:

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. Даже из коробки он у вас будет работать, поможет в разработке, сэкономит время, и вам проще будет расти.
MySQL против PostgreSQL | PostgreSQL
Меня часто спрашивают, «Что вы предпочитаете, PostgreSQL или MySQL?» Мой ответ всегда один и тот же: «Это – вопрос предпочтения». Вы можете задать множеству других разработчиков тот же самый вопрос, и их ответы будут весьма различного толка.
Вот – сравнение баз данных MySQL и PostgreSQL, предлагаемое не ради высказывания моего мнения, а ради того, чтобы помочь другим принять собственное решение. Обеим системам есть что предложить в вопросах стабильности, гибкости и производительности. MySQL имеет особенности, в которых PostgreSQL испытывает недостаток, и наоборот.
Моя первичная задача – помочь решить, какая из этих двух баз данных будет использоваться в ваших собственных разработках. Прежде, чем начать сравнение этих баз данных, я должен прояснить, что буду придерживаться заданных по умолчанию инсталляций. MySQL имеет много различных типов таблиц, которые поддерживают транзакации и внешние ключи.
Однако, некоторые из конфигураций этих типов таблиц весьма сложны. Не многие разработчики сети или программисты используют дополнительные типы таблиц, существующие в MySQL. А теперь давайте сравним эти два продукта.
В таблице А приведено сравнение наиболее употребимых особенностей и возможностей баз данных MySQL и PostgreSQL.
Таблица А – это не исчерпывающий список особенностей, типов данных или проблем производительности, касающийся этих двух систем баз данных – она лишь дает некоторое представление о том, что каждая из них может предложить.
Из таблицы мы видим, что PostgreSQL предлагает полные особенности и возможности традиционных приложений баз данных, в то время как MySQL сосредотачивается на более быстром выполнении (работе) для веб приложений. Развитие индустрии «открытых исходников» принесет большее количество особенностей и возможностей в последующих версиях обеих баз данных.
Таблица A: сравнение MySQL и PostgreSQL
Особенности PostgreSQL MySQL
ANSI SQL совместимость Близка к стандарту ANSI SQL Следует некоторым стандартам ANSI SQL
Скорость работы Медленнее Быстрее
Вложенные селекты Да Нет
Транзакации Да Да, однако должен использоваться тип таблицы InnoDB
Ответ базы данных Да Да
Поддержка внешних ключей Да Нет
Представления Да Нет
Хранимые процедуры Да Нет
Триггеры Да Нет
Unions Да Нет
Полные Joins Да Нет
Ограничители целостности Да Нет
Поддержка Windows Да Да
Вакуум (очистка) Да Нет
ODBC Да Да
JDBC Да Да
Различные типы таблиц Нет Да
Почему бы вы предпочли MySQL, нежели PostgreSQL? Сначала, мы должны рассмотреть потребности приложений в терминах требований базы данных. Если я хочу создать веб приложение, и главное для меня это производительность и скорость – MySQL будет лучшим выбором, потому что она быстра и разработана для того, чтобы хорошо работать с веб серверами.
Однако, если я хочу создать другое приложение, которое требует выполнения транзакаций и наличия внешних ключей, лучшим выбором станет PostgreSQL. Даже при том, что MySQL не полностью совместима с ANSI SQL стандартом, я должен упомянуть, что, в то время как PostgreSQL ближе к ANSI SQL стандарту, MySQL ближе к ODBC стандарту.
Позвольте мне описать некоторые плюсы использования MySQL:
MySQL относительно быстрее PostgreSQL.
Дизайн и планирование базы данных несколько проще.
Можно создать простой веб сайт с использованием базы.
Ответы на запросы MySQL были хорошо протестированны.
Нет нужды использовать методы очистки (вакуум).
Не много веб-разработчиков используют в своей работе PostgreSQL, так как считают, что дополнительные особенности и возможности снижают производительность и скорость работы. Однако, PostgreSQL имеет много преимуществ над MySQL. Например, некоторые из особенностей, которые часто используются – внешние ключи, триггеры и представления. Они позволяют скрывать сложность базы данных от приложения, таким образом избегая создания сложных команд SQL.
Cуществует немало разработчиков, которые предпочитают богатые функциональные возможности SQL команд PostgreSQL. Одно из наиболее ощутимых различий между MySQL и PostgreSQL – невозможность создания вложенных подзапросов (селектов) в MySQL. PostgreSQL соответствует многими SQL стандартам ANSI, таким образом позволяя создание сложных команд SQL.
Несколько причин использовать PostgreSQL:
Сложный дизайн базы данных.
Переезд с Oracle, Sybase или MSSQL.
Сложные наборы правил.
Использование процедурных языков на сервере.
Транзакации
Использование хранимых процедур.
Использование географичеких данных.
R-Trees (например, использование индексов).
Вы должны будете выбрать, взвесив все плюсы и минусы, какая база данных является «совершенной» для вашего приложения или сайта. А может быть и такое, что вы захотите использовать обе базы (бывают и такие случаи). Мое заключение – одна база не обязательно лучше другой, и каждая из них занимает свою определеную нишу в мире баз данных с открытым исходным кодом.
MySQL vs PostgreSQL

Выбор между MySQL и PostgreSQL — это решение, которое должен принять каждый разработчик веб-приложений, который выбирает между различными Open-Source СУБД. Оба решения проверены временем и оба заслуживают пристального внимания. СУБД MySQL задумывалась как более быстрая но менее функциональная, в то время как разработчики PostgreSQL сосредоточились на большем количестве функционально полезных примочек чтобы как можно ближе соответствовать стандартам Oracle. MySQL очень популярен среди Web разработчиков по причине его высокой скорости и простоты использования. PosgreSQL менее популярен, так как удобен и просто только для тех разработчиков, которые ранее использовали Oracle или другие похожие базы данных. Но все скоростные характеристики MySQL по сравнению с PostgreSQL постепенно таят, так как с каждым обновлением PostgreSQL заметно прибавляет в скорости. Теперь рассмотрим эти две СУБД более пристально.

Архитектура

PostgreSQL уникальная СУБД с единым сервером хранения данных (СХД). MySQL имеет два слоя в своей архитектуре. Первый слой — это набор серверов хранения данных. По этому при сравнении обычно указывают какой именно сервер хранения данных MySQL использовался. Каждый сервер отличают и параметры быстродейстсвия и его функциональные возможности. Самый распространенный из них — InnoDB. Он отличается от остальных полной поддержкой модели ACID и высокой производительностью. Прямым конкурентом InnoDB считается MyISAM, который годится для обработки и хранения сравнительно небольших объемов данных, которые преимущественно считываются из БД, а не записываются. А также когда не критично отсутствие ACID. Приложения, которые работают с MySQL, могут одновременно использовать несколько СХД для обеспечения наилучшего набора функциональности и производительности.

Производительность

Производительность СУБД может быть оптимизирована исходя из среды использования. Сравнения производительности различных СУБД также нужно проводить очень аккуратно и обращать внимание на цель использования и конфигурацию в которой работает СУБД. И MySQL и PostgreSQL имеют множество рычагов, с помощью которых можно управлять производительностью.

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

— частичное индексирование;

— сжатие данных;

— объем данных, хранимых в оперативной памяти;

— кэш запросов;

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

PostgreSQL поддерживает только один единственный СХД. Он входит в стандартную поставку PostgreSQL.

MySQL:ядро
MySQL 5.1 поддерживает 9 различных СХД:

MyISAM

InnoDB

NDB Cluster

MERGE

MEMORY (HEAP)

FEDERATED

ARCHIVE

CSV

BLACKHOLE

Однако, Federated и Blackhole не являются серверами «хранения» данных (например, Blackhole ничего не хранит). InnoDB разработан сторонней компанией InnoBase, которая была основана компанией Oracle. InnoDB поддерживает транзакции и занимает лидирующее место из всех поставляемых с MySQL серверов хранения данных.

MySQL планирует представить новые СХД Maria и Falcon в предстоящей версии 6.x. На них возложена задача заменить существующие движки MyISAM и InnoDB соответственно.

Существуют и другие СХД, разработанные сторонними компаниями и группами разработчиков. Наиболее популярные из них:

SolidDB

NitroEDB

BrightHouse

MySQL MyISAM имеет примитивный кэш, который перед выполнением каждого запроса на выборку сверяет простым сравнением строку запроса с предыдущими выполненными запросами и если есть совпадение то выдает ранее выбранный результат. Данный подход годится для систем, где подавляющей операцией является считывание данных, потому как только любая из таблиц изменит свое состояние (INSERT, UPDATE, DELETE) весь кэш очищается и соответственно теряется преимущество в производительности.

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

MySQL также поддерживает сетевой протокол сжатия данных, который включается и выключается на стороне клиента (если конечно позволяет сервер). Данная функция сжимает все данные которые идут от сервера к клиенту.

MySQL:MyISAM

MyISAM это традиционный СХД для MySQL и предлагает лучшее соотношение производительности и функциональности для баз данных предназначенных преимущественно для выборки данных (select). MySQL MyISAM обрабатывает запросы на выборку быстрее чем PostgreSQL, если речь идет о простых запросах. MyISAM не поддерживает транзакций и внешних ключей.

MyISAM поддерживает лидирующий префикс сжатия для ключей и сжатых таблиц предназначенных только для чтения.

Системный таблицы MySQL всегда используют СХД MyISAM. Это сделано для того, чтобы исключить даже потенциальную возможность потери данных.

MySQL:InnoDB

InnoDB это полно функциональная ACID транзакционная система (сервер) хранения данных (СХД), которая использует технологию MVCC. Это хороший выбор для современных приложений MySQL.

InnoDB хранит данные с первичным ключами, так что поиск по первичным ключам происходит очень быстро. Данный подход очень полезен для физической оптимизации БД. В случае когда он не применим и дает низкую производительность, то явно его можно не использовать и тогда система создаст невидимый внутренний первичный ключ типа Integer(15) и будет проводить индексацию по нему.

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

InnoDB имеет буфер вставки, который кэширует обновления вторичных индексов и фиксирует их в фоновом режиме. Данная функция фундаментально увеличивает производительность запросов на вставку данных. Чтобы уменьшить количество обращений к жесткому диску для записи новых данных их необходимо комбинировать в большие группы.

Если InnoDB установлен как плагин к MySQL 5.1, он поддерживает сжатие таблиц налету. Вы можете использовать атрибуты ROW_FORMAT=COMPRESSED или KEY_BLOCK_SIZE в запросах CREATE TABLE и ALTER TABLE, чтобы дать команду InnoDB сжать каждую страницу в 1K, 2K, 4K, 8K или 16K байт.

Innobase Oy, это компания, которая занимается разработкой InnoDB. Она была куплена компанией Oracle в октябре 2005 года. С тех пор InnoDB все больше и больше заимствует у СУБД Oracle. А теперь, с покупкой компании MySQL компанией SUN эти и без того тесные взаимоотношения между Oracle и MySQL стали еще крепче. MySQL выходит на качественно новый уровень возможностей.

MySQL:NDB Cluster

NDB это высокопроизводительный преимущественно располагающиеся в Оперативной Памяти (RAM) СХД. Не индексируемые атрибуты могут сохраняться на жестком диске. Данные и логи также периодически синхронизируются на жесткий диск, чтобы избежать потери данных в случае внезапного «падения» кластера. NDB преимущественно используется в сфере телекоммуникаций, где аптайм и производительность в реальном масштабе времени критичны. NDB прозрачно собирает данные в фрагменты которые регулярно доставляет во все участки кластера. NDB использует внутреннюю синхронную репликацию чтобы записи были распространенны по меньшей мере на двух участках кластера прежде чем совершать фиксацию на жесткий диск. NDB также поддерживает автоматическое восстановление «упавших» элементов кластера (нодов). Из слабых сторон NDB стоит отметить очень плохую поддержку сложных запросов с использованием операторов JOIN.

В PostgreSQL похожих решений на данный момент просто нет.

MySQL:Archive

MySQL поддерживает сжатие на лету с версии 5.0, когда в дистрибутив попал СХД ARCHIVE. Archive — это СХД, который позволяет делать одновременно только 1 запись и множество чтений. Разработан специально для архивных баз данных, где запись в БД осуществляется гораздо реже и преимущественно одним источником данных. Сила сжатия достигает 90%. Archive не поддерживает индексы. В версии MySQL 5.1 Archive может работать с несколькими разделами (партициями).

MySQL:Falcon

Falcon это ACID транзакционный СХД, который был разработан самой MySQL. В данный момент он находится в зачаточном состоянии и доступен для тестирования в бета-ветке MySQL 6.0. Falcon поддерживает сжатие данных налету. Данные, сохраненные в таблицах Falcon, сжимаются на жестком диске, но в оперативной памяти хранятся не в сжатом ввиде. Сжатие происходит автоматически, когда данные синхронизируются на жесткий диск.

MySQL:Maria

Maria это ACID СХД, который был разработан Монти Вайденисом (Monty Widenius) и командой разработчиков MySQL.

Мультпроцессность

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

С распространением на рынке мультипроцессорных систем, MySQL кинул свои силы на доработку СУБД. С каждой новой версией MySQL работает все быстрее и быстрее при использовании многопроцессорных систем. Наиболее удачными версиями, которые координально увеличивают производительность СУБД по сравнению с предыдущими версиями стоит отметить 5.0.30, 5.0.54 и 5.0.58. Данный факт подтверждается многими проведенными тестами.

Ассинхронный Ввод/Вывод

PostgreSQL полностью поддерживает асинхронный API для использования в клиентских приложениях. Данная возможность позволяет увеличить производительность в некоторых случаях до 40%. В MySQL отсутствует поддержка асинхронного режима. Но существует несколько драйверов, которые предоставляют эту возможность. Например MySQL драйверы для perl и ruby.

COUNT()

Транзакционные версионные СУБД, которые построены на модели MVCC, например такие как PostgreSQL и InnoDB, выполняют COUNT() очень медленно в сравнении с не транзакционными СХД или транзакционными не версионными СХД, например такими как MyISAM. MyISAM в MySQL использует сканирование индексов для обработки COUNT() и также кэширует полученный результат, данный подход гораздо эффективнее. PostgreSQL и InnoDB требуют полного сканирования таблицы на предмет учета всех видимых полей. MVCC-совместимые СХД выполняют операцию COUNT() данным способом потому, что MVCC сохраняет информацию о видимости или не видимости транзакции в данных самой записи (ROW). Во всех MVCC-совместимых СХД кэширование результатов операции COUNT() приведет к возврату некорректных данных. PostgreSQL Count() работает медленнее чем COUNT() в InnoDB.

Тесты производительности

Все тесты производительности СУБД напрямую зависят от среды и целей использования. Каждая СУБД может быть настроена на оптимальную производительность для каждого отдельного случая. По этому будет не корректно проводить сравнения простых или сложных выборок из БД. Или же вставки. Чтобы определить наиболее быструю СУБД, нужно проводить сравнения в требуемых условиях на требуемом оборудовании и с требуемыми данными.

Модель ACID
ACID следует понимать как Atomicity, Consistency, Isolation и Durability (Валентность, Последовательность, Изоляция и Длительность). Данная модель используется для обеспечения целостности данных средствами СУБД. Многие СУБД достигают соглашений ACID путем использования транзакций.
PostgreSQL и MySQL использующий InnoDB, Cluster и Falcon СХД полностью соответствуют всем принципам и канонам модели ACID.

Возможности
PostgreSQL и MySQL оба обладают внушительным набором возможностей и функций которые обеспечивают целостность данных, функциональность и производительность. Возможности, которые входят в состав PostgreSQL и MySQL позволяют улучшить производительность, легкость использования, функциональность или стабильность.
Простота использования
Готча (Gotcha) — это функция или функции которые работают так как описаны но не так как ожидалось (http://sql-info.de/mysql/gotchas.html). Поклонники PostgreSQL настаивают на том, что MySQL имеет больше готчей чем PostgreSQL.
В последних версиях MySQL представила пользователям различные режими работы SQL, которые совместимы с различными стандартами SQL и позволяют легко разобраться в MySQL тем, кто с MySQL никогда не работал.
Insert Ignore / Replace

MySQL поддерживает операторы ‘INSERT IGNORE’ и ‘REPLACE’ которые вставляют запись если ее не существует и ничего не делают в другом случае или заменяют текущую запись соответственно.

PostgreSQL не поддерживает ничего из выше перечисленного и советует использовать сохраненные процедуры для достижения такого эффекта. Однако существует одно «НО». В одно и тоже время может быть вставлено только одно значение. Данное условие накладывает серьезные ограничения на производительность и вызывает определенные сложности. INSERT IGNORE и REPLACE обрабатывают вставку нескольких значений и их запись симпатичнее чем процедура.

Еше одна полезная запись в MySQL: INSERT … ON DUPLICATE UPDATE также напрочь отсутствует в PostgreSQL и для реализации своими руками требует написания сохраненных процедур, которые могут обрабатывать только 1 запись в один момент времени.

Ограничители

Обе СУБД PostgreSQL и MySQL поддерживают ограничители Not-Null, Unique, Primary Key и Foreign Key. Однако MySQL не поддерживает ограничение Check когда PostgreSQL поддерживает его уже довольно продолжительное время.

Таблицы InnoDB поддерживают проверки внешних ключей. Для остальных СХД MySQL разбирает и игнорирует FOREIGN KEY и REFERENCES в директиве CREATE TABLE.

Для движков MySQL не поддерживающих внешние ключи могут быть применены тригеры.

Значения по умолчанию
PostgreSQL позволяет для колонок использовать в качестве значения по умолчанию любую функцию помеченную как IMMUTABLE или STABLE. В MySQL, на данный момент, лишь функция Now() может быть использована как значение по умолчанию для колонки.
Сохраненные процедуры
И PostgreSQL и MySQL поддерживают сохраненные процедуры.
Главный язык запросов в PostgreSQL — PL/pgSQL, он похож на PL/SQL в Oracle. PostgreSQL также поддерживает SQL:2003 PSM сохраненные процедуры также как и другие популярные языки программирования Perl (PL/Perl), Python (PL/Python), TCL (PL/Tcl), Java (PL/Java) и даже C (PL/C).
MySQL следует синтаксису SQL:2003 для сохраненных процедур, который также используется в IBM DB2.
MySQL поддерживает другие языки программирования сохраненный процедур с помощью плагинов. Из самых популярных стоит отметить Java, Perl, XML-RPC.
Триггеры

И PostgreSQL и MySQL поддерживают триггеры. Триггеры в PostgreSQL могут выполнять любые пользовательские функции из любого процедурного языка.

Триггеры в MySQL активируют только SQL запросами. Они не активируются изменениями в таблицах, которые делаются при помощи MySQL API и не выполняют никаких SQL запросов.

PostgreSQL также поддерживает правила (RULES), которые позволяют оперировать над синтаксисом запросов и могут делать некоторые операции проще, чем традиционный механизм триггеров.

Синтаксис для определения триггеров в PostgreSQL не так силен как в MySQL. PostgreSQL требует раздельного определения функции с специальным типом возвращаемого значения.

Репликация и Высокая Доступность

Репликация — это механизм СУБД дублировать свои данные для резервных копий а также для зеркалирования на другие сервера для обеспечения высокой стабильности. PostgreSQL и MySQL оба поддерживают репликации:

PostgreSQL
PostgreSQL поддерживает репликацию на уровне подключаемых модулей. Существует несколько модулей, которые позволяют осуществлять репликацию данных СУБД PostgreSQL:

— PGCluster

— Slony-I

— DBBalancer

— pgpool

— PostgreSQL table comparator

— SkyTools

— Sequoia

— Bucardo

— Mammoth Replicator

— Cubercluster

— GridSQL (shared-nothing)
Существует заблуждение о том, что эти модули третих производителей как-то плохо интегрируются и выполняют свою работу не надлежащим образом. Например Slony, был спроектирован и разработан Жаном Вейком (Jan Weick), членом команды разработчиков PostgreSQL при участии множества людей из сообщества PostgreSQL. Однако, Slony, гараздо медленнее и использует больше ресурсов чем встроенный репликатор в MySQL. Но в версии PostgreSQL 8.4 вышел встроенный репликатор.
Слабые места репликации в PostgreSQL
Slony-I наиболее широко используемый инструмент для репликации данных в PostgreSQL и является прямой противоположностью встроенному механизму репликации данных в MySQL. Во первых он использует SQL и триггера для сбора данных для репликации по всему серверу. Этот подход координально медленнее чем родной способ репликации данных в MySQL, который использует бинарный режим обработки БД. Во вторых Slony-I не придатен для использования в огромных кластерах, так как потребление ресурсов равно квадрату используемых серверов для репликации данных.
2 сервера: MySQL: 2 = 2 PostgreSQL: 22^2 = 8

4 сервера: MySQL: 4 = 4 PostgreSQL: 24^2 = 32

12 серверов: MySQL: 12 = 12 PostgreSQL: 212^2 = 288.
Пока Slony-I адекватен для высокой доступности с использованием двух серверов. Slony-I очень тяжело администрировать.
Bucardo написан на языке Perl и интенсивно использует триггеры PL/PGSQL и PL/PERLU.
PGCluster не полезен там, где ожидается высокая производительность и большое количество источников данных потому, что в PGCluster реализована синхронная репликация которая ожидает пока проихойдет запись на всех машинах, участвующих в кластере. Однако в ситуациях, где количество источников данных минимально и требуется чтобы на всех машинах в кластере данные были всегда идентичны — PGCluster станет хорошим инструментом.
MySQL
MySQL поставляется с поддержкой асинхронной репликации данных. Начиная с версии 5.1, MySQL поддерживает два формата репликации. SBR отслеживает SQL запросы, которые вносят изменения в БД, в специальный бинарный логфайл, на который подписаны все дочерние сервера. Соответственно при изменениях в главной БД, все остальные БД получают копии данных. RBR отслеживает инкрементальные изменения записей и записывает их в бинарный лог-файл, из которого получают данные все дочерние БД. RBR используется автоматически, когда выполняется определенный запрос в главной БД. Некоторые СХД как NDB, Falcon и в некоторых случаях InnoDB для репликации используют только RBR.
Начиная с версии 6.0 MySQL поддерживает полу-синхронную репликацию в которой мастер подтверждает получение хотя бы одной дочерней БД до возврата из процедуры комита данных. Этот метод позволяет уменьшить до минимума потери данных, особенно в больших кластерах.
Типы данных
PostgreSQL не поддерживает unsigned integer, но имеет более широкую поддержку типов данных в аспектах соответствия стандартам, базовый логический тип Boolean, определение пользовательских типов данных, встроенные типы данных.
PostgreSQL позволяет колонкам таблиц быть определенными как мультиразмерный массив с изменяемой длинной. Массивы могут быть любого встроенного или пользовательского типа, enum или композитного типа. Но вот массивы доменов пока не поддерживаются.
MySQL не имеет типа данных IP Адрес, который присутствует в PostgreSQL но для преобразований из и в IPV4 используются функции INET_ATON() и INET_NTOA(). В БД хранится как Integer.
Подзапросы
MySQL и PostgreSQL поддерживают подзапросы. В MySQL подзапросы появились недавно и требуют сильной доработки по части производительности. В PostgreSQL подзапросы доведены практически до совершенства.
Расширенное индексирование
Расширенное индексирование позволяет СУБД выполнять запросы с гораздо более высокой скоростью. И MySQL и PostgreSQL поддерживают расширенное индексирование.
Множественные индексы.
MySQL поддерживает множественные индексы для каждой таблицы в отдельности и может использовать один индекс для одной таблицы. PostgreSQL поддерживает множественные индексы для каждого запроса в отдельности.
Полнотекстовые индексы.
MySQL идет с поддержкой полнотекстового поиска, но поиск может быть использован только на СХД MyISAM. Также MySQL поддерживает внешние модули для организации полнотекстового поиска — Sphinx Fulltext Search Engine. Данный плагин добавляет поддержку полнотекстового поиска для СХД InnoDB.
PostgreSQL начиная с версии 8.2 имеет в своем распоряжении полнотекстовый поиск в модуле tsearch3. Начиная с версии 8.3 модуль tsearch3 интегрирован в ядро PostgreSQL.
Частичное индексирование
MySQL не поддерживает частичного индексирования. PostgreSQL поддерживает частичное индексирование. Частичный индекс — это индекс построенный на срезе таблицы. Срез определяется специальным выражением, которое называется предикатом частичного индекса. Индекс содержит записи, которые удовлетворяют предикату. Частичные индексы — это довольно специфичная штука, но существуют ситуации, в которых частичные индексы могут быть очень полезны.
Один из важнейших аспектов использования частичных индексов — это избежание индексирования повторяющихся значений. Когда запрос ищет повторяющиеся значения, которые занимают не более нескольких процентов от всей таблицы, индексы не используются. Так что нет нужды хранить эти данные в индексе. Данный подход уменьшает размер индекса и увеличивает скорость обработки запросов. А также увеличивается скорость выполнения других операций над таблицами, например скорость обновления записей.
Порционирование
MySQL поддерживает несколько форм горизонтального порционирования:

— RANGE

— LIST

— HASH

— KEY

— Композитное порционирование используя RANGE или LIST с HASH или KEY
PostgreSQL поддерживает только RANGE и LIST. HASH порционирование поддерживается с помощью внешних функций. Также PostgreSQL поддерживает композитные решения.
Лицензирование
PostgreSQL распространяется по лицензии BSD, в которой отмечены пункты Free Software Definition и Open Source Definition и стандарт Copyfree.
MySQL доступен по лицензии GNU General Public License, в которой также отмечены пункты Free Software Definition и Open Source Definition но не по стандарту Copyfree. А это значит что если будет издан продукт, в котором используются исходники MySQL вам придется либо заплатить за коммерческую копию MySQL AB либо открыть исходные коды для общего пользования.
Разработка
MySQL владеет и спонсирует одна профилирующая компания MySQL AB. Правда теперь она является частью Sun Microsystems, которая в свою очередь была приобретена компанией Oracle. MySQL AB держит копирайты и исходники MySQL.
PostgreSQL не принадлежит никакой компании и поддерживается глобальным сообществом разработчиков а также компаниями, которые участвуют в разработке. PostgreSQL имеет корпоративных спонсоров, которые дают деньги на разработку.
MySQL — это ПРОДУКТ с открытым исходным кодом.

PostgreSQL — это ПРОЕКТ с открытым исходным кодом.
Происхождение названия
Когда был создан стандарт ANSI SQL, его автор сказал, что официально SQL произносится как «ess queue ell». Имена и MySQL и PostgreSQL отражают в своих именах этот стандарт. MySQL официально произносится как «my ess queue ell». Однако многие произносят MySQL как «my sequel».
Так как MySQL является собственностью компании MySQL AB, то компания была вынуждена сохранить копирайты на имя своего детища и по этому название скорее всего останется неизменным.
PostgreSQL произносится как «пост гресс ку элл». Название сформировано из старого названия Postgres (так называлась СУБД на базе которой был создан PostgreSQL) и SQL. Некоторые люди называют Постгрескуэл как пиджискуэл (pgsql). Ходят слухи, что PostgreSQL будет переименован назад в Postgres. На данный момент идут активные дебаты по этому поводу.
Популярность
MySQL широко известен и применяется в большинстве открытых (open-source) разработок по всему миру. Наиболее часто используется СХД MyISAM. И с уверенностью можно сказать, что MySQL самая популярная СУБД для вебразработок по всему миру.
Основаниями для такой популярности служит то, что MySQL легче использовать, чем другие СУБД, в частности PostgreSQL. Это утверждение бытует уже много лет. Но фактически несколько лет назад PostgreSQL произвел серьезные изменения в своей структуре и может по праву считаться более легким в использовании нежели MySQL. Но вопрос по прежнему открыт. Что же выбрать? MySQL или PostgreSQL?
Версия статьи

0.4

Подсвечено жирным шрифтом название раздела. Спасибо Никите Бабакину (skew).

0.3

Исправлено множество грамматических ошибок. Спасибо Алексею (oktogen).

0.2

Исправлены недочеты в разделе «Производительность». Спасибо Илье Звягину.

0.1

Первый релиз.
MySQL vs PostgreSQL | Блог Валерия Леонтьева
Неделю назад я инициировал обсуждение на одном сайтике на тему миграции с MySQL на PostgreSQL. В процессе обсуждения плавно сменили тему на сравнение этих двух популярных СУБД. В результате мне показалось, что почитать это обсуждение будет интересно и полезно многим программистам. В обсуждении участвовал известный программист PHP, автор двух книг по PHP, разработчик сервиса moikrug.ru Дмитрий Котеров.
Вот обсуждение, немного обработанное с вырезанными лишними постами.
from MySQL to PostgreSQL
Валерий Леонтьев, программист PHP/MySQL
Вопрос тем, кто уже прошел такой путь: на сколько сложен переход для программиста, на сколько велики отличия, сколько % запросов обычно надо переписать для сайта на MySQL. Все рассматривается в контексте программирвоания на PHP.
Илья Бутыльский, web-developer
Не сильно сложно. Взвесьте все «за» и «против». Может и не стоит переходить.
Валерий Леонтьев, программист PHP/MySQL
Уже взвесил. Скорость постгри при нагрузке в разы выше, чем у MySQL. При этом, предел отказоустойчивости тоже выше. Т.е. переводить мелкие проекты смысла нет, а вот крупные стоило бы.
Михаил Талисов, Магистрант, Java EE developer
У меня тоже возникала год назад необходимость переводить приложение с MySQL на PostgreSQL. Особых трудностей не возникло.
Но все же некоторые вещи пересмотреть пришлось: в PostgreSQL нет автоинкрементных полей (для автоматического инкремента ПК используется специальный тип SERIAL). И для хранения значения счетчика используются специальные конструкции — sequence. Для получения текущего значения счетчика используется нечто вроде:
«select currval(‘task_id_seq’)»
Вроде больше особых отличий нету, остальное — детали.
Дмитрий Кадыков, web-программист Интернет-гипермаркета 003.ru
Мне приходилось делать обратную операцию: перевести часть кода с Postgre на MySQL. Пришлось заменить TO_CHAR(date,’MM.YYYY’) на DATE_FORMAT(date, ‘%m.%Y\’), и в принципе всё.
Валерий Леонтьев, программист PHP/MySQL
Re: Дмитрий Кадыков
А по какой причине так пришлось сделать, если не секрет?
Антон Полумисков, PHP программист
А на каком MySQL проект находится сейчас? У постгри приемуществ конечно хватает, но может проще будет перейти на MySQL5, если проект конечно не под 5 работает )), он и быстрее чем предшественники и возможностей стало больше. Но и самое главное — возникнет значительно меньше проблем с переходом.
Валерий Леонтьев, программист PHP/MySQL
Re: Антон Полумисков
Понимаешь, тут дело такое: если бы не 5 версия MySQL, то я бы уже давно перешел на ту же PostgreSQL или что-то другое. Версии до 5 — это полупустые СУБД. Там кроме тормозючести еще и половины фишек нет, которые в других СУБД давно есть и являются стандартом.
Евгений Ненаглядов, Вэб-разработчик
А мне из мускула не хватает REPLACE. В постгресе сие реализуется только триггером на INSERT, а я еще не освоил программирование процедур.
Переводил довольно крупный проект. Нудно, но не критично.
Из-за особенностей работы с автоинкреметными полями, реализовал замену функции mysql_insert_id().
Дмитрий Котеров, МойКруг.ру: сооснователь, рук. разработки
Скорость постгри при нагрузке в разы выше, чем у MySQL
Мой опыт показывает, что это совершенно неверное заявление. Все в точности да наоборот. Вы какой тип таблиц используете? Если MyISAM, то все понятно — они под нагрузкой плохо живут, если операции записи производятся сравнительно часто. Попробуйте InnoDB, они работают примерно так же, как таблицы в PostgreSQL (версионник с блокировкой строк). И попробуйте еще настройки MySQL потюнить — от них многое зависит.
Для крупных высоконагруженных проектов важное значение имеет репликация. В MySQL она встроенная и, главное, работает отлично — практически нет запаздывания при обновлении реплики. Для PostgreSQL есть Slony, однако у него: (а) раз в 10 бОльший «барьер на вход» (т.е. если с репликацией MySQL Вы в продакшене освоитесь, скажем, за неделю, то в Slony — за 10 недель), и (б) конструктивно значительный лаг при обновлении реплик, а значит, Вам придется строить приложение с учетом этого лага, что не так-то просто (встроенных средств в Slony для отслеживания этого лага [пока] нет).
Кроме того, если Вы рассчитываете с переходом на PostgreSQL обеспечить лучшую сохранность данных, то для обеспечения высокой производительности совместно* с высокой надежностью нужно обязательно использовать аппаратный дисковый контроллер со встроенной кэш-памятью записи значительного размера и батарейкой (а такие контроллеры недешевы). Без аппаратного решения Вы «упретесь» в операцию fsync, которая, собственно, и обеспечивает сохранность данных, и которая несовместима с интенсивным обновлением данных без аппаратного решения.
Так что, если у Вас проект прекрасно работает на MySQL, возможностей MySQL ему хватает, то я бы категорически не рекомендовал переходить на PostgreSQL. PostgreSQL нужен для действительно сложных проектов, когда возможностей MySQL (даже 5-й версии) не хватает, когда приходится применять нереляционный подход, — например, для МойКруг. По крайней мере, в стратегическом (долгосрочном) плане повышения быстродействия при переходе с MySQL на PostgreSQL Вы точно не добьетесь.
Валерий Леонтьев, программист PHP/MySQL
Re: Дмитрий Котеров
Спасибо за столь подробный ответ. Мое «заявление» на самом деле основывалось не на личном опыте (как понятно из темы — я с постгри не работал), а не статьях других программистов. Последняя статья на эту тему, которую я прочитал была опубликована в журнале «Системный администратор» кажется за август (я не обратил внимания на номер). И как раз там у них по результатам опытов разница получилась в разы.
В MySQL медленнее работают сложные запросы: с джойнами и подзапросами. На этой почве у меня даже развилась некая фобия таких запросов. А если эх будет много в скрипте, да плюс нагрузка пиковая большая, то MySQL может и в ступор впасть. Один раз я такой ступор уже наблюдал. Правда там причина была в том, что проект был написан неграмотно (не мной) и не стояли индексы. Когда я открыл show processes, я там наблюдал кучу сложных висящих запросов. И загрузка ЦП деманом мускуля 99%. Так как времени на оптимизацию не было, да и двиг этот скоро уйдет в корзину, я не менял запросы, но просто сделал для них «правильные индексы», проблема частично решилась. Таких ступоров больше не было. И вот сложилось по статьям у меня впечатление, что с постгри такого не будет, а если и будет, то при много большей нагрузке. Тип таблиц в данном скрипте действительно MyISAM.
Александр Лещинский, Мизантропичный админ
Re: Дмитрий Котеров
Мой опыт показывает, что это совершенно неверное заявление.
нечасто я соглашаюсь с Дмитрием, но тут поддержу из всех стволов. Безмозглое неграмотное мудачье, не знающее матчасти, делает «абы как» своими руками, растущими из жопы, а потом удивляется «а шо, нам обещали что будет все шоколадно, а все совсем не так»? Любой инструмент, даже самый хороший, не отменяет необходимости думать… головой!!! а не тем, чем привыкли так называемые «работники» — очком.
Re: Валерий Леонтьев
Про журнальчик этот вобще цензурных слов нет… большего сборища ламерья я еще не встречал… Писать и проектировать надо аккуратно, чтобы не накрывал БП
Дмитрий Кадыков, web-программист Интернет-гипермаркета 003.ru
Re: Валерий Леонтьев
Да просто новому начальнику не понравилось, что одна часть проекта работает по Postgre, а всё остальное — под MySQL. Кстати, сразу же хотелось бы задать вопрос всем: может ли считаться оправданным совмещение двух СУБД в рамках одного проекта и в каких случаях стоит так делать?
Валерий Леонтьев, программист PHP/MySQL
Re: Дмитрий Котеров
Кстати, как я понял, Дмитрий Котеров повсеместно предпочитает использовать InnoDB. А как с fulltext-поиском? Используете ли Вы его? Или ищите по каким-то другим алгоритмам?
Валерий Леонтьев, программист PHP/MySQL
Re: Дмитрий Кадыков
Логически поразмышляв, пришел к выводу, что совмещение СУБД оправдано быть не может. Обычно, из 2х СУБД одна лучше. Тогда зачем делить, логичнее все делать на той, которая лучше в данной ситуации. Возможно, деление оправдано в крайне редких случаях, когда разные элементы проекта требуют функционал, доступный только в разных СУБД. Не знаю бывает ли такое вообще, но если и бывает, то крайне редко (может 1 сайт из 1000).
Александр Лещинский, Мизантропичный админ
Re: Валерий Леонтьев
Логически поразмышляв, пришел к выводу, что совмещение СУБД оправдано быть не может.
А практики говорят, что резоны могут быть…
Валерий Леонтьев, программист PHP/MySQL
Ну так у любого правила есть исключения. Я и пример даже привел.
Евгений Неверов, Я — человек!
Если же вернуться к сути вопроса, то структуру из одной БД нужно будет перенести заранее ручками (проще это), а вот данные скорее всего перенесутся без проблем.
Был у меня один проект, который я переносил с MySQL на PostgreSQL, так вот там по ходу дела пришлось сменить структуру таблиц. Чтобы импортировать данные я написал около 20 регулярных выражений, которые преобразовывали INSERT-запросы к нужному формату. Но в результате всё получилось очень хорошо.
Ответить
Виктор Куряшкин, Semantic Web specialist, Sun Microsystems
На постгрес с мускула имеет смысл переходить, если вы будете использовать возможности постгреса.
Просто «переписать запросы», сделать автоинкремент сиквенсом и все — это не аргумент.
Если вы не планируете усложнять логику на уровне субд — то точно переходить не стоит. Просто провозитесь и получите прибавку к производительности 5%, а то и потеряете в некоторых случаях.
Дмитрий Котеров, МойКруг.ру: сооснователь, рук. разработки
В MySQL медленнее работают сложные запросы: с джойнами и подзапросами
Не совсем так. Скорость выполнения запроса зависит во многом от того, «попадает» ли он, грубо говоря, в индексы. Если запрос «не попал» в индексы в MySQL и «не попал» в PostgreSQL, неверно говорить, что «в PostgreSQL этот запрос будет работать быстрее» — он в обоих случаях работает недопустимо долго.
Другое дело, что в PostgreSQL мощный планировщик и оптимизатор запросов (правда, он при этом и очень сложен, а также часто «ошибается», т.е. на его приструнение и изучение нужно тратить много времени). Кроме того, в PostgreSQL есть всякие там Hash Join и т.д. Так что, действительно, у написанного «от балды» сложного многотабличного запроса в PostgreSQL вероятность выполниться быстро выше, чем у того же запроса в MySQL. Но речь-то сейчас не о вероятностях, а о том, что запросы нужно строить грамотно, смотреть план их выполнения и «подгонять» друг под друга запрос, его план и индексы. А если все подогнанно, то и там, и там выполняется быстро, и на передний план выходит уже скорость апдейтов и простота репликации.
Кстати, как я понял, Дмитрий Котеров повсеместно предпочитает использовать InnoDB. А как с fulltext-поиском? Используете ли Вы его? Или ищите по каким-то другим алгоритмам?
Собственно, на MойКруге PostgreSQL во многом как раз из-за того, что в нем есть отличный полнотекстовый поиск, который и не снился MySQL. (А в 8.3 он будет еще лучше.) В InnoDB, к сожалению, полнотекстовых индексов и правда не бывает. Но я слышал, что есть масса внешних решений для индексации таблиц — в этом случае индекс строится с задержкой и по нему не так удобно искать, конечно, но — это лучше, чем ничего. Лично мне с ними работать не приходилось.
Опять же, если строить систему с нуля, и если в системе планируется много апдейтов данных, то лучше идти в сторону как раз раздельного хранения полнотекстового индекса и данных. Ну или хотя бы считать полнотекстовый индекс асинхронно (с задержкой) — как сделано здесь.
Насчет систем с двумя различными СУБД — почему бы и нет? Мы, например, используем и MySQL тоже (как раз там, где мало селектов, но много инсертов и апдейтов). Да, на администрирование дополнительной базы должно тратиться больше времени, однако тут есть два «но»:
1. Админ, работая с двумя базами сразу, здорово повышает свою квалификацию. Кроме того, появляется возможность сравнивать те или иные вещи.
2. MySQL очень неприхотлива и нетребовательна в администрировании (по моим приблизительным оценкам — там раз в 10 меньше подводных камней, чем в PostgreSQL), поэтому затраты на администрирование и MySQL тоже крайне малы.
Поучаствовать в обсуждении можно здесь: http://moikrug.ru/topics/216367527/
Вывод: прежде чем переходить на PostgreSQL нужно хорошо обдумать, стоит ли оно того, чтобы потом не пришлось откатывать все назад.
json в PostgreSQL vs Mysql vs Mongodb / Хабр
As such, there’s really no “standard” benchmark that will inform you about the best technology to use for your application. Only your requirements, your data, and your infrastructure can tell you what you need to know.
Для начала немного философии. NoSql окружает и от этого никуда не убежать (хотя не очень то и хотелось). Оставим вопросы о глубинных причинах за рамками данного текста, отметим лишь, что этот тренд отражается не только в появлении новых NoSql решений и развитии старых. Еще одна грань — смешение противоположностей, а именно поддержка хранения schema-less данных в традиционных реляционных базах. В этой серой области на стыке реляционной модели хранения данных и всего остального кроется головокружительное количество возможностей. Но, как и всегда, нужно уметь найти баланс, который подходит именно для ваших данных. Это бывает трудно, в первую очередь из-за того, что приходится сравнивать мало сравнимые вещи, например, производительность NoSql решения с традиционной базой данных. В этой небольшой заметке будет предложена такая попытка и приведено сравнение производительности работы с jsonb в PostgreSQL с json в Mysql и с bson в Mongodb.
Что, черт возьми, вообще происходит?
Краткие вести с полей:
PostgreSQL 9.4 — новый тип данных jsonb, поддержка которого будет немного расширена в грядущей PostgreSQL 9.5

Mysql 5.7.7 — новый тип данных json

и ряд других примеров, о которых расскажу в следующий раз. Замечательно то, что эти типы данных предполагают не текстовое, а бинарное хранение json, что делает работу с ним гораздо шустрее. Базовый функционал везде идентичен, т.к. это очевидные требования — создать, выбрать, обновить, удалить. Самое древнейшее, почти пещерное, желание человека в этой ситуации — провести ряд benchmark’ов. PostgreSQL & Mysql выбраны, т.к. реализация поддержки json очень похожа в обоих случаях (к тому же они находятся в одинаковой весовой категории), ну а Mongodb — как старожил NoSql мира. Работа, проведенная EnterpriseDB, немного в этом плане устарела, но ее можно взять, в качестве первого шага для дороги в тысячу ли. На данный момент целью данной дороги является не показать, кто быстрее/медленее в искусственных условиях, а постараться дать нейтральную оценку и получить feedback.
Исходные данные и некоторые детали
pg_nosql_benchmark от EnterpriseDB предполагает достаточно очевидный путь — сначала генерируется заданный объем данных разного вида с легкими флуктуациями, который затем записывается в исследуемую базу и по нему происходят выборки.
Функционал для работы с Mysql в нем отсутствует, поэтому его понадобилось реализовать на основе аналогичного для PostgreSQL. На данном этапе есть только одна тонкость, когда мы задумываемся об индексах — дело в том, что в Mysql не реализовано
индексирование json на прямую, поэтому приходится создавать виртуальные колонки и индексировать уже их. Помимо этого, меня смутило то, что для mongodb часть сгенерированных данных размером превышает 4096 байт и не вмещается в буфер mongo shell, т.е. просто отбрасывается. В качестве хака получилось выполнять insert’ы из js файла (который еще и приходится разбивать несколько chunk’ов, т.к. один не может быть больше 2GB). Помимо этого, чтобы избежать издержек, связанных со стартом шелла, аутентификацией и проч., совершается соответствующее количество «no-op» запросов, время которых затем исключается (хотя они, на самом деле, достаточно малы).
Со всеми полученными изменениями проверки проводились для следующих случаев:
PostgreSQL 9.5 beta1, gin

PostgreSQL 9.5 beta1, jsonb_path_ops

PostgreSQL 9.5 beta1, jsquery

Mysql 5.7.9

Mongodb 3.2.0 storage engine WiredTiger

Mongodb 3.2.0 storage engine MMAPv1

Каждый из них был развернут на отдельном m4.xlarge инстансе с ubuntu 14.04 x64 на борту с настройками по умолчанию, тесты проводились на количестве записей, равном 1000000. Для тестов с jsquery надо прочитать readme и не забыть установить bison, flex, libpq-dev и даже postgresql-server-dev-9.5. Результаты будут сохранены в json файл, который можно визуализировать с помощью matplotlib (см. здесь).
Помимо этого возникали сомнения относительно настроек, связанных с durability. Поэтому я провел пару дополнительных тестов для следующих случаев (на мой взгляд, часть из них является скорее теорией, т.к. вряди кто-то будет использовать такие настройки в живую):
Mongodb 3.2.0 journaled (writeConcern j:true)

Mongodb 3.2.0 fsync (transaction_sync=(enabled=true,method=fsync))

PostgreSQL 9.5 beta 1, no fsync (fsync=off)

Mysql 5.7.9, no fsync (innodb_flush_method=nosync)

Картинки
Все графики, связанные со временем выполнения запросов, представлены в секундах, связанные с размерами — в мегабайтах. Соответственно, для обоих случаев чем меньше величина, тем больше производительность.
Select
Insert
Insert (custom configuration)
Update
Еще одним изменением относительно оригинального кода pg_nosql_benchmark было добавление тестов на обновление. Здесь явным лидером оказалась Mongodb, скорее всего за счет того, что в PostgreSQL и Mysql обновление даже одного значения на данным момент означает перезапись всего поля.
Update (custom configuration)
Как можно предположить из документации и подсмотреть в этом ответе, writeConcern j:true — это наивысший возможный уровень durability для одного сервера mongodb, и судя по всему он должен быть эквивалентен конфигурациям с fsync. Я не проверял durability, однако интересно, что для mongodb операции обновления с fsync получились намного медленнее.
Table/index size
I have a bad feeling about this
Измерение производительности — слишком скользкая тема, тем более в этом случае. Все, что описано выше, нельзя считать полноценным и завершенным бенчмарком, это только первый шаг к тому, чтобы понять текущую ситуацию — что-то вроде пищи для размышлений. В данный момент мы занимаемся проведением тестов с использованием ycsb, а также, если повезет, сравним производительность кластерных конфигураций. Помимо этого, буду рад всем конструктивным предложениям, идеям и правкам (т.к. я вполне мог что-то упустить).
PostgreSQL против MySQL: важные различия
Критические отличия Postgres от MySQL:
Postgres — это многофункциональная база данных, которая может обрабатывать сложные запросы и большие базы данных.
MySQL — это более простая база данных, относительно простая в настройке и управлении, быстрая, надежная и понятная.
Postgres — это объектно-реляционная база данных (ORDBMS) с такими функциями, как наследование таблиц и перегрузка функций, тогда как MySQL — это чистая реляционная база данных (RDBMS).
Большинство разработчиков скажут вам, что MySQL лучше подходит для веб-сайтов и онлайн-транзакций, а PostgreSQL лучше для больших и сложных аналитических процессов. Они также заметят, что PostgreSQL имеет «множество замечательных функций», таких как расширяемость и собственные возможности NoSQL, которые помогут вам справиться с трудными ситуациями с базами данных. Наконец, они напомнят вам, что в MySQL мало функций, поэтому он может сосредоточиться на «скорости и надежности».
По большей части эти точки зрения верны.Несмотря на то, что с каждым новым выпуском MySQL и PostgreSQL становятся все ближе друг к другу в отношении их предложений (см. Таблицу), отличительные характеристики этих систем баз данных означают, что — для определенных случаев использования — одна может быть лучше другой.
Сравнение характеристик PostgreSQL 10 MySQL 8
Общее табличное выражение (CTE) Есть Да (недавно добавлено)
Декларативное разбиение на разделы Да (недавно добавлено) Есть
Полнотекстовый поиск Есть Есть
Географическая информационная система (GIS) / Пространственная справочная система (SRS) Есть Да (обновлено)
JSON Есть Да (обновлено)
Логическая репликация Да (недавно добавлено) Есть
Полусинхронная репликация Да (недавно добавлено) Есть
Оконные функции Есть Да (недавно добавлено)
Интегрируйте свои данные сегодня!
Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.
В этом руководстве мы поможем вам понять различные характеристики MySQL и PostgreSQL, чтобы вы могли определить, какая из них лучше для вашего варианта использования. Не стесняйтесь переходить к наиболее интересным разделам:
Общий обзор MySQL и PostgreSQL
Почему разработчики предпочитают одного другому?
Поддержка пользователей MySQL vs.PostgreSQL
MySQL или PostgreSQL быстрее?
Какие языки программирования они поддерживают?
С какими операционными системами они работают?
Как они индексируются?
Чем отличается кодирование?
Общий обзор MySQL и PostgreSQL
Интегрируйте свои данные сегодня!
Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.
MySQL: общий обзор
MySQL — самая популярная в мире СУБД (в 2019 году ее использовали 39% разработчиков) — это быстрая, надежная, универсальная система управления реляционными базами данных. Хотя ему не хватает обширных возможностей PostgreSQL, он отлично подходит для широкого спектра приложений, особенно веб-приложений.
Фактически, MySQL — лучший выбор для масштабируемых веб-приложений — отчасти потому, что он входит в стандартную комплектацию стека LAMP (набор веб-приложений с открытым исходным кодом, состоящий из Linux, HTTP-сервера Apache, MySQL и PHP).Кроме того, популярные системы управления контентом, такие как Drupal, Joomla и WordPress, полагаются на MySQL, поэтому вы можете найти MySQL практически везде в Интернете.
Вот некоторые дополнительные характеристики MySQL :
Открытый исходный код: MySQL — это бесплатная система управления реляционными базами данных (РСУБД) с открытым исходным кодом.
Долгая история: MySQL впервые стал доступен с 1995 года.
Поддерживается Oracle: Oracle владеет и обслуживает MySQL и предлагает расширенные (платные) версии MySQL с дополнительными услугами, проприетарными плагинами, расширениями и поддержкой пользователей.
Сообщество поддержки: Сообщество преданных волонтеров готово помочь с устранением неполадок, когда это необходимо.
Стабильный и надежный: Пользователи соглашаются с тем, что MySQL является очень стабильной СУБД, если вы поддерживаете свои базы данных в «порядке» и выполняете регулярное обслуживание.
Возможности MVCC: MySQL теперь предлагает функции управления одновременным выполнением нескольких версий (MVCC). Функция, которой PostgreSQL более известен (подробнее об этом мы поговорим ниже).
Частые обновления: MySQL извлекает выгоду из частых обновлений с новыми функциями и улучшениями безопасности. Последнее обновление — версия 8.0.16 от 25 апреля 2019 г.
4.3-звездочный рейтинг: MySQL получил 4.3-звездочный рейтинг (из 5 звезд) по 1261 отзывам на G2Crowd.
Вот отличный итог MySQL от обозревателя G2Crowd:
MySQL — это бесплатная, стабильная система управления базами данных с открытым исходным кодом, которую можно использовать в производственных приложениях.Это легкая база данных, которую разработчики могут установить и использовать на рабочих серверах приложений с большими многоуровневыми приложениями, а также на настольных компьютерах. Его можно установить на всех платформах, таких как Windows, Linux и Mac. Это безопасно и не уязвимо для каких-либо уязвимостей.
MySQL может похвастаться некоторыми известными пользователями:
Facebook
Google
Flickr
GitHub
НАСА
Netflix
Spotify
Тесла
Twitter
Убер
ВМС США
WeChat
Википедия
YouTube
Zappos
Zendesk
Интегрируйте свои данные сегодня!
Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.
PostgreSQL: общие характеристики

PostgreSQL воспринимается как идеальное решение для выполнения сложных операций с большими объемами данных. Это потому, что PostgreSQL лучше справляется с чрезвычайными ситуациями с базами данных (мы поговорим об этом позже).
PostgreSQL «имеет больше возможностей», чем другие системы управления базами данных (пользователи подтверждают это). Кроме того, PostgreSQL является расширяемым, «потому что его работа управляется каталогом».Другими словами, он не просто хранит информацию о таблицах и столбцах; он позволяет вам определять типы данных, типы индексов и функциональные языки.
Дополнительные моменты, которые отличают PostgreSQL, — это то, что он объектно-реляционный, ACID-совместимый, высокопараллельный и предлагает поддержку NoSQL (честно говоря, MySQL также предлагает поддержку NoSQL, начиная с версии 8.0).
Наконец, хотя PostgreSQL не является самой «популярной» системой баз данных в мире, за последние два года она получила награду «База данных года» как самая быстрорастущая СУБД.
Вот некоторые дополнительные характеристики PostgreSQL :
Открытый исходный код: PostgreSQL — это бесплатная объектно-реляционная система управления базами данных (ORDBMS) с открытым исходным кодом. Как ORDBMS, а не RDBMS, PostgreSQL обеспечивает функциональность как объектно-ориентированной, так и реляционной базы данных.
Настраиваемый: Вы можете настроить PostgreSQL, разработав плагины, чтобы СУБД соответствовала вашим требованиям. PostgreSQL также позволяет включать пользовательские функции, созданные с помощью других языков программирования, таких как C / C ++, Java и других.
Долгая история: PostgreSQL доступен с 1988 года.
Частые обновления: Последнее обновление PostgreSQL было версией 11.3 от 9 мая 2019 г.
Либеральная лицензия с открытым исходным кодом: PostgreSQL предлагает обширную лицензию с открытым исходным кодом, которая позволяет вам использовать, изменять и распространять СУБД по своему усмотрению.
MVCC Особенности: PostgreSQL была первой СУБД, в которой реализованы функции управления одновременным доступом нескольких версий (MVCC).
Сообщество поддержки: Преданное сообщество разработчиков и волонтеров готово помочь, когда это необходимо. Также доступны частные сторонние службы поддержки. Это же сообщество поддерживает PostgreSQL и обновляет платформу через глобальную группу разработчиков PostgreSQL.
4,4-звездочный рейтинг: Имеет 4,4-звездочный обзор (из 5 звезд) на основе 415 отзывов на G2Crowd.
Вот отличный итог PostgreSQL от пользователя G2Crowd:
PostgreSQL — один из самых интересных вариантов в реляционных базах данных с открытым исходным кодом.Это бесплатно… кроме того, сегодня он предлагает множество дополнительных опций. Фактически, на сегодняшний день он считается наиболее продвинутым ядром СУБД. В Postgres нет необходимости использовать блокировки чтения при выполнении транзакции, что дает нам большую масштабируемость. Кроме того, этим инструментом управляет не человек или компания, а сообщество разработчиков, которое помогает нам упростить и ускорить нашу работу.
Среди пользователей
PostgreSQL:
яблоко
БиоФарм
Cisco
Debian
Etsy
Facebook
Fujitsu
IMDB
Instagram
Macworld
Красная шляпа
Skype
Spotify
Sun Microsystem
Yahoo

Интегрируйте свои данные сегодня!
Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.

Почему разработчики предпочитают одного другому?
PostgreSQL как вариант с «богатым набором функций» получает множество фанатских отзывов от разработчиков. Как вы увидите в описании ниже, у него есть много наворотов. Тем не менее, когда дело доходит до проектирования базы данных, простота, легкость и другие характеристики MySQL имеют большее значение для определенных случаев использования. В этом отношении СУБД превосходны в разных областях.
Давайте посмотрим на ключевые особенности MySQL и PostgreSQL с точки зрения того, почему разработчики СУБД предпочитают одно другому.
Почему разработчики выбирают MySQL?
Вот некоторые из наиболее важных преимуществ MySQL:
Высокая гибкость и масштабируемость: MySQL позволяет выбирать из широкого диапазона механизмов хранения. Это дает вам гибкость для интеграции данных из различных типов таблиц. MySQL 8.0 поддерживает следующие механизмы хранения:
InnoDB
MyISAM
объем памяти
CSV
Архив
Черная дыра
NDB / NDBCLUSTER
Объединить
Федеративный
пример
A Сосредоточьтесь на скорости и надежности: Не включая некоторые функции SQL, MySQL остается легким, отдавая приоритет скорости и надежности.Скорость MySQL особенно очевидна, когда дело доходит до одновременного выполнения функций только для чтения. Это может сделать его отличным выбором для определенных целей бизнес-аналитики. При этом, если вам нужно выполнить много сложных запросов при больших нагрузках, PostgreSQL может быть лучшим выбором.
Параметры для оптимизации сервера: MySQL предлагает множество вариантов для настройки и оптимизации вашего сервера MySQL, регулируя такие переменные, как sort_buffer_size, read_buffer_size, max_allowed_packet и т. Д.
Простой в использовании и популярный: Популярность MySQL означает, что легко найти администраторов баз данных с большим опытом работы с MySQL. Пользователи также сообщают, что это проще в настройке и не требует такой тонкой настройки, как другие решения СУБД. Это руководство покажет вам, насколько легко новичкам создать свою первую базу данных MySQL. Кроме того, ряд внешних интерфейсов (например, Adminer, MySQL Workbench, HeidiSQL и dbForge Studio) добавляют к MySQL графический интерфейс, который обеспечивает более удобный интерфейс.
СУБД, готовая к работе в облаке: MySQL готов к работе в облаке, и многие облачные платформы предлагают функции MySQL, где они устанавливают и поддерживают вашу базу данных MySQL за плату.
Мультиверсионное управление параллелизмом (MVCC) и соответствие ACID, доступные с движком InnoDB: Механизмом по умолчанию для текущих версий MySQL является InnoDB. Это добавляет соответствие MVCC и ACID. Однако проблемы с поврежденными таблицами могут все еще возникать с InnoDB в MySQL из-за его формата таблицы MyISAM.Согласно MySQL, «даже несмотря на то, что формат таблицы MyISAM очень надежен (все изменения в таблице, сделанные оператором SQL, записываются до того, как оператор возвращается), вы все равно можете получить поврежденные таблицы». Более того, выбор другого двигателя, вероятно, приведет к потере совместимости с MVCC и ACID.
Почему разработчики выбирают PostgreSQL?
Вот некоторые из наиболее важных преимуществ PostgreSQL. Вы уже могли заметить, почему эта СУБД требует немного больше технических знаний:
ORDBMS — это не просто RDBMS: PostgreSQL — это объектно-реляционный язык программирования (ORDBMS), поэтому он служит мостом между объектно-ориентированным программированием и реляционным / процедурным программированием (как это делает C ++).Это позволяет вам определять объекты и наследование таблиц, что приводит к более сложным структурам данных. ORDBMS отлично подходит, когда вы имеете дело с данными, которые не связаны с строго реляционной моделью.
Отлично подходит для сложных запросов: Когда вам нужно выполнить сложные операции чтения-записи, используя данные, требующие проверки, PostgreSQL — отличный выбор. Однако ORDBMS может замедляться при работе с операциями только для чтения (в этом случае MySQL превосходит MySQL).
Поддерживает NoSQL и большое количество типов данных: PostgreSQL — популярный выбор для функций NoSQL. Он изначально поддерживает широкий спектр типов данных, включая JSON, hstore и XML. Вы можете определить исходные типы данных, а также настроить собственные функции.
Разработан для управления сверхбольшими базами данных: PostgreSQL не ограничивает размер ваших баз данных. По словам администратора базы данных Adjust.com, его компания использует PostgreSQL для управления «примерно 4 ПБ [петабайтами] данных».Это 4000 терабайт. Он также утверждает, что их «среда обрабатывает (а затем регистрирует) от 100 до 250 тысяч запросов извне за секунду». Это тяжелая нагрузка!
Управление параллельным выполнением нескольких версий (MVCC): MVCC — одна из наиболее важных причин, по которой компании выбирают PostgreSQL. MVCC позволяет различным читателям и писателям одновременно взаимодействовать с базой данных PostgreSQL и управлять ею. Это устраняет необходимость в блокировке чтения-записи каждый раз, когда кому-то нужно взаимодействовать с данными, что повышает эффективность.MVCC достигает этого с помощью «изоляции моментальных снимков» (как это называет Oracle). Снимки представляют состояние данных в определенный момент времени.
Соответствие ACID: PostgreSQL предотвращает повреждение данных и сохраняет целостность данных на уровне транзакций. Узнайте больше о ценности соответствия PostgreSQL ACID здесь. (Как упоминалось выше, и, честно говоря, MySQL также предлагает возможность соответствия ACID, но могут возникнуть сложности).
Интегрируйте свои данные сегодня!
Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.
Поддержка пользователей MySQL и PostgreSQL
Оба решения СУБД имеют чрезвычайно полезные сообщества для оказания поддержки пользователям в дополнение к платным вариантам поддержки от владельца СУБД или сторонних поставщиков. Вот как они сравниваются:
Поддержка пользователей MySQL
В качестве проекта с открытым исходным кодом MySQL имеет большое сообщество добровольцев, готовых помочь вам бесплатной поддержкой и рекомендациями.Лучший способ получить такую поддержку — на веб-сайтах MySQL и Percona.
Вот что говорит один ИТ-специалист о поддержке клиентов MySQL на G2Crowd:
Что мне больше всего понравилось, так это то, что MySQL — это проект с открытым исходным кодом, а это означает, что в Интернете есть тысячи поддерживающих и бесплатных справочных материалов. Я обнаружил, что это особенно полезно при разрешении сложных ситуаций. Одна из лучших вещей в MySQL — это то, что он настолько популярен, что вы найдете огромное сообщество людей, готовых помочь вам с любой вашей проблемой.
В дополнение к бесплатной поддержке сообщества Oracle (владелец MySQL) предлагает круглосуточную платную поддержку коммерческих версий своих продуктов, которая стоит от 2000 до 10 000 долларов в зависимости от уровня пакета поддержки, который вы хотите приобрести. Кроме того, вы можете самостоятельно устранить неполадки, углубившись в бесплатные книги, руководства и руководства по MySQL, которые можно найти здесь.
Поддержка пользователей PostgreSQL
Как и MySQL, PostgreSQL имеет большое сообщество добровольцев, которые бесплатно дают советы пользователям через IRC и через следующие списки рассылки.Кроме того, вы можете приобрести платную поддержку у сторонних поставщиков. Или вы можете самостоятельно устранить неполадки, просмотрев многочисленные руководства и книги по PostgreSQL, которые можно найти здесь.
Вот что говорит один администратор базы данных о поддержке PostgreSQL в G2Crowd:
… с точки зрения поддержки лучший союзник — это сообщество людей, которые помогают другим через форумы.
Другой обозреватель G2Crowd сказал следующее:
Один недостаток, с которым я столкнулся лично, — это то, что немного сложнее получить поддержку сообщества или Google за результатами.Однако с более широким использованием PostgreSQL поддержка сообщества становится лучше.
В конечном счете, поддержка PostgreSQL может быть немного более сложной, потому что (1) СУБД требует дополнительных технических знаний для настройки и использования; и (2) экспертов по PostgreSQL меньше, чем экспертов по MySQL.
Интегрируйте свои данные сегодня!
Попробуйте Xplenty бесплатно в течение 7 дней. Кредитная карта не требуется.
MySQL или PostgreSQL быстрее?
И MySQL, и PostgreSQL имеют сильную репутацию одних из самых быстрых доступных решений СУБД.Однако что касается самого быстрого , ответ не совсем ясен. По словам Скотта Нойеса на TechTarget:
Легко найти тесты, в которых одна база данных предпочтительнее другой, в зависимости от оборудования, конфигурации и теста. Одна база данных может лучше работать на одноядерной машине с небольшим объемом памяти, в то время как другая может лучше использовать возможности масштабирования до нескольких ядерных процессоров. Один может вести чтение, а другой — запись.
TechTarget сообщает, что тесты скорости дают противоречивые результаты.Например, Windows Skills говорит, что MySQL быстрее, а Benchw говорит, что PostgreSQL быстрее. В конечном итоге скорость будет зависеть от того, как вы используете базу данных. PostgreSQL, как известно, быстрее обрабатывает массивные наборы данных, сложные запросы и операции чтения-записи. Между тем известно, что MySQL работает быстрее с командами только для чтения.
Какие языки программирования они поддерживают?
MySQL и Postgres поддерживают многие из одних и тех же языков с небольшими различиями.
MySQL Поддерживаемые языки
MySQL предлагает поддержку следующих языков:
C / C ++
Delphi
Erlang
Перейти
Джава
Лисп
Node.js
Perl
PHP
R
PostgreSQL Поддерживаемые языки
PostgreSQL предлагает поддержку немного большего количества языков:
C / C ++
Delphi
Erlang
Перейти
Джава
JavaScript
Лисп
.Сеть
Python
R
Tcl
Другие языки программирования
С какими операционными системами они работают?
Вот что вам нужно знать о требованиях к операционной системе для MySQL по сравнению с PostgreSQL:
Совместимость с ОС MySQL
MySQL предлагает облачную поддержку, локальную установку и совместим со следующими операционными системами и форматами:
Windows
MacOS
Linux (Ubuntu, Debian, Generic, SUSE Linux Enterprise Server, Red Hat Enterprises, Oracle)
Oracle Solaris
Fedora
FreeBSD
Сборка с открытым исходным кодом
Совместимость с ОС PostgreSQL
PostgreSQL предлагает облачную поддержку и локальную установку, и пользователи обычно устанавливают PostgreSQL на серверах Linux.Кроме того, ORDBMS предлагает PostgREST REST API. По данным сайта PostgreSQL:
PostgREST — это автономный веб-сервер, который превращает вашу базу данных PostgreSQL непосредственно в RESTful API. Структурные ограничения и разрешения в базе данных определяют конечные точки и операции API.
PostgreSQL доступен для следующих операционных систем:
MacOS
Солярис
Windows
BSD (FreeBSD, OpenBSD)
Linux (семейство Red Hat Linux, включая варианты CentOS / Fedora / Scientific / Oracle, Debian GNU / Linux и производные, Ubuntu Linux и производные, SuSE и OpenSuSE, другие операционные системы Linux)
Интегрируйте свои данные сегодня!
Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.
Как они индексируются?
Индексы
повышают производительность базы данных за счет ускорения запросов SQL при работе с большими таблицами данных. Без индексации базы данных запросы будут медленными и чрезмерно обременительными для СУБД. И MySQL, и PostgreSQL предлагают разные варианты индексации.
Типы индексации MySQL
Типы индексов MySQL включают:
Индексы, хранящиеся в B-деревьях, такие как INDEX, FULLTEXT, PRIMARY KEY и UNIQUE.
Индексы, хранящиеся в R-деревьях, например индексы, найденные в типах пространственных данных.
Индексы хеширования и инвертированные списки при использовании индексов FULLTEXT.
Типы индексов PostgreSQL
Типы индексов PostgreSQL включают:
Индексы хеширования и индексы B-дерева.
Частичные индексы, которые организуют информацию только из части таблицы.
Индексы выражений, которые создают индекс на основе функций выражения, а не значений столбцов.
Чем отличается кодирование?
Вот три различия между кодированием с MySQL и PostgreSQL, о которых вам следует знать:
Чувствительность к регистру
Наборы символов и строки по умолчанию
IF и IFNULL против операторов CASE
Чувствительность корпуса
MySQL не учитывает регистр . При написании запросов вам не нужно использовать заглавные буквы в строках, поскольку они появляются в базе данных.PostgreSQL чувствителен к регистру. Вам нужно использовать строки в точности так, как они отображаются в базе данных, иначе запрос не будет выполнен.
Наборы символов и строки по умолчанию
В некоторых версиях MySQL — это , необходимое для преобразования наборов символов и строк в UTF-8. В PostgreSQL не обязательно для преобразования наборов символов и строк в UTF-8. Кроме того, в PostgreSQL запрещен синтаксис UTF-8.
IF и IFNULL в сравнении с CASE
В MySQL совершенно нормально использовать операторы IF и IFNULL. В PostgreSQL операторы IF и IFNULL не работают. Вместо этого вам нужно использовать оператор CASE.

PostgreSQL против MySQL Trends

Заключение
В заключение, выбор между MySQL и PostgreSQL часто сводится к следующим вопросам:
Вам нужна многофункциональная база данных, способная обрабатывать сложные запросы и большие базы данных? PostgreSQL может быть вашим выбором.
Вам нужна более простая база данных, которая относительно проста в настройке и управлении, быстрая, надежная и понятная? MySQL может быть вашим выбором.
При этом, как вы видели из этого руководства, ваше решение может быть немного более тонким, чем ваши ответы на эти простые вопросы. В Xplenty нам интересно узнать, какое из этих решений СУБД вы используете в настоящее время и почему вы выбрали одно вместо другого. Пожалуйста, напишите нам и дайте нам знать!
Интегрируйте свои данные сегодня!
Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.
Xplenty: Решения для интеграции данных для MySQL и PostgreSQL
Интеграция данных из СУБД MySQL или PostgreSQL в вашу платформу бизнес-аналитики может быть источником постоянных препятствий и проблем. Здесь может помочь Xplenty. В Xplenty мы предлагаем чрезвычайно мощное и интуитивно понятное решение ETL для извлечения информации практически из любого источника данных (независимо от того, используете ли вы MySQL, PostgreSQL или что-то еще), а затем преобразовываем данные для беспрепятственной интеграции с вашим хранилищем данных бизнес-аналитики.Свяжитесь с Xplenty сейчас, чтобы узнать, как наши решения могут решить ваши проблемы интеграции данных.
.
PostgreSQL против MySQL: в чем разница?
Home
Тестирование
Back
Agile Testing
BugZilla
Cucumber
Тестирование базы данных
Тестирование ETL
0003
Jmeter
Jmeter Load Backing
Ручное тестирование
Мобильное тестирование
Mantis
Почтальон
QTP
Назад
Центр качества (ALM)
RPA
SAP Testing
Selenium
SAP
Назад
ABAP
APO
Начало er
Basis
BODS
BI
BPC
CO
Назад
CRM
Crystal Reports
FICO
Pay4
HR
Назад
PI / PO
PP
SD
SAPUI5
Безопасность
Менеджер решений
Successfactors
SAP Tutorials
Назад
Web
Angular
Web
ASP.Net
C
C #
C ++
CodeIgniter
СУБД
JavaScript
Назад
Java
JSP
Kotlin
Linux
Linux
Kotlin
Linux
js
Perl
Назад
PHP
PL / SQL
PostgreSQL
Python
ReactJS
Ruby & Rails
Scala
SQL
000
SQL
000
0003 SQL
000
0003 SQL
000
UML
VB.Net
VBScript
Веб-службы
WPF
Обязательно учите!
Назад
Бухгалтерский учет
Алгоритмы
Android
Блокчейн
Business Analyst
Создание веб-сайта
CCNA
Облачные вычисления
00030003 COBOL
9000 Compiler
9000 Встроенные системы
00030003 9000 Compiler 9000
Ethical Hacking
Учебные пособия по Excel
Программирование на Go
IoT
ITIL
Jenkins
MIS
Сети
Операционная система
00030003
Назад
Управление проектами Обзоры
Salesforce
SEO
Разработка программного обеспечения
VB A
Big Data
Назад
AWS
BigData
Cassandra
Cognos
Хранилище данных
0003
HBOps
0003
HBOps
0003
MicroStrategy
Монг
.
PostgreSQL и MySQL: всестороннее сравнение
Известен как Самая продвинутая база данных с открытым исходным кодом в мире. самая популярная в мире база данных с открытым исходным кодом .
Разработка PostgreSQL — проект с открытым исходным кодом . MySQL — это продукт с открытым исходным кодом .
Произношение post gress queue ell my ess queue ell
Лицензирование Лицензия в стиле MIT Стандартная общественная лицензия GNU
Язык программирования реализации C C C
Инструмент с графическим интерфейсом PgAdmin MySQL Workbench
ACID Да Да
Механизм хранения Один механизм хранения Несколько механизмов хранения g., InnoDB и MyISAM
Полнотекстовый поиск Да Да (ограниченно)
Удалить временную таблицу Нет `TEMP` или `TEMPORARY` ключевое слово в заявлении
091 DROP TABLE
000
000
Тип данных
Да (поддерживается CTE, начиная с MySQL 8.0)
9000 Поддержите ключевое слово `TEMP` или `TEMPORARY` в операторе `DROP TABLE` , который позволяет удалить только временную таблицу.
`DROP TABLE` Поддержка опции `CASCADE` для удаления зависимых объектов таблицы e.г., таблицы и представления. Не поддерживает опцию `CASCADE` .
`TRUNCATE TABLE` PostgreSQL `TRUNCATE TABLE` поддерживает больше функций, таких как `CASCADE` , `RESTART IDENTITY` , `CONTINUE IDENTITY` , транзакционная безопасность и т. Д. MySQL `TRUNCATE TABLE не поддерживает TRUNCATE TABLE CASCADE и безопасная транзакция, т.е. после удаления данных их нельзя откатить.`
Столбец с автоматическим приращением `SERIAL` `AUTO_INCREMENT`
Столбец идентификаторов Да Нет
Да Да Да Да Поддержка Да многие расширенные типы, такие как массив, hstore и пользовательский тип. Стандартные типы SQL
Целое число без знака Нет Да
Логический тип Да Использовать `TINYINT (1)` внутренне для логического адреса
Нет
Установить значение по умолчанию для столбца Поддерживать как постоянный, так и функциональный вызов Должен быть константой или `CURRENT_TIMESTAMP` для `TIMESTAMP` или `DATETIME` столбцов
CTE
`EXPLAIN` вывод Более подробно Менее подробный
Материализованные представления Да Нет
Ограничение CHECK Да, начиная с версии 8.0.16 Поддерживается Да До этого MySQL просто игнорировал ограничение CHECK)
Наследование таблиц Да Нет
Языки программирования для хранимых процедур Ruby, Perl, Python, TCL, PL / pgSQL, SQL, JavaScript и т. Д. Синтаксис SQL: 2003 для хранимых процедур
`FULL OUTER JOIN` Да Нет
`INTERSECT` Да Нет
Нет
0
9004
с версии2)
0004 Task Schedule
Частичные индексы Да Нет
Растровые индексы Да Нет
Индексы Expression Да Нет
Да. MySQL поддерживает покрывающие индексы, которые позволяют извлекать данные, просматривая только индекс, не касаясь данных таблицы. Это выгодно в случае больших таблиц с миллионами строк.
Триггеры Триггеры поддержки, которые могут срабатывать для большинства типов команд, кроме тех, которые влияют на базу данных глобально, например, роли и табличные пространства. Ограничено некоторыми командами
Разбиение на разделы RANGE, LIST RANGE, LIST, HASH, KEY и составное разделение с использованием комбинации RANGE или LIST с подразделами HASH или KEY
Task Schedule Запланированное событие
Масштабируемость соединения Каждое новое соединение - это процесс ОС Каждое новое соединение - это поток ОС
.
MySQL против PostgreSQL для веб-приложений
Переполнение стека
Около
Продукты
Для команд
Переполнение стека
Общественные вопросы и ответы
Переполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегами
Вакансии
Программирование и связанные с ним технические возможности карьерного роста
Талант
Нанимайте технических специалистов и создавайте свой бренд работодателя
Реклама
Обратитесь к разработчикам и технологам со всего мира
О компании
Загрузка…
.
No related posts.
Share :

Навигация по записям
Previous: Увеличить это какой знак: Увеличить на… Увеличить в… — урок. Математика, 3 класс.
Next: Id owner: Как достать owner_id и post_id вконтакте? — Хабр Q&A
Related Post
Html код таблицы для сайта: Создаем таблицу на html-странице : WEBCodius
Jquery vue js: Забываем о jQuery с Vue.js (Часть 1) | by Vlad Kopenkin
Майкрософт вики: Microsoft | Microsoft вики | Fandom
Добавить комментарий Отменить ответ
Ваш адрес email не будет опубликован. Обязательные поля помечены *
Комментарий *
Имя *
Email *
Сайт

Рубрики
Jquery
Mysql
Php
Для чайников
Разное
Сервер
Советы
Установка
Декабрь 2024
Пн Вт Ср Чт Пт Сб Вс
1
2 3 4 5 6 7 8
9 10 11 12 13 14 15
16 17 18 19 20 21 22
23 24 25 26 27 28 29
30 31
« Ноя
Архивы
Ноябрь 2024
Октябрь 2024
Ноябрь 2021
Октябрь 2021
Сентябрь 2021
Август 2021
Июль 2021
Июнь 2021
Май 2021
Апрель 2021
Март 2021
Февраль 2021
Январь 2021
Декабрь 2020
Ноябрь 2020
Октябрь 2020
Сентябрь 2020
Август 2020
Июль 2020
Июнь 2020
Май 2020
Апрель 2020
Март 2020
Февраль 2020
Январь 2020
Декабрь 2019
Ноябрь 2019
Октябрь 2019
Сентябрь 2019
Август 2019
Июль 2019
Июнь 2019
Май 2019
Апрель 2019
Март 2019
Февраль 2019
Январь 2019
Декабрь 2018
Ноябрь 2018
Октябрь 2018
Сентябрь 2018
Август 2018
Июль 2018
Июнь 2018
Май 2018
Апрель 2018
Март 2018
Февраль 2018
Январь 2018
Февраль 1970
Январь 1970
2024 © Все права защищены. Карта сайта

Особенности	PostgreSQL	MySQL
ANSI SQL совместимость	Близка к стандарту ANSI SQL	Следует некоторым стандартам ANSI SQL
Скорость работы	Медленнее	Быстрее
Вложенные селекты	Да	Нет
Транзакации	Да	Да, однако должен использоваться тип таблицы InnoDB
Ответ базы данных	Да	Да
Поддержка внешних ключей	Да	Нет
Представления	Да	Нет
Хранимые процедуры	Да	Нет
Триггеры	Да	Нет
Unions	Да	Нет
Полные Joins	Да	Нет
Ограничители целостности	Да	Нет
Поддержка Windows	Да	Да
Вакуум (очистка)	Да	Нет
ODBC	Да	Да
JDBC	Да	Да
Различные типы таблиц	Нет	Да

Сравнение характеристик	PostgreSQL 10	MySQL 8
Общее табличное выражение (CTE)	Есть	Да (недавно добавлено)
Декларативное разбиение на разделы	Да (недавно добавлено)	Есть
Полнотекстовый поиск	Есть	Есть
Географическая информационная система (GIS) / Пространственная справочная система (SRS)	Есть	Да (обновлено)
JSON	Есть	Да (обновлено)
Логическая репликация	Да (недавно добавлено)	Есть
Полусинхронная репликация	Да (недавно добавлено)	Есть
Оконные функции	Есть	Да (недавно добавлено)

Mysql vs postgresql vs: Сравнение MySQL и PostgreSQL | Losst

Сравнение MySQL и PostgreSQL | Losst

Системы управления базами данных

Краткая история

MySQL

Postgresql

Хранение данных

MySQL

Postgresql

Стандарт SQL

MySQL

Postgresql

Возможности обработки

MySQL

Postgresql

Производительность

MySQL

Postgresql

Типы данных

MySQL

Postgresql

Разработка

MySQL

Postgresql

Выводы

PostgreSQL vs MySQL / Хабр

MySQL против PostgreSQL | PostgreSQL

MySQL vs PostgreSQL

MySQL vs PostgreSQL | Блог Валерия Леонтьева

json в PostgreSQL vs Mysql vs Mongodb / Хабр

Что, черт возьми, вообще происходит?

Исходные данные и некоторые детали

Картинки

Select

Insert

Insert (custom configuration)

Update

Update (custom configuration)

Table/index size

I have a bad feeling about this

PostgreSQL против MySQL: важные различия

Критические отличия Postgres от MySQL:

Интегрируйте свои данные сегодня!

Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.

Общий обзор MySQL и PostgreSQL

Почему разработчики предпочитают одного другому?

Поддержка пользователей MySQL vs.PostgreSQL

MySQL или PostgreSQL быстрее?

Какие языки программирования они поддерживают?

С какими операционными системами они работают?

Как они индексируются?

Чем отличается кодирование?

Общий обзор MySQL и PostgreSQL

Интегрируйте свои данные сегодня!

Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.

MySQL: общий обзор

Интегрируйте свои данные сегодня!

Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.

PostgreSQL: общие характеристики

Интегрируйте свои данные сегодня! Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.

Интегрируйте свои данные сегодня!

Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.

Почему разработчики предпочитают одного другому?

Почему разработчики выбирают MySQL?

Почему разработчики выбирают PostgreSQL?

Интегрируйте свои данные сегодня!

Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.

Поддержка пользователей MySQL и PostgreSQL

Поддержка пользователей MySQL

Поддержка пользователей PostgreSQL

Интегрируйте свои данные сегодня!

Попробуйте Xplenty бесплатно в течение 7 дней. Кредитная карта не требуется.

MySQL или PostgreSQL быстрее?

Какие языки программирования они поддерживают?

MySQL Поддерживаемые языки

PostgreSQL Поддерживаемые языки

С какими операционными системами они работают?

Совместимость с ОС MySQL

Совместимость с ОС PostgreSQL

Интегрируйте свои данные сегодня!

Интегрируйте свои данные сегодня!
Попробуйте Xplenty бесплатно в течение 7 дней.Кредитная карта не требуется.