Представлен (http://blog.mariadb.org/announcing-mariadb-10-0-0-alpha/) первый выпуск новой значительной ветки СУБД MariaDB 10.0.0 (https://kb.askmonty.org/en/mariadb-1000-release-notes/), продолжающий развитие кодовой базы MariaDB 5.5 (http://www.opennet.me/opennews/art.shtml?num=33589) и содержащий ряд возможностей, бэкпортированных из ветки MySQL 5.6 (http://www.opennet.me/opennews/art.shtml?num=31291). Проект развивается компанией Monty Program Ab, созданной Майклом Видениусом, основателем MySQL, после его ухода из Sun Microsystems. БД MariaDB полностью совместима с MySQL и может выступать в качестве прозрачной замены MySQL, дополненной рядом расширенных функций (http://www.opennet.me/opennews/art.shtml?num=33589), оптимизациями производительности, новыми движками хранилищ (FederatedX, PBXT, XtraDB, Aria, OQGRAPH, Sphinx) и улучшениями от сообщества независимых разработчиков. Как и MySQL 5.6 ветка MariaDB 10.x пока имеет экспериментальный характер и не вышла за рамки альфа-стадии разработки, не рекомендованной для промышленного применения.
Ранее ветки MariaDB нумеровались синхронно с ветками MySQL, на которых они были основаны. Но в настоящее время MariaDB уже не является просто набором патчей, применённых поверх MySQL, а содержит достаточно большой набор дополнительных функций и возможностей, реализованных иначе, чем в MySQL (например, пул тредов, поддержка микросекунд и аннотированные запросы). Изменился также и метод синхронизации с кодовой базой MySQL, в настоящее время первичным в разработке является код MariaDB, в который бэкпортируются новшества MySQL. В связи с этим, чтобы более явно обозначить независимость разработки от MySQL решено присвоить очередному релизу MariaDB номер 10.Среди новшеств MariaDB (https://kb.askmonty.org/en/what-is-mariadb-100/) 10.0.0:
- Улучшенный вывод сообщений об ошибках. Все числовые номера ошибок теперь сопровождаются пояснительными текстами.
- Поддержка выражения "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" на лету.URL: http://blog.mariadb.org/announcing-mariadb-10-0-0-alpha/
Новость: http://www.opennet.me/opennews/art.shtml?num=35316
> содержащий ряд возможностей, бэкпортированных из ветки MySQL 5.6.Если редхат в пику ораклу создаст репу, в которой изменения мускула разобраны по патчам и с комментариями, развитие форков мускула пойдет гораздо быстрее :)
да, только это гогно особо то и не нужно. Причём в первую очередь не нужно даже самому ораклу.
Миллионы леммингов не могут ошибаться.
Я думаю на сегодняшний день MySQL самая распространенная СУБД, а то что лично у вас она вызывает идиосинкразию в общем то ваши проблемы.
>MySQL самая распространенная СУБДНеверно. Самая распространенная СУБД - sqlite. Каждый день установочная база увеличивается на 1 200 000 экземпляров. А всего используется более 1 500 000 000 инстансов.
> Самая распространенная СУБД - sqlite.Неверно.
> Каждый день установочная база увеличивается на 1 200 000 экземпляров. А всего используется более 1 500 000 000 инстансов.
А у MySQL каждый день установочная база увеличивается на 1 200 000 000 000 000 экземпляров. И всего используется более 1 500 000 000 000 000 000 инстансов.
man sqlite
man android
man ios
man chrome
> man sqlite
> man android
> man ios
> man chromeNo manual entry for sqlite
No manual entry for android
No manual entry for ios
No manual entry for chrome
Это не его вина. Libsqlite есть в практически каждой системе, десктопной и не очень.Example: файрфокс хранит в скулайтовых базах кучу всякого добра типа букмарков, истории и тому подобного. А скулайт очень удобен: база данных необслуживаема + сама либа весит всего около 300 кило со всеми ништяками. За что и пользуется популярностью.
>1 500 000 000 000 000 000 инстансов.Что вы, что вы, Амарок не настолько популярен.
>>1 500 000 000 000 000 000 инстансов.
> Что вы, что вы, Амарок не настолько популярен.Зато я умею писать но-о-олики-и-и!
>>1 500 000 000 000 000 000 инстансов.
> Что вы, что вы, Амарок не настолько популярен.Кто знает, кто знает ;)
> Кто знает, кто знает ;)Думаете, обитатели соседних галактик на него подсели? :)
конечно, не могут. Ошибиться ведь можно только делая осознанный выбор. А бессознательное животное лишено такой возможности.
> А бессознательное животное лишено такой возможности.Вы хотите, чтобы вас пожалели?
> да, только это гогно особо то и не нужно.Это ваши личные половые трудности. А людям - нужно.
> Это ваши личные половые трудности. А людям - нужно.Для таких сказочных персонажей других людей не существует. И других мнений, окромя собственного.
Корпоративные клиенты с радостью свалят на Percona Server
> Корпоративные клиенты с радостью свалят на Percona ServerЧто-то не видно бурных потоков валящих корпоративных клиентов.
> да, только это гогно особо то и не нужно. Причём в первую очередь не нужно даже самому ораклу.То-то оракл вбухал кучу бабла в покупку сана. Разумеется, не нужно. Просто бабло хотели потратить. Бизнесмены, они такие.
хватит так безжалостно тупить. Ораклу от SUNа было нужно а)железо и б) SunOS для своих продуктов и в какой-то степени ява была нужна. Т.е. купил традиционных компаньёнов, которые и так большая часть кастомеров покупает, например, к их же рСУБД. Раньше такие полные решения были только у IBM.[сообщение отредактировано модератором]
полный бред.
ораклу почти не нужно было железо, ещё меньше solaris (какой ещё SunOS?), нужен был мускуль и ОЧЕНЬ нужна была жаба.
более того, только из-за жабы санки и купили бы.[сообщение отредактировано модератором]
> хватит так безжалостно тупить. Ораклу от SUNа было нужно а)железо и б)
> SunOS для своих продуктов и в какой-то степени ява была нужна.Поэтому они
1) Практически похоронили железное направление.
2) Закрыли солярис и спускают его на тормозах.
3) Обломались с патентным троллингом гугля :)
> Поэтому они
> 2) Закрыли солярис и спускают его на тормозах.Спускают на тормозах Солярис? Вы в какой вселенной живете?
> Причём в первую очередь не нужно даже самому ораклу.Ясен пень, оракл не идиот - сам себе конкуренцию повышать. Ибо чем больше купит их базу и чем меньше проскочит нахаляву с мускулем тем они богаче :)
> Ясен пень, оракл не идиотВ отличие от вас.
> сам себе конкуренцию повышать. Ибо чем больше купит их базу и чем меньше проскочит нахаляву с мускулем тем они богаче :)
Иначе вы бы догадались, что мускул вовсе не конкурент оракловской базе.
А разве Drizzle не есть более правильное развитие MySQL?
Не троллинга ради, действительно интересно какие приемущества MariaDB или недостатки Drizzle видят люди, использующие форки MySQL в продакшене.
полная несовместимость с mysql и переписывание 60% кода sql
One
А почему версия не 20 или 30? М.б. 100 было бы лучше?
> А почему версия не 20 или 30? М.б. 100 было бы лучше?Какой вы придирчивый, сударь.
надо же как-то о себе заявить. Никто же не пользуется, а денежки которые sun отвалил уже заканчиваются...
а тут еще MySQL TM не отдал Oracle... одни печали..
во-первых, только альфа версия, релиз будет не ранее чем через 3 мес - полгода,
хотя схема нумерации версий у них такая что .0 считается альфой .1 и .2 бетой, а .3 - GAво-вторых, жаль что и они теперь погнались за циферками в номере версии...
Не погнались. Они же [объясняют](http://blog.mariadb.org/explanation-on-mariadb-10-0/), что мускуль релизится слишком долго, и за это время они успевают наколбасить столько фич, что их уже нельзя впихнуть в ту циферку, которая на основе соответствующей циферки мускуля. По этому они делают отдельную ветку для своих хаков, в которую будут портировать фичи из мускуля. Версии на основе мускуля с соответствующими циферками продолжат выпускаться.
Так что вполне логичный шаг. Новая ветка нужна, чтобы версии не пересекались с версиями, эквивалентными мускулю. Десятка взята просто как цифра, до которой оракл доползет только через пару столетий.
"слишком долго"
хм...
как по мне - мимоходные(беглые) натурные наблюдения другие - выходит майsql(1), выходит майsql(2), выходит перкона с изменениями от майsql(1), а еще примерно через месяц /или более/ выходит мария с позапрошлой перконой.и, что до "полностью совместима с MySQL" из новости. Кажется это очень сильное преувеличение. Хотябы даже из-за того, что энжины подменяются. А еще есть и просто несовместимости, к примеру разные результаты у CHECKSUM TABLE в марии и майsql.