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

C>То есть? "C" там вполне классическое — гарантия того, что события будут одинаково упорядочены для разных наблюдателей (как следствие "every read receives the most recent write").
Не для разных наблюдателей и не имеет это ничего общего с классикой. Конкретно для CAP ввели специальный термин "atomic consistency", который потом сократили до просто consistency, для простоты. И пришлось очень долго объяснять, что этот термин не имеет ничего общего ни с atomicity ни с consistency, в общепринятом, классическом понимании этих терминов. А вводить специальный термин пришлось, потому что иначе красивой теоремы не получилось бы.

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

C>Уточню. "C" или есть, или его нет. Это как беременность.
Это смотря как это С определить. В одном определении его нет, а в другом — есть.

C>Если "C" нет, то есть разные варианты "eventual consistency". И да, eventual consistency вполне удовлетворяет большинство компаний.
Ровно потому, что определение С подбиралось так, чтобы получить красивую теорему, а не решить практическую задачу.

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

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

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

студент детектед. финсектор и банки это не только лишь процессинг

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

на переферии может быть, в европе exadata съела все и вся.

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

совсем другим занимается олтп в фин секторе, откуда и вытеснилди RAC весь этот изредко консистентный NoSQL

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

а кому в 21 интересны запрсы ? на дворе 21 век, кругом реалтайм стриминг. кафка + спарк + hdfs давно стандарт в отрасли.
что такое ddb ?
кстати, 10 лет назад RAC уже на 5-6 нодах выдавал десятки млн транзакций в тестах tpc-c. т.е. порядка сотни млн запросов. сейчас, спустя десятилетие млрд запросов tpc-c прожует и половинка exadata.

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

S>·>Я делаю перевод с аккаунта 1, на аккаунт 2. Как я потом могу делать перевод с 2 на 3 или с 1 на 4, если произошло разделение? Если допускать овердрафты и рисковать потерями денег, то система будет AP. Если не допускать, то CP (некоторые переводы не будут проходить). Либо сделать чтобы не было разделения — всех клиентов послать в одно отделение банка и пусть там стоят в одной очереди, то будет CA (правда в этом случае клиенты скорее всего просто пойдут в другой банк). Четвёртого не дано.
S>
S>Во-первых, сведя всё к одному серверу, А вы не получите, как я уже упомянул. Вы её не улучшите, а ухудшите.
Ты не понял. На серваке работает алгоритм, который обладает CA-свойством. Однонодовая система принципиально разделяться не может.

S>Во-вторых, вы опять забываете про то, что "разделение" — это временная штука. Если у нас время восстановления меньше, чем SLA на транзакцию по переводу денег, то система будет CAP.
В CAP разделение это потеря сообщений. Потеряли, а потом нашли что-ли?

S>В-третьих, в задаче про переводы денег, как и в любой другой, нас интересует не 100% Availability, а "экономически оправданная". И если мы внимательно рассмотрим требования и возможности, то окажется, что мы можем сделать так, что даже при разделении кластера у нас будут падать не все запросы, а только достаточно небольшая их доля. При определённых усилиях окажется так, что эта доля будет меньше доли запросов, которые падают по несвязанным с разделением причинам.
S>Опять-таки, CAP нам в этом никак не поможет.
Т.е. ты описал CP-систему. Об чём спор-то?

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

S>·>Ну так нельзя же. Ты почему-то опровергаешь то, что теорема не утверждает. "Вечного двигателя не существует", а ты это опровергаешь "Но ведь двигатели же существуют!"
S> Очень хороший пример. С точки зрения инженерной науки, теорема Карно гораздо полезнее теоремы о невозможности вечного двигателя.
Ок, если это спор о полезности, то я сдаюсь. Полезность вещь чисто субъективная, о вкусах не спорят.

S>>>Тогда у нас будет повод изменить MTBF сегментов — например, продублировав их.
S>·>И как же держать дубликаты in-sync без потери C или A?
S>Очень просто: берём 2 (два) провода, воткнутые в две сетевые карточки. Сможете сами рассчитать вероятность выхода из строя одновременно обеих, если вероятность выхода из строя одной известна?
И дальше что? Сетевые карточки будет обслуживать сервак, который внезапно может перестать отвечать, по обоим проводам.

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

C>>Кто куда перешёл? Классический процессинг в нынешней технологии можно обработать в масштабах всей страны на одной персоналке. Там вообще ничего нетривиального по меркам современных технологий нет, так что я не удивляюсь, что впариватели из Оракала его успешно пихают.
Gt_>студент детектед. финсектор и банки это не только лишь процессинг
Ещё мелочи типа load underwriting, но там тоже (ВНЕЗАПНО!) нет никакого RAC. Так как нужна производительность.

C>>А вот в инвестиционном банкинге или финтехе — никакими RAC и не пахнет.
Gt_>на переферии может быть, в европе exadata съела все и вся.
Ага, конечно.

C>> Хадуп занимается совсем другим.
Gt_>совсем другим занимается олтп в фин секторе, откуда и вытеснилди RAC весь этот изредко консистентный NoSQL
DynamoDB — это OLTP, а не аналитика. JFYI.

C>>Ну и как насчёт миллиарда запросов в секунду на DDB? Это "проигрывают обычному хадупу"?
Gt_>а кому в 21 интересны запрсы ? на дворе 21 век, кругом реалтайм стриминг. кафка + спарк + hdfs давно стандарт в отрасли.
Чатбот детектед.

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

CK>А не напомнишь, о чем собственно спор? Что этот дизайн нам доказывает? И какими по твоему свойствами, опровергающими полезность САР, эта система обладает?
Эта система гарантирует consistency при очень неплохой availability.
Опровергает полезность это очень просто — с т.з. CAP, все CP системы одинаково бесполезны.
А с точки зрения инженерной (и бизнеса) availability в 1 девятку очень сильно отличается от availability в 5 девяток.

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

DI>Во-первых, про роутер ты в своей архитектуре ты ничего не говорил, пока я не указал, что он нужен.
Вы как-то ловко подменяете задачу. Началось всё, напомню, с вашего безапелляционного заявления о том, что failover cluster невозможно масштабировать.
Вам показали, как именно его можно масштабировать. Речи о том, что failover cluster — это серебряная пуля, или обязательства нарисовать полную архитектуру, которая обеспечивает CAP для произвольно придуманной прикладной задачи, не было.

DI>Во-вторых, ссылку то дай, а то пока твое слово против моего и не я должен опровергать, что в книге нет, а ты доказывать. В-третьих, дай-то уж нормальное описание предлагаемой тобой архитектуры, а то пока ты только что-то туманное вбросил.
Эти вопросы освещены в главе 6, Partitioning. Страницы с 209 по 216.
DI>Где? Не увидел.
Все поставленные вами задачи сводятся к rebalancing partitions. Я вам написал пошаговый сценарий перевоза шарда с одной ноды на другую.
S>>Чем вас не устраивает Raft или модификации Paxos?
DI>Подожди, давай ты сначала покажешь масштабируемую архитектуру обеспечивающую доступность и консистентность. Пока почему-то ты просто скипаешь мои аргументы.
Мне неизвестна единая архитектура, обеспечивающая CAP для произвольного масштаба, и пригодная для произвольной прикладной задачи.
Для принятия архитектурных решений придётся начать с конкретной задачи, и уже исходя из функциональных и нефункциональных требований подобрать к ней реализацию.

В целом, направление разработки — именно такое: шардинг + репликация; линки различной степени надёжности для локальных и для глобальных коммуникаций; консенсус для обеспечения C и A (как, например, в SQL Azure, где коммит требует "2 из 3"). Для роутинга выбираются более консервативные алгоритмы консенсуса, т.к. там можно оптимизироваться для "mostly read" нагрузки, и потеря availability в операциях записи нам не так страшна.

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

CK>>А не напомнишь, о чем собственно спор? Что этот дизайн нам доказывает? И какими по твоему свойствами, опровергающими полезность САР, эта система обладает?
S>Эта система гарантирует consistency при очень неплохой availability.
S>Опровергает полезность это очень просто — с т.з. CAP, все CP системы одинаково бесполезны.
Конкретно CAP тут сама по себе непричём, но у всех CP или CA систем есть ограничение по масштабируемости.

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

S>>Во-первых, сведя всё к одному серверу, А вы не получите, как я уже упомянул. Вы её не улучшите, а ухудшите.
·>Ты не понял. На серваке работает алгоритм, который обладает CA-свойством. Однонодовая система принципиально разделяться не может.
Это просто означает, что данное определение "CA-свойства" неприменимо на практике. Получается, что в CAP какая-то странная Availability: в однонодовой системе A нет, а по CAP получается что есть.
А в реальных многонодовых системах наоборот — A есть, а с точки зрения CAP — нету. Нуинахрена?

·>В CAP разделение это потеря сообщений. Потеряли, а потом нашли что-ли?
Конечно. Вы же в курсе, как работает TCP?

·>Т.е. ты описал CP-систему. Об чём спор-то?
О том, что CAP не позволяет нам сделать никаких выводов относительно возможности построения такой системы.

·>Я не знаю что ты имеешь в виду. Алгоритм обладает двумя сложностными характеристиками — пространство (память) и время (макс число операций). Я не имел в виду физическое время. В контексте O-нотации по-моему очевидно какое время имеется в виду. Под "Быстрее" я имел в вмиду требует меньше времени.
Я подробно написал, что имею в виду. Ваше понимание термина "быстрее" и термина "время" по-прежнему показывает разницу между подходами инженера и математика: когда инженер говорит о скорости, он имеет в виду "календарное" время — то есть response times, а не number of operations. Второе его тоже интересует, но как независимая величина, которая влияет на энергопотребление.
А вы смешиваете их в одну кучу. Даже если лично вы всё время помните о том, что ваше "время" — это не время, то все остальные, кто читает ваши утверждения, понимают их превратно.
Заметьте, что в оригинале, на который вы сослались, терминов "время" и "скорость" нет. Там честно написано про количество операций — именно потому, что профессионалы знают между ними разницу.

·>Ок, если это спор о полезности, то я сдаюсь. Полезность вещь чисто субъективная, о вкусах не спорят.
Не, объективная. Ваша теорема о невозможности вечных двигателей запрещает очень узкий класс двигателей.
А теорема Карно позволяет отсеять также даровые двигатели и вечные двигатели второго рода.


·>И дальше что? Сетевые карточки будет обслуживать сервак, который внезапно может перестать отвечать, по обоим проводам.
Это не является partition в терминах CAP. Вы же сами только что цитировали — там речь про потерю пакетов. Если у нас нагнулся сервер, это совсем другая проблема, и она совершенно по-другому влияет на consistency.

Здравствуйте, Cyberax, Вы писали:
C>Конкретно CAP тут сама по себе непричём, но у всех CP или CA систем есть ограничение по масштабируемости.
Давайте же озвучим это ограничение!

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

C>>Конкретно CAP тут сама по себе непричём, но у всех CP или CA систем есть ограничение по масштабируемости.
S>Давайте же озвучим это ограничение!
Основная проблема — трафик синхронизации масштабируется экспоненциально с ростом числа узлов в CP-системах. В CA-системах с ростом числа узлов экспоненциально увеличивается риск отказа.

Здравствуйте, Cyberax, Вы писали:
C>Основная проблема — трафик синхронизации масштабируется экспоненциально с ростом числа узлов в CP-системах. В CA-системах с ростом числа узлов экспоненциально увеличивается риск отказа.
Спасибо, очень интересно!
Хотелось бы почитать про это более подробно, с формулами и доказательствами. Это как раз то, что я ищу.
По идее, это даст возможность получить ту самую математику, которой не хватает — формулу, которая связывает не булевые, а рациональные значения C, A, и P.

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

C>Основная проблема — трафик синхронизации масштабируется экспоненциально с ростом числа узлов в CP-системах. В CA-системах с ростом числа узлов экспоненциально увеличивается риск отказа.
Вот такая теорема была бы существенно полезнее САР.
О чем собственно, и весь этот разговор.

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

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

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

"при очень неплохой" это субъективное суждение, как минимум, твоя система реплицирует данные только внутри ДЦ, потому что каждый replica set (который ты назваешь failover cluster, так себе название для _части_ кластера) может жить только в каком-то одном ДЦ, ты с этим согласен?

Твое понимание consistency тоже отличается от общепринятого (если я тебя правильно понял), в том смысле, что если у нас недоступен один replica-set а значит и какой-то диапазон ключей, то система потеряла доступность. Даже если он недоступен только на запись. Поэтому каждый раз, когда твой watchdog сервис делает failover, твоя система частично недоступна какое-то время. Если watchdog прилег, то неограниченно долгое. Поэтому обычно, за failover в таких системах отвечает не один сервис, а кластер. Посмотри на Redis Sentinel.

Сервис координации тоже нельзя рассматривать отдельно. Вообще, в твоей системе replica-set-ы (aka failover cluster-ы) могут быть тупыми хранилищами, а запросы пользователей на запись и чтение могут поступать сначала на front-end узлы, которые бы уже перенаправляли их в нужный replica set. Эти front-end узлы должны учатсвовать в консенсусе, чтобы иметь одинаковый routing. Эти же front-end узлы могут перемещать шарды с одного replicaset-а на другой, при реконфигурации кластера.

S>Опровергает полезность это очень просто — с т.з. CAP, все CP системы одинаково бесполезны.

Можно подробнее? Я не припомню, чтобы из САР теоремы можно было сделать такой вывод.

S>А с точки зрения инженерной (и бизнеса) availability в 1 девятку очень сильно отличается от availability в 5 девяток.

Tier 4 data-center гарантирует 99.995 доступность. То бишь в рамках одного ДЦ ты не получишь 5 девяток. AWS и Asure, насколько я знаю, тоже не обеспечивают 5 девяток, если ты держишь все в одном ДЦ.

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

S>Хотелось бы почитать про это более подробно, с формулами и доказательствами. Это как раз то, что я ищу.

посмотри сколько сообщений требует Paxos на каждый раунд, как оно зависит от количества узлов и что происходит в случае конфликта

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

C>>Основная проблема — трафик синхронизации масштабируется экспоненциально с ростом числа узлов в CP-системах. В CA-системах с ростом числа узлов экспоненциально увеличивается риск отказа.
S>Спасибо, очень интересно!
S>Хотелось бы почитать про это более подробно, с формулами и доказательствами. Это как раз то, что я ищу.
С CA-системами всё понятно — при росте числа узлов вероятность отказа хотя бы одного из них растёт экспоненциально (просто сумма вероятностей).

При гарантированном CP нужно запускать алгоритмы консенсуса на каждое чтение. При увеличении числа узлов трафик будет расти минимум квадратично, но без учёта конфликтов.

S>По идее, это даст возможность получить ту самую математику, которой не хватает — формулу, которая связывает не булевые, а рациональные значения C, A, и P.
Тут основной затык на букве "C". Оно или есть, или её нет. Если есть, то можно делать определённые компромиссы между A/P. Если отказываться от C, то пространство решений существенно расширяется.

На практике, самое основное значение вносит необходимость географической распределённости.

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

C>С CA-системами всё понятно — при росте числа узлов вероятность отказа хотя бы одного из них растёт экспоненциально (просто сумма вероятностей).
Зато вероятность отказа одновременно N/2+1 узлов падает.
C>При гарантированном CP нужно запускать алгоритмы консенсуса на каждое чтение. При увеличении числа узлов трафик будет расти минимум квадратично, но без учёта конфликтов.
Ну, трафик-трафиком, а как будет зависеть от N матожидание 50-percentile? Можно же две модели рассматривать — та, в которой network congestion пренебрегаем, и та, в которой учитываем.
Если нам для консенсуса надо дождаться N/2+1 ответов, то нас интересуют самые быстрые

C>Тут основной затык на букве "C". Оно или есть, или её нет. Если есть, то можно делать определённые компромиссы между A/P. Если отказываться от C, то пространство решений существенно расширяется.
Ну вот C ведь тоже можно измерять.

C>На практике, самое основное значение вносит необходимость географической распределённости.
На пальцах всё это понятно.

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

CK>"при очень неплохой" это субъективное суждение, как минимум, твоя система реплицирует данные только внутри ДЦ, потому что каждый replica set (который ты назваешь failover cluster, так себе название для _части_ кластера) может жить только в каком-то одном ДЦ, ты с этим согласен?
Согласен. Но даже получить availability "такую же, как у Data Center" — вполне неплохое достижение для приложения.

CK>Твое понимание consistency тоже отличается от общепринятого (если я тебя правильно понял), в том смысле, что если у нас недоступен один replica-set а значит и какой-то диапазон ключей, то система потеряла доступность.
Ээээ, так consistency или availability?

CK>Сервис координации тоже нельзя рассматривать отдельно. Вообще, в твоей системе replica-set-ы (aka failover cluster-ы) могут быть тупыми хранилищами, а запросы пользователей на запись и чтение могут поступать сначала на front-end узлы, которые бы уже перенаправляли их в нужный replica set. Эти front-end узлы должны учатсвовать в консенсусе, чтобы иметь одинаковый routing. Эти же front-end узлы могут перемещать шарды с одного replicaset-а на другой, при реконфигурации кластера.
Совершенно верно.
CK>Можно подробнее? Я не припомню, чтобы из САР теоремы можно было сделать такой вывод.
Всё наоборот — никакого другого вывода из CAP теоремы сделать нельзя. Если у вас есть способ вывести из CAP теоремы что-то более конструктивное, чем "обеспечение availability при partition tolerance требует отказа от consistency" — продемонстрируйте.

CK>Tier 4 data-center гарантирует 99.995 доступность. То бишь в рамках одного ДЦ ты не получишь 5 девяток. AWS и Asure, насколько я знаю, тоже не обеспечивают 5 девяток, если ты держишь все в одном ДЦ.
И?

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

S>Согласен. Но даже получить availability "такую же, как у Data Center" — вполне неплохое достижение для приложения.

чтобы было так же, как у ДЦ, нужно чтобы твое приложение работало вообще без отказов, я слабо представляю как такое возможно

CK>>Твое понимание consistency тоже отличается от общепринятого (если я тебя правильно понял), в том смысле, что если у нас недоступен один replica-set а значит и какой-то диапазон ключей, то система потеряла доступность.
S>Ээээ, так consistency или availability?

бес попутал, availability конечно

CK>>Можно подробнее? Я не припомню, чтобы из САР теоремы можно было сделать такой вывод.
S>Всё наоборот — никакого другого вывода из CAP теоремы сделать нельзя. Если у вас есть способ вывести из CAP теоремы что-то более конструктивное, чем "обеспечение availability при partition tolerance требует отказа от consistency" — продемонстрируйте.

Я про "с т.з. CAP, все CP системы одинаково бесполезны". САР вообще про полезность ничего не говорит, кмк. Не очень понятно как можно вывод о бесполезности из нее сделать.

CK>>Tier 4 data-center гарантирует 99.995 доступность. То бишь в рамках одного ДЦ ты не получишь 5 девяток. AWS и Asure, насколько я знаю, тоже не обеспечивают 5 девяток, если ты держишь все в одном ДЦ.
S>И?
Ну дык, ты же сам писал — "А с точки зрения инженерной (и бизнеса) availability в 1 девятку очень сильно отличается от availability в 5 девяток", то бишь если с точки зрения бизнеса, нужно иметь пять девяток, то тебе нужно в multidatacenter setup, если бизнес хочет гео-распределенность, ради низкой latency, тоже самое. Требования к системе диктуют tradeoff-ы, которые ты можешь использовать. Поэтому докозательство в духе — вот СР система, которая может в HA, поэтому на практике она ничем не уступает AP системам, по крайней мере с точки зрения пользователя — не работает. Уступает.

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

C>Основная проблема — трафик синхронизации масштабируется экспоненциально с ростом числа узлов в CP-системах. В CA-системах с ростом числа узлов экспоненциально увеличивается риск отказа.

Почему экспоненциально? Ведь не каждый с каждым же...