После полутора лет разработки увидел свет первый стабильный выпуск новой ветки СУБД MariaDB 10.0, в рамках которой развивается ответвление от MySQL, сохраняющее обратную совместимость и отличающееся интеграцией дополнительных движков хранения и расширенных возможностей. Развитие MariaDB курирует независимая организация MariaDB Foundation в соответствии с полностью открытым и прозрачным процессом разработки, не зависящим от отдельных вендоров. MariaDB уже поставляется вместо MySQL в таких дистрибутивах, как RHEL 7, Fedora, openSUSE, Slackware и Arch Linux. Состоятельность проекта и способность обеспечить соответствующую корпоративным стандартам техническую поддержку подтверждены миграцией на MariaDB таких крупных проектов, как Wikipedia (http://www.opennet.me/opennews/art.shtml?num=36759), Google Cloud SQL (http://www.opennet.me/opennews/art.shtml?num=37905) и Nimbuzz (http://www.opennet.me/opennews/art.shtml?num=36506).
Выпуск MariaDB 10.0 продолжает развитие кодовой базы MariaDB 5.5 (http://www.opennet.me/opennews/art.shtml?num=33589) и содержит ряд возможностей, бэкпортированных из ветки MySQL 5.6 (http://www.opennet.me/opennews/art.shtml?num=36031). Прошлые ветки MariaDB нумеровались синхронно с ветками MySQL, на которых они были основаны, но начиная с представленного выпуска MariaDB уже не является просто набором патчей, применённых поверх MySQL, а содержит достаточно большой набор дополнительных функций и возможностей, реализованных иначе, чем в MySQL (например, пул тредов, поддержка микросекунд и аннотированные запросы). Изменился также и метод синхронизации с кодовой базой MySQL, отныне первичным в разработке является код MariaDB, в который бэкпортируются новшества MySQL. В связи с этим, чтобы более явно обозначить независимость разработки от MySQL было решено присвоить очередному релизу MariaDB номер 10.Ключевые улучшения MariaDB 10.0:
- Новое хранилище Connect (https://kb.askmonty.org/en/connect/), позволяющее организовать доступ к произвольным локальным или удалённым данным, в виде, как если бы они были сохранены в таблице. Например можно ассоциировать содержимое виртуальной таблицы с данными из файла в определённом формате;- Новое хранилище Cassandra Storage Engine (https://kb.askmonty.org/en/cassandra-storage-engine/) (SE), добавляющее в MariaDB и MySQL поддержку средств для доступа к данным, хранимым в распределённой БД Apache Cassandra (http://www.opennet.me/opennews/art.shtml?num=33676). Используя Cassandra SE разработчики получают возможность обращаться к данным и добавлять данные в БД Cassandra при помощи обычных SQL-запросов. При этом используемая в Cassandra модель хранения данных в виде семейства столбцов (ColumnFamily) отображается в форме свойственных для MariaDB/MySQL таблиц, для которых можно применять стандартные SQL-директивы SELECT, INSERT, DELETE и UPDATE, а также выполнять операции объединения (JOIN) с другими таблицами.
- Интеграция хранилища SPIDER с реализацией системы шардинга, позволяющей разносить большие таблицы на несколько серверов. С точки зрения формирования запросов такие таблицы не отличаются от обычных локальных таблиц, но фактически при использовании SPIDER разные порции данных, составляющих одну таблицу, хранятся на разных серверах. Для обеспечения высокой доступности таблиц, распределённых по серверам при помощи SPIDER, могут применяться новые средства репликации.
- Улучшенная реализация динамических столбцов (https://kb.askmonty.org/en/dynamic-columns/), позволяющих получить различный набор "виртуальных столбцов" для каждой строки в таблице. Добавлена поддержка запросов в формате JSON и возможность интеграции с БД Cassandra;
- Многочисленные оптимизации производительности, позволяющие в MariaDB 10 добиться многократного ускорения некоторых операций по сравнению с MySQL и прошлыми ветками MariaDB. Среди ключевых оптимизаций отмечается поддержка параллельной репликации и развитие системы групповых коммитов.
- Улучшены средства репликации. Обеспечена защита работы реплицируемых slave-серверов от проблем в случае краха. Добавлена поддержка репликации данных от нескольких master-серверов, что может применяется для агрегирования данных из нескольких источников, например, для анализа обобщённого представления данных.
- Поддержка (https://mariadb.atlassian.net/browse/MDEV-26) глобальных идентификаторов транзакций;- Возможность использования проверки IF (NOT) EXIST для выражений ALTER TABLE;
- Дополнительные оптимизации выполнения вложенных запросов, например преобразование выражений "NOT EXISTS" в блоки "IN";
- Хранилище Sequence (https://kb.askmonty.org/en/sequence/) для формирования виртуальных таблиц, заполненных возрастающими или убывающими последовательностями (например, seq_1_to_5 или seq_5_to_1_step_2).
- Улучшенный вывод сообщений об ошибках. Все числовые номера ошибок теперь сопровождаются пояснительными текстами.
- Поддержка выражения "SHOW EXPLAIN FOR thread_id (https://kb.askmonty.org/en/show-explain/)" для анализа запроса, выполняемого в заданной нити. Так как "SHOW EXPLAIN" учитывает план выполнения оптимизатором реального запроса, он позволяет получить более близкие к реальности показатели, чем выполнение запроса внутри "EXPLAIN";
- Поддержка multi-source репликации (https://kb.askmonty.org/en/multi-source-replication/), позволяющей одному серверу реплицировать изменения от нескольких master-серверов. Из примеров использования multi-source репликации упоминается решение задачи сбора в одном месте данных, разнесённых на разные машины, с целью выполнения аналитических запросов или для создания резервной копии;
- В InnoDB добавлены дополнительные оптимизации, позволяющие зметно ускорить выполнения транзакций, не выполняющих операции записи и изменения данных. Для выполнения транзакций в режиме чтения добавлена новая команда "TRANSACTION READ ONLY";
- Оптимизировано выполнение конструкции "LIMIT ... ORDER BY";
- Из MySQL 5.6.5 перенесён обновлённый вариант хранилища InnoDB;
- Из MySQL 5.6.5 портирована поддержка движка PERFORMANCE_SCHEMA (http://dev.mysql.com/doc/refman/5.6/en/performance-schema.html) и связанной с ним базы performance_schema, предоставляющей низкоуровневые средства для мониторинга за выполнением запросов и различными событиями при работе СУБД;
- Из пока не до конца реализованных возможностей, но гарантированно попадающих в финальный релиз, отмечаются: поддержка автоматического обновления времени (timestamp) в DATETIME; хранимые в памяти таблицы с эффективной поддержкой типов VARCHAR и BLOB; новое хранилище Cassandra (http://www.opennet.me/opennews/art.shtml?num=34980); выполнение "ALTER TABLE" на лету.
- Универсальная система накопления статистики (https://kb.askmonty.org/en/engine-independent-table-statistics/) об активности и наполнении таблиц для использования оптимизатором запросов, реализованная без привязки к конкретным движкам хранения;
- Поддержка (https://mariadb.atlassian.net/browse/MDEV-4011) анализа потребления памяти в привязке к отдельной нити;- Значительное ускорение работы конструкций ALTER TABLE для хранилищ Aria и MyISAM при наличии проверки уникальных ключей;
- Переработанная поддержка автоматического назначения и обновления времени для timestamp и datetime.
Ранее реализованные улучшения (http://kb.askmonty.org/v/mariadb-versus-mysql), отличающие MariaDB от MySQL:
- Дополнительные движки хранилищ:
- Aria (http://www.opennet.me/opennews/art.shtml?num=13934) (ранее Maria) - основанное на MyISAM высоконадежное хранилище, отличающееся повышенной устойчивостью и сохранению целостности данных после краха, при полной совместимости с MyISAM. Благодаря ведению лога операций, в случае краха производится откат результатов выполнения текущей операции. Также поддерживается возможность восстановления состояния из любой точки в логе операций (включая поддержку CREATE/DROP/RENAME/TRUNCATE).
...URL: https://blog.mariadb.org/the-mariadb-foundation-announces-ge.../
Новость: http://www.opennet.me/opennews/art.shtml?num=39444
Эй, бородастые-свитерастые!
Можно ей уже пользоваться?
Насколько я понял задумка такова, что я просто меняю MySQL на Maria и больше не совершаю никаких телодвижений -- всё совместимо.
Идея держаться подальше от Оракла мне нравится, но заниматься тестированием БД (я спец по совсем другим делам) я не могу.
Кто-то перелезал с мускула? Нормально? Были танцы с бубном?
Уже год как пользуюсь (параллельно с MySQL). Танцев с бубном в плане переноса и т.п. не видел вообще.
10-я ветка лишилась обратной совместимости, вот так.
Прошу прощения — не лишилась.
Она не будет синхронно с mysql развиваться.
используем у себя в конторе в полный рост, проблем не знаем
5.5 - полет нормальный, 10-ю пока не тестил.
Последний раз когда я щупал мускуль, он не осилил полнотекстовый поиск. Интересно сейчас что-нить поменялось?
<TrollMode>Чем только люди не занимаются, чтобы не ставить постгрес</TrollMode>
Поиск с морфологией приделывается через сфинкс...
Cфинкс это отдельный движок, а я хотел чтоб из коробки все работало. Но таки гугление показало, что можно что-то сделать на MyISAM (https://mariadb.com/kb/en/fulltext-index-overview/).
тестируя запросы на MariaDB , и залив на продакшн где MySQL некоторые из запросов выполнялись неправильно. Проблемы были с датами. Точнее с функциями их сравнения.
после этого сообщение -- начинает складываться ассоциация что MySQL это этакая реинкарнация MSSQL :-)
Неудивительно. Они одноклассники.
С SYBASE не путай.
Ха! Я и не путаю.
>В связи с этим, чтобы более явно обозначить независимость разработки от MySQL было решено присвоить очередному релизу MariaDB номер 10.А поцчему не 459?
Чтобы никто не догадался
>>В связи с этим, чтобы более явно обозначить независимость разработки от MySQL было решено присвоить очередному релизу MariaDB номер 10.
> А поцчему не 459?вероятно "клоны" 5.х будут развиваться параллельно с Oracle My SQL, ну и что-бы потом не пересекались с новыми 6.х 7.х
Вот бы еще где нормальное сравнение с Percona найти...
Подскажите, в MariaDB можно в пределах одной таблицы сделать партиции типа Innodb и Memory?
А вьюху из 2-х таблиц уже не судьба?
1. Партицированная таблица одна, через VIEW их надо создавать вручную, много, да еще и следить за соответствием структур данных и индексов.
2. Партиции создаются автоматически по заданному алгоритму и существенно ускоряют вставку из-за уменьшения объема перестраиваемых индексов. При решении через VIEW для достижения того же эфекта таблицы надо создавать вручную.
3. Партиции я мог бы настроить так, чтобы данные за сутки клались в MEMORY, а все более старые перетекали бы автоматически в InnoDB партициии. Через VIEW всё нужно опять же перекидывать вручную.
4. У VIEW много других ограничений и по моему прямая работа с таблицами даже проще, чем через VIEW
Поэтому VIEW не подходит
> 3. Партиции я мог бы настроить так, чтобы данные за сутки клались
> в MEMORY, а все более старые перетекали бы автоматически в InnoDB
> партициии. Через VIEW всё нужно опять же перекидывать вручную.ИМХО эта не задача базы данных. А сохранность данных в структуре ( таблице ) и восстановление этих данных, в случае непредвиденных обстоятельств, при таком подходе это вообще задача с зашкаливающим количеством неизвестных, при этом таблица будет восприниматься сторонним человеком которому досталась поддержка/доработка как абсолютно обычная.
Построение мегакомбайнов не единственный популярный подход в разработке, хотя некоторые всем известные вендоры идут именно этим путём, а потом костыли не самых удачных, из принятых, решений вынуждены поддерживать годами.
Бред.Зыж
Что значит вручную?
Для этого и придумали хранимые процедуры, триггеры (включая инстид оф),... и такое понятие как "АПИ доступа к данным".
Это всё костыли. База должна уметь гибко подстраиваться под данные, которые в ней требуется хранить.
База данных должна хранить данные.
Вот и храни. В 2-х таблицах.
Зыж
Это ещё про материализованные вьюхи не говорил.Ззыж
Но для неофитов придумывать костыли — самое то.
Потом же костыльно и отлаживать.
Это уже давно не так. Современная база должна не только хранить данные, но и управлять ими. Чем гибче управление - тем лучше
> Это всё костыли. База должна уметь гибко подстраиваться под данные, которые в
> ней требуется хранить.Интересное мнение :)
Пару интересных патчей
- http://mysql.taobao.org/index.php/Patch_source_code#Optimiza...
- http://mysql.taobao.org/index.php/Patch_source_code#Correct_...
- http://mysql.taobao.org/index.php/Patch_source_code#Report_p...
- http://mysql.taobao.org/index.php/Patch_source_code#Optimiza...
А про докручивание до ума обновления и вставки данных в триггерах уровня таблицы изменяющих данные в той же таблице так и не слышно :(
>Выпуск MariaDB 10.0 продолжает развитие кодовой базы MariaDB 5.5
>10.0
>5.5Это такая тонкая первоапрельская шутка, да? Да?
31-ая мартовская"31.03.2014 17:21 Стабильный выпуск СУБД MariaDB 10.0 "