Сравнение на mysql postgresql mssql база данни. Кога не трябва да използвате PostgreSql

Серия съдържание:

1. История на развитието на MySQL и PostgreSQL

Историята на MySQL започва през 1979 г., когато стои в началото малка компанияначело с Монти Видениус. През 1996 г. се появи първото издание на 3.11 за Solaris с публичен лиценз. Тогава MySQL беше пренесен към други операционни системи и се появи специален търговски лиценз. През 2000 г., след добавяне на интерфейс, подобен на Berkeley DB, базата данни става транзакционна. Репликацията беше добавена приблизително по същото време. През 2001 г. версия 4.0 добави двигателя InnoDB към съществуващия MyISAM, което доведе до кеширане и повишена производителност. През 2004 г. беше пусната версия 4.1, която въведе подзаявки, частично индексиране за MyISAM и Unicode. Във версия 5.0 през 2005 г. се появиха съхранени процедури, курсори, тригери и изгледи. MySQL развива търговски тенденции: през 2009 г. MySQL стана търговска марка на Oracle.

Историята на Postgres започва през 1977 г. с базата данни Ingress.

През 1986 г. е преименуван на PostgreSQL в университета Бъркли, Калифорния.

През 1995 г. Postgres стана отворена база данни. Появи се интерактивен psql.

През 1996 г. Postgres95 е преименуван на Версии на PostgreSQL 6.0.

Postgres има няколкостотин разработчици по целия свят.

2. Архитектура на MySQL и PostgreSQL

PostgreSQL– унифициран сървър на база данни с един двигател – двигател за съхранение. Postgres използва модел клиент-сървър.

За всеки клиент, a нов процес(не поток!). За да работи с такива клиентски процеси, сървърът използва семафори.

Клиентската заявка преминава през следните етапи.

  1. Свържете се.
  2. Разбор: проверява се коректността на заявката и се създава дърво на заявката. Анализаторът е базиран на основните Unix помощни програми yacc и lex.
  3. Пренаписване: взема се дърво на заявка и се проверява наличието на правила в него, които лежат в системни директории. Всеки път, когато потребителската заявка се пренаписва в заявка, която има достъп до таблиците на базата данни.
  4. Оптимизатор: за всяка заявка се създава план за заявка, който се предава на изпълнителя. Смисълът на плана е, че преминава през всички възможни варианти за получаване на резултата (дали да се използват индекси, обединения и т.н.), и се избира най-бързият вариант.
  5. Изпълнение на заявка: изпълнителят преминава рекурсивно в дървото и получава резултата, използвайки сортиране, обединяване и т.н., и връща редове. Postgres е обектно-релационна база данни, всяка таблица в нея представлява клас, а между таблиците е имплементирано наследяване. Внедрени стандарти SQL92 и SQL99.

Транзакционният модел е изграден на базата на т. нар. multi-version concurrency control (MVCC), което дава максимална производителност. Референтната цялост се осигурява от наличието на първичен и вторичен ключ.

MySQLима два слоя - външен sql слой и вътрешен набор от машини, от които най-често се използва InnoDb машината, тъй като тя най-пълно поддържа ACID.

Въведен стандарт SQL92.

От модулна гледна точка кодът на MySQL може да бъде разделен на следните модули.

  1. Инициализация на сървъра.
  2. Мениджър на връзките.
  3. Мениджър на потоци.
  4. Манипулатор на команди.
  5. Удостоверяване.
  6. Анализатор.
  7. Оптимизатор.
  8. Мениджър на маса.
  9. Двигатели (MyISAM, InnoDB, MEMORY, Berkeley DB).
  10. Сеч.
  11. Репликация.
  12. API на мрежата.
  13. API на ядрото.

Редът на работа на модулите е следният: първо се зарежда първият модул, който чете опции на командния ред, конфигурационни файлове, разпределя памет, инициализира глобални структури, зарежда системни таблици и прехвърля контрола на мениджъра на връзките.

Когато клиент се свърже с базата данни, контролът се прехвърля към мениджъра на нишките, който създава нишка (а не процес!) за клиента и нейното удостоверяване се проверява.

Клиентски заявки в зависимост от вида им Горно нивообработвани от четвъртия модул (диспечер). Заявките ще бъдат регистрирани до 11-ия модул. Командата се предава на анализатора и кеша се проверява. След това заявката може да отиде до оптимизатора, модула за таблица, модула за репликация и т.н. В резултат на това данните се връщат на клиента чрез мениджъра на потока.

Най-важният код е във файла sql/mysqld.cc. Съдържа основни функции, които не са променени от версия 3.22: init_common_variables() init_thread_environment() init_server_components() grant_init() // sql/sql_acl.cc init_slave() // sql/slave.cc get_options() handle_connections_sockets() create_new_thread() handle_one_connection() check_connection() acl_check_host() // sql/sql_acl.cc create_random_string() // sql/password.cc check_user() // sql/sql_parse.cc mysql_parse() // sql/sql_parse.cc dispatch_command() Query_cache::store_query () // sql/sql_cache.cc JOIN::optimize() // sql/sql_select.cc open_table() // sql/sql_base.cc mysql_update() // sql/sql_update.cc mysql_check_table() // sql/sql_table .cc

Заглавката sql/sql_class.h дефинира базовите класове: Query_arena, Statement, Security_context, класове Open_tables_state, THD. Обектът на класа THD представлява манипулатор на нишка и е аргумент голямо количествофункции.

3. Сравнение на MySQL и PostgreSQL: прилики и разлики

Стандарт ACID

Стандартът ACID се основава на атомарност, цялост, изолация и надеждност. Този модел се използва за гарантиране на целостта на данните. Това се осъществява на базата на транзакции. PostgreSQL е напълно съвместим с ACID. За да поддържате изцяло ACID в MySQL, трябва да зададете default-storage-engine=innodb в конфигурацията.

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

Базите данни често се оптимизират въз основа на средата, в която работят. И двете бази имат различни технологииза подобряване на производителността. В исторически план MySQL започва да се разработва с оглед на скоростта, докато PostgreSQL е разработен от самото начало като база данни с Голям бройнастройки и съответствие със стандарта. PostgreSQL има редица настройки, които увеличават скоростта на достъп:

  • частични индекси;
  • компресиране на данни;
  • разпределение на паметта;
  • подобрен кеш.

MySQL има частична поддръжка за частични индекси в InnoDB. Ако вземете двигателя MySQL ISAM, той се оказва по-бърз при плоски заявки, докато няма блокиране на вмъквания, няма поддръжка за транзакции, външни ключове.

Компресия

PostgreSQL компресира и декомпресира данните по-добре, което ви позволява да спестите повече данни на дисковото пространство. В същото време компресираните данни се четат по-бързо от диска.

Компресията на MySQL за различни двигатели се поддържа отчасти, отчасти не и това зависи от конкретната версия на даден двигател.

По отношение на многопроцесорната производителност, PostgreSQL има предимство пред MySQL. Дори самите разработчици на MySQL признават, че техният двигател не е толкова добър в това отношение.

Типове данни

MySQL: използва типове TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB за съхраняване на двоични данни, които се различават по размер (до 4 GB).

Символ: четири типа - TINYTEXT, TEXT, MEDIUMTEXT, LONGTEXT.

PostgreSQL: Поддържа машина за потребителски данни с команда CREATE TYPE, тип BOOLEAN, геометрични типове.

Символ: ТЕКСТ (ограничение – максимален размер на реда).

За съхраняване на двоични данни има тип BLOB, който се съхранява в файлова система. Колоните на таблицата могат да бъдат определени като многомерен масивпроменлива дължина. Обектно-релационно разширение: Структурата на една таблица може да бъде наследена от друга таблица.

Съхранени процедури

И PostgreSQL, и MySQL поддържат съхранени процедури. PostgreSQL следва стандарта Oracle PL/SQL, MySQL следва стандарта IBM DB2. MySQL поддържа разширение на SQL за писане на функции в C/C++ от версия 5.1. PostgreSQL: PL/PGSQL, PL/TCL, PL/Perl, SQL, C за писане на съхранени процедури.

Ключове

Както PostgreSQL, така и MySQL поддържат уникален първичен ключ и външен ключ. MySQL не поддържа ограничение за проверка, плюс вторичните ключове са частично внедрени. PostgreSQL: пълно внедряване плюс поддръжка за ON DELETE CASCADE и ON UPDATE CASCADE.

Тригери

MySQL: елементарна поддръжка. PostgreSQL: декларативни тригери: SELECT, INSERT, DELETE, UPDATE, INSTEAD OF; процедурни тригери: CONSTRAINT TRIGGER. Събития: ПРЕДИ или СЛЕД на INSERT, DELETE, UPDATE.

Автоматично увеличаване

MySQL: Може да има само една такава колона в таблица, която трябва да бъде индексирана. PostgreSQL: SERIAL тип данни.

Репликации

Поддържа се както в MySQL, така и в PostgreSQL. PostgreSQL има модулна архитектура и репликацията е включена в отделни модули:

  • Slony-I е основният механизъм за репликация в Postgres; производителността намалява като квадратична функция на броя на сървърите;

Репликацията в PostgreSQL е базирана на тригери и е по-бавна, отколкото в MySQL. Предвижда се добавяне на репликация към ядрото от версия 8.4.

В MySQL репликацията е включена в ядрото и има два варианта, като се започне от версия 5.1:

  • SBR – репликация, базирана на оператори;
  • RBR – репликация, базирана на ред.

Първият тип се основава на регистриране на записи в двоичен журнал, вторият е базиран на регистриране на промени. Започвайки от версия 5.5, MySQL поддържа така наречената полусинхронна репликация, при която главният сървър (master) нулира данните към друг сървър (slave) с всеки комит. Машината NDB извършва пълна синхронна двуфазна репликация.

Транзакции

MySQL: само InnoDB. Поддръжка на SAVEPOINT, ВЪРТАНЕ КЪМ SAVEPOINT. Нива на заключване: ниво таблица (MyISAM). PostgreSQL: поддържа се плюс ангажирани за четене и нива на изолация. Поддръжка ROLLBACK, ROLLBACK TO SAVEPOINT. Нива на заключване: ниво ред, ниво таблица.

Нива на привилегии

PostgreSQL: Привилегиите могат да бъдат присвоени на потребител или потребителска група.

Експорт-импорт на данни

MySQL: набор от помощни програми за експортиране: mysqldump, mysqlhotcopy, mysqlsnapshot. Внос от текстови файлове, html, dbf. PostgreSQL: експортиране - помощна програма pg_dump. Импортиране между бази данни и файлова система.

Вложени заявки

Предлага се както в MySQL, така и в PostgreSQL, но може да не работи ефективно в MySQL.

Индексиране

Хеширане на индекс: частично в MySQL, пълно в PostgreSQL. Пълнотекстово търсене: в MySQL – частично, в PostgreSQL – пълно. Частични индекси: не се поддържат в MySQL, поддържат се в PostgreSQL. Многоколонни индекси: в MySQL ограничението е 16 колони, в PostgreSQL – 32. Експресионни индекси: в MySQL – емулация, в PostgreSQL – пълни. Неблокиращ индекс за създаване: в MySQL - частичен, в PostgreSQL - пълен.

Преграждане

MySQL поддържа хоризонтално разделяне: диапазон, списък, хеш, ключ, съставно разделяне. PostgreSQL поддържа RANGE и LIST. Автоматично разделяне на таблици и индекси.

Автоматично възстановяване от повреди

MySQL: частично за InnoDB - трябва ръчно да направите резервно копие. PostgreSQL: Предварително записване в журнал (WAL).

Механизми за съхранение на данни

PostgreSQL поддържа един двигател – Postgres Storage System. Има няколко от тях в MySQL 5.1:

  • MyISAM – използва се за съхраняване на системни таблици;
  • InnoDB – максимално съответствие с ACID, съхранява данни от първични ключове, кешира вмъквания, поддържа компресия, започвайки от версия 5.1 - вижте атрибут ROW_FORMAT=COMPRESSED;
  • NDB Cluster – двигател, ориентиран към паметта, клъстерна архитектура, използваща синхронна репликация;
  • АРХИВ – поддържа компресия, не използва индекси;
  • и също така: ОБЕДИНЯВАНЕ, ПАМЕТ (HEAP), CSV.

InnoDB е разработена от InnoBase, дъщерно дружество на Oracle. Във версия 6 трябва да се появят два двигателя - Maria и Falcon. Falcon е двигател, базиран на ACID транзакции.

Лицензиране

PostgreSQL: BSD (Berkeley Software Distribution) с отворен код. MySQL: GPL (общ публичен лиценз на Gnu) или търговски. MySQL е продукт с отворен код. Postgres е проект с отворен код.

Заключение

За да обобщим, можем да кажем следното: MySQL и PostgreSQL са двете най-популярни бази данни с отворен код в света. Всяка основа има свои собствени характеристики и разлики. Ако се нуждаеш бързо съхранениеЗа прости заявкис минимална настройка бих препоръчал MySQL. Ако се нуждаеш сигурно съхранениеза големи обеми данни с възможност за разширение, репликация, напълно съобразени със съвременните стандарти SQL език, бих предложил да използвате PostgreSQL.

Ще обсъждаме въпроси Настройки на MySQLи PostgreSQL.

Ресурси за изтегляне

static.content.url=http://www.site/developerworks/js/artrating/

Зона=Отворен код, Linux

ИД на артикула=779830

ArticleTitle=MySQL & PostgreSQL: Част 1. Сравнителен анализ

Отличен въпрос за holivar. Но ние няма да го направим. Публикуван от автора, авторът разглежда и двете СУБД от позицията на грижа за данните и стига до извода, че PostgreSQL е подходящ за сериозни проекти, а MySQL изобщо не е опция.

Пример за превъзходството на PosgreSQL над MySQL

Например, нека създадем таблица и зададем тип numeric(4, 2) за едно от полетата - четири цифри за съхранение на цялото число и две цифри след десетичната запетая. И тогава ще се опитаме да вмъкнем номер, който не отговаря на описанието. И какво мислите? Няма проблем!

В ръчен режим (евентуално) ще видим предупреждение (1 предупреждение), ще се опитаме да познаем за какво става дума и ще възстановим предишната стойност. Но предупреждението е лесно да се пропусне. Ако пишете приложение, което се занимава със съхраняване на финансови данни, подобни грешки ще ви струват много скъпо.

PostgreSQL се грижи за вашите данни и се държи по-сериозно:

INSERT INTO DATA VALUES (1, 1234.5678); ГРЕШКА: препълване на ЧИСЛОВОТО ПОЛЕ ПОДРОБНОСТИ: ПОЛЕ С ТОЧНОСТ 4, скала 2 трябва да закръгли ДО абсолютна СТОЙНОСТ, по-малка от 10 ^2.

Те просто няма да ни позволят да направим грешка. Освен това съобщението ще съдържа подробности: какво точно ограничение сме нарушили и какво максимален размердадено число Това е.

А сега малко мистика. Помните ли как описахме, че полето id за MySQL не трябва да бъде NULL? Да опитаме:

Изненадващо, въпреки изричната забрана (NOT NULL), MySQL DBMS позволи актуализиране на полето и зададе стойността му на 0, въпреки че изобщо не казахме нищо за нула. 0 и NULL са напълно различни обекти. 0 е число. NULL е специален индикатор, който ни казва, че не знаем какво число се съдържа в това поле. И не е задължително да е 0. Така СУБД отново присвои произволна стойност на нашата база данни. Ако вашето приложение има същата грешка, тогава MySQL ще помогне тази грешка да остане неоткрита за дълго време. Какво ще кажете за PostgreSQL? Тук всичко е ясно.

Сравнението по-долу е направено в MySQL AB. Опитах се да бъда възможно най-точен и обективен, но познавайки MySQL, не можех да се похваля със същите познания за възможностите на PostgreSQL, така че можеше да съм сгрешил в някои отношения.

На първо място бих искал да отбележа, че PostgreSQL и MySQL са широко използвани софтуерни продукти, които са разработени за различни цели (въпреки че създателите и на двата се стремят да ги доведат до пълна съвместимост със стандарта ANSI SQL). Това означава, че MySQL е по-подходящ за решаване на някои проблеми, докато PostgreSQL е по-подходящ за други. Когато избирате СУБД, проверете дали неговите възможности отговарят на изискванията на решавания проблем. Ако искаш максимална скоростработа, вероятно би било най-добре да изберете MySQL сървър. Ако се нуждаеш допълнителни функции, наличен само в PostgreSQL, тази СУБД си струва да се използва.

Съществена разлика между MySQL и PostgreSQL е, че почти целият код, съдържащ се в MySQL, е създаден от разработчици, работещи в MySQL AB и постоянно заети с подобряването на сървърния код. Изключение от това правило са системите за транзакции и библиотеката с регулярни изрази на regexp.

По-голямата част от кода на PostgreSQL е написан от много разработчици, които нямат връзка помежду си. Неотдавна разработчиците на PostgreSQL обявиха, че техният екип най-накрая има достатъчно време да прегледа целия код, включен в следващата версия на PostgreSQL.

Сравнение на функциите на MySQL и PostgreSQL

MySQL има следните предимства пред PostgreSQL:

· MySQL обикновено е много по-бърз от PostgreSQL. В допълнение, MySQL 4.0 прилага кеш на заявки. Тя ви позволява да увеличите многократно скоростта на обработка на заявките за сайтове, които са доминирани от повтарящи се заявки за четене.

· В брой Потребители на MySQLсъщо много по-добър от PostgreSQL. Поради това кодът се тества много по-щателно и експериментално е доказано, че надеждността му е по-голяма от тази на PostgreSQL. MySQL се използва по-често от PostgreSQL в производството, главно защото MySQL AB (по-рано TCX DataKonsult AB) предоставя висококачествени търговски технически Поддръжка на MySQLот появата на тази система на пазара, а PostgreSQL нямаше никаква поддръжка до съвсем скоро.

· MySQL работи по-добре на Windows от PostgreSQL. MySQL Server работи като истинско (родно) Windows приложение (услуга на NT/2000/XP), докато PostgreSQL работи в емулационна среда, Cygwin. Чувал съм за липсата на стабилност на PostgreSQL в средата на Windows, но все още не можах да проверя тази информация сам.

Оборудвано с MySQL голяма сума API за други езици и се поддържа от много съществуващи програмиотколкото PostgreSQL.

MySQL работи с висока надеждност индустриални системи 24/7 (24 часа в денонощието, 7 дни в седмицата). В повечето случаи не се изискват почиствания в MySQL. PostgreSQL все още не може да работи на такива системи, тъй като понякога е необходимо да се стартира VACUUM, за да се освободи пространството, заето от последствията от командите UPDATE и DELETE, и да се извърши статистическият анализ, необходим за постигане максимална производителност PostgreSQL. Също така е необходимо да стартирате VACUUM след всяко добавяне на няколко колони към таблицата. При натоварени системи VACUUM трябва да се стартира по-често, в най-лошия случай няколко пъти на ден. Но докато VACUUM работи (и работата му може да продължи с часове, ако базата данни е достатъчно голяма), базата данни е практически „мъртва“. Във версия 7.2 на PostgreSQL обаче изпълнението на основните функции на тази програма вече не води до блокиране на базата данни и потребителите могат да продължат да работят с нея нормално. Новата команда VACUUM FULL приема нещата по-сериозно: точно както в по-старите версии, тя заключва таблицата и компресира копие на таблицата на диска.

· Има значително повече книги за MySQL, отколкото за PostgreSQL. Книги за MySQL са публикувани от O"Reilly, SAMS, Que и New Riders. Всички функции на MySQL са описани подробно в документацията, тъй като е предпоставкавключване на нови функции в кода.

· MySQL има много по-мощна реализация на ALTER TABLE.

· MySQL предоставя възможност за създаване на таблици без транзакции, което е необходимо за приложения, които изискват възможно най-висока скорост.

· MySQL може да работи с две машини за таблици, които поддържат транзакции, а именно InnoDB и BerkeleyDB. Тъй като всички системи за поддръжка на транзакции работят по различен начин при различни условия, това дава възможност на разработчика да намери най-доброто решениеза условията, в които ще работи неговата система. Вижте раздел 7 MySQL Типове таблици.

· Командата за обединяване на таблици MERGE ви дава уникалната възможност да създадете изглед на няколко идентични таблици и да работите с тях като една. Това е особено удобно за работа с дневници, разделени например по месеци.

· Възможност за компресиране на таблици само за четене без отмяна директен достъпкъм техните записи, подобрява производителността на системата чрез намаляване на броя на операциите за четене на диск. Това е особено полезно за архивиране.

· MySQL изпълнява пълнотекстово търсене.

· Възможно е да се работи с няколко бази данни чрез една връзка (разбира се, в зависимост от привилегиите на потребителя).

· MySQL е проектиран от самото начало да бъде многонишков, докато PostgreSQL използва процеси. Превключването на контексти и достъпът до споделени данни от множество нишки е много по-бързо, отколкото от отделни процеси. Това дава на MySQL Server добро предимство в производителността в многопотребителски приложения и също така позволява на MySQL Server да се възползва много по-ефективно от симетричните мултипроцесорни (SMP) системи.

· MySQL има много по-мощна система за привилегии от PostgreSQL. Докато PostgreSQL предоставя само INSERT, SELECT и UPDATE/DELETE привилегии над база данни или таблица, MySQL предоставя възможността да се дефинира пълен набор от различни привилегии на ниво база данни, таблица и колона. Освен това MySQL ви позволява да задавате привилегии за комбинации хост/потребител.

· MySQL използва комуникационен протокол между клиент и сървър с компресиране на данни, което повишава производителността на системата в условия на нискоскоростни комуникационни канали.

· Всички типове таблици в MySQL (с изключение на InnoDB) се изпълняват като файлове (по една таблица на файл), което значително опростява създаването резервни копия, преместване, изтриване и дори създаване на символни връзки между бази данни и таблици, дори ако сървърът не работи.

· Актуализирането на MySQL е напълно безболезнено. Когато надграждате MySQL, няма нужда да копирате/възстановявате данни, което е необходимо да направите при инсталиране на повечето актуализации на PostgreSQL.

По-долу са предимствата на PostgreSQL пред MySQL днес.

Други причини да изберете PostgreSQL:

· В някои случаи PostgreSQL е по-близо до ANSI SQL.

· PostgreSQL работаМожете да го ускорите, като изпълните кода си като съхранени процедури.

· Когато съхранявате географски данни, R-дърветата дават предимство на PostgreSQL пред MySQL (забележка: в MySQL версии 4.1, поддръжката за R-дървета е внедрена за MyISAM таблици).

· Екипът от разработчици на PostgreSQL, който пише код за сървъра, е по-голям.

Недостатъци на PostgreSQL в сравнение с MySQL:

· VACUUM прави PostgreSQL труден за използване на постоянно включени системи.

· Наличие само на транзакционни таблици.

· Значително повече бавна работаКоманди INSERT, DELETE и UPDATE.

Заключение

Единствените бенчмаркове, налични днес, които сравняват MySQL Server и PostgreSQL, които всеки може да изтегли и стартира, са бенчмарковете в MySQL пакета. И затова избирам MySQL

  • Блог на компанията Mail.ru Group

    • В очакване на моя доклад на конференцията PGCONF.RUSSIA 2015, ще споделя някои наблюдения относно важните разлики между СУБД MySQL и PostgreSQL. Този материал ще бъде полезен за всички, които вече не са доволни от възможностите и функциите на MySQL, както и за тези, които правят първите си стъпки в Postgres. Разбира се, тази публикация не трябва да се разглежда като изчерпателен списък от разлики, но ще бъде напълно достатъчна, за да вземете решение в полза на една или друга СУБД.

    Репликация

    Темата на моя доклад е „Асинхронна репликация без цензура или защо PostgreSQL ще завладее света“, а репликацията е една от най-болезнените теми за натоварени проекти, използващи MySQL. Има много проблеми - правилна работа, стабилност, производителност - и на пръв поглед изглеждат несвързани. Ако погледнем историческия контекст, получаваме интересно заключение: Репликацията на MySQL има толкова много проблеми, защото не беше обмислена и точката, от която няма връщане, беше поддръжката на двигателя за съхранение (plug-in двигатели) без отговори на въпросите „какво да правя с регистрационния файл?“ и „как различни машини за съхранение могат да участват в репликацията“. През 2004 г. в пощенския списък на PostgreSQL потребител се опита да „намери“ машината за съхранение в програмен код PostgreSQL и беше много изненадан, че ги няма. По време на дискусията някой предложи добавянето на тази функция към PostgreSQL и един от разработчиците отговори: „Момчета, ако направим това, ще имаме проблеми с репликацията и транзакциите между двигателите.“
    Проблемът е, че много място за съхранение системи за управление… често правят свои собствени WAL и PITR. Някои правят собствено управление на буфера, заключване и управление на репликация/зареждане. Така че, както казвате, трудно е да се каже къде трябва да бъде интерфейсът
    абстрахиран.
    връзка към това писмо в пощенския списък на postgresql

    Минаха повече от 10 години и какво виждаме? MySQL има досадни проблеми с транзакциите между таблици в различни машини за съхранение, а MySQL има проблеми с репликацията. През тези десет години PostgreSQL добави допълнителни типове данни и индекси, а също така има репликация - тоест предимството на MySQL е изравнено, докато архитектурните проблеми на MySQL остават и пречат на живота. MySQL 5.7 се опита да реши проблема с производителността на репликацията, като го паралелизира. Тъй като проектът по време на работа е много чувствителен към производителността на репликация поради неговия мащаб, аз се опитах да тествам дали се е подобрил. Открих, че паралелната репликация в 5.7 е по-бавна от репликацията с една нишка в 5.5 и само в някои случаи - приблизително същата. Ако в момента използвате MySQL 5.5 и искате да надстроите до по-нова версия, моля, имайте предвид, че миграцията не е възможна за силно натоварени проекти, тъй като репликацията просто вече няма да се справи.

    След разговора за високо натоварване Oracle взе под внимание разработения от мен тест и каза, че ще се опитат да решат проблема; наскоро дори ми писаха, че са успели да видят паралелизъм в техните тестове и ми изпратиха настройките. Ако не се лъжа при 16 нишки имаше леко ускорение спрямо еднонишковия вариант. За съжаление, все още не съм повторил тестовете си на предоставените настройки - особено защото с такива резултати нашите проблеми все още остават актуални.

    Точните причини за тази регресия на производителността не са известни. Имаше няколко предположения - например Кристиан Нелсен, един от разработчиците на MariaDB, написа в блога си, че може да има проблеми със схемата за изпълнение и синхронизирането на нишки. Поради това има регресия от 40%, която се вижда при редовни тестове. Разработчиците на Oracle опровергават това и дори ме убедиха, че не съществува; явно виждам някакъв друг проблем (и колко от тях има?).

    При репликацията на MySQL проблемите с механизма за съхранение се утежняват от избраното ниво на репликация - те са логически, докато в PostgreSQL те са физически. По принцип логическата репликация има своите предимства, позволява ви да правите по-интересни неща, това също ще спомена в доклада. Но PostgreSQL, дори в рамките на своята физическа репликация, вече намалява всички тези предимства до нищо. С други думи, почти всичко, което е в MySQL, вече може да се направи в PostgreSQL (или ще бъде възможно в близко бъдеще).

    Не можете да се надявате да приложите физическа репликация на ниско ниво в MySQL. Проблемът е, че вместо един журнал (както в PostgreSQL), има два или четири от тях, в зависимост от това как ги броите. PostgreSQL просто извършва заявки, те отиват в дневник и този дневник се използва при репликация. Репликацията на PostgreSQL е супер стабилна, защото използва същия журнал като операциите за преодоляване при отказ. Този механизъм е написан отдавна, добре тестван и оптимизиран.

    В MySQL ситуацията е различна. Имаме отделен журнал на InnoDB и регистър на репликация и трябва да извършим и двете. И това е двуфазов ангажимент между журналите, който по дефиниция е бавен. Тоест не можем просто да кажем, че повтаряме транзакция от журнала на InnoDB - трябва да разберем какъв вид заявка е и да я изпълним отново. Дори ако това е логическа репликация, на ниво ред, тогава тези редове трябва да се търсят в индекса. И не само, че трябва да свършите много работа, за да изпълните заявката, но тя отново ще бъде записана в нейния InnoDB журнал на репликата, което очевидно не е добро за производителността.

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

    Освен това има тригер репликация за PostgreSQL - това е Tungsten, който ви позволява да правите същото. Репликацията на тригера работи по следния начин: тригерите се задават, те попълват таблици или записват файлове, резултатът се изпраща до репликата и се прилага там. Чрез Tungsten, доколкото знам, те мигрират от MySQL към PostgreSQL и обратно. В MySQL логическата репликация работи директно на ниво двигател и вече не е възможно да се направи по друг начин.

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

    PostgreSQL има много по-добра документация. В MySQL формално дори изглежда, че съществува, но въпросът е там индивидуални опцииможе да бъде трудно за разбиране. Изглежда, че е написано какво правят, но за да разберете как да ги конфигурирате правилно, трябва да използвате неофициална документация и да потърсите статии по тази тема. Често трябва да разберете архитектурата на MySQL; без това разбиране настройките изглеждат като някаква магия.

    Например, компанията Percona излетя: те пуснаха MySQL Performance Blog и в този блог имаше много статии, които обсъждаха някои аспекти на използването на MySQL. Това донесе дива популярност, насочи клиентите към консултации и ни позволи да привлечем ресурси, за да стартираме разработката на нашия собствен Percona-Server fork. Съществуването и популярността на 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. Разликата между двете заявки - в нашия пример групирането по отделни таблици и обединяването на всички отгоре работи 15 пъти по-бързо от обединяването на всички и след това групирането, въпреки че оптимизаторът трябва да приведе и двете заявки в един и същ ефективен план за изпълнение на заявката. Ще трябва да генерираме такива заявки ръчно - тоест да губим времето на разработчиците за това какво трябва да прави базата данни.

    „Простотата“ на MySQL е резултат, както може да се види по-горе, от изключително слаби възможности - MySQL просто работи по-зле и изисква повече време и усилия по време на разработката. За разлика от тях PostrgreSQL има хистограми и нормален оптимизатор и ще изпълнява такива заявки ефективно. Но ако има хистограми, има и техните настройки - поне размер на кофата. Трябва да знаете за настройките и да ги промените в някои случаи - следователно трябва да разберете какво представлява тази настройка, за какво отговаря, да можете да разпознавате такива ситуации и да видите как да изберете оптималните параметри.

    Понякога се случва умението на PostrgreSQL да попречи, вместо да помогне. 95% от времето всичко работи добре - по-добре от MySQL - но една глупава заявка работи много по-бавно. Или всичко работи добре и след това изведнъж (от гледна точка на потребителя), докато проектът расте, някои заявки започват да работят зле (има повече данни, започва да се избира различен план за изпълнение на заявката). Най-вероятно, за да го поправите, просто стартирайте анализ или коригирайте малко настройките. Но трябва да знаете какво да правите и как да го правите. Като минимум трябва да прочетете документацията на PostgreSQL по тази тема, но по някаква причина те не обичат да четат документация. Може би защото е от малка помощ в MySQL? :)

    Бих искал да подчертая, че PostgreSQL не е по-лош в този смисъл, той просто ви позволява да отлагате проблемите, докато MySQL веднага ги изхвърля и трябва да отделите време и пари за решаването им. В този смисъл MySQL винаги работи постоянно лошо и дори на етапа на разработка хората вземат предвид тези функции: те правят всичко по възможно най-простия начин. Това се отнася само за производителността, по-точно за методите за нейното постигане и нейната предвидимост. От гледна точка на коректност и удобство, PostgreSQL е с глава над MySQL.

    И така, какво трябва да изберете?

    За да изберете между MySQL и PostgreSQL за конкретен проект, първо трябва да отговорите на други въпроси.

    Първо, какъв опит има екипът? Ако целият екип има 10 години опит в работата с MySQL и трябва да започне да работи възможно най-бързо, тогава не е факт, че си струва да смените познат инструмент с непознат. Но ако крайните срокове не са критични, тогава PostgreSQL си струва да опитате.

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

    Да обобщим: ако имате обикновен онлайн магазин, нямате пари за администратор, нямате сериозни амбиции, в които да се развивате голям проекти имате опит с MySQL, тогава вземете MySQL. Ако очаквате, че проектът ще бъде популярен, ако е голям, ще бъде трудно да го пренапишете, ако има сложна логика и връзки между таблици - вземете PostgreSQL. Дори и извън кутията, той ще работи за вас, ще ви помогне в развитието, ще спести време и ще ви улесни в растежа.