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

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

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

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


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


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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

Это почему?

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

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

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