Couchbase

     Поскольку на текущем месте работы у нас используется Couchbase, я решил познакомиться с ним по ближе.  Скачал себе architecture review. Ну и покурил его на досуге. Мое первое впечатление:

1. Интересная архитектура
2. Отличная документация
3. Прямо из коробки идет отличный web интерфейс -  через который можно смотреть статистику по кластеру, изменять настройки на лету. В общем приятно работать с таким софтом. 

Но есть в нем вещи которые меня очень насторожили. Уж очень гладко все на бумаге - nothing share architecture, master-master replication. Хочешь в разных датацентрах - пожалуйста, вот тебе XDCR репликация. Прям - вот оно, настало счастье программистов, не СУБД а мечта. Но если внимательно почитать документацию то понимаешь - что все построено в расчете на оптимистичный сценарий. Если все хорошо с серверами - то и мы вроде как работаем,  а если с серверами какая хрень случается - то уж как получится...

1. По умолчанию сервер отправляет клиенту подтверждения - не дожидаясь пока данные будут реально записаны на диск. Он кладет данные в некоторый кэш, и ставит в очередь на сохранение. А сохраняться они действительно или нет - этого ты при таком раскладе не узнаешь.
2. Можно с помощью опции сказать серверу,  чтобы он отправлял клиенту подтверждение только после успешного сохранения данных на диск.  Но вдруг диск сдохнет ? Для обеспечения консистентности нам нужно сохранить данные минимум на две ноды. К сожалению невозможно заставить Couchbase сначала сохранить данные на диск, отреплецировать данные на другую ноду - и только потом отправлять клиенту подтверждение. 
3. Следующая вещь, которая вызвала у меня кучу вопросов - это auto failover. Да, задумано все круто, это беспорно.  Но меня интересует вопрос - вот упала нода, сколько времени  потребуется кластеру на то чтобы определить это, и перевести реплику в активное состояние ? 2 минуты ? 3 минуты ? 5 ? В документации об этом не слова. С какой частотой Couchbase клиент проверяет cluster map ? Сколько вообще времени пройдет до того момента как данные снова станут доступны ? Хз. Другого ответа нет.
4. Еще больше вопросов возникает к управлению кластером. Что произойдет если так называемый - orchestrator, нода выбранная управлять кластером - сама двинет кони ? Согласно документации  кластер выберет нового orchestrator,  и все будет замечательно. Но что произойдет с клиентами которые в  этот момент захотят получить cluster map ? Ведь orchestrator - это обычный узел кластера, который также обслуживает определенные partition, и в случае смерти нужно чтобы кто-то перевел реплику в активное состояние, а partition который находился на умершей ноде в состояние dead.  Вообще интересный момент - как сказать сдохшей ноде, что она должна перейти в состояние dead ? Разговор с мертвецами - это под силу только Couchbase. И вообще, может нода вовсе и не умирала, а умер коммутатор в который она была воткнута ? Потом коммутатор сменили, и у нас в кластере внезапно оказалось две активных реплики одного раздела.  В общем не очевидно как будут разруливаться такие ситуации.
5. Если продолжить фантазировать на тему сдохнувшего свича, то легко можно смоделировать ситуацию когда мы получаем классический split brain. Если внезапно кластер распадается на 2 подсети - в каждой из них будет выбрано по одному orchestrator. И каждый  из них будет думать что он то и есть настоящий,  и будет раздавать на право и на лево свою cluster map, и писать данные данные... а что потом потом делать  с этими двумя кластерами и как объеденить данные с них - это будет головоломка для dev-ops.
6. Что еще меня повеселило - это открытие в области алгоритмов, сделанное программистами Couchbase. Встречайте - B-Superstar index, новое слово в алгоритмике. И не важно что вот уже лет 50 никто ничего нового в этой области не придумал - они новый тип индекса изобрели. Просто маркетинг головного мозга.

Можно конечно сказать что я придираюсь, и Couchbase как-то обрабатывает все эти ситуации - но реальность показывает что это не так. С нашим небольшим Couchbase кластером из 3-х нод не так давно произошла "пренеприятная" история. Он ушел в даун (или сделал вид что ушел в даун) и никто из админов долго не мог сказать что с ним стряслось.  Я процентов на 90 уверен что без косяков админов там не обошлось, но по факту - одна из трех нод умерла, одновременно с этим начался процесс  репликации и производительность кластера настолько деградировала что пациент был скорее мертв чем жив.