Отказоустойчивость в Greenplum

 Как интересно, оказалось, что в Greenplum нет полноценной отказоустойчивости мастера. Есть только реплика, на которой лежит копия информация с мастера. Если он перезапустится - эту информацию можно будет считать и восстановить состояние. В общем, сделано как в Хадупе прошлых версий (в Hadoop 3 уже вроде бы федерализованный мастер).

А вот на уровне сегментов в Greenplum автоматическая отказоустойчивость есть. Сегменты - это наборов экземпляров Postgres. В каждом таком сегменте есть своя главная реплика, управляющая сегментом. В случае её падения главной становится одна из подчинённых реплик.

Примечание. Greenplum - широкоиспользуемая аналитическая СУБД с открытым кодом. Один из главных конкурентов Vertica. Используется, например, в Тинькове 

Шардирование

 На Хабре появилась интересная статья А.Комягина (ссылка) о масштабировании СУБД с помощью шардов. Приведу несколько цитат 

Определение шардирования:

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

 Выбор ключа шардирования - диапазонный (range) или хэшированный?

в большинстве случаев я бы рекомендовал использовать хешированное распределение (hashed shard key). Причина проста — hash-функция позволяет даже плохой ключ, с точки зрения формальных признаков, превратить в хороший. Если ещё проще, то задача hash-функции — равномерно распределить сущности по шардам. Я мог бы углубиться в суровую математику и рассказать про критерий Пирсона и другие интересные вещи, но в этом нет необходимости, поскольку инженеры компании MongoDb Inc. уже за нас всё продумали и выбрали хорошую hash-функцию для задачи шардирования. Поэтому нам осталось просто этим всем пользоваться и наслаждаться.

Подсчёт общего числа документов на шардах - по-моему, намного более жизненная иллюстрация проблемы снимка мгновенного состояния, чем хрестоматийный пример про банковскую систему

в шардированных коллекциях не всегда работает операция count. Она может возвращать большее количество документов, чем в действительности. Причина — балансировщик, который в фоне «переливает» документы с одного шарда на другой. В какой-то момент времени возникает ситуация, когда документы уже записались на целевой шард, а на исходном ещё не удалились — count посчитает их дважды.  

Ну и интересная картинка - кластер с шардами СУБД, распределённый на два ЦОД (кликните, чтобы увеличить):