В дните, когато някой казваше MySQL, имаше само MySQL. Можете да изберете различни версии (4.0, 4.1), но доставчикът беше един и същ. Това се промени около MySQL 5.0/5.1, когато Percona реши да пусне свой собствен вкус на MySQL - Percona Server. Малко по-късно MariaDB се присъедини към MariaDB 5.1 и забавлението (или объркването) се увеличи. Каква версия да използвам? Каква е разликата между MySQL 5.1, Percona Server 5.1 и MariaDB 5.1? Кой е по-бърз? Кой е по-стабилен? Кой от тях има превъзходна функционалност? С времето това се влоши, тъй като във всеки от вкусовете бяха въведени все повече и повече промени. Тази публикация в блога ще бъде нашият опит да обобщим основните характеристики, които ги отличават. Също така ще се опитаме да ви дадем някои предложения за това кой вкус може да е най-добрият за даден тип проект. Да започваме.
Oracle MySQL
Преди беше MySQL, сега е нагоре. По-голямата част от разработката започва тук, всяка версия, започваща от 5.6, разрешава някои вътрешни спорове и носи по-добра производителност. Нови функции също се добавят редовно. MySQL 5.6 ни донесе (наред с други) GTID и първоначална реализация на паралелна репликация. Той също така ни даде възможност да изпълняваме повечето от ALTER по онлайн начин. Нека да разгледаме характеристиките на най-новата версия на MySQL - MySQL 5.7
Характеристики на MySQL 5.7
Една от основните промени са промените в процеса на внедряване - вместо различни скриптове, можете просто да стартирате mysqld --initialize, за да настроите MySQL от нулата. Друга много важна промяна - паралелна репликация, базирана на логически часовник. И накрая, можем да използваме паралелна репликация във всички случаи - без значение дали използвате множество схеми или не. Друго подобрение на репликацията е репликацията от няколко източника – 5.7 подчинен може да има множество главни – това е страхотна функция, ако искате да изградите подчинен за агрегация и, да речем, да комбинирате данни от множество отделни клъстери.
InnoDB започна да поддържа пространствени типове, буферният пул на InnoDB най-накрая може да бъде преоразмерен по време на изпълнение, онлайн ALTER бяха подобрени, за да поддържат повече случаи като разделяне и ALTER без операции.
MySQL започна да поддържа типовете данни JSON изначално заедно с няколко нови функции, които са фокусирани върху добавянето на функционалност около JSON. Сигурността на вашите данни е много важна в наши дни, MySQL 5.7 поддържа криптиране на данни в покой за пространства за таблици файл на таблица. Добавени са и някои подобрения в поддръжката на SSL (SSL ще бъде конфигуриран, ако ключовете са на място, включен е скрипт, който може да се използва за създаване на сертификати). От гледна точка на управлението на потребителите е добавена настройка за продължителността на живота на паролата, което би трябвало да направи дизайна на правилата за изтичане на паролата малко по-лесен.
Друга функция, която има за цел да подпомогне DBA, е схемата „sys“, набор от изгледи, предназначени да улеснят използването на схемата за производителност. Той е включен по подразбиране в MySQL 5.7.
И накрая, MySQL Group Replication (и евентуално MySQL InnoDB Cluster) е добавен към MySQL 5.7. Той работи като плъгин и е включен в последните версии на клона 5.7, но това е отделна тема. Накратко, груповата репликация ви позволява да изградите „виртуално“ синхронен клъстер.
Това определено не е пълен списък с функции - ако се интересувате от всички, може да искате да се консултирате с документацията на MySQL 5.7.
Сървър Percona
В началото имаше набор от кръпки, които да се прилагат към изходния код на MySQL, които добавиха някои подобрения на производителността и функционалност. В някакъв момент Percona реши да пусне своя собствена версия на MySQL, която включва тези пачове. С времето станаха налични повече ресурси за разработка, така че бяха добавени все повече и повече функции.
Като цяло можете да видите Percona Server като най-новата версия на MySQL с множество пачове/подобрения. С течение на времето някои от подобренията на функциите на Percona Server се заменят с функции от по-горе по веригата - всеки път, когато Oracle разработи функция, която замества една от функциите, добавени в Percona Server. Докато имплементацията е на ниво, Percona премахва собствения си код в полза на кода от горния поток. Това прави Percona Server основно заместник на MySQL на Oracle. Една от областите, в които са направени значителни подобрения в производителността, е InnoDB. Той е модифициран достатъчно значително, за да го брандира като XtraDB. В момента е напълно съвместим с InnoDB, но не винаги е било така. Например, някои функции в Percona Server 5.5 не бяха съвместими с MySQL 5.5. Това важи и за по-новите версии на Percona Server. Важното е, че по подразбиране Percona Server се предлага с деактивирани всички несъвместими функции - улеснява тестването му и връщането към MySQL на Oracle, ако е необходимо. Като се има предвид всичко по-горе, все пак трябва да бъдете внимателни, когато планирате да мигрирате от Percona Server към MySQL – някой може да е активирал една от несъвместимите функции.
Това, което си струва да се подчертае, е, че Percona се стреми да внедри отново функциите на предприятието нагоре по веригата. В случай на MySQL примерите са внедряване на пул от нишки или PAM плъгин за удостоверяване. Нека да разгледаме набързо някои от функциите на сървъра Percona.
Характеристики на Percona Server 5.7
Една от основните характеристики на XtraDB е подобрената мащабируемост на буферния пул – въпреки че има все по-малко спорове поради работата, която Oracle върши във всяка версия на MySQL, инженерният екип на Percona се стреми да увеличи производителността още повече и да премахне допълнителни мютексове, които могат да ограничат производителността. Освен това в монитора на InnoDB се записват повече данни (достъпни чрез SHOW ENGINE INNODB STATUS) относно спорове в InnoDB – например добавен е раздел за семафори.
Друг набор от подобрения са направени в областта на I/O. В InnoDB можете да зададете метод за изчистване само за пространствата за таблици InnoDB и това причинява двойно буфериране за регистрационните файлове за повторно изпълнение на InnoDB. XtraDB прави възможно използването на O_DIRECT и за тези файлове. Той също така добавя повече данни относно контролните точки към изхода на SHOW ENGINE INNODB STATUS. В допълнение към това, паралелен буфер за двойно записване и многонишков LRU flusher са внедрени, за да се намалят споровете при I/O операции в InnoDB.
Пулът от нишки е друга функция, предоставена от Percona Server. В Oracle MySQL той е достъпен само в изданието Enterprise. Тук можете да използвате внедряването на Percona безплатно. Като цяло пулът от нишки намалява споровете, като същевременно обслужва голям брой връзки от приложението, като използва повторно съществуващи връзки към базата данни.
Още две функции са директни замествания на функции от Enterprise версията на MySQL. Един от тях е плъгинът за удостоверяване на PAM, който е разработен от Percona и е предназначен да позволи използването на множество различни опции за удостоверяване като LDAP, RSA SecurID или всякакви други методи, поддържани от PAM. Втората функция също е свързана със сигурността - плъгин за лог за одит. Той ще създаде файл със запис на действията, предприети на сървъра на базата данни.
От време на време Percona въвежда значителни подобрения в други машини за съхранение, като промените, които са направили в механизма MEMORY, което позволява използването на данни от типа VARCHAR или BLOB.
Въвеждането на резервни ключалки също беше доста значително подобрение. В Oracle и MariaDB единственият метод за заключване на таблицата за получаване на последователно архивиране беше използването на FLUSH TABLES WITH READ LOCK (FTWRL). Доста е тежък и принуждава MySQL да затвори всички отворени таблици. Заключването на архивиране, от друга страна, използва по-лек подход на заключванията на метаданни. В много случаи на силно натоварен сървър, изпълняващ FTWRL, отнема твърде много време (и заключва сървъра за твърде дълго), за да се счита за осъществим, докато блокирането на архивиране позволява да се направи резервно копие с помощта на mysqldump или xtrabackup.
Percona е отворена и за функции за пренасяне от други доставчици. Един такъв пример е порт на MariaDB НАЧАЛНА ТРАНЗАКЦИЯ С ПОДХОДЯЩИ МОМЕНТНИ СНИМКИ. Тази функция е свързана и с архивирането – с нейна помощ можете да правите последователно логическо архивиране (използвайки mysqldump), без да изпълнявате FLUSH TABLE WITH READ LOCK.
И накрая, три функции, които подобряват наблюдаемостта - първо:потребителска статистика. Това е доста лека функция, която събира данни за потребители, индекси, таблици и нишки. Позволява ви да намерите неизползвани индекси или да определите кой потребител е отговорен за натоварването на сървъра. В момента е частично излишен за performance_schema, но е малко по-лек и е създаден в дните на MySQL 5.0 - 5.1, където никой дори не е мечтал за performance_schema.
Второ - подобрен дневник на бавните заявки. Отново беше добавен във времена, когато най-високата детайлност на long_query_time беше 1 секунда. С това допълнение имате микросекундна детайлност и куп допълнителни данни за InnoDB статистика на заявка или нейните общи характеристики на производителност. Създаде ли временна таблица? Използваше ли индекс? Кеширано ли е в кеша на заявките на MySQL?
Третата функция, която споменахме няколко пъти по-горе - Percona Server излага значително повече данни в SHOW ENGINE INNODB STATUS, отколкото нагоре. Определено помага за по-нататъшното разбиране на натоварването и улавянето на още проблеми, преди те да се развият.
Разбира се, това не е пълен списък - ако се интересувате от повече подробности, може да искате да проверите документацията на Percona Server.
MariaDB
MariaDB стартира като разклонение на MySQL, но след като част от първоначалния екип за разработка на MySQL се присъедини към MariaDB, тя бързо се фокусира върху добавянето на функции. В MariaDB 5.3, много функции бяха добавени към оптимизатора:пакетен ключ за достъп, многообхватно четене, избутване на състоянието на индекса, за да назовем само няколко. Това позволи на MariaDB да се отличи в някои работни натоварвания, където MySQL или Percona Server биха се затруднили. Досега някои от тези функции бяха добавени към MySQL (предимно в MySQL 5.6), но някои все още са уникални за MariaDB.
Друга важна функция, която беше въведена от MariaDB, беше Global Transaction ID. Не много по-късно Oracle пусна собствена реализация, но MariaDB беше първата, която я има. Подобна история е и с друга функция за репликация - репликация с множество източници:MariaDB я имаше преди Oracle. Сега, наскоро пуснатият MariaDB 10.2 също съдържа функции, които ще бъдат достъпни в MySQL 8.0, който все още е в процес на разработка. Говорим например за рекурсивни общи таблични изрази или прозоречни функции.
Характеристики на MariaDB 10.2
Както споменахме, MariaDB 10.2 въвежда функции на прозорци и рекурсивни изрази на общи таблици – подобрения в SQL, които трябва да помогнат на разработчиците да пишат по-ефективни SQL заявки.
Много важна промяна е, че MariaDB 10.2 използва InnoDB. До 10.1 XtraDB се използва като хранилище по подразбиране. Това, за съжаление, прави функциите, добавени в най-новия XtraDB, недостъпни за потребителите на MariaDB 10.2.
Направени са подобрения във виртуалните колони - повече ограничения бяха премахнати в 10.2.
И накрая, беше добавена поддръжка за множество задействания за едно и също събитие – сега можете да създадете няколко, например ON UPDATE тригери на една и съща таблица.
Разработчиците трябва да се възползват от поддръжката на JSON, заедно с няколко функции, които са свързани с нея. Те също трябва да харесват нови функции, които им позволяват да експортират пространствени данни във формат GeoJSON. Говорейки за JSON, бяха направени подобрения в изхода EXPLAIN FORMAT=JSON – показва се повече данни.
По отношение на сигурността е добавена поддръжка за OpenSSL 1.1 и LibreSSL.
Разбира се, този списък не е пълен и ако се интересувате от това, което е добавено към MySQL 10.2, може да искате да се консултирате с документацията.
В допълнение към новите функции, MariaDB 10.2 се възползва от функции, внедрени в предишни версии. Ще преминем през най-важните.
Най-важните характеристики на MariaDB 10.1
На първо място, MariaDB от 10.1 идва в комплект с клъстер Galera - няма нужда да инсталирате допълнителни библиотеки, всичко е готово за използване.
MariaDB 10.1 донесе внедряване на криптиране на данни в покой. В сравнение с функцията, внедрена в MySQL на Oracle, MariaDB я има по-разширена. Той не само криптира пространства за таблици, но също така криптира регистрационни файлове за повторно изпълнение, временни файлове и двоични регистрационни файлове. Това идва с някои проблеми - CLI инструменти като mysqldump или xtrabackup нямат достъп до двоични регистрационни файлове и може да имат проблеми с архивирането на криптирани копия (това е особено вярно за xtrabackup - съвсем наскоро MariaDB създаде xtrabackup fork, наречен MariaDB Backup, който поддържа данни в покой криптиране).
Добре, кой вкус да използвам?
Както обикновено е, правилният отговор би бил:„Зависи“ :-) . Ще споделим няколко от нашите наблюдения, които може или не може да ви помогнат да вземете решение, но в крайна сметка от вас зависи да изпълните сравнителни показатели и да намерите коя опция ще работи най-добре за вашата среда и приложение.
Първо, нека поговорим за потока. Oracle пуска нова версия - да кажем MySQL 5.7. По отношение на производителността в този момент това е най-бързият MySQL вкус на пазара. Това е така, защото само Oracle разполага с достатъчно ресурси, за да работи върху подобряването на InnoDB до такава степен. В рамките на няколко месеца (в случай на 5.7, това беше 4 месеца) Percona пуска Percona Server 5.7 с техния набор от подобрения - в зависимост от вида на натоварването, той може да осигури дори по-добра производителност от предходния. И накрая, MariaDB приема нова версия нагоре по веригата и изгражда новата си версия върху нея.
Ето как изглеждаше в календар (все още говорим за MySQL 5.7).
MySQL 5.7 GA:21 октомври 2015 г.
Percona Server 5.7 GA:23 февруари 2016 г.
MariaDB 10.2 GA:23 май 2017 г.
Моля, обърнете внимание колко време отне MariaDB, за да пусне версия, базирана на MySQL 5.7 - всички предишни версии са базирани на MySQL 5.6 и, очевидно, осигуряват по-ниска производителност от MySQL 5.7. От друга страна, беше пусната MariaDB 10.2, като InnoDB заменя XtraDB. Въпреки че е вярно, че Oracle най-вече затвори разликата в производителността между MySQL и Percona Server, това все още е просто „предимно“. В резултат на това MariaDB 10.2 може да осигури по-ниска производителност от тази на Percona Server в някои случаи (и по-добра в някои други случаи - поради работата на оптимизатора, извършена в MariaDB 5.3, някои от които все още не са пресъздадени в MySQL).
По отношение на функциите е по-сложен. MariaDB добавя много функции, така че ако се интересувате от някои от тях, определено може да помислите да използвате MariaDB. Има и обратна страна. Percona Server имаше много функции, които го различаваха от MySQL нагоре по веригата, но когато Oracle започна да ги внедрява в MySQL, Percona реши да амортизира техните реализации в полза на използването на имплементацията от upstream. Това намали количеството код, който се различава между MySQL и Percona Server, улеснява поддържането на кода на Percona Server и, което е най-важното, прави Percona Server 100% съвместим с MySQL.
Това, за съжаление, не е вярно за MariaDB. MariaDB представи първо GTID, това е вярно, но след като Oracle разработи своята версия на GTID, MariaDB реши да се придържа към собствената си реализация. Този блог не е мястото да решим кое внедряване е по-добро, но в резултат трябва да управляваме две различни, несъвместими GTID системи – добавя тежест върху всеки инструмент, който управлява репликацията и намалява оперативната съвместимост. Придържане към репликация - групово извършване и паралелна репликация:и Oracle, и MariaDB имат собствена реализация и ако работите и с двете, трябва да ги научите и двете, за да приложите необходимата настройка - копчетата са различни и работят по различен начин. Подобен е случаят и с поддръжката на виртуални колони - две различни, не 100% съвместими реализации, които в резултат на това направиха невъзможно лесното изхвърляне на данни от MariaDB и зареждане в MySQL на Oracle (и обратно), тъй като синтаксисът е малко по-различен. Така че, ако решите да използвате версия на MariaDB за някаква чисто нова функция, може в крайна сметка да се забиете с нея, дори ако искате да мигрирате обратно към MySQL, за да използвате внедряването на Oracle. В най-добрия случай миграцията ще изисква много повече усилия за изпълнение. Разбира се, ако останете в една среда през цялото време, това може да не ви засегне сериозно. Но дори и тогава липсата на съвместимост ще бъде забележима за вас, макар и само докато четете блогове в интернет и намирате решения, които не са наистина приложими за вашия вкус на MySQL.
И така, за да обобщим - ако се интересувате от поддържане на съвместимост с MySQL, Percona Server (или самия MySQL, разбира се) вероятно би бил правилният начин. Ако се интересувате от производителност, стига да има Percona Server, изграден върху най-новия MySQL, това може да е правилният начин. Разбира се, може да искате да сравните MariaDB и да видите дали работното ви натоварване не може да се възползва от някои оптимизации, които все още са уникални за MariaDB. От гледна точка на работата вероятно е добре да се придържате към една от среди (Oracle/Percona или MariaDB), коя от двете работи по-добре за вас. MySQL или Percona Server имат предимство по начин, че се използват по-често и е малко по-лесно да ги интегрирате с външни инструменти (тъй като не всички инструменти поддържат всички функции на MariaDB). Ако бихте се възползвали от нова и лъскава функция, която току-що беше внедрена в MariaDB, трябва да я обмислите, като имате предвид всички потенциални проблеми със съвместимостта и възможно по-ниска производителност.
Надяваме се, че тази публикация в блога ви даде някои идеи за различни възможности за избор, които имаме в света на MySQL, и различни ъгли, от които можете да ги сравните. В края на деня ваша задача ще бъде да решите кое е най-доброто за вашата настройка. Може да не е лесно, но все пак трябва да сме благодарни, че имаме избор и можем да изберем това, което работи най-добре за нас.
