Mariadb проти mysql

Версія для друку

Існує досить багато причин для того, щоб перейти на MariaDB. Давайте подивимося, чи настільки вони вагомі, щоб переконати вас це зробити.

MariaDB - різновид вихідного коду MySQL. відокремилася відразу після того, як почали з'являтися сумніви про те, що Oracle буде робити з ліцензуванням MySQL (MySQL був придбаний компанією Sun. яка незабаром була сама куплена Oracle). Це досить виправдані сумніви, про які я поговорю трохи пізніше. Крім своєї ролі "спрощеної версії" MySQL, MariaBD також володіє декількома новими функціями, які, на думку деяких, роблять її краще MySQL.

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

Команда розробників MariaDB, мабуть, знають про це, тому що вони вирішили використовувати нову схему нумерації. Найновіша версія MariDB (яка все ще є альфа-версією) - Maria 10.0, за якою слідує молодший номер пристрою:

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

Так що за нові функції? Давайте розглянемо парочку з них.

Однією з унікальних функцій MariaDB є її движок для з'єднання з серверною версією СУБД Cassandra. Сам движок є просто посередником, який з'єднується з сервером Cassandra, запущеним окремо. Cassandra - це NoSQL сховище даних, яке спочатку було створено для Facebook. а потім стало проектом Apache; хоча воно і може використовуватися в кластерах без єдиної точки відмови, воно все ще не є сумісним з ACID. Взагалі, якщо ви збираєтеся використовувати Cassandra як движка, не чекайте такий же швидкості продуктивності, як у InnoDB або ExtraBD.

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

Так що ця функція може бути корисною, якщо ви. мм. Дайте подумати. ну.

Якщо ви пишете програмне додаток, яке вимагає доступу до даних в Cassandra, тоді вам, можливо, краще використовувати вбудований Cassandra API, а не MySQL. Вважаю, що якщо ви страждаєте з інтерфейсом командного рядка MySQL і потрібно взяти деякі дані, то Cassandra може виявитися корисною - але якщо ви збираєтеся скористатися цим, то чи не простіше помучитися з інтерфейсом командного рядка Cassandra?

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

Не буду надто багато про нього розповідати, так як ідея та ж, що і в Cassandra: движок є просто інтерфейсом обчислювального движка Open Query Graph (сховища для організації складних графів). Це може допомогти в деяких спеціалізованих додатках, хоча адаптація структур графів до SQL формату є на перший погляд трохи дивною.

Одним важливим поліпшенням, що робить MariaDB більш потужною, є використання XtraDB як прискореного заміщення InnoDB. Але XtraDB додає нові можливості масштабування, в яких потребують сучасні програми - і саме в цьому полягає головна відмінність. Oracle стверджує, що на даний момент MySQL масштабує краще, ніж будь-коли раніше. Можливо, це так і є, але вона хороша так само, як і її движок. А якщо движок на практиці не масштабує так, як слід, то і MySQL не зможе зробити цього краще.

Однією з головних причин, чому слід вибирати реляційну базу даних, а не звичайну NoSQL, є те, що реляційна база повністю сумісна з ACID. Простіше кажучи, якщо виникає якась помилка, ніхто не хоче, щоб всі дані зникли. І хоча на комп'ютерах розробників помилки - явище нечасте, вони все ще відбуваються в багатьох IT центрах. На даний момент, стандартний InnoDB / XtraDB движок для запису даних використовує подвійну буферизацію. щоб гарантувати успішну запис даних в разі будь-якого збою. Як би там не було, при роботі з високошвидкісними SSD пристроями (візьмемо за приклад), подвійний буфер може погано позначитися на продуктивності, не даючи вам можливості використовувати всю швидкість SSD. Яке рішення? Ви можете вибрати один буфер і скористатися режимом атомарної записи (Atomic Writes). Спробуйте на свій страх і ризик і, краще не на виробництві.

Повторюся, функція цікава, але не настільки, щоб переконати вас закинути MySQL і перейти на MariaDB.

Порівняння продуктивності MySQL і MariaDB

Одним з найбільш поширених результатів неправильного кодування є те, що ви будете спостерігати приріст продуктивності при роботі з першими 8 або 16 потоками, після чого ніякого поліпшення спостерігатися не буде. Якщо у вас виникла така проблема, то швидше за все справа в алгоритмах. І це буде в разі або з гіперпотокамі, або з апаратними потоками. Це саме те, що ми спостерігаємо в тестах MySQL. Для мене це означає наявність проблем з масштабуванням в MySQL, і це привід задуматися. У тому ж тесті у MariaDB також спостерігалися деякі проблеми, тому що продуктивність зменшувалася, але незначно; я припускаю, що це не стосується паралельних алгоритмів.

Також я не знаю, наскільки добре деякі версії підходили до комп'ютерів, які використовувалися для проведення тесту. При компіляції Intel-коду, вам потрібно, щоб компілятор генерував SIMD-код розміру, відповідного для цільової машини. У разі невідповідності ви не отримаєте очікуваного продуктивності від вашого коду векторизації. Щоб зробити це правильно, вам буде потрібно вставити в код потрібні Прагма, потім правильно написати алгоритми векторизації і, нарешті, запустити відповідні опції компілятора. Знаю, звучить безглуздо, але я бачив програми, видані з неправильними опціями частіше, ніж ви думаєте. У будь-якому випадку, чистий MySQL-код не був так оптимізований для підтримки багатоядерності і векторизації, як MariaDB.

Найбільше мені хотілося б побачити різновид або MySQL, або MariaDB, скомпільовану спеціально для співпроцесора Intel Xeon Phi, де код розвантажує 61-ядерний cопроцессор, а хтось намагається розкрутити все 244 потоку. На жаль, у мене немає доступу до такої машини. Також, якщо ви хочете дізнатися більше про векторизації і паралельному кодуванні, почитайте останню книгу співробітників Intel Джеймса Джефферса (James Jeffers) і Джеймса Райндерса (James Reinders) "Високопродуктивне програмування для співпроцесора Intel Xeon Phi".