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

MA>> Quis custodiet ipsos custodes?

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

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

Мне вообще ближе системы в которых чтение приводит к записи, и в них все эти пляски с бубнами в общем-то до фенечек.

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

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

S>·>В данном случае сценарий довольно простой: посылаем системе 1млрд запросов за одну секунду и ожидаем получить non-error ответ на каждый запрос. Построить такую available систему без scalability не выйдет, как минимум по технологическим причинам, или даже по физическим.
S>Конечно же выйдет. Просто последний запрос получит ответ через 1 миллиард лет.
Зуб даёшь? 1млрд запросов даже в сетевой проводок даже супер-пупер сервера не влезут, поэтому запросы тупо потеряются и ты не сможешь дать ответ даже через 100500 миллиардов лет.
CAP не даёт никаких физических цифр. Это теорема об алгоритмах в распределённых системах.
В качестве аналогии: O(1) сложность алгоритма вполне может означать 1 миллиард лет. И что?

S>·>Я не понимаю каким образом ты базируешь failover на scalability. Это тёплое на мягком. Масштабирование это именно про нагрузку:
S>·>Scalability is the property of a system to handle a growing amount of work by adding resources to the system.
S>Вы неправильно понимаете слова Ивана.
S>Предположим, у вас уже стоит вполне себе отмасштабированная система. Например, у нас стоит миллион серверов, которые хранят остатки денег на счетах клиентов. Тогда каждый из них обрабатывает всего лишь тысячу запросов в секунду.
S>Предположим также, что данные клиентов не дублируются вовсе — просто хеш номера счёта однозначно определяет номер сервера, у которого нужно спросить.
S>Как видим, со scalability тут нет никаких проблем — по мере роста количества клиентов мы просто будем добавлять новые сервера.

S>Проблема появится в тот момент, когда один из серверов выйдет из строя. Внезапно часть запросов не смогут быть обслужены — нарушение availability.
S>Failover Cluster позволяет решить эту маленькую проблемку — заменим каждый сервер на FOC из, скажем, трёх серверов. Вот вам и availability поверх scalability.
"Хранят"? В смысле RO-система? В этом случае CAP как-то не в тему. Ибо эта теорема рассматривает RW. Вот когда ты на этом миллионе серверов захочешь сделать какой-то алгоритм, например, "перевести деньги со счёта на счёт без овердрафта", то у тебе придётся делать выбор C либо A.

S>·>Эээ.. Ну да. Только какие сценарии ни бери, CAP нарушить не удастся.
S>Конечно же удастся. Потому что результат зависит от того, что мы называем C, а что A. И тогда я буду иметь и C, и А одновременно даже в случае P.
Как можно нарушить математически доказанную теорему? Ну да, можно так сказать... просто нарушить предусловия теоремы или дать другое толкование терминам. И что?

S>·>CAP теорема позволяет в такой ситуации сделать вывод — что невозможно построить CA-систему в таком сценарии, как бы тебе ни хотелось — только либо A, либо C.
S>Очень интересно. Ок, а для 1 миллиона RPS можно построить CA-систему? А для 1 тысячи? Ок, ну, хотя бы для 1 запроса в 10 секунд — можно ли построить CA — систему?
Можно, конечно, на нашем уровне развития техники, но не будет P (т.е. ровно один узел).

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

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

·>"Хранят"? В смысле RO-система? В этом случае CAP как-то не в тему. Ибо эта теорема рассматривает RW. Вот когда ты на этом миллионе серверов захочешь сделать какой-то алгоритм, например, "перевести деньги со счёта на счёт без овердрафта", то у тебе придётся делать выбор C либо A.

Тут нет выбора между C и A как такого. Такого рода операция абсолютно аналогична межбанковским переводам, или транзакциям ч/з платежные карты. Т.е. списываем/блокируем, задание в очередь, телепорт на узел с целевым счетом, пополнение. Возможен центральный "арбитр" или правила ролбэка. Между чем тут выбирать. Её можно обрабатывать хоть бесконечность, при чем ни один узел не перейдет в неведомо-неконсистентное состояние вне зависимости от ежемоментной доступности т.н. кластера будь он четвертован или нет.

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

S>Рекомендую взглянуть на архитектуру DNS с этой точки зрения — там вполне классически single-master репликация, при этом масштабирование совершенно сумасшедшее. И availability — на зависть многим. Consistency при этом тоже весьма неплоха — всё зависит от того, что именно мы назовём Consistency. Скажем, у нас есть заранее известный верхний предел времени, которое должно пройти после модификации, чтобы ни один запрос не вернул stale data.


Какой-нибудь ресурс посоветуете кроме вики, где на этом бы акцентировались? Ну и для DNS свой протокол, чай не REST.

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

CK>мы это не выяснили, это ты почему-то написал, что амазаон throughput за availability считает, в ответ на утверждение о том, что амазон сколько то там запросов в секунду умеет обрабатывать, что есть non sequuntur
Это не я написал, это сотрудник амазона написал, как доказательство доступности их системы.

CK>Совершенно согласен, дискуссии о САР действительно обычно содержать разные противоречящие определения availability, Клипман все правильно написал
О чем тогда спорим? Собственно и мой поинт ровно в том, что CAP косячная, так как не дает внятного определения терминам которыми оперирует.


CK>>>Ну дык, это можно сделать при упавшем регионе, если система построена как Dynamo, запросы будут возвращать не ошибку. Данные можно будет прочитать и записать. В CP системе (например HBase) так сделать будет нельзя.
IB>>То есть, вы согласны, что пропускная способность — тоже может являться критерием доступности?

CK>Как это может быть ответом на мой комментарий?
Так же как и ваш на мой комментарий.

CK>И нет, не согласен.
Ну, ваше право.

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

MA>·>"Хранят"? В смысле RO-система? В этом случае CAP как-то не в тему. Ибо эта теорема рассматривает RW. Вот когда ты на этом миллионе серверов захочешь сделать какой-то алгоритм, например, "перевести деньги со счёта на счёт без овердрафта", то у тебе придётся делать выбор C либо A.
MA> Тут нет выбора между C и A как такого.
Гы. Ты угадал все буквы, но не смог назвать слово.
Повторяюсь. Это теорема о свойствах алгоритмов в распределённых системах.

MA>Такого рода операция абсолютно аналогична межбанковским переводам, или транзакциям ч/з платежные карты.
Ок. Это наша распределённая система.

MA>Т.е. списываем/блокируем, задание в очередь, телепорт на узел с целевым счетом, пополнение.
Это AP-алгоритм.

MA>Возможен центральный "арбитр"
А это CP-алгоритм.

MA>или правила ролбэка.
Тоже AP-алгоритм, с Eventual Consistency.

MA>Между чем тут выбирать.
В этом и суть теоремы — выбирай, но не всё сразу.

MA>Её можно обрабатывать хоть бесконечность,
Про бесконечность ты немного загнул. Алгоритм не бывает бесконечным, по определению.

MA>при чем ни один узел не перейдет в неведомо-неконсистентное состояние вне зависимости от ежемоментной доступности т.н. кластера будь он четвертован или нет.
Угу. Ведь узел по определению косистентый. А CAP-теорема о том как эти узлы взаимодействуют.

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

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

DI>Я это не говорил, я говорил, что горизонтальное Scalability вытекает из Partition, никак по другому горизонтально масштабироваться не получится.
Ладно, пойдем длинным путем. Без Scalability Partition возможен или нет?

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

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

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

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

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

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

MA>>Такого рода операция абсолютно аналогична межбанковским переводам, или транзакциям ч/з платежные карты.
·>Ок. Это наша распределённая система.
MA>>Т.е. списываем/блокируем, задание в очередь, телепорт на узел с целевым счетом, пополнение.
·>Это AP-алгоритм.
MA>>Возможен центральный "арбитр"
·>А это CP-алгоритм.
MA>>или правила ролбэка.
·>Тоже AP-алгоритм, с Eventual Consistency.
MA>>Между чем тут выбирать.
·>В этом и суть теоремы — выбирай, но не всё сразу.
Это потому, что ты хочешь что бы, эта операция была как бы транзакция на обоих сторонах.
А эта операция — обещание чертенка за мзду (или по доброте) взять у тебя пакет с деньгами с обещанием его доставить адресату, или вернуть его обратно, в течении, скажем 7 дней. Довольно трудно сюда натягивать CAP, т.к. чертенок выполняет перемещения между узлами на реактивных голубях, и его проблема (P) вообще не колышет. Безусловно могут возникают иные проблемы. Но, то что ты называешь "Eventual Consistency" — это не применимо тут. Система консистентна всё время — это её нормальное состояние. Более того, между узлом 1 обслуживающем счет отправлителя и между узлом 2 обслуживающим счет получателя не существует консистентности, — они обслуживают разные сущности. К ним ни по отдельности, ни в месте не применимы эти понятия.

MA>>Её можно обрабатывать хоть бесконечность,
·>Про бесконечность ты немного загнул. Алгоритм не бывает бесконечным, по определению.
Очевидно, что пока задействованные части системы не доступны или разделены — без протокола (соглашения) о выполнении независимых ролбэков — оно зависнет на время разделения.

MA>>при чем ни один узел не перейдет в неведомо-неконсистентное состояние вне зависимости от ежемоментной доступности т.н. кластера будь он четвертован или нет.
·>Угу. Ведь узел по определению косистентый. А CAP-теорема о том как эти узлы взаимодействуют.
Именно. Только, в данном случае, мы не оперируем с узлами которые дублируют данные, этим узлам, кроме пересылки голубей ничего не нужно, что бы всегда быть CAP.

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

S>Рекомендую взглянуть на архитектуру DNS с этой точки зрения — там вполне классически single-master репликация, при этом масштабирование совершенно сумасшедшее. И availability — на зависть многим. Consistency при этом тоже весьма неплоха — всё зависит от того, что именно мы назовём Consistency. Скажем, у нас есть заранее известный верхний предел времени, которое должно пройти после модификации, чтобы ни один запрос не вернул stale data.

Если бы еще DNS записи часто обновлялись. Масштабировать что-то одно, только чтение или только запись несложно. В чем смысл обсуждать какой-то вырожденный случай? Если хочется обсуждать реальные системы, можно взять что-то реальное за основу (Google Chubby, DynamoDB, FAWN, Pnuts, ...) и посмотреть как там проявляются ограничения CAP. Но это конечно сложнее, нежели тыкать оппонентов в DNS, который в общем-то даже не очень то и отказоустойчив.

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

DI>Что такое чистый шардинг?

это такой шардинг, который еще не осквернили грязными деталями реализации, поэтому он живет в чистом мире идей, в голове автора термина

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

IB>Это не я написал, это сотрудник амазона написал, как доказательство доступности их системы.

я сдаюсь

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

Клмпман никогда не говорил такой ерунды. Твоя цитата про дискуссии о САР! В общем, я еще раз сдаюсь.

CK>>>Ну дык, это можно сделать при упавшем регионе, если система построена как Dynamo, запросы будут возвращать не ошибку. Данные можно будет прочитать и записать. В CP системе (например HBase) так сделать будет нельзя.
IB>>То есть, вы согласны, что пропускная способность — тоже может являться критерием доступности?
CK>>Как это может быть ответом на мой комментарий?
IB>Так же как и ваш на мой комментарий.

я не отстану, до этого было вот что

CK>>>>нет, не является, ведь пропускная способность ничего нам не говорит о том, как поведет себя система (я так понимаю DynamoDB) в случае, если упадет один из регионов, а вот CAP говорит, если система available — она продолжит обрабатывать запросы, если нет — будет недоступна для записи
IB>>>Ну как же — конечно говорит. Для того чтобы обработать эти запросы, надо отвечать не ошибкой, что бы там с системой внутри не происходило.
CK>>Ну дык, это можно сделать при упавшем регионе, если система построена как Dynamo, запросы будут возвращать не ошибку. Данные можно будет прочитать и записать. В CP системе (например HBase) так сделать будет нельзя.

ты утверждаешь что throughput определяет доступность системы, верно?

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

в общем, да, ты это утверждаешь

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

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

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

CK>я сдаюсь



CK>ты утверждаешь что throughput определяет доступность системы, верно?

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

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


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

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

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

MA>>>Между чем тут выбирать.
MA>·>В этом и суть теоремы — выбирай, но не всё сразу.
MA> Это потому, что ты хочешь что бы, эта операция была как бы транзакция на обоих сторонах.
MA> А эта операция — обещание чертенка за мзду (или по доброте) взять у тебя пакет с деньгами с обещанием его доставить адресату, или вернуть его обратно, в течении, скажем 7 дней. Довольно трудно сюда натягивать CAP, т.к. чертенок выполняет перемещения между узлами на реактивных голубях, и его проблема (P) вообще не колышет. MA>Безусловно могут возникают иные проблемы. Но, то что ты называешь "Eventual Consistency" — это не применимо тут. Система консистентна всё время — это её нормальное состояние. Более того, между узлом 1 обслуживающем счет отправлителя и между узлом 2 обслуживающим счет получателя не существует консистентности, — они обслуживают разные сущности. К ним ни по отдельности, ни в месте не применимы эти понятия.
Читай понятие Strong Consistency — именно то, что применяется в теореме. На пальцах — это возможность обеспечить одинаковое состояние между всеми узлами системы. Скажем, в классических субд можно например иметь как в psql txid — идентификатор состояния и он будет означать одно и то же на всех узлах системы. В простейшем случае, это будет CA-система (один сервер субд или 2PC). Если начать кластеризовать, то станет CP-системой, т.к. потребуется центральный узел для сериализации txid. Различные новомодные распределённые nosql это AP-системы и никакого txid соорудить не выйдет.

MA>>>Её можно обрабатывать хоть бесконечность,
MA>·>Про бесконечность ты немного загнул. Алгоритм не бывает бесконечным, по определению.
MA> Очевидно, что пока задействованные части системы не доступны или разделены — без протокола (соглашения) о выполнении независимых ролбэков — оно зависнет на время разделения.
"Зависнет" это и есть результат отсутствия A.

MA>>>при чем ни один узел не перейдет в неведомо-неконсистентное состояние вне зависимости от ежемоментной доступности т.н. кластера будь он четвертован или нет.
MA>·>Угу. Ведь узел по определению косистентый. А CAP-теорема о том как эти узлы взаимодействуют.
MA> Именно. Только, в данном случае, мы не оперируем с узлами которые дублируют данные, этим узлам, кроме пересылки голубей ничего не нужно, что бы всегда быть CAP.
Не понял что ты имеешь в виду. Откуда возьмётся консистентное состояние _системы_, а не узла в твоём описании? (если я правильно это описание понял, конечно)

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

> Не понял что ты имеешь в виду. Откуда возьмётся консистентное состояние _системы_, а не узла в твоём описании? (если я правильно это описание понял, конечно)

Узлы не хранят дублирующие данные. Sinclair предложил "суперкластер" (аля шардинг), из failover-кластеров (или кто там в ветке это предложил). Узлы этого суперкластера не нуждаются быть консистентными, т.к. их область ведения фактически не пересекается между собой.

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

Я влез сюда из-за счетов. Работа со счетами либо выполняется в ACID, либо, выполняется через машину состояний (внешнюю или внутреннюю). Всё остальное не работает, либо повторяет эти два подхода.

А если захотеть настоящую распределенную транзакцию, то... таких не бывает.

--

Я вот уже помню слабо, вроде когда-то писали, что gmail там держит пару резерных копий пользовательских данных, но доставляя как минимум одну копию в географически-выгодное место (уж не знаю насколько это правда), и эта копия обслуживает аккаунт. Являеется ли И применимо ли к gmail CAP? Я, как пользователь, фактически всегда обращаюсь к одному узлу, пишу в один узел и читаю из одного узла (ну вроде как), помимо меня с данными ещё работает почтовый сервер, с конкуренцией стремящейся к нулю. Как эта система, в практическом смысле, может быть не консистентной? (видимо вместо gmail можно поставить и что-нибудь другое — Тут я его только как пример. Суть, я надеюсь, понятна.)

--

Я не спорю, что могут быть более интересные задачи, требующие быть более "энергичным", но, положа руку на сердце, я в это не верю. (В том, смысле, что кластера это не только о серверах, но и о данных, пользователях, паттернах доступа и операциях. Если вам нужно 100 серверов для одной БД — то врядли вам нужны все данные сразу. А если все сразу данные не нужны, то тут и начинается партиционирование и дальнейшее изучение предметной области. А если все данные нужны сразу — то это уже проблема).

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

MA> Мне вообще ближе системы в которых чтение приводит к записи, и в них все эти пляски с бубнами в общем-то до фенечек.

Енто как, можно подробнее?

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

MA>> Мне вообще ближе системы в которых чтение приводит к записи, и в них все эти пляски с бубнами в общем-то до фенечек.
S>Енто как, можно подробнее?

Ну, например получение баланса карты — это в зависимости от пл. системы — регистрируемая транзакция.

Ну, а так — банальный обязательный аудит. Конечно, его можно и в сторонке, но это зависит от требований.

Мне ближе — это... привычнее.
Безусловно, если можно ограничиться только чтением, то так и надо. А ограничиться им можно.

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

CK>Если бы еще DNS записи часто обновлялись.
Ага, я вижу, что постепенно наступает понимание того, что требования зависят от задачи.

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

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

Здравствуйте, Denis Ivlev, Вы писали:
DI>Я хз, ты читать не умеешь? Или с интеллектом что-то?
Коллега, вам так нестерпимо хочется в бан? Вы не стесняйтесь — пишите напрямую модераторам. Это быстрее и эффективнее.
DI>Прям в этом описании есть сценарий, когда кластер перестает быть доступным на запись.
Да, есть. Но вы же сами зачем-то упомянули про то, что он в это время доступен на чтение. Значит, вас не устраивает бинарная трактовка availability — с практической точки зрения, частичная availability лучше, чем никакая; а CAP с её черно/белой трактовкой не даёт никаких основ для рассуждения о частичной availabilty. За это мы её и не любим.

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

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

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

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

·>"Хранят"? В смысле RO-система? В этом случае CAP как-то не в тему. Ибо эта теорема рассматривает RW.
Почему RO? Вполне себе RW. Просто нам заранее известно, что ваш счёт лежит на сервере №110, а мой — на сервере №465. Поэтому когда у нас идёт команда пополнить мой счёт на 1000р, то она приземляется в мой сервер, а ваша — в ваш.
·>Вот когда ты на этом миллионе серверов захочешь сделать какой-то алгоритм, например, "перевести деньги со счёта на счёт без овердрафта", то у тебе придётся делать выбор C либо A.
Я вас разочарую, но в CAP нет ничего про multi-node updates. Это раз.
Два — если бы мы реально делали систему с транзакциями типа "перевести деньги со счёта на счёт", то под availability мы бы не стали понимать "100% ответов", т.к. такой показатель недостижим даже безо всяких Partition просто в силу ненадёжности аппаратуры. Мы бы с вами имели требования к Availability вроде 99.9%, при чём под ней бы понималось не просто "успешное завершение запроса", а что 99.9% запросов укладываются в 30 секунд.
И тут внезапно CAP теряет всякую полезность — потому что из неё непонятно, достаточно ли такого ограничения availability, чтобы получить consistency, или нет?
Нужно ли нам разрешить овердрафты иногда? На всякий случай напомню, что в реальных card processing systems овердрафты являются частью нормального функционирования
И реальный бизнес вполне может сказать "ну ок, овердрафты в пределах 1% от остатка на счетах не являются для нас проблемой".

S>>Конечно же удастся. Потому что результат зависит от того, что мы называем C, а что A. И тогда я буду иметь и C, и А одновременно даже в случае P.
·>Как можно нарушить математически доказанную теорему? Ну да, можно так сказать... просто нарушить предусловия теоремы или дать другое толкование терминам. И что?
И то, что формулировки C и A, выбранные в доказательстве этой великой теоремы, не имеют практической применимости. На практике, нас не интересует ни та A, которая там выбрана, ни C.

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

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