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

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

Здравствуйте, 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)
Только это всё никоим образом не противоречит теореме.

Здравствуйте, 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 никаких компромиссов нет. За это мы её и не любим.

Здравствуйте, ·, Вы писали:
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>Это прекрасно, это именно то, чего я хочу. Но для такого разговора придётся отказаться от 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" пространство архитектурных выборов снижается до очень небольшого.

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

S>·>Я не прыгаю. Это просто такой яркий пример когда без P не обойтись никак, просто из-за физических свойств нашей вселенной.
S>Совершенно верно, без P обойтись никак. А теорема Брюера делает вид, что существуют AC системы.
Вообще говоря, существуют и даже активно впариваются клиентам. Ярким представителем является Oracle RAC, где при правильной установке получается 3-кратное дублирование каналов связи и анальное самоогораживание узлов при первых признаках проблем. Что привело к паре очень громких публичных фэйлов, кстати.

Здравствуйте, 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 никаких компромиссов нет. За это мы её и не любим.

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

Здравствуйте, 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>Это демагогия — выражение "все в мире компромисы" не верно, так как бескомпромисно.
Ну так это же ваше утверждение. Вы уже определитесь, за вы или против.

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

DI>>>Я правда недоумеваю, зачем бороться с ветряными мельницами, ну устроен мир вот так — везде компромисы. Обратного так никто из борящихся так и не показал
...
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>Вы уже определитесь, за вы или против.

За или против демагогии? Против, зачем доводить до абсурда и играть словами?

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

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

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

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

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