поделюсь и своими соображениями.....

я с постгрес работал (наверно стоит сказать баловался) лет эдак 6-8 назад и все
тоесть ничерта уже не знаю и не помню

пред история
сейчас сервис работает на MySQL 5.1.52 (если мне не изменяет память), все таблици MyISAM, master+slave
сейчас БД занимает около 50ГБ, постоянно растет

после того как сдохла мать на одно из серверов, и позиция бинлога слейва опережала мастер ну очень прилично, а так же из-за того что восстановлени и запуск сервиса занял аж 6 часов времени, ни и естественно после того как директор вспомнил всех "лаского"...
было принято решение переехать на что то более стабильное, соответсвенно задались вопрос "а на что?"

сразу требования были такими
1. максимальная стабильность
2. синхронная репликация
3. легкость восстановления
4. отсутвие переделки кода, или сведение переделок к минимуму

я прошерстил мускульные решения и остановился на Percona XtraDB Cluster.
наш админ, был категорически против такого костыльного решение, цитирую не дословно )) "надстройка над дряхлой реализацией репликации в мускула". И предложил свою идею - "нафига нам такая глючная СУБД, давайте PostgreSQL ставить, есть много промышленых решений ....".
И еще стоит вспомнить то что обычно я на плюсы обращаю в последнию очередь, если решение подходит по требования, то мне куда интереснее знать минусы системы и с чем нам придеться столкнуться, чем знать всякие плюшки на которые и так никто не расчитывал. Посему в моих отчетах было больше высказано всяких бяк перконы (я с нее начал) чем преимуществ. На что админ "хватась за голову" кричал "нафига нам надо такое дерьмо, я в продакшн его не пущу, и вообще гарантий не даю"

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

Вообщем сошлись на том что нужно проверять/тестировать.

Начну с конца, тоесть с того вывода который я сам для себя сделал в самый последний момент
это "промышленность решения"
с одной стороны это означает что данноя штука уже давным давно используеться в продакшн, а с другой
Перкона - контора которая промышленно занимаеться разработкой, продукт постоянно развиваеться, ведет продвижение в массы, тех поддержку и пр.
"поделки постгреса" - написано вроде валом, вроде в продакшене работают, но никто ни за что не отвечает. Ну окромя skytools, но она нам не подходила так как имела асинхронную репликацию.

Для постгреса был выбран pgpool II , так как PGCluster умер вроде бы давно, вторую версию мы с админом так и не нашли. А ничто другое синхронную репликацию не поддерживает.

Почему начал с конца?
именно с возможности найти вменяемую свежую, обновляемую информацию по каждому и зрешений из какотото одного места. Тоесть сто бы создать кластер перконы мне понабоилось два ресурса, один из которых сам сайт перконы второй http://www.mysqlperformanceblog.com/, который и так ведут перконовци. Потом уже понадобилось куча других ресурсов, но то уже больше касалось понимания происходящих процессво и тонокого тюна.

Еще стоит отметить - что наш админ, сильно настаивал на том что не очень доверяет какимто продуктам и конторорам которые не дают сразу из коробки какогото полноценного решения. Витиевато сказал )). Я к тому что вот кластре перконы давал инфу как построить кластер, но не давал сриптов/программ/решений как полноценно мониторить кластер как автоматически правильно восстанавливать узел и пр.

Это в свою очередь добавило еще такое неявное условие к тестированию: оба кластера тестировались только с теми настройками которые рекомендовались для работы серверов в кластере. Никакого тонкого тюнинга не проводилось. Балансировщики также ни как тонко не настраивались. Вообщем такое себе "коробочное" решение.

И так некоторые данные из тестов:



все перечисленные конфиги относяться к виртуалкам запущеным на офисных (вообщем даже домашних) машинах.

далее админ сказал что неплохо было бы проверить LA при интенсивной записи, хотябы по top
поскольку нам нужна синхронная репликация, то масштабировать запись получаеться не сильно, тоесть нужно было проверить насколько движки серверов будут блоикровать остальную систему и самих себя

для данного теста были оставлены два узла, 6 ядерная машина была использована как гостевая для ВМ балансера, и создание тестовых процессов, на ней же поднята NFS, куда collectd писал свои наблюдения с узлов кластера.

условия

что имеем


еще интересно то что la у постгреса значительно меньше получился на машине с более быстрым процессором - почему не знаю.


и снова небольшое резюме
графики load average - при сравнении кластеров не показательны
да у мускуля он выше, но мускул делает значительно больше работы чем тот постгрес, пишет данные, ведет бинлог, ведет кеш Галеры и еще кучу всего. И при этом отрабатывает запросы быстрее постгреса. Вот если опустить скорость до уровня постгреса, вот тогда можно было что то сказать более конкретно.

Восстановление

перкона - простовь добавь узел, если упало так что видно что будет трудно восстанавливать - добей (удали все), и покдлючи с нуля
постгрес - лично я (я не админ и не сильно хотел рыться во всем этом) так и не понял как сделать востановление, на момент написания моего отчета и этого текста, админ тоже не разобрался как его восстанавливать.

и еще пару слов
если я правильно понимаю - то репликация pgpool как то и не репликация вовсе, тоесть по термину то она работает как надо, а вот если глянуть внутрь то pgpool просто делает такую себе широковещательную рассылку на узлы кластера

так же проверялось, но описывать уже не буду
- на сколько легко меняються струкутуры таблиц в двух решениях, и как это влияет на работу кластера
- также бегло было определено что перезд, именно переезд, существующего приложения на постргрес - вообще кактастрофа, просто так БД не конвертируешь, часть кода придеться менять точно.
- писать приложение с нуля на постгрес можно, хотя все таки меня смущает вопрос производительности. Так же у постгреса более развитый язык описания функций/процедур, и много вкусных плюшек в типах данных и ограничениях, но это уже....другая история вообщем то.

хочеться услышать ваше ФИ по моему тексту

то что перкона патчит эт я знаю, можно увидеть самому когда собирать перокону и тянуть из дистрибов
но все таки это официальное лицо которое поставлет Percona XtraDB Cluster
EnterpriseDB - дает какоето бесплатное кластерное решение? я серьезно спрашиваю

распереденная транзакция это подноготная происходящего процесса, но почему почти везде и на та же перкона имено так и называет свою репликацию синхронной ( http://www.percona.com/software/percona-xtradb-cluster/)



MasterZivВы сравнивали транзакционный Postgres и нетранзационный MySQL+MyISAM ?


мы сранивали постргес и перкону с ее движком поумолчанию XtraDB

MasterZivИзвини за прямоту, вы просто зря потратили время.
Тестирование СУБД -- это очень непростое дело, и что два сдуру сунувшихся в это дело
человека покажут что-то путное в виде результатов -- это абсолютно невероятное событие.

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

я даже по секрету скажу -
постгрес хоть и знаком админу, но как его тюнинговать, как вообще им пользоваться )) в компании никто не знает, я сам 6 лет мускулом пользуюсь, мож не знаю абсолютно всего, но 6 лет это и так не мало ))) (хочеться так думать)

и все таки результат как бы есть
переход на перкону как минимум не ухудшит производительности (с учетом того что текущиее решение тюнинговалось 6 лет, а перкона запускалась с "дефолтными" настройками). Да и переход будет безболезненным с минимальным временем простоя сервиса.

на данный момент мы просто не увидели сильных преимуществ постгреса на майскул "с патчами от перконы ))"

если я что то упустил, серьезное, с удовольствием выслушаю

Yo.!1.5M записей 10 минут ... как-то не впечатляет перфоменс. а сколько стооит эта перкона на такие 4 ноды ?
пока нисколько
все тестировалось на VirtaulBox машинах, проыцессор и память указаны в результатах
тюнингом никто не занимался

такой вопрос - а какой показатель считать впечатляющим?

(мы принципе сейчас находиммся на этапе реорганизации сервиса, часть операций вообще уйдет в NoSQL, там где именно важна скорость засписи а не целостность данных)

Yo.!1.5M записей 10 минут ... как-то не впечатляет перфоменс. а сколько стооит эта перкона на такие 4 ноды ?

зыж
и еще
она вообще бесплатна, платна только поддержка (срочная если нужно очень)
а про пока нисколько - я имел ввиду аренду шелезяк

рекомендуеться нечетное число узлов для того что бы галера могла нормально решить проблему split brain (мы пока остановились на 3х серверах)
кстати я так и не понял как с этим обстоят дела у pgpool

http://www.enterprisedb.com/solutions/mysql-vs-postgresql
вот такие высокопарные слова, а реальных данных для сравнениея нема
админ тоже так задушевно )) рассказывал о преимуществах но так и не привел никаких толковых аргументов

на данный момент из того что нам требуеться я нашел только вот это
http://www.enterprisedb.com/products-services-training/products/postgres-plus-advanced-server
но сколько оно стоит???