MySQL “на стероїдах”, Різне, Програмування, статті

Ігор Савчук


Придбання корпорацією Oracle компанії Sun поставило під питання існування і характер подальшого розвитку відразу безлічі відомих вільних технологій. У цій статті мені б хотілося коротко розглянути історію, сучасний стан, динаміку розвитку та перспективи такого відомого і сверхзначімого для сучасного інтернету проекту, як сервер баз даних MySQL. Тут ми перерахуємо і розглянемо специфіку всіх популярних існуючих нині Форк MySQL, які не лише активно розвиваються останнім часом, але і багато в чому вже перевершили свого батька – MySQL.


Сервер реляційних баз даних MySQL (RDBMS MySQL) за короткий час встиг стати сверхпопулярной СУБД, а також незамінною частиною сучасного Інтернету, входячи у священну зв’язку з “великої четвірки” відкритих web-технологій LAMP (Linux-Apache-MySQL-PHP ), Яка і формує технологічно майже весь сучасний Web. Роль баз даних у цій зв’язці в наш насичений інформацією століття все більше і більше набуває винятковий характер, і тому архітектура сучасного сайту завжди має на увазі наявність швидкого і гнучкого сховища інформації, роль якого в сучасному інтернеті в більшості випадків уготована саме MySQL.


Історично, перша більш-менш працездатна публічна версія MySQL мала номер 3 і була випущена в 2000 році. Цю версію можна лише умовно назвати СУБД – це була, скоріше, лише заготовка для майбутнього сервера БД з самою мінімальною підтримкою SQL. Потім, в 2004 році після дуже тривалого тестування і обкатки зарелізілась дуже вдала і добре збалансована по функціоналу і якості коду версія 4, яка і отримала саме широке поширення в Web-проектах, створивши ту саму популярність, яку проект MySQL пожинає і до цього дня.


У ній вперше з’явилися сполуки, підзапити, підтримка B-і R-дерев, коротше, той мінімум підтримки SQL, який реально дозволяв використовувати MySQL як вільне і ефективне сховище даних для реальних малих і середніх проектів по всьому світу. Рівно через рік спішно була доопрацьована і випущена нова версія 5, яка вдає із себе вже цілком закінчену і логічно зрілу СУБД з усіх точок зору, що містить в собі такі просунуті можливості, як, наприклад, збережені процедури, подання, курсори, тригери, транзакції і багато іншого. Версія 5.1, що вийшла в 2008 році, – це подальша шліфування тієї ж “п’ятірки” з додаванням планувальника подій, підтримки плагінів і розширень, зберігання логів і статистики сервера у вигляді таблиць БД, а також багатьох інших декоративних змін-зручностей.


У міру приходу популярності і початку активного розвитку проекту в нього стали з’являтися і серйозні проблеми, якість розробки погіршили численні перепродажу і зміни власника компанії-розробника MySQL AB. Наприклад, навіть остання версія MySQL 5.1 містить ряд серйозних помилок (які добре документовані й відомі), що призводять до краху сервера або видачі невірних результатів – їх виправлення відкладається постійно на потім нібито в силу їх серйозної архітектурної природи. У порівнянні з версією 4.1, в нових версіях серйозно впала продуктивність. Коротше, я б назвав би все це типовою проблемою зростання відомого проекту. На цьому перехідному етапі, коли сміливі бажання, вскруженние успіхом голови і породжувані настільки швидким розвитком складні проблеми стали випереджати реальні можливості розробників, десь в районі 2008-2009 років з’явилося багато незадоволених вищеописаним станом справ, після чого стали, як гриби після дощу, з’являтися альтернативні Форк-реінкарнації добре відомого нам MySQL.


З безлічі прикладів наведу тільки один, зате найбільш яскравий приклад – це відхід з Sun самого автора і творця MySQL Майкла Вайдініуса (Michael “Monty” Widenius) саме через причини надзвичайно неякісного виробничого циклу розробки MySQL, встановленого в стінах Sun Microsystems, коли ще об’єктивно не готову програму (до речі, призначену для промислової експлуатації) адміністративними заходами примушують реліз до заздалегідь жорстко встановлених дат, пояснюючи це якимись туманними маркетинговими міркуваннями. Крім того, на думку Майкла Вайдініуса, розробка повинна вестися в єдиному відкритому просторі, без поділу вихідних текстів на комерційну та ком’юніті гілки, як це зробила Sun. Так, наприклад, в гілці MySQL 5.1 досі не виправлені 20 добре відомих критичних помилок, що призводять до краху процесу або до спотворення даних.


Число критичних помилок можна сміливо збільшити ще на 35, якщо враховувати невирішені проблеми гілки 5.0, які, швидше за все, присутні і в 5.1. На тлі цього наростаючого бардака терпіння Майкла увірвався, і він вирішив звільнитися після того, коли навіть критична помилка, пов’язана зі збоєм при зміні первинних ключів в режимі порядкової реплікації, не зупинила Sun від випуску фінального “стабільного” релізу MySQL 5.1. Чи потрібно говорити про те, що з переходом MySQL у власність Oracle ситуація з розробкою тільки ще більше погіршилася? Всі ці надзвичайно деструктивні тенденції дуже сильно підхльоснули творчість розробників цієї популярної БД “на стороні”. Якщо подивитися ретроспективно, то 2008-2009 рік – це різкий сплеск створення проектів-Форк MySQL, і слід зауважити, забігаючи трохи вперед, що багато з них виявилися дуже навіть перспективними та успішними. Тепер давайте розглянемо оглядово головні з них на кінець 2010 року.


ExtSQL


У розвитку різних гілок їх розробники пішли різними концептуальними шляхами. З одного боку, зроблена спроба нарощування ще більшої функціональності і додавання безлічі нових фичей – наприклад, це проект компанії Software Workshop під назвою ExtSQL. У проекті паралельно ведуться дві гілки розробки, що базуються, відповідно, на кодових гілках четвертий і 5-ої версії оригінального MySQL. ExtSQL розроблявся з сильним ухилом на спеціалізоване використання в системах web-хостингу і покликаний вирішити проблеми, пов’язані з організацією обліку споживання ресурсів. Адміністратори ExtSQL отримують можливість повного моніторингу активності користувачів, всіх баз даних і з’єднань.


Наприклад, запит “SHOW STATISTICS select, insert FROM user HISTORY“Дозволить дізнатися число запитів”select“І”insert“, Скоєних користувачами за останній час. Природно, для цього в колишньому MySQL додані нові команди і розширений діалект SQL, але при цьому збережена повна зворотна сумісність з MySQL. Окрім підтримки своєї версії MySQL, організація-розробник Software Workshop входить до складу технічного комітету INCITS H2, який бере участь у розвитку стандарту SQL, і активно намагається домогтися розширення SQL в плані додавання можливостей для обліку споживання серверних ресурсів. В цілому, якщо говорити мовою цифр, то незалежне тестування показують, що плата за подібні надбудови над MySQL виражається в втрати продуктивності сервера в середньому на 5% на звичайних завданнях і на 15-20% при інтенсивній роботі з реально великими базами даних. Отже, ExtSQL – це свого роду редакція “MySQL Server Advanced Hoster Edition “для особливо вимогливих користувачів СУБД цього класу.


Drizzle


Цілком протилежною дорогою пішов інший популярний форк MySQL – проект Drizzle. Цей проект заснований колишнім директором MySQL з архітектури Брайаном Ейкером (Brian Aker) і являє собою спрощений і більш швидкий варіант MySQL, в якому ретельно відібрані і видалені всі ресурсомісткі і малозатребуваних можливості MySQL 5. Частина з цих можливостей все-таки можна реалізувати через спільні плагіни. Ця СУБД позиціонується як високошвидкісна і високонадійна БД з підтримкою ACID-транзакцій. В якості сховищ даних використовуються InnoDB і PBXT. Цікаво, що весь сішний вихідний код MySQL був повністю переписаний на мові C + +. Управління проектом знаходиться в руках незалежного спільноти.


На відміну від SQLite, Drizzle не претендує на роль вбудованого рішення і реалізований у вигляді сервера. Архітектура Drizzle побудована на основі ідеї мікро-ядра, в ній сповідаються максимальне спрощення структури БД і винос логіки на сторону додатків. Зокрема, такий дизайн СУБД дозволяє організувати обробку просто ВЕЛИЧЕЗНОГО числа паралельних запитів, при виконанні яких повною мірою задіюються потужності сучасних багатоядерних CPU. Як результат – Drizzlовскіе пікові показники інтенсивності обміну запитами-відповідями з web-додатком заважить будь-який стандартний сервер MySQL 5.1, який просто захлинеться під такий навантаженням (тисячі або десятки тисяч мережевих з’єднань у випадку “звичайного” MySQL майже гарантовано викликають проблеми з пам’яттю сервера БД – див відкриті помилки bug#26590, bug#33948, bug#49169, Так що не думайте, що при такому навантаженні досить просто оновити залізо сервера).


Крім цього, в Drizzle додатково реалізовані вбудовані засоби для рознесення даних по ключовому полю (шардінг) на кластер з декількох машин, для створення ефективної балансування навантаження для по-справжньому сверхнагруженних проектів. У порівнянні з MySQL, в Drizzle видалена підтримка збережених процедур (замість CREATE FUNCTION слід використовувати зв’язуються об’єкти), тригерів, кеша запитів (query cache), Уявлень (view), Операцій GRANT і ALTER, Обмежень ACL, Команди SHOW, Попередньо підготовлених запитів (prepared statement) Та ін Припинено підтримка маловикористовуваних типів даних з MySQL. На питання опонентів, як же можна використовувати БД, наприклад, без viewов, розробники відповідають в тому ключі, що “всі ті, кому дійсно серйозно потрібні viewи, вже давно сидять на PostgreSQL або Oracle, це ж стосується і всіх інших просунутих фичей “.


Так, дійсно, для запуску під Drizzle, наприклад, дуже багатьох блогових движків, написаних у зв’язці з MySQL, знадобиться модифікація і деякий тюнинг коду цих движків. Втім, як заспокоюють розробники, зміни ці невеликі, і можливостей Drizzle, насправді, більш ніж достатньо для повноцінного функціонування більшості популярних CMS. Крім того, співтовариство вже кастомизировать багато відомих php-движки під Drizzle, що дозволяє показувати їх рекордну продуктивність на тому ж залозі, на якому раніше крутився старий-добрий MySQL. В якості приємного побічного ефекту, на Drizzle перестали проходити багато популярних різновиду “sql-injections” для MySQL, так що безпека стала мимовільним бонусом цього проекту, попутно демонструючи нам всім глибокі філософські висновки про те, що мінімалізм майже тотожний безпеки.


SkySQL


Розглянувши, так би мовити, крайнощі – максі-і міні-варіанти оригінального MySQL, давайте подивимося, які є більш традиційно-класичні продовження цього відомого проекту. На тлі тотального виведення з Oracle розробників MySQL (з Oracle добровільно “катапультувався” вже більше 70% оригінальної команди MySQL AB), вони, розбрідаючись по світу, намагаються якось заново підлаштуватися вже під нову історичну епоху для MySQL.


Так з’явилася компанія SkySQL, Заснована звільнилися з Oracle розробниками MySQL, частково фінансується кількома колишніми інвесторами MySQL AB і очолювана Ульфом Санбергом (Ulf Sandberg), колишнім віце-президентом з надання глобальних сервісів MySQL. Нова компанія поки не має наміру розвивати свій форк MySQL, а займеться наданням комерційної технічної підтримки, консалтингових послуг, навчанням і продажем готових рішень на базі MySQL. Крім того, SkySQL організувала випуск і підтримку альтернативної промислового складання MySQL – SkySQL Enterprise. Продукт розповсюджується за передплатою і забезпечений повноцінної технічною підтримкою (Допомога у вирішенні проблем, консультації з налаштування, усунення наслідків збоїв) і консалтинговим сервісом (планування впровадження та проведення оптимізації), тобто фактично повністю перезапустила бізнес свого прототипу, нині дістався Oracle, – шведської компанії MySQL AB. Так от, тут дуже цікаво, що входить до складу цієї самої SkySQL Enterprise? А входить туди, крім супутніх утиліт, “Прозора заміна” MySQL – MariaDB Server.


MariaDB Server


Давайте зупинимося і задамося питанням – що ж таке MariaDB Server? Для цього небагато відкотимося в короткий історичний огляд, щоб зрозуміти, звідки і навіщо взявся цей черговий новий форк MySQL. Майкл “Монті”, творець і беззмінний лідер проекту СУБД MySQL, покинувши в Наприкінці 2008 року компанію Sun Microsystems і припинивши безпосередньо брати участь в розробці MySQL, задумав створити максимально сумісний з MySQL, але ідейно новий сервер, який базується на принципово новому движку сховища даних. Нове сховище даних, що використовується в MariaDB, – це стійкий до збоїв клон MyISAM. Багато фахівців відзначають, що Maria Engine це, як мінімум, один з кращих двигунів для вибірки даних з усіх, що зараз існують, тоді як у класичній MySQL дефолтний MyISAM – її найслабше місце.


У новій компанії разом з Монті над проектом працюють близько 20 співробітників – колишніх розробників з MySQL AB, які пішли з Sun слідом за своїм ідейним лідером. Творець MySQL заявляє, що в MariaDB Server забезпечується максимально точна і сумісна інтерфейсна копія SQL, що використовується в оригінальному MySQL 5, тоді як всередині цей сервер уже багато в чому перевершує свій прототип, що дав йому життя і стартову кодову базу. Більше того, Монті заявив, що MariaDB відтепер є єдиною офіційною версією MySQL, тоді як Oracle MySQL “is now dead”. Найстрашніше в цьому молодому проекті – це те, що багато незадоволені жіночим назвою нової СУБД: ну, так одну з дочок автора MySQL звуть My, а другу – Maria. Звідси й назви систем. Є, правда, ще один син, і звуть його, про всяк випадок, Max. І MaxDB вже, до речі, створена, але тут про неї не буде сказано ні слова.


Таким чином, підсумовуючи, частина розробників після відходу з Sun і Oracle осіла в компанії Monty Program , Де день і ніч вони пиляють новий-старий MySQL, але під уже новою назвою – MariaDB Server, Тоді як друга частина програмістів і сервісного персоналу з колишнього MySQL AB заснувала компанію SkySQL із супроводу та підтримки MariaDB Server. І до речі, на мою думку, MariaDB Server – це найякісніша і збалансована заміна для MySQL після того, як Oracle цю СУБД поховає (а на мою суб’єктивну думку, чекати цього залишилося вже не довго, і перші дзвіночки як би навіть вже подзвонюють).


Наприклад, на моєму хостингу MariaDB прекрасно працює в зв’язці з PHP5, обслуговуючи звичайні WordPressи та інші популярні движки, для роботи з БД налаштований звичайний PhpMyAdmin, Самі користувачі хостингу про існування такої БД навіть і не підозрюють, приймаючи її за справжні MySQL. Хоча заради справедливості варто зауважити, що самі розробники кажуть, що розбіжність з кодової базою MySQL вже зараз досягла приблизно 20 відсотків і буде, звичайно, наростатиме й далі. Також мною перевірялася робота MariaDB в зв’язці з MySQL Proxyі спеціалізованим файрволом для MySQL – GreenSQL: Обидві софтина працювали з MariaDB прямо як з рідною MySQL, так що думаю, що, як мінімум, одна гідна і дуже перспективна альтернатива MySQL вже відбулася. Хочеться додати, що MariaDB Server, як і Drizzle, дуже активно розвивається і еволюціонує. Принаймні, кожен з цих двох проектів дуже добре виглядає в своїх, кілька різних цільових нішах.


OurDelta


Наступний проект, який ми коротко розглянемо, – це дистрибутиви OurDelta. Насправді, це популярні ре-збірки двох upstream-проектів: для MySQL 5 підтримуються два паралельних дистрибутива – OurDelta і OurDelta-Sail. Якщо в перший дистрибутив включаються білди, зібрані із застосуванням до стандартних сирцю MySQL 5 тільки добре протестованої колекції сторонніх “неканонічних” патчів, то в другу, почасти експериментальну гілка включається все найпрогресивніше і максимально свіже, що мається на момент релізу, але зрозуміло, що часто воно толком ще не обкатана як слід в реальних умовах, з усіма витікаючими звідси наслідками.


Крім цього, в паралельній гілці OurDelta розширюється і функціональність MariaDB 5, яка вважається прямим конкурентом і приймачем MySQL, але тут на даний момент є тільки одна гілка збірок – стабільна для MariaDB. Що ж це за такі патчі, якими регулярно пригощає нас проект OurDelta?


Основна частина робочого матеріалу – це адаптація в одну гілку сумарних напрацювань MariaDB Server, а також патчсета компанії Google, який вона розвиває для своїх власних потреб, масштабуючи і розширюючи (Часом досить радикально) функціональність оригінального MySQL. Наступний великий донор проекту – це патчсети від Марка Калагхана (Mark Callaghan) з Facebook, який запекло “пиляє під себе” MySQL для цієї компанії вже п’ятий рік. Крім того, використовуються патчі ряду інших компаній, перераховувати які тут немає сенсу в силу їх граничної маловідомі широкому колу читачів і письменників навроде мене. Таким чином, проект OurDelta – це свого роду “MySQL / MariaDB на стероїдах”, що робить просунуті, накачані новою функціональністю збірки MySQL / MariaDB на колір і смак. Хотілося б лише зазначити, що в OurDelta дуже охоче використовують патчі також і від такого самобутнього проекту-Форк, як Percona, на якому давайте зараз зупинимося трохи детальніше.


Percona

Компанія Percona заснована у 2008 році двома вітчизняними розробниками, вже колишніми членами MySQL dev.team Петром Зайцевим та Вадимом Ткаченко. Їх сервер баз даних грунтується на кодової базі MySQL 5.1, яка доповнена власними численними і (що хочеться окремо підкреслити) досить якісними патчами, спрямованими на додавання нових функцій, підвищення стабільності роботи і підвищення зручності адміністрування. Але головна фіча проекту – інтеграція власного движка XtraDB, заснованого на коді InnoDB-plugin і повністю сумісного з ним, але відрізняється істотно більш високою продуктивністю. Крім того, Percona поставляє разом з цим движком дуже потужну бекаповую систему XtraBackup, яка дозволяє вирішувати і автоматизувати навіть самі екзотичні завдання з області збереження даних, ввірених за зберігання серверу БД.

Так от, в експертних кулуарах зараз (на кінець 2010 року) ніби вважається, що основна гостра конкуренція розгорається саме між движками Maria Engine (Движок зовсім недавно був перейменований в Aria) і якраз Percona XtraDB – Ніяких більш просунутих на даний момент storage engines просто немає в природі, так що дідок MySQL буде потихеньку по-любому здавати свої позиції на тлі його більш активних і стурбованих розвитком конкурентів, якщо, звичайно, Oracle раптом не схаменеться і не стане вкладати сили / ресурси у подальшу глибоку розробку системи.


На додаток, тут можна подивитися цікаве відео з виступом члена команди Percona Євгена Степченко, в якому дається детальний огляд проекту Percona.


NoSQL


На закінчення хотілося б сказати, що підбір модифікації MySQL, найбільш підходящою до конкретного технічного завдання, зовсім не обмежується вибором оптимального дистрибутива і тюнінгу його налаштувань; можна вибирати і принциповий режим роботи самого сервера. Як приклад наведу нещодавню успішну реалізацію підходу NoSQL на базі MySQL-сервера.

Ще один колишній учасник MySQL dev.team Йошинорі Мацунобу (Yoshinori Matsunobu) у своїй докладної технічної статті (Див. також її переклад на російську мову) розповідає про цю новою методикою, а також ділиться тестами і реальним кодом клієнтів, який можна вже прямо зараз використовувати в високонавантажених проектах.


Ну що тут сказати – рішення дуже красиве. Плагін HandlerSocket дозволяє гнучко перемикатися між звичайним SQL-синтаксисом зі звичайних клієнтів і власним протоколом для переходу в NoSQL-режим надвисокої продуктивності. І все це чудо миттєвого перетворення MySQL в суперпродуктивна СУБД є на самому звичайному залозі! Працюючи в цьому режимі, Йошинорі фактично уперся в пропускну здатність наявного каналу (1Gb), так що рости ще є куди 😉

Завершуючи свою оглядову статтю про життєвий цикл MySQL, хочу побажати вам вдумливого вибору, прийнятних навантажень на ваших серверах БД, а всім нам разом – подальшого розвитку чудових Форк, широке різноманітність яких об’єднує лише одне: загальний знатний батько – чудова СУБД MySQL!

Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*