Сотрудники Wikimedia продолжили эксперименты с использованием MariaDB и перевели (http://lists.wikimedia.org/pipermail/wikitech-l/2012-Decembe...) один из рабочих slave-серверов, обслуживающих англоязычную часть Wikipedia, на СУБД MariaDB, в рамках которой независимым сообществом развивается (https://www.opennet.ru/opennews/art.shtml?num=35316) совместимое на уровне API и ABI ответвление от MySQL. В будущем ожидается плавный перевод на MariaDB и остальных серверов инфраструктуры.
Предварительная оценка внедрения MariaDB 5.5 показала увеличение производительности в среднем на 8% (некоторые запросы выполняются на 10-15% быстрее, но некоторые замедлились на 3%), по сравнению с ранее используемой конфигурацией на базе MySQL 5.1. Общая способность обработки запросов после задействования MariaDB возросла на 2-10%. При этом отмечается, что основной целью миграции является не производительность, а полностью открытый (https://www.opennet.ru/opennews/art.shtml?num=35503) процесс разработки MariaDB, не зависящий от отдельных вендоров.
Отдельно можно напомнить о решении (https://www.opennet.ru/opennews/art.shtml?num=35982) разработчиков дистрибутивов Fedora и openSUSE об использовании MariaDB в качестве предлагаемой по умолчанию реализации MySQL, начиная с Fedora 19 и openSUSE 12.3. Поддержка MySQL будет сохранена и пользователи смогут установить данную СУБД из штатных репозиториев, но все зависимости для требующих MySQL сторонних пакетов будут теперь связаны с MariaDB. В прошлых выпусках Fedora и openSUSE СУБД MariaDB предлагалась в качестве опции.
Что касается Ubuntu, то в данном дистрибутиве пакеты с MariaDB пока отсутствуют в стандартном репозитории, для их установки необходимо подключение сторонних PPA. Последний стабильный выпуск MariaDB 5.5 основан на кодовой базе MySQL 5.5 (https://www.opennet.ru/opennews/art.shtml?num=33589) и полностью совместим с данной СУБД. Для тестирования также доступна ветка MariaDB 10 (https://www.opennet.ru/opennews/art.shtml?num=35316), в которой выполняется работа по бэкпортированию изменений из экспериментальной ветки MySQL 5.6 (https://www.opennet.ru/opennews/art.shtml?num=31291).
URL: http://lists.wikimedia.org/pipermail/wikitech-l/2012-Decembe...
Новость: https://www.opennet.ru/opennews/art.shtml?num=36014
Почему не на Drizzle?
Жосткие архитектурные особенности
Я так понял MySQL скоро переползет на могильник Apache, чтобы OO скучно не было.
Не дай Боже этот финт повторится с VirtualBox...
OO куда живее, чем LO. А теперь, когда LO-шные клоуны своими руками похерили совместимость, воровать из OO решения, выдавая их за свои результаты, им будет гораздо сложнее.
> своими руками похерили совместимостьСовместимость чего с чем?
> воровать из OO решения
Это проблемы выбранной ими лицензии.
А разве из OO уже есть что воровать?
> похерили совместимостьага, костели выкинули :))))
последний 3.6 совсем супер - летает, удобен.
> воровать из OO решенияэто именно то самое деяние -- которым займутся проприетарщики, выпуская свой очередной
SuperMegaOffice Professionsl Edition 12.1 XT (cracked by 666xakerVasya666):-)
а вот LibreOffice -- это просто не надо. незачем потому что
> OO куда живее, чем LO.Не заметно. У меня LO работает и каши не просит, в общем.
> А теперь, когда LO-шные клоуны
Лошный клоун - это вы про себя?
> Я так понял MySQL скоро переползет на могильник ApacheУ нее лицензия неправильная. Вот оракль и апачисты будут делить на 0 :)
> Не дай Боже этот финт повторится с VirtualBox...
А у нас KVM есть, нам пофигу.
"Последний стабильный выпуск MariaDB 5.5 основан на кодовой базе MySQL 5.5 ... доступна ветка MariaDB 10, в которой выполняется работа по бэкпортированию изменений из экспериментальной ветки MySQL 5.6 ..."
Если он отправится на могильник, то откуда разработчики MariaDB будут бэкпортировать (слово то какое для простого слизывания кода) фичи?
Вот и плати после этого всяким товарищам гигабакс за Open Source.
Ты таки хочешь сказать, что авторы MySQL в чем-то нарушили закон? Условия лицензии? Права на торговую марку?Если бы MySQL продолжали развивать те загребущие руки, что его купили - он бы успешно конкурировал с форком.
Хочу сказать, что это не выгодно (покупать), вот и все.
> Хочу сказать, что это не выгодно (покупать), вот и все.Почему вы так решили?
> Хочу сказать, что это не выгодно (покупать), вот и все.И сказал ты глупость.
Программный продукт, связанная с ним инфраструктура - не штабель кирпичей, к примеру. Кирпичи купил - и можешь на них радостно сидеть-свистеть. Захотел - сам дом из них построил. Захотел - продал через месяц/год/десять...
А программа, которую ты купил и на дальнейшее развитие которой забил - будет просто терять пользователей. И виноват в этом вовсе не Open Source, а только такой дурак как ты...
Я не являюсь фанатом mysql, но объективности ради - это весьма востребованная система, и производитель на ней очень хорошо зарабатывал, так что Вы ошибаетесь. Проблема не в Open Source, а в дурном руководстве oracle. У sun этот самый mysql рос и плодоносил.
> а в дурном руководстве oracleПраво, ничего дурного тут особо не видно. Oracle оно с самого начала нафиг нужно не было. Sun преобретался вовсе не из-за mysql, совсем нет.
Зачем развивать пускалку для собственной БД - понятно. А зачем развивать потенциальный конкурент этой БД?
Мне показалосьб, что MySQL в Oracle закрывал нишу простых и дешовых SQL баз (не путать с простейшими).
Тоже мне мигранты.
Вот если бы они решили на PostgreSQL переехать - то была бы миграция.
На постгрис это ппц. Вообщем SQL у них похожий, но в мелочах настолько разный что хоть заново пиши...
> Вообщем SQL у них похожий, но в мелочах настолько разный что хоть заново пиши...ANSI SQL, иначе сам виноват.
>> Вообщем SQL у них похожий, но в мелочах настолько разный что хоть заново пиши...
> ANSI SQL, иначе сам виноват.ANSI SQL не стандартизирует индексы и такие критические вещи для web как блокировки.
Это если пишешь систему подразумевающий выбор БД для использования. (Блог какой-нибудь)
А если такой надобности нет, почему бы не использовать фичи конкретной БД?Аналогично писать проект Linux only и не использовать возможности доступные только для него.
> А если такой надобности нет, почему бы не использовать фичи конкретной БД?Потому, например, что "надобность" может возникнуть в будущем.
Я понимаю, такие решения не могут быть универсальны для всех случаев. И каждый проект решает для себя сам что и как использовать. В том числе с перспективой на будущее.
Но ё мае, новые фичи вообще нельзя использовать что ли?
Все можно, если осторожно.
На практике - почти во всех случаях дешевле затачивать под конкретную базу. Если условия меняются так, что выбранная база не справляется, то затраты на адаптацию под что-то другое - мелочь в море других затрат. Собственно, если есть хоть какая-то внятная архитектура, то SQL довольно локализован. А если спагетти - то его рефакторинг с вероятностью даст эдак на порядок больше, чем переход на постгрес или ещё куда. Хотя в случае веба дешевле клепать костыли до последнего, тупо обкладываясь кэшами и кластерами.
> Хотя в случае веба дешевле клепать костыли до последнего, тупо обкладываясь кэшами и кластерами.И не в вебе тоже ;)
По сути каждый раз есть выбор или вложить много и сделать качественное изменение кода или вложить мало и костылями решить локальные проблемы.
Вкладывать каждый раз по много и делать качественный рефакторинг получается слишком дорого на круг. А если постоянно экономить и костылить, то код очень быстро превратиться в лапшу, которую только выкинуть остается.
ИМХО золотая середина где то между этими подходами - раз в пол-года-год делается качественный рефакторинг, остальное время решаются локальные косяки.
Минорное изменение.Вот если бы они мигрировали инфраструктуру на единую распределенную СУБД типа ColumnFamily - вот это было бы и интереснее и полезнее. Особенно для распределенных проектов.
Видите ли, они заинтересованы прежде всего в результате - то есть живых и работающих веб-сайтах.Проекты такого уровня даже постгрес переводить - заявка на суицид, что там говорить об экзотике...
> Видите ли, они заинтересованы прежде всего в результате - то есть живых
> и работающих веб-сайтах.Согласен - проще заменить на аналог, тем более совместимый по API, чем на другую систему хранения.
> Проекты такого уровня даже постгрес переводить - заявка на суицид, что там
> говорить об экзотике...Это в краткосрочном периоде, а в долгосрочном наоборот. Сейчас у них система накостылена в виде несколько мастеров, куча слейвов, на мастера запись, со слейвов чтение. Различные разделы лежать в разных базах, на разных серверах. К этому зоопарку, конечно, привыкли, но админить его нужно. Переход на единую распределенную СУБД позволить сэкономить время админов. Плюс появятся новые возможности - тот же бэкап будет идти по всем данным википедии, а не только тому, что упало на конкретный слейв.
хм, а почему никто Percon'у не рассматривает?
полностью открытый процесс разработки не зависящий от отдельных вендоров