Здравствуйте, Cyberax, Вы писали:
C>Т.е. при необходимости буквы "C" пространство архитектурных выборов снижается до очень небольшого.
Проблема в том, что С, которое в САР, не имеет ничего общего с С, которое нужно бизнесу. В итоге необходимость С есть, но и пространство выборов более чем достаточное, так как это вовсе не то С, которое в теореме.
Мы уже победили, просто это еще не так заметно...
Re[21]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, Denis Ivlev, Вы писали:
DI>Что говоришь? Я тебе в штаны насрал? Лол, отдыхай, болезный. Еды не будет, гуляй, тролятина.
Так бездарно слился... А как дышал, как дышал!
Мы уже победили, просто это еще не так заметно...
Re[33]: Теория инф-ии vs теория распределенных систем. CAP
·>Это в лучшем случае будет CA-система. "в каком отделении открывали счет туда и идите" — это клиентам на такую систему будет наплевать.
Не надо говорить за всех клиентов. В мире множество самых разнообразных сценариев и полезными могут быть системы с самыми причудливыми свойствами.
А то вы очень лихо скачите когда вам выгодно со сферической теории в вакууме, на реальный кейс и обратно.
Мы уже победили, просто это еще не так заметно...
Re[25]: Теория инф-ии vs теория распределенных систем. 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 (два) провода, воткнутые в две сетевые карточки. Сможете сами рассчитать вероятность выхода из строя одновременно обеих, если вероятность выхода из строя одной известна?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, 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?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[27]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, chaotic-kotik, Вы писали:
CK>только проблема в том, что Asure прилег из-за этого, и ненадеждность не в том, что была даунтайм, а в том, что неверные данные оттуда удаляются очень не сразу, а пока это не произошло, у тебя ничего не работает
Бррр. Какие неверные данные?
В последний раз я такую проблему наблюдал в 1999 в Java, где у негативных DNS-респонсов был бесконечный TTL.
Неужто с тех пор кто-то ещё раз наступил на те же грабли?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[33]: Теория инф-ии vs теория распределенных систем. CAP
CK>а как достигается отказоустойчивость внутри failover cluster? я правильно понимаю, что там есть мастер и он синхронно записывает в реплики каждое обновление и потом возвращает клиенту ответ, о том что операция прошла, или не прошла? ну и в случае падения мастера, выбирается новый мастер?
Да, как я понимаю — инменно так. Но если честно, то в деталях конкретно этой реализации я ни разу не разбирался.
CK>"перевозим" это как? кто координирует?
Там ниже пошаговый алгоритм. Координировать может сторонний сервис watchdog; поскольку ему не нужно работать в реальном времени, то availability не проблема.
Можно принимать решение локально — нода, которая предсказывает перегрузку, начинает суетиться.
CK>кто переключает?
Сервис координации. Тут же важно не "кто переключает", а "как убедится, что все ноды трактуют роутинг одинаково".
S>>На шагах 2 и 3 может потребоваться ожидание консенсуса. Алгоритмы для этого есть.
CK>какие алгоритмы ты имеешь ввиду?
Коллега Ivlev уже прокомментировал -Paxos и его потомки, Raft.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[34]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, Sinclair, Вы писали:
CK>>какие алгоритмы ты имеешь ввиду? S>Коллега Ivlev уже прокомментировал -Paxos и его потомки, Raft.
А не напомнишь, о чем собственно спор? Что этот дизайн нам доказывает? И какими по твоему свойствами, опровергающими полезность САР, эта система обладает?
Re[22]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, Sinclair, Вы писали:
DI>>Не наплевать, не выяснили. Я понял твою идею про кластер из супернадежных нод, каждая нода имеет свой набор данных, поэтому не зависит от остальных. Есть одна мелочь — по какому-то признаку организовать шардирование и вот тут возникает маленькая проблемка — вот это знание должно где-то быть, иначе вся система становится бесполезной. Для этих целей делается роутер, пользователь идет в него, роутер говорит куда идти за данными. Ты вообще никак не сказал как с этим жить. S>Ну вот, а говорите — книгу читали. Роутер строится на основе алгоритмов консенсуса.
Во-первых, про роутер ты в своей архитектуре ты ничего не говорил, пока я не указал, что он нужен. Во-вторых, ссылку то дай, а то пока твое слово против моего и не я должен опровергать, что в книге нет, а ты доказывать. В-третьих, дай-то уж нормальное описание предлагаемой тобой архитектуры, а то пока ты только что-то туманное вбросил.
DI>>И можно продолжать дальше, но давай хотя-бы с этими сценариями разберемся. S>Ниже по тексту.
Где? Не увидел.
S>Чем вас не устраивает Raft или модификации Paxos?
Подожди, давай ты сначала покажешь масштабируемую архитектуру обеспечивающую доступность и консистентность. Пока почему-то ты просто скипаешь мои аргументы.
Re[23]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, Denis Ivlev, Вы писали:
DI>Соси лапу, тролятина, не подаю.
Как говорят зарубежные коллеги — go fuck yourself. Только не кипятись, сделай это спокойно и с расстановкой, чтобы в другой раз так публично не обделаться. =)
Мы уже победили, просто это еще не так заметно...
Re[24]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, IB, Вы писали:
DI>>Соси лапу, тролятина, не подаю. IB>Как говорят зарубежные коллеги — go fuck yourself. Только не кипятись, сделай это спокойно и с расстановкой, чтобы в другой раз так публично не обделаться. =)
Тролятина, еды нет, соси лапу.
Re[25]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, IB, Вы писали:
IB>Здравствуйте, Denis Ivlev, Вы писали:
DI>>Тролятина, еды нет, соси лапу. IB>Да вы еще уныло однообразны — полная печаль...
Тролятина, еды нет, соси лапу.
Re[24]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, IB, Вы писали:
C>>Т.е. при необходимости буквы "C" пространство архитектурных выборов снижается до очень небольшого. IB>Проблема в том, что С, которое в САР, не имеет ничего общего с С, которое нужно бизнесу. В итоге необходимость С есть, но и пространство выборов более чем достаточное, так как это вовсе не то С, которое в теореме.
Без разницы. Отказ от классического "C" сразу влечёт кардинальное изменение архитектуры.
Sapienti sat!
Re[26]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, Gt_, Вы писали:
C>>Вообще говоря, существуют и даже активно впариваются клиентам. Ярким представителем является Oracle RAC, где при правильной установке получается 3-кратное дублирование каналов связи и анальное самоогораживание узлов при первых признаках проблем. Что привело к паре очень громких публичных фэйлов, кстати. Gt_>скорее к безусловному лидерству в фин секторе. RAC уже процентов 70 фин сектора вытеснив всю noSQL-щину.
Кто куда перешёл? Классический процессинг в нынешней технологии можно обработать в масштабах всей страны на одной персоналке. Там вообще ничего нетривиального по меркам современных технологий нет, так что я не удивляюсь, что впариватели из Оракала его успешно пихают.
А вот в инвестиционном банкинге или финтехе — никакими RAC и не пахнет.
Gt_>и в первую очередь потому как нужна настоящая консистеность и availability. а вот ФБ и твитер что-то сбоят кажду неделю уже. т.е. даже лайки и те посчитать не получается.
Я не пользуюсь обоими, но вот как раз RAC ответственен за то, что Амазон полностью изжил Oracle и РСУБД из критических систем.
Gt_>и пока не видно серьезных конкурентов. доморощенные поделки в стиле динамодб чудовфищно проигрывают обычному хадупу по throughput, при этом в плане консистентности ничего интересней чем то что есть уже у хадупов забесплатно нет. на hdfs писать можно на порядок быстрее.
Хадуп занимается совсем другим.
Ну и как насчёт миллиарда запросов в секунду на DDB? Это "проигрывают обычному хадупу"?
Sapienti sat!
Re[27]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, Denis Ivlev, Вы писали:
DI>Тролятина, еды нет, соси лапу.
У тебя уже несколько суток лидер лежит и твой хваленый Raft видимо нихера не работает.
Здравствуйте, Cyberax, Вы писали:
C>Без разницы. Отказ от классического "C" сразу влечёт кардинальное изменение архитектуры.
Да мы-то о другом, к классическому С претензий нет. Проблема в том С, которое в CAP — оно ни разу не классическое.
Мы уже победили, просто это еще не так заметно...
Re[24]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, IB, Вы писали:
C>>Т.е. при необходимости буквы "C" пространство архитектурных выборов снижается до очень небольшого. IB>Проблема в том, что С, которое в САР, не имеет ничего общего с С, которое нужно бизнесу. В итоге необходимость С есть, но и пространство выборов более чем достаточное, так как это вовсе не то С, которое в теореме.
Уточню. "C" или есть, или его нет. Это как беременность.
Если "C" нет, то есть разные варианты "eventual consistency". И да, eventual consistency вполне удовлетворяет большинство компаний.
Sapienti sat!
Re[26]: Теория инф-ии vs теория распределенных систем. CAP
Здравствуйте, IB, Вы писали:
C>>Без разницы. Отказ от классического "C" сразу влечёт кардинальное изменение архитектуры. IB>Да мы-то о другом, к классическому С претензий нет. Проблема в том С, которое в CAP — оно ни разу не классическое.
То есть? "C" там вполне классическое — гарантия того, что события будут одинаково упорядочены для разных наблюдателей (как следствие "every read receives the most recent write").