The OpenNET Project / Index page

[ новости /+++ | форум | wiki | теги | ]

Wikimedia планирует мигрировать с MySQL на MariaDB

04.02.2013 00:06

Сотрудники Wikimedia продолжили эксперименты с использованием MariaDB и перевели один из рабочих slave-серверов, обслуживающих англоязычную часть Wikipedia, на СУБД MariaDB, в рамках которой независимым сообществом развивается совместимое на уровне API и ABI ответвление от MySQL. В будущем ожидается плавный перевод на MariaDB и остальных серверов инфраструктуры.

Предварительная оценка внедрения MariaDB 5.5 показала увеличение производительности в среднем на 8% (некоторые запросы выполняются на 10-15% быстрее, но некоторые замедлились на 3%), по сравнению с ранее используемой конфигурацией на базе MySQL 5.1. Общая способность обработки запросов после задействования MariaDB возросла на 2-10%. При этом отмечается, что основной целью миграции является не производительность, а полностью открытый процесс разработки MariaDB, не зависящий от отдельных вендоров.

Отдельно можно напомнить о решении разработчиков дистрибутивов Fedora и openSUSE об использовании MariaDB в качестве предлагаемой по умолчанию реализации MySQL, начиная с Fedora 19 и openSUSE 12.3. Поддержка MySQL будет сохранена и пользователи смогут установить данную СУБД из штатных репозиториев, но все зависимости для требующих MySQL сторонних пакетов будут теперь связаны с MariaDB. В прошлых выпусках Fedora и openSUSE СУБД MariaDB предлагалась в качестве опции. Что касается Ubuntu, то в данном дистрибутиве пакеты с MariaDB пока отсутствуют в стандартном репозитории, для их установки необходимо подключение сторонних PPA. Последний стабильный выпуск MariaDB 5.5 основан на кодовой базе MySQL 5.5 и полностью совместим с данной СУБД. Для тестирования также доступна ветка MariaDB 10, в которой выполняется работа по бэкпортированию изменений из экспериментальной ветки MySQL 5.6.

  1. Главная ссылка к новости (http://lists.wikimedia.org/pip...)
  2. OpenNews: Обновление MariaDB 5.5.29, 5.3.12, 5.2.14 и 5.1.67 с устранением уязвимостей
  3. OpenNews: В Fedora 19 одобрена замена MySQL на MariaDB и поддержка CRIU, но не принят переход на Btrfs
  4. OpenNews: Разработчики дистрибутива Fedora рассматривают возможность замены MySQL на MariaDB
  5. OpenNews: Основатели MySQL учредили организацию MariaDB Foundation, которая будет развивать и продвигать альтернативу MySQL
  6. OpenNews: Увидела свет СУБД MariaDB 10.0.0
Автор новости: CSRedRat
Тип: К сведению
Короткая ссылка: https://opennet.ru/36014-mariadb
Ключевые слова: mariadb, mysql
При перепечатке указание ссылки на opennet.ru обязательно
Обсуждение (34) Ajax | 1 уровень | Линейный | +/- | Раскрыть всё | RSS
  • 1.1, Аноним (-), 10:50, 04/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    Почему не на Drizzle?
     
     
  • 2.23, Аноним (-), 20:59, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Жосткие архитектурные особенности
     

  • 1.3, Аноним (-), 11:15, 04/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +13 +/
    Я так понял MySQL скоро переползет на могильник Apache, чтобы OO скучно не было.
    Не дай Боже этот финт повторится с VirtualBox...
     
     
  • 2.5, clown (?), 12:15, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • –21 +/
    OO куда живее, чем LO. А теперь, когда LO-шные клоуны своими руками похерили совместимость, воровать из OO решения, выдавая их за свои результаты, им будет гораздо сложнее.
     
     
  • 3.7, Аноним (-), 12:18, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > своими руками похерили совместимость

    Совместимость чего с чем?

    > воровать из OO решения

    Это проблемы выбранной ими лицензии.

     
  • 3.8, anonymous (??), 12:23, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    А разве из OO уже есть что воровать?
     
  • 3.9, fi (ok), 12:29, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    > похерили совместимость

    ага, костели выкинули :))))

    последний 3.6 совсем супер - летает, удобен.

     
  • 3.16, Xasd (ok), 13:52, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +1 +/
    > воровать из OO решения

    это именно то самое деяние -- которым займутся проприетарщики, выпуская свой очередной
    SuperMegaOffice Professionsl Edition 12.1 XT (cracked by 666xakerVasya666)

    :-)

    а вот LibreOffice -- это просто не надо. незачем потому что

     
  • 3.25, Аноним (-), 22:06, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > OO куда живее, чем LO.

    Не заметно. У меня LO работает и каши не просит, в общем.

    > А теперь, когда LO-шные клоуны

    Лошный клоун - это вы про себя?

     
  • 2.24, Аноним (-), 22:04, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Я так понял MySQL скоро переползет на могильник Apache

    У нее лицензия неправильная. Вот оракль и апачисты будут делить на 0 :)

    > Не дай Боже этот финт повторится с VirtualBox...

    А у нас KVM есть, нам пофигу.

     
  • 2.29, Java coder (?), 02:38, 05/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    "Последний стабильный выпуск MariaDB 5.5 основан на кодовой базе MySQL 5.5 ... доступна ветка MariaDB 10, в которой выполняется работа по бэкпортированию изменений из экспериментальной ветки MySQL 5.6 ..."
    Если он отправится на могильник, то откуда разработчики MariaDB будут бэкпортировать (слово то какое для простого слизывания кода) фичи?
     

  • 1.4, Аноним (-), 11:24, 04/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    Вот и плати после этого всяким товарищам гигабакс за Open Source.
     
     
  • 2.10, myhand (ok), 12:30, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Ты таки хочешь сказать, что авторы MySQL в чем-то нарушили закон?  Условия лицензии?  Права на торговую марку?

    Если бы MySQL продолжали развивать те загребущие руки, что его купили - он бы успешно конкурировал с форком.

     
     
  • 3.12, Аноним (-), 13:20, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Хочу сказать, что это не выгодно (покупать), вот и все.
     
     
  • 4.14, Аноним (-), 13:27, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Хочу сказать, что это не выгодно (покупать), вот и все.

    Почему вы так решили?

     
  • 4.17, myhand (ok), 14:03, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +2 +/
    > Хочу сказать, что это не выгодно (покупать), вот и все.

    И сказал ты глупость.

    Программный продукт, связанная с ним инфраструктура - не штабель кирпичей, к примеру.  Кирпичи купил - и можешь на них радостно сидеть-свистеть.  Захотел - сам дом из них построил.  Захотел - продал через месяц/год/десять...

    А программа, которую ты купил и на дальнейшее развитие которой забил - будет просто терять пользователей.  И виноват в этом вовсе не Open Source, а только такой дурак как ты...

     
  • 4.19, Аноним (-), 17:49, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Я не являюсь фанатом mysql, но объективности ради - это весьма востребованная система, и производитель на ней очень хорошо зарабатывал, так что Вы ошибаетесь. Проблема не в Open Source, а в дурном руководстве oracle. У sun этот самый mysql рос и плодоносил.
     
     
  • 5.21, myhand (ok), 20:49, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > а в дурном руководстве oracle

    Право, ничего дурного тут особо не видно.  Oracle оно с самого начала нафиг нужно не было.  Sun преобретался вовсе не из-за mysql, совсем нет.

    Зачем развивать пускалку для собственной БД - понятно.  А зачем развивать потенциальный конкурент этой БД?

     
     
  • 6.35, A. (?), 13:52, 05/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Мне показалосьб, что MySQL в Oracle закрывал нишу простых и дешовых SQL баз (не путать с простейшими).
     

  • 1.6, Аноним (-), 12:16, 04/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +7 +/
    Тоже мне мигранты.
    Вот если бы они решили на PostgreSQL переехать - то была бы миграция.
     
     
  • 2.11, rshadow (ok), 13:03, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +4 +/
    На постгрис это ппц. Вообщем SQL у них похожий, но в мелочах настолько разный что хоть заново пиши...
     
     
  • 3.13, тфьу (?), 13:22, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Вообщем SQL у них похожий, но в мелочах настолько разный что хоть заново пиши...

    ANSI SQL, иначе сам виноват.

     
     
  • 4.15, Аноним (-), 13:30, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    >> Вообщем SQL у них похожий, но в мелочах настолько разный что хоть заново пиши...
    > ANSI SQL, иначе сам виноват.

    ANSI SQL не стандартизирует индексы и такие критические вещи для web как блокировки.

     
  • 4.20, Sinot (ok), 18:16, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Это если пишешь систему подразумевающий выбор БД для использования. (Блог какой-нибудь)
    А если такой надобности нет, почему бы не использовать фичи конкретной БД?

    Аналогично писать проект Linux only и не использовать возможности доступные только для него.

     
     
  • 5.22, myhand (ok), 20:52, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > А если такой надобности нет, почему бы не использовать фичи конкретной БД?

    Потому, например, что "надобность" может возникнуть в будущем.


     
     
  • 6.27, Sinot (ok), 22:39, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Я понимаю, такие решения не могут быть универсальны для всех случаев. И каждый проект решает для себя сам что и как использовать. В том числе с перспективой на будущее.
    Но ё мае, новые фичи вообще нельзя использовать что ли?
     
     
  • 7.28, myhand (ok), 22:44, 04/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Все можно, если осторожно.
     
  • 6.30, Crazy Alex (ok), 02:46, 05/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    На практике - почти во всех случаях дешевле затачивать под конкретную базу. Если условия меняются так, что выбранная база не справляется, то затраты на адаптацию под что-то другое - мелочь в море других затрат. Собственно, если есть хоть какая-то внятная архитектура, то SQL довольно локализован. А если спагетти - то его рефакторинг с вероятностью даст эдак на порядок больше, чем переход на постгрес или ещё куда. Хотя в случае веба дешевле клепать костыли до последнего, тупо обкладываясь кэшами и кластерами.
     
     
  • 7.33, VoDA (ok), 11:06, 05/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Хотя в случае веба дешевле клепать костыли до последнего, тупо обкладываясь кэшами и кластерами.

    И не в вебе тоже ;)

    По сути каждый раз есть выбор или вложить много и сделать качественное изменение кода или вложить мало и костылями решить локальные проблемы.

    Вкладывать каждый раз по много и делать качественный рефакторинг получается слишком дорого на круг. А если постоянно экономить и костылить, то код очень быстро превратиться в лапшу, которую только выкинуть остается.

    ИМХО золотая середина где то между этими подходами - раз в пол-года-год делается качественный рефакторинг, остальное время решаются локальные косяки.

     

  • 1.18, VoDA (ok), 15:45, 04/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +1 +/
    Минорное изменение.

    Вот если бы они мигрировали инфраструктуру на единую распределенную СУБД типа ColumnFamily - вот это было бы и интереснее и полезнее. Особенно для распределенных проектов.

     
     
  • 2.31, Crazy Alex (ok), 02:48, 05/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    Видите ли, они заинтересованы прежде всего в результате - то есть живых и работающих веб-сайтах.

    Проекты такого уровня даже постгрес переводить - заявка на суицид, что там говорить об экзотике...

     
     
  • 3.34, VoDA (ok), 11:10, 05/02/2013 [^] [^^] [^^^] [ответить]  
  • +/
    > Видите ли, они заинтересованы прежде всего в результате - то есть живых
    > и работающих веб-сайтах.

    Согласен - проще заменить на аналог, тем более совместимый по API, чем на другую систему хранения.

    > Проекты такого уровня даже постгрес переводить - заявка на суицид, что там
    > говорить об экзотике...

    Это в краткосрочном периоде, а в долгосрочном наоборот. Сейчас у них система накостылена в виде несколько мастеров, куча слейвов, на мастера запись, со слейвов чтение. Различные разделы лежать в разных базах, на разных серверах. К этому зоопарку, конечно, привыкли, но админить его нужно. Переход на единую распределенную СУБД позволить сэкономить время админов. Плюс появятся новые возможности - тот же бэкап будет идти по всем данным википедии, а не только тому, что упало на конкретный слейв.

     

  • 1.26, lavros (?), 22:24, 04/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • –1 +/
    хм, а почему никто Percon'у не рассматривает?
     
  • 1.32, Аноним (-), 03:27, 05/02/2013 [ответить] [﹢﹢﹢] [ · · · ]  
  • +/
    полностью открытый процесс разработки не зависящий от отдельных вендоров
     

     Добавить комментарий
    Имя:
    E-Mail:
    Текст:



    Спонсоры:
    Inferno Solutions
    Hosting by Hoster.ru
    Хостинг:

    Закладки на сайте
    Проследить за страницей
    Created 1996-2020 by Maxim Chirkov
    Добавить, Поддержать, Вебмастеру