Анализ с MariaDB AX - tThe Open Source Columnar Datastore

Отдавна отминаха дните на подхода за една база данни за всички.

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

Доста обичайно е да видите как множество хранилища за данни работят заедно в една и съща среда.

И така, как MariaDB AX се вписва в картината? Как се сравнява с MariaDB TX и какъв проблем решава?

В тази публикация в блога ще разгледаме MariaDB AX и ще видим защо може да искате да го използвате.

Какво е MariaDB AX?

Първо, първо, какво е MariaDB AX?

Това е хранилище на колони и съхранява данните си по ...колона! Реализиран е като отделен двигател в базата данни MariaDB 10.3.

Както може би знаете, MySQL и MariaDB са проектирани да използват плъзгащи се машини за съхранение. Всеки механизъм за съхранение, било то InnoDB, Aria, MyRocks, Spider или всякакви други механизми, са плъгини.

По същия начин, MariaDB AX използва машина ColumnStore:

MariaDB [(none)]> SHOW ENGINES\G
*************************** 1. row ***************************
      Engine: Columnstore
     Support: YES
     Comment: Columnstore storage engine
Transactions: YES
          XA: NO
  Savepoints: NO

Това води до интересна комбинация. Разборът на SQL се извършва от MariaDB, така че можете да очаквате да работите със синтаксис на заявка, който е много подобен на този, с който сте свикнали в MariaDB. Това също така улеснява комбинирането на достъп до MariaDB AX и MariaDB TX в едно и също приложение. Няма нужда от специфични конектори или библиотеки за свързване към две хранилища за данни. Всичко може да се направи с помощта на MySQL или MariaDB клиентска библиотека. Можете също да използвате MaxScale и за двете хранилища за данни, което може да помогне за изграждането на висока наличност за MariaDB AX.

Защо да използваме колонно хранилище за данни?

Нека преминем през кратко въведение в идеята зад колонните хранилища за данни.

Какво прави MariaDB AX различен от MariaDB TX?

Основната разлика е как са структурирани данните. В типичната база данни данните се съхраняват като редове.

Id, Product, Price, Code, Warehouse
1, Door, 10, 12334, EU1
2, Window, 9, 9523, EU1
3, Glass, 12, 97643, EU2

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

Проблемът е, че този начин на съхранение на данни не е наистина ефективен, когато искате да получите само подмножество от тези данни. Да кажем, че искате да получите само колоните „Продукт“ и „Цена“ – за да направите това, трябва да прочетете цели редове, всички данни и след това да изхвърлите ненужните колони. Също така е трудно да се сортират данните. Ако искате да сортирате набора от данни от най-скъпия към най-евтиния продукт, трябва да прочетете всичко и след това да извършите сортирането.

Всички знаем, че базите данни използват индекси, за да ускорят достъпа. Индексът е структуриран по начин, който съдържа съдържанието на индексираната колона, както и указател към пълния ред (в InnoDB това е първичният ключ). Например, индекс в колоната „Продукт“, ако се приеме, че „Id“ е първичният ключ, може да изглежда така:

Product, Id
Door, 1
Window, 2
Glass, 3

Това ускорява достъпа до данните, тъй като няма нужда да четете целия ред, само за да намерите стойност в колоната „Продукт“. След като базата данни го намери, тя може да прочете останалата част от реда (ако е необходимо), като следва показалеца.

В магазин за колони нещата са различни. Данните са структурирани не като редове, а като колони. До известна степен това е подобно на индекса. Нашата таблица в колонно хранилище за данни може да изглежда така:

Id: 1, 2, 3
Product: Door, Window, Glass
Price: 10, 9, 12
Code: 12334, 9523, 97643
Warehouse: EU1, EU1, EU2

В MariaDB AX колоните се съхраняват в отделни файлове, като всеки запис за даден „ред“ започва от едно и също отместване.

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

В нашия пример по-рано, вместо да четем целия набор от данни, можем просто да заредим данни за колоните „Продукт“ и „Цена“. Това намалява данните, необходими за достъп на диска, и ускорява процеса.

Това, което също е важно, съхраняването на данни в колони ги прави по-малко различими, което ги прави по-добре компресирани. Например, в нашата колона „Склад“ имаме само два типа записи. Дори в реалния сценарий е много вероятно да се окажем с малък брой складове в сравнение с броя на продуктите. Това прави колоната „Склад“ много добра цел за компресиране.

В резултат на всичко това колонните хранилища за данни могат да обработват по-добре голям набор от данни и могат да го правят заявки по по-ефективен начин от „стандартните“ бази данни, фокусирани върху OLTP.

Защо да използвам MariaDB AX?

Достъпът до диск е основна пречка в базите данни. Колонното хранилище за данни подобрява производителността, като намалява количеството данни, които трябва да бъдат прочетени от диска. Той чете само данните, необходими за отговор на запитването.

Разбира се, MariaDB AX не е единственото колонно хранилище за данни. Има много други като например Clickhouse или Apache HBase.

Истината е, че нито една от другите опции не поддържа пълен SQL синтаксис, който MySQL прави. Те изискват различни конектори, различен подход към заявката на данните, докато MariaDB AX може да бъде запитан точно както бихте направили заявка за „нормалния“ MariaDB.

Това, което също е важно, като се има предвид, че MariaDB AX използва двигател ColumnStore, е напълно добре да го смесвате с други двигатели. Можете да смесвате и обединявате таблици InnoDB и ColumnStore в една и съща заявка без проблем.

Освен това инструментите, които идват с MariaDB TX, като MaxScale, ще работят добре с MariaDB AX, което улеснява изграждането на интегрирана, лесна за използване среда. Така че, когато изпълнявате ClusterControl с MariaDB 10.3 и MaxScale, можете лесно да добавите MariaDB AX в микса и той ще работи с други части от настройката.

MariaDB AX се предлага с инструменти, които са предназначени да помогнат при прехвърлянето на данни от други източници. Ако случайно използвате Kafka или Spark, има конектори, които да използвате, когато импортирате данни от тези източници в MariaDB AX.

Освен това, въпреки че редовната репликация между MariaDB TX (InnoDB) и MariaDB AX (ColumnStore) не се представя добре поради ограниченията на ColumnStore (винаги е по-добре да правите пакетни вмъквания в колонни хранилища за данни, отколкото единични вмъквания, както се прави при репликация), това е възможно е да се изгради тръбопровод, който да се състои от MaxScale, конфигуриран като binlog сървър и Avro CDC рутер, MaxScale CDC Data Adapter и MariaDB AX, който ще получава данни от адаптера почти в реално време.

Надяваме се, че тази публикация в блога ще ви даде представа какво представлява MariaDB AX и как може да се използва заедно с MariaDB TX среда, разгърната и управлявана от ClusterControl (изтеглете я безплатно!).