А за три года до этого, Убер перешел с MySQL на PostgreSQL.
Ну т.е. они не следили за пулом соединений, открывали долгие транзакции, что было ок для MySQL, переползли на PostgreSQL и начали страдать от того что эти проблемы на Другой СУБД начали стрелять?
С репликацией я согласен, нужно уметь её готовить в PostgreSQL, равно как и в MySQL. У каждой есть свои плюсы и минусы и в PostgreSQL субьективно это делается с бОльшими танцами с бубном, но по остальным пунктам - есть у меня подозрение что они просто умели в MySQL (и весь их имеющийся на тот момент код) и перейдя на другую СУБД огребли от тех аспектов которые в MySQL не стреляли.
Я поработал с тем и другим и при прочих равных выберу PostgreSQL за более мощную работу с типами и индексами или последнюю MySQL в strict режиме только если команда или заказчик того захотят. Потому что ловить баги "какого хрена у меня в NOT NULL поле ничего не лежит?!" или не получать ошибки при попытке записи строки в 1000 символов в поле VARCHAR(20) - это непосильно для моих нервов =)
Ну а если стоимость сервера деленная на количество попугаев удручает:
Перед apache поставить nginx или вообще заменить его на nginx,
Продумать систему статического кэширования страниц, либо тот же memcache чтобы mysql не загибался
Какую всю историю? В арбитраж WebMoney «владелец кошелька получает деньги за продажу уроков, авторским правом на которые не обладает», туда же прикрепить ссылку на ваш оригинальный сайт либо на него же, на страницу с описанием душещипательной истории какой он нехороший человек =)
Основные минусы Elliptics, как уже сказали — документация и поддержка.
С доками полный аллес капут, настолько что товарищ, писавший обертку-интерфейс для php в конце концов начал забивать на чтение огрызков доки, письма авторам и тупо начал ковырять код, выдирая оттуда параметры навроде «как указать этой хреновине с каким modification-time сохранить этот файлик».
Ну а поддержка — есть 2 ноды, они работают. Как мониторить их состояние — не особо понятно. Да, есть тулза, показывающая состояние, но что с этим еще можно сделать — непонятно. В итоге сидим и думаем, а не отказаться ли от него в сторону чего-нибудь еще.
И да, тюнить всё. монгу (не знаю, не сталкивался), nginx — воркеры, треды, ulimit, поставить мониторинг (хотя бы munin, под обработку данных — другая машина, на сервере только munin-клиент)
не знаю как в memcache, но в redis можно подписываться на события. Т.о. скрипт может подписаться на канал и получать уведомления при поступлении события
Ну т.е. они не следили за пулом соединений, открывали долгие транзакции, что было ок для MySQL, переползли на PostgreSQL и начали страдать от того что эти проблемы на Другой СУБД начали стрелять?
С репликацией я согласен, нужно уметь её готовить в PostgreSQL, равно как и в MySQL. У каждой есть свои плюсы и минусы и в PostgreSQL субьективно это делается с бОльшими танцами с бубном, но по остальным пунктам - есть у меня подозрение что они просто умели в MySQL (и весь их имеющийся на тот момент код) и перейдя на другую СУБД огребли от тех аспектов которые в MySQL не стреляли.
Я поработал с тем и другим и при прочих равных выберу PostgreSQL за более мощную работу с типами и индексами или последнюю MySQL в strict режиме только если команда или заказчик того захотят. Потому что ловить баги "какого хрена у меня в NOT NULL поле ничего не лежит?!" или не получать ошибки при попытке записи строки в 1000 символов в поле VARCHAR(20) - это непосильно для моих нервов =)