- PVSM.RU - https://www.pvsm.ru -
Во время моего первого опыта работы с распределенными системами я постоянно сталкивался с некой CAP-теоремой, пришлось изрядно покопать, чтобы изучить и осознать её со всех сторон. Я не являюсь мастером баз данных, но надеюсь, что мое маленькое исследование мира распределённых систем будет полезно для обычных разработчиков. В статье я расскажу о том, что такое CAP, его проблемы и альтернативы, а также рассмотрим некоторые популярные системы баз данных через CAP призму.
Эта теорема была представлена на симпозиуме по принципам распределенных вычислений в 2000 году Эриком Брюером. В 2002 году Сет Гилберт и Нэнси Линч из MIT опубликовали формальное доказательство гипотезы Брюера, сделав ее теоремой.
По словам Брюера, он хотел, чтобы сообщество начало дискуссию о компромиссах в распределённых системах и уже спустя некоторое количество лет начал вносить в неё поправки и оговорки.
В CAP говорится, что в распределенной системе возможно выбрать только 2 из 3-х свойств:
Уже есть достаточно наглядных доказательств этой теоремы, поэтому дам ссылки на университет Баумана [1] и доказательство в виде сервиса «Позвони, напомню!» [2].
Многие статьи сводятся к вот такому вот простому треугольнику.
Для применения CAP теоремы на практике, я выбрал 3 наиболее, на мой взгляд, подходящие и достаточно популярные системы баз данных: Postgresql, MongoDB, Cassandra.
Следующие пункты относятся к абстрактной распределенной БД Postgresql.
Таким образом, система не может продолжать работу в случае partition, но обеспечивает strong consistency и availability. Это система CA!
Следующие пункты относятся к абстрактной распределенной БД MongoDB.
Таким образом, система может продолжать работу в случае разделения сети, но теряется CAP-availability всех узлов. Это CP система!
Cassandra использует схему репликации master-master, что фактически означает AP систему, в которой разделение сети приводит к самодостаточному функционированию всех узлов.
Казалось бы всё просто… Но это не так.
На тему проблем в CAP теореме написано множество подробных и интересных статей, здесь, на Хабре, поэтому я оставлю ссылку на CAP больше не актуален [3] и мифы о CAP теореме [4]. Обязательно почитайте их, но относитесь к каждой статье, как к своего рода новому взгляду и не принимайте слишком близко к сердцу, потому что одни ругают, другие хвалят. Сам же я не буду слишком углублятся, а постараюсь выдать некоторую необходимую компиляцию.
Итак, проблемы CAP теоремы:
Consistency в CAP фактически означает линеаризуемость (и ее действительно трудно достичь). Чтобы объяснить, что такое линеаризуемость, давайте посмотрим на следующую картинку:
В описанном случае рефери закончил игру, но не каждый клиент получает один и тот же результат. Чтобы сделать его систему линеаризованной, нам нужно мгновенно синхронизировать данные между рефери и другими источниками данных, чтобы, когда рефери закончит игру, каждый клиент получил правильную информацию.
Availability в CAP, исходя из определения имеет две серьёзные проблемы. Первая — нет понятия частичной доступности, или какой-то её степени (проценты например), а есть только полная доступность. Вторая проблема — неограниченное время ответа на запросы, т.е. даже если система отвечает час, она всё ещё доступна.
Устойчивость к распределению не включает в себя упавшие узлы, и вот почему:
Поэтому, нужно помнить про способность системы восстанавливаться, но за рамками CAP теоремы.
Коммуникация узлов между собой обычно происходит через асинхронную сеть, которая может задерживать или удалять сообщения. Интернет и все наши центры обработки данных обладают этим свойством, и это не маловероятные инциденты, поэтому CA системы в рамках разработки рассматриваются крайне редко.
Представьте систему, в которой два узла (Master, Slave) и клиент. Если вдруг вы потеряли связь с Master, клиент может читать из Slave, но не может писать — нет CAP-availability.
Ок, вроде CP система, но если Master и Slave синхронизируются асинхронно, то клиент, может запросить данные от Slave раньше успешной синхронизации — теряем CAP-consistency.
Чистые AP системы, могут включать в себя просто 2 генератора чисел. Чистые CP системы, могут вообще не быть доступны, т.к. буду пытаться придти к согласованному состоянию и не будут нам отвечать. Идём дальше, CP системы дают нам не ожидаемый нами strong consistency, а eventual consistency. О нём поговорим чуть позже.
В конце концов, это всего лишь попытка классифицировать что-то абстрактное, поэтому вам не нужно изобретать велосипед. Я рекомендую использовать следующий подход при попытке работать с распределенными БД:
Теорема PACELC [6] была впервые описана и формализована Даниелом Дж. Абади из Йельского университета в 2012 году. Поскольку теорема PACELC основана на CAP, она также использует его определения.
Вся теорема сводится к IF P -> (C or A), ELSE (C or L).
Latency — это время, за которое клиент получит ответ и которое регулируется каким-либо уровнем consistency. Latency (задержка), в некотором смысле представляет собой степень доступности.
BASE — это своеобразный контраст ACID, который говорит нам, что истинная согласованность не может быть достигнута в реальном мире и не может быть смоделирована в высокомасштабируемых системах.
Что стоит за BASE:
Меня несколько раз спрашивали о том, что лучше ACID или BASE — это зависит от вашего проекта. Например, если ваши данные не критичны, и пользователь действительно заботится о скорости взаимодействия, BASE будет лучшим вариантом. Если всё наоборот — ACID поможет вам сделать систему максимально надежной с точки зрения данных.
Теперь, когда мы знаем о большинстве подводных камней, давайте попробуем рассмотреть те же самые популярные системы баз данных через призму полученных знаний.
Postgresql действительно допускает множество различных конфигураций системы, поэтому их очень сложно описать. Давайте просто возьмем классическую Master-Slave репликацию с реализацией через Slony.
Давайте узнаем что-то новое о MongoDB:
Спасибо за внимание!
Автор: svinopapka
Источник [20]
Сайт-источник PVSM.RU: https://www.pvsm.ru
Путь до страницы источника: https://www.pvsm.ru/postgresql/255382
Ссылки в тексте:
[1] университет Баумана: http://ru.bmstu.wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP_(Consistency,_Availability_%D0%B8_Partition_tolerance)#.D0.9E.D0.B1.D0.BE.D1.81.D0.BD.D0.BE.D0.B2.D0.B0.D0.BD.D0.B8.D1.8F
[2] доказательство в виде сервиса «Позвони, напомню!»: https://habrahabr.ru/post/130577/
[3] CAP больше не актуален: https://habrahabr.ru/post/258145/
[4] мифы о CAP теореме: https://habrahabr.ru/post/322276/
[5] ACID: https://ru.wikipedia.org/wiki/ACID
[6] PACELC: https://en.wikipedia.org/wiki/PACELC_theorem
[7] dzone.com/articles/better-explaining-cap-theorem: https://dzone.com/articles/better-explaining-cap-theorem
[8] blog.thislongrun.com/2015/03/the-confusing-cap-and-acid-wording.html: http://blog.thislongrun.com/2015/03/the-confusing-cap-and-acid-wording.html
[9] neo4j.com/blog/acid-vs-base-consistency-models-explained: https://neo4j.com/blog/acid-vs-base-consistency-models-explained/
[10] databases.about.com/od/databasetraining/a/databasesbegin.htm: http://databases.about.com/od/databasetraining/a/databasesbegin.htm
[11] brooker.co.za/blog/2014/07/16/pacelc.html: https://brooker.co.za/blog/2014/07/16/pacelc.html
[12] www.postgresql.org/files/developer/transactions.pdf: https://www.postgresql.org/files/developer/transactions.pdf
[13] www.airpair.com/postgresql/posts/sql-vs-nosql-ko-postgres-vs-mongo: https://www.airpair.com/postgresql/posts/sql-vs-nosql-ko-postgres-vs-mongo
[14] jennyxiaozhang.com/nosql-hbase-vs-cassandra-vs-mongodb: http://jennyxiaozhang.com/nosql-hbase-vs-cassandra-vs-mongodb/
[15] blog.thislongrun.com/2015/04/the-unclear-cp-vs-ca-case-in-cap.html: http://blog.thislongrun.com/2015/04/the-unclear-cp-vs-ca-case-in-cap.html
[16] www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed: https://www.infoq.com/articles/cap-twelve-years-later-how-the-rules-have-changed
[17] cs-www.cs.yale.edu/homes/dna/papers/abadi-pacelc.pdf: http://cs-www.cs.yale.edu/homes/dna/papers/abadi-pacelc.pdf
[18] blog.thislongrun.com/2015/03/dead-nodes-dont-bite.html: http://blog.thislongrun.com/2015/03/dead-nodes-dont-bite.html
[19] queue.acm.org/detail.cfm?id=2462076: http://queue.acm.org/detail.cfm?id=2462076
[20] Источник: https://habrahabr.ru/post/328792/?utm_source=habrahabr&utm_medium=rss&utm_campaign=sandbox
Нажмите здесь для печати.