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


CK>Вот самое распространенное определение того, что есть availability (из CAP)
Самое распространенное и "из CAP" это разные вещи

CK> "Every request received by a non-failing node in the system must result in a response." (и под response тут имеется ввиду не возврат кода ошибки а ответ о том что все ОК). Это свойство системы, которое заключается в том, что на каждый запрос приходит ответ (если запрос дошел до работающей ноды). Заметь, что свойство никуда не пропадает, если часть машин недоступны.
То есть односерверная машина у нас априори available?
То есть пофиг что внутри происходит, главное ОК вернуть?
То есть пофиг сколько ждать перед тем как ОК вернуть?
Формальные ответы на эти вопросы — ДА, иного в CAP не указано, а на тему времени ответа даже ремарка есть.

И какой смысл в этом определении?

CK>Если система является доступной, в нее можно записывать всегда.
Но это не означает, что потом можно будет прочитать. То есть в грубом приближении AP система это /dev/null.

CK>Другое определение availability, с которым мне доводилось встречаться (и я думал что ты именно его имеешь ввиду) — это тупо то же самое что и аптайм. Тут мы действительно можем повысить availability поставив дополнительный блок питания, так как вероятность аппаратного сбоя снижается. Но я исхожу из того что а) это само собой разумеется б) в контексте NoSQL availability — свойство системы куда интереснее и полезнее, нежели availability — надежность системы.

Availability это не свойство железа, а свойство системы (железа, каналов связи, логики серверов, логики клиентов). Определяется как процент времени когда система способна отвечать на запросы за разумное (заранее определённое) время и сохранять работоспособность. Для этого нужно в первую очередь поддерживать аптайм железа, чтобы серваки не падали и поддерживать логику работы.
При этом вовсе не требуется, чтобы на каждый запрос возвращался ОК, вполне возможно повторение запроса на клиенте, если сервер недоступен или отвечает "обратитесь позже". Так устроены многие протоколы от REST до TCP\IP.


Availability в CAP — бесполезное на практике свойство и его потеря по факту может не значить вообще ничего.
Partition tolerance кстати тоже. В большинстве случаев partition tolerant системы не могут сохранить согласованность данных даже через любое длительное время.

Писал об этом на хабре https://habrahabr.ru/post/231703/