DI>Еще раз. У тебя 300К запросов в секунду, а 1 сервер не вывозит больше 50К.

Если наугад ставить выдуманные из головы ограничения, то ничто и никогда не работает.

Я тоже так умею: прекрасный мастерлесс кластер не выдерживает больше 50к запросов в секунду, а пришло 300к запросов. Ну и нахрена теперь нужен мастерлесс кластер?

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

M>Если наугад из головы ограничения

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

M>Я тоже так умею: прекрасный мастерлесс кластер не выдерживает больше 50к запросов в секунду, а пришло 300к запросов. Ну и нахрена теперь нужен мастерлесс кластер?

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

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

DI>Это какое-то лукавство, что значит буква P? Partition tolerance. А откуда оно взялось, ведь взять обсуждаемую архитектуру: все запросы идут в одну ноду, нода синхронно реплицируется (C), если мастер падает, то мастером становится реплика (А) и все запросы теперь идут через нее. Где тут Р? И откуда Р появилась? Ну видимо оттуда, что все запросы в одну ноду стали узким местом и пришлось пустить запросы по разным нодам. Утверждать что это не так — смело, но глупо.

Самое смешное, что как раз так и есть. Весь CAP — он не потому, что кто-то "стал узким местом". А потому, что в случае P у нас кластер распался на два сегмента. И каждый из них думает, что он-то и есть единственный рабочий.
И в каждом из них появляется свой мастер (это если A), либо не появляется (и тогда С). С чем из этого вы хотите поспорить?

Здравствуйте, ·, Вы писали:
·>Нет такой машины, способной обработать любое число запросов. Поэтому в какой-то очень скорый момент времени твоя масштабилка через один мастер просто кончится и придётся добавлять новые узлы в систему, вместо одного мастера потребуется два и здравствуй CAP.
Нет. Здравствуй CAP появляется только при борьбе за Availability.
Без неё я могу запросто распилить систему по горизонтали — пусть Москву обслуживает Московский сервер, а СПБ — Питерский. Делов-то. А если клиенту из Москвы нужны данные про Питер, но связь лежит, то нарушается не S, а A.

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

DI>- И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?
Оно надо для того, чтобы в случае сбоя одного из узлов приложение продолжало работать. Ваш К.О.
Иначе вы из компонентов с Availability в две девятки никак не получите пять девяток.

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

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

S>Самое смешное, что как раз так и есть. Весь CAP — он не потому, что кто-то "стал узким местом". А потому, что в случае P у нас кластер распался на два сегмента.

2 + 2 = 4

Что сказать-то хотел?

S>И каждый из них думает, что он-то и есть единственный рабочий.

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

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

Чего? С чем я должен спорить-то?

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

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

·>В данном случае сценарий довольно простой: посылаем системе 1млрд запросов за одну секунду и ожидаем получить non-error ответ на каждый запрос. Построить такую available систему без scalability не выйдет, как минимум по технологическим причинам, или даже по физическим.
Конечно же выйдет. Просто последний запрос получит ответ через 1 миллиард лет. А чего вы хотели — интернет не гарантирует ни ширину полосы, ни лаг доставки.

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

Проблема появится в тот момент, когда один из серверов выйдет из строя. Внезапно часть запросов не смогут быть обслужены — нарушение availability.
Failover Cluster позволяет решить эту маленькую проблемку — заменим каждый сервер на FOC из, скажем, трёх серверов. Вот вам и availability поверх scalability.

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

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

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

DI>>- И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?
S>Оно надо для того, чтобы в случае сбоя одного из узлов приложение продолжало работать. Ваш К.О.

Капитан у тебя сломался, А достигается и по другому.

S>Иначе вы из компонентов с Availability в две девятки никак не получите пять девяток.

Ты мне кажется не понимаешь о чем говоришь.

S>Вопросы масштабирования решаются по-другому. Как правило — в зависимости от конкретной задачи.

О, еще один эксперт. Ну расскажи как вот это:

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

Может горизонтально масштабироваться.

S>Рекомендую взглянуть на архитектуру DNS с этой точки зрения — там вполне классически single-master репликация, при этом масштабирование совершенно сумасшедшее.

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

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

Quis custodiet ipsos custodes?

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

S>Здравствуйте, ·, Вы писали:
S>·>Нет такой машины, способной обработать любое число запросов. Поэтому в какой-то очень скорый момент времени твоя масштабилка через один мастер просто кончится и придётся добавлять новые узлы в систему, вместо одного мастера потребуется два и здравствуй CAP.
S>Нет. Здравствуй CAP появляется только при борьбе за Availability.
Или в борьбе за Consistency.

S>Без неё я могу запросто распилить систему по горизонтали — пусть Москву обслуживает Московский сервер, а СПБ — Питерский. Делов-то.
Осталось определить какие бизнес-требования у московских клиентов читать-менять данные Питера. Кстати, если московские и питерские данные вообще не пересекаются, то у тебя нет никакого P, это две отдельные системы и можно иметь вообще C+A.

S>А если клиенту из Москвы нужны данные про Питер, но связь лежит, то нарушается не S, а A.
А можно сделать так, чтобы Московский имел копию данных Питера и кешировал у себя модификации на случай пропадания связи. Тогда A нарушаться не будет, зато будет нарушаться C.

ЗЫ Что здесь значит "S" я не понял.

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

DI>Не совсем так. Например, лидера назначает внешний арбитр, а сами ноды решение об этом принимать не могут.
Отлично. Что делать, если отпал арбитр?

DI>Чего? С чем я должен спорить-то?
С тем, что CAP никакого отношения к Scalability не имеет.

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

DI>Капитан у тебя сломался, А достигается и по другому.
Расскажите.

S>>Иначе вы из компонентов с Availability в две девятки никак не получите пять девяток.

DI>Ты мне кажется не понимаешь о чем говоришь.
А мне кажется наоборот.

DI>

DI>Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.

DI>Может горизонтально масштабироваться.
Я тут по соседству написал — поставите сотню таких кластеров. вот вам и масштаб. Вы же задачу не привели

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

DI>>Не совсем так. Например, лидера назначает внешний арбитр, а сами ноды решение об этом принимать не могут.

MA> Quis custodiet ipsos custodes?

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

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

S>>Нет. Здравствуй CAP появляется только при борьбе за Availability.
·>Или в борьбе за Consistency.
Нет. Consistency проще лёгкого обеспечить безо всякого CAP. На одном узле.

S>>Без неё я могу запросто распилить систему по горизонтали — пусть Москву обслуживает Московский сервер, а СПБ — Питерский. Делов-то.
·>Осталось определить какие бизнес-требования у московских клиентов читать-менять данные Питера. Кстати, если московские и питерские данные вообще не пересекаются, то у тебя нет никакого P, это две отдельные системы и можно иметь вообще C+A.
Ну это нам тогда повезло. В рамках задачи у нас нет возможности сегментировать клиентов — каждый запрашивает любые данные. Мы просто умеем их роутить куда нужно (см. тж. "шардинг").

·>А можно сделать так, чтобы Московский имел копию данных Питера и кешировал у себя модификации на случай пропадания связи. Тогда A нарушаться не будет, зато будет нарушаться C.
Ну вот о том и речь, что масштабирование прекрасно достижимо безо всяких CAP ограничений. И только когда мы хотим получить A, то внезапно начинает действовать CAP и негативно влиять на C.
И опять — проблема ровно в том, что без количественных характеристик разговор бесполезен. Есть много разных определений C, кроме самой жёстко-хардкорного. И они вполне применимы на практике; и система, неконсистентная с т.з. CAP вполне консистентна с точки зрения бизнеса. И определений A тоже можно ввести много разных, а не просто обязанность любого узла быть мгновенно достижимым в любой момент времени. И тоже окажется, что недоступная с т.з. CAP система вполне себе доступна с точки зрения бизнеса. И выбор — вовсе не между C и A, а между разными степенями С и А, с учётом ожидаемой частоты и длительности P.
·>ЗЫ Что здесь значит "S" я не понял.
Scalability.

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

DI>>Не совсем так. Например, лидера назначает внешний арбитр, а сами ноды решение об этом принимать не могут.
S>Отлично. Что делать, если отпал арбитр?

Ответил рядом. TLDR — если хочешь серебрянную пулю, то ее нет.

DI>>Чего? С чем я должен спорить-то?
S>С тем, что CAP никакого отношения к Scalability не имеет.

Конечно, там таких слов нет, вот только сразу как начинаешь горизонтально масштабироваться немедленно возникает угроза разделения кластера.

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

DI>Конечно, там таких слов нет, вот только сразу как начинаешь горизонтально масштабироваться немедленно возникает угроза разделения кластера.
Смотря как масштабироваться. Чистый шардинг создаёт нулевую угрозу разделения кластера.

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

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

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

DI>>Капитан у тебя сломался, А достигается и по другому.
S>Расскажите.

Только сначала отучаемся от резьбы по цитатам.

— В Windows технология failover clustering работает вообще по-другому, через выбор мастера. Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.
— И как это горизонтально масштабируется? Никак что-ли? А зачем оно тогда надо?
— Оно надо для того, чтобы в случае сбоя одного из узлов приложение продолжало работать. Ваш К.О.

Совсем не обязательно для сохранения доступности пускать все запросы через одну ноду, а так да, доступность достигается избыточностью — несколько дц, в каждом копия данных.

S>>>Иначе вы из компонентов с Availability в две девятки никак не получите пять девяток.

DI>>Ты мне кажется не понимаешь о чем говоришь.
S>А мне кажется наоборот.

Тебе кажется, а я уже знаю (начитался твоих пассажей) — здесь есть существенное отличие.

DI>>

DI>>Все запросы физически идут в одну ноду, а если она падает, то выбирается новый мастер.

DI>>Может горизонтально масштабироваться.
S>Я тут по соседству написал — поставите сотню таких кластеров. вот вам и масштаб. Вы же задачу не привели

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

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

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

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

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

DI>>Конечно, там таких слов нет, вот только сразу как начинаешь горизонтально масштабироваться немедленно возникает угроза разделения кластера.
S>Смотря как масштабироваться. Чистый шардинг создаёт нулевую угрозу разделения кластера.

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