Comments 85
Звучит заманчиво. Кто-нибудь тестил все это дело под серьезной нагрузкой? Насколько готово к продакшену? Особенно интересует XtraDB.
Очевидно, Гугль тестил. Точнее гуглопатчи туда входят. Куда уж серьёзней нагрузки?
Мы же не знаем для чего оно используется в Гугле…
Некоторая информация есть тут:
http://www.mysql.com/customers/view/?id=555
http://www.mysql.com/customers/view/?id=555
Мои коллеги используют перкона сервер на рекламной бирже с 4000 ежесекундных запросах к БД, притом многие из них достаточно тяжеловесны. У перкона сервера есть платный саппорт — пока ни разу не обращались (2 недели), миграцию пережили без существенных артефактов поведения.
Вполне готово. Везде где используется MySQL+InnoDB его можно смело заменять на Percona Server. Цитирую из документации «High-profile users include 37signals, New Relic, and Scribd to name just a few. „
Серьёзная проблема что этих форков нет в официальных репозитариях.
Многие бы заменили себе MySQL на один из форков если бы им не пришлось возиться с самостоятельной компиляцией.
Многие бы заменили себе MySQL на один из форков если бы им не пришлось возиться с самостоятельной компиляцией.
появятся, дайте время.
ну и rpmbuild/dpkg -b никто не отменял.
ну и rpmbuild/dpkg -b никто не отменял.
rpmbuild/dpkg -b — это не выход. За обновлениями необходимо следить самостоятельно. Плюс проблемы с безопасностью — ведь бэкпортированием секьюритификсов из новых версий в старые (если минорное обновление не допустимо) придется заниматься опять же самому. В общем это не для продакшена.
я имел в виду, что это лучше, чем на пакетном дистре делать ./configure>make>make install
Вполне себе для продакшена, если у вас тысячи однотипных серверов, создаем свой локальный репозиторий, следим за апдейтами. Ничего сложного. Когда нависает highload, то лучше так, чем упираться рогом в «нету в офф. репах, как же мы будем жить?»
Вполне себе для продакшена, если у вас тысячи однотипных серверов, создаем свой локальный репозиторий, следим за апдейтами. Ничего сложного. Когда нависает highload, то лучше так, чем упираться рогом в «нету в офф. репах, как же мы будем жить?»
хотите, чтобы за вас грязную работу сделали?
станьте мейнтейнером…
станьте мейнтейнером…
Не знаю, как у MariaDB, но у Percona server есть свои репозитории для Yum и Apt — руками собирать не придется
Gentoo style:
Уже довольно давно :)
.deb и rmp у них на офф сайте давно можно взять.
echo dev-db/mysql xtradb >> /etc/portage/package.use
emerge mysql
Уже довольно давно :)
.deb и rmp у них на офф сайте давно можно взять.
erelesse@ergil-laptop ~ $ eix maria
* dev-db/mariadb
Available versions: (~)5.1.42 (~)5.1.42-r1 (~)5.1.50 {big-tables cluster +community debug embedded extraengine latin1 libevent max-idx-128 minimal pbxt +perl profiling selinux ssl static test}
Homepage: askmonty.org/
Description: MariaDB is a MySQL fork with 3rd-party patches and additional storage engines merged.
Ой?
* dev-db/mariadb
Available versions: (~)5.1.42 (~)5.1.42-r1 (~)5.1.50 {big-tables cluster +community debug embedded extraengine latin1 libevent max-idx-128 minimal pbxt +perl profiling selinux ssl static test}
Homepage: askmonty.org/
Description: MariaDB is a MySQL fork with 3rd-party patches and additional storage engines merged.
Ой?
У Percona свои репозитарии. Подключайте и пользуйтесь на здоровье.
Использую MariaDB вместо mysql.
Кстати, в теме не указан движок XtraDB
Кстати, в теме не указан движок XtraDB
вот тут рассмотрено немного больше форков: blogerator.ru/page/mysql-na-steroidah
Рассмотрено, но толку от них?
В данной теме только то, что реально можно использовать.
В данной теме только то, что реально можно использовать.
располагаете тайным знанием? так поделитесь им!
Почему тайным?
Идем на сайт Drizzle в раздел FAQ:
Can I run a website with this?
No. We are still making incompatible changes, and certainly do not believe the code is production quality.
Далее по списку в статье:
Активность в Ourdelta выдохлась — последний релиз был год назад. По-моему, вследствие появления deb-репозитариев у Percona. Я эту Ourdelta только из-за репозитария выбирал.
ExtSQL — Extended Usage Statistics for SQL. Формально — форк, но со временем Percona подобрала все важные статистические возможности или сделала свои. Последняя активность тоже была год назад.
SkySQL — вообще не форк, а название компании. В той статейке просто для массовки.
NoSQL — очевидно, сеонизаторский прием. Абы впихнуть модное слово в статью и выловить модный трафик.
Идем на сайт Drizzle в раздел FAQ:
Can I run a website with this?
No. We are still making incompatible changes, and certainly do not believe the code is production quality.
Далее по списку в статье:
Активность в Ourdelta выдохлась — последний релиз был год назад. По-моему, вследствие появления deb-репозитариев у Percona. Я эту Ourdelta только из-за репозитария выбирал.
ExtSQL — Extended Usage Statistics for SQL. Формально — форк, но со временем Percona подобрала все важные статистические возможности или сделала свои. Последняя активность тоже была год назад.
SkySQL — вообще не форк, а название компании. В той статейке просто для массовки.
NoSQL — очевидно, сеонизаторский прием. Абы впихнуть модное слово в статью и выловить модный трафик.
спасибо, это уже интересное добавление к обзору :)
>NoSQL — очевидно, сеонизаторский прием.
Это вы про HandlerSocket? По-моему, довольно классная штука — очень красиво оптимизировали узкую задачу — выборку по PK.
>NoSQL — очевидно, сеонизаторский прием.
Это вы про HandlerSocket? По-моему, довольно классная штука — очень красиво оптимизировали узкую задачу — выборку по PK.
Вот именно, что узковато для большинства пользователей. И что было целью упоминания? Сеонизаторство.
И кстати, в том проекте выборка возможна не только по PK.
И кстати, в том проекте выборка возможна не только по PK.
Кстати, с недавних пор handler sockets интегрированы в Percona Server :)
Drizzle?
>Support of other connection protocols other than libmysql
kb.askmonty.org/v/about-federatedx
>Сurrently, since FederatedX only uses libmysql, it can only talk to another MySQL RDBMS.
>Сurrently, since FederatedX only uses libmysql, it can only talk to another MySQL RDBMS.
Нужно понимать, что опенсорс-проекты из-за постоянной нехватки ресурсов делают только то, что реально нужно. Проблемы связи по odbc решаются однократным импортом-экспортом или на уровне клиентского приложения. Разработка же коммерческих СУБД в немалой степени направлена на удобство работы и создание уникальных фич, с которых потом невозможно слезть.
Поэтому federatedx подразумевает подключение к другому серверу по протоколу mysql. По сравнению с обычным federated (он без всяких форков и в 5.0 есть) исправлены важные принципиальные проблемы.
Поэтому federatedx подразумевает подключение к другому серверу по протоколу mysql. По сравнению с обычным federated (он без всяких форков и в 5.0 есть) исправлены важные принципиальные проблемы.
Это фактически то же самое, что Federated, но улучшенное и регулярно поддерживаемое: автор Federated ушёл из MySQL и работает над этим движком.
> В портах FreeBSD всего этого не найти, основной упор делается на Linux. Если кто-то собирал и ставил — поделитесь плиз опытом.
Могу попробовать написать для вас простенький порт.
Могу попробовать написать для вас простенький порт.
Например для MariaDB
скажу так: у меня чисто академический интерес, если порт напишите, то могу подбить админа попробовать его поставить в паралель с мускулем и погонять! было бы интересно. Пока получил репорт, что при сборке из сорцов проблем не возникает, мануала пока нет.
ТА ДА https://github.com/siasia/mariadb-port
Сойдёт для сельской местности.
Сойдёт для сельской местности.
Как и говорил собирать и инсталить нужно с префиксом ибо конфликтует с mysql.
Например:
# make PREFIX=/usr/local/mariadb
# make install PREFIX=/usr/local/mariadb
Например:
# make PREFIX=/usr/local/mariadb
# make install PREFIX=/usr/local/mariadb
Между делом порт ушёл в официальный репозиторий.
www.freebsd.org/cgi/cvsweb.cgi/ports/databases/mariadb/
www.freebsd.org/cgi/cvsweb.cgi/ports/databases/mariadb/
Ну и что? Ссылка на бинарник Перкона под Фряху. Вы хоть знаете, что такое порты?
Oracle тоже зашевелился и в версии 5.5 интегрированы патчи от Google, улучшена репликация, InnoDB 1.1 можно использовать новый формат хранения данных Barracuda. Установка google-perftools и сетап LD_PRELOAD также дают заметное увеличение производительности.
На проектах нашей компании в продакшене используется как MySQL 5.5.xx (да-да он только релиз кандидат но работает достаточно стабильно, хотя были небольшие неприятности) так и Percona Server 5.1.xx
Платформа Fedora Linux, пересобирается из *.src.rpm
На проектах нашей компании в продакшене используется как MySQL 5.5.xx (да-да он только релиз кандидат но работает достаточно стабильно, хотя были небольшие неприятности) так и Percona Server 5.1.xx
Платформа Fedora Linux, пересобирается из *.src.rpm
MariaDB вполне стабильно работает в production. Единственный глюк словили — иногда выставляет время работы какое-то совсем неприличное, соответственно, Linux загоняет его в nice 1 где-то.
>К счастью мы уже с вами живем в мире, где информация разносится со скоростью печати мысли и решения находятся молниеносно.
этот текст не несет смысловой нагрузки. мускуль форкнули благодаря тому что лицензия позволяет.
этот текст не несет смысловой нагрузки. мускуль форкнули благодаря тому что лицензия позволяет.
не совсем так. Изначально MariaDB начинался как независимый проект и то что он стал синхронен с MySQL — решения последующие.
Да, и вообще: мой текст — моя стилистика, я пишу для того чтобы пообщаться и выразить свои мысли, сделать микро обзорчик в вольной форме, привлечь внимание в конце концов, а не ставлю задачи составить академически верный обзор продукции.
Да, и вообще: мой текст — моя стилистика, я пишу для того чтобы пообщаться и выразить свои мысли, сделать микро обзорчик в вольной форме, привлечь внимание в конце концов, а не ставлю задачи составить академически верный обзор продукции.
Кстати, кто детально рылся в механизме ликвидации запросов? Если я верно понял, то им удается выкинуть из обработки связывающие таблицы, так как если бы на лету строился view, поправьте меня кто разобрался в деталях.
select t1.d, t3.e from t1, t2, t3, where t1.a=t2.b and t2.b=t3.c;
очевидно что t2 в запросе не участвует (where можно переписать как t1.a=t3.c and ...) т.о. ее можно выкинуть. Это снизит кол-во рассматриваемых вариантов в оптимизаторе, может ощутимо ускорить выполнение запроса когда во from много таблиц.
очевидно что t2 в запросе не участвует (where можно переписать как t1.a=t3.c and ...) т.о. ее можно выкинуть. Это снизит кол-во рассматриваемых вариантов в оптимизаторе, может ощутимо ускорить выполнение запроса когда во from много таблиц.
и да, оно вроде ликвидация таблиц, а не запросов.
кроме указанного в mariadb еще есть несколько оптимизаций выполнения подзапросов, как во from так и во where, которые отсутствуют в mysql.
Напишите подробнее — вставлю в статью
mysql сейчас безусловно материализует все подзапросы во from во время открытия таблиц. это ведет к тому что даже explain может занимать оч. много времени из-за материализации. в maria это поправили и вроде релизнули уже. кроме того, в марии подзапросы во from могут мержиться в верхний селект, так же как view, это позволяет выбрать более оптимальный план.
мария умеет переписывать подзапросы во where в виде semi-join (описание что это точно есть у постгресс, есть ли у марии не знаю).
еще у марии есть продвинутый join cache который позволяет ускорять выполнение join'ов в несколько раз (если удачно сложится).
но есть вопрос насколько все это production ready, есть слухи что не на 100% (сам не тестировал).
mysql этого пока не умеет
мария умеет переписывать подзапросы во where в виде semi-join (описание что это точно есть у постгресс, есть ли у марии не знаю).
еще у марии есть продвинутый join cache который позволяет ускорять выполнение join'ов в несколько раз (если удачно сложится).
но есть вопрос насколько все это production ready, есть слухи что не на 100% (сам не тестировал).
mysql этого пока не умеет
Как раз вчера пробовал поставить MariaDB как замену MySQL. Оказалось что просто так, прозрачно заменить, не получается (пробовал по freebsd 8.0), т.к. по умолчанию (да и по факту) innoDB ставиться как плагин, запустить который не позвезло (потому все таблицы с innoDB стали unknown table engine). Пришлось откатиться назад на mysql и ресерчить вопрос…
> Новые хранилища данных:
…
Справедливости ради стои заметить, что некоторые из них давно не новый и Sphinx, PrimeBase XT и FederatedX прекрасно работают с MySQL. Подозреваю, что остальные (как минимум OQGRAPH и XtraDB) тоже.
…
Справедливости ради стои заметить, что некоторые из них давно не новый и Sphinx, PrimeBase XT и FederatedX прекрасно работают с MySQL. Подозреваю, что остальные (как минимум OQGRAPH и XtraDB) тоже.
Никак не могу определиться, MariaDB или Percona выбрать. Вроде бы пишут что в MariaDB интегрированы в том числе те же патчи, что и в Percona, плюс ещё свои фишки, так что установив MariaDB я никаких преимуществ из Percona не упущу?
На текущий момент из преимуществ нужна расширенная статистика по пользователям, чтобы была возможность выяснить кто больше всего грузит базу.
На текущий момент из преимуществ нужна расширенная статистика по пользователям, чтобы была возможность выяснить кто больше всего грузит базу.
MariaDB включает движок XtraDB. Так что все основные фишки будут, если вы будете его использовать.
Percona Server, содержит также некоторое количество общих улучшений, решайте сами насколько они вам нужны — www.percona.com/docs/wiki/percona-server:features:start
Percona Server, содержит также некоторое количество общих улучшений, решайте сами насколько они вам нужны — www.percona.com/docs/wiki/percona-server:features:start
конкретно вам, похоже нужно вот это — www.percona.com/docs/wiki/percona-server:features:userstatv2
Я не знаю, есть ли этот патч в MariaDB
Я не знаю, есть ли этот патч в MariaDB
В MariaDB он есть kb.askmonty.org/v/mariadb-520-release-notes
Пока нужно только это, но в дальнейшем по оптимизации надо дальше куда-то развиваться, вот и никак не определюсь — выбрать путь MariaDB или Percona… Всё же думаю MariaDB будет перспективнее, остановлюсь на нём.
Пока нужно только это, но в дальнейшем по оптимизации надо дальше куда-то развиваться, вот и никак не определюсь — выбрать путь MariaDB или Percona… Всё же думаю MariaDB будет перспективнее, остановлюсь на нём.
У Percona Server также недавно стали доступны сборки для MacOS:
www.percona.com/downloads/TESTING/Percona-Server-55/Percona-Server-5.5.11-20.2/release-5.5.11-20.2/114/MacOSX/binary/
www.percona.com/downloads/TESTING/Percona-Server-55/Percona-Server-5.5.11-20.2/release-5.5.11-20.2/114/MacOSX/binary/
Поставили на этой недели Percona Server 5.5.32-31.0. Переходили с MySQL 5.1 — нагрузку в 16000 запросов в минуту прекрасно держит. На одном инстансе сервера развернуто 340 баз. Средний трафик к БД составляет 4,3 mb/s.
Sign up to leave a comment.
Форки движка MySQL: MariaDB, Percona. who is who?