Здравствуйте, 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/
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[28]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, 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, которая полностью бесполезна для ответов на заданные вопросы.
Я правда недоумеваю, зачем бороться с ветряными мельницами, ну устроен мир вот так — везде компромисы. Обратного так никто из борящихся так и не показал
Re[22]: Теория инф-ии vs теория распределенных систем. 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 — в том, что "ломаемость" мира в модель добавили, а "починимость" — нет. Давайте предположим, что одиночный сегмент сети восстанавливается после сбоя за время TR. Вряд ли оно зависит от количества сегментов; выбрав таймаут операции большим, чем TR, мы получим консистентную и доступную систему, терпимую к разделению кластера.
В 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.
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 никаких компромиссов нет. За это мы её и не любим.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[23]: Теория инф-ии vs теория распределенных систем. 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 сегментов — например, продублировав их. ·>Только это всё никоим образом не противоречит теореме.
Это противоречит её практическому применению.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, 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" пространство архитектурных выборов снижается до очень небольшого.
Sapienti sat!
Re[24]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, Sinclair, Вы писали:
S>·>Я не прыгаю. Это просто такой яркий пример когда без P не обойтись никак, просто из-за физических свойств нашей вселенной. S>Совершенно верно, без P обойтись никак. А теорема Брюера делает вид, что существуют AC системы.
Вообще говоря, существуют и даже активно впариваются клиентам. Ярким представителем является Oracle RAC, где при правильной установке получается 3-кратное дублирование каналов связи и анальное самоогораживание узлов при первых признаках проблем. Что привело к паре очень громких публичных фэйлов, кстати.
Sapienti sat!
Re[30]: Теория инф-ии vs теория распределенных систем. 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 никаких компромиссов нет. За это мы её и не любим.
Это демагогия — выражение "все в мире компромисы" не верно, так как бескомпромисно.
Здравствуйте, 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>Это демагогия — выражение "все в мире компромисы" не верно, так как бескомпромисно.
Ну так это же ваше утверждение. Вы уже определитесь, за вы или против.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[31]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, Denis Ivlev, Вы писали:
DI>>>Я правда недоумеваю, зачем бороться с ветряными мельницами, ну устроен мир вот так — везде компромисы. Обратного так никто из борящихся так и не показал
... DI>Это демагогия — выражение "все в мире компромисы" не верно, так как бескомпромисно.
Вот так плюрализм, и всё в одной голове!
Re[24]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, 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?
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: Теория инф-ии vs теория распределенных систем. CAP
S>Если речь про failover clusters, из которых построена sharded — система, то ей наплевать на пропадание связи между компонентами. Как мы вроде бы выяснили.
Это в лучшем случае будет CA-система. "в каком отделении открывали счет туда и идите" — это клиентам на такую систему будет наплевать.
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Re[32]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, 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>Вы уже определитесь, за вы или против.
За или против демагогии? Против, зачем доводить до абсурда и играть словами?
Re[32]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, Ikemefula, Вы писали:
DI>>Это демагогия — выражение "все в мире компромисы" не верно, так как бескомпромисно.
I>Вот так плюрализм, и всё в одной голове!
Я так понимаю принять участие в дискуссии интеллект не позволяет, но высказаться очень хочется? На здоровье, но кормить тролятину не буду. Свободен.
Re[33]: Теория инф-ии vs теория распределенных систем. CAP
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 (почти всегда работает).
это такой лютый оверкилл для миграции шардов
Re[32]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, 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 может потребоваться ожидание консенсуса. Алгоритмы для этого есть.
какие алгоритмы ты имеешь ввиду?
Re[26]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, Sinclair, Вы писали:
CK>>гугли azure dns outage S>И? двухчасовой даунтайм? При этом он зааффектил вовсе не всю инфраструктуру DNS, а только её крошечный кусочек. Ок, давайте возьмём период в год — посчитайте, сколько получается девяток. А если мы скорректируем эту оценку с учётом того, что большинство DNS запросов в это время продолжали обслуживаться, то полученную Availability побить будет крайне сложно. S>Но я согласен с вами — DNS малоинтересный пример. Давайте обсуждать то, что вы предложили.
только проблема в том, что Asure прилег из-за этого, и ненадеждность не в том, что была даунтайм, а в том, что неверные данные оттуда удаляются очень не сразу, а пока это не произошло, у тебя ничего не работает
Re[25]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, Sinclair, Вы писали:
S>>·>Я не прыгаю. Это просто такой яркий пример когда без P не обойтись никак, просто из-за физических свойств нашей вселенной. S>>Совершенно верно, без P обойтись никак. А теорема Брюера делает вид, что существуют AC системы. C>Вообще говоря, существуют и даже активно впариваются клиентам. Ярким представителем является Oracle RAC, где при правильной установке получается 3-кратное дублирование каналов связи и анальное самоогораживание узлов при первых признаках проблем. Что привело к паре очень громких публичных фэйлов, кстати.
скорее к безусловному лидерству в фин секторе. RAC уже процентов 70 фин сектора вытеснив всю noSQL-щину. и в первую очередь потому как нужна настоящая консистеность и availability. а вот ФБ и твитер что-то сбоят кажду неделю уже. т.е. даже лайки и те посчитать не получается.
и пока не видно серьезных конкурентов. доморощенные поделки в стиле динамодб чудовфищно проигрывают обычному хадупу по throughput, при этом в плане консистентности ничего интересней чем то что есть уже у хадупов забесплатно нет. на hdfs писать можно на порядок быстрее.