Послужила необхідність забезпечення вільного статусу СУБД (під ліцензією GPL), на противагу невизначеній політиці ліцензування MySQL компанією Oracle. Продукт поширюється та використовується згідно з ліцензією GNU GPL v.2, GNU LGPL.

Система написана із використанням: C, C++, Perl, Bash. Продукт працює під управлінням ОС Linux і UNIX-подібних, Windows.

2014: MariaDB Enterprise 1.0

Розвиток MariaDB займається незалежною організацією MariaDB Foundation відповідно до повністю відкритого та прозорого процесу розробки, що не залежить від окремих вендорів. MariaDB поставляється замість MySQL у багатьох дистрибутивах Linux (RHEL 7, SUSE 12, Fedora, openSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian 9). Система впроваджена в проектах: Wikipedia, Google Cloud SQL та Nimbuzz.

Основні покращення MariaDB 10.1

  • Підтримка шифрування таблиць і логів транзакцій, що дозволяє захиститися від витоку даних у разі крадіжки жорсткого диска, але марно в ситуації отримання контролю над СУБД, що працює, наприклад, в результаті атаки через підстановку SQL-запиту або злому системи. При включенні шифрування накладні витрати зростають на 3-5%. Ключі шифрування має сенс зберігати на окремому захищеному сервері з включенням системи ротації ключів, що передбачає періодичне перешифрування з новим ключем після старіння поточного ключа. Підтримка шифрування реалізована у сховищах XtraDB та InnoDB. Пропонується кілька схем: шифрування вибраних таблиць, шифрування всіх таблиць у БД і шифрування всіх таблиць крім вибраних. Завдяки шифруванню лога транзакцій захист також забезпечується у системах із реплікацією;
  • Включення у базове постачання технології синхронної multi-master (active-active) реплікації Galera, раніше запропонованої в рамках окремого продукту MariaDB Galera Cluster. Galera розширює можливості СУБД MariaDB засобами синхронної реплікації, коли всі вузли завжди містять актуальні дані, тобто. гарантується відсутність втрачених транзакцій, оскільки транзакція фіксується лише після поширення даних у всіх вузлах. При цьому в рамках транзакції операції виконуються відразу, затримка через очікування підтвердження виникає тільки при виконанні операції "commit". Реплікація виконується у паралельному режимі, на рівні рядків, з передачею лише інформації про зміни. Управління належністю вузлів кластеру виконується автоматично, збійні вузли одразу виключаються з кластера без участі адміністратора, нові вузли при необхідності можна підключити на льоту без додаткової переконфігурації;
  • Можливість реплікації даних з MySQL 5.6 під час включення на MySQL підтримки GTID, тобто. MySQL тепер може використовуватися як master-сервер для MariaDB. Зазначена можливість дозволяє суттєво спростити тестування у процесі міграції з MySQL на MariaDB;
  • Підтримка стиснення сторінок даних для сховищ InnoDB та XtraDB. Від раніше доступного механізму стиснення (row_format=compressed) новий метод відрізняється можливістю вибору різних алгоритмів стиснення (zlib, lz4, lz0, lzma, bzip2 та snappy) та іншою організацією процесу роботи з упакованими даними. Якщо в традиційній реалізації в буфері знаходяться як стислі, так і ще не упаковані дані, то нова схема має на увазі знаходження в буфері лише розпакованих даних - сторінки стискаються перед записом у сховище та розпаковуються після читання. Новий метод найбільш ефективний при використанні SSD-накопичувачів або NVM-пам'яті. Найкращі результати спостерігаються під час використання плат FusionIO;
  • Реалізовано систему дефрагментації сховищ InnoDB, засновану на напрацюваннях, наданих компанією Facebook. Раніше, при видаленні рядків з InnoDB, вони лише позначалися віддаленими і ставали доступними для нових записів без фактичного звільнення блоків на диску і без повернення дискового простору системі. Виконання "OPTIMIZE TABLE" вирішує зазначену проблему, але шляхом повного перебудови таблиці з копіюванням даних на нове місце, тобто. вимагає великого обсягу вільного дискового простору. Після включення у файлі конфігурації підтримки дефрагментації (innodb-defragment=1) виконання команди "OPTIMIZE TABLE" не призводить до копіювання в нові таблиці, а реалізується через механізм переміщення записів;
  • Реалізовано "оптимістичний" режим паралельної реплікації, який значно спрощений порівняно з засобами паралельної реплікації slave-серверів, що з'явилися в MariaDB 10.0. Зокрема, забезпечено можливість паралельного застосування до slave-сервера будь-яких операцій INSERT/UPDATE/DELETE, навіть якщо вони поки що не завершені на master-сервері;
  • Можливість перевірки ступеня надійності заданого пароля за допомогою плагінів simple_password_check та cracklib_password_check;
  • Внесено порцію оптимізації продуктивності, що дозволило знизити навантаження на CPU і збільшити ефективність роботи на багатоядерних системах. Тестування показало приріст кількості оброблюваних транзакцій від 135 до 190% та можливість обробки більше мільйона OLTP-операцій за секунду;
  • Додано команди "EXPLAIN FORMAT=JSON" та "ANALYZE FORMAT=JSON", у яких висновок з оцінкою характеристик запиту формується у форматі JSON. Штатний висновок команди ANALYZE тепер схожий на висновок EXPLAIN, але включає отримані в результаті виконання запиту дані (кількість прочитаних рядків і т.п.);
  • Кошти для просторової прив'язки (Spatial Reference) даних геоінформаційних систем. Реалізація нових функцій для роботи з просторовими координатами: ST_Boundary, ST_ConvexHull, ST_IsRing, ST_PointOnSurface, ST_Relate;
  • Підтримка виразів "IF EXISTS", "IF NOT EXISTS" та "OR REPLACE" у директивах "CREATE DATABASE", CREATE FUNCTION UDF", CREATE ROLE", CREATE SERVER", CREATE USER", CREATE VIEW", DROP ROLE", DROP USER", CREATE EVENT", "DROP EVENT" CREATE INDEX", "DROP INDEX" CREATE TRIGGER" та "DROP TRIGGER";
  • Підтримка команд SHOW та FLUSH для плагінів, наприклад, "SHOW LOCALES", "SHOW QUERY_RESPONSE_TIME", "FLUSH QUERY_RESPONSE_TIME";
  • Підтримка директиви "SET DEFAULT ROLE", що дозволяє визначити роль за умовчанням, що застосовується до всіх нових сполук;
  • Підтримка systemd.

Після півтора року розробки та п'яти попередніх випусків сформовано перший стабільний реліз нової гілки СУБД MariaDB 10.2, в рамках якої розвивається відгалуження від MySQL, що зберігає зворотну сумісність і відрізняється інтеграцією додаткових двигунів зберігання та розширених можливостей. Розвиток MariaDB займається незалежною організацією MariaDB Foundation відповідно до повністю відкритого та прозорого процесу розробки, що не залежить від окремих вендорів. MariaDB поставляється замість MySQL у багатьох дистрибутивах Linux (RHEL 7, SUSE 12, Fedora, OpenSUSE, Slackware, OpenMandriva, ROSA, Arch Linux, Debian 9) і впроваджений у таких великих проектах, як Wikipedia, Google Cloud SQL та Nimbuzz.

Ключові покращення MariaDB 10.2:

  • Додано експериментальну підтримку двигуна зберігання MyRocks, розробленого Facebook на базі системи зберігання RocksDB, оптимізованої для Flash-накопичувачів. У сховищі MyRocks застосовуються сторінки даних плаваючого розміру, що дозволяють уникнути вирівнювання по фіксованій межі блоку, і модель зберігання даних у формі лога (Log Structured Merge Trees), що допускає лише доповнення (очищення проводиться збирачем сміття). У процесі виконання запитів у кілька разів скорочено кількість операцій послідовного читання/запису, що призвело до збільшення продуктивності порівняно з InnoDB на 20-30% на SDD та до 6 разів на НЖМД при навантаженні з великим числом операцій випадкового запису. Крім того, MyRocks дозволяє на 50% скоротити розмір БД у порівнянні зі стислим сховищем InnoDB та в 3.5 рази порівняно з InnoDB без застосування стиснення. З недоліків MyRocks можна відзначити відсутність підтримки зовнішніх ключів та повнотекстових індексів;
  • Додано підтримку віконних функцій, що задаються ключовим словом OVER і дозволяють обчислити над набором рядків, пов'язаних з поточним рядком. За аналогією з агрегатними функціями віконні функції дозволяють звернутися до інших рядків у процесі обробки результату запиту, але, на відміну від агрегатних функцій, вони не групують результат в один рядок;
  • Підтримка загальних табличних виразів (вираз «WITH») та рекурсивних загальних табличних виразів (WITH RECURSIVE). Секцію WITH можна використовувати визначення підзапитів як локальних тимчасових таблиць, куди можна багато разів посилатися у запиті. WITH RECURSIVE дозволяє звертатися до власного результату, наприклад, можна організувати обхід дерева в процесі виконання запиту;
  • Додано вираз «CONSTRAINT… CHECK» у блоці «CREATE TABLE» для визначення обмежень стовпця;
  • Реалізовано можливість вказівки виразів у блоці DEFAULT, наприклад, b int DEFAULT (a+1). Забезпечено підтримку вказівок значень DEFAULT для полів BLOB і TEXT;
  • Сховище InnoDB оновлено до випуску зі складу MySQL 5.7.18 і задіяне за замовчуванням (раніше за промовчанням пропонувалося відгалуження від InnoDB — XtraDB, сенс використання якого загубився після того, як в InnoDB реалізували більшість основних можливостей XtraDB). У InnoDB додано підтримку просторових індексів (spatial index);
  • Додано вираз "SHOW CREATE USER", що показує повний вираз "CREATE USER", використаний для створення вказаного користувача;
  • Для виразу «CREATE USER» реалізовано опції для обмеження споживання ресурсів та налаштування tls/ssl. Наприклад, тепер можна обмежити максимальну кількість запитів або з'єднань за годину;
  • Подано новий вираз «ALTER USER», що дозволяє внести зміни до облікового запису існуючого користувача;
  • Знято багато обмежень для віртуально обчислюваних стовпців;
  • Додано підтримку виразу «EXECUTE IMMEDIATE» для запуску динамічного SQL-вираження, створеного на льоту;
  • До оператора PREPARE додано можливість використання більшості виразів;
  • Додані функції для роботи з даними у форматі JSON;
  • Додано плагін аутентифікації, який використовує алгоритм ed25519 для зберігання паролів;
  • До складу збірок для Windows, CentOS, RHEL і Fedora додано плагін для розшифрування ключів, що використовуються в Amazon Web Services (AWS) Key Management Service (KMS), для їх подальшого використання для шифрування даних у БД;
  • З'явилася можливість прив'язки кількох різних тригерів до події;
  • Додано підтримку відкладеної реплікації, коли стан slave-сервера на заданий проміжок часу відстає від master-сервера;
  • Перероблено реалізацію виразу ANALYZE TABLE, який тепер не блокує таблицю під час збору статистики;
  • Бібліотека wsrep, що використовується для організації синхронної multi-master (active-active) реплікації Galera, оновлена ​​до випуску 25.3.20;
  • Забезпечено формування пакетів для Ubuntu 17.04;
  • Mysqldump додана опція «-add-drop-trigger», що відтворює функціональність MySQL 5.6 з додавання в SQL-дамп вирази для видалення тригера перед його створенням;
  • Додано скрипт mysqlbinlog для організації безперервного бекапу бінарного лога;
  • Додана підтримка OpenSSL 1.1 та LibreSSL;
  • Додано змінні innodb_deadlock_detect та innodb_stats_include_delete_marked для відключення система визначення взаємних блокувань та обліку записів, помічених як віддалені, при розрахунку статистики;
  • Додана змінна read_binlog_speed_limit, що задає обмеження швидкості, з якої slave-сервер читає бінарний лог master-сервера;
  • Видалено стару клієнтську бібліотеку, що постачається під ліцензією GPL, на зміну якої прийшла нова бібліотека, що має ліцензію LGPL.

Від автора:Система управління базами даних стала невід'ємною частиною розробки динамічного веб-продукту. З її допомогою можна систематизувати весь масив потрібних файлів. Все це потрібно для швидкого доступу та оптимізації роботи програми або сайту. Але щоб повністю освоїти все, хай навіть найпопулярніші, знадобляться десятиліття. Слід визначиться, яку ви будете використовувати, вивчати і прокачувати свій скілл. Найпопулярніше порівняння – MariaDB vs MySQL. На них ми сьогодні і зосередимося. Не забудемо і продукти, які тільки набирають популярність, але вже мають суттєву конкурентну перевагу.

Реляційна система

До того, як були винайдені подібні рішення, не могло бути й мови про створення масивних продуктів. Навіть ті машини, які мали хороший об'єм фізичної та оперативної пам'яті, не могли обробити Big Data, якщо вона зберігалася відносно хаотично – у вигляді файлів. На початку вісімдесятих років було випущено першу РСУБД, розробниками якої стали IBM.

На перший погляд, створення бази даних видається досить тривіальним завданням. Зовні все виглядає просто як велика таблиця, в якій різні типи інформації розміщені у своїх колонках. Насправді, цьому винаходу передувала ціла низка математичних дискусій та спроб розробки. Вся суть була не в тому, щоб зробити просту базу даних, а ту, в якій змінні залежатимуть один від одного. Найбільш точний опис майбутньої БД дав доктор Кодд, який сформував 12 правил реляційної бази. До речі, їх 13 . Вони й досі використовуються розробки реляційної бази даних.

Реляційна система управління базою даних має використовувати жодних інших методів управління, крім реляційних. Все це може здатися простим лише для тих, хто розуміє математичні терміни як мінімум на ідейному рівні. Між кожною атомарною одиницею даних має бути реляційна зв'язок, значно краще, ніж просто файли, розкидані по фізичному сховищу.

JavaScript. Швидкий старт

Як і казали, СУБД – це таблиця, й інший структури може бути в системи. Зате дані в таблиці можуть бути різного типу. Деякі СУБД підтримують не так багато типів, деякі запроваджують навіть нові, для інформаційних технологій. Це і булеви, і стрінги, і дані з точкою, що плаває, і багато інших. І всі ці дані пов'язані між собою згідно з реляційною моделлю.

Проте, щоб прописати дані у рядок, їй потрібно задати тип даних. Дуже схожу процедуру ви робите з осередками в Exel та подібних програмах. Існують, звичайно, і винятки з цих правил, але це вже тема для цілої книги, а не порівняння наших баз даних.

Коли йдеться про веб-сайти та додатки, то в осередках виявляються дані про користувачів ресурсу, сам вміст, продукція і будь-що. Мета бази даних тут у тому, щоб оперативно надавати цю інформацію на запит користувача: серверний скрипт, в обмін на клієнтський.

Переваги та недоліки СУБД

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

Серед недоліків, що часто обговорюються, сучасних систем управління базами даних:

нелегко освоїти. Щоб працювати з Photoshop, вам необхідно познайомитися з основними інструментами цього програмного забезпечення та навчиться їх використовувати. Розуміти, як працює сама програма, необов'язково. Цього не можна сказати про СУБД. Розуміти принципи роботи MySQL означає розбиратися в базах даних. Якщо ви намагаєтеся діяти за шаблоном, то, швидше за все, на розробку чекає невдача. Невідомо, що краще: не розуміти СУБД у принципі чи розуміти її неправильно;

вартість. Сама система управління базами даних може коштувати дуже багато, але обслуговування бази даних, придбання стороннього ПЗ та інші. Навіть розмістити велику базу даних на хорошому хостингу коштує грошей.

вага. Одні тільки файли для функціональної програми будуть важити багато. А якщо обернути їх у базу даних, обсяг суттєво зросте, адже тепер файли мають деякі функції, перебувають у логічному зв'язку та викликаються скриптами. Все це коштує не лише грошей, а й пам'яті на сервері. Це особливо відчутно, якщо сервер служить персональний комп'ютер розробника.

централізоване розміщення. Тільки в останні роки розробники почали використовувати розподілений реєстр для зберігання файлів. Коли файли знаходяться в межах однієї бази даних, вони вразливі.

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

По-перше, це економія пам'яті. Хоча і сама СУБД займає певне місце, вона не дає розмножуватися зайвої інформації. Ніякого надлишку, жодних файлів-дублів. У той самий час, та інформація, яка має зберігатися надміру, зберігається саме в такий спосіб. Як ми й казали, це складна математична модель, яку важко зрозуміти пересічному розробнику.

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

Велику роль грають системи управління базами даних під час спільної розробки. Забезпечити груповий доступ до дерева файлів досить важко, дотримуючись усіх запобіжних заходів. Але ви можете забезпечити санкціонований доступ до СУБД обмеженому колу осіб, без втрат для системи безпеки.

JavaScript. Швидкий старт

Вивчіть основи JavaScript на практичному прикладі створення веб-додатку

До речі, про безпечне зберігання. Сьогодні важко реалізувати зберігання даних краще, ніж із сучасною СУБД. Впровадження АБД дозволяє визначити необхідні заходи безпеки: що може бути кращим? До того ж нові інструменти для захисту бази даних виходять щодня. Доступ, як правило, здійснюється через форму запилення, але за достатніх навичок, ви зможете реалізувати все: від антропометрії до двофакторної аутентифікації. Особливо це застосовується до open-source СУБД, якою є MariaDB (про неї пізніше).

Важко уявити щось краще, щодо резервного копіювання, ніж системи управління базами даних. Якщо ви зберігаєте програму у файлах, значить збереження даних лежить у ваших руках. Ви змушені дбати про те, щоб вчасно створити бекапи та необхідні копії. СУБД може робити це із встановленою періодичністю та переносити інформацію на зовнішній носій або в хмару.

MySQL: заслужений успіх

Однозначно, це найпопулярніша з усіх існуючих СУБД. На ній будують не лише веб-застосунки та складне програмне забезпечення: облік матеріалів у бібліотеці вашого міста, швидше за все, реалізований через MySQL або MSSQL. Функціональність цієї системи змушує конкурентів вигадувати нові і нові рішення. Але й самі розробники не відстають: остання версія програмного забезпечення вийшла зовсім недавно. Свою періодичність вони не переривають уже протягом більш як двадцяти років.

Раніше цією розробкою володіла компанія Sun Microsystems, яка подарувала нам Java та багато інших інструментів розробки. У 2010 році всі продукти, разом з MySQL, перейшли компанії Oracle. Вона здійснює підтримку СУБД і сьогодні.

vСпочатку ця система була розроблена однойменною компанією в 1995 році. Творці використовували найшвидші мови програмування: C, C++ і HTML. Таким чином, розробники отримали у розпорядження стабільну та швидку СУБД із постійною підтримкою. Сьогодні MySQL входить до складу так званих «джентельменських наборів», які складаються із сервера, бази даних та скриптової мови програмування.

Однозначною перевагою MySQL перед конкурентами можна назвати використання. Як завжди, чим популярніше ПЗ, тим легше з ним працювати. Всі баги виявляються швидко, так само швидко виправляються. Не варто забувати і про те, що це програмний продукт для програмістів і розробників, який розвивається швидко завдяки спільноті. Постійно з'являються нові плагіни та різні розширення для MySQL.

Встановлювати MySQL дуже просто. Завдяки наявності GUI - графічного інтерфейсу користувача, це перетворюється на звичайну установку ПЗ. Те саме стосується й інсталяції доповнень до СУБД.

Не можна не згадати про те, що MySQL - одна з найбільш кросплатформових СУБД. Відчувається рука компанії Sun, для якої запуск ПЗ «хоч на калькуляторі» був пріоритетом. Що говорити про масштабованість: майже всі найбільші ресурси, з якими ви працюєте в мережі, побудовані на основі MySQL. Хоча існують і більш професійні варіанти, наприклад PostgreSQL, про який ми не забули.

«Марія», як найкраще в СУБД

Як і у всіх open-source проектів, у MySQL стався вдалий форк, який отримав назву MariaDB. І материнська СУБД, та її відгалуження, носять імена дочок творця: Мю та Марія. Цю систему звикли називати альтернативою MySQL, проте це докорінно неправильна заява. Хоч і суперечки про те, що краще, Maria чи My досі тривають.

Метою розробників «Марії» було створити продукт, повністю сумісний із MySQL, але значно покращений. Наприклад, двигуном для зберігання даних у MySQL була MyISAM. У Марії – це Aria, яка подарувала СУБД велику продуктивність у порівнянні з основним проектом. І хоча MariaDB заснована на MySQL, останні версії містять не більше ніж 25% оригінального коду.

Марія може похвалитися вищою продуктивністю загалом. Особливо це стосується перекодування символів. На високих обсягах інформації коефіцієнт досягає більш як 2%. Налагоджувальний код також оптимізований, порівняно з MySQL. Загалом розробники відзначають вищу швидкість розробки, ніж міг видати «батько». Спільнота, яка працює над MariaDB обіцяє ще більші покращення.

Крім того, сам користувач може покращувати та оптимізувати роботу Марії. Що відрізняє цю СУБД від решти, так це повноцінний open-source: ніяких закритих елементів або модулів, все в доступі. Грати з кодом можна необмежено, як і робити пропозиції щодо зміни спільноти, яка розробляє MariaDB.

Заявка на перемогу від Postgres

PostgreSQL – це ще одна система управління базами даних, тільки вже не реляційна, об'єктно-реляційна. Це означає, що користувач може створювати об'єкти для операцій, куди можуть входити різні дані. Вона повністю безкоштовна і найбільш гнучка. Деякі розробники називають PostgreSQL найпрофесійнішим рішенням, з усіх, що існують на ринку. Ця СУБД з'явилася з некомерційного університетського проекту, створеного у Берклі, що називалася Postgres. Ця система розроблялася довгі вісім років і підтримується до цього дня.

Як буває з такими продуктами, вона вийшла "від програмістів для програмістів" - неймовірно функціональною, але надто складною в освоєнні для звичайного розробника. Спочатку СУБД навіть мала власну мову запитів, але згодом від цієї ідеї відмовилися, залишивши тривіальний «сіквел». Незважаючи на ентузіазм незалежних розробників, PostgreSQL не така гарна, якою її люблять називати. До цього часу у вихідному коді знаходять проблемні місця.

За масштабованістю PostgreSQL не поступається, якщо порівнювати з MySQL та MariaDB. На основі цього програмного забезпечення будуються масивні проекти з обробки Big Data, оскільки її стабільності довіряють розробники. Декілька варіантів інтерфейсу роблять продукт доступним для персоналізації.

Але до масового продукту PostgreSQL ще далеко. Справа в тому, що ця система дуже складна для простого розробника. Навіть якщо взяти в руки документацію, ви не отримаєте відповіді на всі питання, включаючи найбільш логічні. Також, бентежить швидкість виконання запиту в PostgreSQL.

Ця СУБД чудово підходить для корпоративних рішень. Наприклад, база даних для IT-компанії, де її підтримкою може зайнятися кожен із розробників. Тим більше, що PostgreSQL повністю безкоштовна.

На цьому у нас усі. Пам'ятайте, що у таких складних рішеннях як СУБД важко назвати лідера. За використання – це MySQL, за розширюваністю – MariaDB і PostgreSQL. Як тільки ми отримаємо продукт, який стане панацеєю для всіх випадків, ми обов'язково розповімо про це.

JavaScript. Швидкий старт

Вивчіть основи JavaScript на практичному прикладі створення веб-додатку

СУБД є відгалуженням від MySQL і розвивається компанією Monty Program Ab, створеною Майклом Віденіусом після його відходу з Sun Microsystems. Вона включає всі основні відкриті механізми зберігання, включаючи додатково механізм зберігання Maria. У багатьох відносинах MariaDB працюватиме так само, як MySQL: всі команди, інтерфейсів, бібліотек та API-інтерфейси, які існують у MySQL, існують також у MariaDB.

Як повідомляють розробники цієї СУБД, вони мають намір синхронізувати випуски релізів MariaDB з релізами MySQL.

Назва MariaDB походить від імені молодшої дочки Майкла Віденіуса Марії.

Історія

Платформи

Windows amd64 (64-bit), Windows x86 (32-bit), Solaris 10 x86, Solaris 11 x86, Linux amd64 (64-bit), Linux x86, CentOS 5 / RedHat 5 amd64 (64-bit), CentOS 5 / RedHat 5x86 (32-bit).

Редакції

Системи зберігання

    Aria– новий механізм зберігання MySQL та MariaDB (раніше називався Maria). Система зберігання є альтернативою MyISAM, але стійкіша до краху. Завдяки веденню лога операцій, у разі краху, здійснюється відновлення всіх таблиць до стану перед виконанням оператора або до перед виконанням останньої команди LOCK TABLES. Також підтримується можливість відновлення стану будь-якої точки в лозі операцій (включаючи підтримку CREATE/DROP/RENAME/TRUNCATE). У роботі здійснюється краще кешування, ніж MyISAM, а також більш розвинений паралелізм при множинних вставках. Усі внутрішні таблиці MariaDB використовують цей механізм зберігання. Розроблявся з 2007 року.

    MyISAM- Одна з основних систем зберігання даних у СУБД. Вона ґрунтується на коді ISAM і має в порівнянні з ним ряд корисних доповнень. Таблиці MyISAM чудово підходять для використання у WWW та інших середовищах, де переважають запити на читання. Використовується як механізм зберігання за промовчанням.

    XtraDB- являє собою розширену версію механізму зберігання InnoDB, спрямовану на більш ефективну масштабованість сучасного обладнання і включає, в тому числі, безліч функцій, корисних в умовах високої продуктивності. У XtraDB покращено механізм роботи з пам'яттю, покращено роботу підсистеми вводу/виводу InnoDB, додано підтримку кількох потоків читання та запису, підтримку управління пропускною здатністю, реалізацію попереджувальної вибірки даних (read-ahead), адаптивне встановлення контрольних точок (adaptive checkpointing). Розширено можливості масштабування для великих проектів, система організації блокувань адаптована для роботи на системах з великим числом CPU, додані додаткові можливості для накопичення та аналізу статистики. Механізм є повністю зворотно сумісним, і тому може використовуватися як замінник стандартного InnoDB. Система зберігання XtraDB базується на основі Oracle/Innobase InnoDB плагіні версії 1.0.3, з додатковими розширеннями.

    PBXT (PrimeBase XT)- Система зберігання розроблена з нуля і підтримує мультиверсійний метод організації зберігання даних MVCC (multi-version concurrency control), що дозволяє позбавитися блокування при виконанні операцій читання. PBXT підтримує ACID-сумісні транзакції, швидкий відкат транзакцій та відновлення після некоректного завершення роботи сервера. Є засоби для забезпечення цілісності даних, підтримка визначення зовнішніх ключів (foreign key), каскадних оновлень і видалень даних. Підтримується можливість прямого потокового введення та виведення бінарних даних (BLOB) у БД.

    FederatedX- Система зберігання, що дозволяє організувати звернення до віддалених таблиць як до локальних. Є підтримка транзакцій, одночасної установки кількох з'єднань до віддаленої СУБД використання операцій "LIMIT".

Ліцензування

MariaDB доступно відповідно до умов ліцензії GPL v2, як і MySQL. Ліцензія GPL поширюється лише на код, який надається іншим сторонам. Для внутрішнього використання в рамках організації такий код є абсолютно безкоштовним і не підпадає під дію будь-яких умов. Підключення до віддаленої служби, яка працює в MariaDB (або будь-яких інших програм GPL) у фоновому режимі, також є безкоштовним.