Мои коллеги используют перкона сервер на рекламной бирже с 4000 ежесекундных запросах к БД, притом многие из них достаточно тяжеловесны. У перкона сервера есть платный саппорт — пока ни разу не обращались (2 недели), миграцию пережили без существенных артефактов поведения.
Вполне готово. Везде где используется MySQL+InnoDB его можно смело заменять на Percona Server. Цитирую из документации «High-profile users include 37signals, New Relic, and Scribd to name just a few. „
rpmbuild/dpkg -b — это не выход. За обновлениями необходимо следить самостоятельно. Плюс проблемы с безопасностью — ведь бэкпортированием секьюритификсов из новых версий в старые (если минорное обновление не допустимо) придется заниматься опять же самому. В общем это не для продакшена.
я имел в виду, что это лучше, чем на пакетном дистре делать ./configure>make>make install
Вполне себе для продакшена, если у вас тысячи однотипных серверов, создаем свой локальный репозиторий, следим за апдейтами. Ничего сложного. Когда нависает highload, то лучше так, чем упираться рогом в «нету в офф. репах, как же мы будем жить?»
потому что рекомендуется использовать отдельные файлы в /etc/portage/package.разное/, а не один файл на use, один файл на keywords и т.д.
да и самому так проще разбираться.
Почему тайным?
Идем на сайт 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.
Вот именно, что узковато для большинства пользователей. И что было целью упоминания? Сеонизаторство.
И кстати, в том проекте выборка возможна не только по PK.
Нужно понимать, что опенсорс-проекты из-за постоянной нехватки ресурсов делают только то, что реально нужно. Проблемы связи по odbc решаются однократным импортом-экспортом или на уровне клиентского приложения. Разработка же коммерческих СУБД в немалой степени направлена на удобство работы и создание уникальных фич, с которых потом невозможно слезть.
Поэтому federatedx подразумевает подключение к другому серверу по протоколу mysql. По сравнению с обычным federated (он без всяких форков и в 5.0 есть) исправлены важные принципиальные проблемы.
> В портах FreeBSD всего этого не найти, основной упор делается на Linux. Если кто-то собирал и ставил — поделитесь плиз опытом.
Могу попробовать написать для вас простенький порт.
скажу так: у меня чисто академический интерес, если порт напишите, то могу подбить админа попробовать его поставить в паралель с мускулем и погонять! было бы интересно. Пока получил репорт, что при сборке из сорцов проблем не возникает, мануала пока нет.
Как и говорил собирать и инсталить нужно с префиксом ибо конфликтует с mysql.
Например:
# make PREFIX=/usr/local/mariadb
# make install PREFIX=/usr/local/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
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 много таблиц.
mysql сейчас безусловно материализует все подзапросы во from во время открытия таблиц. это ведет к тому что даже explain может занимать оч. много времени из-за материализации. в maria это поправили и вроде релизнули уже. кроме того, в марии подзапросы во from могут мержиться в верхний селект, так же как view, это позволяет выбрать более оптимальный план.
мария умеет переписывать подзапросы во 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) тоже.
Никак не могу определиться, MariaDB или Percona выбрать. Вроде бы пишут что в MariaDB интегрированы в том числе те же патчи, что и в Percona, плюс ещё свои фишки, так что установив MariaDB я никаких преимуществ из Percona не упущу?
На текущий момент из преимуществ нужна расширенная статистика по пользователям, чтобы была возможность выяснить кто больше всего грузит базу.
MariaDB включает движок XtraDB. Так что все основные фишки будут, если вы будете его использовать.
Percona Server, содержит также некоторое количество общих улучшений, решайте сами насколько они вам нужны — www.percona.com/docs/wiki/percona-server:features:start
В MariaDB он есть kb.askmonty.org/v/mariadb-520-release-notes
Пока нужно только это, но в дальнейшем по оптимизации надо дальше куда-то развиваться, вот и никак не определюсь — выбрать путь MariaDB или Percona… Всё же думаю MariaDB будет перспективнее, остановлюсь на нём.
Поставили на этой недели Percona Server 5.5.32-31.0. Переходили с MySQL 5.1 — нагрузку в 16000 запросов в минуту прекрасно держит. На одном инстансе сервера развернуто 340 баз. Средний трафик к БД составляет 4,3 mb/s.
Форки движка MySQL: MariaDB, Percona. who is who?