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

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

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

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

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


·>Это в лучшем случае будет CA-система. "в каком отделении открывали счет туда и идите" — это клиентам на такую систему будет наплевать.
Не надо говорить за всех клиентов. В мире множество самых разнообразных сценариев и полезными могут быть системы с самыми причудливыми свойствами.
А то вы очень лихо скачите когда вам выгодно со сферической теории в вакууме, на реальный кейс и обратно.

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

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

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


А не напомнишь, о чем собственно спор? Что этот дизайн нам доказывает? И какими по твоему свойствами, опровергающими полезность САР, эта система обладает?

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

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

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

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

DI>>Не наплевать, не выяснили. Я понял твою идею про кластер из супернадежных нод, каждая нода имеет свой набор данных, поэтому не зависит от остальных. Есть одна мелочь — по какому-то признаку организовать шардирование и вот тут возникает маленькая проблемка — вот это знание должно где-то быть, иначе вся система становится бесполезной. Для этих целей делается роутер, пользователь идет в него, роутер говорит куда идти за данными. Ты вообще никак не сказал как с этим жить.
S>Ну вот, а говорите — книгу читали. Роутер строится на основе алгоритмов консенсуса.

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

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

Где? Не увидел.

S>Чем вас не устраивает Raft или модификации Paxos?

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

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

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

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

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

Тролятина, еды нет, соси лапу.

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

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

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

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

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

Тролятина, еды нет, соси лапу.

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

C>>Т.е. при необходимости буквы "C" пространство архитектурных выборов снижается до очень небольшого.
IB>Проблема в том, что С, которое в САР, не имеет ничего общего с С, которое нужно бизнесу. В итоге необходимость С есть, но и пространство выборов более чем достаточное, так как это вовсе не то С, которое в теореме.
Без разницы. Отказ от классического "C" сразу влечёт кардинальное изменение архитектуры.

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

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

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

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

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

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

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