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

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

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

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

CK>бес попутал, availability конечно
Общепринятое понимание термина availability — это процент успешно выполненных запросов. Если у меня недоступно 1% диапазона ключей, то (в предположении равномерного распределения запрашиваемых данных) availability системы равна 99%.
Эта неожиданная на первый взгляд трактовка как раз и лежит, в частности, в основе географического сегментирования — когда теряется связь с удалёнными узлами, я всё ещё могу работать с локальными данными. Это гораздо лучше, чем полный отказ в обслуживании.

CK>Я про "с т.з. CAP, все CP системы одинаково бесполезны". САР вообще про полезность ничего не говорит, кмк. Не очень понятно как можно вывод о бесполезности из нее сделать.
Полезность — это уже бизнес-интерпретация свойства availability. С точки зрения CAP нет никакой разницы между системами с availability в 90% и в 99.999% — обе не являются available. "Вы пожертвовали availability". Тот факт, что availability в 5 девяток — запредельная для прикладного сервиса величина, теорему никак не меняет.

CK>Ну дык, ты же сам писал — "А с точки зрения инженерной (и бизнеса) availability в 1 девятку очень сильно отличается от availability в 5 девяток", то бишь если с точки зрения бизнеса, нужно иметь пять девяток, то тебе нужно в multidatacenter setup, если бизнес хочет гео-распределенность, ради низкой latency, тоже самое. Требования к системе диктуют tradeoff-ы, которые ты можешь использовать. Поэтому докозательство в духе — вот СР система, которая может в HA, поэтому на практике она ничем не уступает AP системам, по крайней мере с точки зрения пользователя — не работает. Уступает.
Кто сказал "ничем не уступает"??? Чтобы понять, кто кому уступает, надо сначала сравнить реальные показатели consistency и availability.
Ещё раз повторю очевидную мысль: CAP теорема не даёт нам никакого базиса для сравнения систем с различным количеством девяток — просто потому, что в её определении availability нет никаких девяток.
Поэтому я не вполне понимаю, как можно без лукавства привлекать эту теорему для обоснования каких-либо решений. Вот вы приходите ко мне, и говорите: "я предлагаю сделать вот такую AP систему, потому что CAP не даёт нам возможности получить CAP-систему". А я вам отвечаю: "ок, то есть ваша система — она прямо вся такая A, несмотря ни на какие P"? Вы мне: "ой, нет, DC, в котором она развернута, даёт A=99.95%". Тогда я вам говорю: "а нахрена вы мне приносите P-систему, в которой нет ни A ни С? Давайте вы лучше мне сделаете CP-систему, которая имеет A в 99.9%. Полпроцента сожрал DC, я даю вам ещё полпроцента A на обеспечение С".

Боюсь, что после этого вам придётся свернуть CAP-теорему в трубочку и заняться реальной service reliability engineering работой.

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

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

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

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

CK>бес попутал, availability конечно
Общепринятое понимание термина availability — это процент успешно выполненных запросов. Если у меня недоступно 1% диапазона ключей, то (в предположении равномерного распределения запрашиваемых данных) availability системы равна 99%.
Эта неожиданная на первый взгляд трактовка как раз и лежит, в частности, в основе географического сегментирования — когда теряется связь с удалёнными узлами, я всё ещё могу работать с локальными данными. Это гораздо лучше, чем полный отказ в обслуживании.

CK>Я про "с т.з. CAP, все CP системы одинаково бесполезны". САР вообще про полезность ничего не говорит, кмк. Не очень понятно как можно вывод о бесполезности из нее сделать.
Полезность — это уже бизнес-интерпретация свойства availability. С точки зрения CAP нет никакой разницы между системами с availability в 90% и в 99.999% — обе не являются available. "Вы пожертвовали availability". Тот факт, что availability в 5 девяток — запредельная для прикладного сервиса величина, теорему никак не меняет.

CK>Ну дык, ты же сам писал — "А с точки зрения инженерной (и бизнеса) availability в 1 девятку очень сильно отличается от availability в 5 девяток", то бишь если с точки зрения бизнеса, нужно иметь пять девяток, то тебе нужно в multidatacenter setup, если бизнес хочет гео-распределенность, ради низкой latency, тоже самое. Требования к системе диктуют tradeoff-ы, которые ты можешь использовать. Поэтому докозательство в духе — вот СР система, которая может в HA, поэтому на практике она ничем не уступает AP системам, по крайней мере с точки зрения пользователя — не работает. Уступает.
Кто сказал "ничем не уступает"??? Чтобы понять, кто кому уступает, надо сначала сравнить реальные показатели consistency и availability.
Ещё раз повторю очевидную мысль: CAP теорема не даёт нам никакого базиса для сравнения систем с различным количеством девяток — просто потому, что в её определении availability нет никаких девяток.
Поэтому я не вполне понимаю, как можно без лукавства привлекать эту теорему для обоснования каких-либо решений. Вот вы приходите ко мне, и говорите: "я предлагаю сделать вот такую AP систему, потому что CAP не даёт нам возможности получить CAP-систему". А я вам отвечаю: "ок, то есть ваша система — она прямо вся такая A, несмотря ни на какие P"? Вы мне: "ой, нет, DC, в котором она развернута, даёт A=99.95%". Тогда я вам говорю: "а нахрена вы мне приносите P-систему, в которой нет ни A ни С? Давайте вы лучше мне сделаете CP-систему, которая имеет A в 99.9%. 0.05% сожрал DC, я даю вам ещё 0.05% A на обеспечение С".

Боюсь, что после этого вам придётся свернуть CAP-теорему в трубочку и заняться реальной service reliability engineering работой.