Отличие mysql от postgresql: PostgreSQL vs MySQL / Блог компании Mail.ru Group / Хабр

Содержание

PostgreSQL vs MySQL / Блог компании Mail.ru Group / Хабр

В преддверии своего доклада на конференции 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. Даже из коробки он у вас будет работать, поможет в разработке, сэкономит время, и вам проще будет расти.

что выбрать в вашем случае?

Вот некоторые характеристики PostgreSQL:

Открытый исходный код: PostgreSQL — это свободная и открытая объектно-реляционная система управления базами данных (ОРСУБД). В отличие от обычных РСУБД. Она позволяет использовать как объектно-ориентированные, так и реляционные базы данных.
Расширенные настройки: вы можете разработать собственные плагины и настроить PostgreSQL под свои нужды. PostgreSQL также позволяет активировать нестандартные функции, написанные на других языках программирования, таких как C/C++, Java и других.
Долгая история: PostgreSQL развивается с 1988 года.
- Частые обновления: так, последним обновлением на март 2020 года в PostgreSQL является версия 12.2 от 13 февраля 2020 года.
Либеральная открытая лицензия: у PostgreSQL щедрая опенсорсная лицензия, которая позволяет использовать, изменять и распространять СУБД как вам угодно.
Функции MVCC: PostgreSQL была первой СУБД, которая реализовала функции управления параллельным доступом посредством многоверсионности (MVCC).
Отзывчивое сообщество: преданное сообщество разработчиков и активистов всегда готово помочь. Кроме того, можно воспользоваться платной поддержкой от сторонних компаний. Сообщество поддерживает PostgreSQL и обновляет платформу через группу PostgreSQL Global Development Group.
Высокая оценка пользователей: у PostgreSQL рейтинг 4,4 звезды (из пяти) по итогам 452 отзывов на G2 Crowd.

«PostgreSQL — одна из самых интересных РСУБД с открытым исходным кодом. Она бесплатная, кроме того, предлагает много продвинутых опций. На сегодняшний день PostgreSQL считается самой продвинутой системой управления базами данных. При совершении транзакции тут не нужно ставить блокировки чтения, что дает лучшую масштабируемость. Также этот инструмент управляется не человеком или компанией, а сообществом разработчиков».

Отзыв о PostgreSQL от рецензента на G2 Crowd

Среди пользователей PostgreSQL: Apple, BioPharm, Cisco, Debian, Etsy, Facebook, Fujitsu, IMDB, Instagram, Macworld, Red Hat, Skype, Spotify, Sun Microsystem, Yahoo.

Когда разработчики выбирают MySQL, а когда PostgreSQL

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

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

Основные преимущества MySQL для разработчиков

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

InnoDB
MyISAM
Memory
CSV
Archive
Blackhole
NDB/NDBCLUSTER
Merge
Federated
Example

Скорость и надежность: отказавшись от некоторых функций SQL, система MySQL сохранила легкость, отдавая приоритет скорости и надежности. Ее скорость особенно очевидна, когда речь заходит о высокопараллельных операциях без записи в БД (только чтение). Это отличный выбор для определенных приложений бизнес-аналитики. Но если вам нужно выполнить много сложных запросов под большой нагрузкой, то PostgreSQL может справиться лучше.

Варианты оптимизации сервера: MySQL предлагает множество вариантов настройки и оптимизации вашего сервера MySQL путем настройки переменных, таких как sort_buffer_size, read_buffer_size, max_allowed_packet и так далее.

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

Кроме того, ряд сервисов фронтенда — такие как Adminer, MySQL Workbench, HeidiSQL и dbForge Studio, добавляют к MySQL графический интерфейс, более удобный и простой, чем работа из командной строки.

Облачная СУБД: MySQL Database хорошо подходит для использования в облаке, многие облачные платформы предлагают соответствующие платные услуги: они готовы установить и поддерживать вашу базу данных.

Управление параллельным доступом посредством многоверсионности (MVCC) и соответствие ACID с движком InnoDB: в текущих версиях MySQL движок по умолчанию — это InnoDB. Он обеспечивает функциональность MVCC и соответствие требованиям ACID. Однако из-за формата таблиц MyISAM в InnoDB на MySQL все равно мог

Базовые различия при работе с базами данными MySQL и PostgreSQL Дилетантский обзор / Хабр

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

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

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

Что я бы выделил на этапе компиляции из исходников этих двух БД,

1.1 PostgreSQL не имеет типы движков (MySQL — innodb, mysql, archive и т.д), но имеет кучу расширений, подобно PHP, которые можно дополнительно ставить, расширяя возможности. Создается впечатление, что PostgreSQL это своего рода каркас, который набиваешь функциональностью.

1.2 Разворачивание сервера MySQL сводиться лишь по сути к запуску сервера (systemctl start mysql.conf, service mysql start), тогда как в PostgreSQL нужно завести отдельного пользователя (в операционной системе) для запуска сервера, развернуть отдельно кластер (крутое слово, но по сути тоже самое, что и в MySQL — несколько баз данных на одном сервере)

1.3 Физическое указание расположения новых таблиц на диске (табличное пространство) на уровне SQL для PostgreSQL.

и т.д.

2. Различия в клиентах при запросах к БД — psql и mysql.

2.1 Что явно не хватает в MySQL, так это подобие команды \watch в psql, которая позволяет, указав секунды, повторять выполнение SQL запроса (аналог утилиты watch -n). Это обычно удобно для того, чтобы отслеживать как идет миграция (наполнение данных в таблицах)

select NOW() \watch 1;

2.2 В PostgreSQL по умолчанию все выполняемые запросы не отображают время исполнения, в отличие от MySQL, нужно дополнительно указывать команду \timing. Повторное выполнение команды отключает опцию. Такой прием часто встречается во многих настройках PostgreSQL, в отличие от MySQL, где это нужно писать более длинее. При этом, в PostgreSQL, когда смотришь справочную информацию, то рядом в круглых скобочках отображается текущее значение просматриваемой настройки. Очень удобно. Плохо только, что одним шрифтом теста идет, не сразу зрительно быстро воспринимается.

2.3 В PostgreSQL можно быстро просмотреть историю запросов из psql командой \s, тогда как в клиенте MySQL нужно использовать клавиши вверх/вниз задействую функционал readline библиотеки (либо смотреть историю команд отдельно от клиента mysql). Это часто нужно, когда тестируешь повторно запрос на использование индексов. Было бы удобней в PostgreSQL после набора \s вместо копирования запроса, набирать номер запроса, как это делается при profile в MySQL.

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

К примеру, вывод результата select, который не помещается по горизонтали. В обоих клиентах баз данных есть вертикальный вывод. Для MySQL достаточно добавить в конец запроса \G, тогда как в PostgreSQL в начале нужно выполнить \pset expanded. Когда нужно по быстрому просмотреть, вариант PostgreSQL на мой взгляд это не совсем удобно.

4. Особо интересный момент в PostgreSQL, в отличие от MySQL, это более тесная интеграция с bash оболочкой.

Можно из psql выполнять shell команды (наподобие как в vim редакторе :! pwd), сохранять в переменные результат и затем использовать в генерации SQL запросов. В MySQL это все можно тоже сделать, но более длинными и не всегда удобными путями.

5. PostgreSQL выделяется особой любовью к использованию переменных окружения (export) в отличие от MySQL.

Ты это чувствуешь сразу после того, как скомпилировал исходники и начинаешь “разворачивать” сервер, указывая путь к директории базы данных (-D или PGDATA).

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

Сравнение MySQL и PostgreSQL с точки зрения разработчика / Хабр

Аннотация

В статье представлен сравнительный анализ двух бесплатных свободных систем управления базами данных (СУБД): MySQL и PostgreSQL. Анализ ведётся с точки зрения использования этих СУБД в мало- и средненагруженных приложениях. Не рассматриваются вопросы масштабирования и оптимизации под проекты с многомиллионными аудиториями. Не приводятся данные сравнения производительности. Рассматриваются MySQL 5.1 и PostgreSQL 8.3.

Типы данных

Первое с чем приходится сталкиваться разработчику — это доступные типы данных. Проведём сравнение доступных типов данных.

Целые числа и числа с плавающей точкой

Я не буду указывать диапазоны возможных значений, однако укажу информационную ёмкость в байтах.

.                       |MySQL                | PostgreSQL        
TINYINT                 |1 байт               |                   
SMALLINT                |2 байта              | 2 байта           
MEDIUMINT               |3 байта              |                   
INTEGER, INT            |4 байта              | 4 байта           
BIGINT                  |8 байт               | 8 байт            
FLOAT, DOUBLE, REAL     |4 или 8 байт         | 4 или 8 байт      
DECIMAL, NUMERIC        |65 десятичных знаков | без ограничений   
SERIAL, BIGSERIAL       |8 байт               | 4 или 8 байт
BIT                     |он есть              | он есть

Примечание:

1) В MySQL есть поддержка UNSIGNED типов, однако это не входит в стандарт SQL.

2) Для типов с плавающей точкой PostgreSQL использует формат стандарта IEEE 754, поэтому можно хранить значения +Inf, -Inf и NaN, однако использовать эти значения в математических операциях не выйдет.

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

Строки и данные

Размеры указываются в байтах. Не забывайте, что для одного символа UTF-8 может использоваться от 1 до 4 байт.

.                       | MySQL           | PostgreSQL
BINARY, CHAR            | 255             | 10485760
VARCHAR, VARBINARY      | 65535*          | 10485760
TINYBLOB,TINYTEXT       | 2^8             | 
BLOB, TEXT, bytea       | 2^16            | не ограничен
MEDIUMBLOB              | 2^24            | 
LONGBLOB                | 2^32            |

* ограничение вызвано максимальной длиной строки, равной 65535 байтам, но в реальности максимальная длинна гораздо меньше.

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

Чтобы не быть голословным приведу пример — хранение данных пользователя. Предположим, что нам потребовалось хранить о пользователе не только его имя, фамилию и отчество, но адрес и телефоны, да мало ли что мы можем предложить хранить пользователю в своём профиле. С точки зрения SQL для этого должны использоваться типы CHAR и VARCHAR. И вот тут в MySQL приходится решать какая максимальная длинна у фамилии, какая максимальная длинна у имени, какая максимальная длинна у адреса, ибо на всё про всё дано 65535 байт. В то же время в PostgreSQL мы просто указываем в качестве типа для всех столбцов таблицы VARCHAR, куда мы в случае необходимости можем уложить гораздо больше данных, чем нам позволяет MySQL. (Попрошу не предлагать использовать TEXT в MySQL для этих целей.)

Дата и время

Типы даты и времени для двух баз практически идентичны и проблем как правило не вызывают.

Нестандартные типы

Для желающих PostgreSQL предлагает целую группу типов данных для работы, которые напрочь отстутствуют в MySQL: массивы, структуры, типы для хранения IP и MAC адресов, и даже типы для хранения параметров геометрических фигур. Желающие могут самостоятельно ознакомиться с типами данных PostgreSQL.
UPD В MySQL, оказывается, есть типы данных для геометрических фигур подробности в комментариях

Выводы по типам данных

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

Возможности управления данными

Здесь я хочу сравнить две СУБД с точки зрения дополнительного функционала предлагаемого разработчику. Часть этого функционала включена в стандарт SQL.

Хранимые процедуры

Начнём с простейшего — хранимые процедуры. Грубо говоря, в MySQL вообще нет функционала хранимых процедур. Если выражаться более точно, то вообще они есть, но довольно условны. Так, например, при включённой репликации хранимые процедуры могут быть только readonly. Так что довольно популярная схема ограничения прав пользователя через хранимые процедуры вовсе не реализуема на MySQL.

Индексы и ключи

На этом фронте MySQL тоже не блещет своими возможностями. Ограничение в 1000 байт на размер ключа — куда это годится? Допустим, я разрешаю своим пользователям создавать учётные записи на любом языке (UTF-8). В качестве максимальной длинны логина я выбираю 512 символов. Так как логины должны быть уникальными, прихожу к выводу, что нужно наложить уникальный ключ на столбец, и, как выясняется, не могу, ибо ключ не вписывается в 1000 байт. Приходится идти на уступки и делать уникальность только по первым 333 символам. Кто не верит, может самостоятельно посмотреть на результат create table t( t varchar(512), key(t)) character set = utf8.
PostgreSQL такими комплексами не страдает, а просто делает уникальный ключ необходимого размера.

Проверка данных на этапе добавления

В стандарте SQL была предусмотрена инструкция CHECK, которая задаёт выражение, которому должны удовлетворять данные добавляемые в таблицу. В руководстве MySQL об этой инструкции сказано предельно просто «The CHECK clause is parsed but ignored by all storage engines.» Больше добавить мне к этому нечего, в постгре, как и ожидалось, всё в порядке.

Транзакции и внешние ключи

По умолчанию в MySQL для таблиц используется движок MyISAM, который не поддерживает ни транзакций ни внешних ключей. Это сложилось исторически и у такого подхода есть оправдание, если рассматривать работу с БД с точки производительности. Можно просто заметить, что, если вам нужны транзакции и внешние ключи, то использование storage engine InnoDB обязательно. Естественно в PostgreSQL транзакции и вешние ключи полностью функциональны.

Выводы

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

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

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

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

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

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

Некоторые интересные отличия PostgreSQL от MySQL

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

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

В PostgreSQL вы можете использовать курсоры. Представьте, что некоторый запрос возвращает гигабайт данных. Вы вынуждены передать весь этот гигабайт по сети (если СУБД работает на отдельном сервере) и сохранить его в памяти перед тем, как что-то с ним делать. Даже если используемый вами драйвер поддерживает функции типа fetch_next_row, в действительности он все равно сначала кладет весь результат выполнения запроса в память. С помощью курсоров вы можете не только забирать данные кусками, тем самым обрабатывая их в постоянном объеме памяти, но и свободно перемещаться по ним в разные стороны. Например, вы можете прочитать первые 100 строк, потом посмотреть 10001-ую, и в зависимости от ее значения перейти к последней строке или вообще закрыть курсор.

Не менее интересным механизмом являются функциональные индексы. Допустим, вам нужно хранить имя и фамилию пользователя в отдельных столбцах и с учетом регистра, однако поиск пользователей при этом происходит по полному имени и без учета регистра. Если СУБД не поддерживает функциональные индексы, вы вынуждены создать в таблице дополнительное поле со значением LOWER(first_name || ' ' || last_name), построить по нему индекс и поддерживать в этом поле правильное значение. Если такого рода вариантов запросов десять, вам понадобится десять дополнительных столбцов. Функциональные индексы, как и следует из названия, позволяют построить индекс по произвольной функции, избежав тем самым всех описанных проблем. Например, вы можете эффективно выполнять запросы с условиями вроде WHERE sin(x) > 0.45 AND sin(x) < 0.46.

PostgreSQL может строить индексы только по части строк в таблице. Этот механизм называется частичными индексами. Например, если вы ходите в базу с запросами вроде SELECT * FROM logs WHERE ip > inet '192.168.0.0' AND ip < inet '192.168.0.255' AND level = 'error', то можете построить индекс по полю ip только для строк, значение поля level которых равно 'error'. Это имеет смысл, если логов много, а строк со значением level = 'error' мало. С помощью частичных индексов вы получаете более быстрые запросы и меньшие накладные расходы (место на диске, время добавления новых строк), чем в случае использования обычных индексов.

PostgreSQL поддерживает bitmap scans. Например, вам нужно выполнить запрос с условием WHERE a = 1 AND b = 2. В MySQL вы можете построить индекс по нескольким столбцам, что позволяет эффективно выполнять этот запрос, а также запросы WHERE a = 1, WHERE a > 1, но не WHERE b = 2 или WHERE b > 10 AND b < 20. Для эффективного выполнения двух последних запросов понадобится дополнительный индекс по полю b. PostgreSQL также поддерживает индексы по нескольким столбцам. Однако, благодаря поддержке bitmap scans, в PostgreSQL вы можете построить отдельный индекс по a, отдельный индекс по b и использовать эти индексы во всех приведенных запросах, даже с участием в условии обоих полей. Помимо одновременного использования нескольких индексов bitmap scans позволяет эффективно выполнять запросы с условиями вроде WHERE a = 4 OR a = 8 OR a = 15 OR a = 16. Работает это очень просто. Запрос разбивается на несколько подзапросов, каждый из которых выполняется с использованием подходящих индексов, а потом результаты выполнения этих запросов объединяются OR’ом или AND’ом.

В PostgreSQL есть поддержка огромного количества типов данных на все случаи жизни. Помимо традиционных типов, таких, как целые числа и строки (кстати, размер varchar в PostgreSQL не ограничен 65536-ю символами, как в MySQL), в вашем распоряжении есть UUID, IP- и MAC-адреса, точки, круги и другие геометрические фигуры, XML и JSON, а также массивы и диапазоны значений. Если встроенных типов недостаточно, вы можете объявить собственные типы и функции для работы с ними.

PostgreSQL предоставляет различные типы индексов помимо классических Hash и B-Tree индексов. Например, с помощью GiST и SP-GiST индексов можно найти все точки, находящиеся внутри заданного круга. GiST индексы также позволяют, например, сортировать заправки по расстоянию до ваших текущих координат и делать прочие операции с геоданными. GIN индексы предназначены для работы с типами, которые могут содержать более одного значения. Например, с помощью индексов этого типа вы можете найти все массивы, содержащие заданный элемент. Как GIN, так и GiST индексы могут использоваться для полнотекстового поиска. Притом в PostgreSQL полнотекстовый поиск работает реально не хуже, чем в Sphinx, чего про MySQL сказать никак нельзя. Еще из интересных видов индексов следует отметить индексы BRIN (не очень быстрый индекс, зато супер компактный) и Bloom (фильтр Блума).

Из прочих, но при этом не менее важных, отличий MySQL от PostgreSQL хотелось бы отметить поддержку в последнем регулярных выражений, savepoint’ов (это почти что вложенные транзакции), рекурсивных запросов, наследования таблиц, возможность написания триггеров и хранимых процедур на Tcl, Perl и Python, а также логирования медленных запросов с указанием времени с точностью до миллисекунд. Разумеется, отличия на этом не заканчиваются.

Нельзя не обратить внимание и на несколько моментов, не имеющих отношения к функционалу PostgreSQL и MySQL. В качестве преимуществ PostgreSQL над прочими РСУБД нередко отмечается надежность кода. Однажды я слушал доклад Константина Осипова, на котором, помимо прочего, он упомянул один занятный эксперимент. Был написан генератор случайных неправильных SQL-запросов в стиле WHERE * FROM SELECT. Большинству людей никогда не придет в голову писать такое. Эти запросы скармливались MySQL. В результате был найден десяток запросов, роняющих СУБД. Спрашивается, если в MySQL так скверно написан парсер запросов, что же творится во всей остальной СУБД? Я бы точно не доверил ей хранить информацию о моем банковском счете.

Второй важный момент заключается в том, что с 2008 года MySQL развивается компанией Oracle. Бытует небезосновательное мнение, что Oracle намеренно тормозит развитие MySQL. В настоящее время ведутся работы над множеством форков MySQL, наиболее интересным среди которых, видимо, является MariaDB. Недавно на эту СУБД переехала Wikipedia. В Slackware, Arch Linux, OpenSUSE, Fedora и RHEL также по умолчанию вместо MySQL используется MariaDB.

Разумеется, у PostgreSQL есть свои нюансы. Например, если у вас есть таблица (id, login, pass), вы можете ALERT’нуть ее и получить (id, login, pass, email), но не (id, login, email, pass). То есть, добавлять столбцы можно только в конец. Конечно, если только вы не создадите совершенно новую таблицу. Впрочем, обычно это не представляет собой большую проблему. Также в PostgreSQL нельзя написать запрос вроде INSERT INTO blablabla ON DUPLICATE KEY UPDATE blablabla (дополнение: в PostgreSQL 9.5 это исправили). Казалось бы, в одной транзакции можно писать DELETE, а затем INSERT, но это не работает. Правильное решение заключается в том, чтобы написать merge-функцию. Код таких merge-функций нетрудно генерировать автоматически, так что это тоже не представляет собой большую проблему.

Надеюсь, после прочтения этой заметки вам захочется присмотреться к PostgreSQL повнимательней.

Дополнение: Совсем забыл. В PostgreSQL есть механизм NOTIFY/LISTEN.

Метки: PostgreSQL, СУБД.

Сравнение MySQL и PostgreSQL » Tapen.ru

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

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

MySQL

Postgresql

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

MySQL

Postgresql

Стандарт SQL

MySQL

Postgresql

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

MySQL

Postgresql

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

MySQL

Postgresql

Типы данных

MySQL

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

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-данные.

Разработка

MySQL

Postgresql

Выводы

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

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

Разница между MySQL и PostgreSQL (со сравнительной таблицей)

В этой статье мы обсудим две системы управления базами данных с открытым исходным кодом, то есть MySQL и PostgreSQL . Где MySQL — это продукт Oracle Corporation, а PostgreSQL — продукт Global Development Group. Какой лучше использовать? Ответ на этот вопрос варьируется от программиста к программисту. Это зависит от требований приложения или веб-сайта, создаваемого программистом.

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

Содержимое: MySQL против PostgreSQL

Таблица сравнения
Определение
Ключевые отличия
Заключение

Таблица сравнения

Основа для сравнения	MySQL	PostgreSQL
Basic	MySQL — это система управления реляционными базами данных.	PostgreSQL — это система управления объектно-реляционной базой данных.
Продукт	MySQL является продуктом корпорации Oracle.	PostgreSQL является продуктом Global Development Group.
Операционная система	MySQL поддерживается Windows, Mac OS X, Linux, BSD, UNIX, z / OS, Symbian, AmigaOS.	Postgre поддерживается Windows, Mac OS X, Linux и BSD, но не UNIX, z / OS, Symbian, AmigaOS.
Расширяемый	MySQL не расширяется.	PostgreSQL отличается высокой расширяемостью.
Интерфейс	В MySQL инструмент phpMyAdmin предоставляет графический интерфейс.	В PostgreSQL инструмент pgAdmin предоставляет графический интерфейс.
Резервное копирование	Mysqldump и XtraBackup обеспечивает резервное копирование в MySQL.	PostgresSQL обеспечивает оперативное резервное копирование.
Материализованное представление	MySQL предоставляет временную таблицу, но не предоставляет материализованное представление.	PostgreSQL предоставляет временную таблицу, а также материализованное представление.
Объект Data Domain	MySQL не предоставляет объект Data Domain.	PostgreSQL предоставляет объект Data Domain.

Определение MySQL

MySQL — это система управления реляционными базами данных с открытым исходным кодом . Имя MySQL представляет собой комбинацию имени дочери соучредителя Майкла Видениуса «My» и сокращенного обозначения SQL для языка структурированных запросов. MySQL является продуктом Oracle Corporation .MySQL поддерживает множество стандартов SQL.

Что касается операционной системы, MySQL поддерживается почти всеми операционными системами, такими как Windows, Mac OS X, Linux, BSD, UNIX, z / OS, Symbian, AmigaOS . Система базы данных MySQL используется в Интернете для добавления, доступа и управления данными в Интернете. В MySQL инструмент phpMyAdmin отвечает за предоставление GUI и интерфейса SQL.

MySQL не предлагает вариант резервного копирования, но он использует инструменты Mysqldump и XtraBackup для обеспечения резервного копирования.MySQL предлагает временные таблицы, но не предоставляет материализованного представления . Поскольку MySQL управляет только реляционными базами данных, он не предоставляет объект области данных .

Определение PostgreSQL

PostgreSQL — это система управления реляционными базами данных с открытым исходным кодом, . Global Development Group разрабатывает PostgreSQL. Он использует множество стандартов SQL. PostgreSQL полностью совместим с ACID. Внешний ключ поддержка, триггеры и Union доступны в PostgreSQL.

PostgreSQL поддерживается операционными системами Windows, Mac OS X, Linux и BSD , но не UNIX, z / OS, Symbian, AmigaOS . Язык программирования PostgreSQL очень расширяемый . PostgreSQL использует инструмент pgAdmin для предоставления графического интерфейса пользователя и интерфейса SQL.

PostgresSQL предлагает возможность онлайн-резервного копирования. Он предоставляет временные таблицы, а также материализованное представление . а также предоставляет объект области данных .

Ключевые различия между MySQL и PostgreSQL

Архитектурное различие между MySQL и PostgreSQL заключается в том, что MySQL — это система управления реляционными базами данных, тогда как PostgresSQL — это система управления объектно-реляционными базами данных.
MySQL поддерживается следующими операционными системами: Windows, Mac OS X, Linux, BSD, UNIX, z / OS, Symbian, AmigaOS. Однако PostgreSQL поддерживается Windows, Mac OS X, Linux и BSD, но не UNIX, z / OS, Symbian, AmigaOS.
MySQL — продукт Oracle Corporation, а PostgreSQL — продукт Global Development Group.
Мой язык программирования SQL не расширяем, тогда как язык программирования PostgreSQL очень расширяемый.
В MySQL инструмент phpMyAdmin предоставляет графический интерфейс и интерфейс SQL. Однако в PostgreSQL инструмент pgAdmin предоставляет графический интерфейс и интерфейс SQL.
В MySQL инструменты Mysqldump и XtraBackup обеспечивают резервное копирование. С другой стороны, PostgresSQL обеспечивает полное резервное копирование онлайн.
MySQL предоставляет временные таблицы, но не обеспечивает материализованное представление. Однако PostgreSQL предоставляет временную таблицу, а также материализованное представление.
MySQL не предлагает объект домена данных, тогда как PostgreSQL предоставляет объект домена данных.

Заключение

Необязательно, чтобы MySQL лучше PostgreSQL или наоборот. Это зависит от требований программиста к разработке веб-приложения или веб-сайта.

отличий MySQL от Oracle в PostgreSQL — qaru
Переполнение стека
Около
Продукты
Для команд
Переполнение стека
Общественные вопросы и ответы
Переполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегами
Вакансии
Программирование и связанные с ним технические возможности карьерного роста
Талант
Нанимайте технических специалистов и создавайте свой бренд работодателя
Реклама
Обратитесь к разработчикам и технологам со всего мира
.
В чем разница между различными решениями для баз данных, такими как mysql, Nosql, Cassandra, Mongodb, postgresql, и когда вы бы использовали каждое из них?
Переполнение стека
Около
Продукты
Для команд
Переполнение стека
Общественные вопросы и ответы
Переполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегами
Вакансии
Программирование и связанные с ним технические возможности карьерного роста
Талант
Нанимайте технических специалистов и создавайте свой бренд работодателя
Реклама
Обратитесь к разработчикам и технологам со всего мира
О компании
.
разница между mysql и sql server? Производительность, особенности, …?
Переполнение стека
Около
Продукты
Для команд
Переполнение стека
Общественные вопросы и ответы
Переполнение стека для команд
Где разработчики и технологи делятся частными знаниями с коллегами
Вакансии
Программирование и связанные с ним технические возможности карьерного роста
Талант
Нанимайте технических специалистов и создавайте свой бренд работодателя
Реклама
Обратитесь к разработчикам и технологам со всего мира
О компании
.
No related posts.

Ноябрь 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

Отличие mysql от postgresql: PostgreSQL vs MySQL / Блог компании Mail.ru Group / Хабр

PostgreSQL vs MySQL / Блог компании Mail.ru Group / Хабр

что выбрать в вашем случае?

Когда разработчики выбирают MySQL, а когда PostgreSQL

Основные преимущества MySQL для разработчиков

Базовые различия при работе с базами данными MySQL и PostgreSQL Дилетантский обзор / Хабр

Сравнение MySQL и PostgreSQL с точки зрения разработчика / Хабр

Аннотация

Типы данных

Целые числа и числа с плавающей точкой

Строки и данные

Дата и время

Нестандартные типы

Выводы по типам данных

Возможности управления данными

Хранимые процедуры

Индексы и ключи

Проверка данных на этапе добавления

Транзакции и внешние ключи

Выводы

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

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

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

MySQL

Postgresql

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

MySQL

Postgresql

Стандарт SQL

MySQL

Postgresql

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

MySQL

Postgresql

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

MySQL

Postgresql

Типы данных

MySQL

Postgresql

Разработка

MySQL

Postgresql

Некоторые интересные отличия PostgreSQL от MySQL

Сравнение MySQL и PostgreSQL » Tapen.ru

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

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

MySQL

Postgresql

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

MySQL

Postgresql

Стандарт SQL

MySQL

Postgresql

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

MySQL

Postgresql

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

MySQL

Postgresql

Типы данных

MySQL

Postgresql

Разработка

MySQL

Postgresql

Выводы

Разница между MySQL и PostgreSQL (со сравнительной таблицей)

Содержимое: MySQL против PostgreSQL

Таблица сравнения

Определение MySQL

Определение PostgreSQL

Ключевые различия между MySQL и PostgreSQL

Заключение

В чем разница между различными решениями для баз данных, такими как mysql, Nosql, Cassandra, Mongodb, postgresql, и когда вы бы использовали каждое из них?

разница между mysql и sql server? Производительность, особенности, …?

Добавить комментарий Отменить ответ