Здравствуйте, kaa.python, Вы писали: KP>Почему это? Можно, просто ты получаешь, к примеру при наличии системы из двух узлов, две независимые системы которые удовлетворяют A и C, и, что интересно, P тоже, так как подобная система рано или поздно вырождается в набор независимых узлов.
В этой трактовке непонятно, что такое Consistency. Если нас устраивает ситуация, в которой две независимые системы имеют разные представления об истинности каких-то утверждений, то вообще непонятно, зачем мы изначально их склеивали в одну систему. Понятно, что M независимых систем гораздо надёжнее и проще устроены, чем одна композитная система с M компонентами.
S>>Во-вторых, меня интересует не "пожертвовать A и С", а принимать инженерные решения. В инженерном подходе бессмысленно говорить об Availability как о бинарном параметре — да и вообще почти все параметры описываются гораздо более сложными моделями, чем есть/нету. Я и так понимаю, что даже безо всяких CAP невозможно получить гарантированную availability, даже пожертвовав вообще всем — потому что превращение Солнца в сверхновую гарантированно уничтожит мою систему, даже если я сделаю резервную реплику на Юпитере. Меня интересует, как достичь заданного заказчиком процента отказов, при условии, что я знаю профили отказов компонентов, из которых я строю свою систему.
KP>По моему мнению, теорема не должна в принципе давать ответа на такой вопрос, так как она как раз и описывает набор бинарных свойств. Хорошая теорема — должна. KP>Тут скорее дело в том, что у разных людей разные ожидания от теоремы как таковой. Лично мне она было очень полезна на начальном этапе, так как дает базовую, бинарную логику. А потом уже приходит понимание того, о чем ты пишешь выше.
Я всё же рекомендую внимательно ознакомиться со статьёй Клеппана на эту тему. Сейчас теорема CAP интересна не более, чем представления древних греков о структуре материи с точки зрения современной физики.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>1. Во-первых, она криво сформулирована. Поскольку нет такого понятия, как Partition Tolerance в отдельности от Consistency, не имеет и смысл ставить вопрос так, как будто там есть выбор. Более корректная, но менее красивая формулировка утверждения этой теоремы состоит в том, что при network partition вам придётся выбирать между consistency и availability. S>2. Во-вторых, она бесполезна, т.к. не предлагает никаких инструментов для управления этим выбором. Грубо говоря, могу ли я частично пожертовать availability, чтобы получить частичную consistency? Если да, то насколько? Если нет, то почему?
Она ни в коем случае не бесполезна, т.к. является формализмом и точкой отправления для рассуждений об распр. системах. Выше я привел ссылку на теорему Шеннона из которой и других подобных теорем выработан подробный мат. аппарат и целая теория (теория информации), как из шумящих и ненадежных по отдельности систем за счет математики и прочих формализмов сделать систему надежную. Имеем распределенные системы, дано -- ограниченный по своим ресурсам
компьютер, который может обработать ограниченног число запрсов\сек, ненадежная сеть. И как из ентих ограниченных машин и ненадежной сети сделать систему, которая может обработать любое кол-во запросов. Аналогия видна? И никакой математики, никаких формализмов вообще нет, т.е не было до CAP. Нету какой-то систематизированной теории распределенных систем, все пишут в меру своего понимания. Выше пример, как каждый по-своему понимает тот же CAP. Про теоремы вообще молчу. Понятоно, что есть Лесил Лампорт со своими работами по консенсусу в распределенных системах, аналог Клода Шеннона в ти. Но как-то ентого кажется не достаточно, кмк. Т.е. мне видится разработка распр. как искусство,
нежели инженерное ремесло.
Здравствуйте, Sinclair, Вы писали:
S>Я всё же рекомендую внимательно ознакомиться со статьёй Клеппана на эту тему. Сейчас теорема CAP интересна не более, чем представления древних греков о структуре материи с точки зрения современной физики.
Ты как-то криво это прочитал и преувеличиваешь. САР описывает регистр, она не описывает базу данных. В базе данных у тебя может быть свой отдельный трейдоф для чтения/записи/разных уровней изоляции.
Здравствуйте, Sinclair, Вы писали:
S> Меня интересует, как достичь заданного заказчиком процента отказов, при условии, что я знаю профили отказов компонентов, из которых я строю свою систему.
Она и не должна отвечать на ентот вопрос. Она отвечает за состояние всей системы целиком, а не отдельных компонентов. Вопрос выше -- вопрос на тему избыточности компонентов, репликации.
Т.е. типа диск ломается раз в три года, у нас 1000 дисков, и следовательно десятки дисков будут ломаться ежедневно. Ну и т.д. Причем здесь CAP&
Здравствуйте, Sharov, Вы писали:
S>Она ни в коем случае не бесполезна, т.к. является формализмом и точкой отправления для рассуждений об распр. системах. Выше я привел ссылку на теорему Шеннона из которой и других подобных теорем выработан подробный мат. аппарат и целая теория (теория информации), как из шумящих и ненадежных по отдельности систем за счет математики и прочих формализмов сделать систему надежную.
Прекрасная аналогия. Теорема Шеннона имеет количественную формулировку. Аналогом CAP для Котельникова-Шеннона было бы утверждение вроде "обеспечение бесконечной точности воспроизведения сигнала требует бесконечной частоты дискретизации". Ну, как бы да, ичо? Во-первых, это очевидно, во-вторых, это бесполезно.
S>Имеем распределенные системы, дано -- ограниченный по своим ресурсам S>компьютер, который может обработать ограниченног число запрсов\сек, ненадежная сеть. И как из ентих ограниченных машин и ненадежной сети сделать систему, которая может обработать любое кол-во запросов. Аналогия видна? И никакой математики, никаких формализмов вообще нет, т.е не было до CAP.
Ну это, конечно же, неправда. S>Нету какой-то систематизированной теории распределенных систем, все пишут в меру своего понимания. Выше пример, как каждый по-своему понимает тот же CAP. Про теоремы вообще молчу. Понятоно, что есть Лесил Лампорт со своими работами по консенсусу в распределенных системах, аналог Клода Шеннона в ти. Но как-то ентого кажется не достаточно, кмк. Т.е. мне видится разработка распр. как искусство, S>нежели инженерное ремесло.
Это как раз очень плохо, т.к. в данном контексте термин "искусство" — ругательный. И я вижу, как систематизированная теория распределённых систем всё же строится. И для её построения нужно избегать мусора типа CAP, а заниматься нормальными инженерными расчётами и математическими обоснованиями.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sharov, Вы писали:
S>Она и не должна отвечать на ентот вопрос. Она отвечает за состояние всей системы целиком, а не отдельных компонентов. Вопрос выше -- вопрос на тему избыточности компонентов, репликации. S>Т.е. типа диск ломается раз в три года, у нас 1000 дисков, и следовательно десятки дисков будут ломаться ежедневно. Ну и т.д. Причем здесь CAP&
Охохохо. Начнём с азов: что такое availability? Вот у нас есть запрос клиента, вот есть на него ответ. То есть availability — это способность системы отвечать на запросы, так?
Но ведь ответы никогда не приходят мгновенно!
Предположим, у нас случилось нарушение коммуникации между клиентом и сервером (в современном интернете это происходит сплошь и рядом). Это нарушение исправили через 10 секунд.
Ответ получен? Получен. Система доступна? Доступна.
Ок, починка заняла неделю. Ничто не мешает нам реализовать коммуникационный слой таким образом, чтобы это выглядело не как отказ, а как медленный ответ.
Ну, тогда у нас вообще никаких проблем с availability не бывает никогда — рано или поздно система таки ответит.
Ой, а как же CAP? А вот так: нет никакого CAP, если разрешить unbounded delays.
А если запретить? То есть у нас ответ на запрос должен приходить за время T0. Отсутствие ответа = сбой.
Ну ок, мы понимаем, что даже безо всякого Partition и Consistency есть шанс не получить ответ — много что может случиться, так ведь?
Значит, мы выражаем Availability в виде приемлемого % запросов, которые вылезут за пределы T0.
И нас может устраивать availability в 90, 99, 99.9, 99.99% и так далее. И таймаут может быть 5мс, 5с, или 50с. .
Понятно, что от выбора этих требований зависит сложность их обеспечить — например, если у нас частота сбоев внутрисистемной коммуникации ниже определённой, или, скажем, время их разрешения быстрее определённого, то мы запросто можем получить нужную нам availability без потери consistency, несмотря на наличие partition.
Точно так же и consistency — есть много разных вариантов трактовки этого требования, есть более жёсткие и менее жёсткие требования; и не факт, что в нашей прикладной задаче прямо необходимо будет требовать выполнения произвольных предикатов над полными разделяемыми данными.
Полезной была бы теорема вроде Шеннона, которая бы связывала количественные метрики — сколько процентов availability можно получить из M узлов, если availability каждого узла X, а availability связывающей их сети — Y.
CAP бесконечно далека от этого, увы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>Прекрасная аналогия. Теорема Шеннона имеет количественную формулировку. Аналогом CAP для Котельникова-Шеннона было бы утверждение вроде "обеспечение бесконечной точности воспроизведения сигнала требует бесконечной частоты дискретизации". Ну, как бы да, ичо? Во-первых, это очевидно, во-вторых, это бесполезно.
Не согласен. Енто уже некий словарь ключевых теримнов и понятий, от которых можно оттолкнуться и вокруг которых можно строить разговор, архитектуру. Аналогом К-Ш было введение понятия частоты, дискретизации,
желание воспроизвести сигнал и т.д. Базовые вещи и понятия. Далее идет сама т. К-Ш, количественная. И тут в мире распр. систем наступает затык. Вот допустим я хочу построить систему, где у меня будет
< 100 req/sec. я должен ..., а если >100000 req/sec. я должен... Т.е. количества у нас нет, нету математики формул и т.д. Но хотя бы есть ключевые понятия (CAP).
S>>Имеем распределенные системы, дано -- ограниченный по своим ресурсам S>>компьютер, который может обработать ограниченног число запрсов\сек, ненадежная сеть. И как из ентих ограниченных машин и ненадежной сети сделать систему, которая может обработать любое кол-во запросов. Аналогия видна? И никакой математики, никаких формализмов вообще нет, т.е не было до CAP. S>Ну это, конечно же, неправда.
Кроме Лэмпорта что-то еще было?
S>Это как раз очень плохо, т.к. в данном контексте термин "искусство" — ругательный. И я вижу, как систематизированная теория распределённых систем всё же строится. И для её построения нужно избегать мусора типа CAP, а заниматься нормальными инженерными расчётами и математическими обоснованиями.
Здравствуйте, Sharov, Вы писали:
S>Не согласен. Енто уже некий словарь ключевых теримнов и понятий, от которых можно оттолкнуться и вокруг которых можно строить разговор, архитектуру.
Ну конечно же нет. Словарь ключевых терминов и понятий вводится как раз, к примеру, в DDIA. Или в той же статье Клеппмана, на которую я тут сослался. S>Аналогом К-Ш было введение понятия частоты, дискретизации, желание воспроизвести сигнал и т.д. Базовые вещи и понятия. Далее идет сама т. К-Ш, количественная.
Ну так она количественная как раз потому, что у нас в базовых понятиях есть количественные показатели. А если бы мы, как в CAP, оперировали абсолютностями, вроде "сигнал" и "идеально восстановить сигнал", то никакой К-Ш сформулировать бы не удалось. Потому что в CAP нет ни малейшего желания availability измерять в каких-то единицах, кроме "есть"/"нету".
S>И тут в мире распр. систем наступает затык. Вот допустим я хочу построить систему, где у меня будет S>< 100 req/sec. я должен ..., а если >100000 req/sec. я должен... Т.е. количества у нас нет, нету математики формул и т.д. Но хотя бы есть ключевые понятия (CAP).
Ну естественно. С таким базисом, как CAP, двигаться некуда — сразу затык. Если availability (или consistency) нету, то о чём дальше говорить? Всё, темнота, хаос. Нет никаких параметров, формулы для которых мы бы могли придумать.
Типа если у нас наступил P, и мы не готовы жертвовать Consistency, то всё, никакой тебе A. Никакие реквесты, даже частично, даже за длинное время, невыполнимы.
Или наоборот — если мы хотим A, то при наступлении P мы можем вообще на любой запрос отдавать 42 — а чо, consistency же нет!
Нельзя, к примеру, давать оплачивать никакие покупки, даже на сумму менее 100р, при отсутствии двусторонней связи с банком-эмитентом — АВДРУГ!
А ведь если мы понятие consistency задаём как "нельзя снять со счёта в минус", то при наступлении P сегмент размера S может безопасно разрешить списание вплоть до S/STotal от суммы счёта на момент разделения.
Ухты, как же так? Ведь CAP нам явно запрещает получать одновременно C и A? А вот так. При последующем слиянии сегментов транзакции прекрасно отсериализуются, без нарушения инвариантов.
Вот потому-то CAP лучше забыть, как страшный сон, и начать читать нормальную литературу.
S>>>Имеем распределенные системы, дано -- ограниченный по своим ресурсам S>>>компьютер, который может обработать ограниченног число запрсов\сек, ненадежная сеть. И как из ентих ограниченных машин и ненадежной сети сделать систему, которая может обработать любое кол-во запросов. Аналогия видна? И никакой математики, никаких формализмов вообще нет, т.е не было до CAP. S>>Ну это, конечно же, неправда.
S>Кроме Лэмпорта что-то еще было?
Да кто угодно этим занимался. Я лично читал локальные публикации про распределённые системы ещё в 90х. Что-то типа "концепция времени в распределённых системах".
Но это неважно — даже если бы вообще никаких других результатов не было вплоть до послезавтра, ценность у CAP отрицательная. Именнно потому, что она провоцирует на неверные выводы — хуже, чем Проблема Останова. S>Полностью согласен, но CAP выбрасыать не стоит.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Не согласен. Енто уже некий словарь ключевых теримнов и понятий, от которых можно оттолкнуться и вокруг которых можно строить разговор, архитектуру. S>Ну конечно же нет. Словарь ключевых терминов и понятий вводится как раз, к примеру, в DDIA. Или в той же статье Клеппмана, на которую я тут сослался.
В DDIA вообще ничего не вводится. Болтовня, немного обо всем. Если бы DDIA ввела бы понятия CAP в 2000 году, тогда да, согласен. Для 2019 это набор ссылок в конце глав, неплохой.
CAP -- это набор ключевых понятий, которых не было и оне вдруг сформулировались. Стало понятно куда копать и над чем думать\работать. Енто уже большое дело!
S>>Аналогом К-Ш было введение понятия частоты, дискретизации, желание воспроизвести сигнал и т.д. Базовые вещи и понятия. Далее идет сама т. К-Ш, количественная. S>Ну так она количественная как раз потому, что у нас в базовых понятиях есть количественные показатели. А если бы мы, как в CAP, оперировали абсолютностями, вроде "сигнал" и "идеально восстановить сигнал", то никакой К-Ш сформулировать бы не удалось. Потому что в CAP нет ни малейшего желания availability измерять в каких-то единицах, кроме "есть"/"нету".
Просто никто следущий шаг, количественный, не сделал или его просто невозможно сделать? Или он у каждой системы свой... Может мы не знаем, а оне есть?...
S>Вот потому-то CAP лучше забыть, как страшный сон, и начать читать нормальную литературу.
Пример нормальной литературы можно, кроме работ Лэмпорта? Оне вообще есть. DDIA не предлагать, это не учебная литература, а обзорная. Танненбаум?
S>>Кроме Лэмпорта что-то еще было? S>Да кто угодно этим занимался. Я лично читал локальные публикации про распределённые системы ещё в 90х. Что-то типа "концепция времени в распределённых системах".
Это, вероятно, работа Лэмпорта и есть, еще годов 70-х.
S>Но это неважно — даже если бы вообще никаких других результатов не было вплоть до послезавтра, ценность у CAP отрицательная. Именнно потому, что она провоцирует на неверные выводы — хуже, чем Проблема Останова.
Благодаря CAP состоялась не одна система, которой, вероятно, мы пользуемся каждый день. Огромному число архитекторов сэкномили время на изобретения велосипедов и решения несущственных проблем,
четко указав чем мы жертвуем в том или ином случае. Польза есть и немалая.
Позже запилю с ссылкой енту дискуссию в пост для широкой аудитории. Вопрос интересный. Либо выделить енту подветку во flame.comp, отредактировав заголовок типа "Теория инф-ии vs распеделенные системы".
Здравствуйте, Sharov, Вы писали:
S>В DDIA вообще ничего не вводится. Болтовня, немного обо всем. Если бы DDIA ввела бы понятия CAP в 2000 году, тогда да, согласен. Для 2019 это набор ссылок в конце глав, неплохой. S>CAP -- это набор ключевых понятий, которых не было и оне вдруг сформулировались. Стало понятно куда копать и над чем думать\работать. Енто уже большое дело!
А можно уточнить — какие именно "ключевые понятия" введены в CAP?
S>Просто никто следущий шаг, количественный, не сделал или его просто невозможно сделать? Или он у каждой системы свой... Может мы не знаем, а оне есть?...
Почему не сделал? Сделал. Липтон и Сандберг, к примеру, доказали, что any algorithm implementing a sequentially consistent read-write registermust have|r|+|w| ≥d, where |r| is the latency of a read operation, |w| is the latency of a write operation,and d is the network delay. Это как бы 1988. Аттия и Уэлч в 1995 доказывают, что any algorithm implementing a linearizable read-write register must have an operation latency of at least u/2, where u is the uncertainty of delay in the network between replicas.
Это к вопросу о том, что до CAP "никто не занимался распределёнными системами", ага.
S>>Вот потому-то CAP лучше забыть, как страшный сон, и начать читать нормальную литературу.
S>Пример нормальной литературы можно, кроме работ Лэмпорта? Оне вообще есть. DDIA не предлагать, это не учебная литература, а обзорная. Танненбаум?
Начать можно отсюда: https://arxiv.org/pdf/1509.05393.pdf.
S>Это, вероятно, работа Лэмпорта и есть, еще годов 70-х.
Нет, Лэмпорт в нашем ВЦ совершенно точно не работал.
S>Благодаря CAP состоялась не одна система, которой, вероятно, мы пользуемся каждый день. Огромному число архитекторов сэкномили время на изобретения велосипедов и решения несущственных проблем, S>четко указав чем мы жертвуем в том или ином случае. Польза есть и немалая.
Чего? Какие системы "состоялись благодаря CAP"? Вы, коллега, что-то путаете.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
S>>В DDIA вообще ничего не вводится. Болтовня, немного обо всем. Если бы DDIA ввела бы понятия CAP в 2000 году, тогда да, согласен. Для 2019 это набор ссылок в конце глав, неплохой. S>>CAP -- это набор ключевых понятий, которых не было и оне вдруг сформулировались. Стало понятно куда копать и над чем думать\работать. Енто уже большое дело! S>А можно уточнить — какие именно "ключевые понятия" введены в CAP?
Был явно обозначен компромисс между C,A и P.
S>>Просто никто следущий шаг, количественный, не сделал или его просто невозможно сделать? Или он у каждой системы свой... Может мы не знаем, а оне есть?... S>Почему не сделал? Сделал. Липтон и Сандберг, к примеру, доказали, что any algorithm implementing a sequentially consistent read-write registermust have|r|+|w| ≥d, where |r| is the latency of a read operation, |w| is the latency of a write operation,and d is the network delay. Это как бы 1988. Аттия и Уэлч в 1995 доказывают, что any algorithm implementing a linearizable read-write register must have an operation latency of at least u/2, where u is the uncertainty of delay in the network between replicas.
S>Это к вопросу о том, что до CAP "никто не занимался распределёнными системами", ага.
Я, возможно, был не совсем точен. Безусловно занимались, но вот обощить все енто дело и свести к простым понятием до CAP не смогли.
S>>Это, вероятно, работа Лэмпорта и есть, еще годов 70-х. S>Нет, Лэмпорт в нашем ВЦ совершенно точно не работал.
Что не мешает цитировать его работы:"Time, Clocks, and the Ordering of Events in a Distributed System".
S>>Благодаря CAP состоялась не одна система, которой, вероятно, мы пользуемся каждый день. Огромному число архитекторов сэкномили время на изобретения велосипедов и решения несущственных проблем, S>>четко указав чем мы жертвуем в том или ином случае. Польза есть и немалая. S>Чего? Какие системы "состоялись благодаря CAP"? Вы, коллега, что-то путаете.
Не состоялсь, а началось активное развитие. Что-то типа NoSql.
Здравствуйте, Sharov, Вы писали: S>Был явно обозначен компромисс между C,A и P.
Конкретнее можно? Чтобы говорить о каких-то компромиссах нужно внятно определить C, A, и P.
И вот Брюер начинает за здравие, говоря что A, вообще-то, измеряется в процентах. Но затем, ближе к формулировке теоремы, внезапно уходит к понятию "highly available", которое требует, чтобы произвольный запрос достигал конкретно заданной ноды. Вы для сравнения вернитесь к началу DDIA, повнимательнее прочитайте определения. Они важны.
S>Я, возможно, был не совсем точен. Безусловно занимались, но вот обощить все енто дело и свести к простым понятием до CAP не смогли.
CAP — плохое "сведение к простым понятиям".
S>Не состоялсь, а началось активное развитие. Что-то типа NoSql.
Конкретнее? Мне кажется, у вас какое-то искажённое представление о роли CAP в NoSQL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Был явно обозначен компромисс между C,A и P. S>Конкретнее можно? Чтобы говорить о каких-то компромиссах нужно внятно определить C, A, и P.
В вики.
S>>Не состоялсь, а началось активное развитие. Что-то типа NoSql. S>Конкретнее? Мне кажется, у вас какое-то искажённое представление о роли CAP в NoSQL.
Возможно, ибо с NoSql я не работал. Но насколько я понимаю, благодаря CAP, явно поняв компромиссы, люди начали их(NoSql) активнее использовать. CAP понятнее чем
"linearizable read-write register" и т.п. Вы же не будете спорить, что для людей, которые хотят построить какое-нибудь расп. приложение, типа соц. сети или блогов,
от CAP больше толку чем от процитированных выше работ 70\80-х годов. Для людей, которые пилят движки распр. бд, типа NoSql,riak и т.п. CAP уже будет не столь полезен, кмк.
Здравствуйте, Sharov, Вы писали:
S>В вики.
Я-то думал вы реально Брюера читали
S>Возможно, ибо с NoSql я не работал. Но насколько я понимаю, благодаря CAP, явно поняв компромиссы, люди начали их(NoSql) активнее использовать. CAP понятнее чем S>"linearizable read-write register" и т.п. Вы же не будете спорить, что для людей, которые хотят построить какое-нибудь расп. приложение, типа соц. сети или блогов, S>от CAP больше толку чем от процитированных выше работ 70\80-х годов. Для людей, которые пилят движки распр. бд, типа NoSql,riak и т.п. CAP уже будет не столь полезен, кмк.
А, ну в таком смысле, наверное, да. Популяризация — штука важная.
Но мы-то, коллега, не журналистами работаем. С точки зрения технаря, а не гуманитария, CAP — это булшит.
Важно понимать, почему — чтобы красивые аббревиатуры не заслоняли смысл важных величин.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Stalker., Вы писали:
S>странно что Кalen Delaney никто не упомянул, ее набор книг по внутреннястям сервера абсолютная классика
Согласен. Мне посчастливилось в своё время попасть на её семинар. Могу точно сказать, что она реально весьма глубоко разбирается в том, о чем пишет и чему учит. Да и книги хорошие.
Может мы не знаем, а оне есть?...
