29 октября 2009 г. стал особенным днем в сообществе баз данных - состоялся первый релиз MariaDB Server. MariaDB, изначально созданная как ответвление от MySQL после покупки её Oracle Corporation, развилась и теперь является одной из самых популярных и надежных систем управления реляционными базами данных (RDBMS) в мире. В этом месяце (октябрь 2024) MariaDB отмечает свое 15-летие, поэтому я подобрал 15 причин, из опыта общения и практики, по которым разработчики и администраторы баз данных любят MariaDB.
Разработчики приложений
Давайте рассмотрим некоторые функции MariaDB, которые просто обожают разработчики приложений.
Причина 1: Динамические столбцы
MariaDB предлагает динамические столбцы, которые позволяют хранить различные наборы столбцов в каждой строке таблицы. Эта функция добавляет гибкости в работе с быстро меняющимися структурами данных без изменения схемы.
Пример:
CREATE TABLE products ( name VARCHAR(100) PRIMARY KEY, -- a common attribute for all assets dynamic_cols BLOB -- dynamic columns will be stored here
);
INSERT INTO products
VALUES ("T-shirt", COLUMN_CREATE("price", 40, "size", 'M')), -- dynamic schema ("Laptop", COLUMN_CREATE('price', 3000, "ram", "36GB")); -- dynamic schema
SELECT name, COLUMN_GET(dynamic_cols, "price" AS INT) AS price, COLUMN_GET(dynamic_cols, "size" AS CHAR) AS size, COLUMN_GET(dynamic_cols, "ram" AS CHAR) AS ram
FROM products;
+---------+-------+------+------+
| name | price | size | ram |
+---------+-------+------+------+
| Laptop | 3000 | NULL | 36GB |
| T-shirt | 40 | M | NULL |
+---------+-------+------+------+
Документация: https://mariadb.com/kb/en/dynamic-columns/
Причина 2: Невидимые столбцы
Невидимые столбцы в MariaDB упрощают изменение схемы. Вы можете добавлять новые невидимые столбцы в таблицу, и они не будут отображаться в результатах SQL-запросов, если только не было явно запрошены, что позволяет осуществлять более плавные переходы, например, во время обновления вашего приложения.
Пример:
CREATE OR REPLACE TABLE products (
name VARCHAR(100) PRIMARY KEY
);
INSERT INTO products VALUES ("T-shirt"), ("Laptop");
SELECT * FROM products; -- before
+---------+
| name |
+---------+
| Laptop |
| T-shirt |
+---------+
ALTER TABLE products ADD COLUMN column_for_new_app_version INT INVISIBLE;
SELECT * FROM products; -- after (the new column is not visible)
+---------+
| name |
+---------+
| Laptop |
| T-shirt |
+---------+
INSERT INTO products(name, column_for_new_app_version)
VALUES ("MariaDB Server", 15); -- insert value in invisible column: it works
SELECT * FROM products;
+----------------+
| name |
+----------------+
| Laptop |
| MariaDB Server |
| T-shirt |
+----------------+
ALTER TABLE products
MODIFY COLUMN column_for_new_app_version INT; -- make the column visible
SELECT * FROM products;
+----------------+----------------------------+
| name | column_for_new_app_version |
+----------------+----------------------------+
| Laptop | NULL |
| MariaDB Server | 15 |
| T-shirt | NULL |
+----------------+----------------------------+
Документация: https://mariadb.com/kb/en/invisible-columns/
Причина 3: Мгновенное добавление столбцов
Добавление столбцов без блокировки таблицы означает, что вы можете изменять схемы, не вызывая простоев. Функция мгновенного добавления столбцов ADD COLUMN
в MariaDB поддерживает работу вашего приложения при изменении схемы.
Пример:
CREATE OR REPLACE TABLE products (
name VARCHAR(100) PRIMARY KEY
) ENGINE=InnoDB; -- this feature is available in the InnoDB storage engine
INSERT INTO products
VALUES
("T-shirt"),
("Laptop"),
... many, many more, maybe many millions of rows ...
);
SET SESSION alter_algorithm='INSTANT';
ALTER TABLE products -- O(log n) instead of O(n) with n=number of rows
ADD COLUMN notes VARCHAR(500) DEFAULT "N/A";
Документация: https://mariadb.com/kb/en/instant-add-column-for-innodb/
Причина 4: лучшее соответствие ACID
Параметр конфигурации MariaDB innodb_snapshot_isolation обеспечивает лучшее соответствие ACID, например, гарантируя, что неповторяющиеся или немонотонные чтения не допускаются. Он исправляет проблемы, которые все еще могут возникать в MySQL (на момент написания этой статьи), повышая надежность данных. Вот почему я люблю говорить «MariaDB исправляет MySQL».
Пример:
SET GLOBAL innodb_snapshot_isolation=ON;
Документация: https://mariadb.com/kb/en/innodb-system-variables/#innodb_snapshot_isolation
Причина 5: Простые в использовании JSON функции
В то время как другие системы реляционных баз данных увеличивают число JSON функций, MariaDB фокусируется на удобстве использования. Разработчики могут легко манипулировать данными JSON без сложностей, присущих некоторым другим СУБД, что делает MariaDB привлекательным выбором для приложений, использующих JSON.
Пример:
SELECT JSON_UNQUOTE(JSON_EXTRACT('{"name": "Maria"}', '$.name')) as name;
+-------+
| name |
+-------+
| Maria |
+-------+
Документация: https://mariadb.com/kb/en/json-functions/
Вебинар: Лучшие практики гибридной модели данных: JSON + реляционная
Причина 6: Совместимость с Oracle/PostgreSQL/SQL Server
MariaDB обладает высокой совместимостью. Вы можете переносить приложения из Oracle, PostgreSQL или SQL Server, не изменяя весь код приложения, благодаря встроенному режиму совместимости SQL в MariaDB. Эта функция снижает затраты при переходе между базами данных и минимизирует усилия по рефакторингу кода.
Пример:
CREATE TABLE "CUSTOMERS"( -- double quotes
"CUST_ID" NUMBER(8,0), -- double quotes
"CUST_NAME" VARCHAR2(50)); -- Oracle’s VARCHAR2 type
ERROR 1064 (42000): You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near '"CUSTOMERS"(
"CUST_ID" NUMBER(8,0),
"CUST_NAME" VARCHAR2(50))' at line 1
SET SESSION sql_mode="Oracle";
CREATE TABLE "CUSTOMERS"( -- double quotes
"CUST_ID" NUMBER(8,0), -- double quotes
"CUST_NAME" VARCHAR2(50)); -- Oracle’s VARCHAR2 type
Query OK, 0 rows affected (0.365 sec) -- it works now!
Запрос выполнен успешно, затронуто 0 строк (0,365 с) -- теперь работает!
Документация: https://mariadb.com/kb/en/sql-mode/
Видео: Миграция кода приложения в MariaDB с использованием SQL Mode и MaxScale
Причина 7: Высокопроизводительный векторный поиск
Начиная с MariaDB Server 11.6, у вас есть быстрый масштабируемый векторный поиск использующий высокопроизводительный алгоритм Hierarchical Navigable Small World (HNSW), являющийся отраслевым стандартом. Это делает базу данных MariaDB отлично подходящей для приложений ИИ, использующих генерацию дополненного поиска (RAG), которые требуют эффективного и быстрого поиска по большим наборам данных.
Пример:
CREATE OR REPLACE TABLE products (
name varchar(128),
description varchar(2000),
embedding BLOB NOT NULL, -- vector embedding
VECTOR INDEX (embedding) -- vector indexing
);
-- vector search (similarity search)
SELECT name, description FROM products
ORDER BY VEC_DISTANCE(p.embedding, VEC_FromText('[0.3, 0,5, 0.1, 0.3]'))
LIMIT 10
Документация: https://mariadb.com/kb/en/vectors/
Для администраторов баз данных
Давайте теперь рассмотрим некоторые функции MariaDB, которые нравятся администраторам баз данных. Помните, что во многих организациях разработчики берут на себя обязанности администраторов баз данных, поэтому часто эти функции напрямую применяются и к разработчикам приложений.
Причина 8: Быстрое изменение схемы
Мы уже упомянули мгновенные операции ADD COLUMN. Фактически, MariaDB поддерживает быстрое изменение схемы для большинства операций DDL (ALTER TABLE) без блокировки таблиц. Это означает минимальное нарушение работы пользователей и сокращение времени простоя при выполнении задач по обслуживанию базы данных.
Документация: https://mariadb.com/kb/en/innodb-online-ddl-overview/
Причина 9: Одновременные использование различных механизмов хранения
Сервер MariaDB поддерживает несколько механизмов хранения, что позволяет управлять различными типами рабочей нагрузки в рамках одной СУБД. Вы можете оптимизировать различные таблицы для определенных нужд, например, для интенсивного чтения или записи. Более того, вы можете смешивать таблицы, использующие различные механизмы хранения, в одном SQL запросе.
Документация: https://mariadb.com/kb/en/storage-engines/
Вебинар (обязательно к просмотру!): Повышение производительности и масштабируемости с оптимизированными для рабочей нагрузки механизмами хранения
Причина 10: Гибко настраиваемая репликация
MariaDB предлагает надежные функции репликации, включая параллельную полусинхронную репликацию. Для тех, кто ищет еще более строгую согласованность, MariaDB Server интегрируется с Galera для синхронной репликации, обеспечивая гибкость для различных конфигураций высокой доступности.
Документация: https://mariadb.com/kb/en/standard-replication/
Видео: Все, что вы когда-либо хотели знать о репликации MariaDB
Причина 11: прокси-сервер MaxScale
MaxScale, мощный прокси-сервер базы данных MariaDB, упрощает балансировку нагрузки с разделением чтения/записи, автоматическим переключением на резерв и даже поддерживает NoSQL (например, вы можете подключить свои приложения MongoDB к MariaDB). Это, пожалуй, один из самых продвинутых прокси-серверов баз данных, который помогает вам легко реализовать масштабируемость и высокую доступность.
Документация: https://mariadb.com/kb/en/maxscale/
Видео (обязательно к просмотру!): Ускоренный курс по прокси-серверам баз данных
Причина 12: Резервное копирование корпоративного уровня
Встроенные инструменты создания резервных копий корпоративного уровня с возможностями неблокируемого инкрементального копирования позволяют выполнять операции без снижения производительности или остановки. Это важно для организаций, которым нужны операции с нулевым временем простоя и надежные решения для аварийного восстановления.
Документация: https://mariadb.com/kb/en/backing-up-and-restoring-databases/
Причина 13: Плагин аудита
MariaDB Server предлагает плагин аудита из коробки, который может отслеживать и регистрировать активность пользователей базы данных. Для тех, кому нужно еще больше функционала, плагин аудита предприятий расширяет эти возможности в целях безопасности и соответствия требованиям.
Документация: https://mariadb.com/kb/en/mariadb-audit-plugin/
Любим как разработчиками, так и администраторами баз данных:
Причина 14: Лицензия
MariaDB Server лицензирован по GPL, гарантируя, что его исходный код останется открытым и будет доступен для всех. Всегда. Разработчики и администраторы баз данных ценят уверенность в том, что они не заперты в фирменных решениях. GPL также способствует инновациям, позволяя любому вносить свой вклад или изменять базу данных.
Причина 15: Поддержка
Поскольку MariaDB Server выпускается под GPL, его открытый исходный код означает, что вы можете быть уверены, что найдете компанию (например, нас!), которая реализует нужную вам функцию или исправит ошибку, которая, ну, вас раздражает. Исправления включены в официальный код MariaDB Server, что способствует процветанию всего сообщества пользователей по всему миру.
Присоединяйтесь к празднованию!
Вы можете присоединиться к поздравлениям, задать вопросы или написать замечания в соцсетях и сообществах MariaDB.
Комментарии (4)
Heilgecht
03.11.2024 20:24Пришло время искать альтернативу MariaDB так как K1 Investment купил MariaDB. https://mariadb.com/newsroom/press-releases/k1-acquires-a-leading-database-software-company-mariadb-and-appoints-new-ceo/
RodionGork
Ну, возможно основная причина - потому что на шаред-хостингах всегда был mysql и энное количество лет назад с него плавно же хостинги стали перетекать на mariadb. По сравнению с постгресом в те времена mysql/maria казались "человечнее" что ли :) да и выбор не всегда предлагался. Так что типовой кейс - вот у меня сайт на PHP и у него должна быть база - она в 95% случаев наверное оказывалась на mysql и позже maria. А зачем трогать то что работает. Сейчас постгрес завоёвывает мир энтерпрайза уверенно - в том числе по мудрёным кейсам шардирования и проч - но и maria за ним подтягивается по большинству фичей так что своё место под солнцем думаю у неё будет всегда.
Ну правда про лёгкость миграции с постгреса и оракла - это погорячились пожалуй :)
blind_oracle
Постгрес силён, спору нет. Но и там есть спорные архитектурные вещи, которые сложно уже изменить.
Тот же buffer pool в InnoDB работает лучше т.к. находится в процессе, а не отдаётся на откуп файловому кешу ОС. После перезапуска можно с диска загрузить актуальный дамп горячих данных и сразу быстро на запросы отвечать.
Эта же особенность негативно влияла на скорость Постгреса после всяких уязвимостей в процессорах, когда переключение контекста стало неожиданно дорогим т.к. читать из своей памяти в MySQL дёшево, а делать read() с файловой системы (хоть и из кеша) - стало дороже т.к. context switch.
В общем как по мне - если нужна сложная логика в БД и прочая продвинутость, то Постгрес. А если что-то попроще, или хайлоад, то MySQL отдельно или в виде Vitess (https://vitess.io/)