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

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

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

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

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

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

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

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

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

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

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

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

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

  

Проектирование высоконагруженной системы на примере отделения банка

 Давно хотел почитать что-нибудь про проектирование систем. Толстых книг много, но читать их некогда. Хотелось что-нибудь покороче.

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

В итоге: 

получили на выходе сложную систему, включающую в себя:

— распараллеливание;

— предобработку;

— очередь;

— балансировку;

— конвейер;

— отложенные вычисления;

— кэширование;

— толстого клиента.

Заметка называется "Как думать при проектировании высоконагруженной системы?", читать здесь

Определение завершения распределённых вычислений

Несколько ссылок

• Слайды-книжка Кшемкальяни и Сингала Termination detection
• Раджив Мисра Termination detection
• Обзор статьи Мисры (видимо, другого) Detecting Termination of Distributed Computations Using Markers (1983)

А вообще как-то негусто лекционного материала на эту тему

Снимки глобального состояния - ссылки

Самый известный алгоритм для случая FIFO каналов - алгоритм Чанди-Лэмпорта, для неFIFO - алгоритм Лай-Янга. Есть ещё парочка алгоритмов для случая каузальной доставки (causal ordering).

Теперь ссылки. Сначала классические статьи

K. Chandy, L. Lamport Distributed Snapshots: Determining Global States of Distributed Systems (ссылка)

Ten H. Lai and Tao H. Yang On Distributed Snapshots (ссылка) 

F. Mattern Efficient Algorithms for Distributed Snapshots and Global Virtual Time Approximation (ссылка)

Материалы университета Принстон (курс COS 418: Distributed Systems):

• Themis Melissaris and Daniel Suo Chandy-Lamport Snapshotting (ссылка) 
• Kyle Jamieson Vector Clocks and Distributed Snapshots (ссылка)
• Лабораторка Chandy-Lamport Distributed Snapshots (ссылка)

Материалы университета МакМастера (курс CAS 769):

• Dr. Borzoo Bonakdarpour  Introduction, Logical clocks, Snapshots (ссылка)

Материалы университета Айовы:

• Ghosh Distributed Snapshot (ссылка) - есть граф достижимости состояний

Разбор статьи Чанди-Лэмпорта (ссылка)

Нашёл тут интересный блог The morning paper, где разбирают разные статьи по информатике. Понравился подзаголовок журнала: A random walk through Computer Science research. Блог интересный, располагается здесь.

Поскольку сейчас вникаю в тему распределённых снимков глобального состояния, просмотрел заметку о статье Чанди и Лэмпорта Distributed Snapshots: Determining Global States of Distributed Systems (1985). Хороший пересказ, есть пример о разноцветных шариках.

Из другого поста того же блога (Asynchronous Distributed Snapshots for Distributed Dataflows) можно узнать, что алгоритм Чанди-Лэмпорта используется в Apache Flink (это такая штука, которая позволяет проводить вычисления на потоках данных).

Снимки: предварительные сведения

Глобальное состояние - совокупность состояний всех локальных состояний процессов и каналов.

Глобальное состояние согласовано, если выполнены два условия:
C1. если посылка сообщения по каналу от P_i к P_j входит в локальное состояние P_i, то либо это сообщение входит в состояние канала C_ij, либо событие приёма этого сообщения входит в локальное состояние процесса P_j. Имеются ввиду состояния канала C_ij и локальные состояния процессов P_i и P_j, входящие в данное глобальное состояние. 
C2. если посылка сообщения по каналу от P_i к P_j не входит в локальное состояние P_i, то это сообщение не входит в состояние канала C_ij и не входит в локальное состояние процесса P_j.

Две основные проблемы при записи состояний:
П1. Как отличить сообщения, которые нужно записать в снимок от тех, которые записывать не нужно. С1 и C2 говорят, что нужно записывать те сообщения от P_i, которые были посланы процессом P_i до фиксации своего локального состояния.
П2. Как определить момент, когда процессу нужно сделать снимок. С2 говорит, что процесс P_j должен зафиксировать своё состояние до обработки сообщения от P_i, которое было послано  P_i после фиксации своего состояния.