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

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

S>>>Другая подобная теорема и т.д. Т.е. куча людей разрабатывают системы, которые работают, разрабатывались с оглядкой на CAP и вдруг хоп, все делают не так. И никакой вменяемой альтернативы не сформулировано, критика есть, альтернативы нет.
G>>Почему нужна именно теорема? Есть SOA с кучей стандартов построения отказоустойчивых систем, есть REST со своей формулированной семантикой.

S>Необязательно, но в данной теме проводится сравнение теории информации, и ее мат. обеспеченность, между теорией распределенных систем и ее полным отсутствие мат. обеспеченности в купе с неудовлетворительной CAP теоремой.
S>Все-таки странно сравнивать REST и CAP. Кстати, REST стал возможен благодаря вообще удачной web архитектурке в целом.
Не надо искать смвсл там где его нет. CAP и теория информации не связаны.
Более того, CAP доказывается в формальной модели, отличающейся от рельного мира, поэтому практическая полезность равна нулю.
Диссертация Филдинга ориентирована на реальный мир и практическая полезность максимальная.
Почему их нельзя сравнивать? Их сравнивать нужно.

S>>>На что конкретно в этой работе советуете обратить внимание -- идеи мысли и т.д.?
G>>На все. Там намного больше, чем вы себе представляете.
S>Ну можно хотя бы пример на что обратить внимание, помимо REST? Что показалось любопытным при первом знакомтве, на что внимание обратили?
Реально на все:
Первая глава — что такое архитектура и её составные части.
Вторая глава — архитектуры сетевых приложений, какие бывают
Третья глава — способы взаимодействия в сетевых приложениях
Главы 4-6 — собственно REST

Причем внезапно сам филдинг не ставит знак равенства между REST и WWW, хотя утвреждает что HTTP максимально подходит для REST (он вообще много для чего подходит).

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

S>Почему тогда до сих пор нету альтернативы? Другая подобная теорема и т.д. Т.е. куча людей разрабатывают системы, которые работают, разрабатывались
S>с оглядкой на CAP и вдруг хоп, все делают не так.
Вы телегу впереди лошади ставите. Сначала появилось куча распределенных систем и NoSQL, а уже потом, как объяснение того, почему они так херово работают, маркетологи придумали CAP теорему. Мол, то чего вы хотите — теоретически не возможно, поэтому успокойтесь уже.
Никто, ничего с оглядкой на CAP не разрабатывал и не разрабатывает. Собственно, это и объясняет, и отсутствие каких-либо параметров и практическую неприменимость этой теоремы.

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

DI>Что такое чистый шардинг?

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

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

DI>>Это демагогия — выражение "все в мире компромисы" не верно, так как бескомпромисно.

I>Вот так плюрализм, и всё в одной голове!

Я так понимаю принять участие в дискуссии интеллект не позволяет, но высказаться очень хочется? На здоровье, но кормить тролятину не буду. Свободен.

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

G>Простой пример. Кластер из трех БД — все они делают синхронную репликацию на два других узла. Синхронная репликация считается успешной когда хотя бы один узел ответил ОК.
G>Происходит разделение, один узел теряет возможность общаться с другими.
G>Как сильно упадет доступность системы в таком случае?
G>Правильный ответ — никак.

G>У нас получается система консистентная, доступная и устойчивая к разделению? По логике обывателя — да. По логике CAP — нет (внезапно).

Ну как же, если у тебя скажем не хватает одной записи в таблице в БД №1, но она есть в БД №2, а БД №3 недоступна, ты не сможешь определить, была запись удалена, либо добавлена. Скажем, у тебя возможна ситуация, когда одна БД №1 моргнула, на БД №2 пришел запрос на удаление/добавление, он отработал, синхронно реплицировался на БД №3, после чего БД №3 стала недоступна из-за разделения.

Чтобы система была консистентной, тебе нужно читать кворум, а не одну БД. Если ты будешь это делать, то обнаружишь, что у тебя доступность таки упала, так как в вышеописанном случае, тебе придется вернуть ошибку.

G>Только системы CP системы применимы в реальной жизни, а за исключением единичных примеров вроде DNS (классическая AP система).

oh boy oh boy

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

S>>Нет. Здравствуй CAP появляется только при борьбе за Availability.
·>Или в борьбе за Consistency.
Нет. Consistency проще лёгкого обеспечить безо всякого CAP. На одном узле.

S>>Без неё я могу запросто распилить систему по горизонтали — пусть Москву обслуживает Московский сервер, а СПБ — Питерский. Делов-то.
·>Осталось определить какие бизнес-требования у московских клиентов читать-менять данные Питера. Кстати, если московские и питерские данные вообще не пересекаются, то у тебя нет никакого P, это две отдельные системы и можно иметь вообще C+A.
Ну это нам тогда повезло. В рамках задачи у нас нет возможности сегментировать клиентов — каждый запрашивает любые данные. Мы просто умеем их роутить куда нужно (см. тж. "шардинг").

·>А можно сделать так, чтобы Московский имел копию данных Питера и кешировал у себя модификации на случай пропадания связи. Тогда A нарушаться не будет, зато будет нарушаться C.
Ну вот о том и речь, что масштабирование прекрасно достижимо безо всяких CAP ограничений. И только когда мы хотим получить A, то внезапно начинает действовать CAP и негативно влиять на C.
И опять — проблема ровно в том, что без количественных характеристик разговор бесполезен. Есть много разных определений C, кроме самой жёстко-хардкорного. И они вполне применимы на практике; и система, неконсистентная с т.з. CAP вполне консистентна с точки зрения бизнеса. И определений A тоже можно ввести много разных, а не просто обязанность любого узла быть мгновенно достижимым в любой момент времени. И тоже окажется, что недоступная с т.з. CAP система вполне себе доступна с точки зрения бизнеса. И выбор — вовсе не между C и A, а между разными степенями С и А, с учётом ожидаемой частоты и длительности P.
·>ЗЫ Что здесь значит "S" я не понял.
Scalability.

Здравствуйте, Denis Ivlev, Вы писали:
DI>И что я подменил?
С вопроса "принципы масштабирования failover cluster" мы переходим к вопросу разработки всеобъемлющей архитектуры с неизвестными заранее требованиями по масштабу, временам отклика, надёжности, и функциональности.
DI>И это так.
DI>Нет, не показали.
Ну, то есть вся ветка была напрасной.
DI>Обсуждение есть, а подтверждения твоим словам нет.
DI>Все? Ожидаемо оказался заборот САР, "чистый шардинг" сдулся. Ну и стоило ли упрямствовать?
Если вас интересует математическое обоснование построения CAP-системы, то лучше всего почитать работу про совмещение real-time causal consistency с always-on availability. Это гораздо более интересный результат, чем CAP.

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

S>>Во-первых, сведя всё к одному серверу, А вы не получите, как я уже упомянул. Вы её не улучшите, а ухудшите.
·>Ты не понял. На серваке работает алгоритм, который обладает CA-свойством. Однонодовая система принципиально разделяться не может.
Это просто означает, что данное определение "CA-свойства" неприменимо на практике. Получается, что в CAP какая-то странная Availability: в однонодовой системе A нет, а по CAP получается что есть.
А в реальных многонодовых системах наоборот — A есть, а с точки зрения CAP — нету. Нуинахрена?

·>В CAP разделение это потеря сообщений. Потеряли, а потом нашли что-ли?
Конечно. Вы же в курсе, как работает TCP?

·>Т.е. ты описал CP-систему. Об чём спор-то?
О том, что CAP не позволяет нам сделать никаких выводов относительно возможности построения такой системы.

·>Я не знаю что ты имеешь в виду. Алгоритм обладает двумя сложностными характеристиками — пространство (память) и время (макс число операций). Я не имел в виду физическое время. В контексте O-нотации по-моему очевидно какое время имеется в виду. Под "Быстрее" я имел в вмиду требует меньше времени.
Я подробно написал, что имею в виду. Ваше понимание термина "быстрее" и термина "время" по-прежнему показывает разницу между подходами инженера и математика: когда инженер говорит о скорости, он имеет в виду "календарное" время — то есть response times, а не number of operations. Второе его тоже интересует, но как независимая величина, которая влияет на энергопотребление.
А вы смешиваете их в одну кучу. Даже если лично вы всё время помните о том, что ваше "время" — это не время, то все остальные, кто читает ваши утверждения, понимают их превратно.
Заметьте, что в оригинале, на который вы сослались, терминов "время" и "скорость" нет. Там честно написано про количество операций — именно потому, что профессионалы знают между ними разницу.

·>Ок, если это спор о полезности, то я сдаюсь. Полезность вещь чисто субъективная, о вкусах не спорят.
Не, объективная. Ваша теорема о невозможности вечных двигателей запрещает очень узкий класс двигателей.
А теорема Карно позволяет отсеять также даровые двигатели и вечные двигатели второго рода.

·>И дальше что? Сетевые карточки будет обслуживать сервак, который внезапно может перестать отвечать, по обоим проводам.
Это не является partition в терминах CAP. Вы же сами только что цитировали — там речь про потерю пакетов. Если у нас нагнулся сервер, это совсем другая проблема, и она совершенно по-другому влияет на consistency.

IB>>а это не правда

AK>Я попытался себе представить все три из трех, C + A + P, и это сломало мне мозг. Я не могу представить систему, которая во фрагментированном состоянии была бы одновременно консистентна и всегда доступна.

Проблема в CAP в том что она бинарная: или-или, по другому никак. Во всяком случае, в том виде как ее все пишут: CAP, выбери любые два. Eventual consistency уже нарушает CAP: система таки становится консистентной.

Вторая проблема, что ее всегда описывают только с технической стороны зрения.

На практике для всех трех параметров есть границы дозволенности. Если данные станут консистентными через 4 недели и бизнесу это не мешает, то с точки зрения бизнеса это нормальный уровень консистентности. Если ответ придет не через 1 миллисекунду, а через 2 минуты, это вполне может быть available с точки зрения бизнеса. В итоге бизнес выдвигает требования и границы дозволенности и системы обычно проектируются в стиле «90% узлов должны быть доступны 98% времени с временем отклика 30-200ms. Запись данных должна выполняться в узлы A-N с времененм отклика в пределах 400ms. Чтение — с узлов C—Q с временем отклика в пределах 300ms, мы согласны если данные рассогласованы в течение 1200ms» и т.п.

Здравствуйте, chaotic-kotik, Вы писали:
CK>И для сервисов, которые должны работать постоянно, в контексте дискуссии нас именно это интересует, ты сам начал рассуждать про "пять девяток", а теперь утверждаешь что это для электростанций :D
Вот мы сидим и долбим какую-то систему ежесекундными запросами. Из них часть завершается успешно, часть падает с таймаутом или 503. (простейший пример — ping -t).
Каким образом вы от лога результатов перейдёте к "минутам" и "продолжительности инцидентов"? Ну, чтобы вычислить availability?

CK>Еще раз. Ты это _неправильно_ понимаешь. В АР системе, работающей в нескольких ДЦ, при сбое одного ДЦ, все данные будут доступны. Нормальной практикой является периодическое отключение ДЦ, в рамках тестирования боевой инфраструктуры на resiliency, например.

S>>Что такого умного вы сможете сделать, зная CAP, чего вы не могли бы, не имея доказательства CAP?

CK>С помощью CAP я могу понять, что у меня есть трэйдоф, я могу обеспечить целостность (linearizability) или доступность.
Не-не-не, вот эти все "я могу понять, что у меня есть трэйдоф" — не надо. Вы привели конкретный пример — покажите, как именно вы применяете CAP в решении задачи.

CK>"Ближе к пользователю", это когда у тебя есть три ДЦ, в каждом из которых крутится web frontend, который берет/кладет данные в Cassandra. Cassandra при этом крутится в каждом из этих ДЦ и в каждом из них есть копия всех данных. Недоступность одного из ДЦ не приводит к простою (все товары из БД доступны).
CK>Это пишет человек, который всего несколько сообщений назад рассуждал про "требования бизнеса". У тебя чувак из Нидерландов может заказать что-нибудь в Китае, находясь при этом в Южной Америке. В данном случае, поддержка подобной распределенной архитектуры, это продуктовое решение.
Ну так расскажите, зачем вам в этой задаче "ближе к пользователю". Если у вас именно продакт решает, сколько будет DC, то это очень странно. Может, он заодно и СУБД за разработчиков выберет, и ЯП?

CK>Временем респонза в интернет магазине пренебречь нельзя. Особенно, если у этого магазина есть не только веб морда, но еще и мобильное приложение. Требования к latency в данном случае, это тоже решение продакта, а не программиста.
Ну ок. Я, как продакт, пишу вам latency в пределах 2500мс. Вам уже очевидно, что в него укладываются раундтрипы через весь шарик и обратно?
CK>Для этого как раз пригодится САР.
Как именно? Ждём примера.

Здравствуйте, Sharov, Вы писали:
S>А есть какая-то методолгия расчета девяток, т.е. мы должны учесть каждый узел компонент и т.д., выбрать наименьшее и т.д. ? В контксте availability.
Ну, как — берём MTBF и MTTR, и считаем (MTBF-MTTR)/(MTBF).
Если у нас есть статистика обработки запросов, то считаем СountSuccessful/CountTotal.

Публичной математики на эту тему почему-то очень мало. Например, в SRE Book основное внимание уделено рассуждениям, а не формулам расчёта.
Тем не менее, почитать их главу про борьбу с Consistency и Availability крайне интересно: https://landing.google.com/sre/sre-book/chapters/managing-critical-state/

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

CK>ты просто не понимаешь САР
Да я и не претендую )
Собственно, обсуждаемая проблема ровно в том, что ее в принципе мало кто понимает, но все носятся с ней как с откровением. Как следствие, практического применения от этой теоремы — только вред.

CK>Ерунду он там написал, хотя бы потому что он SLA путает с availability.
CK>availability в САР это не возможность обработать 100% запросов,

"Availability: Every request receives a (non-error) response" (c)

Иными словами, таки 100%.

CK> у нас СР система может обработать 100% запросов если нет упавших узлов, прикажешь считать такую систему CAP системой?
Для начала я предлагаю определиться, что считать "упавшим узлом".

CK> Это полный бред
Однако именно так эта теорема большинством и понимается.

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

CK>Если исходить из ситуации, что у нас есть кворум (набор машин, в которые нужно записать) и происходит сбой или партишн, то можно быстро дойти до выводов САР.
До выводов CAP можно дойти даже без партишенов. Эти выводы известны со времен первых баз: если с диска считалась какая-то фигня, то есть всего два варианта — либо отдать эту фигню, либо вернуть ошибку.
А теперь самое интересное — во времена локальных баз, сбой диска явление крайне редкое, поэтому выбор в пользу "consistency" был настолько очевидным, что никакой "теоремы" придумывать не пришлось. Однако, когда дисков стало несколько — вероятность сбоя сильно возросла, однако возросла и вероятность вернуть что-то внятное, не смотря на сбой... И возникла необходимость выбора. Но выбор, который предлагает САР плох тем, что он во-первых, не дает никаких ориентиров, когда и что выбирать, а во-вторых, внушает мысль, что выбор делать необходимо, даже когда на самом деле не надо.

CK>Теперь вопрос, что тут можно измерять численно?
Численно можно измерять кучу всего. Что считать сбоем? При каких требованиях к доступности необходимо жертвовать консистентностью? И когда наоборот? и так далее..

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

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

CK>>Ерунду он там написал, хотя бы потому что он SLA путает с availability.

S>Почему SLA не может выступать количественной характеристикой availability?

Потому что SLA шире. SLA зависит например от поставщика электричества, надежности upstream канала твоего дц и тд.

Availability в CAP — это свойство алгоритма. Это аналог сложности алгоритма или lock free/wait free гарантии в многопоточном программировании. Там ты тоже на практике можешь получить ситуацию, когда lock free алгоритм заблокировался, например в случае priority inversion, или O(N) будет быстрее чем O(LogN). С А в САР та же история. Это просто гарантия. Скажем, если ты читаешь данные без кворума, при этом у тебя РА система и ты приконнектился к отвалившемуся от кластера узлу — у тебя будет stale read. У тебя tradeoff, либо разрешить stale reads (РА), либо оказаться в ситуации, когда в случае, когда у тебя кластер развалился и нет кворума, ты не сможешь прочитать (PC).

При этом в остальное время у тебя вообще другой трейдоф — позволить некоторую неконсистентность (eventual consistence) чтобы работало быстрее, либо поддерживать строгую консистентность всегда, но платить за это вычислительными ресурсами. Про это есть PACELC теорема.

Здравствуйте, 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, и с какими параметрами надо резервировать.
К сожалению, вот именно эта часть их системы публичного освещения не получила

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

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

IB>Поинт в том, что прежде чем представлять, надо сначала определить, что значит "консистентна" и что значит "доступна". И внезапно окажется, что при консистентности Х и доступности Y, возможно и С и А и P и еще и Z в придачу. Иными словами, утверждение CAP — ложно.

ты просто не понимаешь САР

IB>Более подробно и с примерами Антон ответил тут: http://rsdn.org/forum/db/7518063.1

Ерунду он там написал, хотя бы потому что он SLA путает с availability.
availability в САР это не возможность обработать 100% запросов, у нас СР система может обработать 100% запросов если нет упавших узлов, прикажешь считать такую систему CAP системой? Это полный бред, т.к. CAP описывает поведение во время сбоя.
Если исходить из ситуации, что у нас есть кворум (набор машин, в которые нужно записать) и происходит сбой или партишн, то можно быстро дойти до выводов САР. Скажем, кворум = 3, ты хочешь записать, записать можно только в 2 места из 3х (один узел упал), если ты записал в 2 — неконсистентность, если ты говоришь что операция записи невозможна — ты сохраняешь консистентность, но теряешь доступность.
Происходит партишн и скажем все 3 машины, нужные для кворума недоступны. Ты можешь задействовать hinted handoff (теряешь консистентность) или выдать ошибку (теряешь консистентность).
Теперь вопрос, что тут можно измерять численно?

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

IB>Собственно, обсуждаемая проблема ровно в том, что ее в принципе мало кто понимает, но все носятся с ней как с откровением. Как следствие, практического применения от этой теоремы — только вред.

а в чем заключается вред?

CK>>Ерунду он там написал, хотя бы потому что он SLA путает с availability.
CK>>availability в САР это не возможность обработать 100% запросов,
IB>

IB>"Availability: Every request receives a (non-error) response" (c)

IB>Иными словами, таки 100%.

я там хотел сказать, что система, которая обрабатывает вот прямо сейчас 100% запросов не обязательно является available в терминах САР

CK>> у нас СР система может обработать 100% запросов если нет упавших узлов, прикажешь считать такую систему CAP системой?
IB>Для начала я предлагаю определиться, что считать "упавшим узлом".

в терминах САР, упавший узел просто не отвечает на запросы

CK>> т.к. CAP описывает поведение во время сбоя.
IB>Совершенно верно, но она не дает определение сбоя.
IB>Надеюсь теперь проблема понятна? CAP оперирует набором терминов, которые каждый понимает по своему. В итоге делаются совершенно странные выводы, не имеющие ничего общего с действительностью.

САР описывает поведение модели, не реальной системы.
Узел, это атомарный регистр, поддерживающий две операции put(value) и get().
Сonsistency означает, что регистр работает так, как если бы он был единственным, а не распределенным (все изменения атомарны и линеаризуемы, если мы сделаем put(1) put(2), а потом get(), get всегда вернет 2).
Асинхронная сеть, это модель, в которой сообщения могут теряться, или доставляться за какое-то неопределенное, но ограниченное время.
Network partition не ограниченн по времени, соответственно, корректный алгоритм когда-нибудь завершится в случае задержек, в случае, если он не может обработать network partition — он не завершится никогда.
Это все не имеет прямой связи с реальностью, это изначально упрощенная модель, но ты не сделаешь распределенную систему, которая обходит ограничения САР, поэтому ее нужно понимать все равно.

Поэтому в этом обсуждении, очевидно, что многие не понимаю САР, потому что они атакуют те выводы, которые с помощью САР сделать нельзя.

CK>>Если исходить из ситуации, что у нас есть кворум (набор машин, в которые нужно записать) и происходит сбой или партишн, то можно быстро дойти до выводов САР.
IB>До выводов CAP можно дойти даже без партишенов. Эти выводы известны со времен первых баз: если с диска считалась какая-то фигня, то есть всего два варианта — либо отдать эту фигню, либо вернуть ошибку.

Это не имеет отношения к САР. Ни диск, ни фигня, которая с него считалась. Как можно говорить о САР, когда у тебя одна машина?

IB>А теперь самое интересное — во времена локальных баз, сбой диска явление крайне редкое, поэтому выбор в пользу "consistency" был настолько очевидным, что никакой "теоремы" придумывать не пришлось. Однако, когда дисков стало несколько — вероятность сбоя сильно возросла, однако возросла и вероятность вернуть что-то внятное, не смотря на сбой... И возникла необходимость выбора. Но выбор, который предлагает САР плох тем, что он во-первых, не дает никаких ориентиров, когда и что выбирать, а во-вторых, внушает мысль, что выбор делать необходимо, даже когда на самом деле не надо.

Опять же, во времена локальных баз нельзя было выбирать, потому что ты в принципе не можешь получить неконсистентность, как ее понимает САР.
Не важно, кажется ли тебе выбор, который предлагает сделать САР правильным или не правильным, тебе его придется сделать, так или иначе. Это фундаментально ограничение, которое не обойти.

IB>Численно можно измерять кучу всего. Что считать сбоем? При каких требованиях к доступности необходимо жертвовать консистентностью? И когда наоборот? и так далее..
"Что считать сбоем" можно выразить числом?

В рамках САР, если у тебя есть N узлов и происходит network partition, который делит их на две части, ты пытаешься прочитать значение, но тебе доступна только половина узлов, соотв. ты можешь либо прочитать то что доступно (PA) либо выдать ошибку (PC). Эта ситуация легко транслируется на реальные системы. Соотв. вопрос. Что здесь численно измерять? Что здесь может быть неверно? Почему ты считаешь что тут выбор делать может быть не нужно?

Здравствуйте, ·, Вы писали:
S>>·>Availability: Every request receives a (non-error) response – without the guarantee that it contains the most recent write
S>>Очевидно, тем, что не учитывает Scalability вовсе никак, что противоречит вашей формуле в посте выше.
·>Scalability это аспект availability. Т.е. возможность системы оставаться available при growing amount of work путём adding resources.
И тем не менее, в ваших определениях это никак не связано. Availability в вашей формулировке всего лишь требует получать ответ на каждый запрос — при этом нет никаких временных рамок; это означает, что при росте нагрузки можно наращивать время ожидания результата безо всяких дополнительных телодвижений.

·>Зуб даёшь? 1млрд запросов даже в сетевой проводок даже супер-пупер сервера не влезут, поэтому запросы тупо потеряются и ты не сможешь дать ответ даже через 100500 миллиардов лет.
А с чего вы взяли, что мы собираемся запихивать этот миллиард запросов в один сетевой проводок?
У нас же не один клиент генерирует этот миллиард запросов, так? Ну вот у нас миллион клиентов делает по 1к RPS, которые приземляются на 100к прокси серверах, и каждый принимает всего лишь по 10к RPS.
Запросы лежат в очереди, и прокси выполняют их через тот самый 1 сервер. Никаких принципиальных проблем с CAP тут не возникает.

·>"Хранят"? В смысле RO-система? В этом случае CAP как-то не в тему. Ибо эта теорема рассматривает RW.
Почему RO? Вполне себе RW. Просто нам заранее известно, что ваш счёт лежит на сервере №110, а мой — на сервере №465. Поэтому когда у нас идёт команда пополнить мой счёт на 1000р, то она приземляется в мой сервер, а ваша — в ваш.
·>Вот когда ты на этом миллионе серверов захочешь сделать какой-то алгоритм, например, "перевести деньги со счёта на счёт без овердрафта", то у тебе придётся делать выбор C либо A.
Я вас разочарую, но в CAP нет ничего про multi-node updates. Это раз.
Два — если бы мы реально делали систему с транзакциями типа "перевести деньги со счёта на счёт", то под availability мы бы не стали понимать "100% ответов", т.к. такой показатель недостижим даже безо всяких Partition просто в силу ненадёжности аппаратуры. Мы бы с вами имели требования к Availability вроде 99.9%, при чём под ней бы понималось не просто "успешное завершение запроса", а что 99.9% запросов укладываются в 30 секунд.
И тут внезапно CAP теряет всякую полезность — потому что из неё непонятно, достаточно ли такого ограничения availability, чтобы получить consistency, или нет?
Нужно ли нам разрешить овердрафты иногда? На всякий случай напомню, что в реальных card processing systems овердрафты являются частью нормального функционирования

И реальный бизнес вполне может сказать "ну ок, овердрафты в пределах 1% от остатка на счетах не являются для нас проблемой".

S>>Конечно же удастся. Потому что результат зависит от того, что мы называем C, а что A. И тогда я буду иметь и C, и А одновременно даже в случае P.
·>Как можно нарушить математически доказанную теорему? Ну да, можно так сказать... просто нарушить предусловия теоремы или дать другое толкование терминам.

И что?
И то, что формулировки C и A, выбранные в доказательстве этой великой теоремы, не имеют практической применимости. На практике, нас не интересует ни та A, которая там выбрана, ни C.

S>>Очень интересно. Ок, а для 1 миллиона RPS можно построить CA-систему? А для 1 тысячи? Ок, ну, хотя бы для 1 запроса в 10 секунд — можно ли построить CA — систему?
·>Можно, конечно, на нашем уровне развития техники, но не будет P (т.е. ровно один узел).
Вы что, полагаете, что 1 узел вам даст возможность получить ответы на 100% запросов? Прямо на все-все 100%? И питание у него не пропадает никогда, и железо не сыплется? Апдейты на него не ставят никогда, да?

S>>Если да, то как? А если нет, то почему вы пишете "в таком сценарии" — что в этом сценарии такого особенного?
·>Я просто хотел сказать, что для 1млрд физически невозможно построить без P. Нет такого железа у нас.
И для 0.001 RPS тоже нет такого железа, чтобы получить C, A, и P.

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

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

Мне кажется тут влияет знание не теорем, и CAP в частности, а знание/понимание предметной области, с ее конкретной (естественной) кластеризацией данных/сущностей, понимание требований к системе.

И соц. сети в большинстве своем тут являются плохим примером системы для которой достаточно быть иногда консистентной. Здесь скорее важнее социальные аспекты: что бы пользователь всегда получали доступ (но не обязательно видели последнее состояние чужих сущностей), а так же всегда наблюдали реакцию на собственные действия (лайк ставится и наблюдаем, написанный свой комментарий — тут же видим, а тот факт, что он на другом конце земли будет виден через пол часа и утонет в ленте — это вообще не важно).

И когда, такое понимание предметной области есть — то можно выбрать и подходящее решение. Если для операции требуется ACID — то его придется обеспечить.

Транзакции/учет баланса тоже пример хороший, он, в решениях в лоб — требует ACID. Но доступ к балансу пользовательского счета в 99.9% — неконкурентный, что, с некоторыми ограничениями, допущениями и в конце концов закладываемыми рисками — можно использовать, и обеспечить выполнение транзакции на разделенной системе вплоть до полной суммы. (Под некоторые ограничения, я например, отвожу транзакцию с чипованной картой, где существует монотонный счетчик транзакций, как одна из возможных точек опоры. А под заложенные риски — это недосчитаться денег на балансе, и потом изыскивать способ их вернуть, хотя, при нормальных взаимоотношениях клиента и банка это вообще не проблема.)

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

DI>И как это горизонтально масштабируется?
А при чем тут масштабирование и какое это все имеет отношение к обсуждаемому вопросу? Предлагаю не путать теплое с мягким и с фокусироваться на availability и consistency в терминах CAP. Масштабирование — это другой вопрос, к CAP отношения не имеющий.

DI>Никак что-ли? А зачем оно тогда надо?
А это уже вообще вопрос третий. Слово failover в названии решения как бы намекает на то, что это про availability. А scalability — это уже 4-я буква в уравнении, которой тоже не плохо бы дать определение. В данном случае решение уже с масштабировано, но это масштабирование сделано не с целью увеличить пропускную способность, а с целью дать внятный ответ с большей гарантией.
Если достать голову из мира где в угоду быстрому ответу приносится в жертву вообще все, то failover кластера придумали вовсе не от скуки, а потому что такие решения тоже очень востребованы. И, что характерно, они как раз про доступность. С другой стороны, возвращаясь к теме топика, являются ли такие решения доступными в терминах CAP? Да фиг знает, но с точки зрения формального доказательства скорее нет. Являются ли такие решения доступными в практическом плане? Однозначно да, их доступности и одна машина позавидовать может, так как они отвечают не только при сетевом сбое, но и при любой другой проблеме с одним узлом. Более того ответ такой системы всегда консистентен, то есть в практическом смысле это CA система.
Утверждать что такие системы не нужны — смело, но глупо.

CAP дает возможность классифицировать распределенные системы (CA, CP, AP в http://ru.wikipedia.org/wiki/%D0%A2%D0%B5%D0%BE%D1%80%D0%B5%D0%BC%D0%B0_CAP и пункты 3.2.1 — 3.2.3 в http://lpd.epfl.ch/sgilbert/pubs/BrewersConjecture-SigAct.pdf). Но эти классы распределенных систем являются крайними случаями. Реальные системы или их части могут занимать промежуточное положение или быть гибридными. Так как:

Consistency — в теореме сформулировано требованием, того чтобы во всех вычислительных узлах в любой момент времени данные не противоречат друг другу. То есть устаревание кэша узла распределенной БД не допускается. На практике считается допустимым и даже необходимым, если конечные пользователи видят устаревшие данные. Если данные на мониторе будут меняться 20 раз в секунду, пользователю это не понравится. Но слишком устаревшие данные тоже плохо. Так что это требование на практике не формализуемо, завит от того какие именно данные имеются ввиду и кем они используются. Если из за использования устаревших данных была произведена некорректная транзакция, то такая транзакция откатывается. На практике это допустимо.

Availability — в теореме сформулировано требованием, того чтобы любой запрос к распределённой системе завершается корректным откликом. Это означает, что если удаленный ресурс не может выполнить запрос он должен сказать об этом, а не молчать. На практике на запросы к удаленным ресурсам ставятся таймауты. Если сработал таймаут пользователю либо предлагается сделать запрос позже, либо запрос ставится в очередь и с заданным интервалом времени делаются повторные попытки сделать запрос.

Partition tolerance — расщепление распределённой системы на несколько изолированных секций не приводит к некорректности отклика от каждой из секций. Это значит, что если вы записали в одну из изолированных секций (секция — это множество узлов, между которым есть связь), а в другой секции потом читаете, Вам должны четко сказать что чтение в данный момент невозможно (жертвуем Consistency, класс AP) или задержать ответ пока связь между секциями не восстановится (жертвуем Availability, класс CP). На практике для одних данных допустим один вариант, для других другой.

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

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

S>>И тем не менее, в ваших определениях это никак не связано. Availability в вашей формулировке всего лишь требует получать ответ на каждый запрос — при этом нет никаких временных рамок; это означает, что при росте нагрузки можно наращивать время ожидания результата безо всяких дополнительных телодвижений.
·>Не понял что за рамки имеешь в виду. Вообще-то, timeout error это тоже error в терминах Availability. Наращивать сколько конкретно? Хинт: O(∞) — оксюморон.
Я имею в виду как раз величину таймаута. Я вижу, вы уже понимаете, что без таймаута говорить об availability никакого смысла нет.
И, что ещё лучше, вы готовы к конструктивному разговору: насколько именно придётся наращивать таймаут в зависимости от объёма данных.
Это прекрасно, это именно то, чего я хочу. Но для такого разговора придётся отказаться от CAP и перейти к чему-то более серъёзному, типа Service Reliability Engineering.
CAP вам в этом никак не поможет, т.к. она не оперирует ни привычными нам параметрами A, выраженными в %, ни таймаутами, ни MTTR, ни replication delay.

S>>Запросы лежат в очереди, и прокси выполняют их через тот самый 1 сервер. Никаких принципиальных проблем с CAP тут не возникает.
·>В очередях бесконечной длины? Круто чё. Если ты не просёк, то мы рассматриваем не обработку 1млрд запросов, посланных за секунду, а систему, способную обрабатывать 1млрд запросов в секунду.
Вы как-то произвольно прыгаете между математической абстракцией (миллиард RPS) и практической реализацией. Если вы хотите переводить разговор в практическую плоскость, то я вам отвечу, что и породить такое количество запросов будет затруднительно.

·>И пока какой-то из этих серверов лежит, система неконсистентна или недоступна. ЧТД.

Ну, а теперь заменим каждый сервер на failover cluster.

S>>·>Вот когда ты на этом миллионе серверов захочешь сделать какой-то алгоритм, например, "перевести деньги со счёта на счёт без овердрафта", то у тебе придётся делать выбор C либо A.
S>>Я вас разочарую, но в CAP нет ничего про multi-node updates. Это раз.
·>Там есть о взаимоотношении R и W _одного_ регистра. Т.е. случаи "пишем в X, читаем Y" или "пишем в X, пишем в Y и никогда ничего не читаем" или "читаем X и читаем Y" — это не то что описывает теорема, да и на практике нечасто встречается.
Ну так вы-то хотите "пишем X и Y", а это — вовсе не один регистр.

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

CAP об алгоритмах, а не об аппаратуре.

S>>Нужно ли нам разрешить овердрафты иногда? На всякий случай напомню, что в реальных card processing systems овердрафты являются частью нормального функционирования

S>>И реальный бизнес вполне может сказать "ну ок, овердрафты в пределах 1% от остатка на счетах не являются для нас проблемой".
·>Да, т.е. AP-система, объясняем бизнесу что C может нарушаться. И? К чему ты клонишь?

·>А теорему не интересует что вас это не интересует. Теорема — это теория, а не практика. Например, есть теорема о том, что алгоритм сортировки нельзя сделать быстрее чем O(n*log(n)). И тут приходят "практики" и "опровергают" теорему: "а у нас тут поразрядная сортировка", "а у нас тут много ядер", "а у нас тут такие данные".

Отличный пример, как раз в тему дискуссии. Я не очень хочу отвлекаться от CAP, поэтому ограничимся иллюстративными рассуждениями.
1. Вы подменяете утверждение "меньше чем за n*log(n) сравнений" утверждением "быстрее, чем за O(n*log(n))". Скорость — это время (количество тактов), она не равна количеству операций. Верно вы пишете — "а у нас много ядер". Формулы для нижней границы количества тактов в зависимости от количества параллельных компараторов и размера входных данных пока что получить не удалось (см. Кнут, III). Алгоритмы, сортирующие быстрее, чем n*logN, совершенно точно есть.
2. Вы игнорируете тот факт, что для большинства систем интересна не нижняя граница, а Nth Percentile. Грубо говоря, за какое время завершатся 99% сортировок, при заданном нами распределении входных данных. Верно вы пишете — "а у нас тут такие данные".
И там, где "математик" победно пишет "я доказал, что сортировать быстрее чем за O(n*log(n)) невозможно" и идёт обедать, "инженер" продолжает искать, и находит решение, которое почти всегда сортирует данные за log(n).

Меня интересует инженерный подход, т.к. я занимаюсь не теоремами, а разработкой продуктов. У продуктов есть потребительские характеристики. Меня не интересует строгое математическое доказательство того, что невозможно построить алгоритм, отличающий на фотографии букву О от цифры 0. Меня интересует разработка распознавалки, которая почти всегда угадывает верно.

·>Ещё раз. Алгоритмам питание не нужно.
Ну так алгоритмы и не ломаются. В математическом мире все ноды мгновенно достижимы. Недостижимость ноды — это математическая модель реального мира.
Проблема CAP — в том, что "ломаемость" мира в модель добавили, а "починимость" — нет. Давайте предположим, что одиночный сегмент сети восстанавливается после сбоя за время T_R. Вряд ли оно зависит от количества сегментов; выбрав таймаут операции большим, чем T_R, мы получим консистентную и доступную систему, терпимую к разделению кластера.
Если мы зададим ожидаемую частоту выхода сегментов из строя (MTBF), то для любого наперёд заданного показателя Availability мы сможем рассчитать потребную величину таймаута — с учётом того, что несколько сбоев могут наложиться друг на друга.
·>И?

The vast majority of software services and systems should aim for almost-perfect reliability rather than perfect reliability—that is, 99.999 or 99.99 percent rather than 100 percent—because users cannot tell the difference between a service being 100 percent available and less than "perfectly" available.

(https://queue.acm.org/detail.cfm?id=3096459)

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

C>>Вообще говоря, существуют и даже активно впариваются клиентам. Ярким представителем является Oracle RAC, где при правильной установке получается 3-кратное дублирование каналов связи и анальное самоогораживание узлов при первых признаках проблем. Что привело к паре очень громких публичных фэйлов, кстати.
Gt_>скорее к безусловному лидерству в фин секторе. RAC уже процентов 70 фин сектора вытеснив всю noSQL-щину.
Кто куда перешёл? Классический процессинг в нынешней технологии можно обработать в масштабах всей страны на одной персоналке. Там вообще ничего нетривиального по меркам современных технологий нет, так что я не удивляюсь, что впариватели из Оракала его успешно пихают.

А вот в инвестиционном банкинге или финтехе — никакими RAC и не пахнет.

Gt_>и в первую очередь потому как нужна настоящая консистеность и availability. а вот ФБ и твитер что-то сбоят кажду неделю уже. т.е. даже лайки и те посчитать не получается.
Я не пользуюсь обоими, но вот как раз RAC ответственен за то, что Амазон полностью изжил Oracle и РСУБД из критических систем.

Gt_>и пока не видно серьезных конкурентов. доморощенные поделки в стиле динамодб чудовфищно проигрывают обычному хадупу по throughput, при этом в плане консистентности ничего интересней чем то что есть уже у хадупов забесплатно нет. на hdfs писать можно на порядок быстрее.

Хадуп занимается совсем другим.

Ну и как насчёт миллиарда запросов в секунду на DDB? Это "проигрывают обычному хадупу"?

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

CK>>Общепринятое определение availability — количество времени, которое система (либо ее часть) была недоступна.
CK>>(525600 − M) ÷ 525600 (где М — время простоя в минутах)
S>Во-первых, наоборот. Время, когда система была доступна.

временной интервал (год, месяц, неделя) минус суммарная продолжительность всех инцидентов, приведших к недоступности сервиса, на этом интервале времени, будешь с этим спорить?

S>Во-вторых, про период ровно в год — это вы взяли один пример, и думаете, что он и есть определение. Очевидно, что он неверный — система, пролежавшая полтора года, по вашей формуле имеет availability равную (-50%).

я исходил из предположения, что мой собеседник — умный человек и поймет, почему в формуле 525600 минут и что нужно сделать, если мы рассматриваем другой интервал времени

S>В-третьих, этот подход (время доступности) — это упрощение, изначально предложенное для систем непрерывного действия (например, электростанций).

И для сервисов, которые должны работать постоянно, в контексте дискуссии нас именно это интересует, ты сам начал рассуждать про "пять девяток", а теперь утверждаешь что это для электростанций :D

CK>>ты это как-то по особенному понимаешь, при "географическом сегментировании" я хочу иметь доступ ко всем данным, даже если один дц недоступен
S>Ничего особенного в этом нет. Ваше наивное желание не соответствует реальным бизнес требованиям. Не бывает так, чтобы доступ ко всем данным имел одинаковый приоритет; и даже в этом частном случае любой заказчик предпочтёт при сбое иметь доступ к части данных, чем не иметь его вовсе.

Еще раз. Ты это _неправильно_ понимаешь. В АР системе, работающей в нескольких ДЦ, при сбое одного ДЦ, все данные будут доступны. Нормальной практикой является периодическое отключение ДЦ, в рамках тестирования боевой инфраструктуры на resiliency, например.

S>Это попытка объяснить, что даже тот юзкейс, для которого потенциально можно было бы применить CAP, не работает.
S>Что такого умного вы сможете сделать, зная CAP, чего вы не могли бы, не имея доказательства CAP?

С помощью CAP я могу понять, что у меня есть трэйдоф, я могу обеспечить целостность (linearizability) или доступность. С появлением САР, люди поняли, что пространство возможных решений шире, что привело к созданию алтернативных дизайнов (NoSQL), которые жертвуют линеаризуемостью, но имеют другие интересные свойства. Собственно на этом полезность и заканчивается.

CK>>или вот такой — наш интернет магазин доставляет товары в ЮВА, Европе и Америке, сделай так, чтобы данные хранились и обрабатывались как можно ближе к пользователю
S>Ок, опять. Что такое "как можно ближе к пользователю"? Тут, конечно, интуитивно понятно, что хочется иметь консистентность на уровне хотя бы "размещённые заказы не теряются", и availability на приемлемом уровне (например, три девятки).

"Ближе к пользователю", это когда у тебя есть три ДЦ, в каждом из которых крутится web frontend, который берет/кладет данные в Cassandra. Cassandra при этом крутится в каждом из этих ДЦ и в каждом из них есть копия всех данных. Недоступность одного из ДЦ не приводит к простою (все товары из БД доступны).

S>Мотивацией для "ближе к пользователю" могут быть два совершенно разных фактора: один — это response times, которым в современном веб-магазине обычно можно пренебречь, второй — это как раз та самая availability, которую вы отказываетесь понимать. В том смысле, что пользователю из Китая будет совершенно безразлично, что он прямо сейчас не может заказать доставку в Нидерланды, ему важно смочь заказать доставку в своём же регионе.

Это пишет человек, который всего несколько сообщений назад рассуждал про "требования бизнеса". У тебя чувак из Нидерландов может заказать что-нибудь в Китае, находясь при этом в Южной Америке. В данном случае, поддержка подобной распределенной архитектуры, это продуктовое решение.

Временем респонза в интернет магазине пренебречь нельзя. Особенно, если у этого магазина есть не только веб морда, но еще и мобильное приложение. Требования к latency в данном случае, это тоже решение продакта, а не программиста.

S>Т.е. падение связи между серверами Европы и ЮВА имеет смысл обрабатывать специальным образом, а не делать недоступной всю систему.

Для этого как раз пригодится САР.

Здравствуйте, chaotic-kotik, Вы писали:
CK>в общем-то, ты спросил как имзерять, я ответил — "Каким образом вы от лога результатов перейдёте к "минутам" и "продолжительности инцидентов"? Ну, чтобы вычислить availability?"
Вы же понимаете, что смысл ваших действий — это аппроксимировать % упавших клиентских запросов на основании данных о падении мониторящих запросов?

Клиента (и Product Manager) не интересуют показания вашего монитора. Если раунд-робин выбирает сервис, который отдаёт 500, каждый четвёртый раз, а агенту нужно хотя бы 2 500 "подряд", то ваша лампочка будет гореть зелёным, а с т.з. клиента availability будет равна 75%.

CK>если подумать, то есть
CK>у тебя данные хранятся в одном месте, поэтому они становятся недоступными при непродолжительном отказе, а при продолжительном что будет? в дц пожар, твоя стойка сгорела
Вы опять путаете network partition с device loss. "У меня" данные нигде пока что не хранятся; мы пока что обсуждаем только уровень требований к системе.
Я же Product Manager — я вам (архитектору) объясняю что нет, для меня отказ от консистентности гораздо хуже, чем отказ в обслуживании части запросов при network partition.
Что нагрузка устроена нетривиальным образом; поэтому когда мы выбираем между "терять 10% от всех запросов" и "терять 100% от 1% запросов" выбор однозначно в пользу последнего.

CK>Почему ты думаешь что клиенты в Москве обслуживаются одним ДЦ? Я думаю процентов 50 клиентов ЯТакси, это Мск и СПб.
Я привёл абстрактный иллюстративный пример. Ок, давайте рассмотрим Химки — сколько процентов заказов, сделанных из Химок хотят подачу машину в Химках, а сколько — в других районах?

CK>Еще раз, ты не понимаешь multidatacenter setup. Оно будет нормально работать. В случае ЯТакси, они умеют отрабатывать ситуацию N-1 ДЦ без импакта для пользоватлей. Они проводят учения с отключением одного из боевых ДЦ.
Ну, то есть они опровергли CAP теорему, я вас правильно понял? Ведь ни разу такого не было, чтобы одному клиенту назначили две машины и наоборот — то есть consistency у них соблюдена.

CK>значит читал известно чем (либо читал в переводе и переводили известно чем), потому что там как раз это все расписано
"Это всё" — это что?
Давайте с цитатами, что ли.

Здравствуйте, 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 на понятный мне язык.

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

S>но как-то единой теории с соотв. мат. аппаратом не появилось? Почему?

1) Сперва сделают единую теорию, а потом она сломается, потому что у RAID-контроллера прошивка немного кривенькая, но поставщик поставляет as is и ответственности не несёт. Это мосту нужен сопромат, потому что за падение моста и посадить могут, а вот за падение программ и железа никого не сажают.
2) Вся наука в айти закончилась в 1990 году примерно (или когда там C++ в народ пошёл), и дальше начался сплошной сбор денег.
3) Человек, пишущий в Inria на Coq в Мадриде, будет зарабатывать меньше чем энергичный вася, пишущий на JavaScript в Москве. Ну какая тут наука.

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

IB>А при чем тут масштабирование и какое это все имеет отношение к обсуждаемому вопросу? Предлагаю не путать теплое с мягким и с фокусироваться на availability и consistency в терминах CAP. Масштабирование — это другой вопрос, к CAP отношения не имеющий.

Это какое-то лукавство, что значит буква P? Partition tolerance. А откуда оно взялось, ведь взять обсуждаемую архитектуру: все запросы идут в одну ноду, нода синхронно реплицируется (C), если мастер падает, то мастером становится реплика (А) и все запросы теперь идут через нее. Где тут Р? И откуда Р появилась? Ну видимо оттуда, что все запросы в одну ноду стали узким местом и пришлось пустить запросы по разным нодам. Утверждать что это не так — смело, но глупо.

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

DI>>Не совсем так. Например, лидера назначает внешний арбитр, а сами ноды решение об этом принимать не могут.
S>Отлично. Что делать, если отпал арбитр?

Ответил рядом. TLDR — если хочешь серебрянную пулю, то ее нет.

DI>>Чего? С чем я должен спорить-то?
S>С тем, что CAP никакого отношения к Scalability не имеет.

Конечно, там таких слов нет, вот только сразу как начинаешь горизонтально масштабироваться немедленно возникает угроза разделения кластера.

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

CK>Если бы еще DNS записи часто обновлялись.
Ага, я вижу, что постепенно наступает понимание того, что требования зависят от задачи.

CK>Масштабировать что-то одно, только чтение или только запись несложно.
Верно.
CK>В чем смысл обсуждать какой-то вырожденный случай?
Вырожденный случай — это CAP, в которой под availability понимается 100% возможность получить ответ от любого узла.

CK>Если хочется обсуждать реальные системы, можно взять что-то реальное за основу (Google Chubby, DynamoDB, FAWN, Pnuts, ...) и посмотреть как там проявляются ограничения CAP.
Ок, давайте пообсуждаем. Хотя мне кажется, что вы путаете реальные системы с инструментами. Реальная система — это, к примеру, банковское приложение. У него, в отличие от инструмента, есть набор функциональных и нефункциональных требований.
CK>Но это конечно сложнее, нежели тыкать оппонентов в DNS, который в общем-то даже не очень то и отказоустойчив.
По факту — весьма отказоустойчив. Настолько отказоустойчив, что прочие reliable services типа того же chubby легко полагаются на DNS как механизм резолвинга ссылок.

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

DI>Соси лапу, тролятина, не подаю.
Как говорят зарубежные коллеги — go fuck yourself. Только не кипятись, сделай это спокойно и с расстановкой, чтобы в другой раз так публично не обделаться. =)

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

DI>Во-первых, про роутер ты в своей архитектуре ты ничего не говорил, пока я не указал, что он нужен.
Вы как-то ловко подменяете задачу. Началось всё, напомню, с вашего безапелляционного заявления о том, что failover cluster невозможно масштабировать.
Вам показали, как именно его можно масштабировать. Речи о том, что failover cluster — это серебряная пуля, или обязательства нарисовать полную архитектуру, которая обеспечивает CAP для произвольно придуманной прикладной задачи, не было.

DI>Во-вторых, ссылку то дай, а то пока твое слово против моего и не я должен опровергать, что в книге нет, а ты доказывать. В-третьих, дай-то уж нормальное описание предлагаемой тобой архитектуры, а то пока ты только что-то туманное вбросил.
Эти вопросы освещены в главе 6, Partitioning. Страницы с 209 по 216.
DI>Где? Не увидел.
Все поставленные вами задачи сводятся к rebalancing partitions. Я вам написал пошаговый сценарий перевоза шарда с одной ноды на другую.
S>>Чем вас не устраивает Raft или модификации Paxos?
DI>Подожди, давай ты сначала покажешь масштабируемую архитектуру обеспечивающую доступность и консистентность. Пока почему-то ты просто скипаешь мои аргументы.
Мне неизвестна единая архитектура, обеспечивающая CAP для произвольного масштаба, и пригодная для произвольной прикладной задачи.
Для принятия архитектурных решений придётся начать с конкретной задачи, и уже исходя из функциональных и нефункциональных требований подобрать к ней реализацию.

В целом, направление разработки — именно такое: шардинг + репликация; линки различной степени надёжности для локальных и для глобальных коммуникаций; консенсус для обеспечения C и A (как, например, в SQL Azure, где коммит требует "2 из 3"). Для роутинга выбираются более консервативные алгоритмы консенсуса, т.к. там можно оптимизироваться для "mostly read" нагрузки, и потеря availability в операциях записи нам не так страшна.

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

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

S>>Согласен. Но даже получить availability "такую же, как у Data Center" — вполне неплохое достижение для приложения.

CK>чтобы было так же, как у ДЦ, нужно чтобы твое приложение работало вообще без отказов, я слабо представляю как такое возможно

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

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

CK>Ну дык, ты же сам писал — "А с точки зрения инженерной (и бизнеса) availability в 1 девятку очень сильно отличается от availability в 5 девяток", то бишь если с точки зрения бизнеса, нужно иметь пять девяток, то тебе нужно в multidatacenter setup, если бизнес хочет гео-распределенность, ради низкой latency, тоже самое. Требования к системе диктуют tradeoff-ы, которые ты можешь использовать. Поэтому докозательство в духе — вот СР система, которая может в HA, поэтому на практике она ничем не уступает AP системам, по крайней мере с точки зрения пользователя — не работает. Уступает.
Кто сказал "ничем не уступает"??? Чтобы понять, кто кому уступает, надо сначала сравнить реальные показатели consistency и availability.
Ещё раз повторю очевидную мысль: CAP теорема не даёт нам никакого базиса для сравнения систем с различным количеством девяток — просто потому, что в её определении availability нет никаких девяток.
Поэтому я не вполне понимаю, как можно без лукавства привлекать эту теорему для обоснования каких-либо решений. Вот вы приходите ко мне, и говорите: "я предлагаю сделать вот такую AP систему, потому что CAP не даёт нам возможности получить CAP-систему". А я вам отвечаю: "ок, то есть ваша система — она прямо вся такая A, несмотря ни на какие P"? Вы мне: "ой, нет, DC, в котором она развернута, даёт A=99.95%". Тогда я вам говорю: "а нахрена вы мне приносите P-систему, в которой нет ни A ни С? Давайте вы лучше мне сделаете CP-систему, которая имеет A в 99.9%. 0.05% сожрал DC, я даю вам ещё 0.05% A на обеспечение С".

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

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

S>>Я уже почитал. Особенно вдохновляет раздел The Unhelpful CAP Theorem.
CK>значит читал известно чем (либо читал в переводе и переводили известно чем), потому что там как раз это все расписано

Стр. 337

The Unhelpful CAP Theorem
CAP is sometimes presented as Consistency, Availability, Partition tolerance: pick 2
out of 3. Unfortunately, putting it this way is misleading [32] because network parti‐
tions are a kind of fault, so they aren’t something about which you have a choice: they
will happen whether you like it or not [38].
At times when the network is working correctly, a system can provide both consis‐
tency (linearizability) and total availability. When a network fault occurs, you have to
choose between either linearizability or total availability. Thus, a better way of phras‐
ing CAP would be either Consistent or Available when Partitioned [39]. A more relia‐
ble network needs to make this choice less often, but at some point the choice is
inevitable.
In discussions of CAP there are several contradictory definitions of the term availa‐
bility, and the formalization as a theorem [30] does not match its usual meaning [40].
Many so-called “highly available” (fault-tolerant) systems actually do not meet CAP’s
idiosyncratic definition of availability. All in all, there is a lot of misunderstanding
and confusion around CAP, and it does not help us understand systems better, so
CAP is best avoided.

Здравствуйте, 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, действуйте.

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

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

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

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

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

S>Предлагаю поднятые выше два вопроса обсудить.

А вы CAP-теорему читали?
Я вот читал и согласен с Синклером.
Даже на хабре постил статью на эту тему https://habr.com/ru/post/231703/

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

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

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

IB>>Как раз вот это утверждение и подтверждает правоту точки зрения Антона о том, что теорема вредна.
IB>>Ведь на самом-то деле нет такого закона как два из трех. На самом деле, возможно все три, все дело в допущениях и граничных условиях. Но "теорема" об этом ничего не говорит, а лишь категорично утверждает, что чем-то надо пожертвовать — а это не правда. То есть CAP намеренно вводит в заблуждение излишне упрощая проблему.

S>Тот факт, что в ней отсутсвуют количественные характеристики не делает ее бесполезной.

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

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

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

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

Рассматривая цифры можно сделать другие выводы:
1) Разделения сети на практике не такое частое явления. Системы для которых важна отказоустойчивость и отсутствие потерь данных чаще всего работают в одной локальной сети. Сами авторы теоремы говорят что можно считать, что разделения в локальной сети не случаются.
2) eventualy consistent системы работают только тогда, когда интервал восстановления согласованности меньше частоты изменения данных. А в случае неограниченно долгого разделения этого обеспечить никак не получится. Поэтому система гарантированно потеряет данные или нарушит инварианты.
3) Недоступность части узлов на практике не уменьшает доступность системы в целом. Кворумы и failover-кластеры работающие при сохранении связности более N/2 узлов помогают пережить даже значительные разделения без падения доступности.

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

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

S>Маленький оффтоп:

CK>>Availability в CAP — это свойство алгоритма. Это аналог сложности алгоритма или lock free/wait free гарантии в многопоточном программировании. Там ты тоже на практике можешь получить ситуацию, когда lock free алгоритм заблокировался, например в случае priority inversion,

S>Навереное не алгоритм заблокировлся, а поток, его исполняющий?

Да, поток, исполняющий lock free алгоритм может застрять по множеству причин, это не говорит о том что lock free — бесполезная гарантия.

CK>> или O(N) будет быстрее чем O(LogN).

S>Это когда данные есть в кэше или неудачный pivot в quick sort?

Ага.

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

DI>>Это вообще к чему?
DI>>Начинали с обсуждения этой архитектуры: "Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер." Еще раз вопрос, как это может масштабироваться?
S>А в чем проблема это отмасштабировать? Выбирается другой мастер на другой машине, и запросы идуд через него.
Напомню: Scalability is the property of a system to handle a growing amount of work by adding resources to the system
Нет такой машины, способной обработать любое число запросов. Поэтому в какой-то очень скорый момент времени твоя масштабилка через один мастер просто кончится и придётся добавлять новые узлы в систему, вместо одного мастера потребуется два и здравствуй CAP.
failover тут вообще не в тему.

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

S>>>А в чем проблема это отмасштабировать? Выбирается другой мастер на другой машине, и запросы идуд через него.
DI>>У тебя 300К запросов в секунду, а 1 сервер не вывозит больше 50К.

S>Не понял, речь шла о масшабируемости в случае падения мастера...

Если не понял, можно спросить. Обсуждение началось с этого:

— В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.

— И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?

S>В сценарии выше иметь необходимое кол-ов серверов для обработки в избытке.

Еще раз. У тебя 300К запросов в секунду, а 1 сервер не вывозит больше 50К. Как ты имея одну точку входа, которая физически не способна обработать поток запросов, эти самые запросы обработаешь?

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

S>Это прекрасно, это именно то, чего я хочу. Но для такого разговора придётся отказаться от CAP и перейти к чему-то более серъёзному, типа Service Reliability Engineering.
Нету такого.

На практике у нас всего две возможности:
1) Храним данные в небольшом кластере, где можно за счёт избыточных интерконнектов не волноваться о буквах "P", и за счёт географической близости о букве "A".
2) Отказываемся от буквы "C".

Решение 1), на самом деле, вполне себе неплохо для подавляющего большинства задач. Но у него есть твёрдый потолок масштабирования, который не пробивается никак. Его можно чуть пытаться поднимать с помощью всяких in-memory DB и прочих ужимок, но это всё ограничено. Ну и так же есть принципиальная невозможность получить географическую распределённость.

S>·>В очередях бесконечной длины? Круто чё. Если ты не просёк, то мы рассматриваем не обработку 1млрд запросов, посланных за секунду, а систему, способную обрабатывать 1млрд запросов в секунду.
S>Вы как-то произвольно прыгаете между математической абстракцией (миллиард RPS) и практической реализацией. Если вы хотите переводить разговор в практическую плоскость, то я вам отвечу, что и породить такое количество запросов будет затруднительно.
В этом году именно такую нагрузку выдерживал DynamoDB, обеспечивающий работу сайта Amazon.com, во время нагрузочных тестов. Реальная нагрузка от пользователей была около 400 миллионов запросов в секунду.

S>·>И пока какой-то из этих серверов лежит, система неконсистентна или недоступна. ЧТД.

S>Ну, а теперь заменим каждый сервер на failover cluster.
И что дальше-то?

S>Меня интересует инженерный подход, т.к. я занимаюсь не теоремами, а разработкой продуктов. У продуктов есть потребительские характеристики. Меня не интересует строгое математическое доказательство того, что невозможно построить алгоритм, отличающий на фотографии букву О от цифры 0. Меня интересует разработка распознавалки, которая почти всегда угадывает верно.
У CAP-теоремы есть вполне практические последствия — см. выше.

Т.е. при необходимости буквы "C" пространство архитектурных выборов снижается до очень небольшого.

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

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

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

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

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

S>По идее тут мы жертвуем А, соотв. никто не будет отвечать.
Так вот этот вывод неверный. Ибо доступность узла != доступность системы.
Но этот вывод непременно сделают маркетологи NoSQL.

G>>Это полезно? Какие выводы можно сделать? Какие советы вы бы дали архитектору системы?
S>Енто зависит от предметной области данного архитектора. И перед ним четко сформулированы компромиссы.
Архитекторы тоже люди и им свойственно подвергаться влиянию рекламы и буллшита.

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

S>Давайте от противного, а назовите полезную теорему, если таковая имеется, которая поможет разработчикам распр. систем? Вот почитал\изучил, все стало ясно и вперед.
Про теорему не в курсе, но однозначно разработчика распределенных систем поможет докторская диссертация Роя Филдинга, которая называется REpresentational State Transfer.

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

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

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

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

IB>>а это не правда

AK>Я попытался себе представить все три из трех, C + A + P, и это сломало мне мозг. Я не могу представить систему, которая во фрагментированном состоянии была бы одновременно консистентна и всегда доступна.
Нет такой.

Более того, Представить систему, которая в фрагментированном состоянии консистента и недоступна тоже нельзя.
По факту теорема подталкивает к выводу, что самая нужная система — AP — доступная, но не консистентная во фрагментированном состоянии.

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

AK>Можете привести какой-нибудь пример, где теорема САР не работала бы?

Простой пример. Кластер из трех БД — все они делают синхронную репликацию на два других узла. Синхронная репликация считается успешной когда хотя бы один узел ответил ОК.
Происходит разделение, один узел теряет возможность общаться с другими.
Как сильно упадет доступность системы в таком случае?
Правильный ответ — никак.

У нас получается система консистентная, доступная и устойчивая к разделению? По логике обывателя — да. По логике CAP — нет (внезапно).

Только системы CP системы применимы в реальной жизни, а за исключением единичных примеров вроде DNS (классическая AP система).

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

G>>У нас получается система консистентная, доступная и устойчивая к разделению? По логике обывателя — да. По логике CAP — нет (внезапно).

CK>Ну как же, если у тебя скажем не хватает одной записи в таблице в БД №1, но она есть в БД №2, а БД №3 недоступна, ты не сможешь определить, была запись удалена, либо добавлена. Скажем, у тебя возможна ситуация, когда одна БД №1 моргнула, на БД №2 пришел запрос на удаление/добавление, он отработал, синхронно реплицировался на БД №3, после чего БД №3 стала недоступна из-за разделения.
Не выдумывай, репликация делается через ЛОГ, а в нем есть инфа о том, что быдло удалено и добавлено. По крайней мере во взрослых СУБД так.

CK>Чтобы система была консистентной, тебе нужно читать кворум, а не одну БД. Если ты будешь это делать, то обнаружишь, что у тебя доступность таки упала, так как в вышеописанном случае, тебе придется вернуть ошибку.
Для консистентности вовсе не надо читать кворум. Это очередные выдумки NoSQL маркетологов. Взрослые СУБД движки вполне обходятся кворумом записи и вовсе не требуется нескольким узлам тратить время на обработку одного и того же запроса.

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

CK>>Ну как же, если у тебя скажем не хватает одной записи в таблице в БД №1, но она есть в БД №2, а БД №3 недоступна, ты не сможешь определить, была запись удалена, либо добавлена. Скажем, у тебя возможна ситуация, когда одна БД №1 моргнула, на БД №2 пришел запрос на удаление/добавление, он отработал, синхронно реплицировался на БД №3, после чего БД №3 стала недоступна из-за разделения.
G>Не выдумывай, репликация делается через ЛОГ, а в нем есть инфа о том, что быдло удалено и добавлено. По крайней мере во взрослых СУБД так.

ты писал — "Простой пример. Кластер из трех БД — все они делают синхронную репликацию на два других узла. Синхронная репликация считается успешной когда хотя бы один узел ответил ОК."

мы говорим "delete foo", это отрабатывает на БД2 и БД3, говорим ОК
БД1 неистово пытается приконнектиться к двум другим, в это время в нее приходит клиент 1, спокойно делает "select * where key=foo" и получает старые данные
клиент 2 делает тоже самое на БД2 и получает другой ответ

БД1 может не принимать запросы на чтение, пока не восстановит подключение к другим БД и не получит от них log sequence number последнего коммита, но это значит что мы потеряли availability

CK>>Чтобы система была консистентной, тебе нужно читать кворум, а не одну БД. Если ты будешь это делать, то обнаружишь, что у тебя доступность таки упала, так как в вышеописанном случае, тебе придется вернуть ошибку.
G>Для консистентности вовсе не надо читать кворум. Это очередные выдумки NoSQL маркетологов. Взрослые СУБД движки вполне обходятся кворумом записи и вовсе не требуется нескольким узлам тратить время на обработку одного и того же запроса.

Это так. Кворум штука дорогая. Современные СУБД пытаются уменьшить quorum amplification. Например Amazon Aurora так делает, но чтобы так делать, она поддерживает информацию о том что уже записалось, а что еще нет на своем центральном узле

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

G>Не выдумывай, репликация делается через ЛОГ, а в нем есть инфа о том, что быдло удалено и добавлено. По крайней мере во взрослых СУБД так.
Все "взрослые СУБД" не являются available.

CK>>Чтобы система была консистентной, тебе нужно читать кворум, а не одну БД. Если ты будешь это делать, то обнаружишь, что у тебя доступность таки упала, так как в вышеописанном случае, тебе придется вернуть ошибку.
G>Для консистентности вовсе не надо читать кворум. Это очередные выдумки NoSQL маркетологов. Взрослые СУБД движки вполне обходятся кворумом записи и вовсе не требуется нескольким узлам тратить время на обработку одного и того же запроса.
Ну вот потому они и не могут быть available и partition tolerant. Поэтому все "взрослые СУБД" на практике и ограничены одним сервером (максимум, небольшим кластером с быстрыми интерконнектами между узлами).

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

DI>- И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?
Оно надо для того, чтобы в случае сбоя одного из узлов приложение продолжало работать. Ваш К.О.
Иначе вы из компонентов с Availability в две девятки никак не получите пять девяток.

Вопросы масштабирования решаются по-другому. Как правило — в зависимости от конкретной задачи.
Рекомендую взглянуть на архитектуру DNS с этой точки зрения — там вполне классически single-master репликация, при этом масштабирование совершенно сумасшедшее. И availability — на зависть многим. Consistency при этом тоже весьма неплоха — всё зависит от того, что именно мы назовём Consistency. Скажем, у нас есть заранее известный верхний предел времени, которое должно пройти после модификации, чтобы ни один запрос не вернул stale data.

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

DI>>Не совсем так. Например, лидера назначает внешний арбитр, а сами ноды решение об этом принимать не могут.

MA> Quis custodiet ipsos custodes?

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

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

MA>·>"Хранят"? В смысле RO-система? В этом случае CAP как-то не в тему. Ибо эта теорема рассматривает RW. Вот когда ты на этом миллионе серверов захочешь сделать какой-то алгоритм, например, "перевести деньги со счёта на счёт без овердрафта", то у тебе придётся делать выбор C либо A.
MA> Тут нет выбора между C и A как такого.
Гы. Ты угадал все буквы, но не смог назвать слово.
Повторяюсь. Это теорема о свойствах алгоритмов в распределённых системах.

MA>Такого рода операция абсолютно аналогична межбанковским переводам, или транзакциям ч/з платежные карты.
Ок. Это наша распределённая система.

MA>Т.е. списываем/блокируем, задание в очередь, телепорт на узел с целевым счетом, пополнение.
Это AP-алгоритм.

MA>Возможен центральный "арбитр"
А это CP-алгоритм.

MA>или правила ролбэка.
Тоже AP-алгоритм, с Eventual Consistency.

MA>Между чем тут выбирать.
В этом и суть теоремы — выбирай, но не всё сразу.

MA>Её можно обрабатывать хоть бесконечность,
Про бесконечность ты немного загнул. Алгоритм не бывает бесконечным, по определению.

MA>при чем ни один узел не перейдет в неведомо-неконсистентное состояние вне зависимости от ежемоментной доступности т.н. кластера будь он четвертован или нет.
Угу. Ведь узел по определению косистентый. А CAP-теорема о том как эти узлы взаимодействуют.

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

S>Хотелось бы почитать про это более подробно, с формулами и доказательствами. Это как раз то, что я ищу.

посмотри сколько сообщений требует Paxos на каждый раунд, как оно зависит от количества узлов и что происходит в случае конфликта

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

CK>>Мне не нужно от лога к availability переходить, у меня есть мониторинг, в котором это все считается.
S>

)
S>1. А мониторинг как работает? Он не делает запросы?
S>2. Вы понимаете, что если мониторинг показывает, что "всё ок", а клиент получает таймаут, то прав клиент, а не мониторинг? Ну, и наоборот — тоже?

В нашем случае используется black-box мониторинг, который работает отдельно от основной инфраструктуры, в нескольких георграфически удаленных регионах, он делает запросы в API и измеряет время отклика. Если заданное количество агентов не получили ответ от сервиса, или получили, но с превышением таймаута, заданного в SLA, поднимается alert, регистрируется начал инцедента. Когда все агенты снова получили ответ, генерируется новый alert и регистрируется окончание инцидента. Есть метрика в графане, которая по этим данным рисует доступность.
Это довольно распространенное решение, datadog и alertra считают availability похожим образом.

S>Мне кажется смешным такая вот бескомпромиссная трактовка Availability. Реальные системы запросто жертвуют доступом к части данных, продолжая работать с тем, что есть.

Еще раз, мне интересны распределенные системы в общем и распредленные БД в частности. Мне не очень интересны системы, где можно пожертвовать частью данных, такие как сайты с котиками и онлайн агрегаторы, торгующие авиабилетами. В контектсе баз данных, недоступность части данных эквивалентна потере доступности.

S>Вот, первое что в голову пришло — aviasales прекрасно продолжают отдавать результаты, даже если связь с одним из поставщиков временно нагибается.

Aviasales это агрегатор, поставщик — сторонний вендор, а не часть системы. Хорошим примером ялвяется приложение такси. Представь, что у яндекс.такси накрылся один ДЦ и 1/(количество Дц) клиентов не может использовать сервис, и такая же доля водителей не может принимать и завершать заказы. В результате, компания несет миллионы рублей убытков.

То, о чем ты говоришь, называется graceful service degradation. Хорошая вещь, но в качестве дополнения, а не как единственное поведение в случае проблем.

CK>>1. да, имеет смысл обрабатывать специальным образом
CK>>2. делать недоступной всю систему тоже делать не стоит
CK>>3. делать независимую систему на каждый регион, объясняя это какими-то своими домыслами — неправильно
CK>>4. если решишь подумать, как можно добиться 1. и 2. без 3., то тебе вероятно понадобится САР в твоих рассуждениях
S>Опять косвенные соображения. Мы дождёмся примера применения CAP в рассуждениях архитектора системы? Пока что получается так, что все содержательные мысли образуются без помощи CAP.

Я не могу сделать эти шаги за тебя. Попробуй DDIA прочитать более внимательно что-ли.

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

S>Ну вот, то что я предлагаю, вид сбоку.
ты ничего конкретного пока не предложил

S>Ну, то есть пока падает меньше выбранного вами процента запросов, вы считаете, что система available.
я точно не помню что там SRE наворотили, скорее всего есть гистерезис небольшой (нужно несколько 500 подряд чтобы агент сагрился)

S>Когда мы проектируем систему, мы оперируем не black box availability, а предсказываем реальное поведение.
ты можешь посчитать availability зная MTTF каждого компонента системы, да
это не значит что не нужно измерять
в общем-то, ты спросил как имзерять, я ответил — "Каким образом вы от лога результатов перейдёте к "минутам" и "продолжительности инцидентов"? Ну, чтобы вычислить availability?"

S>>>Мне кажется смешным такая вот бескомпромиссная трактовка Availability. Реальные системы запросто жертвуют доступом к части данных, продолжая работать с тем, что есть.
CK>>Еще раз, мне интересны распределенные системы в общем и распредленные БД в частности. Мне не очень интересны системы, где можно пожертвовать частью данных, такие как сайты с котиками и онлайн агрегаторы, торгующие авиабилетами. В контектсе баз данных, потеря 1/N данных, при отказе одного из N датацентров — неприемлема.
S>Нет никакой потери.

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

S>Во-первых, не 1/N. А 1/(N в большой степени), потому что тут не "DC накрылся", а произошёл network partition. В итоге клиенты из Новосибирска не могут вызвать такси в Москве. К счастью, таких запросов — 1 на миллион, поэтому почти никто не заметит потери. Нам важно дать возможность клиентам в Нске заказывать машину в Нске, а Москвичам — в Москве. Причины очевидны или надо разжёвывать?

Почему ты думаешь что клиенты в Москве обслуживаются одним ДЦ? Я думаю процентов 50 клиентов ЯТакси, это Мск и СПб.

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

Еще раз, ты не понимаешь multidatacenter setup. Оно будет нормально работать. В случае ЯТакси, они умеют отрабатывать ситуацию N-1 ДЦ без импакта для пользоватлей. Они проводят учения с отключением одного из боевых ДЦ.

S>Я уже почитал. Особенно вдохновляет раздел The Unhelpful CAP Theorem.
значит читал известно чем (либо читал в переводе и переводили известно чем), потому что там как раз это все расписано

Здравствуйте, 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 и потом восстановить консистентность, после восстановления связи между ДЦ, довольно очевидным образом.

Здравствуйте, 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 систему, для регистрации прогресса РА систему.

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

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

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

M>Теорема появилась в 1998-м году. CouchDB, который и начала хайп NoSQL появился в 2005-м.
Хронологически да, да и то не совсем. в 98 появился принцип CAP, а теорему из него сделали позже и другие люди.
Но по факту, про САР вспомнили, когда надо было объяснить почему NoSQL работают так как работают...

M>А куча распределенных систем... Ну она стала появляться как раз в середине 90-х. И CAP, как теорема, была сформулирована человеком, который собственно и занимался распрделенными системами в Inktomi.
Да, и этот же человек позже вынужден был писать объяснение, что вы все не правильно CAP понимаете, и я вовсе не это имел ввиду.

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

DI>>Дай ссылку на определение, а то на мой взгляд ты как-то очень своеобразно трактуешь САР теорему. В теореме вообще про узлы ничего нет, там только про свойства системы.

G>https://users.ece.cmu.edu/~adrian/731-sp04/readings/GL-cap.pdf
G>Про узлы там есть, nodes если что это узлы

Я просил дать определение CAP теоремы (она же теорема Брюера), ты дал ссылку на статью Сета Гилберта и Ненси Линч, где они рассматривают один из случаев когда CAP теорема выполняется. Что это было?

DI>>>>2) Системы для которых важна отказоустойчивость и отсутствие потерь данных никогда не работают в одной сети, всегда есть реплицирование как минимум в один другой датацентр.
G>>>И? Вопрос пассивных реплик не рассматривается в CAP. Рассматриваются только случаи когда все узлы активные, то есть отвечают на запросы клиентов.
DI>>Дай ссылку на определение, а то на мой взгляд ты как-то очень своеобразно трактуешь САР теорему.
G>https://users.ece.cmu.edu/~adrian/731-sp04/readings/GL-cap.pdf
G>Я трактую её ровно так, как она доказана, а не так, как работает в голове у некоторых людей.

Я просил дать определение CAP теоремы (она же теорема Брюера), ты дал ссылку на статью Сета Гилберта и Ненси Линч, где они рассматривают один из случаев когда CAP теорема выполняется. Что это было?

DI>>>>2) В каком алгоритме консенсус достигается при половине членов? Насколько я могу представить, наоборот, требуется избыточность.
G>>>В алгоритме синхронного коммита. Когда запрос приходит на узел узел отправляет данные всем остальным узлам и в случае получения подтверждения от N/2+1 узлов отвечает на запрос клиента.
DI>>Дай ссылку на описание алгоритма, может я что-то не понял, но твое определение звучит как чушь, никакого консенсуса так достичь нельзя.
G>https://users.ece.cmu.edu/~adrian/731-sp04/readings/GL-cap.pdf

Дай ссылку на алгоритм.

G>почему ты считаешь что нельзя, если так работает в жизни?

Это не работает. Есть 3 ноды, пришла информация, что у Васи счет пополнился на 100 рублей, на 2 нодах информация обновилась, а третья отвалилась, согласно твоей трактовке все ок, ведь N/2+1 нод имеют актуальные данные. Тут 3 очухалась, а вторая отвалилась и вот сюрприз — мы имеем конфликт. А если еще и первая стала недоступна, то третья начинает распространять недостоверную информацию.

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

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

DI>>>Дай ссылку на определение, а то на мой взгляд ты как-то очень своеобразно трактуешь САР теорему. В теореме вообще про узлы ничего нет, там только про свойства системы.

G>>https://users.ece.cmu.edu/~adrian/731-sp04/readings/GL-cap.pdf
G>>Про узлы там есть, nodes если что это узлы

DI>Я просил дать определение CAP теоремы (она же теорема Брюера), ты дал ссылку на статью Сета Гилберта и Ненси Линч, где они рассматривают один из случаев когда CAP теорема выполняется. Что это было?
Я дал ссылку на доказательство. Другого не существует.
Вы же не хотите сказать что пользуетесь "теоремой" в другой формулировке или в других условиях, в которых она недоказана?

DI>Дай ссылку на алгоритм.
Они описаны в доказательстве.

G>>почему ты считаешь что нельзя, если так работает в жизни?

DI>Это не работает. Есть 3 ноды, пришла информация, что у Васи счет пополнился на 100 рублей, на 2 нодах информация обновилась, а третья отвалилась, согласно твоей трактовке все ок, ведь N/2+1 нод имеют актуальные данные.
Да. При чтении 1 и 2 ноды данные будут согласованы. Третья не будет отвечать.

DI>Тут 3 очухалась, а вторая отвалилась и вот сюрприз — мы имеем конфликт.
Нет, третья нода получит лог от первой и тоже станет согласованной.

DI>А если еще и первая стала недоступна, то третья начинает распространять недостоверную информацию.
Нет, так как кворума не будет.

Вы точно хотите поспорить с тем, что у же работает на практике?

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

C>Все "взрослые СУБД" не являются available.
Совершенно верно. Это еще один из пунктов критики CAP — в формальном доказательстве этой теоремы требования availability на столько параноидальные, что им не удовлетворяет ни одна реальная система. Что делает теорему бесполезной, в практическом смысле.

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

IB>Смело, но глупо, утверждать что это так =)

Вы снова что-то понаписали, но проигнорировали прямые вопросы, это уже даже не смело, а просто глупо — пытаться оставить последнее слово за собой.

IB>Если я правильно расшифровал вашу логическую цепочку, то вы ставите знак равенства между Partition и Scalability и по вашему они означают одно и тоже.

Я это не говорил, я говорил, что горизонтальное Scalability вытекает из Partition, никак по другому горизонтально масштабироваться не получится.

IB>Но тогда ваши претензии к failover системам не состоятельны

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

IB>так как partition там уже присутствует, а значит они scalable согласно вашему же определению.

Это вообще к чему?

Начинали с обсуждения этой архитектуры: "Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер." Еще раз вопрос, как это может масштабироваться?

DI>Еще раз. У тебя 300К запросов в секунду, а 1 сервер не вывозит больше 50К.

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

Я тоже так умею: прекрасный мастерлесс кластер не выдерживает больше 50к запросов в секунду, а пришло 300к запросов. Ну и нахрена теперь нужен мастерлесс кластер?

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

DI>Конечно, там таких слов нет, вот только сразу как начинаешь горизонтально масштабироваться немедленно возникает угроза разделения кластера.
Смотря как масштабироваться. Чистый шардинг создаёт нулевую угрозу разделения кластера.

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

DI>>Если падает мастер, то арбитр назначает нового, а старого изгоняют из кластера. Если падает арбитр, а мастер работает, то кластер остается рабочим. Если к падению арбитра добавляется падение мастера, то кластер все равно не приходит в неконсистентное состояние, так как сами ноды стать мастерами самостоятельно не могут, при этом кластер вполне может оставаться доступным на чтение. Компромисы в действии.
S>Ну вот видите, CAP запрещает, а кластер работает. Как так?

Я хз, ты читать не умеешь? Или с интеллектом что-то? Прям в этом описании есть сценарий, когда кластер перестает быть доступным на запись.

Здравствуйте, Denis Ivlev, Вы писали:
DI>Я хз, ты читать не умеешь? Или с интеллектом что-то?
Коллега, вам так нестерпимо хочется в бан? Вы не стесняйтесь — пишите напрямую модераторам. Это быстрее и эффективнее.
DI>Прям в этом описании есть сценарий, когда кластер перестает быть доступным на запись.
Да, есть. Но вы же сами зачем-то упомянули про то, что он в это время доступен на чтение. Значит, вас не устраивает бинарная трактовка availability — с практической точки зрения, частичная availability лучше, чем никакая; а CAP с её черно/белой трактовкой не даёт никаких основ для рассуждения о частичной availabilty. За это мы её и не любим.

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

DI>Я уже ору с рсдн экспертов, ты снова пробил дно. Любой шардинг — деление данных по какому-то признаку, обычно просто берут хеш от первичного ключа, и считают по нему номер сервера (тупо) или виртуального бакета.
Попробуйте перестать орать и начать разговаривать спокойно.

S>>а в требования consistenсy не входит ссылочная целостность.
DI>А это ты что сочинил?
Эмм, вы не знаете что такое "ссылочная целостность"?

S>>Простейший пример — энциклопедия, которую мы делим на шарды по префиксу ключа.
S>>То, что в таком сценарии разделение кластера нам не грозит — очевидно, или нужно пояснять?

DI>Конечно не очевидно, поясняй, я пока за попкорном схожу.
Ок, поясняю: поскольку ссылочная целостность нас не интересует, падение связи с любым из шардов нам ничем не грозит. Ну, вы там выше написали ваше понимание шардинга — вот в нём мы тупо по хешу первичного ключа однозначно получаем номер сервера. Запись и чтение по первичному ключу идут туда. Если сервер временно недоступен, мы просто ждём его возврата в строй. Под consistency мы здесь понимаем всего лишь то, что читаем то, что записали.
Если есть какой-то способ потерять consistency в этом сценарии — покажите.

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

DI>>Конечно не очевидно, поясняй, я пока за попкорном схожу.
И мне захвати, плз. Sinclair оплачивает банкет.

S>Ок, поясняю: ... Если сервер временно недоступен, мы просто ждём его возврата в строй.
Иначе говоря — нам придётся, например, вводить таймаут, который может генерировать timeout _error_. Ибо бесконечно долго работающих алгоритмов не бывает по определению. Т.е. CP-система, Availability нет. Что сказать-то хотел?

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

IB>>Я утверждаю, что throughput адекватнее и практичнее CAP.
CK>что значит адекватнее?
Значит ближе реальному миру и позволяет принимать реальные технические решения.

CK>ошибочный ответ может быть адекватным в каких-то случаях, например если требования к целостности данных высокие (финансовые данные) и мы, например, через 2PC коммитим данные в разные ДЦ, то отдать ошибку при network partition — вполне адекватный ответ, а отдать не ошибку и допустить рассогласованность — недопустимо
Но тогда это уже не соответствие требованию throughput, так как ошибка означает, что запрос не обработан.
То есть требование пропускной способности 1B R/S, означает, что весь этот 1B должен успешно обработаться, а не абы как.

CK>throughput не замена а дополнение, это вообще про разное
Конечно про разное, CAP нельзя использовать в реальной жизни, а пропускную способность — можно.

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

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

G>>Ты же понимаешь, что всем было бы насрать на readiness в этом случае? Или сразу бы спросили — как это соотносится с доступностью?
G>>Потому что доступность выраженная в процентах это то что нужно людям, и то за что они готовы платить. А readiness — непонятное свойство алгоритма, в непонятной вычислительной модели, которое еще и не дает никаких гарантий.

CK>людям нужна гео-репликация, сейчас даже сайты, торгующие одеждой хостятся в нескольких ДЦ
Это какие?

CK>собственно, без непонятного свойства этого не добиться
Все равно не продашь, придется объяснять связь с настоящим availability.

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

IB>>>Если не понятно, могу разжевать еще раз, мне не сложно ))
DI>>Да, напиши как это может горизонтально масштабироваться.
IB>Я же отвечал на вопрос "зачем оно тогда надо?", повторить?

Что говоришь? Я тебе в штаны насрал? Лол, отдыхай, болезный. Еды не будет, гуляй, тролятина.

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

DI>Я знаю, что такое ссылочная целостность, но не понимаю, что это значит в контексте выдуманного тобой "чистого шардинга".
Это значит, что нам наплевать, если данные с одного шарда ссылаются на данные с другого шарда, а этих данных на другом шарде нет.

DI>А, теперь понял, ты про то, что данные со всеми зависимостями находятся на одном шарде. Твой пример с энциклопедией здесь, кстати, не в тему, так как ты пойдешь по ссылкам из статьи и окажешься на другом шарде, ну или надо вообще всю энциклопедию держать на 1 шарде, что уже вырожденный случай.
Как я уже сказал, по условиям задачи нас не волнует перспектива пойти по ссылке, которая никуда не ведёт.
DI> Вернемся к САР с которым ты как Дон Кихот борешься — в предложенном тобой "чистом шардинге" напрочь отсутствует буква А. Если побороться за А, то придется сделать репликацию и мы можем потерять С из-за разделения мастера и реплики.
Ну вот, теперь можно вернуться к разговору о failover cluster. Масштабирование мы уже получили, безо всяких угроз разделения кластера. Теперь заменим каждую ноду на failover cluster, и получим ту самую A.

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

DI>Вот этот сценарий не рассмотрели:
DI>И этот:
Оба сценария рассмотрены в DDIA. Не вижу смысла пересказывать всю книгу в форуме.

DI>>>ну ок, допустим сама нода крайне живучая и никогда не отказывает, но что делать с каналом, через который она общается с внешним миром?
S>>Faoliver Cluster не решает проблему живучести канала. Хотя для её обеспечения тоже есть механизмы — например, всё то же дублирование.
DI>И мы напарываемся на проблему синхронизации данных, со всеми вытекающими.
Нет. Дублирование канала связи (например, подключение к internet backbone через двух провайдеров, или наличие двух карточек IO в физическом сервере) никакого отношения к проблеме синхронизации данных не имеет.
S>>Ну, и CAP ничего не говорит про пропадание связи между клиентом и системой.
DI>

DI>Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes

Здесь под нодами понимаются только компоненты кластера, а не клиентские ноды. Если связь пропадёт на стороне клиента, то вообще никакие методики не дадут нам availability, независимо от нашего отношения к consistency.
DI>Ну то есть ты почитал и понял, что в предложенной тобой архитектуре не решены вопросы ни доступности, ни масштабируемости?
Опять всё сначала? Не вижу смысла продолжать дискуссию с оппонентом, который не читает то, что ему пишут.

S>>Вместе с критикой CAP, которая полностью бесполезна для ответов на заданные вопросы.
DI>Я правда недоумеваю, зачем бороться с ветряными мельницами, ну устроен мир вот так — везде компромисы. Обратного так никто из борящихся так и не показал

Мир — да, именно так и устроен. А в CAP никаких компромиссов нет. За это мы её и не любим.

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

DI>>Вот этот сценарий не рассмотрели:
DI>>И этот:
S>Оба сценария рассмотрены в DDIA. Не вижу смысла пересказывать всю книгу в форуме.

Я если что книгу читал и нет там рецептов как в таких сценарий сделать систему поддерживающей все три буквы: САР. Если я ошибаюсь ну ткни пальцем.

DI>>

DI>>Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes

S>Здесь под нодами понимаются только компоненты кластера, а не клиентские ноды.

Так и я про члены кластера. Твоя архитектура не учитывает, что в кластере из чудесных высоконадежных компонентов, может пропадать связь между компонентами.

DI>>Ну то есть ты почитал и понял, что в предложенной тобой архитектуре не решены вопросы ни доступности, ни масштабируемости?
S>Опять всё сначала? Не вижу смысла продолжать дискуссию с оппонентом, который не читает то, что ему пишут.

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

DI>>Я правда недоумеваю, зачем бороться с ветряными мельницами, ну устроен мир вот так — везде компромисы. Обратного так никто из борящихся так и не показал

S>Мир — да, именно так и устроен. А в CAP никаких компромиссов нет. За это мы её и не любим.

Это демагогия — выражение "все в мире компромисы" не верно, так как бескомпромисно.

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

S>>И всё. Вот вам бесславный финал CAP теоремы.
·>Эээ?
Ооо, да. Внезапно оказывается, что CAP из абсолюта превращается в относительность — стоит чуть подкрутить таймаут, и внезапно P перестаёт быть P.
·>А они не существуют? Один сервак — типичная CA-система.
Вы шутите? Откуда в нём возьмётся А? Вас не настораживает то, что в любом разговоре о high availability начинается с замены 1 машины кластером?

·>Задача есть и решения есть.

·>Но не консистентной.
Да ну?

·>Я делаю перевод с аккаунта 1, на аккаунт 2. Как я потом могу делать перевод с 2 на 3 или с 1 на 4, если произошло разделение? Если допускать овердрафты и рисковать потерями денег, то система будет AP. Если не допускать, то CP (некоторые переводы не будут проходить). Либо сделать чтобы не было разделения — всех клиентов послать в одно отделение банка и пусть там стоят в одной очереди, то будет CA (правда в этом случае клиенты скорее всего просто пойдут в другой банк). Четвёртого не дано.

Во-первых, сведя всё к одному серверу, А вы не получите, как я уже упомянул. Вы её не улучшите, а ухудшите.
Во-вторых, вы опять забываете про то, что "разделение" — это временная штука. Если у нас время восстановления меньше, чем SLA на транзакцию по переводу денег, то система будет CAP.
В-третьих, в задаче про переводы денег, как и в любой другой, нас интересует не 100% Availability, а "экономически оправданная". И если мы внимательно рассмотрим требования и возможности, то окажется, что мы можем сделать так, что даже при разделении кластера у нас будут падать не все запросы, а только достаточно небольшая их доля. При определённых усилиях окажется так, что эта доля будет меньше доли запросов, которые падают по несвязанным с разделением причинам.
Опять-таки, CAP нам в этом никак не поможет.

S>>Нет, это опровергает ваше утверждение.
·>Которое?
"алгоритм сортировки нельзя сделать быстрее чем O(n*log(n))"

·>Ну так нельзя же. Ты почему-то опровергаешь то, что теорема не утверждает. "Вечного двигателя не существует", а ты это опровергаешь "Но ведь двигатели же существуют!"

Очень хороший пример. С точки зрения инженерной науки, теорема Карно гораздо полезнее теоремы о невозможности вечного двигателя.

·>Да говорю же, CAP не про ломаемость\починимость. А про то, какими свойствами могут обладать любые возможные алгоритмы с учётом того, что что-то в принципе может поломаться.
Непонятно, почему вы так упорно не хотите учитывать возможность исследовать свойства алгоритмов с учётом того, что что-то сломанное в принципе можно починить.

S>>>>Если мы зададим ожидаемую частоту выхода сегментов из строя (MTBF), то для любого наперёд заданного показателя Availability мы сможем рассчитать потребную величину таймаута — с учётом того, что несколько сбоев могут наложиться друг на друга.
S>>·>А если получится так, что эта величина таймаута выше возможной?
S>>Тогда у нас будет повод изменить MTBF сегментов — например, продублировав их.
·>И как же держать дубликаты in-sync без потери C или A?
Очень просто: берём 2 (два) провода, воткнутые в две сетевые карточки. Сможете сами рассчитать вероятность выхода из строя одновременно обеих, если вероятность выхода из строя одной известна?

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

DI>>Что говоришь? Я тебе в штаны насрал?
IB>Так

Соси лапу, тролятина, не подаю.

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

DI>Тролятина, еды нет, соси лапу.
Да вы еще уныло однообразны — полная печаль...

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

C>Уточню. "C" или есть, или его нет. Это как беременность.
Это смотря как это С определить. В одном определении его нет, а в другом — есть.

C>Если "C" нет, то есть разные варианты "eventual consistency". И да, eventual consistency вполне удовлетворяет большинство компаний.
Ровно потому, что определение С подбиралось так, чтобы получить красивую теорему, а не решить практическую задачу.

Здравствуйте, Cyberax, Вы писали:
C>Основная проблема — трафик синхронизации масштабируется экспоненциально с ростом числа узлов в CP-системах. В CA-системах с ростом числа узлов экспоненциально увеличивается риск отказа.
Спасибо, очень интересно!
Хотелось бы почитать про это более подробно, с формулами и доказательствами. Это как раз то, что я ищу.
По идее, это даст возможность получить ту самую математику, которой не хватает — формулу, которая связывает не булевые, а рациональные значения C, A, и P.

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

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

Общепринятое определение availability — количество времени, которое система (либо ее часть) была недоступна.

(525600 − M) ÷ 525600 (где М — время простоя в минутах)

5 минут простоя — пять девяток
60 минут простоя — четыре, итд

S>Эта неожиданная на первый взгляд трактовка как раз и лежит, в частности, в основе географического сегментирования — когда теряется связь с удалёнными узлами, я всё ещё могу работать с локальными данными. Это гораздо лучше, чем полный отказ в обслуживании.

ты это как-то по особенному понимаешь, при "географическом сегментировании" я хочу иметь доступ ко всем данным, даже если один дц недоступен

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

availability из CAP не имзеряется в девятках, ты это понимаешь, о чем тогда спор?

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

с этим я изначально и не спорил

S>Поэтому я не вполне понимаю, как можно без лукавства привлекать эту теорему для обоснования каких-либо решений. Вот вы приходите ко мне, и говорите: "я предлагаю сделать вот такую AP систему, потому что CAP не даёт нам возможности получить CAP-систему". А я вам отвечаю: "ок, то есть ваша система — она прямо вся такая A, несмотря ни на какие P"? Вы мне: "ой, нет, DC, в котором она развернута, даёт A=99.95%". Тогда я вам говорю: "а нахрена вы мне приносите P-систему, в которой нет ни A ни С? Давайте вы лучше мне сделаете CP-систему, которая имеет A в 99.9%. 0.05% сожрал DC, я даю вам ещё 0.05% A на обеспечение С".

опять заворачивание всего в один юзкейс?

вот тебе другой юзкейс, один поисковик собирает клики пользователей и записывает их в распределенное хранилище, данных прилетает примерно петабайт в день, консистентность не нужна

или вот такой — наш интернет магазин доставляет товары в ЮВА, Европе и Америке, сделай так, чтобы данные хранились и обрабатывались как можно ближе к пользователю

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

Бедные SRE то тут причем?

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

MA>твой ~~хваленый~~ Raft видимо нихера не работает.

Хочешь обсудить Рафт? Давай обсудим. Итак, когда он не работает?

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

DI>>И что я подменил?
S>С вопроса "принципы масштабирования failover cluster" мы переходим к вопросу разработки всеобъемлющей архитектуры с неизвестными заранее требованиями по масштабу, временам отклика, надёжности, и функциональности.

Мы до этого еще не дошли, застряли на масштабировании failover cluster, ты как-то все время делаешь вид, будто вопрос закрыт и упорно игнорируешь мои доводы, что никакой масштабируемости там нет.

DI>>Все? Ожидаемо оказался заборот САР, "чистый шардинг" сдулся. Ну и стоило ли упрямствовать?
S>Если вас интересует математическое обоснование построения CAP-системы, то лучше всего почитать работу про совмещение real-time causal consistency с always-on availability. Это гораздо более интересный результат, чем CAP.

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

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

CK>Мне не нужно от лога к availability переходить, у меня есть мониторинг, в котором это все считается.

)
1. А мониторинг как работает? Он не делает запросы?
2. Вы понимаете, что если мониторинг показывает, что "всё ок", а клиент получает таймаут, то прав клиент, а не мониторинг? Ну, и наоборот — тоже?

CK>Что именно тебе кажется смешным? Доступность данных при недоступности одного ДЦ или отключение ДЦ для тестирования?
Мне кажется смешным такая вот бескомпромиссная трактовка Availability. Реальные системы запросто жертвуют доступом к части данных, продолжая работать с тем, что есть.
Вот, первое что в голову пришло — aviasales прекрасно продолжают отдавать результаты, даже если связь с одним из поставщиков временно нагибается.

CK>1. да, имеет смысл обрабатывать специальным образом
CK>2. делать недоступной всю систему тоже делать не стоит
CK>3. делать независимую систему на каждый регион, объясняя это какими-то своими домыслами — неправильно
CK>4. если решишь подумать, как можно добиться 1. и 2. без 3., то тебе вероятно понадобится САР в твоих рассуждениях
Опять косвенные соображения. Мы дождёмся примера применения CAP в рассуждениях архитектора системы? Пока что получается так, что все содержательные мысли образуются без помощи CAP.

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

CK>В нашем случае используется black-box мониторинг, который работает отдельно от основной инфраструктуры, в нескольких георграфически удаленных регионах, он делает запросы в API и измеряет время отклика.
Ну вот, то что я предлагаю, вид сбоку.
CK>Если заданное количество агентов не получили ответ от сервиса, или получили, но с превышением таймаута, заданного в SLA, поднимается alert, регистрируется начал инцедента. Когда все агенты снова получили ответ, генерируется новый alert и регистрируется окончание инцидента.
Ну, то есть пока падает меньше выбранного вами процента запросов, вы считаете, что система available.
CK>Есть метрика в графане, которая по этим данным рисует доступность.
CK>Это довольно распространенное решение, datadog и alertra считают availability похожим образом.
То, что вы рассказываете — это попытка получить приближение к "настоящей" формуле availability при отсутствии возможности её прямого измерения.
Когда мы проектируем систему, мы оперируем не black box availability, а предсказываем реальное поведение.
S>>Мне кажется смешным такая вот бескомпромиссная трактовка Availability. Реальные системы запросто жертвуют доступом к части данных, продолжая работать с тем, что есть.
CK>Еще раз, мне интересны распределенные системы в общем и распредленные БД в частности. Мне не очень интересны системы, где можно пожертвовать частью данных, такие как сайты с котиками и онлайн агрегаторы, торгующие авиабилетами. В контектсе баз данных, потеря 1/N данных, при отказе одного из N датацентров — неприемлема.
Нет никакой потери.
CK>Aviasales это агрегатор, поставщик — сторонний вендор, а не часть системы. Хорошим примером ялвяется приложение такси. Представь, что у яндекса накрылся один ДЦ и 1/(количество Дц) клиентов не может использовать сервис, и такая же доля водителей не может принимать и завершать заказы.
Во-первых, не 1/N. А 1/(N в большой степени), потому что тут не "DC накрылся", а произошёл network partition. В итоге клиенты из Новосибирска не могут вызвать такси в Москве. К счастью, таких запросов — 1 на миллион, поэтому почти никто не заметит потери. Нам важно дать возможность клиентам в Нске заказывать машину в Нске, а Москвичам — в Москве. Причины очевидны или надо разжёвывать?
Ну, и конечно же система, которая продолжает принимать заказы из Нска в Москву без гарантии их выполнения (нарушение консистентности) гораздо хуже системы, которая честно говорит "сервис заказа в данном городе временно недоступен, попробуйте позже".
CK>То, о чем ты говоришь, называется graceful service degradation. Хорошая вещь, но в качестве дополнения, а не как единственное поведение в случае проблем.
Речь не о единственности, а о том, какой показатель показывает хорошесть этой вещи. Опять таки, с точки зрения бескомпромиссной availability все эти изобретения бесполезны — они не улучшают измеряемый показатель.
Расскажите, какую именно метрику вы улучшаете при graceful degradation?

CK>Я не могу сделать эти шаги за тебя.
Попробуйте сделать их за себя. Пока что продемонстрировано не больше пользы от CAP, чем от иконы на приборной доске автомобиля.
CK>Попробуй DDIA прочитать более внимательно что-ли.
Я уже почитал. Особенно вдохновляет раздел The Unhelpful CAP Theorem.

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

CK>некоторые системы сложно классифицировать и не очень то нужно, поэтому в этом случае лучше обойтись без CAP
А в каком случае не лучше обойтись без CAP?

CK>до этого там идет не менее интересный фрагмент, который ты решил не включать, там как раз про полезность
Который?

Здравствуйте, 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.

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

Здравствуйте.

У нас тут с Синклером вышла интересная дисскуссия по поводу теории распределенных систем, где был затронут ряд вопросов на счет матиматического обеспечения данной теории, и о теореме CAP в частности. Итак:

1) Вот у нас имеются отдельные ненадежные(шумящие) компоненты и ненадежный(шумящий) канал. И вот с помощью целой теории,
в основе которой лежат теорема Котельниова-Шеннона и просто Шеннона, суть которых в том, что из ненадежных
отдельных компонентов и ненадежного канала мы можем построить надежную систему до каких-то там девяток -- 99.999(9). Рассмотрим теперь компьютер, который в своих
физических возможностях ограничен -- мы можем одной машиной обработать исключительно конченое число запросов в ед. времени. Если нам нужно обрабатывать сущ. большее кол-во запросов, чем способна обработать одна машина, мы добавляем еще машин и т.д. И у нас также имеется ненадежный канал, сеть. И... вот все, никаких формализмов, никаких мат. формул, да и вообще никакой существенной математики нет. Хотя аналогия с приемом\передачей сигналов и ненадежных компонентов самая прямая. Т.е. из отдельных компонентов с помощью неких законов мы получаем работающую систему. В одном случае разработана целая теория с подробным мат. аппаратом, типа кодирования и восстановления инф-ии, сжатие и т.д. А в другом, кроме CAP, по сути, ничего нет. Нету каких-либо формул, количественных показателей и т.д Т.е. руководства типа если <100 req/sec делай так, > 10000 req/sec то уже так. Построение распределенных систем в некоторой мере искусство, где каждый справляется как может.

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

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

Предлагаю поднятые выше два вопроса обсудить.

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

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

S>>но как-то единой теории с соотв. мат. аппаратом не появилось? Почему?

С>1) Сперва сделают единую теорию, а потом она сломается, потому что у RAID-контроллера прошивка немного кривенькая, но поставщик поставляет as is и ответственности не несёт. Это мосту нужен сопромат, потому что за падение моста и посадить могут, а вот за падение программ и железа никого не сажают.

Так енто должно учитываться.

С>3) Человек, пишущий в Inria на Coq в Мадриде, будет зарабатывать меньше чем энергичный вася, пишущий на JavaScript в Москве. Ну какая тут наука.

Рынок, что поделать...

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

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

IB>Как раз вот это утверждение и подтверждает правоту точки зрения Антона о том, что теорема вредна.
IB>Ведь на самом-то деле нет такого закона как два из трех. На самом деле, возможно все три, все дело в допущениях и граничных условиях. Но "теорема" об этом ничего не говорит, а лишь категорично утверждает, что чем-то надо пожертвовать — а это не правда. То есть CAP намеренно вводит в заблуждение излишне упрощая проблему.

Тот факт, что в ней отсутсвуют количественные характеристики не делает ее бесполезной. А обобщить для допущений и граничных условий, вероятно, не просто, ибо енто уже специфика бизнес области. Т.е. для
каждого будет что-то свое.

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

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

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

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

По идее тут мы жертвуем А, соотв. никто не будет отвечать.

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

Енто зависит от предметной области данного архитектора. И перед ним четко сформулированы компромиссы.
Слушайте, ну ента теорема не решит всех ваших проблем, там действительно нет никаких магических формул. Все чем она может помочь, енто дать представление о тех проблемах с
которыми неминуемо столкнется разработчик распределенных приложений. Я уже в другой дискуссии с Синклером сказал, что да, для людей которые пилят распределенных бд или протоколы данная теорема не очень
интересна, а для массы других разработчиков самое то.

Давайте от противного, а назовите полезную теорему, если таковая имеется, которая поможет разработчикам распр. систем? Вот почитал\изучил, все стало ясно и вперед.

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

Интересно, а енто про частоту откуда?

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

А если 50 на 50?

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

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

Почему тогда до сих пор нету альтернативы? Другая подобная теорема и т.д. Т.е. куча людей разрабатывают системы, которые работают, разрабатывались
с оглядкой на CAP и вдруг хоп, все делают не так. И никакой вменяемой альтернативы не сформулировано, критика есть, альтернативы нет.

G>Про теорему не в курсе, но однозначно разработчика распределенных систем поможет докторская диссертация Роя Филдинга, которая называется REpresentational State Transfer.

На что конкретно в этой работе советуете обратить внимание -- идеи мысли и т.д.? Stateless вещь хорошая, но не всегда возможная.

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

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

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

S>Почему тогда до сих пор нету альтернативы?
Альтернативы чего?

S>Другая подобная теорема и т.д. Т.е. куча людей разрабатывают системы, которые работают, разрабатывались с оглядкой на CAP и вдруг хоп, все делают не так. И никакой вменяемой альтернативы не сформулировано, критика есть, альтернативы нет.
Почему нужна именно теорема? Есть SOA с кучей стандартов построения отказоустойчивых систем, есть REST со своей формулированной семантикой.

G>>Про теорему не в курсе, но однозначно разработчика распределенных систем поможет докторская диссертация Роя Филдинга, которая называется REpresentational State Transfer.
S>На что конкретно в этой работе советуете обратить внимание -- идеи мысли и т.д.?
На все. Там намного больше, чем вы себе представляете.

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

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

S>>Почему тогда до сих пор нету альтернативы?
G>Альтернативы чего?

Теоремы CAP, вестимо.

S>>Другая подобная теорема и т.д. Т.е. куча людей разрабатывают системы, которые работают, разрабатывались с оглядкой на CAP и вдруг хоп, все делают не так. И никакой вменяемой альтернативы не сформулировано, критика есть, альтернативы нет.
G>Почему нужна именно теорема? Есть SOA с кучей стандартов построения отказоустойчивых систем, есть REST со своей формулированной семантикой.

Необязательно, но в данной теме проводится сравнение теории информации, и ее мат. обеспеченность, между теорией распределенных систем и ее полным отсутствие мат. обеспеченности в купе с неудовлетворительной CAP теоремой.
Все-таки странно сравнивать REST и CAP. Кстати, REST стал возможен благодаря вообще удачной web архитектурке в целом.

S>>На что конкретно в этой работе советуете обратить внимание -- идеи мысли и т.д.?
G>На все. Там намного больше, чем вы себе представляете.

Ну можно хотя бы пример на что обратить внимание, помимо REST? Что показалось любопытным при первом знакомтве, на что внимание обратили?

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

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

S> А обобщить для допущений и граничных условий, вероятно, не просто, ибо енто уже специфика бизнес области. Т.е. для
S>каждого будет что-то свое.
Утверждение в этой "теореме" препятствует делать какие либо попытки выяснить "что-то свое".

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

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

1) Железо ломается и чем больше в кластере нод, тем более рядовым явлением становится потеря члена.
2) Системы для которых важна отказоустойчивость и отсутствие потерь данных никогда не работают в одной сети, всегда есть реплицирование как минимум в один другой датацентр.

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

1) Что такое фейловер кластер? Мне понятны слова по отдельности, но не вместе.
2) В каком алгоритме консенсус достигается при половине членов? Насколько я могу представить, наоборот, требуется избыточность.

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

IB>а это не правда

Я попытался себе представить все три из трех, C + A + P, и это сломало мне мозг. Я не могу представить систему, которая во фрагментированном состоянии была бы одновременно консистентна и всегда доступна.

Можете привести какой-нибудь пример, где теорема САР не работала бы?

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

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

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

DI>1) Железо ломается и чем больше в кластере нод, тем более рядовым явлением становится потеря члена.
И? В CAP не рассматривается случай потери одного узла. Там рассматривается разделение сети, когда узлы работают, отвечают клиентам, но не общаются между собой.

DI>2) Системы для которых важна отказоустойчивость и отсутствие потерь данных никогда не работают в одной сети, всегда есть реплицирование как минимум в один другой датацентр.
И? Вопрос пассивных реплик не рассматривается в CAP. Рассматриваются только случаи когда все узлы активные, то есть отвечают на запросы клиентов.

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

DI>1) Что такое фейловер кластер? Мне понятны слова по отдельности, но не вместе.
Это название технологии в Windows Server, а также неофициально применяется для семейства технологий обеспечения отказоустойчивости на основе кворума.

DI>2) В каком алгоритме консенсус достигается при половине членов? Насколько я могу представить, наоборот, требуется избыточность.
В алгоритме синхронного коммита. Когда запрос приходит на узел узел отправляет данные всем остальным узлам и в случае получения подтверждения от N/2+1 узлов отвечает на запрос клиента.

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

G>Представить систему, которая в фрагментированном состоянии консистента и недоступна тоже нельзя.

Почему нельзя-то? Тут как раз легко.
При фрагментации система вам говорит, что не может ответить на запрос до воссоединения с другими узлами. "Ждите".

G>По факту теорема подталкивает к выводу, что самая нужная система — AP — доступная, но не консистентная во фрагментированном состоянии.

Eventual consistency.

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

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

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

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

G>>Представить систему, которая в фрагментированном состоянии консистента и недоступна тоже нельзя.

AK>Почему нельзя-то? Тут как раз легко.
Потому что система недоступная не может обладать никакими потребительскими свойствами.

AK>При фрагментации система вам говорит, что не может ответить на запрос до воссоединения с другими узлами. "Ждите".
Нет ответа — система не доступна — не может быть консистента или нет, потому что... нет ответа.

Я даже где-то умную статью видел, что по нельзя жертвовать доступностью.

G>>По факту теорема подталкивает к выводу, что самая нужная система — AP — доступная, но не консистентная во фрагментированном состоянии.
AK>Eventual consistency.
Это не гарантия, а обещание, которое еще может и не выполниться.

G>>Происходит разделение, один узел теряет возможность общаться с другими.
G>>У нас получается система консистентная, доступная и устойчивая к разделению?
AK>Не получается. Это не консистентная система. Отвалившийся узел не может гарантировать, что его данные верны.
Именно, с точки зрения CAP это так.

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

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

AKЮ>Почему нельзя-то? Тут как раз легко.
G>Потому что система недоступная не может обладать никакими потребительскими свойствами.

Не понял эту мысль.
У вас три сервера и на каждом по пользователю. Один сервер отвалился — его пользователь об этом не знает и продолжает работать. Система недоступна для других узлов, но сама по себе-то она работает.

AK>При фрагментации система вам говорит, что не может ответить на запрос до воссоединения с другими узлами. "Ждите".
G>Нет ответа — система не доступна — не может быть консистента или нет, потому что... нет ответа.

Консистентность это требование непротиворечивости данных.
Отсутствие доступа к данным не нарушает их непротиворечивость — просто вот сейчас операцию выполнить нельзя. И нельзя именно из соображений консистентности.

G>Я даже где-то умную статью видел, что по нельзя жертвовать доступностью.

Там, где нельзя жертвовать доступностью, жертвуют консистентностью. О том, в общем-то, и теорема.

AK>>Eventual consistency.
G>Это не гарантия, а обещание, которое еще может и не выполниться.

Да.

G>Именно, с точки зрения CAP это так.

С любой точки зрения.
У вас остается проблема с тем, что любые изменения, произведенные на отвалившемся узле, не попадут в остальные части системы -> система не консистентна. Если кто-то из клиентов продолжает работать с отвалившимся куском системы, то этот клиент работает с устаревшими данными. До того момента как система восстановится (если вообще когда-нибудь), целостность данных в системе нарушена.

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

G>В жизни отвалившийся узел просто становится не доступен.

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

G> Все клиенты об этом узнают тем или иным способом и подключаются к другим узлам.

Ну вот подключился клиент к другому узлу и обнаружил, что купленный им только что товар пропал из его покупок. Как можно назвать такую систему консистентной?

G>Более того, такое поведение можно заложить в протокол и для клиента это будет прозрачно.

Это понятно. Но это другое.
Я просил пример того, где CAP теорема, якобы, не работает. Вы приводите пример, как жить дальше с отвалившимся куском системы — это другое, это никак не опровергает и не противоречит теореме САР. Вы не можете предоставить строгую консистентность на отвалившемся куске системы.

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

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

AKЮ>>Почему нельзя-то? Тут как раз легко.
G>>Потому что система недоступная не может обладать никакими потребительскими свойствами.

AK>Не понял эту мысль.
AK>У вас три сервера и на каждом по пользователю. Один сервер отвалился — его пользователь об этом не знает и продолжает работать. Система недоступна для других узлов, но сама по себе-то она работает.
Вы сейчас про какую доступность? Про CAP, про обывательскую или какую-то свою?

AK>>При фрагментации система вам говорит, что не может ответить на запрос до воссоединения с другими узлами. "Ждите".
G>>Нет ответа — система не доступна — не может быть консистента или нет, потому что... нет ответа.

AK>Консистентность это требование непротиворечивости данных.
Нет. Это требование "прочитал то, что записал" независимо от того куда придет обращение.

AK>Отсутствие доступа к данным не нарушает их непротиворечивость — просто вот сейчас операцию выполнить нельзя. И нельзя именно из соображений консистентности.
Доступность с точки зрения CAP это то что ЛЮБОЙ узел системы может ответить. И доступность внезапно бинарная. Она или есть или нет.
Если система не испытывает разделения, то она доступна и согласована. Но если мы рассматриваем CP систему, то в момент разделения она становится недоступна и в целом её согласованность уже не интересует (особенно маркетологов NoSQL).

G>>Я даже где-то умную статью видел, что по нельзя жертвовать доступностью.
AK>Там, где нельзя жертвовать доступностью, жертвуют консистентностью. О том, в общем-то, и теорема.
Посыл был в том, что только AP имеют право на существование.

G>>Именно, с точки зрения CAP это так.
AK>С любой точки зрения.
Не с любой.

AK>У вас остается проблема с тем, что любые изменения, произведенные на отвалившемся узле, не попадут в остальные части системы -> система не консистентна. Если кто-то из клиентов продолжает работать с отвалившимся куском системы, то этот клиент работает с устаревшими данными. До того момента
как система восстановится (если вообще когда-нибудь), целостность данных в системе нарушена.
Вы выдумываете определения на ходу. Что по вашему консистнетность, а что написано в CAP ?

G>>В жизни отвалившийся узел просто становится не доступен.
AK>Если этот узел полностью выводится из системы — консистентность может быть восстановлена, но только в случае если на том узле никаких данных не менялось. Если данные менялись, то консистентность нужно как-то восстанавливать уже другими способами.
Если узел недоступен, то очевидно ничего поменяться на нем не может.

G>> Все клиенты об этом узнают тем или иным способом и подключаются к другим узлам.
AK>Ну вот подключился клиент к другому узлу и обнаружил, что купленный им только что товар пропал из его покупок. Как можно назвать такую систему консистентной?
В описанном мной сценарии такого не случится.

AK>Я просил пример того, где CAP теорема, якобы, не работает. Вы приводите пример, как жить дальше с отвалившимся куском системы — это другое, это никак не опровергает и не противоречит теореме САР. Вы не можете предоставить строгую консистентность на отвалившемся куске системы.
Я привожу пример, что может быть доступная и согласованная система при разделении в обывательском понимании. Но с точки зрения CAP система не доступна. Это фактически говорит о том, что CAP не работает нигде и противоречит реальной жизни.

Еще раз прочитайте сначала этот топик, и топик где Синклер объясняет, что эта теорема бессмысленна из-за довольно странной модели в рамках которой она доказывается.

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

DI>>1) Железо ломается и чем больше в кластере нод, тем более рядовым явлением становится потеря члена.
G>И? В CAP не рассматривается случай потери одного узла. Там рассматривается разделение сети, когда узлы работают, отвечают клиентам, но не общаются между собой.

Дай ссылку на определение, а то на мой взгляд ты как-то очень своеобразно трактуешь САР теорему. В теореме вообще про узлы ничего нет, там только про свойства системы.

DI>>2) Системы для которых важна отказоустойчивость и отсутствие потерь данных никогда не работают в одной сети, всегда есть реплицирование как минимум в один другой датацентр.
G>И? Вопрос пассивных реплик не рассматривается в CAP. Рассматриваются только случаи когда все узлы активные, то есть отвечают на запросы клиентов.

Дай ссылку на определение, а то на мой взгляд ты как-то очень своеобразно трактуешь САР теорему.

DI>>2) В каком алгоритме консенсус достигается при половине членов? Насколько я могу представить, наоборот, требуется избыточность.
G>В алгоритме синхронного коммита. Когда запрос приходит на узел узел отправляет данные всем остальным узлам и в случае получения подтверждения от N/2+1 узлов отвечает на запрос клиента.

Дай ссылку на описание алгоритма, может я что-то не понял, но твое определение звучит как чушь, никакого консенсуса так достичь нельзя.

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

S>>Необязательно, но в данной теме проводится сравнение теории информации, и ее мат. обеспеченность, между теорией распределенных систем и ее полным отсутствие мат. обеспеченности в купе с неудовлетворительной CAP теоремой.
S>>Все-таки странно сравнивать REST и CAP. Кстати, REST стал возможен благодаря вообще удачной web архитектурке в целом.
G>Не надо искать смвсл там где его нет. CAP и теория информации не связаны.

Конечно не связаны. Я сравнивал теорию инф-ии с ее мат. аппаратом и кучей теорем, и теор. распр. систем с... только CAP теоремой, которые тут многие считают крайне неудачной. Почему так?

G>Диссертация Филдинга ориентирована на реальный мир и практическая полезность максимальная.
G>Почему их нельзя сравнивать? Их сравнивать нужно.

Холодное с мягким. Одно дело некий закон, теоерма "2 из 3", другеое дело методология и подход. Пусть второй и полезнее первого (подход над теоремой).

IB>Вы телегу впереди лошади ставите. Сначала появилось куча распределенных систем и NoSQL, а уже потом, как объяснение того, почему они так херово работают, маркетологи придумали CAP теорему.

Теорема появилась в 1998-м году. CouchDB, который и начала хайп NoSQL появился в 2005-м.

А куча распределенных систем... Ну она стала появляться как раз в середине 90-х. И CAP, как теорема, была сформулирована человеком, который собственно и занимался распрделенными системами в Inktomi.

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

CK>Ерунду он там написал, хотя бы потому что он SLA путает с availability.

Почему SLA не может выступать количественной характеристикой availability?

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

Маленький оффтоп:

CK>Availability в CAP — это свойство алгоритма. Это аналог сложности алгоритма или lock free/wait free гарантии в многопоточном программировании. Там ты тоже на практике можешь получить ситуацию, когда lock free алгоритм заблокировался, например в случае priority inversion,

Навереное не алгоритм заблокировлся, а поток, его исполняющий?

CK> или O(N) будет быстрее чем O(LogN).

Это когда данные есть в кэше или неудачный pivot в quick sort?

IB>Хронологически да, да и то не совсем. в 98 появился принцип CAP, а теорему из него сделали позже и другие люди.
IB>Но по факту, про САР вспомнили, когда надо было объяснить почему NoSQL работают так как работают...

The theorem first appeared in autumn 1998. It was published as the CAP principle in 1999 and presented as a conjecture by Brewer at the 2000 Symposium on Principles of Distributed Computing (PODC).[9] In 2002, Seth Gilbert and Nancy Lynch of MIT published a formal proof of Brewer's conjecture, rendering it a theorem

Как ни крути, твой таймлайн не бьется.

M>>А куча распределенных систем... Ну она стала появляться как раз в середине 90-х. И CAP, как теорема, была сформулирована человеком, который собственно и занимался распрделенными системами в Inktomi.
IB>Да, и этот же человек позже вынужден был писать объяснение, что вы все не правильно CAP понимаете, и я вовсе не это имел ввиду.

Тебя удивляет, что люди неправильно понимают теоремы? Особенно если они их не особенно-то и читают? Тут рядом REST упоминали. Диссертация по RESTу — 2000-й год. 19 лет спустя единицы читали, вообще мало кто понимает за пределами упрощенных и неправильных объяснений.

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

CK>а в чем заключается вред?
В том что в общепринятом понимании, первоначальный смысл CAP искажается на противоположный. Как вы совершенно верно заметили, мало кому приходит в голову что CAP описывает не работающую систему, а сломанную.

CK>я там хотел сказать, что система, которая обрабатывает вот прямо сейчас 100% запросов не обязательно является available в терминах САР
Вот в этом месте мы опять рискуем оказаться в терминологической ловушке. Если под "обрабатывает" имеется ввиду "отвечает", то она таки 100% available в терминах CAP.

CK>в терминах САР, упавший узел просто не отвечает на запросы
Какое время он не отвечает на запросы?

CK>САР описывает поведение модели, не реальной системы.
То что это модель, не избавляет от необходимости описывать модель достаточно точно. Иными словами — херово описывает.

CK>Асинхронная сеть, это модель, в которой сообщения могут теряться, или доставляться за какое-то неопределенное, но ограниченное время.
А за какое? почему оно неопределенное? Почему ограниченное и чем?

CK>Это все не имеет прямой связи с реальностью, это изначально упрощенная модель,
Модель не имеющая связи с реальностью, не имеет практического смысла.

CK> но ты не сделаешь распределенную систему, которая обходит ограничения САР, поэтому ее нужно понимать все равно.
При определенных допущениях можно сделать такую распределенную систему, где "ограничения CAP" можно игнорировать и считать что их нет. Но CAP ни каким образом не помогает понять параметры этих допущений.

CK>Поэтому в этом обсуждении, очевидно, что многие не понимаю САР, потому что они атакуют те выводы, которые с помощью САР сделать нельзя.
Они атакуют CAP за те выводы, которые с помощью CAP сделать можно, и которые были сделаны, не смотря на то, что самой CAP эти выводы даже не предполагались.

CK>Это не имеет отношения к САР. Ни диск, ни фигня, которая с него считалась. Как можно говорить о САР, когда у тебя одна машина?
Это имеет самое прямое отношение к CAP. Собственно consistency в понимании CAP — предполагает, что весь набор узлов — это одна машина. И весь этот набор должен возвращать одинаковый результат. A partition tolerance уточняет, что машина на самом деле не одна и что между ними возможна не согласованность. (Собственно, это еще один пункт критики CAP, что она не явно связывает partition tolerance и consistency)
Иными словами, модель описанная CAP — это частный случай обычной записи, где вероятность сбоя одного конкретного типа сильно выше. И дальше разбирается, что можно с этим сделать, когда такой сбой произошел.

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

CK>Не важно, кажется ли тебе выбор, который предлагает сделать САР правильным или не правильным, тебе его придется сделать, так или иначе. Это фундаментально ограничение, которое не обойти.
Вот это как раз тот самый ложный вывод к которому подталкивает CAP.
В реальной жизни, можно подобрать параметры такой системы, в которой этот выбор делать не придется.

CK>"Что считать сбоем" можно выразить числом?
Временем отклика, например.

CK>В рамках САР, если у тебя есть N узлов и происходит network partition, который делит их на две части, ты пытаешься прочитать значение, но тебе доступна только половина узлов, соотв. ты можешь либо прочитать то что доступно (PA) либо выдать ошибку (PC). Эта ситуация легко транслируется на реальные системы. Соотв. вопрос. Что здесь численно измерять? Что здесь может быть неверно? Почему ты считаешь что тут выбор делать может быть не нужно?
Требуемое время отклика узла, время отклика системы, требования к согласованности и т. д, там дофига параметров.
А выбор делать не нужно, например, в том случае, когда время отклика узла меньше чем требуемое время отклика всей системы.

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

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

DI>>>1) Железо ломается и чем больше в кластере нод, тем более рядовым явлением становится потеря члена.
G>>И? В CAP не рассматривается случай потери одного узла. Там рассматривается разделение сети, когда узлы работают, отвечают клиентам, но не общаются между собой.
DI>Дай ссылку на определение, а то на мой взгляд ты как-то очень своеобразно трактуешь САР теорему. В теореме вообще про узлы ничего нет, там только про свойства системы.

https://users.ece.cmu.edu/~adrian/731-sp04/readings/GL-cap.pdf
Про узлы там есть, nodes если что это узлы

DI>>>2) Системы для которых важна отказоустойчивость и отсутствие потерь данных никогда не работают в одной сети, всегда есть реплицирование как минимум в один другой датацентр.
G>>И? Вопрос пассивных реплик не рассматривается в CAP. Рассматриваются только случаи когда все узлы активные, то есть отвечают на запросы клиентов.
DI>Дай ссылку на определение, а то на мой взгляд ты как-то очень своеобразно трактуешь САР теорему.
https://users.ece.cmu.edu/~adrian/731-sp04/readings/GL-cap.pdf
Я трактую её ровно так, как она доказана, а не так, как работает в голове у некоторых людей.

DI>>>2) В каком алгоритме консенсус достигается при половине членов? Насколько я могу представить, наоборот, требуется избыточность.
G>>В алгоритме синхронного коммита. Когда запрос приходит на узел узел отправляет данные всем остальным узлам и в случае получения подтверждения от N/2+1 узлов отвечает на запрос клиента.
DI>Дай ссылку на описание алгоритма, может я что-то не понял, но твое определение звучит как чушь, никакого консенсуса так достичь нельзя.
https://users.ece.cmu.edu/~adrian/731-sp04/readings/GL-cap.pdf
почему ты считаешь что нельзя, если так работает в жизни?

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

S>Конечно не связаны. Я сравнивал теорию инф-ии с ее мат. аппаратом и кучей теорем, и теор. распр. систем с... только CAP теоремой, которые тут многие считают крайне неудачной. Почему так?
Потому что CAP работает в модели, отличающейся от реального мира. Особенно если обсуждаем доступность.

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

IB>>Вы телегу впереди лошади ставите. Сначала появилось куча распределенных систем и NoSQL, а уже потом, как объяснение того, почему они так херово работают, маркетологи придумали CAP теорему.

M>Теорема появилась в 1998-м году. CouchDB, который и начала хайп NoSQL появился в 2005-м.
Теорема появилась в 2000, доказана в 2002.
https://users.ece.cmu.edu/~adrian/731-sp04/readings/GL-cap.pdf

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

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

CK>>а в чем заключается вред?
IB>В том что в общепринятом понимании, первоначальный смысл CAP искажается на противоположный. Как вы совершенно верно заметили, мало кому приходит в голову что CAP описывает не работающую систему, а сломанную.

так читать же нужно

CK>>я там хотел сказать, что система, которая обрабатывает вот прямо сейчас 100% запросов не обязательно является available в терминах САР
IB>Вот в этом месте мы опять рискуем оказаться в терминологической ловушке. Если под "обрабатывает" имеется ввиду "отвечает", то она таки 100% available в терминах CAP.

нет, СР система может отвечать на 100% запросов

CK>> но ты не сделаешь распределенную систему, которая обходит ограничения САР, поэтому ее нужно понимать все равно.
IB>При определенных допущениях можно сделать такую распределенную систему, где "ограничения CAP" можно игнорировать и считать что их нет. Но CAP ни каким образом не помогает понять параметры этих допущений.

можно тут поподробнее?

IB>Это имеет самое прямое отношение к CAP. Собственно consistency в понимании CAP — предполагает, что весь набор узлов — это одна машина. И весь этот набор должен возвращать одинаковый результат. A partition tolerance уточняет, что машина на самом деле не одна и что между ними возможна не согласованность. (Собственно, это еще один пункт критики CAP, что она не явно связывает partition tolerance и consistency)

С в САР не предполагает такого, С — значит что любой узел вернет один и тот же результат, поэтому не важно, к какому узлу обращаться, история изменений значения регистра будет линейной

CK>>В рамках САР, если у тебя есть N узлов и происходит network partition, который делит их на две части, ты пытаешься прочитать значение, но тебе доступна только половина узлов, соотв. ты можешь либо прочитать то что доступно (PA) либо выдать ошибку (PC). Эта ситуация легко транслируется на реальные системы. Соотв. вопрос. Что здесь численно измерять? Что здесь может быть неверно? Почему ты считаешь что тут выбор делать может быть не нужно?

IB>Требуемое время отклика узла, время отклика системы, требования к согласованности и т. д, там дофига параметров.
что есть "время отклика системы"?

IB>А выбор делать не нужно, например, в том случае, когда время отклика узла меньше чем требуемое время отклика всей системы.
не понял. при partition-е у тебя может не быть отклика всей системы,т.к. часть узлов не доступны

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

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

CK>>>Ну как же, если у тебя скажем не хватает одной записи в таблице в БД №1, но она есть в БД №2, а БД №3 недоступна, ты не сможешь определить, была запись удалена, либо добавлена. Скажем, у тебя возможна ситуация, когда одна БД №1 моргнула, на БД №2 пришел запрос на удаление/добавление, он отработал, синхронно реплицировался на БД №3, после чего БД №3 стала недоступна из-за разделения.
G>>Не выдумывай, репликация делается через ЛОГ, а в нем есть инфа о том, что быдло удалено и добавлено. По крайней мере во взрослых СУБД так.

CK>ты писал — "Простой пример. Кластер из трех БД — все они делают синхронную репликацию на два других узла. Синхронная репликация считается успешной когда хотя бы один узел ответил ОК."
Я имел ввиду, что один узел получил данные, передал двум другим и один из них ответил ОК.

CK>мы говорим "delete foo", это отрабатывает на БД2 и БД3, говорим ОК
CK>БД1 неистово пытается приконнектиться к двум другим, в это время в нее приходит клиент 1, спокойно делает "select * where key=foo" и получает старые данные
CK>клиент 2 делает тоже самое на БД2 и получает другой ответ
БД1, не имея связи с двумя другими вываливается из кластера и перестает отвечать на эти запросы.

CK>БД1 может не принимать запросы на чтение, пока не восстановит подключение к другим БД и не получит от них log sequence number последнего коммита, но это значит что мы потеряли availability
С точки зрения CAP конечно потеряем. С точки зрения потребителя — не потеряем ничего, потребитель просто повторит запрос к другому узлу. Тем более что во многие протоколы уже зашиты повторы.
Об этом и идет разговор.

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

CK>так читать же нужно
Читать не достаточно, нужно понимать. А с пониманием проблемы, и слишком легко понять не правильно и даже не понять о чем там на самом деле речь, однако быть при этом уверенным, что полностью разобрался.

IB>>Вот в этом месте мы опять рискуем оказаться в терминологической ловушке. Если под "обрабатывает" имеется ввиду "отвечает", то она таки 100% available в терминах CAP.
CK>нет, СР система может отвечать на 100% запросов
Если система отвечает на 100% запросов, и все ответы не ошибка, то это уже АP система. То есть 100% available. А если ответы еще и консистентны, то это уже как минимум CA система.

IB>>При определенных допущениях можно сделать такую распределенную систему, где "ограничения CAP" можно игнорировать и считать что их нет. Но CAP ни каким образом не помогает понять параметры этих допущений.
CK>можно тут поподробнее?
Подробнее, в том посте Антона, с которого начался наш диалог. Вкратце, если время пока узлы между собой могут быть не согласованы меньше, чем требуемое время отклика системы в целом, то в такой системе выбор между С и А не стоит, и она всегда согласована и доступна, а значит и CAP к ней не относится.

IB>>Это имеет самое прямое отношение к CAP. Собственно consistency в понимании CAP — предполагает, что весь набор узлов — это одна машина. И весь этот набор должен возвращать одинаковый результат. A partition tolerance уточняет, что машина на самом деле не одна и что между ними возможна не согласованность. (Собственно, это еще один пункт критики CAP, что она не явно связывает partition tolerance и consistency)
CK>С в САР не предполагает такого, С — значит что любой узел вернет один и тот же результат, поэтому не важно, к какому узлу обращаться, история изменений значения регистра будет линейной
Вы фактически повторили то, что я написал, но другими словами — система в целом должна вернуть один и тот же результат, какой бы узел ни отвечал. Поэтому таки да, именно это consistency в CAP и предполагает. Но тот факт, что отвечать могут разные узлы — это уже детали реализации.
Смысл в том, что если в систему записали сначала 1, а потом 2, то вернуть она должна 2. А вот если один из узлов возвращает 1 и система в целом возвращает 1, значит система уже не С.

IB>>Требуемое время отклика узла, время отклика системы, требования к согласованности и т. д, там дофига параметров.
CK>что есть "время отклика системы"?
Это время пока система считается available, ничего не отвечая.

CK>не понял. при partition-е у тебя может не быть отклика всей системы,т.к. часть узлов не доступны
Внешнему клиенту не известно и не должно быть известно что там с системой происходит, из скольких узлов она состоит и какой (какие) узлы ему отвечают. Для него система атомарна и его не должно заботить как она там устроена. Для него всегда откликается система в целом, которая либо возвращает внятный ответ, либо ошибку.

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

M>Как ни крути, твой таймлайн не бьется.
Яж говорю ни когда теорему доказали, а когда про нее вспомнили. Практической пользы от нее нет, зато маркетинговый эффект весьма заметен.

M>Тебя удивляет, что люди неправильно понимают теоремы? Особенно если они их не особенно-то и читают?
Да, удивляет, так как обычно теоремы либо понимают правильно, либо не понимают вообще. А тут каждый понимает по своему, и главное, легко находит подтверждение своему пониманию в самой теореме... До какого-то момента.

M>>Тебя удивляет, что люди неправильно понимают теоремы? Особенно если они их не особенно-то и читают?
IB>Да, удивляет, так как обычно теоремы либо понимают правильно, либо не понимают вообще. А тут каждый понимает по своему

Когда подавляющее большинство читает не теорему, а ее напевания Рабиновичем, то каждый будет понимать по-своему. Не первая такая теорема и не последняя.

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

DI>>Это не работает. Есть 3 ноды, пришла информация, что у Васи счет пополнился на 100 рублей, на 2 нодах информация обновилась, а третья отвалилась, согласно твоей трактовке все ок, ведь N/2+1 нод имеют актуальные данные.
G>Да. При чтении 1 и 2 ноды данные будут согласованы. Третья не будет отвечать.
А как третья нода узнает, что она в оффлайне? Правильно, она должна опросить остальные два узла о том, является ли её sequence number самым последним.

Т.е. произвести кворумное чтение. Упс.

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

C>>Все "взрослые СУБД" не являются available.
IB>Совершенно верно. Это еще один из пунктов критики CAP — в формальном доказательстве этой теоремы требования availability на столько параноидальные, что им не удовлетворяет ни одна реальная система. Что делает теорему бесполезной, в практическом смысле.
Неверно. Например, для DynamoDB в AWS есть формальное доказательство availability и partition tolerance.

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

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

DI>>>Это не работает. Есть 3 ноды, пришла информация, что у Васи счет пополнился на 100 рублей, на 2 нодах информация обновилась, а третья отвалилась, согласно твоей трактовке все ок, ведь N/2+1 нод имеют актуальные данные.
G>>Да. При чтении 1 и 2 ноды данные будут согласованы. Третья не будет отвечать.
C>А как третья нода узнает, что она в оффлайне? Правильно, она должна опросить остальные два узла о том, является ли её sequence number самым последним.
C>Т.е. произвести кворумное чтение. Упс.
Способов много на самом деле, в том числе железные.
Но если рассматривать только возможности СУБД, то да что-то типа кворумного чтения, совмещенного с накладыванием read-lock.
В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.

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

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

G>>Не выдумывай, репликация делается через ЛОГ, а в нем есть инфа о том, что быдло удалено и добавлено. По крайней мере во взрослых СУБД так.
C>Все "взрослые СУБД" не являются available.
Конечно не являются. В терминах CAP. И всем на это насрать. Кроме маркетологов NoSQL.

CK>>>Чтобы система была консистентной, тебе нужно читать кворум, а не одну БД. Если ты будешь это делать, то обнаружишь, что у тебя доступность таки упала, так как в вышеописанном случае, тебе придется вернуть ошибку.
G>>Для консистентности вовсе не надо читать кворум. Это очередные выдумки NoSQL маркетологов. Взрослые СУБД движки вполне обходятся кворумом записи и вовсе не требуется нескольким узлам тратить время на обработку одного и того же запроса.
C>Ну вот потому они и не могут быть available и partition tolerant. Поэтому все "взрослые СУБД" на практике и ограничены одним сервером (максимум, небольшим кластером с быстрыми интерконнектами между узлами).
И снова на это насрать. Всем почему-то кажется что доступность и устойчивость к разделению пипец какие важные свойства. На практике исчезающе мало случаев, когда эти свойства нужны.

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

G>>Не выдумывай, репликация делается через ЛОГ, а в нем есть инфа о том, что быдло удалено и добавлено. По крайней мере во взрослых СУБД так.
C>Все "взрослые СУБД" не являются available.

Это почему?

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

G>И снова на это насрать. Всем почему-то кажется что доступность и устойчивость к разделению пипец какие важные свойства. На практике исчезающе мало случаев, когда эти свойства нужны.

все случаи когда данные живут более чем в одном дц

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

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

G>>И снова на это насрать. Всем почему-то кажется что доступность и устойчивость к разделению пипец какие важные свойства. На практике исчезающе мало случаев, когда эти свойства нужны.
CK>все случаи когда данные живут более чем в одном дц
Резервное копирование и шардинг не имеют отношения к разделению и доступности если что.
Остальных случаев распределения БД в разных ДЦ исчезающе мало.

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

G>Резервное копирование и шардинг не имеют отношения к разделению и доступности если что.

я не про них

G>Остальных случаев распределения БД в разных ДЦ исчезающе мало.

почти любой более или менее крупный проект сейчас живет +1 дц, как минимум amer/emea/apac, облака делают это доступным любому

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

C>>Т.е. произвести кворумное чтение. Упс.
G>Способов много на самом деле, в том числе железные.

Перечисли пожалуйста несколько.

G>Но если рассматривать только возможности СУБД, то да что-то типа кворумного чтения, совмещенного с накладыванием read-lock.

Я вот тебя читаю и недоумеваю, с такой уверенностью говоришь, что кажется, что ты что-то такое знаешь чего не знают другие, но при вчитываешься и ведь такая же чушь.

G>В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.

И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?

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

DI>И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?
Точно так же можно спросить: а зачем оно надо что-то горизонтально масштабировать, если "вертикальных" ресурсов хватает мягко говоря с головой?

G>>В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.
DI>И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?

Это называется Leader election, и вполне себе масштабируется. Понятно, там всегда будут ограничения и edge cases, но надо смотреть на конкретную топологию сети, выбранные алгоритмы и т.п.

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

G>>>В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.
DI>>И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?

M>Это называется Leader election, и вполне себе масштабируется.

Лол, стригерился на кейворд и выдал статью из википедии, рсдн-эксперты, такие рсдн-эксперты. Будь добр, объясни, как может масштабироваться выделенное, а именно: "Все запросы физически идут в одну ноду".

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

C>>Т.е. произвести кворумное чтение. Упс.
G>Способов много на самом деле, в том числе железные.
Нет. Надёжный способ ровно один — сделать кворумное чтение. Есть ненадёжные способы — попробовать обойтись избыточными интерконнектами, и молиться, что не будет координированного сбоя на всех из них. Так, например, работает Oracle RAC.

Но это не масштабируется географически ну совсем никак.

G>В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.
Без разницы куда они идут. Это будет нарушение буквы "A", если часть сети будет изолирована. Либо опять же, кворумное чтение на каждый запрос.

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

M>>Это называется Leader election, и вполне себе масштабируется.
DI>Лол, стригерился на кейворд и выдал статью из википедии, рсдн-эксперты, такие рсдн-эксперты. Будь добр, объясни, как может масштабироваться выделенное, а именно: "Все запросы физически идут в одну ноду".
Лидеров может быть несколько, каждый из которых отвечает за статически назначенный диапазон шардов.

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

G>>>Не выдумывай, репликация делается через ЛОГ, а в нем есть инфа о том, что быдло удалено и добавлено. По крайней мере во взрослых СУБД так.
C>>Все "взрослые СУБД" не являются available.
S>Это почему?
Так как обычно концентрируются на буквах "C" и "P".

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

C>Лидеров может быть несколько, каждый из которых отвечает за статически назначенный диапазон шардов.

1. Это мы уже сами додумываем архитектуру, написано было вполне однозначно: "Все запросы физически идут в одну ноду".
2. Но и в предложенной тобой архитектуре мы не решили добились одновременно соблюдения всех трех пунктов.

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

C>>Все "взрослые СУБД" не являются available.
G>Конечно не являются. В терминах CAP. И всем на это насрать. Кроме маркетологов NoSQL.
Или тем, кому реально нужна availability. Например, в этом году хранилище данных для Amazon в тестах обрабатывало в пике 1 миллиард запросов в секунду. Реальная пиковая нагрузка была где-то треть от этого.

C>>Ну вот потому они и не могут быть available и partition tolerant. Поэтому все "взрослые СУБД" на практике и ограничены одним сервером (максимум, небольшим кластером с быстрыми интерконнектами между узлами).
G>И снова на это насрать. Всем почему-то кажется что доступность и устойчивость к разделению пипец какие важные свойства. На практике исчезающе мало случаев, когда эти свойства нужны.
Это тоже на практике уже не так. Достаточно много клиентов хотят иметь географическую избыточность, чтобы пережить локальный конец света в отдельном ЦОД.

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

C>>Лидеров может быть несколько, каждый из которых отвечает за статически назначенный диапазон шардов.
DI>1. Это мы уже сами додумываем архитектуру, написано было вполне однозначно: "Все запросы физически идут в одну ноду".
DI>2. Но и в предложенной тобой архитектуре мы не решили добились одновременно соблюдения всех трех пунктов.
Да, это чисто практическое решение, когда не нужны атомарные записи в несколько шардов.

DI>Лол, стригерился на кейворд и выдал статью из википедии, рсдн-эксперты, такие рсдн-эксперты. Будь добр, объясни, как может масштабироваться выделенное, а именно: "Все запросы физически идут в одну ноду".

Какие у тебя проблемы с «запросы идут в одну ноду»?

Цитирую специально для тебя еще раз, выделено:

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

Смешно, когда про теоретиков говорят люди, которые готовы обсуждать некое сферовакуумное масштабирование в полном отрыве от реальности.

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

DI>>Лол, стригерился на кейворд и выдал статью из википедии, рсдн-эксперты, такие рсдн-эксперты. Будь добр, объясни, как может масштабироваться выделенное, а именно: "Все запросы физически идут в одну ноду".

M>Какие у тебя проблемы с «запросы идут в одну ноду»?

M>Цитирую специально для тебя еще раз, выделено:

M>

M>Понятно, там всегда будут ограничения и edge cases, но надо смотреть на конкретную топологию сети, выбранные алгоритмы и т.п.

M>Смешно, когда про теоретиков говорят люди, которые готовы обсуждать некое сферовакуумное масштабирование в полном отрыве от реальности.

чувак, сосредоточся. тебя макнули в конкретную майкрософтскую технологию failover cluster. пойди и почитай как оно работает что бы не попадать вот так в просак. нихрена там не масштабируется, потому как требуется полноценная консистентность и никакие Leader election в плане масштабирования не помогут.

Gt_>чувак, сосредоточся. тебя макнули в конкретную майкрософтскую технологию failover cluster.

В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.

По этому описанию это leader election

Gt_> пойди и почитай как оно работает что бы не попадать вот так в просак.

Читаю: https://docs.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-overview

Описан consensus protocol. Про единый физический мастер ничего не написано (или лень искать). Возможно, раньше был единый мастер, теперь заменили.

Gt_> нихрена там не масштабируется, потому как требуется полноценная консистентность и никакие Leader election в плане масштабирования не помогут.

Опять же какие-то сферовакуумные требования.

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

Gt_>>чувак, сосредоточся. тебя макнули в конкретную майкрософтскую технологию failover cluster.

M>

M>В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.

M>По этому описанию это leader election

Gt_>> пойди и почитай как оно работает что бы не попадать вот так в просак.

M>Читаю: https://docs.microsoft.com/en-us/windows-server/failover-clustering/failover-clustering-overview

M>Описан consensus protocol. Про единый физический мастер ничего не написано (или лень искать). Возможно, раньше был единый мастер, теперь заменили.

Gt_>> нихрена там не масштабируется, потому как требуется полноценная консистентность и никакие Leader election в плане масштабирования не помогут.

M>Опять же какие-то сферовакуумные требования.

смеются над твоими верованиями буд-то это масштабируется.

Это называется Leader election, и вполне себе масштабируется.

конкретно майкрософт failover cluster не масштабируется, потому как настоящая консистентность требуется.

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

C>Лидеров может быть несколько, каждый из которых отвечает за статически назначенный диапазон шардов.

Лидеры отвечают только за маршрутизацию\балансировку в шарды или сами могут сохранять у себя данные?

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

C>>>Все "взрослые СУБД" не являются available.
S>>Это почему?
C>Так как обычно концентрируются на буквах "C" и "P".

C "C" понятно, а для одной "взрослой" "Р" зачем? Или речь о кластере из "взрослых" идет?

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

DI>>Лол, стригерился на кейворд и выдал статью из википедии, рсдн-эксперты, такие рсдн-эксперты. Будь добр, объясни, как может масштабироваться выделенное, а именно: "Все запросы физически идут в одну ноду".

M>Какие у тебя проблемы с «запросы идут в одну ноду»?

Как это может горизонтально масштабироваться? Ты так и не ответил. Нечего сказать — гуляй мимо.

M>Цитирую специально для тебя еще раз, выделено:

M>

M>Понятно, там всегда будут ограничения и edge cases, но надо смотреть на конкретную топологию сети, выбранные алгоритмы и т.п.

И? Ну родишь хоть что-то или так и будешь ломать комедию?

M>Смешно, когда про теоретиков говорят люди, которые готовы обсуждать некое

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

M>сферовакуумное масштабирование в полном отрыве от реальности.

Почему это оно сферовакуумное? Если ты никогда не имел данных или запросов столько, что не один сервер не справится, то это не значит, что у других таких задач нет.

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

C>Неверно. Например, для DynamoDB в AWS есть формальное доказательство availability и partition tolerance.
availability в формальных терминах CAP или в каких-то своих?
Если в CAP — рад за них, но в практическом смысле применимость CAP это не увеличивает ни как.

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

C>Или тем, кому реально нужна availability.
Это смотря что понимать под availability. Проблема в том, что даже тем, кому availability нужна CAP не сильно помогает.

C> Например, в этом году хранилище данных для Amazon в тестах обрабатывало в пике 1 миллиард запросов в секунду. Реальная пиковая нагрузка была где-то треть от этого.
Кул! Не, реально круто. То есть, для Amazon понятие Availability означает пропускная способность в конкретных числовых характеристиках — миллиард запросов в секунду. Заметьте, даже не время отклика на один запрос, а общая пропускная способность системы.
Является ли это availability в терминах CAP? А х.з. так как там каждый понимает это по своему, а с формальным определением — печаль. Но скорее всего нет, так как CAP про пропускную способность вообще ничего не говорит, а оперирует только одним запросом. То есть она вообще про другое.

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

IB>А это уже вообще вопрос третий. Слово failover в названии решения как бы намекает на то, что это про availability. А scalability — это уже 4-я буква в уравнении, которой тоже не плохо бы дать определение.
Зависит от задачи. В общем случае failover это только часть availability.
Более точно будет
failover + scalability = availability
Т.е. когда стоит задача "обрабатывать 1млрд запросов в секунду" и чтобы было availability, то никакой failover не поможет.

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

C>> Например, в этом году хранилище данных для Amazon в тестах обрабатывало в пике 1 миллиард запросов в секунду. Реальная пиковая нагрузка была где-то треть от этого.
IB>Кул! Не, реально круто. То есть, для Amazon понятие Availability означает пропускная способность в конкретных числовых характеристиках — миллиард запросов в секунду. Заметьте, даже не время отклика на один запрос, а общая пропускная способность системы.

это не понятие availability, это thoughput

IB>Является ли это availability в терминах CAP? А х.з. так как там каждый понимает это по своему, а с формальным определением — печаль. Но скорее всего нет, так как CAP про пропускную способность вообще ничего не говорит, а оперирует только одним запросом. То есть она вообще про другое.

нет, не является, ведь пропускная способность ничего нам не говорит о том, как поведет себя система (я так понимаю DynamoDB) в случае, если упадет один из регионов, а вот CAP говорит, если система available — она продолжит обрабатывать запросы, если нет — будет недоступна для записи

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

CK>это не понятие availability, это thoughput
Верно. Но не я тут эту характеристику в качестве критерия availability привел, а Амазон. Значит, для амазона это и есть availability.
Собственно, возвращаясь к моему поинту — в реальной жизни это вполне понятный критерий на основе которого можно сторить систему, в отличии от CAP, где даже внятного определения availability нет, и понимай как хочешь.

CK>нет, не является, ведь пропускная способность ничего нам не говорит о том, как поведет себя система (я так понимаю DynamoDB) в случае, если упадет один из регионов, а вот CAP говорит, если система available — она продолжит обрабатывать запросы, если нет — будет недоступна для записи
Ну как же — конечно говорит. Для того чтобы обработать эти запросы, надо отвечать не ошибкой, что бы там с системой внутри не происходило. Таким образом, возвращаясь к предыдущему пункту, критерий "миллиард запросов в секунду", гораздо адекватнее чем CAP.
К слову, про запись CAP тоже ничего не говорит, она говорит, что если с партишеном проблемы, то система либо не гарантирует консистентность, либо не гарантирует ответ. Но ни каких критериев, помогающих понять, что считать проблемами партишена и какой должен быть ответ кап не оговаривает. В чем собственно и проблема.

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

IB>Собственно, возвращаясь к моему поинту — в реальной жизни это вполне понятный критерий на основе которого можно сторить систему, в отличии от CAP, где даже внятного определения availability нет, и понимай как хочешь.

сорян, но ты похоже действительно понимаешь availability как хочешь

CK>>нет, не является, ведь пропускная способность ничего нам не говорит о том, как поведет себя система (я так понимаю DynamoDB) в случае, если упадет один из регионов, а вот CAP говорит, если система available — она продолжит обрабатывать запросы, если нет — будет недоступна для записи
IB>Ну как же — конечно говорит. Для того чтобы обработать эти запросы, надо отвечать не ошибкой, что бы там с системой внутри не происходило.

Ну дык, это можно сделать при упавшем регионе, если система построена как Dynamo, запросы будут возвращать не ошибку. Данные можно будет прочитать и записать. В CP системе (например HBase) так сделать будет нельзя.

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

CK>сорян, но ты похоже действительно понимаешь availability как хочешь

Как и все остальные, если речь идет о CAP, так как внятного определения не дано. Амазон, вот, throughput за availability считает, как мы выяснили, и по своему прав.
"In discussions of CAP there are several contradictory definitions of the term availability,
and the formalization as a theorem [30] does not match its usual meaning [40]." (c)
Теперь понятны притензии к CAP?

CK>>>нет, не является, ведь пропускная способность ничего нам не говорит о том, как поведет себя система (я так понимаю DynamoDB) в случае, если упадет один из регионов, а вот CAP говорит, если система available — она продолжит обрабатывать запросы, если нет — будет недоступна для записи
IB>>Ну как же — конечно говорит. Для того чтобы обработать эти запросы, надо отвечать не ошибкой, что бы там с системой внутри не происходило.

CK>Ну дык, это можно сделать при упавшем регионе, если система построена как Dynamo, запросы будут возвращать не ошибку. Данные можно будет прочитать и записать. В CP системе (например HBase) так сделать будет нельзя.
То есть, вы согласны, что пропускная способность — тоже может являться критерием доступности?

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

IB>>А это уже вообще вопрос третий. Слово failover в названии решения как бы намекает на то, что это про availability. А scalability — это уже 4-я буква в уравнении, которой тоже не плохо бы дать определение.
·>Зависит от задачи.
Совершенно верно. Поэтому я и прошу дать термину определение, прежде чем им манипулировать.

·>В общем случае failover это только часть availability.
·>Более точно будет
·>failover + scalability = availability
О, вот еще одно определение availability, прямо скажем, довольно смелое. Не затруднит дать определение scalability, для начала? А то ведь это тоже довольно растяжимый термин.
Как я писал выше, failover системы о которых идет речь — уже отмасштабированы, только цель масштабирования другая — отказоустойчивость, а не пропускная способность. Таким образом, эта система уже отказоустойчива и отмасштабирована, то есть, согласно вашему же определению — доступна.

·>Т.е. когда стоит задача "обрабатывать 1млрд запросов в секунду" и чтобы было availability, то никакой failover не поможет.
А failover и не должен в этом помогать, он про другое. Собственно, мой поинт был про то, что если система не про бешенную пропускную способность, то это не значит, что она никому не нужна, если посмотреть шире, то есть масса других сценариев, не менее сложных и интересных.
И, собственно, возвращаясь к CAP (напоминаю, мы все еще разговариваем о CAP), то в этом правиле никакого требования про "миллиард запросов в секунду" — нет. Там вообще термин availablity описан довольно не внятно, в чем собственно и проблема.

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

IB>>А при чем тут масштабирование и какое это все имеет отношение к обсуждаемому вопросу? Предлагаю не путать теплое с мягким и с фокусироваться на availability и consistency в терминах CAP. Масштабирование — это другой вопрос, к CAP отношения не имеющий.

DI>Это какое-то лукавство, что значит буква P? Partition tolerance. А откуда оно взялось, ведь взять обсуждаемую архитектуру: все запросы идут в одну ноду, нода синхронно реплицируется (C), если мастер падает, то мастером становится реплика (А) и все запросы теперь идут через нее. Где тут Р? И откуда Р появилась? Ну видимо оттуда, что все запросы в одну ноду стали узким местом и пришлось пустить запросы по разным нодам. Утверждать что это не так — смело, но глупо.
Смело, но глупо, утверждать что это так =) Если я правильно расшифровал вашу логическую цепочку, то вы ставите знак равенства между Partition и Scalability и по вашему они означают одно и тоже. Допустим это так. Но тогда ваши претензии к failover системам не состоятельны, так как partition там уже присутствует, а значит они scalable согласно вашему же определению.

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

IB>Как и все остальные, если речь идет о CAP, так как внятного определения не дано. Амазон, вот, throughput за availability считает, как мы выяснили, и по своему прав.
мы это не выяснили, это ты почему-то написал, что амазаон throughput за availability считает, в ответ на утверждение о том, что амазон сколько то там запросов в секунду умеет обрабатывать, что есть non sequuntur

IB>"In discussions of CAP there are several contradictory definitions of the term availability,
IB>and the formalization as a theorem [30] does not match its usual meaning [40]." (c)
IB>Теперь понятны притензии к CAP?

Совершенно согласен, дискуссии о САР действительно обычно содержать разные противоречящие определения availability, Клипман все правильно написал

CK>>Ну дык, это можно сделать при упавшем регионе, если система построена как Dynamo, запросы будут возвращать не ошибку. Данные можно будет прочитать и записать. В CP системе (например HBase) так сделать будет нельзя.
IB>То есть, вы согласны, что пропускная способность — тоже может являться критерием доступности?

Как это может быть ответом на мой комментарий? И нет, не согласен.

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

DI>Это вообще к чему?
DI>Начинали с обсуждения этой архитектуры: "Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер." Еще раз вопрос, как это может масштабироваться?

А в чем проблема это отмасштабировать? Выбирается другой мастер на другой машине, и запросы идуд через него.

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

IB>>>А это уже вообще вопрос третий. Слово failover в названии решения как бы намекает на то, что это про availability. А scalability — это уже 4-я буква в уравнении, которой тоже не плохо бы дать определение.
IB>·>Зависит от задачи.
IB>Совершенно верно. Поэтому я и прошу дать термину определение, прежде чем им манипулировать.
А чем тебя не устраивает хотя бы то что в вики?
Availability: Every request receives a (non-error) response – without the guarantee that it contains the most recent write

IB>·>В общем случае failover это только часть availability.
IB>·>Более точно будет
IB>·>failover + scalability = availability
IB>О, вот еще одно определение availability, прямо скажем, довольно смелое. Не затруднит дать определение scalability, для начала? А то ведь это тоже довольно растяжимый термин.
Прошу прощения, я не претендовал дать определение, а просто пояснял как понимать этот термин более правильно.
В данном случае сценарий довольно простой: посылаем системе 1млрд запросов за одну секунду и ожидаем получить non-error ответ на каждый запрос. Построить такую available систему без scalability не выйдет, как минимум по технологическим причинам, или даже по физическим.

IB>Как я писал выше, failover системы о которых идет речь — уже отмасштабированы, только цель масштабирования другая — отказоустойчивость, а не пропускная способность. Таким образом, эта система уже отказоустойчива и отмасштабирована, то есть, согласно вашему же определению — доступна.
Я не понимаю каким образом ты базируешь failover на scalability. Это тёплое на мягком. Масштабирование это именно про нагрузку:
Scalability is the property of a system to handle a growing amount of work by adding resources to the system.

IB>·>Т.е. когда стоит задача "обрабатывать 1млрд запросов в секунду" и чтобы было availability, то никакой failover не поможет.
IB>А failover и не должен в этом помогать, он про другое. Собственно, мой поинт был про то, что если система не про бешенную пропускную способность, то это не значит, что она никому не нужна, если посмотреть шире, то есть масса других сценариев, не менее сложных и интересных.
Эээ.. Ну да. Только какие сценарии ни бери, CAP нарушить не удастся.

IB>И, собственно, возвращаясь к CAP (напоминаю, мы все еще разговариваем о CAP), то в этом правиле никакого требования про "миллиард запросов в секунду" — нет. Там вообще термин availablity описан довольно не внятно, в чем собственно и проблема.
CAP теорема позволяет в такой ситуации сделать вывод — что невозможно построить CA-систему в таком сценарии, как бы тебе ни хотелось — только либо A, либо C.

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

S>А в чем проблема это отмасштабировать? Выбирается другой мастер на другой машине, и запросы идуд через него.

У тебя 300К запросов в секунду, а 1 сервер не вывозит больше 50К.

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

S>>А в чем проблема это отмасштабировать? Выбирается другой мастер на другой машине, и запросы идуд через него.
DI>У тебя 300К запросов в секунду, а 1 сервер не вывозит больше 50К.

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

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

S>>А в чем проблема это отмасштабировать? Выбирается другой мастер на другой машине, и запросы идуд через него.
·>Напомню: Scalability is the property of a system to handle a growing amount of work by adding resources to the system
·>Нет такой машины, способной обработать любое число запросов. Поэтому в какой-то очень скорый момент времени твоя масштабилка через один мастер просто кончится и придётся добавлять новые узлы в систему, вместо одного мастера потребуется два и здравствуй CAP.
·>failover тут вообще не в тему.

Благодарю, понял.

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

M>Если наугад из головы ограничения

Все написанное тобой в теме наугад из головы. И ты же слился когда тебе прямые вопросы задавать стали, снова вернулся народ посмешить?

M>Я тоже так умею: прекрасный мастерлесс кластер не выдерживает больше 50к запросов в секунду, а пришло 300к запросов. Ну и нахрена теперь нужен мастерлесс кластер?

Ох лол, мастерлесс, понимал бы ты еще значения слов которые услышал где-то

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

DI>Это какое-то лукавство, что значит буква P? Partition tolerance. А откуда оно взялось, ведь взять обсуждаемую архитектуру: все запросы идут в одну ноду, нода синхронно реплицируется (C), если мастер падает, то мастером становится реплика (А) и все запросы теперь идут через нее. Где тут Р? И откуда Р появилась? Ну видимо оттуда, что все запросы в одну ноду стали узким местом и пришлось пустить запросы по разным нодам. Утверждать что это не так — смело, но глупо.

Самое смешное, что как раз так и есть. Весь CAP — он не потому, что кто-то "стал узким местом". А потому, что в случае P у нас кластер распался на два сегмента. И каждый из них думает, что он-то и есть единственный рабочий.
И в каждом из них появляется свой мастер (это если A), либо не появляется (и тогда С). С чем из этого вы хотите поспорить?

Здравствуйте, ·, Вы писали:
·>Нет такой машины, способной обработать любое число запросов. Поэтому в какой-то очень скорый момент времени твоя масштабилка через один мастер просто кончится и придётся добавлять новые узлы в систему, вместо одного мастера потребуется два и здравствуй CAP.
Нет. Здравствуй CAP появляется только при борьбе за Availability.
Без неё я могу запросто распилить систему по горизонтали — пусть Москву обслуживает Московский сервер, а СПБ — Питерский. Делов-то. А если клиенту из Москвы нужны данные про Питер, но связь лежит, то нарушается не S, а A.

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

S>Самое смешное, что как раз так и есть. Весь CAP — он не потому, что кто-то "стал узким местом". А потому, что в случае P у нас кластер распался на два сегмента.

2 + 2 = 4

Что сказать-то хотел?

S>И каждый из них думает, что он-то и есть единственный рабочий.

Не совсем так. Например, лидера назначает внешний арбитр, а сами ноды решение об этом принимать не могут.

S>И в каждом из них появляется свой мастер (это если A), либо не появляется (и тогда С).
S>С чем из этого вы хотите поспорить?

Чего? С чем я должен спорить-то?

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

IB>>Совершенно верно. Поэтому я и прошу дать термину определение, прежде чем им манипулировать.
·>А чем тебя не устраивает хотя бы то что в вики?
·>Availability: Every request receives a (non-error) response – without the guarantee that it contains the most recent write
Очевидно, тем, что не учитывает Scalability вовсе никак, что противоречит вашей формуле в посте выше.

·>В данном случае сценарий довольно простой: посылаем системе 1млрд запросов за одну секунду и ожидаем получить non-error ответ на каждый запрос. Построить такую available систему без scalability не выйдет, как минимум по технологическим причинам, или даже по физическим.
Конечно же выйдет. Просто последний запрос получит ответ через 1 миллиард лет. А чего вы хотели — интернет не гарантирует ни ширину полосы, ни лаг доставки.

·>Я не понимаю каким образом ты базируешь failover на scalability. Это тёплое на мягком. Масштабирование это именно про нагрузку:
·>Scalability is the property of a system to handle a growing amount of work by adding resources to the system.
Вы неправильно понимаете слова Ивана.
Предположим, у вас уже стоит вполне себе отмасштабированная система. Например, у нас стоит миллион серверов, которые хранят остатки денег на счетах клиентов. Тогда каждый из них обрабатывает всего лишь тысячу запросов в секунду.
Предположим также, что данные клиентов не дублируются вовсе — просто хеш номера счёта однозначно определяет номер сервера, у которого нужно спросить.
Как видим, со scalability тут нет никаких проблем — по мере роста количества клиентов мы просто будем добавлять новые сервера.

Проблема появится в тот момент, когда один из серверов выйдет из строя. Внезапно часть запросов не смогут быть обслужены — нарушение availability.
Failover Cluster позволяет решить эту маленькую проблемку — заменим каждый сервер на FOC из, скажем, трёх серверов. Вот вам и availability поверх scalability.

·>Эээ.. Ну да. Только какие сценарии ни бери, CAP нарушить не удастся.
Конечно же удастся. Потому что результат зависит от того, что мы называем C, а что A. И тогда я буду иметь и C, и А одновременно даже в случае P.

·>CAP теорема позволяет в такой ситуации сделать вывод — что невозможно построить CA-систему в таком сценарии, как бы тебе ни хотелось — только либо A, либо C.
Очень интересно. Ок, а для 1 миллиона RPS можно построить CA-систему? А для 1 тысячи? Ок, ну, хотя бы для 1 запроса в 10 секунд — можно ли построить CA — систему?
Если да, то как? А если нет, то почему вы пишете "в таком сценарии" — что в этом сценарии такого особенного?

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

DI>>- И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?
S>Оно надо для того, чтобы в случае сбоя одного из узлов приложение продолжало работать. Ваш К.О.

Капитан у тебя сломался, А достигается и по другому.

S>Иначе вы из компонентов с Availability в две девятки никак не получите пять девяток.

Ты мне кажется не понимаешь о чем говоришь.

S>Вопросы масштабирования решаются по-другому. Как правило — в зависимости от конкретной задачи.

О, еще один эксперт. Ну расскажи как вот это:

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

Может горизонтально масштабироваться.

S>Рекомендую взглянуть на архитектуру DNS с этой точки зрения — там вполне классически single-master репликация, при этом масштабирование совершенно сумасшедшее.

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

S>>И каждый из них думает, что он-то и есть единственный рабочий.
DI>Не совсем так. Например, лидера назначает внешний арбитр, а сами ноды решение об этом принимать не могут.

Quis custodiet ipsos custodes?

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

S>Здравствуйте, ·, Вы писали:
S>·>Нет такой машины, способной обработать любое число запросов. Поэтому в какой-то очень скорый момент времени твоя масштабилка через один мастер просто кончится и придётся добавлять новые узлы в систему, вместо одного мастера потребуется два и здравствуй CAP.
S>Нет. Здравствуй CAP появляется только при борьбе за Availability.
Или в борьбе за Consistency.

S>Без неё я могу запросто распилить систему по горизонтали — пусть Москву обслуживает Московский сервер, а СПБ — Питерский. Делов-то.
Осталось определить какие бизнес-требования у московских клиентов читать-менять данные Питера. Кстати, если московские и питерские данные вообще не пересекаются, то у тебя нет никакого P, это две отдельные системы и можно иметь вообще C+A.

S>А если клиенту из Москвы нужны данные про Питер, но связь лежит, то нарушается не S, а A.
А можно сделать так, чтобы Московский имел копию данных Питера и кешировал у себя модификации на случай пропадания связи. Тогда A нарушаться не будет, зато будет нарушаться C.

ЗЫ Что здесь значит "S" я не понял.

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

DI>Не совсем так. Например, лидера назначает внешний арбитр, а сами ноды решение об этом принимать не могут.
Отлично. Что делать, если отпал арбитр?

DI>Чего? С чем я должен спорить-то?
С тем, что CAP никакого отношения к Scalability не имеет.

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

DI>Капитан у тебя сломался, А достигается и по другому.
Расскажите.

S>>Иначе вы из компонентов с Availability в две девятки никак не получите пять девяток.

DI>Ты мне кажется не понимаешь о чем говоришь.
А мне кажется наоборот.

DI>

DI>Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.

DI>Может горизонтально масштабироваться.
Я тут по соседству написал — поставите сотню таких кластеров. вот вам и масштаб. Вы же задачу не привели

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

DI>Если падает мастер, то арбитр назначает нового, а старого изгоняют из кластера. Если падает арбитр, а мастер работает, то кластер остается рабочим. Если к падению арбитра добавляется падение мастера, то кластер все равно не приходит в неконсистентное состояние, так как сами ноды стать мастерами самостоятельно не могут, при этом кластер вполне может оставаться доступным на чтение. Компромисы в действии.
Ну вот видите, CAP запрещает, а кластер работает. Как так?

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

DI>>Капитан у тебя сломался, А достигается и по другому.
S>Расскажите.

Только сначала отучаемся от резьбы по цитатам.

— В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.
— И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?
— Оно надо для того, чтобы в случае сбоя одного из узлов приложение продолжало работать. Ваш К.О.

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

S>>>Иначе вы из компонентов с Availability в две девятки никак не получите пять девяток.

DI>>Ты мне кажется не понимаешь о чем говоришь.
S>А мне кажется наоборот.

Тебе кажется, а я уже знаю (начитался твоих пассажей) — здесь есть существенное отличие.

DI>>

DI>>Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.

DI>>Может горизонтально масштабироваться.
S>Я тут по соседству написал — поставите сотню таких кластеров. вот вам и масштаб. Вы же задачу не привели

Почитай заодно, что такое горизонтальное масштабирование, чтобы не писать подобную ахинею.

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

DI>>Конечно, там таких слов нет, вот только сразу как начинаешь горизонтально масштабироваться немедленно возникает угроза разделения кластера.
S>Смотря как масштабироваться. Чистый шардинг создаёт нулевую угрозу разделения кластера.

Что такое чистый шардинг?

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

MA>> Quis custodiet ipsos custodes?

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

Без деталей конечно тяжело рассуждать. В случае разделения, достаточно, того, что арбитр и мастер остануться живы — и что дальше за трэш будет, не могу предположить. Ммм... прежде всего из-за абстрактной задачи, с неясной топологией и т.п.

Мне вообще ближе системы в которых чтение приводит к записи, и в них все эти пляски с бубнами в общем-то до фенечек.

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

IB>>>Совершенно верно. Поэтому я и прошу дать термину определение, прежде чем им манипулировать.
S>·>А чем тебя не устраивает хотя бы то что в вики?
S>·>Availability: Every request receives a (non-error) response – without the guarantee that it contains the most recent write
S>Очевидно, тем, что не учитывает Scalability вовсе никак, что противоречит вашей формуле в посте выше.
Scalability это аспект availability. Т.е. возможность системы оставаться available при growing amount of work путём adding resources.

S>·>В данном случае сценарий довольно простой: посылаем системе 1млрд запросов за одну секунду и ожидаем получить non-error ответ на каждый запрос. Построить такую available систему без scalability не выйдет, как минимум по технологическим причинам, или даже по физическим.
S>Конечно же выйдет. Просто последний запрос получит ответ через 1 миллиард лет.
Зуб даёшь? 1млрд запросов даже в сетевой проводок даже супер-пупер сервера не влезут, поэтому запросы тупо потеряются и ты не сможешь дать ответ даже через 100500 миллиардов лет.
CAP не даёт никаких физических цифр. Это теорема об алгоритмах в распределённых системах.
В качестве аналогии: O(1) сложность алгоритма вполне может означать 1 миллиард лет. И что?

S>·>Я не понимаю каким образом ты базируешь failover на scalability. Это тёплое на мягком. Масштабирование это именно про нагрузку:
S>·>Scalability is the property of a system to handle a growing amount of work by adding resources to the system.
S>Вы неправильно понимаете слова Ивана.
S>Предположим, у вас уже стоит вполне себе отмасштабированная система. Например, у нас стоит миллион серверов, которые хранят остатки денег на счетах клиентов. Тогда каждый из них обрабатывает всего лишь тысячу запросов в секунду.
S>Предположим также, что данные клиентов не дублируются вовсе — просто хеш номера счёта однозначно определяет номер сервера, у которого нужно спросить.
S>Как видим, со scalability тут нет никаких проблем — по мере роста количества клиентов мы просто будем добавлять новые сервера.

S>Проблема появится в тот момент, когда один из серверов выйдет из строя. Внезапно часть запросов не смогут быть обслужены — нарушение availability.
S>Failover Cluster позволяет решить эту маленькую проблемку — заменим каждый сервер на FOC из, скажем, трёх серверов. Вот вам и availability поверх scalability.
"Хранят"? В смысле RO-система? В этом случае CAP как-то не в тему. Ибо эта теорема рассматривает RW. Вот когда ты на этом миллионе серверов захочешь сделать какой-то алгоритм, например, "перевести деньги со счёта на счёт без овердрафта", то у тебе придётся делать выбор C либо A.

S>·>Эээ.. Ну да. Только какие сценарии ни бери, CAP нарушить не удастся.
S>Конечно же удастся. Потому что результат зависит от того, что мы называем C, а что A. И тогда я буду иметь и C, и А одновременно даже в случае P.
Как можно нарушить математически доказанную теорему? Ну да, можно так сказать... просто нарушить предусловия теоремы или дать другое толкование терминам.

И что?

S>·>CAP теорема позволяет в такой ситуации сделать вывод — что невозможно построить CA-систему в таком сценарии, как бы тебе ни хотелось — только либо A, либо C.
S>Очень интересно. Ок, а для 1 миллиона RPS можно построить CA-систему? А для 1 тысячи? Ок, ну, хотя бы для 1 запроса в 10 секунд — можно ли построить CA — систему?
Можно, конечно, на нашем уровне развития техники, но не будет P (т.е. ровно один узел).

S>Если да, то как? А если нет, то почему вы пишете "в таком сценарии" — что в этом сценарии такого особенного?
Я просто хотел сказать, что для 1млрд физически невозможно построить без P. Нет такого железа у нас.

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

·>"Хранят"? В смысле RO-система? В этом случае CAP как-то не в тему. Ибо эта теорема рассматривает RW. Вот когда ты на этом миллионе серверов захочешь сделать какой-то алгоритм, например, "перевести деньги со счёта на счёт без овердрафта", то у тебе придётся делать выбор C либо A.

Тут нет выбора между C и A как такого. Такого рода операция абсолютно аналогична межбанковским переводам, или транзакциям ч/з платежные карты. Т.е. списываем/блокируем, задание в очередь, телепорт на узел с целевым счетом, пополнение. Возможен центральный "арбитр" или правила ролбэка. Между чем тут выбирать. Её можно обрабатывать хоть бесконечность, при чем ни один узел не перейдет в неведомо-неконсистентное состояние вне зависимости от ежемоментной доступности т.н. кластера будь он четвертован или нет.

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

CK>мы это не выяснили, это ты почему-то написал, что амазаон throughput за availability считает, в ответ на утверждение о том, что амазон сколько то там запросов в секунду умеет обрабатывать, что есть non sequuntur
Это не я написал, это сотрудник амазона написал, как доказательство доступности их системы.

CK>Совершенно согласен, дискуссии о САР действительно обычно содержать разные противоречящие определения availability, Клипман все правильно написал

О чем тогда спорим? Собственно и мой поинт ровно в том, что CAP косячная, так как не дает внятного определения терминам которыми оперирует.

CK>>>Ну дык, это можно сделать при упавшем регионе, если система построена как Dynamo, запросы будут возвращать не ошибку. Данные можно будет прочитать и записать. В CP системе (например HBase) так сделать будет нельзя.
IB>>То есть, вы согласны, что пропускная способность — тоже может являться критерием доступности?

CK>Как это может быть ответом на мой комментарий?
Так же как и ваш на мой комментарий.

CK>И нет, не согласен.

Ну, ваше право.

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

DI>Вы снова что-то понаписали, но проигнорировали прямые вопросы, это уже даже не смело, а просто глупо — пытаться оставить последнее слово за собой.
Я собственно начал ровно с ответа на поставленный вопрос. Но если вам сложно внимательно прочитать, то не надо пытаться оставить последнее слово за собой, вот это действительно глупо ) Но если что-то непонятно, я с радостью объясню

DI>Я это не говорил, я говорил, что горизонтальное Scalability вытекает из Partition, никак по другому горизонтально масштабироваться не получится.
Ладно, пойдем длинным путем. Без Scalability Partition возможен или нет?

DI>У меня нет претензий к failover системам, не нужно фантазировать,

DI>И как это горизонтально масштабируется?
DI>Никак что-ли? А зачем оно тогда надо?

А это кто писал?

DI>более того, фейловеринг обязательная часть любой системы, вот стратегии и допущения здесь могут быть разными.
Насчет "любой" это опять же довольно смело, но в остальном совершенно верно — стратегии и допущения могут быть разными, хорошо бы их только описывать, прежде чем глотку рвать.

DI>Начинали с обсуждения этой архитектуры: "Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер." Еще раз вопрос, как это может масштабироваться?
На это уже ответили. Я же отвечал на вопрос "Зачем оно тогда надо?".
Если не понятно, могу разжевать еще раз, мне не сложно ))

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

MA>>Такого рода операция абсолютно аналогична межбанковским переводам, или транзакциям ч/з платежные карты.
·>Ок. Это наша распределённая система.
MA>>Т.е. списываем/блокируем, задание в очередь, телепорт на узел с целевым счетом, пополнение.
·>Это AP-алгоритм.
MA>>Возможен центральный "арбитр"
·>А это CP-алгоритм.
MA>>или правила ролбэка.
·>Тоже AP-алгоритм, с Eventual Consistency.
MA>>Между чем тут выбирать.
·>В этом и суть теоремы — выбирай, но не всё сразу.
Это потому, что ты хочешь что бы, эта операция была как бы транзакция на обоих сторонах.
А эта операция — обещание чертенка за мзду (или по доброте) взять у тебя пакет с деньгами с обещанием его доставить адресату, или вернуть его обратно, в течении, скажем 7 дней. Довольно трудно сюда натягивать CAP, т.к. чертенок выполняет перемещения между узлами на реактивных голубях, и его проблема (P) вообще не колышет. Безусловно могут возникают иные проблемы. Но, то что ты называешь "Eventual Consistency" — это не применимо тут. Система консистентна всё время — это её нормальное состояние. Более того, между узлом 1 обслуживающем счет отправлителя и между узлом 2 обслуживающим счет получателя не существует консистентности, — они обслуживают разные сущности. К ним ни по отдельности, ни в месте не применимы эти понятия.

MA>>Её можно обрабатывать хоть бесконечность,
·>Про бесконечность ты немного загнул. Алгоритм не бывает бесконечным, по определению.
Очевидно, что пока задействованные части системы не доступны или разделены — без протокола (соглашения) о выполнении независимых ролбэков — оно зависнет на время разделения.

MA>>при чем ни один узел не перейдет в неведомо-неконсистентное состояние вне зависимости от ежемоментной доступности т.н. кластера будь он четвертован или нет.
·>Угу. Ведь узел по определению косистентый. А CAP-теорема о том как эти узлы взаимодействуют.
Именно. Только, в данном случае, мы не оперируем с узлами которые дублируют данные, этим узлам, кроме пересылки голубей ничего не нужно, что бы всегда быть CAP.

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

S>Рекомендую взглянуть на архитектуру DNS с этой точки зрения — там вполне классически single-master репликация, при этом масштабирование совершенно сумасшедшее. И availability — на зависть многим. Consistency при этом тоже весьма неплоха — всё зависит от того, что именно мы назовём Consistency. Скажем, у нас есть заранее известный верхний предел времени, которое должно пройти после модификации, чтобы ни один запрос не вернул stale data.

Если бы еще DNS записи часто обновлялись. Масштабировать что-то одно, только чтение или только запись несложно. В чем смысл обсуждать какой-то вырожденный случай? Если хочется обсуждать реальные системы, можно взять что-то реальное за основу (Google Chubby, DynamoDB, FAWN, Pnuts, ...) и посмотреть как там проявляются ограничения CAP. Но это конечно сложнее, нежели тыкать оппонентов в DNS, который в общем-то даже не очень то и отказоустойчив.

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

IB>Это не я написал, это сотрудник амазона написал, как доказательство доступности их системы.

я сдаюсь

CK>>Совершенно согласен, дискуссии о САР действительно обычно содержать разные противоречящие определения availability, Клипман все правильно написал

IB>О чем тогда спорим? Собственно и мой поинт ровно в том, что CAP косячная, так как не дает внятного определения терминам которыми оперирует.

Клмпман никогда не говорил такой ерунды. Твоя цитата про дискуссии о САР! В общем, я еще раз сдаюсь.

CK>>>Ну дык, это можно сделать при упавшем регионе, если система построена как Dynamo, запросы будут возвращать не ошибку. Данные можно будет прочитать и записать. В CP системе (например HBase) так сделать будет нельзя.
IB>>То есть, вы согласны, что пропускная способность — тоже может являться критерием доступности?
CK>>Как это может быть ответом на мой комментарий?
IB>Так же как и ваш на мой комментарий.

я не отстану, до этого было вот что

CK>>>>нет, не является, ведь пропускная способность ничего нам не говорит о том, как поведет себя система (я так понимаю DynamoDB) в случае, если упадет один из регионов, а вот CAP говорит, если система available — она продолжит обрабатывать запросы, если нет — будет недоступна для записи
IB>>>Ну как же — конечно говорит. Для того чтобы обработать эти запросы, надо отвечать не ошибкой, что бы там с системой внутри не происходило.
CK>>Ну дык, это можно сделать при упавшем регионе, если система построена как Dynamo, запросы будут возвращать не ошибку. Данные можно будет прочитать и записать. В CP системе (например HBase) так сделать будет нельзя.

ты утверждаешь что throughput определяет доступность системы, верно?

IB>>>Таким образом, возвращаясь к предыдущему пункту, критерий "миллиард запросов в секунду", гораздо адекватнее чем CAP.

в общем, да, ты это утверждаешь

я попросил тебя объяснить, как знание пропускной способности системы поможет тебе понять, как система поведет себя в случае если упал ДЦ (ну или регион в AWS), это, если что, network partition

ну и вообще, обоснуй пожалуйста, почему ты думаешь что пропускная способность может являться адекватной заменой CAP? это странное утверждение не я должен опровергать, его ты должен доказывать

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

CK>я сдаюсь

CK>ты утверждаешь что throughput определяет доступность системы, верно?

IB>>>>Таким образом, возвращаясь к предыдущему пункту, критерий "миллиард запросов в секунду", гораздо адекватнее чем CAP.

CK>в общем, да, ты это утверждаешь
Я утверждаю, что throughput адекватнее и практичнее CAP.

CK>я попросил тебя объяснить, как знание пропускной способности системы поможет тебе понять, как система поведет себя в случае если упал ДЦ (ну или регион в AWS), это, если что, network partition
Система должна продолжать выдавать адекватные ответы с заданной частотой, вне зависимости от того, что у нее случилось внутри.
Это вполне понятный критерий с числовой характеристикой, которым регулярно пользуются на практике при построении систем, в отличии от CAP.

CK>ну и вообще, обоснуй пожалуйста, почему ты думаешь что пропускная способность может являться адекватной заменой CAP?
см. выше.

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

MA>>>Между чем тут выбирать.
MA>·>В этом и суть теоремы — выбирай, но не всё сразу.
MA> Это потому, что ты хочешь что бы, эта операция была как бы транзакция на обоих сторонах.
MA> А эта операция — обещание чертенка за мзду (или по доброте) взять у тебя пакет с деньгами с обещанием его доставить адресату, или вернуть его обратно, в течении, скажем 7 дней. Довольно трудно сюда натягивать CAP, т.к. чертенок выполняет перемещения между узлами на реактивных голубях, и его проблема (P) вообще не колышет. MA>Безусловно могут возникают иные проблемы. Но, то что ты называешь "Eventual Consistency" — это не применимо тут. Система консистентна всё время — это её нормальное состояние. Более того, между узлом 1 обслуживающем счет отправлителя и между узлом 2 обслуживающим счет получателя не существует консистентности, — они обслуживают разные сущности. К ним ни по отдельности, ни в месте не применимы эти понятия.
Читай понятие Strong Consistency — именно то, что применяется в теореме. На пальцах — это возможность обеспечить одинаковое состояние между всеми узлами системы. Скажем, в классических субд можно например иметь как в psql txid — идентификатор состояния и он будет означать одно и то же на всех узлах системы. В простейшем случае, это будет CA-система (один сервер субд или 2PC). Если начать кластеризовать, то станет CP-системой, т.к. потребуется центральный узел для сериализации txid. Различные новомодные распределённые nosql это AP-системы и никакого txid соорудить не выйдет.

MA>>>Её можно обрабатывать хоть бесконечность,
MA>·>Про бесконечность ты немного загнул. Алгоритм не бывает бесконечным, по определению.
MA> Очевидно, что пока задействованные части системы не доступны или разделены — без протокола (соглашения) о выполнении независимых ролбэков — оно зависнет на время разделения.
"Зависнет" это и есть результат отсутствия A.

MA>>>при чем ни один узел не перейдет в неведомо-неконсистентное состояние вне зависимости от ежемоментной доступности т.н. кластера будь он четвертован или нет.
MA>·>Угу. Ведь узел по определению косистентый. А CAP-теорема о том как эти узлы взаимодействуют.
MA> Именно. Только, в данном случае, мы не оперируем с узлами которые дублируют данные, этим узлам, кроме пересылки голубей ничего не нужно, что бы всегда быть CAP.
Не понял что ты имеешь в виду. Откуда возьмётся консистентное состояние _системы_, а не узла в твоём описании? (если я правильно это описание понял, конечно)

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

> Не понял что ты имеешь в виду. Откуда возьмётся консистентное состояние _системы_, а не узла в твоём описании? (если я правильно это описание понял, конечно)

Узлы не хранят дублирующие данные. Sinclair предложил "суперкластер" (аля шардинг), из failover-кластеров (или кто там в ветке это предложил). Узлы этого суперкластера не нуждаются быть консистентными, т.к. их область ведения фактически не пересекается между собой.

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

Я влез сюда из-за счетов. Работа со счетами либо выполняется в ACID, либо, выполняется через машину состояний (внешнюю или внутреннюю). Всё остальное не работает, либо повторяет эти два подхода.

А если захотеть настоящую распределенную транзакцию, то... таких не бывает.

--

Я вот уже помню слабо, вроде когда-то писали, что gmail там держит пару резерных копий пользовательских данных, но доставляя как минимум одну копию в географически-выгодное место (уж не знаю насколько это правда), и эта копия обслуживает аккаунт. Являеется ли И применимо ли к gmail CAP? Я, как пользователь, фактически всегда обращаюсь к одному узлу, пишу в один узел и читаю из одного узла (ну вроде как), помимо меня с данными ещё работает почтовый сервер, с конкуренцией стремящейся к нулю. Как эта система, в практическом смысле, может быть не консистентной? (видимо вместо gmail можно поставить и что-нибудь другое — Тут я его только как пример. Суть, я надеюсь, понятна.)

--

Я не спорю, что могут быть более интересные задачи, требующие быть более "энергичным", но, положа руку на сердце, я в это не верю. (В том, смысле, что кластера это не только о серверах, но и о данных, пользователях, паттернах доступа и операциях. Если вам нужно 100 серверов для одной БД — то врядли вам нужны все данные сразу. А если все сразу данные не нужны, то тут и начинается партиционирование и дальнейшее изучение предметной области. А если все данные нужны сразу — то это уже проблема).

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

MA> Мне вообще ближе системы в которых чтение приводит к записи, и в них все эти пляски с бубнами в общем-то до фенечек.

Енто как, можно подробнее?

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

MA>> Мне вообще ближе системы в которых чтение приводит к записи, и в них все эти пляски с бубнами в общем-то до фенечек.
S>Енто как, можно подробнее?

Ну, например получение баланса карты — это в зависимости от пл. системы — регистрируемая транзакция.

Ну, а так — банальный обязательный аудит. Конечно, его можно и в сторонке, но это зависит от требований.

Мне ближе — это... привычнее.
Безусловно, если можно ограничиться только чтением, то так и надо. А ограничиться им можно.

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

DI>Что такое чистый шардинг?
Это когда мы просто пилим данные на части по заранее известному критерию, а в требования consistenсy не входит ссылочная целостность.
Простейший пример — энциклопедия, которую мы делим на шарды по префиксу ключа.
То, что в таком сценарии разделение кластера нам не грозит — очевидно, или нужно пояснять?

Здравствуйте, Sharov, Вы писали:
S>Какой-нибудь ресурс посоветуете кроме вики, где на этом бы акцентировались? Ну и для DNS свой протокол, чай не REST.
Сходу не посоветую. Есть ощущение, что по ссылкам из DDIA надо искать, но пока я её даже саму до конца не дочитал

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

DI>>Вы снова что-то понаписали, но проигнорировали прямые вопросы, это уже даже не смело, а просто глупо — пытаться оставить последнее слово за собой.
IB>Я собственно начал ровно с ответа на поставленный вопрос.

Если начал, то почему не закончил? Одно бла-бла-бла

IB>Но если вам сложно

Какой ты душный, строчишь такие объемные тексты ни о чем, заболтать до смерти что-ли хочешь?

IB>Ладно, пойдем длинным путем.

Мы никуда не пойдем и будем оставаться в этой ветке в той теме, что здесь обсуждалась. Хочешь что-то обсудить еще — создай тему или выдели ветку.

DI>>У меня нет претензий к failover системам, не нужно фантазировать,
IB>

DI>>И как это горизонтально масштабируется?
DI>>Никак что-ли? А зачем оно тогда надо?

IB>А это кто писал?

Омг, давай ты не будешь тратить мое время, если для тебя фейловеринг и горизонтальная масштабируемость это что-то взаимоисключающее.

DI>>более того, фейловеринг обязательная часть любой системы, вот стратегии и допущения здесь могут быть разными.
IB>Насчет "любой" это опять же довольно смело, но в остальном совершенно верно — стратегии и допущения могут быть разными, хорошо бы их только описывать, прежде чем глотку рвать.

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

DI>>Начинали с обсуждения этой архитектуры: "Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер." Еще раз вопрос, как это может масштабироваться?
IB>На это уже ответили.
IB>Если не понятно, могу разжевать еще раз, мне не сложно ))

Да, напиши как это может горизонтально масштабироваться.

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

DI>>Я хз, ты читать не умеешь? Или с интеллектом что-то?
S>Коллега, вам так нестерпимо хочется в бан? Вы не стесняйтесь — пишите напрямую модераторам. Это быстрее и эффективнее.

Ну иди да напиши.

DI>>Прям в этом описании есть сценарий, когда кластер перестает быть доступным на запись.
S>Да, есть.

О, смотри, я тебя читать научил. Алилуя.

S>Но вы же сами зачем-то упомянули про то, что он в это время доступен на чтение.

Извини, я сразу все кейсы не разжевал, а сами вы думать не хотите. Вот еще один кейс: Упал арбитр, упал мастер, кластер все еще доступен для чтения, но данные которые мастер получил перед падением не успели отреплицироваться — теряем С.

S>Значит, вас не устраивает бинарная трактовка availability — с практической точки зрения, частичная availability лучше, чем никакая; а CAP с её черно/белой трактовкой не даёт никаких основ для рассуждения о частичной availabilty. За это мы её и не любим.

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

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

DI>>Что такое чистый шардинг?
S>Это когда мы просто пилим данные на части по заранее известному критерию

Я уже ору с рсдн экспертов, ты снова пробил дно. Любой шардинг — деление данных по какому-то признаку, обычно просто берут хеш от первичного ключа, и считают по нему номер сервера (тупо) или виртуального бакета.

S>а в требования consistenсy не входит ссылочная целостность.

А это ты что сочинил?

S>Простейший пример — энциклопедия, которую мы делим на шарды по префиксу ключа.
S>То, что в таком сценарии разделение кластера нам не грозит — очевидно, или нужно пояснять?

Конечно не очевидно, поясняй, я пока за попкорном схожу.

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

CK>>в общем, да, ты это утверждаешь
IB>Я утверждаю, что throughput адекватнее и практичнее CAP.

что значит адекватнее?

CK>>я попросил тебя объяснить, как знание пропускной способности системы поможет тебе понять, как система поведет себя в случае если упал ДЦ (ну или регион в AWS), это, если что, network partition

IB>Система должна продолжать выдавать адекватные ответы с заданной частотой, вне зависимости от того, что у нее случилось внутри.

ошибочный ответ может быть адекватным в каких-то случаях, например если требования к целостности данных высокие (финансовые данные) и мы, например, через 2PC коммитим данные в разные ДЦ, то отдать ошибку при network partition — вполне адекватный ответ, а отдать не ошибку и допустить рассогласованность — недопустимо

IB>Это вполне понятный критерий с числовой характеристикой, которым регулярно пользуются на практике при построении систем, в отличии от CAP.

throughput не замена а дополнение, это вообще про разное

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

S>>>·>Availability: Every request receives a (non-error) response – without the guarantee that it contains the most recent write
S>>>Очевидно, тем, что не учитывает Scalability вовсе никак, что противоречит вашей формуле в посте выше.
S>·>Scalability это аспект availability. Т.е. возможность системы оставаться available при growing amount of work путём adding resources.
S>И тем не менее, в ваших определениях это никак не связано. Availability в вашей формулировке всего лишь требует получать ответ на каждый запрос — при этом нет никаких временных рамок; это означает, что при росте нагрузки можно наращивать время ожидания результата безо всяких дополнительных телодвижений.
Не понял что за рамки имеешь в виду. Вообще-то, timeout error это тоже error в терминах Availability. Наращивать сколько конкретно? Хинт: O(∞) — оксюморон.

S>·>Зуб даёшь? 1млрд запросов даже в сетевой проводок даже супер-пупер сервера не влезут, поэтому запросы тупо потеряются и ты не сможешь дать ответ даже через 100500 миллиардов лет.
S>А с чего вы взяли, что мы собираемся запихивать этот миллиард запросов в один сетевой проводок?
S>У нас же не один клиент генерирует этот миллиард запросов, так? Ну вот у нас миллион клиентов делает по 1к RPS, которые приземляются на 100к прокси серверах, и каждый принимает всего лишь по 10к RPS.
S>Запросы лежат в очереди, и прокси выполняют их через тот самый 1 сервер. Никаких принципиальных проблем с CAP тут не возникает.
В очередях бесконечной длины? Круто чё. Если ты не просёк, то мы рассматриваем не обработку 1млрд запросов, посланных за секунду, а систему, способную обрабатывать 1млрд запросов в секунду.

У тебя какое-то странное представление об алгоритмах. Твои алгоритмы требуют бесконечного времени и бесконечной памяти. Круто, конечно, но не для нашей вселенной.

S>·>"Хранят"? В смысле RO-система? В этом случае CAP как-то не в тему. Ибо эта теорема рассматривает RW.
S>Почему RO? Вполне себе RW. Просто нам заранее известно, что ваш счёт лежит на сервере №110, а мой — на сервере №465. Поэтому когда у нас идёт команда пополнить мой счёт на 1000р, то она приземляется в мой сервер, а ваша — в ваш.
И пока какой-то из этих серверов лежит, система неконсистентна или недоступна. ЧТД.

S>·>Вот когда ты на этом миллионе серверов захочешь сделать какой-то алгоритм, например, "перевести деньги со счёта на счёт без овердрафта", то у тебе придётся делать выбор C либо A.
S>Я вас разочарую, но в CAP нет ничего про multi-node updates. Это раз.
Там есть о взаимоотношении R и W _одного_ регистра. Т.е. случаи "пишем в X, читаем Y" или "пишем в X, пишем в Y и никогда ничего не читаем" или "читаем X и читаем Y" — это не то что описывает теорема, да и на практике нечасто встречается.

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

CAP об алгоритмах, а не об аппаратуре.

S>Нужно ли нам разрешить овердрафты иногда? На всякий случай напомню, что в реальных card processing systems овердрафты являются частью нормального функционирования

S>И реальный бизнес вполне может сказать "ну ок, овердрафты в пределах 1% от остатка на счетах не являются для нас проблемой".
Да, т.е. AP-система, объясняем бизнесу что C может нарушаться. И? К чему ты клонишь?

S>>>Конечно же удастся. Потому что результат зависит от того, что мы называем C, а что A. И тогда я буду иметь и C, и А одновременно даже в случае P.
S>·>Как можно нарушить математически доказанную теорему? Ну да, можно так сказать... просто нарушить предусловия теоремы или дать другое толкование терминам.

И что?
S>И то, что формулировки C и A, выбранные в доказательстве этой великой теоремы, не имеют практической применимости. На практике, нас не интересует ни та A, которая там выбрана, ни C.
А теорему не интересует что вас это не интересует. Теорема — это теория, а не практика. Например, есть теорема о том, что алгоритм сортировки нельзя сделать быстрее чем O(n*log(n)). И тут приходят "практики" и "опровергают" теорему: "а у нас тут поразрядная сортировка", "а у нас тут много ядер", "а у нас тут такие данные".

S>>>Очень интересно. Ок, а для 1 миллиона RPS можно построить CA-систему? А для 1 тысячи? Ок, ну, хотя бы для 1 запроса в 10 секунд — можно ли построить CA — систему?
S>·>Можно, конечно, на нашем уровне развития техники, но не будет P (т.е. ровно один узел).
S>Вы что, полагаете, что 1 узел вам даст возможность получить ответы на 100% запросов? Прямо на все-все 100%? И питание у него не пропадает никогда, и железо не сыплется? Апдейты на него не ставят никогда, да?
Ещё раз. Алгоритмам питание не нужно.

S>>>Если да, то как? А если нет, то почему вы пишете "в таком сценарии" — что в этом сценарии такого особенного?
S>·>Я просто хотел сказать, что для 1млрд физически невозможно построить без P. Нет такого железа у нас.
S>И для 0.001 RPS тоже нет такого железа, чтобы получить C, A, и P.
И?

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

DI>>Я уже ору с рсдн экспертов, ты снова пробил дно. Любой шардинг — деление данных по какому-то признаку, обычно просто берут хеш от первичного ключа, и считают по нему номер сервера (тупо) или виртуального бакета.
S>Попробуйте перестать орать и начать разговаривать спокойно.

Так тебе и ответили спокойно:

Любой шардинг — деление данных по какому-то признаку, обычно просто берут хеш от первичного ключа, и считают по нему номер сервера (тупо) или виртуального бакета.

S>>>а в требования consistenсy не входит ссылочная целостность.
DI>>А это ты что сочинил?
S>Эмм, вы не знаете что такое "ссылочная целостность"?

Я знаю, что такое ссылочная целостность, но не понимаю, что это значит в контексте выдуманного тобой "чистого шардинга".

S>>>Простейший пример — энциклопедия, которую мы делим на шарды по префиксу ключа.
S>>>То, что в таком сценарии разделение кластера нам не грозит — очевидно, или нужно пояснять?

DI>>Конечно не очевидно, поясняй, я пока за попкорном схожу.
S>Ок, поясняю: поскольку ссылочная целостность нас не интересует, падение связи с любым из шардов нам ничем не грозит. Ну, вы там выше написали ваше понимание шардинга — вот в нём мы тупо по хешу первичного ключа однозначно получаем номер сервера. Запись и чтение по первичному ключу идут туда. Если сервер временно недоступен, мы просто ждём его возврата в строй. Под consistency мы здесь понимаем всего лишь то, что читаем то, что записали.
S>Если есть какой-то способ потерять consistency в этом сценарии — покажите.

А, теперь понял, ты про то, что данные со всеми зависимостями находятся на одном шарде. Твой пример с энциклопедией здесь, кстати, не в тему, так как ты пойдешь по ссылкам из статьи и окажешься на другом шарде, ну или надо вообще всю энциклопедию держать на 1 шарде, что уже вырожденный случай. Вернемся к САР с которым ты как Дон Кихот борешься — в предложенном тобой "чистом шардинге" напрочь отсутствует буква А. Если побороться за А, то придется сделать репликацию и мы можем потерять С из-за разделения мастера и реплики.

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

CK>>В чем смысл обсуждать какой-то вырожденный случай?
S>Вырожденный случай — это CAP, в которой под availability понимается 100% возможность получить ответ от любого узла.

ты же понимаешь, что эта availability просто называется так, можно было назвать по другому, скажем, readiness, было бы меньше непонимания
было бы понятно, что есть availability в девятках, а есть readiness — просто свойство принимать/отдавать данные, даже если в сети произошел сбой

CK>>Если хочется обсуждать реальные системы, можно взять что-то реальное за основу (Google Chubby, DynamoDB, FAWN, Pnuts, ...) и посмотреть как там проявляются ограничения CAP.
S>Ок, давайте пообсуждаем. Хотя мне кажется, что вы путаете реальные системы с инструментами. Реальная система — это, к примеру, банковское приложение. У него, в отличие от инструмента, есть набор функциональных и нефункциональных требований.

у инфраструктуры (к коей относятся перечисленные системы) они тоже есть

CK>>Но это конечно сложнее, нежели тыкать оппонентов в DNS, который в общем-то даже не очень то и отказоустойчив.
S>По факту — весьма отказоустойчив. Настолько отказоустойчив, что прочие reliable services типа того же chubby легко полагаются на DNS как механизм резолвинга ссылок.

гугли azure dns outage

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

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

CK>>>В чем смысл обсуждать какой-то вырожденный случай?
S>>Вырожденный случай — это CAP, в которой под availability понимается 100% возможность получить ответ от любого узла.

CK>ты же понимаешь, что эта availability просто называется так, можно было назвать по другому, скажем, readiness, было бы меньше непонимания
CK>было бы понятно, что есть availability в девятках, а есть readiness — просто свойство принимать/отдавать данные, даже если в сети произошел сбой
Ты же понимаешь, что всем было бы насрать на readiness в этом случае? Или сразу бы спросили — как это соотносится с доступностью?
Потому что доступность выраженная в процентах это то что нужно людям, и то за что они готовы платить. А readiness — непонятное свойство алгоритма, в непонятной вычислительной модели, которое еще и не дает никаких гарантий.

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

G>Ты же понимаешь, что всем было бы насрать на readiness в этом случае? Или сразу бы спросили — как это соотносится с доступностью?
G>Потому что доступность выраженная в процентах это то что нужно людям, и то за что они готовы платить. А readiness — непонятное свойство алгоритма, в непонятной вычислительной модели, которое еще и не дает никаких гарантий.

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

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

DI>Если начал, то почему не закончил? Одно бла-бла-бла
Потому что вы не отвечаете на поставленный вопрос, одно бла-бла-бла =)

DI>Мы никуда не пойдем и будем оставаться в этой ветке в той теме, что здесь обсуждалась.
Странно читать такое от человека, который только и делает, что пытается избежать обсуждаемой здесь темы.
Как-то толсто вы сливаете, коллега, без огонька. )
И так, ответ-то будет или расходимся?

DI>Омг, давай ты не будешь тратить мое время,
Так не тратьте — признайтесь, что чушь спороли и разойдемся.
И не тратье заодно и мое, отпираясь от своих же слов.

DI>Глотку рвешь здесь ты, вместо того, чтобы как адекватный человек не разбирающийся в теме пойти и почитать хотя бы азы распределенных систем.
Как адекватный человек, я пытаюсь пояснить вам всю глубину ваших заблуждений. А вот посылать всех азы учить, когда сказать нечего — совсем не адекватно.

DI>>>Начинали с обсуждения этой архитектуры: "Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер." Еще раз вопрос, как это может масштабироваться?
IB>>На это уже ответили.
IB>>Если не понятно, могу разжевать еще раз, мне не сложно ))
DI>Да, напиши как это может горизонтально масштабироваться.
Вы так трепетно относитесь к своему времени, неужели не жалко его было тратить на фигурную резьбу по цитатам?
На этот вопрос вам повторно ответят те, кто отвечал в первый раз, если им свое время не жалко будет и вы вежливо попросите.
Я же отвечал на вопрос "зачем оно тогда надо?", повторить?

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

CK>ты же понимаешь, что эта availability просто называется так, можно было назвать по другому, скажем, readiness, было бы меньше непонимания
CK>было бы понятно, что есть availability в девятках, а есть readiness — просто свойство принимать/отдавать данные, даже если в сети произошел сбой
Практическая полезность этого свойства равна нулю. Зачем про него теорема? Просто Брюер сказал красивую фразу; когда к ней стали приделывать математическое обоснование, то оказалось, что получается фуфло. В итоге для того, чтобы доказать CAP, пришлось ввести искусственное понятие availability, которое никому не нужно.

CK>у инфраструктуры (к коей относятся перечисленные системы) они тоже есть

CK>>>Но это конечно сложнее, нежели тыкать оппонентов в DNS, который в общем-то даже не очень то и отказоустойчив.
S>>По факту — весьма отказоустойчив. Настолько отказоустойчив, что прочие reliable services типа того же chubby легко полагаются на DNS как механизм резолвинга ссылок.

CK>гугли azure dns outage
И? двухчасовой даунтайм? При этом он зааффектил вовсе не всю инфраструктуру DNS, а только её крошечный кусочек. Ок, давайте возьмём период в год — посчитайте, сколько получается девяток. А если мы скорректируем эту оценку с учётом того, что большинство DNS запросов в это время продолжали обслуживаться, то полученную Availability побить будет крайне сложно.
Но я согласен с вами — DNS малоинтересный пример. Давайте обсуждать то, что вы предложили.

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

S>Это значит, что нам наплевать, если данные с одного шарда ссылаются на данные с другого шарда, а этих данных на другом шарде нет.

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

DI>> Вернемся к САР с которым ты как Дон Кихот борешься — в предложенном тобой "чистом шардинге" напрочь отсутствует буква А. Если побороться за А, то придется сделать репликацию и мы можем потерять С из-за разделения мастера и реплики.
S>Ну вот, теперь можно вернуться к разговору о failover cluster. Масштабирование мы уже получили, безо всяких угроз разделения кластера.

Мы получили только консистентность за счет потери доступности. Само масштабирование мы не получили.

Поясняю: у нас есть кластер из Н нод, мы разделили данные по ним по какому-то принципу, какое-то время все хорошо.

Сценарий 1. Система живет, мы подливаем новые данные, наступает момент когда на ноде заканчивается место, надо добавить еще несколько нод и перебалансировать данные. Как ты это решишь? (подсказка: я уже решение давал).

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

Сценарий 3. Внезапно оказалось, что данные на одной ноде популярнее других (лента новостей Джастина Бибера) и количество запросов превысило пропускную способность ноды. Ок. Мы отселили Джастина Бибера на другую ноду (возможен сценарий 2 и кстати как ты организуешь переезд без даунтайма с сохранением консистентности?) и оказалось, что Джастин уже не популярен, а у молодежи новый кумир (молодежь оказалась ветренной и каждую неделю вкусы меняются).

S>Теперь заменим каждую ноду на failover cluster, и получим ту самую A.

Но ведь не получим, ведь нода все еще может стать недоступной, ну ок, допустим сама нода крайне живучая и никогда не отказывает, но что делать с каналом, через который она общается с внешним миром? А еще помним про сценарии 1, 2, 3.

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

DI>Ок, начались поиски вырожденного случая, видимо пришло понимание, что в общем случае задача не решаема.

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

DI>Мы получили только консистентность за счет потери доступности. Само масштабирование мы не получили.
Ну так оно у нас уже есть.

DI>Поясняю: у нас есть кластер из Н нод, мы разделили данные по ним по какому-то принципу, какое-то время все хорошо.
DI>Сценарий 1. Система живет, мы подливаем новые данные, наступает момент когда на ноде заканчивается место, надо добавить еще несколько нод и перебалансировать данные. Как ты это решишь? (подсказка: я уже решение давал).
Давайте я просто сошлюсь на DDIA, чтобы не пересказывать Клеппмана, ок? В принципе, ничего военного нет — разделяемыми данными здесь является только "карта шардов", которая имеет небольшой размер, поэтому достижение консенсуса в её отношении завершается за реалистичное время. Т.к. на доступность мы пока что забили (напомню: описываемый упрощённый подход предлагает сначала добиться масштаба, а уже потом доступности), то нам не очень важен простой в течение перебалансирови.
А если мы делаем перебалансировку не в тот самый момент, когда место уже закончилось, а при достижении определённого коэффициента заполнения, то у нас есть достаточный запас времени для того, чтобы достичь консенсуса без потери availability и consistency. Ну, то есть всегда есть шанс, что место на ноде закончится до того, как нужная часть шардов будет смигрирована на новую ноду и достигнут консенсус относительно распределения шардов по нодам — особенно с учётом возможности временного пропадания связи между нодами. Но опять-таки, всё, что нам говорит CAP, это что в описанном сценарии для достижения availability мы обязаны пожертвовать consistency. Этот результат не даёт нам никакой полезной информации для дальнейших рассуждений. А вот рассуждения в терминах Reliability Engineering позволяют нам рассчитать вклад вот этого fault-сценария в показатель availability; даже из соображений на пальцах понятно, что мы можем получить практически приемлемую доступность безо всякой потери консистентности.

DI>Сценарий 3. Внезапно оказалось, что данные на одной ноде популярнее других (лента новостей Джастина Бибера) и количество запросов превысило пропускную способность ноды. Ок. Мы отселили Джастина Бибера на другую ноду (возможен сценарий 2 и кстати как ты организуешь переезд без даунтайма с сохранением консистентности?) и оказалось, что Джастин уже не популярен, а у молодежи новый кумир (молодежь оказалась ветренной и каждую неделю вкусы меняются).
S>>Теперь заменим каждую ноду на failover cluster, и получим ту самую A.

DI>Но ведь не получим, ведь нода все еще может стать недоступной,
Эмм, но ведь живучесть failover cluster как бы выше, чем живучесть одной ноды, не так ли?
DI>ну ок, допустим сама нода крайне живучая и никогда не отказывает, но что делать с каналом, через который она общается с внешним миром?
Faoliver Cluster не решает проблему живучести канала. Хотя для её обеспечения тоже есть механизмы — например, всё то же дублирование.
Ну, и CAP ничего не говорит про пропадание связи между клиентом и системой.

DI>А еще помним про сценарии 1, 2, 3.
Вот реально — всё это очень хорошо описано у Клеппмана. Вместе с критикой CAP, которая полностью бесполезна для ответов на заданные вопросы.

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

S>И? двухчасовой даунтайм? При этом он зааффектил вовсе не всю инфраструктуру DNS, а только её крошечный кусочек. Ок, давайте возьмём период в год — посчитайте, сколько получается девяток.

А есть какая-то методолгия расчета девяток, т.е. мы должны учесть каждый узел компонент и т.д., выбрать наименьшее и т.д. ? В контксте availability.

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

DI>>Сценарий 1 разделяемыми данными здесь является только "карта шардов"

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

Вот этот сценарий не рассмотрели:

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

И этот:

Сценарий 3. Внезапно оказалось, что данные на одной ноде популярнее других (лента новостей Джастина Бибера) и количество запросов превысило пропускную способность ноды. Ок. Мы отселили Джастина Бибера на другую ноду (возможен сценарий 2 и кстати как ты организуешь переезд без даунтайма с сохранением консистентности?) и оказалось, что Джастин уже не популярен, а у молодежи новый кумир (молодежь оказалась ветренной и каждую неделю вкусы меняются).

DI>>Но ведь не получим, ведь нода все еще может стать недоступной,
S>Эмм, но ведь живучесть failover cluster как бы выше, чем живучесть одной ноды, не так ли?
DI>>ну ок, допустим сама нода крайне живучая и никогда не отказывает, но что делать с каналом, через который она общается с внешним миром?
S>Faoliver Cluster не решает проблему живучести канала. Хотя для её обеспечения тоже есть механизмы — например, всё то же дублирование.

И мы напарываемся на проблему синхронизации данных, со всеми вытекающими.

S>Ну, и CAP ничего не говорит про пропадание связи между клиентом и системой.

Как это не говорит? Вот в википедии пишут:

Partition tolerance: The system continues to operate despite an arbitrary number of messages being dropped (or delayed) by the network between nodes

Если это неправильное определение, то дай правильное.

DI>>А еще помним про сценарии 1, 2, 3.
S>Вот реально — всё это очень хорошо описано у Клеппмана.

Ну то есть ты почитал и понял, что в предложенной тобой архитектуре не решены вопросы ни доступности, ни масштабируемости?

S>Вместе с критикой CAP, которая полностью бесполезна для ответов на заданные вопросы.

Я правда недоумеваю, зачем бороться с ветряными мельницами, ну устроен мир вот так — везде компромисы. Обратного так никто из борящихся так и не показал

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

S>>>И тем не менее, в ваших определениях это никак не связано. Availability в вашей формулировке всего лишь требует получать ответ на каждый запрос — при этом нет никаких временных рамок; это означает, что при росте нагрузки можно наращивать время ожидания результата безо всяких дополнительных телодвижений.
S>·>Не понял что за рамки имеешь в виду. Вообще-то, timeout error это тоже error в терминах Availability. Наращивать сколько конкретно? Хинт: O(∞) — оксюморон.
S>Я имею в виду как раз величину таймаута. Я вижу, вы уже понимаете, что без таймаута говорить об availability никакого смысла нет.
S>И, что ещё лучше, вы готовы к конструктивному разговору: насколько именно придётся наращивать таймаут в зависимости от объёма данных.
S>Это прекрасно, это именно то, чего я хочу. Но для такого разговора придётся отказаться от CAP и перейти к чему-то более серъёзному, типа Service Reliability Engineering.
S>CAP вам в этом никак не поможет, т.к. она не оперирует ни привычными нам параметрами A, выраженными в %, ни таймаутами, ни MTTR, ни replication delay.
Т.е. подобрать таймауты и прочие параметры таким образом, чтобы у нас все сообщения доставлялись, т.е. не было partition и получить CA-систему. Да, так тоже можно. И что?

S>·>В очередях бесконечной длины? Круто чё. Если ты не просёк, то мы рассматриваем не обработку 1млрд запросов, посланных за секунду, а систему, способную обрабатывать 1млрд запросов в секунду.
S>Вы как-то произвольно прыгаете между математической абстракцией (миллиард RPS) и практической реализацией.
Я не прыгаю. Это просто такой яркий пример когда без P не обойтись никак, просто из-за физических свойств нашей вселенной.

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

S>·>И пока какой-то из этих серверов лежит, система неконсистентна или недоступна. ЧТД.

S>Ну, а теперь заменим каждый сервер на failover cluster.
И?

S>·>Там есть о взаимоотношении R и W _одного_ регистра. Т.е. случаи "пишем в X, читаем Y" или "пишем в X, пишем в Y и никогда ничего не читаем" или "читаем X и читаем Y" — это не то что описывает теорема, да и на практике нечасто встречается.
S>Ну так вы-то хотите "пишем X и Y", а это — вовсе не один регистр.
Я так не хочу, наверное я где-то неточно выразился или вы не так поняли.

S>·>А теорему не интересует что вас это не интересует. Теорема — это теория, а не практика. Например, есть теорема о том, что алгоритм сортировки нельзя сделать быстрее чем O(n*log(n)). И тут приходят "практики" и "опровергают" теорему: "а у нас тут поразрядная сортировка", "а у нас тут много ядер", "а у нас тут такие данные".

S>Отличный пример, как раз в тему дискуссии. Я не очень хочу отвлекаться от CAP, поэтому ограничимся иллюстративными рассуждениями.
S>1. Вы подменяете утверждение "меньше чем за n*log(n) сравнений" утверждением "быстрее, чем за O(n*log(n))". Скорость — это время (количество тактов), она не равна количеству операций. Верно вы пишете — "а у нас много ядер". Формулы для нижней границы количества тактов в зависимости от количества параллельных компараторов и размера входных данных пока что получить не удалось (см. Кнут, III). Алгоритмы, сортирующие быстрее, чем n*logN, совершенно точно есть.
В смысле это опровергает теорему или что?

S>2. Вы игнорируете тот факт, что для большинства систем интересна не нижняя граница, а Nth Percentile. Грубо говоря, за какое время завершатся 99% сортировок, при заданном нами распределении входных данных. Верно вы пишете — "а у нас тут такие данные".
S>И там, где "математик" победно пишет "я доказал, что сортировать быстрее чем за O(n*log(n)) невозможно" и идёт обедать, "инженер" продолжает искать, и находит решение, которое почти всегда сортирует данные за log(n).
Вот именно, что он ищет это "почти всегда", зная где искать и где именно искать компромиссы, благодаря выводам математика. Либо это инженер-любитель, который тыкается наугад.

S>·>Ещё раз. Алгоритмам питание не нужно.
S>Ну так алгоритмы и не ломаются. В математическом мире все ноды мгновенно достижимы. Недостижимость ноды — это математическая модель реального мира.
S>Проблема CAP — в том, что "ломаемость" мира в модель добавили, а "починимость" — нет. Давайте предположим, что одиночный сегмент сети восстанавливается после сбоя за время T_R. Вряд ли оно зависит от количества сегментов; выбрав таймаут операции большим, чем T_R, мы получим консистентную и доступную систему, терпимую к разделению кластера.
В CAP это не "ломаемость" мира. А просто условия, что у нас де иногда сообщения теряются. Или у нас данныех будет бардак. Или мы застрянем. И с чем-то из этого там придётся мириться и учитывать. Это вполне реальность и практика. "Починимости" собственно никакой быть не может. Мы лишь можем принять мир какой он есть.

S>Если мы зададим ожидаемую частоту выхода сегментов из строя (MTBF), то для любого наперёд заданного показателя Availability мы сможем рассчитать потребную величину таймаута — с учётом того, что несколько сбоев могут наложиться друг на друга.
А если получится так, что эта величина таймаута выше возможной?

S>·>И?
S>

S>The vast majority of software services and systems should aim for almost-perfect reliability rather than perfect reliability—that is, 99.999 or 99.99 percent rather than 100 percent—because users cannot tell the difference between a service being 100 percent available and less than "perfectly" available.

S>(https://queue.acm.org/detail.cfm?id=3096459)
Только это всё никоим образом не противоречит теореме.

Здравствуйте, ·, Вы писали:
S>>CAP вам в этом никак не поможет, т.к. она не оперирует ни привычными нам параметрами A, выраженными в %, ни таймаутами, ни MTTR, ни replication delay.
·>Т.е. подобрать таймауты и прочие параметры таким образом, чтобы у нас все сообщения доставлялись, т.е. не было partition и получить CA-систему. Да, так тоже можно. И что?
И всё. Вот вам бесславный финал CAP теоремы.

·>Я не прыгаю. Это просто такой яркий пример когда без P не обойтись никак, просто из-за физических свойств нашей вселенной.
Совершенно верно, без P обойтись никак. А теорема Брюера делает вид, что существуют AC системы.

·>Ну... ээ.. даже допустим, что затруднительно, то... ээ.. и что?
И всё. Задачи нет, решение не нужно.
S>>Ну, а теперь заменим каждый сервер на failover cluster.
·>И?
И система становится доступной.

·>Я так не хочу, наверное я где-то неточно выразился или вы не так поняли.
Ну как же. Вы же хотите транзакционный перевод, т.е. согласованное изменение балансов в двух аккаунтах, которые лежат на разных нодах.

·>В смысле это опровергает теорему или что?
Нет, это опровергает ваше утверждение.

S>>И там, где "математик" победно пишет "я доказал, что сортировать быстрее чем за O(n*log(n)) невозможно" и идёт обедать, "инженер" продолжает искать, и находит решение, которое почти всегда сортирует данные за log(n).
·>Вот именно, что он ищет это "почти всегда", зная где искать и где именно искать компромиссы, благодаря выводам математика. Либо это инженер-любитель, который тыкается наугад.
Благодаря выводам какого-то другого математика. Потому что процитированная вами теорема никак не помогает. Наоборот — она провоцирует инженеров на скорые выводы — ну, вот как вы поспешили написать "нельзя быстрее, чем".

·>В CAP это не "ломаемость" мира. А просто условия, что у нас де иногда сообщения теряются. Или у нас данныех будет бардак. Или мы застрянем. И с чем-то из этого там придётся мириться и учитывать. Это вполне реальность и практика. "Починимости" собственно никакой быть не может. Мы лишь можем принять мир какой он есть.
Как это не может??? Без починимости мы имеем неуклонно деградирующий мир. Вот у нас есть доказательство того, что кластер с 2N+1 нодами остаётся консистентно-доступным, пока доступны N нод. Если не рассматривать его починимым, то получается, что через N+1 сбоев он перестанет быть доступным, и это уже навсегда.

S>>Если мы зададим ожидаемую частоту выхода сегментов из строя (MTBF), то для любого наперёд заданного показателя Availability мы сможем рассчитать потребную величину таймаута — с учётом того, что несколько сбоев могут наложиться друг на друга.
·>А если получится так, что эта величина таймаута выше возможной?
Тогда у нас будет повод изменить MTBF сегментов — например, продублировав их.
·>Только это всё никоим образом не противоречит теореме.
Это противоречит её практическому применению.

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

S>·>Я не прыгаю. Это просто такой яркий пример когда без P не обойтись никак, просто из-за физических свойств нашей вселенной.
S>Совершенно верно, без P обойтись никак. А теорема Брюера делает вид, что существуют AC системы.
Вообще говоря, существуют и даже активно впариваются клиентам. Ярким представителем является Oracle RAC, где при правильной установке получается 3-кратное дублирование каналов связи и анальное самоогораживание узлов при первых признаках проблем. Что привело к паре очень громких публичных фэйлов, кстати.

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

DI>Так и я про члены кластера. Твоя архитектура не учитывает, что в кластере из чудесных высоконадежных компонентов, может пропадать связь между компонентами.
Мы всё ещё про failover cluster? В нём как раз всё учтено.
Если речь про failover clusters, из которых построена sharded — система, то ей наплевать на пропадание связи между компонентами. Как мы вроде бы выяснили.

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

Ну ок, давайте по пунктам.
2. Что делать, когда нагрузка превышает пропускную способность ноды.
Это тот же самый п.1 — перевозим часть шардов на соседние / новые ноды, вплоть до выравнивания нагрузки.
3. Что делать, если популярность Джастина выросла — переселяем его на отдельную ноду.
3.1. Что делать, если популярность Джастина упала — подселяем его обратно на ноду с низкой нагрузкой. Переселяем нового кумира. Называется это dynamic sharding.

Вопрос со звёздочкой: Как организовать переезд без даунтайма.
Шаг 1: Начинаем репликацию данных с ноды X на ноду Y
Шаг 2: Переключаем Master для нашего шарда с ноды X на ноду Y, указывая ноду X в качестве fallback при чтении данных. То есть нода Y знает, что если что-то не найдено, надо форварднуть реквест на ноду X.
Шаг 3: Дожидаемся окончания репликации
Шаг 4: Отключаем fallback, удаляем шард с ноды X.

На шагах 2 и 3 может потребоваться ожидание консенсуса. Алгоритмы для этого есть.

DI>>>Я правда недоумеваю, зачем бороться с ветряными мельницами, ну устроен мир вот так — везде компромисы. Обратного так никто из борящихся так и не показал

S>>Мир — да, именно так и устроен. А в CAP никаких компромиссов нет. За это мы её и не любим.

DI>Это демагогия — выражение "все в мире компромисы" не верно, так как бескомпромисно.
Ну так это же ваше утверждение. Вы уже определитесь, за вы или против.

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

S>>>CAP вам в этом никак не поможет, т.к. она не оперирует ни привычными нам параметрами A, выраженными в %, ни таймаутами, ни MTTR, ни replication delay.
S>·>Т.е. подобрать таймауты и прочие параметры таким образом, чтобы у нас все сообщения доставлялись, т.е. не было partition и получить CA-систему. Да, так тоже можно. И что?
S>И всё. Вот вам бесславный финал CAP теоремы.
Эээ?

S>·>Я не прыгаю. Это просто такой яркий пример когда без P не обойтись никак, просто из-за физических свойств нашей вселенной.
S>Совершенно верно, без P обойтись никак. А теорема Брюера делает вид, что существуют AC системы.
А они не существуют? Один сервак — типичная CA-система.

S>·>Ну... ээ.. даже допустим, что затруднительно, то... ээ.. и что?
S>И всё. Задачи нет, решение не нужно.
Задача есть и решения есть.

S>>>Ну, а теперь заменим каждый сервер на failover cluster.
S>·>И?
S>И система становится доступной.
Но не консистентной.

S>·>Я так не хочу, наверное я где-то неточно выразился или вы не так поняли.
S>Ну как же. Вы же хотите транзакционный перевод, т.е. согласованное изменение балансов в двух аккаунтах, которые лежат на разных нодах.
Ну и?
Я делаю перевод с аккаунта 1, на аккаунт 2. Как я потом могу делать перевод с 2 на 3 или с 1 на 4, если произошло разделение? Если допускать овердрафты и рисковать потерями денег, то система будет AP. Если не допускать, то CP (некоторые переводы не будут проходить). Либо сделать чтобы не было разделения — всех клиентов послать в одно отделение банка и пусть там стоят в одной очереди, то будет CA (правда в этом случае клиенты скорее всего просто пойдут в другой банк). Четвёртого не дано.

S>·>В смысле это опровергает теорему или что?
S>Нет, это опровергает ваше утверждение.
Которое?

S>·>Вот именно, что он ищет это "почти всегда", зная где искать и где именно искать компромиссы, благодаря выводам математика. Либо это инженер-любитель, который тыкается наугад.
S>Благодаря выводам какого-то другого математика. Потому что процитированная вами теорема никак не помогает. Наоборот — она провоцирует инженеров на скорые выводы — ну, вот как вы поспешили написать "нельзя быстрее, чем".
Ну так нельзя же. Ты почему-то опровергаешь то, что теорема не утверждает. "Вечного двигателя не существует", а ты это опровергаешь "Но ведь двигатели же существуют!"

S>·>В CAP это не "ломаемость" мира. А просто условия, что у нас де иногда сообщения теряются. Или у нас данныех будет бардак. Или мы застрянем. И с чем-то из этого там придётся мириться и учитывать. Это вполне реальность и практика. "Починимости" собственно никакой быть не может. Мы лишь можем принять мир какой он есть.
S>Как это не может??? Без починимости мы имеем неуклонно деградирующий мир. Вот у нас есть доказательство того, что кластер с 2N+1 нодами остаётся консистентно-доступным, пока доступны N нод. Если не рассматривать его починимым, то получается, что через N+1 сбоев он перестанет быть доступным, и это уже навсегда.
Да говорю же, CAP не про ломаемость\починимость. А про то, какими свойствами могут обладать любые возможные алгоритмы с учётом того, что что-то в принципе может поломаться.

S>>>Если мы зададим ожидаемую частоту выхода сегментов из строя (MTBF), то для любого наперёд заданного показателя Availability мы сможем рассчитать потребную величину таймаута — с учётом того, что несколько сбоев могут наложиться друг на друга.
S>·>А если получится так, что эта величина таймаута выше возможной?
S>Тогда у нас будет повод изменить MTBF сегментов — например, продублировав их.
И как же держать дубликаты in-sync без потери C или A?

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

S>Если речь про failover clusters, из которых построена sharded — система, то ей наплевать на пропадание связи между компонентами. Как мы вроде бы выяснили.
Это в лучшем случае будет CA-система. "в каком отделении открывали счет туда и идите" — это клиентам на такую систему будет наплевать.

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

S>Мы всё ещё про failover cluster? В нём как раз всё учтено.

Он не масштабируется горизонтально.

S>Если речь про failover clusters, из которых построена sharded — система, то ей наплевать на пропадание связи между компонентами. Как мы вроде бы выяснили.

Не наплевать, не выяснили. Я понял твою идею про кластер из супернадежных нод, каждая нода имеет свой набор данных, поэтому не зависит от остальных. Есть одна мелочь — по какому-то признаку организовать шардирование и вот тут возникает маленькая проблемка — вот это знание должно где-то быть, иначе вся система становится бесполезной. Для этих целей делается роутер, пользователь идет в него, роутер говорит куда идти за данными. Ты вообще никак не сказал как с этим жить.

S>Ну ок, давайте по пунктам.
S>2. Что делать, когда нагрузка превышает пропускную способность ноды.
S>Это тот же самый п.1 — перевозим часть шардов на соседние / новые ноды, вплоть до выравнивания нагрузки.

Зайцы, уставшие от постоянных нападений волков, пошли за советом к сове.
Сова:
— Зайцы, станьте ежиками, и тогда вас волки трогать прекратят.
— Мысль хорошая, но как, как стать ежиками? — спросили зайцы.
— Я стратег, — ответила сова. — Тактикой занимайтесь сами.

1. Тебе как-то надо будет обновлять информацию на роутере
2. Чтобы охранить доступность сначала надо перенести данные на новый шард, затем обновить информацию на роутере, в этот момент старые данные могут быть обновлены
3. Ты все еще не решил проблему доступности, когда шард с данными становится недоступен (сетевой провод до него перерезали, например)

И можно продолжать дальше, но давай хотя-бы с этими сценариями разберемся.

S>3. Что делать, если популярность Джастина выросла — переселяем его на отдельную ноду.
S>3.1. Что делать, если популярность Джастина упала — подселяем его обратно на ноду с низкой нагрузкой. Переселяем нового кумира. Называется это dynamic sharding.

Те же проблемы, что и в предыдущем сценарии, плюс определение когда переезд необходим и сложности с самим переездом.

S>Вопрос со звёздочкой: Как организовать переезд без даунтайма.
S>Шаг 1: Начинаем репликацию данных с ноды X на ноду Y
S>Шаг 2: Переключаем Master для нашего шарда с ноды X на ноду Y, указывая ноду X в качестве fallback при чтении данных. То есть нода Y знает, что если что-то не найдено, надо форварднуть реквест на ноду X.
S>Шаг 3: Дожидаемся окончания репликации
S>Шаг 4: Отключаем fallback, удаляем шард с ноды X.

Хорошо, но как нам быть если на Х в этот момент данные обновляются? Или мы жертвуем доступностью?

S>На шагах 2 и 3 может потребоваться ожидание консенсуса. Алгоритмы для этого есть.

Я даже подскажу: 2-х фазный коммит (не работает), 3-х фазный коммит (почти работает), Paxos/Raft (почти всегда работает).

S>Вы уже определитесь, за вы или против.

За или против демагогии? Против, зачем доводить до абсурда и играть словами?

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

S>>Вопрос со звёздочкой: Как организовать переезд без даунтайма.
S>>Шаг 1: Начинаем репликацию данных с ноды X на ноду Y
S>>Шаг 2: Переключаем Master для нашего шарда с ноды X на ноду Y, указывая ноду X в качестве fallback при чтении данных. То есть нода Y знает, что если что-то не найдено, надо форварднуть реквест на ноду X.
S>>Шаг 3: Дожидаемся окончания репликации
S>>Шаг 4: Отключаем fallback, удаляем шард с ноды X.

S>>На шагах 2 и 3 может потребоваться ожидание консенсуса. Алгоритмы для этого есть.

DI>Я даже подскажу: 2-х фазный коммит (не работает), 3-х фазный коммит (почти работает), Paxos/Raft (почти всегда работает).

это такой лютый оверкилл для миграции шардов

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

S>Мы всё ещё про failover cluster? В нём как раз всё учтено.
S>Если речь про failover clusters, из которых построена sharded — система, то ей наплевать на пропадание связи между компонентами. Как мы вроде бы выяснили.

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

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

S>Ну ок, давайте по пунктам.
S>2. Что делать, когда нагрузка превышает пропускную способность ноды.
S>Это тот же самый п.1 — перевозим часть шардов на соседние / новые ноды, вплоть до выравнивания нагрузки.
S>3. Что делать, если популярность Джастина выросла — переселяем его на отдельную ноду.
S>3.1. Что делать, если популярность Джастина упала — подселяем его обратно на ноду с низкой нагрузкой. Переселяем нового кумира. Называется это dynamic sharding.

"перевозим" это как? кто координирует?

S>Вопрос со звёздочкой: Как организовать переезд без даунтайма.
S>Шаг 1: Начинаем репликацию данных с ноды X на ноду Y
S>Шаг 2: Переключаем Master для нашего шарда с ноды X на ноду Y, указывая ноду X в качестве fallback при чтении данных. То есть нода Y знает, что если что-то не найдено, надо форварднуть реквест на ноду X.
S>Шаг 3: Дожидаемся окончания репликации
S>Шаг 4: Отключаем fallback, удаляем шард с ноды X.

кто переключает?

S>На шагах 2 и 3 может потребоваться ожидание консенсуса. Алгоритмы для этого есть.

какие алгоритмы ты имеешь ввиду?

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

CK>>гугли azure dns outage
S>И? двухчасовой даунтайм? При этом он зааффектил вовсе не всю инфраструктуру DNS, а только её крошечный кусочек. Ок, давайте возьмём период в год — посчитайте, сколько получается девяток. А если мы скорректируем эту оценку с учётом того, что большинство DNS запросов в это время продолжали обслуживаться, то полученную Availability побить будет крайне сложно.
S>Но я согласен с вами — DNS малоинтересный пример. Давайте обсуждать то, что вы предложили.

только проблема в том, что Asure прилег из-за этого, и ненадеждность не в том, что была даунтайм, а в том, что неверные данные оттуда удаляются очень не сразу, а пока это не произошло, у тебя ничего не работает

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

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

S>>·>Я не прыгаю. Это просто такой яркий пример когда без P не обойтись никак, просто из-за физических свойств нашей вселенной.
S>>Совершенно верно, без P обойтись никак. А теорема Брюера делает вид, что существуют AC системы.
C>Вообще говоря, существуют и даже активно впариваются клиентам. Ярким представителем является Oracle RAC, где при правильной установке получается 3-кратное дублирование каналов связи и анальное самоогораживание узлов при первых признаках проблем. Что привело к паре очень громких публичных фэйлов, кстати.

скорее к безусловному лидерству в фин секторе. RAC уже процентов 70 фин сектора вытеснив всю noSQL-щину. и в первую очередь потому как нужна настоящая консистеность и availability. а вот ФБ и твитер что-то сбоят кажду неделю уже. т.е. даже лайки и те посчитать не получается.
и пока не видно серьезных конкурентов. доморощенные поделки в стиле динамодб чудовфищно проигрывают обычному хадупу по throughput, при этом в плане консистентности ничего интересней чем то что есть уже у хадупов забесплатно нет. на hdfs писать можно на порядок быстрее.

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

C>Т.е. при необходимости буквы "C" пространство архитектурных выборов снижается до очень небольшого.
Проблема в том, что С, которое в САР, не имеет ничего общего с С, которое нужно бизнесу. В итоге необходимость С есть, но и пространство выборов более чем достаточное, так как это вовсе не то С, которое в теореме.

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

DI>Что говоришь? Я тебе в штаны насрал? Лол, отдыхай, болезный. Еды не будет, гуляй, тролятина.
Так бездарно слился... А как дышал, как дышал!

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

·>Это в лучшем случае будет CA-система. "в каком отделении открывали счет туда и идите" — это клиентам на такую систему будет наплевать.
Не надо говорить за всех клиентов. В мире множество самых разнообразных сценариев и полезными могут быть системы с самыми причудливыми свойствами.
А то вы очень лихо скачите когда вам выгодно со сферической теории в вакууме, на реальный кейс и обратно.

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

DI>Он не масштабируется горизонтально.

S>>Если реч про failover clusters, из которых построена sharded — система, то ей наплевать на пропадание связи между компонентами. Как мы вроде бы выяснили.

DI>Не наплевать, не выяснили. Я понял твою идею про кластер из супернадежных нод, каждая нода имеет свой набор данных, поэтому не зависит от остальных. Есть одна мелочь — по какому-то признаку организовать шардирование и вот тут возникает маленькая проблемка — вот это знание должно где-то быть, иначе вся система становится бесполезной. Для этих целей делается роутер, пользователь идет в него, роутер говорит куда идти за данными. Ты вообще никак не сказал как с этим жить.
Ну вот, а говорите — книгу читали. Роутер строится на основе алгоритмов консенсуса.

DI>И можно продолжать дальше, но давай хотя-бы с этими сценариями разберемся.
Ниже по тексту.

S>>3. Что делать, если популярность Джастина выросла — переселяем его на отдельную ноду.
S>>3.1. Что делать, если популярность Джастина упала — подселяем его обратно на ноду с низкой нагрузкой. Переселяем нового кумира. Называется это dynamic sharding.

DI>Те же проблемы, что и в предыдущем сценарии, плюс определение когда переезд необходим и сложности с самим переездом.

S>>Вопрос со звёздочкой: Как организовать переезд без даунтайма.
S>>Шаг 1: Начинаем репликацию данных с ноды X на ноду Y
S>>Шаг 2: Переключаем Master для нашего шарда с ноды X на ноду Y, указывая ноду X в качестве fallback при чтении данных. То есть нода Y знает, что если что-то не найдено, надо форварднуть реквест на ноду X.
S>>Шаг 3: Дожидаемся окончания репликации
S>>Шаг 4: Отключаем fallback, удаляем шард с ноды X.

DI>Хорошо, но как нам быть если на Х в этот момент данные обновляются? Или мы жертвуем доступностью?
"в этот" — это какой? После шага 2 данные на X обновляться уже не могут: все записи роутятся в Y.

S>>На шагах 2 и 3 может потребоваться ожидание консенсуса. Алгоритмы для этого есть.

DI>Я даже подскажу: 2-х фазный коммит (не работает), 3-х фазный коммит (почти работает), Paxos/Raft (почти всегда работает).
Чем вас не устраивает Raft или модификации Paxos?

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

CK>только проблема в том, что Asure прилег из-за этого, и ненадеждность не в том, что была даунтайм, а в том, что неверные данные оттуда удаляются очень не сразу, а пока это не произошло, у тебя ничего не работает
Бррр. Какие неверные данные?
В последний раз я такую проблему наблюдал в 1999 в Java, где у негативных DNS-респонсов был бесконечный TTL.
Неужто с тех пор кто-то ещё раз наступил на те же грабли?

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

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

CK>"перевозим" это как? кто координирует?
Там ниже пошаговый алгоритм. Координировать может сторонний сервис watchdog; поскольку ему не нужно работать в реальном времени, то availability не проблема.
Можно принимать решение локально — нода, которая предсказывает перегрузку, начинает суетиться.

CK>кто переключает?
Сервис координации. Тут же важно не "кто переключает", а "как убедится, что все ноды трактуют роутинг одинаково".

S>>На шагах 2 и 3 может потребоваться ожидание консенсуса. Алгоритмы для этого есть.

CK>какие алгоритмы ты имеешь ввиду?
Коллега Ivlev уже прокомментировал -Paxos и его потомки, Raft.

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

CK>>какие алгоритмы ты имеешь ввиду?
S>Коллега Ivlev уже прокомментировал -Paxos и его потомки, Raft.

А не напомнишь, о чем собственно спор? Что этот дизайн нам доказывает? И какими по твоему свойствами, опровергающими полезность САР, эта система обладает?

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

DI>>Не наплевать, не выяснили. Я понял твою идею про кластер из супернадежных нод, каждая нода имеет свой набор данных, поэтому не зависит от остальных. Есть одна мелочь — по какому-то признаку организовать шардирование и вот тут возникает маленькая проблемка — вот это знание должно где-то быть, иначе вся система становится бесполезной. Для этих целей делается роутер, пользователь идет в него, роутер говорит куда идти за данными. Ты вообще никак не сказал как с этим жить.
S>Ну вот, а говорите — книгу читали. Роутер строится на основе алгоритмов консенсуса.

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

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

Где? Не увидел.

S>Чем вас не устраивает Raft или модификации Paxos?

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

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

DI>>Соси лапу, тролятина, не подаю.
IB>Как говорят зарубежные коллеги — go fuck yourself. Только не кипятись, сделай это спокойно и с расстановкой, чтобы в другой раз так публично не обделаться. =)

Тролятина, еды нет, соси лапу.

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

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

DI>>Тролятина, еды нет, соси лапу.
IB>Да вы еще уныло однообразны — полная печаль...

Тролятина, еды нет, соси лапу.

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

C>>Т.е. при необходимости буквы "C" пространство архитектурных выборов снижается до очень небольшого.
IB>Проблема в том, что С, которое в САР, не имеет ничего общего с С, которое нужно бизнесу. В итоге необходимость С есть, но и пространство выборов более чем достаточное, так как это вовсе не то С, которое в теореме.
Без разницы. Отказ от классического "C" сразу влечёт кардинальное изменение архитектуры.

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

DI>Тролятина, еды нет, соси лапу.
У тебя уже несколько суток лидер лежит и твой ~~хваленый~~ Raft видимо нихера не работает.

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

C>Без разницы. Отказ от классического "C" сразу влечёт кардинальное изменение архитектуры.
Да мы-то о другом, к классическому С претензий нет. Проблема в том С, которое в CAP — оно ни разу не классическое.

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

C>>Т.е. при необходимости буквы "C" пространство архитектурных выборов снижается до очень небольшого.
IB>Проблема в том, что С, которое в САР, не имеет ничего общего с С, которое нужно бизнесу. В итоге необходимость С есть, но и пространство выборов более чем достаточное, так как это вовсе не то С, которое в теореме.
Уточню. "C" или есть, или его нет. Это как беременность.

Если "C" нет, то есть разные варианты "eventual consistency". И да, eventual consistency вполне удовлетворяет большинство компаний.

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

C>>Без разницы. Отказ от классического "C" сразу влечёт кардинальное изменение архитектуры.
IB>Да мы-то о другом, к классическому С претензий нет. Проблема в том С, которое в CAP — оно ни разу не классическое.
То есть? "C" там вполне классическое — гарантия того, что события будут одинаково упорядочены для разных наблюдателей (как следствие "every read receives the most recent write").

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

C>То есть? "C" там вполне классическое — гарантия того, что события будут одинаково упорядочены для разных наблюдателей (как следствие "every read receives the most recent write").
Не для разных наблюдателей и не имеет это ничего общего с классикой. Конкретно для CAP ввели специальный термин "atomic consistency", который потом сократили до просто consistency, для простоты. И пришлось очень долго объяснять, что этот термин не имеет ничего общего ни с atomicity ни с consistency, в общепринятом, классическом понимании этих терминов. А вводить специальный термин пришлось, потому что иначе красивой теоремы не получилось бы.

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

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

C>>>Вообще говоря, существуют и даже активно впариваются клиентам. Ярким представителем является Oracle RAC, где при правильной установке получается 3-кратное дублирование каналов связи и анальное самоогораживание узлов при первых признаках проблем. Что привело к паре очень громких публичных фэйлов, кстати.
Gt_>>скорее к безусловному лидерству в фин секторе. RAC уже процентов 70 фин сектора вытеснив всю noSQL-щину.
C>Кто куда перешёл? Классический процессинг в нынешней технологии можно обработать в масштабах всей страны на одной персоналке. Там вообще ничего нетривиального по меркам современных технологий нет, так что я не удивляюсь, что впариватели из Оракала его успешно пихают.

студент детектед. финсектор и банки это не только лишь процессинг

C>А вот в инвестиционном банкинге или финтехе — никакими RAC и не пахнет.

на переферии может быть, в европе exadata съела все и вся.

Gt_>>и пока не видно серьезных конкурентов. доморощенные поделки в стиле динамодб чудовфищно проигрывают обычному хадупу по throughput, при этом в плане консистентности ничего интересней чем то что есть уже у хадупов забесплатно нет. на hdfs писать можно на порядок быстрее.
C>

Хадуп занимается совсем другим.

совсем другим занимается олтп в фин секторе, откуда и вытеснилди RAC весь этот изредко консистентный NoSQL

C>Ну и как насчёт миллиарда запросов в секунду на DDB? Это "проигрывают обычному хадупу"?

а кому в 21 интересны запрсы ? на дворе 21 век, кругом реалтайм стриминг. кафка + спарк + hdfs давно стандарт в отрасли.
что такое ddb ?
кстати, 10 лет назад RAC уже на 5-6 нодах выдавал десятки млн транзакций в тестах tpc-c. т.е. порядка сотни млн запросов. сейчас, спустя десятилетие млрд запросов tpc-c прожует и половинка exadata.

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

S>·>Я делаю перевод с аккаунта 1, на аккаунт 2. Как я потом могу делать перевод с 2 на 3 или с 1 на 4, если произошло разделение? Если допускать овердрафты и рисковать потерями денег, то система будет AP. Если не допускать, то CP (некоторые переводы не будут проходить). Либо сделать чтобы не было разделения — всех клиентов послать в одно отделение банка и пусть там стоят в одной очереди, то будет CA (правда в этом случае клиенты скорее всего просто пойдут в другой банк). Четвёртого не дано.
S>

S>Во-первых, сведя всё к одному серверу, А вы не получите, как я уже упомянул. Вы её не улучшите, а ухудшите.
Ты не понял. На серваке работает алгоритм, который обладает CA-свойством. Однонодовая система принципиально разделяться не может.

S>Во-вторых, вы опять забываете про то, что "разделение" — это временная штука. Если у нас время восстановления меньше, чем SLA на транзакцию по переводу денег, то система будет CAP.
В CAP разделение это потеря сообщений. Потеряли, а потом нашли что-ли?

S>В-третьих, в задаче про переводы денег, как и в любой другой, нас интересует не 100% Availability, а "экономически оправданная". И если мы внимательно рассмотрим требования и возможности, то окажется, что мы можем сделать так, что даже при разделении кластера у нас будут падать не все запросы, а только достаточно небольшая их доля. При определённых усилиях окажется так, что эта доля будет меньше доли запросов, которые падают по несвязанным с разделением причинам.
S>Опять-таки, CAP нам в этом никак не поможет.
Т.е. ты описал CP-систему. Об чём спор-то?

S>>>Нет, это опровергает ваше утверждение.
S>·>Которое?
S>"алгоритм сортировки нельзя сделать быстрее чем O(n*log(n))"
Я не знаю что ты имеешь в виду. Алгоритм обладает двумя сложностными характеристиками — пространство (память) и время (макс число операций). Я не имел в виду физическое время. В контексте O-нотации по-моему очевидно какое время имеется в виду. Под "Быстрее" я имел в вмиду требует меньше времени.

S>·>Ну так нельзя же. Ты почему-то опровергаешь то, что теорема не утверждает. "Вечного двигателя не существует", а ты это опровергаешь "Но ведь двигатели же существуют!"
S>

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

S>>>Тогда у нас будет повод изменить MTBF сегментов — например, продублировав их.
S>·>И как же держать дубликаты in-sync без потери C или A?
S>Очень просто: берём 2 (два) провода, воткнутые в две сетевые карточки. Сможете сами рассчитать вероятность выхода из строя одновременно обеих, если вероятность выхода из строя одной известна?
И дальше что? Сетевые карточки будет обслуживать сервак, который внезапно может перестать отвечать, по обоим проводам.

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

C>>Кто куда перешёл? Классический процессинг в нынешней технологии можно обработать в масштабах всей страны на одной персоналке. Там вообще ничего нетривиального по меркам современных технологий нет, так что я не удивляюсь, что впариватели из Оракала его успешно пихают.
Gt_>студент детектед. финсектор и банки это не только лишь процессинг
Ещё мелочи типа load underwriting, но там тоже (ВНЕЗАПНО!) нет никакого RAC. Так как нужна производительность.

C>>А вот в инвестиционном банкинге или финтехе — никакими RAC и не пахнет.
Gt_>на переферии может быть, в европе exadata съела все и вся.
Ага, конечно.

C>>

Хадуп занимается совсем другим.
Gt_>совсем другим занимается олтп в фин секторе, откуда и вытеснилди RAC весь этот изредко консистентный NoSQL
DynamoDB — это OLTP, а не аналитика. JFYI.

C>>Ну и как насчёт миллиарда запросов в секунду на DDB? Это "проигрывают обычному хадупу"?
Gt_>а кому в 21 интересны запрсы ? на дворе 21 век, кругом реалтайм стриминг. кафка + спарк + hdfs давно стандарт в отрасли.
Чатбот детектед.

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

CK>А не напомнишь, о чем собственно спор? Что этот дизайн нам доказывает? И какими по твоему свойствами, опровергающими полезность САР, эта система обладает?
Эта система гарантирует consistency при очень неплохой availability.
Опровергает полезность это очень просто — с т.з. CAP, все CP системы одинаково бесполезны.
А с точки зрения инженерной (и бизнеса) availability в 1 девятку очень сильно отличается от availability в 5 девяток.

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

CK>>А не напомнишь, о чем собственно спор? Что этот дизайн нам доказывает? И какими по твоему свойствами, опровергающими полезность САР, эта система обладает?
S>Эта система гарантирует consistency при очень неплохой availability.
S>Опровергает полезность это очень просто — с т.з. CAP, все CP системы одинаково бесполезны.
Конкретно CAP тут сама по себе непричём, но у всех CP или CA систем есть ограничение по масштабируемости.

Здравствуйте, Cyberax, Вы писали:
C>Конкретно CAP тут сама по себе непричём, но у всех CP или CA систем есть ограничение по масштабируемости.
Давайте же озвучим это ограничение!

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

C>Основная проблема — трафик синхронизации масштабируется экспоненциально с ростом числа узлов в CP-системах. В CA-системах с ростом числа узлов экспоненциально увеличивается риск отказа.
Вот такая теорема была бы существенно полезнее САР.
О чем собственно, и весь этот разговор.

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

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

CK>>А не напомнишь, о чем собственно спор? Что этот дизайн нам доказывает? И какими по твоему свойствами, опровергающими полезность САР, эта система обладает?
S>Эта система гарантирует consistency при очень неплохой availability.

"при очень неплохой" это субъективное суждение, как минимум, твоя система реплицирует данные только внутри ДЦ, потому что каждый replica set (который ты назваешь failover cluster, так себе название для _части_ кластера) может жить только в каком-то одном ДЦ, ты с этим согласен?

Твое понимание consistency тоже отличается от общепринятого (если я тебя правильно понял), в том смысле, что если у нас недоступен один replica-set а значит и какой-то диапазон ключей, то система потеряла доступность. Даже если он недоступен только на запись. Поэтому каждый раз, когда твой watchdog сервис делает failover, твоя система частично недоступна какое-то время. Если watchdog прилег, то неограниченно долгое. Поэтому обычно, за failover в таких системах отвечает не один сервис, а кластер. Посмотри на Redis Sentinel.

Сервис координации тоже нельзя рассматривать отдельно. Вообще, в твоей системе replica-set-ы (aka failover cluster-ы) могут быть тупыми хранилищами, а запросы пользователей на запись и чтение могут поступать сначала на front-end узлы, которые бы уже перенаправляли их в нужный replica set. Эти front-end узлы должны учатсвовать в консенсусе, чтобы иметь одинаковый routing. Эти же front-end узлы могут перемещать шарды с одного replicaset-а на другой, при реконфигурации кластера.

S>Опровергает полезность это очень просто — с т.з. CAP, все CP системы одинаково бесполезны.

Можно подробнее? Я не припомню, чтобы из САР теоремы можно было сделать такой вывод.

S>А с точки зрения инженерной (и бизнеса) availability в 1 девятку очень сильно отличается от availability в 5 девяток.

Tier 4 data-center гарантирует 99.995 доступность. То бишь в рамках одного ДЦ ты не получишь 5 девяток. AWS и Asure, насколько я знаю, тоже не обеспечивают 5 девяток, если ты держишь все в одном ДЦ.

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

C>>Основная проблема — трафик синхронизации масштабируется экспоненциально с ростом числа узлов в CP-системах. В CA-системах с ростом числа узлов экспоненциально увеличивается риск отказа.
S>Спасибо, очень интересно!
S>Хотелось бы почитать про это более подробно, с формулами и доказательствами. Это как раз то, что я ищу.
С CA-системами всё понятно — при росте числа узлов вероятность отказа хотя бы одного из них растёт экспоненциально (просто сумма вероятностей).

При гарантированном CP нужно запускать алгоритмы консенсуса на каждое чтение. При увеличении числа узлов трафик будет расти минимум квадратично, но без учёта конфликтов.

S>По идее, это даст возможность получить ту самую математику, которой не хватает — формулу, которая связывает не булевые, а рациональные значения C, A, и P.
Тут основной затык на букве "C". Оно или есть, или её нет. Если есть, то можно делать определённые компромиссы между A/P. Если отказываться от C, то пространство решений существенно расширяется.

На практике, самое основное значение вносит необходимость географической распределённости.

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

C>С CA-системами всё понятно — при росте числа узлов вероятность отказа хотя бы одного из них растёт экспоненциально (просто сумма вероятностей).
Зато вероятность отказа одновременно N/2+1 узлов падает.
C>При гарантированном CP нужно запускать алгоритмы консенсуса на каждое чтение. При увеличении числа узлов трафик будет расти минимум квадратично, но без учёта конфликтов.
Ну, трафик-трафиком, а как будет зависеть от N матожидание 50-percentile? Можно же две модели рассматривать — та, в которой network congestion пренебрегаем, и та, в которой учитываем.
Если нам для консенсуса надо дождаться N/2+1 ответов, то нас интересуют самые быстрые

C>Тут основной затык на букве "C". Оно или есть, или её нет. Если есть, то можно делать определённые компромиссы между A/P. Если отказываться от C, то пространство решений существенно расширяется.
Ну вот C ведь тоже можно измерять.

C>На практике, самое основное значение вносит необходимость географической распределённости.
На пальцах всё это понятно.

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

CK>"при очень неплохой" это субъективное суждение, как минимум, твоя система реплицирует данные только внутри ДЦ, потому что каждый replica set (который ты назваешь failover cluster, так себе название для _части_ кластера) может жить только в каком-то одном ДЦ, ты с этим согласен?
Согласен. Но даже получить availability "такую же, как у Data Center" — вполне неплохое достижение для приложения.

CK>Твое понимание consistency тоже отличается от общепринятого (если я тебя правильно понял), в том смысле, что если у нас недоступен один replica-set а значит и какой-то диапазон ключей, то система потеряла доступность.
Ээээ, так consistency или availability?

CK>Сервис координации тоже нельзя рассматривать отдельно. Вообще, в твоей системе replica-set-ы (aka failover cluster-ы) могут быть тупыми хранилищами, а запросы пользователей на запись и чтение могут поступать сначала на front-end узлы, которые бы уже перенаправляли их в нужный replica set. Эти front-end узлы должны учатсвовать в консенсусе, чтобы иметь одинаковый routing. Эти же front-end узлы могут перемещать шарды с одного replicaset-а на другой, при реконфигурации кластера.
Совершенно верно.
CK>Можно подробнее? Я не припомню, чтобы из САР теоремы можно было сделать такой вывод.
Всё наоборот — никакого другого вывода из CAP теоремы сделать нельзя. Если у вас есть способ вывести из CAP теоремы что-то более конструктивное, чем "обеспечение availability при partition tolerance требует отказа от consistency" — продемонстрируйте.

CK>Tier 4 data-center гарантирует 99.995 доступность. То бишь в рамках одного ДЦ ты не получишь 5 девяток. AWS и Asure, насколько я знаю, тоже не обеспечивают 5 девяток, если ты держишь все в одном ДЦ.
И?

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

S>Согласен. Но даже получить availability "такую же, как у Data Center" — вполне неплохое достижение для приложения.

чтобы было так же, как у ДЦ, нужно чтобы твое приложение работало вообще без отказов, я слабо представляю как такое возможно

CK>>Твое понимание consistency тоже отличается от общепринятого (если я тебя правильно понял), в том смысле, что если у нас недоступен один replica-set а значит и какой-то диапазон ключей, то система потеряла доступность.
S>Ээээ, так consistency или availability?

бес попутал, availability конечно

CK>>Можно подробнее? Я не припомню, чтобы из САР теоремы можно было сделать такой вывод.
S>Всё наоборот — никакого другого вывода из CAP теоремы сделать нельзя. Если у вас есть способ вывести из CAP теоремы что-то более конструктивное, чем "обеспечение availability при partition tolerance требует отказа от consistency" — продемонстрируйте.

Я про "с т.з. CAP, все CP системы одинаково бесполезны". САР вообще про полезность ничего не говорит, кмк. Не очень понятно как можно вывод о бесполезности из нее сделать.

CK>>Tier 4 data-center гарантирует 99.995 доступность. То бишь в рамках одного ДЦ ты не получишь 5 девяток. AWS и Asure, насколько я знаю, тоже не обеспечивают 5 девяток, если ты держишь все в одном ДЦ.
S>И?
Ну дык, ты же сам писал — "А с точки зрения инженерной (и бизнеса) availability в 1 девятку очень сильно отличается от availability в 5 девяток", то бишь если с точки зрения бизнеса, нужно иметь пять девяток, то тебе нужно в multidatacenter setup, если бизнес хочет гео-распределенность, ради низкой latency, тоже самое. Требования к системе диктуют tradeoff-ы, которые ты можешь использовать. Поэтому докозательство в духе — вот СР система, которая может в HA, поэтому на практике она ничем не уступает AP системам, по крайней мере с точки зрения пользователя — не работает. Уступает.

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

DI>>Во-первых, про роутер ты в своей архитектуре ты ничего не говорил, пока я не указал, что он нужен.
S>Вы как-то ловко подменяете задачу.

И что я подменил?

S>Началось всё, напомню, с вашего безапелляционного заявления о том, что failover cluster невозможно масштабировать.

И это так.

S>Вам показали, как именно его можно масштабировать.

Нет, не показали.

S>Речи о том, что failover cluster — это серебряная пуля, или обязательства нарисовать полную архитектуру, которая обеспечивает CAP для произвольно придуманной прикладной задачи, не было.

Дал заднюю.

DI>>Во-вторых, ссылку то дай, а то пока твое слово против моего и не я должен опровергать, что в книге нет, а ты доказывать. В-третьих, дай-то уж нормальное описание предлагаемой тобой архитектуры, а то пока ты только что-то туманное вбросил.
S>Эти вопросы освещены в главе 6, Partitioning. Страницы с 209 по 216.

Обсуждение есть, а подтверждения твоим словам нет.

S>Все поставленные вами задачи сводятся к rebalancing partitions. Я вам написал пошаговый сценарий перевоза шарда с одной ноды на другую.
S>>>Чем вас не устраивает Raft или модификации Paxos?
DI>>Подожди, давай ты сначала покажешь масштабируемую архитектуру обеспечивающую доступность и консистентность. Пока почему-то ты просто скипаешь мои аргументы.
S>Мне неизвестна единая архитектура, обеспечивающая CAP для произвольного масштаба, и пригодная для произвольной прикладной задачи.

Все? Ожидаемо оказался заборот САР, "чистый шардинг" сдулся. Ну и стоило ли упрямствовать?

S>В целом, направление разработки — именно такое: шардинг + репликация; линки различной степени надёжности для локальных и для глобальных коммуникаций; консенсус для обеспечения C и A (как, например, в SQL Azure, где коммит требует "2 из 3"). Для роутинга выбираются более консервативные алгоритмы консенсуса, т.к. там можно оптимизироваться для "mostly read" нагрузки, и потеря availability в операциях записи нам не так страшна.

Ок

Здравствуйте, chaotic-kotik, Вы писали:
CK>Общепринятое определение availability — количество времени, которое система (либо ее часть) была недоступна.
CK>(525600 − M) ÷ 525600 (где М — время простоя в минутах)
Во-первых, наоборот. Время, когда система была доступна.
Во-вторых, про период ровно в год — это вы взяли один пример, и думаете, что он и есть определение. Очевидно, что он неверный — система, пролежавшая полтора года, по вашей формуле имеет availability равную (-50%).
В-третьих, этот подход (время доступности) — это упрощение, изначально предложенное для систем непрерывного действия (например, электростанций).
Когда мы говорим о программных системах, вообще разговор о "mission capable" не имеет смысла, пока у нас нет входящих запросов. В принципе нет никакого способа отличить рабочую систему от нерабочей, не присылая ей запросов.
Именно на этом построена идея накатывать апдейты во время низкой нагрузки — это позволяет улучшить availability.
Рассуждать об availability распределённой системы как о возможности исполнить любой запрос не имеет смысла — с этой точки зрения, availability системы DNS равна нулю, т.к. в каждый момент времени какой-то из сотен тысяч участвующих в ней серверов обязательно лежит. Работоспособность системы построена как раз на том, что большинство отправляемых запросов таки достигают рабочих серверов; доля запросов, упирающихся в сломанный DNS, относительно мала.

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

CK>availability из CAP не имзеряется в девятках, ты это понимаешь, о чем тогда спор?
О практической применимости CAP.

CK>опять заворачивание всего в один юзкейс?
Это попытка объяснить, что даже тот юзкейс, для которого потенциально можно было бы применить CAP, не работает.
CK>вот тебе другой юзкейс, один поисковик собирает клики пользователей и записывает их в распределенное хранилище, данных прилетает примерно петабайт в день, консистентность не нужна
Не очень понятно, что вы тут называете "консистентностью", и что — "доступностью" И тем не менее — каким образом CAP поможет нам принять какое-то решение в этом случае?
Что такого умного вы сможете сделать, зная CAP, чего вы не могли бы, не имея доказательства CAP?

CK>или вот такой — наш интернет магазин доставляет товары в ЮВА, Европе и Америке, сделай так, чтобы данные хранились и обрабатывались как можно ближе к пользователю
Ок, опять. Что такое "как можно ближе к пользователю"? Тут, конечно, интуитивно понятно, что хочется иметь консистентность на уровне хотя бы "размещённые заказы не теряются", и availability на приемлемом уровне (например, три девятки).
Мотивацией для "ближе к пользователю" могут быть два совершенно разных фактора: один — это response times, которым в современном веб-магазине обычно можно пренебречь, второй — это как раз та самая availability, которую вы отказываетесь понимать. В том смысле, что пользователю из Китая будет совершенно безразлично, что он прямо сейчас не может заказать доставку в Нидерланды, ему важно смочь заказать доставку в своём же регионе.
Т.е. падение связи между серверами Европы и ЮВА имеет смысл обрабатывать специальным образом, а не делать недоступной всю систему. Основой этих рассуждений является понимание того, что заказы на доставку в Китай с клиентским IP в Европе — редкость, как и наоборот; поэтому их сбои меньше влияют на общую Availability.

В вашем пониманиии "общепринятой трактовки надёжности" подобным рассуждениям места нет:

при "географическом сегментировании" я хочу иметь доступ ко всем данным, даже если один дц недоступен

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

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

S>Вот мы сидим и долбим какую-то систему ежесекундными запросами. Из них часть завершается успешно, часть падает с таймаутом или 503. (простейший пример — ping -t).
S>Каким образом вы от лога результатов перейдёте к "минутам" и "продолжительности инцидентов"? Ну, чтобы вычислить availability?

Мне не нужно от лога к availability переходить, у меня есть мониторинг, в котором это все считается.

CK>>Еще раз. Ты это _неправильно_ понимаешь. В АР системе, работающей в нескольких ДЦ, при сбое одного ДЦ, все данные будут доступны. Нормальной практикой является периодическое отключение ДЦ, в рамках тестирования боевой инфраструктуры на resiliency, например.
S>

Что именно тебе кажется смешным? Доступность данных при недоступности одного ДЦ или отключение ДЦ для тестирования?

CK>>Для этого как раз пригодится САР.
S>Как именно? Ждём примера.

это было ответом на

SS>Т.е. падение связи между серверами Европы и ЮВА имеет смысл обрабатывать специальным образом, а не делать недоступной всю систему. Основой этих рассуждений является понимание того, что заказы на доставку в Китай с клиентским IP в Европе — редкость, как и наоборот; поэтому их сбои меньше влияют на общую Availability.

1. да, имеет смысл обрабатывать специальным образом
2. делать недоступной всю систему тоже делать не стоит
3. делать независимую систему на каждый регион, объясняя это какими-то своими домыслами — неправильно
4. если решишь подумать, как можно добиться 1. и 2. без 3., то тебе вероятно понадобится САР в твоих рассуждениях

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

CK>временной интервал (год, месяц, неделя) минус суммарная продолжительность всех инцидентов, приведших к недоступности сервиса, на этом интервале времени, будешь с этим спорить?
У вас оно вводится как что-то апостериорное, что не позволяет его вычислять из характеристик компонентов системы.
Ок, предположим, что вы имели ввиду мат. ожидание. Тогда оно пересчитывается в вышеупомянутые девятки однозначным образом, т.е. определения (почти) эквивалетны.

CK>С помощью CAP я могу понять, что у меня есть трэйдоф, я могу обеспечить целостность (linearizability) или доступность. С появлением САР, люди поняли, что пространство возможных решений шире, что привело к созданию алтернативных дизайнов (NoSQL), которые жертвуют линеаризуемостью, но имеют другие интересные свойства. Собственно на этом полезность и заканчивается.
С появлением САР, люди поняли, что пространство возможных решений уже и невозможно одновремено иметь абсолютный С, абсолютный А и абсолютный Р.
(Кто бы спорил. В реальном мире их и по отдельности иметь нельзя.)
С появлением САР (некоторые) люди подумали, что можно не париться с С, т.к. он все равно не достижим, когда хочется А и Р.

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

выделил ключевые моменты
A>

A>The Unhelpful CAP Theorem
A>CAP is sometimes presented as Consistency, Availability, Partition tolerance: pick 2
A>out of 3. Unfortunately, putting it this way is misleading [32] because network parti‐
A>tions are a kind of fault, so they aren’t something about which you have a choice: they
A>will happen whether you like it or not [38].
A>At times when the network is working correctly, a system can provide both consis‐
A>tency (linearizability) and total availability. When a network fault occurs, you have to
A>choose between either linearizability or total availability. Thus, a better way of phras‐
A>ing CAP would be either Consistent or Available when Partitioned [39]. A more relia‐
A>ble network needs to make this choice less often, but at some point the choice is
A>inevitable.
A>In discussions of CAP there are several contradictory definitions of the term availa‐
A>bility, and the formalization as a theorem [30] does not match its usual meaning [40].
A>Many so-called “highly available” (fault-tolerant) systems actually do not meet CAP’s
A>idiosyncratic definition of availability. All in all, there is a lot of misunderstanding
A>and confusion around CAP, and it does not help us understand systems better, so
A>CAP is best avoided.

то бишь определение не очень понятно сформулировано, приведен более корректный вариант
в дискуссиях люди несут чушь (ditto)
некоторые системы сложно классифицировать и не очень то нужно, поэтому в этом случае лучше обойтись без CAP

до этого там идет не менее интересный фрагмент, который ты решил не включать, там как раз про полезность

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

CK>>в общем-то, ты спросил как имзерять, я ответил — "Каким образом вы от лога результатов перейдёте к "минутам" и "продолжительности инцидентов"? Ну, чтобы вычислить availability?"
S>Вы же понимаете, что смысл ваших действий — это аппроксимировать % упавших клиентских запросов на основании данных о падении мониторящих запросов?

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

S>Клиента (и Product Manager) не интересуют показания вашего монитора. Если раунд-робин выбирает сервис, который отдаёт 500, каждый четвёртый раз, а агенту нужно хотя бы 2 500 "подряд", то ваша лампочка будет гореть зелёным, а с т.з. клиента availability будет равна 75%.

С чего ты взял что там round-robin DNS?
Ты не понимаешь как работает load balancing, не так ли?

S>Вы опять путаете network partition с device loss. "У меня" данные нигде пока что не хранятся; мы пока что обсуждаем только уровень требований к системе.

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

S>Я же Product Manager — я вам (архитектору) объясняю что нет, для меня отказ от консистентности гораздо хуже, чем отказ в обслуживании части запросов при network partition.
S>Что нагрузка устроена нетривиальным образом; поэтому когда мы выбираем между "терять 10% от всех запросов" и "терять 100% от 1% запросов" выбор однозначно в пользу последнего.

В случае такси как раз важнее availability. Если водитель завершает поездку, а она у него не завершается, я как клиент теряю деньги. В случае же РА системы, данные об окончании поездки запишутся в БД, даже в случае недоступности одного из ДЦ яндекса.
И консистентность там скорее всего достаточно поддерживать в рамках одной поездки, причем допустимо делать это пост фактум. Можно записать время/место начала поездки, точки маршрута и время/место окончания поездки отдельно для клиента и отдельно для водителя. Стоимость заранее расчитывается, биллинг отдельно работает и время задержки между окончанием позедки и списанием средств не критично.

S>Я привёл абстрактный иллюстративный пример. Ок, давайте рассмотрим Химки — сколько процентов заказов, сделанных из Химок хотят подачу машину в Химках, а сколько — в других районах?

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

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

выше ответил

S>Давайте с цитатами, что ли.

в соседней ветке ответил

CK>В случае такси как раз важнее availability.
Ваши же рассуждения ниже, показывают то, что важно и availability и consistency.

CK> Если водитель завершает поездку, а она у него не завершается, я как клиент теряю деньги. В случае же РА системы, данные об окончании поездки запишутся в БД, даже в случае недоступности одного из ДЦ яндекса.
CK>И консистентность там скорее всего достаточно поддерживать в рамках одной поездки, причем допустимо делать это пост фактум. Можно записать время/место начала поездки, точки маршрута и время/место окончания поездки отдельно для клиента и отдельно для водителя. Стоимость заранее расчитывается, биллинг отдельно работает и время задержки между окончанием позедки и списанием средств не критично.
Совершенно верно, и что же мы получаем? С точки зрения CAP — система не консистентна (AP), а с точки зрения бизнеса система и консистентна, и доступна. И водитель смог отчитаться о выполнении, и два такси никому не приехало и деньги аккуратно списались.
Ну и толку нам здесь от CAP?

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

C>С CA-системами всё понятно — при росте числа узлов вероятность отказа хотя бы одного из них растёт экспоненциально (просто сумма вероятностей).

[Зануда mode on]
Строго говоря, не может вероятность расти экспоненциально. Просто потому, что она единицей ограничена. И, естественно, там не сумма вероятностей, а (1 — (1-p)**N), где p — вероятность отказа одного узла.
[Зануда mode off]

Здравствуйте, 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 имеют хоть какое-то отношение к работе с разрывом связей?

Здравствуйте, 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 невозможна, а что возможно?

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

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

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

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

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

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

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

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

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

От:	Ikemefula	http://blogs.rsdn.org/ikemefula
Дата:	06.09.19 08:25
Оценка:	3 (1)

	От:	Cyberax
	Дата:	09.09.19 09:03
	Оценка:	7 (5)

От:	gandjustas	http://blog.gandjustas.ru/
Дата:	22.08.19 15:40
Оценка:	5 (2) +2 -1

От:	IB	http://rsdn.ru
Дата:	22.08.19 16:08
Оценка:	2 (2) +2

	От:	chaotic-kotik
	Дата:	03.09.19 20:54
	Оценка:	1 (1) +1

От:	Sinclair	https://github.com/evilguest/
Дата:	03.09.19 18:23
Оценка:	2 (1) +2

От:	Mamut	http://dmitriid.com
Дата:	23.08.19 09:31
Оценка:	+3

	От:	Mystic Artifact
	Дата:	16.08.19 09:26
	Оценка:	1 (1) +1

	От:	igor-booch
	Дата:	29.08.19 09:11
	Оценка:	1 (1)

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

	От:	Denis Ivlev
	Дата:	03.09.19 11:27
	Оценка:	2 (1)

От:	Artem Korneev	https://www.linkedin.com/in/artemkorneev/
Дата:	22.08.19 19:38
Оценка:

	От:	Слава
	Дата:	15.08.19 22:56
	Оценка:	-2

	От:	artelk
	Дата:	12.09.19 08:19
	Оценка:	+2