Теория инф-ии vs теория распределенных систем. CAP - Компьютерные священные войны

Здравствуйте, chaotic-kotik, Вы писали:

CK>смысл в том, что недоступный сервис будет возвращать много пятисотых ответов и на основании этих данных, можно определить время начала и окончания инцидента

Давайте уточним. "Много" — это сколько? "Мало" — это сколько?

CK>С чего ты взял что там round-robin DNS?
Это был пример. Мы рассуждаем о гипотетических системах, их поведении, и интерпретации этого поведения.
CK>Ты не понимаешь как работает load balancing, не так ли?
Я понимаю, как работает load balancing. А вы, похоже, не понимаете, что мы говорим не про какую-то одну конкретную систему, а про математику доступности и консистентности.

CK>я думал мы ту систему из failover cluster-ов обсуждаем, которая волшебным образом натягивается на любую задачу (на самом деле не натягивается)
Конечно же не натягивается. И не волшебным, и не на любую.

CK>В случае такси как раз важнее availability. Если водитель завершает поездку, а она у него не завершается, я как клиент теряю деньги.
CK>В случае же РА системы, данные об окончании поездки запишутся в БД, даже в случае недоступности одного из ДЦ яндекса.
CK>И консистентность там скорее всего достаточно поддерживать в рамках одной поездки, причем допустимо делать это пост фактум. Можно записать время/место начала поездки, точки маршрута и время/место окончания поездки отдельно для клиента и отдельно для водителя. Стоимость заранее расчитывается, биллинг отдельно работает и время задержки между окончанием позедки и списанием средств не критично.
Ну, так если стоимость рассчитана заранее, то нам и немедленного подтверждения завершения поездки не требуется, не так ли? Связь восстановилась, приложение дослало event — всё, можно биллить. Тем более, что реально биллинг может списывать (и в некоторых сценариях списывает) деньги ещё до окончания поездки.
И по-прежнему непонятно, как мы будем обеспечивать консистентность "в рамках одной поездки", если нам это напрямую запрещено CAP. Хотя бы простейшей задачи — назначить на заказ машину, и обеспечить один заказ на одну машину. В предположении, что у нас может пропадать связь между нодами. Ок, пусть у нас нодой считается DC, network partition в пределах DC мы пренебрежём.
Вы настаиваете на том, что нужно продолжать работу (A) даже если временно пропадает связь между DC. Каким образом два DC, между которыми пропала связь, придут к консенсусу относительно того, какую машину отправлять на заказ №XXXX?
Если такого способа нет, то нужна ли нам 100% availability такой ценой?
Если такой способ есть, то CAP опровергнута, и можно спокойно заниматься разработкой и других аналогичных приложений. Ведь задачи типа "бронирования билетов" и "перевода денег со счёта на счёт" сводятся к той же задаче, что и "свести водителя с пассажиром".

CK>пример нужен был для того, чтобы проиллюстрировать, что PA система, может продолжать работать и выполнять любые запросы, без ограничений, в случае подобного сбоя, можно не извращаться с выискиванием такого расположения данных, которое в случае сбоя затронет минимум клиентов. это удобно
Это удобно ровно настолько, насколько сильно вы предлагаете пожертвовать С.
S>>Ну, то есть они опровергли CAP теорему, я вас правильно понял? Ведь ни разу такого не было, чтобы одному клиенту назначили две машины и наоборот — то есть consistency у них соблюдена.
CK>выше ответил
Нет там ответа.

Здравствуйте, Sinclair, Вы писали:

CK>>бес попутал, availability конечно
S>Общепринятое понимание термина availability — это процент успешно выполненных запросов. Если у меня недоступно 1% диапазона ключей, то (в предположении равномерного распределения запрашиваемых данных) availability системы равна 99%.
S>Эта неожиданная на первый взгляд трактовка как раз и лежит, в частности, в основе географического сегментирования — когда теряется связь с удалёнными узлами, я всё ещё могу работать с локальными данными. Это гораздо лучше, чем полный отказ в обслуживании.

Ссылку на источник общепринятости такого определения — в студию. Потому что в вики, например,

The degree to which a system, subsystem or equipment is in a specified operable and committable state at the start of a mission, when the mission is called for at an unknown, i.e. a random, time. Simply put, availability is the proportion of time a system is in a functioning condition. This is often described as a mission capable rate. Mathematically, this is expressed as 100% minus unavailability.

Слова типа "нормальный специалист не читает википедию" можете сразу пропускать.
Если у вас какой-то более авторитетный для тебя источник — ок, прошу сюда детали.
Про неожиданность вашего определения — безусловно согласен

потому что более вероятно встретить определение из ACID-концепции, в которой понятие частичной доступности данных бессмысленно.

(Тем более что тут почему-то availability в процентах от времени. Сами себе противоречите?)

S>Полезность — это уже бизнес-интерпретация свойства availability. С точки зрения CAP нет никакой разницы между системами с availability в 90% и в 99.999% — обе не являются available. "Вы пожертвовали availability". Тот факт, что availability в 5 девяток — запредельная для прикладного сервиса величина, теорему никак не меняет.

S>Ещё раз повторю очевидную мысль: CAP теорема не даёт нам никакого базиса для сравнения систем с различным количеством девяток — просто потому, что в её определении availability нет никаких девяток.

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

S>Поэтому я не вполне понимаю, как можно без лукавства привлекать эту теорему для обоснования каких-либо решений.

См. абзацем выше.

S>Боюсь, что после этого вам придётся свернуть CAP-теорему в трубочку и заняться реальной service reliability engineering работой.

Подход "чего тут думать, трясти надо" плохо работает в реальной сложной среде.

Здравствуйте, Sharov, Вы писали:

S>1) Вот у нас имеются отдельные ненадежные(шумящие) компоненты и ненадежный(шумящий) канал. И вот с помощью целой теории,
S>в основе которой лежат теорема Котельниова-Шеннона и просто Шеннона, суть которых в том, что из ненадежных
S>отдельных компонентов и ненадежного канала мы можем построить надежную систему до каких-то там девяток -- 99.999(9).

Что можно строить надёжную систему — понятно, но чего я тут не понимаю — при чём тут одна конкретная теорема. (Кстати, если вспоминать историю открытия, то к ней Найквист имел больше отношения, чем Шеннон.)

S>Вопрос -- почему отсутствуют математические основания в теории распр. систем? Т.е. по сути аналогом теорем К.-Ш. является CAP, в которой отсутствует какие-либо
S>количественных характеристики или формулы. Ну да, есть некий компромисс между C,A и P, выберите 2 из 3. Ну чего-то как-то не густо. Есть фундаментальные работы Лэмпорта по консенсусу еще в 70-80-х годах, но как-то единой теории с соотв. мат. аппаратом не появилось? Почему?

Наверно, потому, что тема сложная и никто пока не смог придумать, как оправдать что-то конкретными цифрами?
Или, другой вариант, потому, что цифры строить тупо не на чем.
Как тут далее в дискуссии было, если мы рассматриваем каждый ключ данных по отдельности, мы можем рассматривать теорему для него одного, не учитывая других; если же база данных, как в типичном реляционном подходе, это один неделимый объект с требованием атомарности для него, то рассматривается он в целом и опять же цифры некуда подключить.

Вот если кто-то заинтересуется вопросом темпа сходимости в подходах, когда отдельные данные могут "добегать"... вариант возможный, но уже отработанный.\

S>2) Отдельно хотелось бы обсудить теорему CAP. В дискуссии, на которую я ссылаюсь выше, Синклер считает, что данная теорема как минимум бесполезна, ибо не дает
S>каких-либо количественных характеристик, а как максимум -- вредна. Я же считаю, что данная теорема крайне полезна, т.к. четко проговаривает ключевых абстракции и формулирует некий закон -- 2 из 3. Огромному кол-ву разработчиков всяческих распределенных систем типа соц. сетей, бложиков и т.д. сэкономила кучу времени на разработку костылей, четко определив абстракции, на которые необходимо уделить внимание и предоставив некоторый формализм. Что уже по сути не мало.

Полностью поддерживаю.

Здравствуйте, Слава, Вы писали:

С>2) Вся наука в айти закончилась в 1990 году примерно (или когда там C++ в народ пошёл), и дальше начался сплошной сбор денег.

Наука продолжается и с бо́льшим темпом, чем раньше. Но в школьные учебники это попадёт лет через 30, поэтому тем, кто не наблюдает поток нового, это не видно. Хотя некоторые фундаментальные результаты в давно проверенных областях возникают и сейчас.
А так можете посмотреть на тему, например, byzantine fault tolerance (близкой к теме данной ветки), основные результаты идут уже после 2000.

Здравствуйте, gandjustas, Вы писали:

G>Давайте по простому изложу CAP теорему.

G>У нас есть распределенная система, где клиент может отправлять сообщения произвольному узлу и узлы с точки зрения клиента неразличимы. Узлы общаются между собой.

G>Если возможны разделения сети, то есть узлы перестают общаться между собой, но клиент может достучаться до любых узлов, то у тебя есть два варианта:
G>1) Забить на согласованность данных в системе, то есть ответы от одних узлов будут отличаться от ответов от других узлов. При этом заявляется что можно создать eventualy consistent системы, которые восстановят согласованность после прекращения разделения.
G>2) Узлы не будут отвечать. При этом в теореме не рассматривается сколько узлов не будет отвечать.

G>Это полезно? Какие выводы можно сделать? Какие советы вы бы дали архитектору системы?

Не надеяться на невозможное и принять реальность в виде невозможности реализации всех трёх пунктов сразу.
По-моему, очень практичный совет.

G>Рассматривая цифры можно сделать другие выводы:
G>1) Разделения сети на практике не такое частое явления. Системы для которых важна отказоустойчивость и отсутствие потерь данных чаще всего работают в одной локальной сети. Сами авторы теоремы говорят что можно считать, что разделения в локальной сети не случаются.

Если с подпоркой в виде человека — да, может быть. Иначе проблемы не сводятся к тому, чтобы продублировать связи в количестве K+1 элемента.

G>2) eventualy consistent системы работают только тогда, когда интервал восстановления согласованности меньше частоты изменения данных. А в случае неограниченно долгого разделения этого обеспечить никак не получится. Поэтому система гарантированно потеряет данные или нарушит инварианты.

Про "работают только тогда..." — слишком грубое и некорректное утверждение. Представим себе, что в системе есть чёткое упорядочение событий (для простоты, через vector clock) и при восстановлении связи происходит доливка всех изменений, которые случились до этого, в порядке начиная с более ранних; и полосы пропускания хватает, чтобы влить все изменения за время полносвязности. В таком случае другие узлы не будут видеть только те данные, которые поступили во время активного разрыва. И даже если полоса просто не меньше, чем нужно для доливки всех данных — объём расхождений не будет неограниченно нарастать.

Что при неограниченно долгом разделении будут проблемы — факт. И этот вариант надо практически рассматривать отдельно.

G>3) Недоступность части узлов на практике не уменьшает доступность системы в целом. Кворумы и failover-кластеры работающие при сохранении связности более N/2 узлов помогают пережить даже значительные разделения без падения доступности.

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

Здравствуйте, gandjustas, Вы писали:

S>>Stateless вещь хорошая, но не всегда возможная.
G>REST это не про stateless, это про явное оперирование этим самым state и семантику глаголов для этого оперирования.

Каким боком подробности REST имеют хоть какое-то отношение к работе с разрывом связей?

Здравствуйте, IB, Вы писали:

AK>>Я попытался себе представить все три из трех, C + A + P, и это сломало мне мозг. Я не могу представить систему, которая во фрагментированном состоянии была бы одновременно консистентна и всегда доступна.
AK>>Можете привести какой-нибудь пример, где теорема САР не работала бы?
IB>Поинт в том, что прежде чем представлять, надо сначала определить, что значит "консистентна" и что значит "доступна". И внезапно окажется, что при консистентности Х и доступности Y, возможно и С и А и P и еще и Z в придачу. Иными словами, утверждение CAP — ложно.
IB>Более подробно и с примерами Антон ответил тут: http://rsdn.org/forum/db/7518063.1

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

Ой, а как же CAP? А вот так: нет никакого CAP, если разрешить unbounded delays.

Остальное — "дайте мне так чтобы с цифрами".

Этот подход значительно более непрактичен, чем CAP в "голом" виде, и считать его "опровержением" CAP... ну если у вас есть машина времени и божественная лечилка любой системы, пусть за неограниченное время — ok, действуйте.

А мы попробуем что-то сделать в реальном мире.

Здравствуйте, netch80, Вы писали:
N>Слова типа "нормальный специалист не читает википедию" можете сразу пропускать.
N>Если у вас какой-то более авторитетный для тебя источник — ок, прошу сюда детали.
https://landing.google.com/sre/sre-book/chapters/embracing-risk/#risk-management_measuring-service-risk_aggregate-availability-equation
Инженеры Гугла называют "общепринятое" определение time-based availability.

At Google, however, a time-based metric for availability is usually not meaningful because we are looking across globally distributed services. Our approach to fault isolation makes it very likely that we are serving at least a subset of traffic for a given service somewhere in the world at any given time (i.e., we are at least partially "up" at all times). Therefore, instead of using metrics around uptime, we define availability in terms of the request success rate

(выделение — моё. Источник — https://landing.google.com/sre/sre-book/chapters/embracing-risk/)
Так что эта очевидная, в общем-то, мысль пришла в голову не мне одному. Практически для любой распределённой системы мы понимаем, что она почти всегда partially up, и partially down. Поэтому пытаться опираться на промежутки времени при расчёте availability противоречит здравому смыслу.

N>(Тем более что тут почему-то availability в процентах от времени. Сами себе противоречите?)
Где вы там увидели проценты от времени?
Цитирую:

Значит, мы выражаем Availability в виде приемлемого % запросов, которые вылезут за пределы T₀.

N>Тот, кто прошёл хотя бы базовую математику, догадался бы, что в твоём текущем (совершенно не интересующемся атомарностью) подходе достаточно рассмотреть теорему по отношению к каждой записи данных отдельно.
Ок, давайте рассмотрим.
S>>Поэтому я не вполне понимаю, как можно без лукавства привлекать эту теорему для обоснования каких-либо решений.
N>См. абзацем выше.
Ни абзацем выше, ни абзацем ниже никакого примера использования CAP я не вижу.

N>Подход "чего тут думать, трясти надо" плохо работает в реальной сложной среде.
Именно. Вот я и предлагаю именно думать. Но при думании CAP-теорема не помогает никак. А скорее даже мешает.
SRE — он как раз в первую очередь про "думать", а не про "трясти". "Трясти" — это принимать решения на основе "эвристик" (а чаще — просто шаблонных заблуждений), вроде "Падает? Ну, давайте заменим кластером. Тормозит? Ну, давайте уберём кластер". Это не инжиниринг, это метод проб и ошибок.
Нормальная SRE начинается с требований. Типа "мы хотим приложение вот с таким процентов успешных запросов, при вот таких response times, вот в таких регионах, и с вот такой проектной нагрузкой".
Гугл пишет, что у них есть волшебный инструмент, который из такой формулировки умеет строить решения — сколько кластеров, в каких DC, и с какими параметрами надо резервировать.
К сожалению, вот именно эта часть их системы публичного освещения не получила

Надо полагать, пацаны в курсе, что такое конкурентное преимущество, и в какой момент нужно заткнуться, выступая на конференции.

Здравствуйте, Lexey, Вы писали:

L>[Зануда mode on]
L>Строго говоря, не может вероятность расти экспоненциально. Просто потому, что она единицей ограничена. И, естественно, там не сумма вероятностей, а (1 — (1-p)**N), где p — вероятность отказа одного узла.
L>[Зануда mode off]
Ну, так-то всё верно. Любая функция вида y = A+B*e^(С+В*x) называется экспоненциальной. В том числе и эта

Здравствуйте, netch80, Вы писали:

N>

Ой, а как же CAP? А вот так: нет никакого CAP, если разрешить unbounded delays.

N>Остальное — "дайте мне так чтобы с цифрами".
Дайте хотя бы с формулами.

N>Этот подход значительно более непрактичен, чем CAP в "голом" виде, и считать его "опровержением" CAP... ну если у вас есть машина времени и божественная лечилка любой системы, пусть за неограниченное время — ok, действуйте.

А мы попробуем что-то сделать в реальном мире.
Опровергнуть CAP не получится. Опровергнуть полезность CAP — легко.
Ну, вот к примеру: давайте останемся в той же трактовке A и P, что в CAP. Какова наилучшая Consistency, которую можно получить в AP-системе в этих терминах?
Linearizability невозможна, а что возможно?

Здравствуйте, Sinclair, Вы писали:

CK>>С чего ты взял что там round-robin DNS?
S>Это был пример. Мы рассуждаем о гипотетических системах, их поведении, и интерпретации этого поведения.

В данном случае, я привел в пример реальную систему, с которой работаю, там нет такого поведения.
Ну и я в своей практике ни разу не видел, чтобы кто-то был настолько отчаянным, чтобы ставить свои front-end-ы за round robin DNS без прослойки из HAProxy или другого load balancer-а, который умеет автоматически выводить сервера из ротации, в случае проблем.

CK>>Ты не понимаешь как работает load balancing, не так ли?
S>Я понимаю, как работает load balancing. А вы, похоже, не понимаете, что мы говорим не про какую-то одну конкретную систему, а про математику доступности и консистентности.

Про математику доступности и консистентности ты еще ничего не написал. Может наконец расскажешь как, по твоему, правильно считать/измерять?

CK>>я думал мы ту систему из failover cluster-ов обсуждаем, которая волшебным образом натягивается на любую задачу (на самом деле не натягивается)
S>Конечно же не натягивается. И не волшебным, и не на любую.

И как ты это понял? Уж не с помощью ли САР?

S>Ну, так если стоимость рассчитана заранее, то нам и немедленного подтверждения завершения поездки не требуется, не так ли? Связь восстановилась, приложение дослало event — всё, можно биллить. Тем более, что реально биллинг может списывать (и в некоторых сценариях списывает) деньги ещё до окончания поездки.

Поездка, которая превысила лимит времени, будет пересчитана.

S>И по-прежнему непонятно, как мы будем обеспечивать консистентность "в рамках одной поездки", если нам это напрямую запрещено CAP. Хотя бы простейшей задачи — назначить на заказ машину, и обеспечить один заказ на одну машину. В предположении, что у нас может пропадать связь между нодами. Ок, пусть у нас нодой считается DC, network partition в пределах DC мы пренебрежём.

Давай я точную цитату сюда скопирую, а то ты процитировал то что тебе удобно и споришь с этим.
CK>>И консистентность там скорее всего достаточно поддерживать в рамках одной поездки, причем допустимо делать это пост фактум.

S>Вы настаиваете на том, что нужно продолжать работу (A) даже если временно пропадает связь между DC. Каким образом два DC, между которыми пропала связь, придут к консенсусу относительно того, какую машину отправлять на заказ №XXXX?

Я не утверждал, что для того, чтобы отправить машину на заказ, достаточно АР системы. Тут как раз нужна консистентность, поэтому если клиент начал вызов, но ДЦ, в котором он обслуживается, оказался отрезан от других, вполне нормально вернуть ошибку, чтобы избежать ситуации, когда водитель получает два заказа. Клиент может попробовать вызвать такси второй раз.

S>Если такого способа нет, то нужна ли нам 100% availability такой ценой?
S>Если такой способ есть, то CAP опровергнута, и можно спокойно заниматься разработкой и других аналогичных приложений. Ведь задачи типа "бронирования билетов" и "перевода денег со счёта на счёт" сводятся к той же задаче, что и "свести водителя с пассажиром".

Я предлагал использовать РА систему для регистрации событий поездки — начало, точки через которые проехал водитель, конец, оценка и тд. Тут возможна eventual consistency без конфликтов. Все сводится к записи данных в распределенное хранилище, причем данные могут быть представлены как CRDTs, поэтому даже если данные клиента пришли в изолированный из-за network partition ДЦ, запись можно выполнить через sloppy quorum и потом восстановить консистентность, после восстановления связи между ДЦ, довольно очевидным образом.

Здравствуйте, chaotic-kotik, Вы писали:
CK>В данном случае, я привел в пример реальную систему, с которой работаю, там нет такого поведения.
Ну, вот часть сложностей в этом разговоре ровно от того, что вы обсуждаете конкретную систему (о которой лично мне ничего не известно), а я говорю о теоретических соображениях.

CK>Ну и я в своей практике ни разу не видел, чтобы кто-то был настолько отчаянным, чтобы ставить свои front-end-ы за round robin DNS без прослойки из HAProxy или другого load balancer-а, который умеет автоматически выводить сервера из ротации, в случае проблем.
То есть round-robin DNS в природе не существует, я вас правильно понял?
Ведь если есть LB, то он не нужен, а если он есть, то нет LB.

Тем не менее,

Round-robin DNS is often used to load balance requests between a number of Web servers.

CK>Про математику доступности и консистентности ты еще ничего не написал. Может наконец расскажешь как, по твоему, правильно считать/измерять?
Да без проблем, повторюсь:

Availability — это процент успешно выполненных запросов. Если у меня недоступно 1% диапазона ключей, то (в предположении равномерного распределения запрашиваемых данных) availability системы равна 99%.

CK>И как ты это понял? Уж не с помощью ли САР?

Нет, с помощью более приземлённых соображений.

CK>>>И консистентность там скорее всего достаточно поддерживать в рамках одной поездки, причем допустимо делать это пост фактум.
Я не понимаю, что вы имеете в виду под "пост фактум". То есть приехало две машины, но поскольку клиент сел только в одну из них, вторая будет сосать лапу постфактум?

CK>Я не утверждал, что для того, чтобы отправить машину на заказ, достаточно АР системы. Тут как раз нужна консистентность, поэтому если клиент начал вызов, но ДЦ, в котором он обслуживается, оказался отрезан от других, вполне нормально вернуть ошибку, чтобы избежать ситуации, когда водитель получает два заказа. Клиент может попробовать вызвать такси второй раз.
Ну, так о чём мы тогда спорим?

CK>Я предлагал использовать РА систему для регистрации событий поездки — начало, точки через которые проехал водитель, конец, оценка и тд. Тут возможна eventual consistency без конфликтов. Все сводится к записи данных в распределенное хранилище, причем данные могут быть представлены как CRDTs, поэтому даже если данные клиента пришли в изолированный из-за network partition ДЦ, запись можно выполнить через sloppy quorum и потом восстановить консистентность, после восстановления связи между ДЦ, довольно очевидным образом.
Ок, против этого я не возражаю. Осталось понять, почему мы, имея CAP-систему для назначения поездок, ограничиваемся PA-системой для регистрации прогресса поездки. А также понять, почему "отказ от consistency" не приводит к потере consistency.

Здравствуйте, netch80, Вы писали:

S>>отдельных компонентов и ненадежного канала мы можем построить надежную систему до каких-то там девяток -- 99.999(9).

N>Что можно строить надёжную систему — понятно, но чего я тут не понимаю — при чём тут одна конкретная теорема. (Кстати, если вспоминать историю открытия, то к ней Найквист имел больше отношения, чем Шеннон.)

Это был просто пример конкретной мат. формулы и чуть ли вообще не первой теоремы в этой области. Несолько весомее чем 2 из 3.

S>>Вопрос -- почему отсутствуют математические основания в теории распр. систем? Т.е. по сути аналогом теорем К.-Ш. является CAP, в которой отсутствует какие-либо
S>>количественных характеристики или формулы. Ну да, есть некий компромисс между C,A и P, выберите 2 из 3. Ну чего-то как-то не густо. Есть фундаментальные работы Лэмпорта по консенсусу еще в 70-80-х годах, но как-то единой теории с соотв. мат. аппаратом не появилось? Почему?
N>Наверно, потому, что тема сложная и никто пока не смог придумать, как оправдать что-то конкретными цифрами?
N>Или, другой вариант, потому, что цифры строить тупо не на чем.

Ога, вокруг полно цифр -- latency, MTTF и т.д., объем ОЗУ, ЦПУ и мы ничего не можем толково выразить через формулы.

N>Как тут далее в дискуссии было, если мы рассматриваем каждый ключ данных по отдельности, мы можем рассматривать теорему для него одного, не учитывая других; если же база данных, как в типичном реляционном подходе, это один неделимый объект с требованием атомарности для него, то рассматривается он в целом и опять же цифры некуда подключить.

N>Вот если кто-то заинтересуется вопросом темпа сходимости в подходах, когда отдельные данные могут "добегать"... вариант возможный, но уже отработанный.\

Не понял это утверждение.

Здравствуйте, Sinclair, Вы писали:

S>Ну, вот часть сложностей в этом разговоре ровно от того, что вы обсуждаете конкретную систему (о которой лично мне ничего не известно), а я говорю о теоретических соображениях.

я об этом сразу написал

S>То есть round-robin DNS в природе не существует, я вас правильно понял?
S>Ведь если есть LB, то он не нужен, а если он есть, то нет LB.

то поведение, которое ты описал, возможно только с round-robin DNS, очевидно, мониторить доступность описанным мной способом не получилось бы, если бы использовался round-robin DNS, очевидно, что подразумевается LB (который не отрицает RRDNS, но мониторинг может ходить в обход)
очевидно, без LB даже РА система, которая полностью доступна и работает штатно, будет частично недоступной для клиентов, так как в любой момент времени его может кинуть на временно недоступный узел

CK>>Про математику доступности и консистентности ты еще ничего не написал. Может наконец расскажешь как, по твоему, правильно считать/измерять?
S>Да без проблем, повторюсь:
S>

S>Availability — это процент успешно выполненных запросов. Если у меня недоступно 1% диапазона ключей, то (в предположении равномерного распределения запрашиваемых данных) availability системы равна 99%.

Ну и как ты это планируешь мониторить или считать? Пример — произошло разделение, половина клиентов видит одни 50% диапазона ключей, другая половина клиентов видит другие 50% диапазона ключей. Получается 100% доступность?

CK>>>>И консистентность там скорее всего достаточно поддерживать в рамках одной поездки, причем допустимо делать это пост фактум.
S>Я не понимаю, что вы имеете в виду под "пост фактум"
eventual constitency, очевидно же

CK>>Я предлагал использовать РА систему для регистрации событий поездки — начало, точки через которые проехал водитель, конец, оценка и тд. Тут возможна eventual consistency без конфликтов. Все сводится к записи данных в распределенное хранилище, причем данные могут быть представлены как CRDTs, поэтому даже если данные клиента пришли в изолированный из-за network partition ДЦ, запись можно выполнить через sloppy quorum и потом восстановить консистентность, после восстановления связи между ДЦ, довольно очевидным образом.
S>Ок, против этого я не возражаю. Осталось понять, почему мы, имея CAP-систему для назначения поездок, ограничиваемся PA-системой для регистрации прогресса поездки. А также понять, почему "отказ от consistency" не приводит к потере consistency.

Для назначения поездок мы используем PC систему, для регистрации прогресса РА систему.

Здравствуйте, Sinclair, Вы писали:

S>Ну, так-то всё верно. Любая функция вида y = A+B*e^(С+В*x) называется экспоненциальной. В том числе и эта

Это ты какие-то альтернативные формулировки придумываешь. Обычное определение экспоненциального роста тут.

Здравствуйте, chaotic-kotik, Вы писали:

CK>очевидно, без LB даже РА система, которая полностью доступна и работает штатно, будет частично недоступной для клиентов, так как в любой момент времени его может кинуть на временно недоступный узел
"PA-система" — это плохой термин, т.к. он не означает ничего конкретного. Как, например, в данном случае — мы вроде бы отказались от C, а PA тем не менее не получили.

CK>Ну и как ты это планируешь мониторить или считать? Пример — произошло разделение, половина клиентов видит одни 50% диапазона ключей, другая половина клиентов видит другие 50% диапазона ключей. Получается 100% доступность?
Если клиенты А обращаются только к ключам первой половины, а клиенты Б — только к ключам второй половины, то да, неожиданно availability будет равна 100%.
Давайте займёмся арифметикой. У нас есть 4 типа запросов:
1. Клиент A, ключ 1
2. Клиент A, ключ 2
3. Клиент Б, ключ 1
4. Клиент Б, ключ 2.

Допустим, при разделении у нас начинают фейлиться запросы типов 2 и 3, а запросы типов 1 и 4 продолжают работать.
Полная availability у нас равна доле успешных запросов — то есть надо просто сложить доли запросов 1 и 4.
Если все обращения к ключам равновероятны, то availability будет 50%.
Если же у нас разделение данных выполнено грамотно, то "местные" запросы составляют, скажем, 90%. В таком случае даже после разделения система останется 90%-available.
Для того, чтобы получить четыре девятки общей availability, такого partitioning-а можно себе позволить ажно 520 минут в году.

CK>>>>>И консистентность там скорее всего достаточно поддерживать в рамках одной поездки, причем допустимо делать это пост фактум.
S>>Я не понимаю, что вы имеете в виду под "пост фактум"
CK>eventual constitency, очевидно же

CK>Для назначения поездок мы используем PC систему, для регистрации прогресса РА систему.
Ок, хорошо. Какая именно consistency нам нужна в системе назначения поездок? Далее — раз мы отказались от consistency для регистрации прогресса, то, наверное, должны получаться артефакты неконсистентности, так?
Если да — то какие? Если нет, то почему? Я — продакт менеджер, вы мне продаёте архитектуру системы. Переведите вот эти вот PC и PA на понятный мне язык.

Здравствуйте, Lexey, Вы писали:
L>Это ты какие-то альтернативные формулировки придумываешь. Обычное определение экспоненциального роста тут.
Да, вы правы.

Здравствуйте, Lexey, Вы писали:

L>Здравствуйте, Sinclair, Вы писали:

S>>Ну, так-то всё верно. Любая функция вида y = уA+B*e^(С+В*x) называется экспоненциальной. В том числе и эта

L>Это ты какие-то альтернативные формулировки придумываешь. Обычное определение экспоненциального роста тут.
Такая формула:
y = p^x
Вероятность работоспособности системы из x узлов при вероятности p работоспособности одного узла. Укладывается в формулу из вики как влитое. Так что типичная экспоненциальная зависимость. А переход от вероятности работоспособности к вероятности отказа — это просто немного разные формулировки того же самого.

А y = A+B*e^(С+В*x) переписывается как A+B*e^C*e^B*x
что из формулы
y=a*e^k*x
следует что константа a=B*e^C и константа k=B
А A это просто константа при производной.

	От:	Lexey
	Дата:	12.09.19 14:57
	Оценка:

	От:	artelk
	Дата:	12.09.19 15:12
	Оценка:	+1

От:	Sinclair	https://github.com/evilguest/
Дата:	13.09.19 05:30
Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	13.09.19 05:54
Оценка:

От:	netch80	http://netch80.dreamwidth.org/
Дата:	13.09.19 06:06
Оценка:

	От:	chaotic-kotik
	Дата:	13.09.19 09:32
	Оценка:	1 (1)