Здравствуйте, Sharov, Вы писали:
S>Какой-нибудь ресурс посоветуете кроме вики, где на этом бы акцентировались? Ну и для DNS свой протокол, чай не REST.
Сходу не посоветую. Есть ощущение, что по ссылкам из DDIA надо искать, но пока я её даже саму до конца не дочитал

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

DI>>Вы снова что-то понаписали, но проигнорировали прямые вопросы, это уже даже не смело, а просто глупо — пытаться оставить последнее слово за собой.
IB>Я собственно начал ровно с ответа на поставленный вопрос.

Если начал, то почему не закончил? Одно бла-бла-бла

IB>Но если вам сложно

Какой ты душный, строчишь такие объемные тексты ни о чем, заболтать до смерти что-ли хочешь?

IB>Ладно, пойдем длинным путем.

Мы никуда не пойдем и будем оставаться в этой ветке в той теме, что здесь обсуждалась. Хочешь что-то обсудить еще — создай тему или выдели ветку.

DI>>У меня нет претензий к failover системам, не нужно фантазировать,
IB>

DI>>И как это горизонтально масштабируется?
DI>>Никак что-ли? А зачем оно тогда надо?

IB>А это кто писал?

Омг, давай ты не будешь тратить мое время, если для тебя фейловеринг и горизонтальная масштабируемость это что-то взаимоисключающее.

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

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

DI>>Начинали с обсуждения этой архитектуры: "Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер." Еще раз вопрос, как это может масштабироваться?
IB>На это уже ответили.
IB>Если не понятно, могу разжевать еще раз, мне не сложно ))

Да, напиши как это может горизонтально масштабироваться.

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

DI>>Я хз, ты читать не умеешь? Или с интеллектом что-то?
S>Коллега, вам так нестерпимо хочется в бан? Вы не стесняйтесь — пишите напрямую модераторам. Это быстрее и эффективнее.

Ну иди да напиши.

DI>>Прям в этом описании есть сценарий, когда кластер перестает быть доступным на запись.
S>Да, есть.

О, смотри, я тебя читать научил. Алилуя.

S>Но вы же сами зачем-то упомянули про то, что он в это время доступен на чтение.

Извини, я сразу все кейсы не разжевал, а сами вы думать не хотите. Вот еще один кейс: Упал арбитр, упал мастер, кластер все еще доступен для чтения, но данные которые мастер получил перед падением не успели отреплицироваться — теряем С.

S>Значит, вас не устраивает бинарная трактовка availability — с практической точки зрения, частичная availability лучше, чем никакая; а CAP с её черно/белой трактовкой не даёт никаких основ для рассуждения о частичной availabilty. За это мы её и не любим.

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

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

DI>>Что такое чистый шардинг?
S>Это когда мы просто пилим данные на части по заранее известному критерию

Я уже ору с рсдн экспертов, ты снова пробил дно. Любой шардинг — деление данных по какому-то признаку, обычно просто берут хеш от первичного ключа, и считают по нему номер сервера (тупо) или виртуального бакета.

S>а в требования consistenсy не входит ссылочная целостность.

А это ты что сочинил?

S>Простейший пример — энциклопедия, которую мы делим на шарды по префиксу ключа.
S>То, что в таком сценарии разделение кластера нам не грозит — очевидно, или нужно пояснять?

Конечно не очевидно, поясняй, я пока за попкорном схожу.

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


CK>>в общем, да, ты это утверждаешь
IB>Я утверждаю, что throughput адекватнее и практичнее CAP.

что значит адекватнее?

CK>>я попросил тебя объяснить, как знание пропускной способности системы поможет тебе понять, как система поведет себя в случае если упал ДЦ (ну или регион в AWS), это, если что, network partition

IB>Система должна продолжать выдавать адекватные ответы с заданной частотой, вне зависимости от того, что у нее случилось внутри.

ошибочный ответ может быть адекватным в каких-то случаях, например если требования к целостности данных высокие (финансовые данные) и мы, например, через 2PC коммитим данные в разные ДЦ, то отдать ошибку при network partition — вполне адекватный ответ, а отдать не ошибку и допустить рассогласованность — недопустимо

IB>Это вполне понятный критерий с числовой характеристикой, которым регулярно пользуются на практике при построении систем, в отличии от CAP.

throughput не замена а дополнение, это вообще про разное

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

DI>Я уже ору с рсдн экспертов, ты снова пробил дно. Любой шардинг — деление данных по какому-то признаку, обычно просто берут хеш от первичного ключа, и считают по нему номер сервера (тупо) или виртуального бакета.
Попробуйте перестать орать и начать разговаривать спокойно.

S>>а в требования consistenсy не входит ссылочная целостность.
DI>А это ты что сочинил?
Эмм, вы не знаете что такое "ссылочная целостность"?

S>>Простейший пример — энциклопедия, которую мы делим на шарды по префиксу ключа.
S>>То, что в таком сценарии разделение кластера нам не грозит — очевидно, или нужно пояснять?

DI>Конечно не очевидно, поясняй, я пока за попкорном схожу.
Ок, поясняю: поскольку ссылочная целостность нас не интересует, падение связи с любым из шардов нам ничем не грозит. Ну, вы там выше написали ваше понимание шардинга — вот в нём мы тупо по хешу первичного ключа однозначно получаем номер сервера. Запись и чтение по первичному ключу идут туда. Если сервер временно недоступен, мы просто ждём его возврата в строй. Под consistency мы здесь понимаем всего лишь то, что читаем то, что записали.
Если есть какой-то способ потерять consistency в этом сценарии — покажите.

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

S>>>·>Availability: Every request receives a (non-error) response – without the guarantee that it contains the most recent write
S>>>Очевидно, тем, что не учитывает Scalability вовсе никак, что противоречит вашей формуле в посте выше.
S>·>Scalability это аспект availability. Т.е. возможность системы оставаться available при growing amount of work путём adding resources.
S>И тем не менее, в ваших определениях это никак не связано. Availability в вашей формулировке всего лишь требует получать ответ на каждый запрос — при этом нет никаких временных рамок; это означает, что при росте нагрузки можно наращивать время ожидания результата безо всяких дополнительных телодвижений.
Не понял что за рамки имеешь в виду. Вообще-то, timeout error это тоже error в терминах Availability. Наращивать сколько конкретно? Хинт: O(∞) — оксюморон.

S>·>Зуб даёшь? 1млрд запросов даже в сетевой проводок даже супер-пупер сервера не влезут, поэтому запросы тупо потеряются и ты не сможешь дать ответ даже через 100500 миллиардов лет.
S>А с чего вы взяли, что мы собираемся запихивать этот миллиард запросов в один сетевой проводок?
S>У нас же не один клиент генерирует этот миллиард запросов, так? Ну вот у нас миллион клиентов делает по 1к RPS, которые приземляются на 100к прокси серверах, и каждый принимает всего лишь по 10к RPS.
S>Запросы лежат в очереди, и прокси выполняют их через тот самый 1 сервер. Никаких принципиальных проблем с CAP тут не возникает.
В очередях бесконечной длины? Круто чё. Если ты не просёк, то мы рассматриваем не обработку 1млрд запросов, посланных за секунду, а систему, способную обрабатывать 1млрд запросов в секунду.

У тебя какое-то странное представление об алгоритмах. Твои алгоритмы требуют бесконечного времени и бесконечной памяти. Круто, конечно, но не для нашей вселенной.

S>·>"Хранят"? В смысле RO-система? В этом случае CAP как-то не в тему. Ибо эта теорема рассматривает RW.
S>Почему RO? Вполне себе RW. Просто нам заранее известно, что ваш счёт лежит на сервере №110, а мой — на сервере №465. Поэтому когда у нас идёт команда пополнить мой счёт на 1000р, то она приземляется в мой сервер, а ваша — в ваш.
И пока какой-то из этих серверов лежит, система неконсистентна или недоступна. ЧТД.

S>·>Вот когда ты на этом миллионе серверов захочешь сделать какой-то алгоритм, например, "перевести деньги со счёта на счёт без овердрафта", то у тебе придётся делать выбор C либо A.
S>Я вас разочарую, но в CAP нет ничего про multi-node updates. Это раз.
Там есть о взаимоотношении R и W _одного_ регистра. Т.е. случаи "пишем в X, читаем Y" или "пишем в X, пишем в Y и никогда ничего не читаем" или "читаем X и читаем Y" — это не то что описывает теорема, да и на практике нечасто встречается.

S>Два — если бы мы реально делали систему с транзакциями типа "перевести деньги со счёта на счёт", то под availability мы бы не стали понимать "100% ответов", т.к. такой показатель недостижим даже безо всяких Partition просто в силу ненадёжности аппаратуры.
CAP об алгоритмах, а не об аппаратуре.

S>Нужно ли нам разрешить овердрафты иногда? На всякий случай напомню, что в реальных card processing systems овердрафты являются частью нормального функционирования
S>И реальный бизнес вполне может сказать "ну ок, овердрафты в пределах 1% от остатка на счетах не являются для нас проблемой".
Да, т.е. AP-система, объясняем бизнесу что C может нарушаться. И? К чему ты клонишь?

S>>>Конечно же удастся. Потому что результат зависит от того, что мы называем C, а что A. И тогда я буду иметь и C, и А одновременно даже в случае P.
S>·>Как можно нарушить математически доказанную теорему? Ну да, можно так сказать... просто нарушить предусловия теоремы или дать другое толкование терминам. И что?
S>И то, что формулировки C и A, выбранные в доказательстве этой великой теоремы, не имеют практической применимости. На практике, нас не интересует ни та A, которая там выбрана, ни C.
А теорему не интересует что вас это не интересует. Теорема — это теория, а не практика. Например, есть теорема о том, что алгоритм сортировки нельзя сделать быстрее чем O(n*log(n)). И тут приходят "практики" и "опровергают" теорему: "а у нас тут поразрядная сортировка", "а у нас тут много ядер", "а у нас тут такие данные".

S>>>Очень интересно. Ок, а для 1 миллиона RPS можно построить CA-систему? А для 1 тысячи? Ок, ну, хотя бы для 1 запроса в 10 секунд — можно ли построить CA — систему?
S>·>Можно, конечно, на нашем уровне развития техники, но не будет P (т.е. ровно один узел).
S>Вы что, полагаете, что 1 узел вам даст возможность получить ответы на 100% запросов? Прямо на все-все 100%? И питание у него не пропадает никогда, и железо не сыплется? Апдейты на него не ставят никогда, да?
Ещё раз. Алгоритмам питание не нужно.

S>>>Если да, то как? А если нет, то почему вы пишете "в таком сценарии" — что в этом сценарии такого особенного?
S>·>Я просто хотел сказать, что для 1млрд физически невозможно построить без P. Нет такого железа у нас.
S>И для 0.001 RPS тоже нет такого железа, чтобы получить C, A, и P.
И?

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

DI>>Конечно не очевидно, поясняй, я пока за попкорном схожу.
И мне захвати, плз. Sinclair оплачивает банкет.

S>Ок, поясняю: ... Если сервер временно недоступен, мы просто ждём его возврата в строй.
Иначе говоря — нам придётся, например, вводить таймаут, который может генерировать timeout _error_. Ибо бесконечно долго работающих алгоритмов не бывает по определению. Т.е. CP-система, Availability нет. Что сказать-то хотел?

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

DI>>Я уже ору с рсдн экспертов, ты снова пробил дно. Любой шардинг — деление данных по какому-то признаку, обычно просто берут хеш от первичного ключа, и считают по нему номер сервера (тупо) или виртуального бакета.
S>Попробуйте перестать орать и начать разговаривать спокойно.

Так тебе и ответили спокойно:

Любой шардинг — деление данных по какому-то признаку, обычно просто берут хеш от первичного ключа, и считают по нему номер сервера (тупо) или виртуального бакета.

S>>>а в требования consistenсy не входит ссылочная целостность.
DI>>А это ты что сочинил?
S>Эмм, вы не знаете что такое "ссылочная целостность"?

Я знаю, что такое ссылочная целостность, но не понимаю, что это значит в контексте выдуманного тобой "чистого шардинга".

S>>>Простейший пример — энциклопедия, которую мы делим на шарды по префиксу ключа.
S>>>То, что в таком сценарии разделение кластера нам не грозит — очевидно, или нужно пояснять?

DI>>Конечно не очевидно, поясняй, я пока за попкорном схожу.
S>Ок, поясняю: поскольку ссылочная целостность нас не интересует, падение связи с любым из шардов нам ничем не грозит. Ну, вы там выше написали ваше понимание шардинга — вот в нём мы тупо по хешу первичного ключа однозначно получаем номер сервера. Запись и чтение по первичному ключу идут туда. Если сервер временно недоступен, мы просто ждём его возврата в строй. Под consistency мы здесь понимаем всего лишь то, что читаем то, что записали.
S>Если есть какой-то способ потерять consistency в этом сценарии — покажите.

А, теперь понял, ты про то, что данные со всеми зависимостями находятся на одном шарде. Твой пример с энциклопедией здесь, кстати, не в тему, так как ты пойдешь по ссылкам из статьи и окажешься на другом шарде, ну или надо вообще всю энциклопедию держать на 1 шарде, что уже вырожденный случай. Вернемся к САР с которым ты как Дон Кихот борешься — в предложенном тобой "чистом шардинге" напрочь отсутствует буква А. Если побороться за А, то придется сделать репликацию и мы можем потерять С из-за разделения мастера и реплики.

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

CK>>В чем смысл обсуждать какой-то вырожденный случай?
S>Вырожденный случай — это CAP, в которой под availability понимается 100% возможность получить ответ от любого узла.

ты же понимаешь, что эта availability просто называется так, можно было назвать по другому, скажем, readiness, было бы меньше непонимания
было бы понятно, что есть availability в девятках, а есть readiness — просто свойство принимать/отдавать данные, даже если в сети произошел сбой

CK>>Если хочется обсуждать реальные системы, можно взять что-то реальное за основу (Google Chubby, DynamoDB, FAWN, Pnuts, ...) и посмотреть как там проявляются ограничения CAP.
S>Ок, давайте пообсуждаем. Хотя мне кажется, что вы путаете реальные системы с инструментами. Реальная система — это, к примеру, банковское приложение. У него, в отличие от инструмента, есть набор функциональных и нефункциональных требований.

у инфраструктуры (к коей относятся перечисленные системы) они тоже есть

CK>>Но это конечно сложнее, нежели тыкать оппонентов в DNS, который в общем-то даже не очень то и отказоустойчив.
S>По факту — весьма отказоустойчив. Настолько отказоустойчив, что прочие reliable services типа того же chubby легко полагаются на DNS как механизм резолвинга ссылок.

гугли azure dns outage

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

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

CK>>>В чем смысл обсуждать какой-то вырожденный случай?
S>>Вырожденный случай — это CAP, в которой под availability понимается 100% возможность получить ответ от любого узла.

CK>ты же понимаешь, что эта availability просто называется так, можно было назвать по другому, скажем, readiness, было бы меньше непонимания
CK>было бы понятно, что есть availability в девятках, а есть readiness — просто свойство принимать/отдавать данные, даже если в сети произошел сбой
Ты же понимаешь, что всем было бы насрать на readiness в этом случае? Или сразу бы спросили — как это соотносится с доступностью?
Потому что доступность выраженная в процентах это то что нужно людям, и то за что они готовы платить. А readiness — непонятное свойство алгоритма, в непонятной вычислительной модели, которое еще и не дает никаких гарантий.

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

G>Ты же понимаешь, что всем было бы насрать на readiness в этом случае? Или сразу бы спросили — как это соотносится с доступностью?
G>Потому что доступность выраженная в процентах это то что нужно людям, и то за что они готовы платить. А readiness — непонятное свойство алгоритма, в непонятной вычислительной модели, которое еще и не дает никаких гарантий.

людям нужна гео-репликация, сейчас даже сайты, торгующие одеждой хостятся в нескольких ДЦ
собственно, без непонятного свойства этого не добиться

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

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

CK>ошибочный ответ может быть адекватным в каких-то случаях, например если требования к целостности данных высокие (финансовые данные) и мы, например, через 2PC коммитим данные в разные ДЦ, то отдать ошибку при network partition — вполне адекватный ответ, а отдать не ошибку и допустить рассогласованность — недопустимо
Но тогда это уже не соответствие требованию throughput, так как ошибка означает, что запрос не обработан.
То есть требование пропускной способности 1B R/S, означает, что весь этот 1B должен успешно обработаться, а не абы как.

CK>throughput не замена а дополнение, это вообще про разное
Конечно про разное, CAP нельзя использовать в реальной жизни, а пропускную способность — можно.

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

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

G>>Ты же понимаешь, что всем было бы насрать на readiness в этом случае? Или сразу бы спросили — как это соотносится с доступностью?
G>>Потому что доступность выраженная в процентах это то что нужно людям, и то за что они готовы платить. А readiness — непонятное свойство алгоритма, в непонятной вычислительной модели, которое еще и не дает никаких гарантий.

CK>людям нужна гео-репликация, сейчас даже сайты, торгующие одеждой хостятся в нескольких ДЦ
Это какие?

CK>собственно, без непонятного свойства этого не добиться
Все равно не продашь, придется объяснять связь с настоящим availability.

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

DI>Если начал, то почему не закончил? Одно бла-бла-бла
Потому что вы не отвечаете на поставленный вопрос, одно бла-бла-бла =)

DI>Мы никуда не пойдем и будем оставаться в этой ветке в той теме, что здесь обсуждалась.
Странно читать такое от человека, который только и делает, что пытается избежать обсуждаемой здесь темы.
Как-то толсто вы сливаете, коллега, без огонька. )
И так, ответ-то будет или расходимся?

DI>Омг, давай ты не будешь тратить мое время,
Так не тратьте — признайтесь, что чушь спороли и разойдемся.
И не тратье заодно и мое, отпираясь от своих же слов.

DI>Глотку рвешь здесь ты, вместо того, чтобы как адекватный человек не разбирающийся в теме пойти и почитать хотя бы азы распределенных систем.
Как адекватный человек, я пытаюсь пояснить вам всю глубину ваших заблуждений. А вот посылать всех азы учить, когда сказать нечего — совсем не адекватно.

DI>>>Начинали с обсуждения этой архитектуры: "Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер." Еще раз вопрос, как это может масштабироваться?
IB>>На это уже ответили.
IB>>Если не понятно, могу разжевать еще раз, мне не сложно ))
DI>Да, напиши как это может горизонтально масштабироваться.
Вы так трепетно относитесь к своему времени, неужели не жалко его было тратить на фигурную резьбу по цитатам?
На этот вопрос вам повторно ответят те, кто отвечал в первый раз, если им свое время не жалко будет и вы вежливо попросите.
Я же отвечал на вопрос "зачем оно тогда надо?", повторить?

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

IB>>>Если не понятно, могу разжевать еще раз, мне не сложно ))
DI>>Да, напиши как это может горизонтально масштабироваться.
IB>Я же отвечал на вопрос "зачем оно тогда надо?", повторить?

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

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

CK>ты же понимаешь, что эта availability просто называется так, можно было назвать по другому, скажем, readiness, было бы меньше непонимания
CK>было бы понятно, что есть availability в девятках, а есть readiness — просто свойство принимать/отдавать данные, даже если в сети произошел сбой
Практическая полезность этого свойства равна нулю. Зачем про него теорема? Просто Брюер сказал красивую фразу; когда к ней стали приделывать математическое обоснование, то оказалось, что получается фуфло. В итоге для того, чтобы доказать CAP, пришлось ввести искусственное понятие availability, которое никому не нужно.

CK>у инфраструктуры (к коей относятся перечисленные системы) они тоже есть

CK>>>Но это конечно сложнее, нежели тыкать оппонентов в DNS, который в общем-то даже не очень то и отказоустойчив.
S>>По факту — весьма отказоустойчив. Настолько отказоустойчив, что прочие reliable services типа того же chubby легко полагаются на DNS как механизм резолвинга ссылок.

CK>гугли azure dns outage
И? двухчасовой даунтайм? При этом он зааффектил вовсе не всю инфраструктуру DNS, а только её крошечный кусочек. Ок, давайте возьмём период в год — посчитайте, сколько получается девяток. А если мы скорректируем эту оценку с учётом того, что большинство DNS запросов в это время продолжали обслуживаться, то полученную Availability побить будет крайне сложно.
Но я согласен с вами — DNS малоинтересный пример. Давайте обсуждать то, что вы предложили.

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

DI>Я знаю, что такое ссылочная целостность, но не понимаю, что это значит в контексте выдуманного тобой "чистого шардинга".
Это значит, что нам наплевать, если данные с одного шарда ссылаются на данные с другого шарда, а этих данных на другом шарде нет.

DI>А, теперь понял, ты про то, что данные со всеми зависимостями находятся на одном шарде. Твой пример с энциклопедией здесь, кстати, не в тему, так как ты пойдешь по ссылкам из статьи и окажешься на другом шарде, ну или надо вообще всю энциклопедию держать на 1 шарде, что уже вырожденный случай.
Как я уже сказал, по условиям задачи нас не волнует перспектива пойти по ссылке, которая никуда не ведёт.
DI> Вернемся к САР с которым ты как Дон Кихот борешься — в предложенном тобой "чистом шардинге" напрочь отсутствует буква А. Если побороться за А, то придется сделать репликацию и мы можем потерять С из-за разделения мастера и реплики.
Ну вот, теперь можно вернуться к разговору о failover cluster. Масштабирование мы уже получили, безо всяких угроз разделения кластера. Теперь заменим каждую ноду на failover cluster, и получим ту самую A.

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

S>>И тем не менее, в ваших определениях это никак не связано. Availability в вашей формулировке всего лишь требует получать ответ на каждый запрос — при этом нет никаких временных рамок; это означает, что при росте нагрузки можно наращивать время ожидания результата безо всяких дополнительных телодвижений.
·>Не понял что за рамки имеешь в виду. Вообще-то, timeout error это тоже error в терминах Availability. Наращивать сколько конкретно? Хинт: O(∞) — оксюморон.
Я имею в виду как раз величину таймаута. Я вижу, вы уже понимаете, что без таймаута говорить об availability никакого смысла нет.
И, что ещё лучше, вы готовы к конструктивному разговору: насколько именно придётся наращивать таймаут в зависимости от объёма данных.
Это прекрасно, это именно то, чего я хочу. Но для такого разговора придётся отказаться от CAP и перейти к чему-то более серъёзному, типа Service Reliability Engineering.
CAP вам в этом никак не поможет, т.к. она не оперирует ни привычными нам параметрами A, выраженными в %, ни таймаутами, ни MTTR, ни replication delay.

S>>Запросы лежат в очереди, и прокси выполняют их через тот самый 1 сервер. Никаких принципиальных проблем с CAP тут не возникает.
·>В очередях бесконечной длины? Круто чё. Если ты не просёк, то мы рассматриваем не обработку 1млрд запросов, посланных за секунду, а систему, способную обрабатывать 1млрд запросов в секунду.
Вы как-то произвольно прыгаете между математической абстракцией (миллиард RPS) и практической реализацией. Если вы хотите переводить разговор в практическую плоскость, то я вам отвечу, что и породить такое количество запросов будет затруднительно.

·>И пока какой-то из этих серверов лежит, система неконсистентна или недоступна. ЧТД.
Ну, а теперь заменим каждый сервер на failover cluster.

S>>·>Вот когда ты на этом миллионе серверов захочешь сделать какой-то алгоритм, например, "перевести деньги со счёта на счёт без овердрафта", то у тебе придётся делать выбор C либо A.
S>>Я вас разочарую, но в CAP нет ничего про multi-node updates. Это раз.
·>Там есть о взаимоотношении R и W _одного_ регистра. Т.е. случаи "пишем в X, читаем Y" или "пишем в X, пишем в Y и никогда ничего не читаем" или "читаем X и читаем Y" — это не то что описывает теорема, да и на практике нечасто встречается.
Ну так вы-то хотите "пишем X и Y", а это — вовсе не один регистр.

S>>Два — если бы мы реально делали систему с транзакциями типа "перевести деньги со счёта на счёт", то под availability мы бы не стали понимать "100% ответов", т.к. такой показатель недостижим даже безо всяких Partition просто в силу ненадёжности аппаратуры.
·> CAP об алгоритмах, а не об аппаратуре.

S>>Нужно ли нам разрешить овердрафты иногда? На всякий случай напомню, что в реальных card processing systems овердрафты являются частью нормального функционирования
S>>И реальный бизнес вполне может сказать "ну ок, овердрафты в пределах 1% от остатка на счетах не являются для нас проблемой".
·>Да, т.е. AP-система, объясняем бизнесу что C может нарушаться. И? К чему ты клонишь?

·>А теорему не интересует что вас это не интересует. Теорема — это теория, а не практика. Например, есть теорема о том, что алгоритм сортировки нельзя сделать быстрее чем O(n*log(n)). И тут приходят "практики" и "опровергают" теорему: "а у нас тут поразрядная сортировка", "а у нас тут много ядер", "а у нас тут такие данные".
Отличный пример, как раз в тему дискуссии. Я не очень хочу отвлекаться от CAP, поэтому ограничимся иллюстративными рассуждениями.
1. Вы подменяете утверждение "меньше чем за n*log(n) сравнений" утверждением "быстрее, чем за O(n*log(n))". Скорость — это время (количество тактов), она не равна количеству операций. Верно вы пишете — "а у нас много ядер". Формулы для нижней границы количества тактов в зависимости от количества параллельных компараторов и размера входных данных пока что получить не удалось (см. Кнут, III). Алгоритмы, сортирующие быстрее, чем n*logN, совершенно точно есть.
2. Вы игнорируете тот факт, что для большинства систем интересна не нижняя граница, а Nth Percentile. Грубо говоря, за какое время завершатся 99% сортировок, при заданном нами распределении входных данных. Верно вы пишете — "а у нас тут такие данные".
И там, где "математик" победно пишет "я доказал, что сортировать быстрее чем за O(n*log(n)) невозможно" и идёт обедать, "инженер" продолжает искать, и находит решение, которое почти всегда сортирует данные за log(n).

Меня интересует инженерный подход, т.к. я занимаюсь не теоремами, а разработкой продуктов. У продуктов есть потребительские характеристики. Меня не интересует строгое математическое доказательство того, что невозможно построить алгоритм, отличающий на фотографии букву О от цифры 0. Меня интересует разработка распознавалки, которая почти всегда угадывает верно.

·>Ещё раз. Алгоритмам питание не нужно.
Ну так алгоритмы и не ломаются. В математическом мире все ноды мгновенно достижимы. Недостижимость ноды — это математическая модель реального мира.
Проблема CAP — в том, что "ломаемость" мира в модель добавили, а "починимость" — нет. Давайте предположим, что одиночный сегмент сети восстанавливается после сбоя за время T_R. Вряд ли оно зависит от количества сегментов; выбрав таймаут операции большим, чем T_R, мы получим консистентную и доступную систему, терпимую к разделению кластера.
Если мы зададим ожидаемую частоту выхода сегментов из строя (MTBF), то для любого наперёд заданного показателя Availability мы сможем рассчитать потребную величину таймаута — с учётом того, что несколько сбоев могут наложиться друг на друга.
·>И?

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.

(https://queue.acm.org/detail.cfm?id=3096459)

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

S>Это значит, что нам наплевать, если данные с одного шарда ссылаются на данные с другого шарда, а этих данных на другом шарде нет.

Ок, начались поиски вырожденного случая, видимо пришло понимание, что в общем случае задача не решаема.

DI>> Вернемся к САР с которым ты как Дон Кихот борешься — в предложенном тобой "чистом шардинге" напрочь отсутствует буква А. Если побороться за А, то придется сделать репликацию и мы можем потерять С из-за разделения мастера и реплики.
S>Ну вот, теперь можно вернуться к разговору о failover cluster. Масштабирование мы уже получили, безо всяких угроз разделения кластера.

Мы получили только консистентность за счет потери доступности. Само масштабирование мы не получили.

Поясняю: у нас есть кластер из Н нод, мы разделили данные по ним по какому-то принципу, какое-то время все хорошо.

Сценарий 1. Система живет, мы подливаем новые данные, наступает момент когда на ноде заканчивается место, надо добавить еще несколько нод и перебалансировать данные. Как ты это решишь? (подсказка: я уже решение давал).

Сценарий 2. Система пользуется популярностью, пользователей становится много, в какой-то момент количество запросов превышает пропускную способность ноды.

Сценарий 3. Внезапно оказалось, что данные на одной ноде популярнее других (лента новостей Джастина Бибера) и количество запросов превысило пропускную способность ноды. Ок. Мы отселили Джастина Бибера на другую ноду (возможен сценарий 2 и кстати как ты организуешь переезд без даунтайма с сохранением консистентности?) и оказалось, что Джастин уже не популярен, а у молодежи новый кумир (молодежь оказалась ветренной и каждую неделю вкусы меняются).

S>Теперь заменим каждую ноду на failover cluster, и получим ту самую A.

Но ведь не получим, ведь нода все еще может стать недоступной, ну ок, допустим сама нода крайне живучая и никогда не отказывает, но что делать с каналом, через который она общается с внешним миром? А еще помним про сценарии 1, 2, 3.