Введение
Давно хотел написать про мифы о CAP теореме, но как-то все не доходили руки. Однако, почитав очередной опус, схватился за голову и решил разложить все по полочкам, чтобы в мозгах возникла стройная картина.
Событие, когда какая-то статья вызывает бурю эмоций, — крайне редкое. Первый раз такое возникло, когда я прочитал про chained replication. Меня пытались убедить, что это мощный подход и что это лучшее, что могло произойти с консистентной репликацией. Я сейчас не буду приводить доводы, почему это плохо работает, а просто приведу говорящую цитату из статьи Chain Replication metadata management:
Split brain management is a thorny problem. The method presented here is one based on pragmatics. If it doesn’t work, there isn’t a serious worry, because Machi’s first serious use case all require only AP Mode. If we end up falling back to “use Riak Ensemble” or “use ZooKeeper”, then perhaps that’s fine enough.
В моем вольном пересказе это означает примерно следующее: "У нас тут есть некий алгоритм. Мы не знаем, будет ли он работать правильно или нет. Да нам это и не важно". Хотя бы честно, сэкономило кучу времени, спасибо авторам.
И тут, значит, попадается на глаза статья: Spanner, TrueTime & The CAP Theorem. Её мы разберем по полочкам ближе к концу, вооружившись понятиями и знаниями. А перед этим разберем самые распространенные мифы, связанные с CAP теоремой.
Миф 1: A означает доступность
A, конечно же, образовалось от слова Availability, что означает доступность. Но какая это доступность? Какого рода?
Доступность в разных контекстах означает разное. И тут надо различать как минимум 2 разных контекста, в которых она употребляется:
- Доступность реального сервиса. Эта доступность выражается в процентах: измеряется общее время простоя в течении года и составляется соотношение, выраженное в процентах, говорящее о вероятности доступности в течении длительного времени.
- Доступность в рамках модели теоремы CAP.
В теореме CAP используется понятие, наиболее близкое по смыслу к термину полная доступность (total availability):
For a distributed system to be continuously available, every request received by a non-failing node in the system must result in a response.
Что означает примерно следующее: "любая неупавшая нода в системе должна ответить на запрос". В этом определении есть несколько моментов, которые я хотел бы подчеркнуть:
- "Неупавшая". Понятно, что упавшая нода никак не может ответить. Однако загвоздка состоит в том, что если все ноды упали, то с точки зрения определения такой сервис является доступным. В принципе, можно исправить определение, дополнив обстоятельством, что клиент должен получить ответ.
- "Должна ответить". Теорема не говорит, когда именно. Её вообще не интересуют временные параметры. Понятно, что нода не может ответить мгновенно. А раз не может, то достаточно, чтобы ответила когда-то.
С точки зрения пользователя, если у нас было 100 нод и 99 упали, а оставшаяся одна продолжает отвечать со скоростью один запрос в час, то такой сервис вряд ли можно назвать доступным (это контекст 1). Однако с точки зрения CAP теоремы тут все нормально и такая система будет являться доступной (контекст 2).
Поэтому A — это не доступность в общепринятом понимании, а так называемая полная доступность, которая пользователю может быть совсем неинтересна.
Миф 2: P означает устойчивость к сетевому разделению
Такое определение можно встретить практически во всех статьях. Чтобы понять, что тут не так, надо взглянуть на проблему под другим углом.
Возьмем любую систему, которая обменивается сообщениями. Рассмотрим то, как сообщения передаются между акторами — объектами системы. Эти сообщения могут либо доходить до другого актора, либо не доходить. И тут надо различать 2 случая:
- В системе невозможна ситуация, когда сообщения теряются.
- В системе возможна ситуация, когда сообщения теряются.
Нетрудно догадаться, что этот список исчерпывающий. В этом месте стоит обратить внимание, что каждый пункт описывает свойства системы. Т.е. мы еще даже не дошли до алгоритма. Это будет иметь далеко идущие последствия.
Если мы рассмотрим первый случай, когда сообщения никогда не теряются, то это означает, что в такой ситуации сетевое разделение (network split) просто невозможно. Действительно, раз каждое сообщение от каждого актора может дойти без потерь, то нет смысла говорить о сетевом разделении. Во втором случае все наоборот: из-за потерь возможна ситуация, когда целый сегмент отделился от другого, т.е. произошла потеря связности между группой акторов. В этом случае говорят, что случилось сетевое разделение.
Надо отметить, что свойство возможности изоляции групп акторов друг от друга есть прямое следствие выполнения пункта 2.
Если мы работаем с реальной сетью, то она, как нетрудно догадаться, подпадает под 2-й пункт. При этом мы еще не начали думать про алгоритм, а у нас уже появилась способность к разделению и потери связности между группами акторов. P — именно про это, что в системе возможно расщепление. И это — не свойство алгоритма, а свойство системы, в которой работает алгоритм.
Почему вообще в случае наличия потерь сообщений важно рассматривать именно сетевое разделение? Потому что остальные проблемы не вызывают столько хлопот и проблем, сколько порождает расщепление системы на независимые части.
В заключении этого мифа приведу цитату из блога Aphyr: Percona XtraDB Cluster:
Partition tolerance doesn’t require every node still be available to handle requests. It just means that partitions may occur. If you deploy on a typical IP network, partitions will occur; partition tolerance in these environments is not optional.
Таким образом, если мы рассматриваем систему, которая работает с реальной ненадежной сетью, то нарушения сетевой связности — это не исключительная ситуация, а то, с чем приходится иметь дело. И буква P в данном контексте всего лишь означает, что в системе возможно нарушение сетевой связности.
Миф 3: систем AC не существует
Из предыдущего мифа может возникнуть ощущение, что систем AC не существует, т.к. не существует надежных сетей, способных передавать данные. На это можно сразу попытаться предложить схему с резервированием компонент. Однако если вероятность потери пакета в линии >0, то как бы мы не добавляли каналов, вероятность не может стать =0 чисто из математических соображений. А раз так, то, согласно описанному выше, может быть сетевое разделение (network split).
Но кто сказал, что CAP описывает исключительно системы, связанные сетью? CAP — это теоретическая модель, которая может применяться к очень широкому классу задач. Например, можно взять многоядерный процессор:
- Каждое ядро — это отдельный актор.
- Акторы (ядра) обмениваются сообщениями (информацией).
Этого достаточно, чтобы говорить об CAP теореме.
Давайте обсудим сначала A. Есть ли доступность ядер? Безусловно, да, в любой момент времени можно обратиться к любому ядру и получить любые данные, которые мы захотим, из памяти.
Что по поводу P? Процессор гарантирует, что данные будут переданы без проблем другому ядру в случае необходимости. Если этого по каким-то причинам не происходит, то такой процессор считается бракованным. Таким образом, буква P отсутствует.
Вопрос с консистентностью также решается следующим образом. В модели памяти определена sequential consistency, что является самым высоким уровнем консистентности в такой системе. При этом внутри процессора как правило реализуют протоколы когерентности кэшей наподобие MESI или MOESI, обеспечивая тем самым заданный уровень консистентности.
Таким образом, современный процессор представляет собой систему AC с гарантированной доставкой сообщений между ядрами.
Миф 4: C означает консистентность
C без сомнения означает консистентность. Однако какую консистентность? Ведь eventual consistency — это тоже консистентность, только крайне слабая. Так что тут имеется в виду? Моделей консистентности много, достаточно взглянуть на диаграмму из статьи Consistency in Non-Transactional Distributed Storage Systems:
И это только про распределенные нетранзакционные системы! Если добавить в рассмотрение транзакционность, то можно сразу похоронить идею о том, чтобы разобраться в этом, так ни разу и не начав.
В оригинальной статье про CAP теорему речь везде шла про линеаризумость. Суть линеаризуемости, если вкратце, следующая. Если произошло какое-либо действие (не важно, чтение, запись, или смешанное действие или действия), то результат этого действия доступен сразу после того, как мы получили ответ.
Возникает закономерный вопрос: а что с другими моделями консистентности? Подпадают ли они под CAP теорему?
И тут начинается полная каша в головах. Некоторые думают, что раз модель доказана для линеаризуемости, то и применять ее стоит строго и исключительно для линеаризуемости. Другие думают, что любая более слабая модель консистентности уже не подпадает под эту теорему. Третьи вообще не понимают, в чем суть обсуждения.
Для ответа на этот вопрос рассмотрим замечательную картинку, взятую из статьи Highly Available Transactions:
О чем она говорит? Красным помечены так называемые модели недоступности, которые работают в рамках CAP теоремы. Т.е. одновременно с ней нельзя достичь A и P одновременно. Однако присутствуют другие модели, обладающие достаточным уровнем консистентности для ряда задач, которые тем не менее могут одновременно выполняться совместно с AP, получая систему CAP без всяких скидок. Типичный пример: Read Committed (RC) и Monotonic Atomic View (MAV) допускают соблюдение одновременно всех трех букв в CAP, при этом сложно назвать такие модели неконсистентными. Такие модели консистентности, для которых нарушается CAP-теорема, называют высокодоступными (highly available models).
Таким образом, говоря об консистентности, имеется в виду широкая группа моделей консистентности, называемых недоступными моделями (unavailable models).
Миф 5: системы CP не являются высокодоступными
После предыдущего пункта это утверждение кажется вполне логичным, но в корне неправильным. Напомню, что A означает полную доступность, а не доступность в рамках девяток. Возможно ли сделать систему CP высокодоступной?
Тут следует разделять модель и железо, т.е. теорию и реальность.
Давайте рассуждать сначала в рамках модели. Доступность в рамках CAP теоремы означает полную доступность, т.е. любая живая нода должна ответить. Однако зачем вообще нужно такое? Ведь логику клиента мы можем написать совершенно по-другому. Предположим, что у нас есть 3 ноды, расположенных в разных датацентрах. Мы пишем на кворум из 2-х нод, при этом 1 нода может прилечь без потери живучести и консистентности всей системы. А читаем мы всегда из 2-х любых нод. При этом если одна нода прилегла, то другая нода даст правильный ответ. Если придет 2 разных ответа, то мы можем выбрать наиболее свежий. Таким образом, если в этой системе гарантируется, что только одна нода может быть неработоспособна в любой промежуток времени, то система будет с точки зрения клиента полностью 100% доступна как на чтение, так и на запись. Причем консистентно.
В реальности всегда существует ненулевая вероятность того, что приляжет не одна, а 2 или более нод. В этом легко убедиться, т.к. если есть ненулевая вероятность падения одной ноды, значит будет и ненулевая вероятность падения другой ноды или нод. Более того, падение — это не самое плохое, что может случиться. Помимо отказов оборудования, может еще быть потеря связности, т.е. поломка разнообразного сетевого оборудования, включая магистральное оборудование. Я думаю, не стоит напоминать о том, что все это имеет ненулевую вероятность. Все эти вероятности складываются, давая лишь некоторое, иногда очень малое, количество девяток. Понятно, что чем больше резервирование узлов, тем большее количество девяток можно получить. И это я еще не принял в рассмотрение саму программу, которую пишут программисты с ненулевой вероятностью внесения ошибки...
Т.е. в теории мы имеем, что правильно написанный клиент может добиться 100% доступности, а на практике мы всегда имеем меньшее число. Вся наука состоит в том, чтобы добиться как можно большего количества девяток. И в этом аспекте CAP теорема полностью бесполезна. Потому что она вообще про другое.
Поэтому идея а высокой доступности нисколько не противоречит тому, что это не A, а значит CP может быть высокодоступной.
Миф 6: системы CP обладают низкой производительностью, высокой латентностью и плохо масштабируются
Очевидно, что чем более высокий уровень консистентности, тем менее производительна система. Вопрос возникает в том, насколько будет просадка в производительности и будет ли она являться критичной для наших процессов.
Оказывается, что даже strict consistency или Strong-1SR (самый высокий уровень консистентности) возможно использовать в системах реального времени. У меня есть экспериментальное доказательство этого факта, но тут я приведу ряд некоторых практичных аргументов в пользу него.
Идея заключается в том, чтобы использовать множество независимых отказоустойчивых сущностей. Их можно запускать где угодно, они работают параллельно, а их количество фактически ограничено размером кластера. Поверх этих сущностей создается транзакционный слой, который связывает работу этих сущностей воедино. Именно так работает Spanner и многие другие системы. Таким образом достигается масштабируемость и быстродействие.
Миф 7: системы AP легко использовать за счет того, что они хорошо масштабируются
Системы с AP допускают более простое масштабирование, однако только в теории. В реальности все равно в той или иной степени приходится решать вопросы консистентности. Практика показывает, что написать клиентский код на основе такой системы — задача крайне нетривиальная, а иногда и вообще недостижимая. Причина в том, что если система не предоставляют каких-то базовых гарантий по консистентному хранению данных, то последующая обработка превращается в очень увлекательную шараду: применилась ли операция? увидят ли ее пользователи? а что они увидят? можно ли получить консистентный срез данных? будут ли видеть разные клиенты одинаковый набор данных? и т.д.
Т.е. не смотря на относительную простоту создания таких систем, сложность её использования возрастает многократно.
Разбор статьи
Ну а теперь приступим к разбору статьи Spanner, TrueTime & The CAP Theorem. Первое, на что стоит обратить внимание:
The CAP theorem [Bre12] says that you can only have two of the three desirable properties of:
- C: Consistency, which we can think of as serializability for this discussion;
- A: 100% availability, for both reads and updates;
- P: tolerance to network partitions.
Первое, на что стоит обратить внимание — ссылка [Bre12] под названием CAP Twelve Years Later: How the "Rules" Have Changed, датированной маем 2012 года. Почему выбрали ссылку не на оригинальную статью — мне неведомо. Более того, это статья про обсуждение CAP теоремы, а не про вывод самой теоремы.
Про буквы C, A и P мы уже обсуждали, не буду останавливаться. Далее:
Once you believe that partitions are inevitable, any distributed system must be prepared to forfeit either consistency (AP) or availability (CP), which is not a choice anyone wants to make.
Первая часть звучит вполне разумно в рамках наших обсуждений, однако после AP & CP следует странное, т.к. внезапно оказывается, мы не хотим делать такой выбор. Почему мы не хотим делать такой выбор, в статье не написано. Зато потом написаны правильные слова:
The actual theorem is about 100% availability, while the interesting discussion here is about the tradeoffs involved for realistic high availability.
Казалось бы, на этом можно было бы остановиться и сказать, что Spanner — это система CP с доступностью 99.9...%, поставив на этом точку. Но нет, автора дальше несет и он пишет подзаголовок:
Spanner claims to be consistent and available.
Spanner claims to be consistent and highly available, which implies there are no partitions and thus many are skeptical.
Как я показывал выше, так называемая высокодоступность (highly available) вовсе не означает A, и тем более не означает отсутствие P. После этого начинается словесная эквилибристика, т.к. из ошибочного посыла можно вывести множество забавных суждений. Автору очень хочется, чтобы система была и C и A одновременно, ведь P пользователю не нужно от слова совсем. При этом вводится новое понятие: effectively CA. Такое ощущение, что автор заигрался с понятиями и начал выдумывать новые без какого-либо определения, т.к. старые плохо описывали такую замечательную систему.
Читаем далее:
Based on a large number of internal users of Spanner, we know that they assume Spanner is highly available.
Сама по себе фраза замечательна. Оказывается, что если внутренние пользователи скажут: "мы предполагаем, что она высокодоступна", то отсюда сразу что-то следует о самой системе. Ладно бы, если бы пользователи заявляли: "да, она высокодоступна", тут же вообще про то, что они лишь предполагают.
Далее следует феерическое:
If the primary causes of Spanner outages are not partitions, then CA is in some sense more accurate.
Т.е. если у нас происходит сбой, не связанный с нарушением сетевой связности, то тогда такую систему более точно в некотором смысле (!) стоит называть как CA. Т.е. если вероятность других сбоев больше, чем нарушение связности, то P нет. В таком смысле стоит понимать эту фразу?
Далее приводятся маркетинговые измышления, что мы построили сверхнадежную систему, подтверждаемые графиками. Чуть ниже наконец-то приводится определение, раскрывающее значение совокупности слов effectively CA:
… to claim effectively CA a system must be in this state of relative probabilities:
- At a minimum it must have very high availability in practice (so that users can ignore exceptions), and
- as this is about partitions it should also have a low fraction of those outages due to partitions.
Spanner meets both.
Т.е. система должна:
- иметь high availability на практике, причем пользователи могут игнорировать исключения, и
- вероятность сетевого разделения должна быть меньше других проблем.
Сразу возникает вопрос: а каков уровень high availability достаточен на практике? 5 девяток? 6 девяток? А может все 9? Тут виден некоторый произвол, не позволяющий однозначно судить о принадлежности к этому свойству. Ну и "игнорирование пользователем исключений" довершает всю двусмысленность и неоднозначность этого, страшно сказать, определения.
Как видно, такое определение не подпадает под модель, которая используется непосредственно в CAP теореме. Тут вообще непонятно, к какой модели это относится. Это скорее про экспериментальные наблюдения, а не про теоретическую модель. И связи между экспериментом и теорией в статье не прослеживается.
Не буду долго расписывать другие аспекты статьи. Скажу лишь, что ряд абзацев вполне заслуживает того, чтобы их почитать, например "What happens during a Partition".
Заканчивают авторы следующим великолепным пассажем:
Spanner reasonably claims to be an “effectively CA” system despite operating over a wide area, as it is always consistent and achieves greater than 5 9s availability.
Ну да, если мы определим, что наша система — это X, то наша система будет обладать свойствами X. Здорово, правда? Только никакого отношения такое определение к CAP теореме не имеет. Это надо четко осознавать. Авторам, видимо, ну очень хотелось, чтобы не было P, а были 2 другие буквы, т.к. пользователь именно за них и платит. Почему их не устроило CP с высокой доступностью — мне неведомо.
Even then outages will occur, in which case Spanner chooses consistency over availability.
Что явно противоречит системе CA: в такой системе не делается никакого выбора, т.к. выбираются оба свойства, как мы это видели выше в примере с CA. Наличие такого утверждения говорит как раз о том, что это точно не CA. Не ожидал я увидеть взаимоисключающие параграфы в такой статье.
Миф последний: CAP теорема устарела
Популярность этой темы привело к тому, что многие перестали понимать значения терминов, они стали размываться, выхолащиваясь до совсем уже вульгарного понимания. Спекуляция на терминах, переопределение и непонимание — вот неполный перечень родовых пятен этой многострадальной теоремы.
На волне популярности маятник качнулся в другую сторону, и про эту теорему стали немножко забывать. Стали появляться статьи про то, что, дескать, CAP теорема устарела и просят остановить её использование. Другие пытались покритиковать и внести свою лепту в закапывание и переиначивание смыслов. Даже сам автор теоремы начинает подменять понятия и искажать первоначальный замысел.
Подобные выпады в сторону теоремы снова и снова лишь подчеркивают её актуальность, обнажая новые, доселе неизвестные, грани.
Заключение
В свое время, знакомство с CAP теоремой достаточно хорошо протрезвляло мозги. Ведь теоретическая невозможность создания определенного вида систем давала основания для того, чтобы не заниматься на практике решением неразрешимых задач и концентрироваться на решении задач определенного класса. В контексте распределенных систем имеет смысл говорить лишь о задачах AP или CP.
Подобного рода теоремы не устаревают, как не может устареть классическая механика, несмотря на наличие релятивистских эффектов или квантовой механики. Просто она должна найти свое достойное место, надо о ней помнить и идти дальше. А все дело в том, что эта теорема является лишь частным случаем более общего фундаментального свойства:
The CAP Theorem, in this light, is simply one example of the fundamental fact that you cannot achieve both safety and liveness in an unreliable distributed system.
Т.е. CAP теорема — это просто один из примеров фундаментального факта, что невозможно достичь одновременно безопасности и живучести в ненадежной распределенной системе.
- C: Безопасность
- A: Живучесть
- P: Ненадежная распределенная система
Григорий Демченко, разработчик YT
Chain Replication metadata management in Machi, an immutable file store
Spanner, TrueTime & The CAP Theorem
Brewer’s Conjecture and the Feasibility of Consistent, Available, Partition-Tolerant Web
Jepsen: Percona XtraDB Cluster
Consistency in Non-Transactional Distributed Storage Systems
Survey on consistency conditions
Highly Available Transactions: Virtues and Limitations (Extended Version)
Spanner: Google’s Globally-Distributed Database
CAP Twelve Years Later: How the "Rules" Have Changed
Забудьте САР теорему как более не актуальную
Please stop calling databases CP or AP
Perspectives on the CAP Theorem
Комментарии (69)
Suvitruf
21.02.2017 12:31Про 2 пункт (P) странные выводы:
Таким образом, если мы рассматриваем систему, которая работает с реальной ненадежной сетью, то нарушения сетевой связности — это не исключительная ситуация, а то, с чем приходится иметь дело. И буква P в данном контексте всего лишь означает, что в системе возможно нарушение сетевой связности.
P тут означает не то, что расщепление возможно (ведь если в системе более 1 ноды, взаимодействующих по сети, то этой ситуации не избежать), а то, что система продолжит функционировать.
gridem
21.02.2017 13:05-2Продолжит или нет функционировать система — вопрос к алгоритму, а не к системе. С точки зрения системы — ей все равно, что там продолжит или не продолжит работать.
Буква P относится к системе. Про это в статье подробно разжевано. Иначе получится, что если система CP, то в случае пропадания majority система перестанет функционировать, т.е. P внезапно пропадет. Противоречие.
Suvitruf
21.02.2017 13:08Так я и не говорил, что P относится к алгоритму. Если система заявлена как CP, то она должна справляться с расщеплением. А каким алгоритмом это достигается — вторично.
gridem
21.02.2017 13:11Что означает "справляться с расщеплением"?
Suvitruf
21.02.2017 13:13Продолжит функционировать в том или ином виде.
gridem
21.02.2017 13:21Поясню свой вопрос.
Предположим у нас система CP. В таком случае разумно предполагать, что справиться с расщеплением — означает сохранение консистентности.
Если же система AP, то тогда справиться с расщеплением — это обеспечить полную доступность.
Уже видно, что определение "справиться с расщеплением" плавает и зависит от того, что мы в итоге хотим получить. Но довершает всю абсурдность ситуации то, что есть системы просто P. Что тогда означает "справиться с расщеплением"? Непонятно.
Пример системы с P: Jepsen: MongoDB 2.4.3 stale reads
Suvitruf
21.02.2017 13:27Хм. Может и у меня каша в голове из этих мифов. По CAP столько разной противоречащей друг другу информации, что уже и не знаешь, как на самом деле.
Предположим у нас система CP. В таком случае разумно предполагать, что справиться с расщеплением — означает сохранение консистентности
Для меня всегда P в контексте системы означало, что при разделении части по обе стороны продолжат работать. Для клиента в этом кейсе, по сути, ничего не поменялось. Но в таком случае рассинхрон данных будет и поддерживать консистентность кластера в целом не видится возможным.
asm0dey
02.03.2017 22:26Это вы AP описали. Если, например, только majority продолжило работать — тогда оно CP. Потому что ноды в minority работают, но отвечать отказываются.
Ravager
21.02.2017 14:27P — система продолжает функционировать при netsplit.
функционировать — обеспечивать выполнение других требований.
Если нет требований C и A то функционирование лишь умозрительное, заключаещеся в том, что процесс просто не упал на нодеgridem
21.02.2017 14:37Осталось лишь сделать следующий шаг. Вот зачем знание о том, что система продолжает функционировать? Ведь другие буквы как раз и будут говорить, как конкретно она будет функционировать. Зачем это знание еще раз дублировать в P, причем неявным способом?
Мне это совершенно непонятно.
Suvitruf
21.02.2017 14:41Потому что не всегда знание о C, к примеру, вообще нужно. Если я использую БД для аналитики или статистики, мне важно, чтоб оно не падало, а то что там не консистентные данные будут — не критично.
gridem
21.02.2017 14:45Ну так тогда и стоит говорить: мне нужна система AP. Пока не вижу противоречий с тем, что я выше написал.
Ravager
21.02.2017 14:48P имеет смысл при наличии других требований в виде C или А.
более того это явное требование к системе — функционировать при netsplit. вы можете построить C систему а можете построить CP систему. и это разные вещи, и P нельзя не принимать во вниманиеgridem
21.02.2017 15:02P имеет смысл при наличии других требований в виде C или А.
Это откуда следует? В моей статье такого нет. Мы что обсуждаем? Для конкретности хочется иметь под рукой какие-нибудь ссылки.
более того это явное требование к системе — функционировать при netsplit
А это вообще к чему? Откуда берется это "явное требование к системе"? Тут явно нужен какой-то контекст, и я не могу его извлечь из данных суждений.
Ravager
21.02.2017 16:00ссылки на что, на чье-то авторитетное мнение?
это следует из-того что определение «система функционирует» слишком абстрактно и без других требований или уточнений совершенно непонятно. P здесь это возможность выполнениях других требований в условиях netsplit
ik62
21.02.2017 15:42+1Имхо тут проблема с человеческим языком.
В статье Гилберта и Линч говорится следующее (http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.6951&rep=rep1&type=pdf) —
2.3 Partition Tolerance
The above definitions of availability and atomicity are qualified by the need
to tolerate partitions. In order to model partition tolerance, the network
will be allowed to lose arbitrarily many messages sent from one node to
another. When a network is partitioned, all messages sent from nodes in
one component of the partition to nodes in another component are lost.
Речь тут о том, что сети разрешается терять сообщения. Точка. То есть это действительно свойство сети, а не системы и не алгоритма и tolerance означает что мы разрешем/терпим такое свойство сети, а не о каких-то гарантиях для этой ситуации.
vintage
22.02.2017 00:02Теорема не устарела, она никогда и не была актуальной, так как оперирует понятиями, совершенно не важными на практике. Именно поэтому её никогда не было смысла использовать. Славно, что это начали понимать.
sumerman
22.02.2017 03:23+2То-то в кластере, обслуживающем десятки терабайт данных, при условии отсуствия сети «как у гугла» актуальность теоремы видно «невооружённым глазом».
vintage
22.02.2017 09:04Не расскажете про свои наблюдения?
sumerman
22.02.2017 12:40Примерно как тут https://aphyr.com/posts/324-call-me-maybe-aerospike к сожалению не могу подробнее. При этом кластер на постгресе (в котором данных даже больше) потерей данных не страдает. (Там есть другие сложности конечно же, но не потеря данных)
tangro
22.02.2017 11:56CAP-теорема — интересное логическое представление, утверждающее что «идеал не достижим». Ну ок. При этом вполне себе могут появиться системы, которые каждую из составляющих CAP на практике доведут до 99.9...(тут 100 девяток)%, чего на практике (в масштабах нашей планеты, человеческой жизни и других практических вещей) будет абсолютно достаточно для того, чтобы считать систему полностью CAP. Да, мудрые математики в своих кабинетах будут рассказывать, что это не правда — но кого это будет волновать?
Spanner — просто ещё один шажок к такой системе, хороший, но далеко не последний.sumerman
22.02.2017 12:37+2Когда consistency начинают в процентах, то случается монга или аэроспайк. На неоктором масштабе /dev/null куда как лучше
tangro
22.02.2017 13:16Что плохого в consistency в процентах? Допустим система даст гарантию, что данные будут консистенты в 99.9(100 девяток)% случаев и консистентность на практике нарушится впервые где-то уже после термодинамической смерти Вселенной. Я думаю, такой системой вполне можно пользоваться.
oxidmod
22.02.2017 13:27+1Вся беда вероятностей отличных от единицы в том, что чихать они хотели на проценты. Исобытие с вероятностью в 0,00(сто нолей)1 вполне может случиться завтра
gridem
22.02.2017 14:54+1Что плохого в consistency в процентах? Допустим система даст гарантию, что данные будут консистенты в 99.9(100 девяток)%
Такой можно пользоваться, конечно. Только как её получить? У вас есть готовые рецепты?
Очень похоже на то, что такое утверждение не очень далеко ушло от "логических представлений".
И как верно заметили выше, стрельнуть может в любую секунду. Одно дело, если у вас логи, другое — если баланс на карте. Сможете продать такую систему банку? Я почему-то сильно сомневаюсь.
tangro
22.02.2017 15:24Ну, стрельнет, и что? Те же банки пользуются кучей систем, надёжность которых не достигает 100%. Вообще трудно себе представить себе что-то, надёжное ровно на 100%. С какой-то степени вероятности система уже применима на практике. Да к любому прибору, даже критически важному, прилагается метрологическая справка насколько он точен и каковы его погрешности — и ни в одном таком документе 0% погрешности не написано.
gridem
22.02.2017 15:29+1Тут опять возникла путаница.
Не стоит путать надежность и консистентность. Надежность никогда не будет 100%, однако алгоритм должен быть на 100% консистентен. Пример: raft consensus.
Стоит внимательней относиться к используемому словарю.
asm0dey
02.03.2017 22:28монга прошла джепсен-тест. Транзакционности там нет, но с консистентностью уже всё ок.
sumerman
02.03.2017 23:22Да, я знаю, молодцы, что починили. Выше речь всё таки о том, что когда консистентность «на глазок», то ничего хорошего выйти не может. Монга до недавнего времени и аэроспайк хорошие кмк примеры.
asm0dey
02.03.2017 23:52Есть такие ребята как GetIntent — им норм с аэроспайком. Ну то есть потеряли — ок. Но обычно не теряем и рубим на этом денег.
sumerman
02.03.2017 23:55У нас похожая история. Я не говорю же, что аэроспайк не годен ни на что, я утверждаю, что 1) их маркетинг расходится с реальностью 2) консистентность «на глазок» это её отсуствие.
asm0dey
03.03.2017 00:04Очевидно, да. Оч хочется посмотреть на джепсен-тест аранги. Они всё обещают доточиться.
sufferingluck
22.02.2017 14:55Нужно написать очень много букв, чтобы опровергнуть очевидное несоответствие, и тем больше, чем оно очевиднее. Потому лишь кратко упомяну, что если мы будем следовать выводу автора о невозможности построения живучей и безопасной системы, обладающей свойствами распределенности, то ни одна из действующих больших сложных технических систем не должна была бы существовать. Они существуют. Да, они не надежны на 100%, но этого никто и не требует. Да, они не живучи на 100%, но и этого никто не требует. Достаточно грамотно построенной поддержки жизненного цикла. То же самое относится и к распределенным сетям, вычислительным или иным.
4dmonster
22.02.2017 17:56Так ведь CAP абсолютна. Как только за любую букву вы прячете не 100% а чуть меньше, так сразу система становится возможной, но теорема уже будет не применимой.
kmu1990
22.02.2017 18:59При этом вводится новое понятие: effectively CA. Такое ощущение, что автор заигрался с понятиями и начал выдумывать новые без какого-либо определения, т.к. старые плохо описывали такую замечательную систему.
Я вот прочитал статью, и не увидел, чтобы там вводили такое понятие. Там используется фраза «effectively CA», но в кавычках и только после того, как прямым текстом сказано, что с точки зрения CAP теоремы Spanner — CP. А после этого идут долгие и упорные диферамбы Google и Spanner, в которых рассказывается как же они делают Partition-ы маловероятными, а если уж они происходят, то как уменьшить их влияние.gridem
23.02.2017 00:59Там используется фраза «effectively CA», но в кавычках и только после того, как прямым текстом сказано, что с точки зрения CAP теоремы Spanner — CP
А зачем тогда писать «effectively CA», если к CAP теореме это не имеет отношения?
kmu1990
23.02.2017 08:53А разве каждое использование букв C и A обязательно должно иметь отношение к CAP теореме? В статьте объясняется, что в effectively CA означают C и A: C — означает консистентность как в CAP теореме, а A означает высокую доступность с 5-ю 9-ами, а не ту доступность, о которой идет речь в CAP теореме. И в статье это прямым текстом написано, так что я не понимаю, почему вы меня об этом прашиваете?
gridem
23.02.2017 10:37А разве каждое использование букв C и A обязательно должно иметь отношение к CAP теореме?
А разве в статье под заголовком "Spanner, TrueTime & The CAP Theorem." должно быть по-другому? Ну с учетом того, что многие люди, судя по комментариям, не знают определений. По-моему, явное использования других смыслов с мутным описанием — явный признак манипуляции.
kmu1990
23.02.2017 10:53Нет не должно, если один из пунктов статьи показать, что кроме A в терминах CAP теоремы, есть и другие «A» и что не нужно всегда подразумевать под A именно тот смысл, который в него вкладывает CAP теорема, тем более что он не отличается практичностью.
То, что многие люди чего-то не знают, не делает статьи, которые описывают вещи, которые эти многие люди не знают, неправдивыми или вводящими в заблуждение. С точки введения в заблуждение, я считаю ваши претензии не оправданными, так как автор прямым текстом написал, что он имеет ввиду под A в effectively CA, и обратил внимание на то, что это не то же самое A, что и в CAP теореме, более того сделал это на самой первой старнице.gridem
23.02.2017 11:01Хорошо, объясните тогда следующий факт. Если A — это не A CAP теоремы, то почему бы тогда не назвать "effectively CAP", ведь есть все 3 буквы в наличии. Зачем потребовалось еще P переобозначать? Тем более, что явного переопределения буквы P в тексте нет.
kmu1990
23.02.2017 11:17Если A — это не A CAP теоремы, то почему бы тогда не назвать «effectively CAP», ведь есть все 3 буквы в наличии.
Где вы в этом предложении увидели факт и какой именно? Я вот вижу, только как вы пытаетесь угадать коварные планы автора (ключевой момент — ваша попытка гадать, чтобы вы потом не кидались в меня помидорами за то, что я выдрал цитату из контекста).
Зачем потребовалось еще P переобозначать?
Будьте конкретны, где и как автор переобозначил P?
Если вы хотите продолжать спор на основе ваших догадок о коварных планах автора, то делайте это без меня. Я, как вы могли заметить, придерживался выше исключительно текста статьи, и показал, что в статье автор прямым текстом говорит, что Spanner, строго формально, с точки зрения CAP теоремы — CP. При этом автор не зашифровал это сообщение, не спрятал его в сноску мелким шрифтом или еще что-то подобное. После этого автор указал, что Availability не должна ограничивается тем смыслом, который в него вкладывает CAP теорема, и, оказывается, есть жизнь и за пределами CAP теоремы. И только после этого пошел обсуждать как там космические корабли что-то бороздяд…
gridem
23.02.2017 18:15Где вы в этом предложении увидели факт и какой именно?
Факт в том, что было названо не "effectively CAP", а "effectively CA". Хочется услышать все-таки ответ на свой вопрос: почему в статье не назвали "effectively CAP"?
kmu1990
23.02.2017 20:00А почему вам не спросить об этом автора статьи? Еще раз повторяю, я не играю в угадайку — я не знаю, о чем думал автор статьи и не собираюсь гадать на эту тему, но я умею читать и понимаю прочитанное. Почему автор не написал CAP вместо CA — это гадание, то что автор написал CA и объяснил, что он имеет под этим ввиду (и что это не CA в терминах CAP теоремы) — это факт.
gridem
23.02.2017 21:19Я задаю эти вопросы в надежде, что вы увидите в рассуждениях автора статьи изъян. Но, судя по всему, вы его видеть в упор не хотите. Ваше право.
Вот давайте разберем ваши комментарии в качестве примера уровня дискуссии.
Я вот прочитал статью, и не увидел, чтобы там вводили такое понятие.
А я вот прочитал и увидел. Сразу вспоминается фраза: "как это — "жопа" есть а слова нет?".
Там используется фраза «effectively CA»
Т.е. для вас, судя по всему, крайне принципиально, что это не понятие, а именно фраза. Это, безусловно, все в корне меняет, т.е. описывать, что означает фраза — не нужно. Ведь это не понятие, верно? А значит можно просто ее использовать, если очень хочется. Такая логика, да?
А разве каждое использование букв C и A обязательно должно иметь отношение к CAP теореме?
А разве нет? Ведь статья называется: "Spanner, TrueTime & The CAP Theorem". Все, кто использует просто отдельные буквы, используют её в контексте CAP теоремы. С этого и начинается статья. И если начать использовать по-другому назначению, то стоит явно указать, что мы эти буквы хотим переопределить, и стоит указать как именно. Ну это если ты хочешь, чтобы тебя поняли. А если не хочешь — то тогда можно писать как попало, все равно схавают. Тем более, прецедент имеется.
В статьте объясняется, что в effectively CA означают C и A: C — означает консистентность как в CAP теореме, а A означает высокую доступность с 5-ю 9-ами, а не ту доступность, о которой идет речь в CAP теореме. И в статье это прямым текстом написано.
И тут хочется спросить: а вы читали мою статью? Ну это где я обсуждал про то, сколько же девяток надо, чтобы называться A "по новому"? Или это не надо специфицировать, и так сойдет?
Для меня тут видится крайне очевидная штука: в рамках CAP теоремы система получается CP. Но тогда сразу возникает вопрос у обывателя: а как же высокая доступность? Чтобы утихомирить обывателя, ему объясняется, что на самом деле доступность — это доступность в рамках девяток. И 5 девяток — это та самая доступность, когда можно сказать "effectively CA".
Разумный человек сразу спросит:
- а почему 5 девяток достаточно, а не 6 или 10?
- а куда делать буква P?
Меня, например, эти вопросы крайне волнуют. А еще волнует вопрос: а с какого перепугу надо переопределять понятия в CAP теореме? Ведь она сформулирована только для определенных понятий, для других понятий нет смысла говорить о CAP теореме. Надо что-то выбрать одно: либо про теорему, либо про другое. Если же совмещать все вместе, то сразу возникает вопрос: а зачем? И это тот вопрос, который меня мучал на протяжении всей статьи? Ведь если убрать ссылку на CAP теорему и связанное с ней обсуждение, то ничего в статье не поменяется.
И я еще не сказал, что автор просто привел неправильные определения, даже в рамках CAP теоремы.
Если вам нравятся такие статьи — на здоровье. Я хочу сказать лишь следующее. В контексте обсуждений CAP теоремы ходят множество мифов. Как правило, все они связаны с неверным толкованием определений. Добавлять в обсуждение новые толкования без нормального объяснения старых — занятие крайне странное и недальновидное, которое может неподготовленного читателя ввести в заблуждение.
Я лишь попытался обнажить некоторые аспекты, связанные с этой теоремой, на основе современных представлений. И к своему прискорбию могу сообщить, что ни один комментарий не был конструктивен, за исключением этого. Т.е. была приведена правильная ссылка и цитата, из которой был сделан вывод. Все остальное — это толчение в ступе собственных мыслей без понимания простого факта: утверждение должно иметь основу.
kmu1990
23.02.2017 22:23Я задаю эти вопросы в надежде, что вы увидите в рассуждениях автора статьи изъян. Но, судя по всему, вы его видеть в упор не хотите. Ваше право.
А я вам указываю на то, что ваши вопросы — это гадание, но вас это не интересует — вам нравится гадать.
Т.е. для вас, судя по всему, крайне принципиально, что это не понятие, а именно фраза. Это, безусловно, все в корне меняет, т.е. описывать, что означает фраза — не нужно. Ведь это не понятие, верно? А значит можно просто ее использовать, если очень хочется. Такая логика, да?
Нет, не такая. Ваши слова:
Почему их не устроило CP с высокой доступностью — мне неведомо.
При этом вводится новое понятие: effectively CA.
Я вам, просто, указал, на то, что авторов вполне устраивает называть Spanner CP в терминах CAP теоремы (цитату я вам привел, вы, просто, ее почему-то игнорируете) и никакого нового понятия они не вводят, никакой новой модели не определяют. А effectively CA используют объяснив, что они подразумевают под effectively, C и A, уж не говоря о том, что effectively CA взято в кавычки (явный признак того, что слова используются не в их обычном смысле). Т. е. авторы подчеркивают всеми доступными грамматическими средствами + прямым указанием в тексте, что CA в данном контексте не является CA в терминах CAP теоремы, а Spanner в терминах CAP теоремы является CP системой.
И тут хочется спросить: а вы читали мою статью? Ну это где я обсуждал про то, сколько же девяток надо, чтобы называться A «по новому»? Или это не надо специфицировать, и так сойдет?
Я то читал, а вы мои комментарии читали? Еще раз повторю, авторы объяснили, что они имеют ввиду под A, и прямым текстом написали, что это не A в терминах CAP теоремы. Такое употребление слова availability имеет право на существование, потому как слово availability — это не слово, которое за пределами CAP теоремы не имеет смысла или никогда не используется.
Разумный человек сразу спросит:
Я эти вопросы никоим образом не считаю бессмысленными. Если вам эти вопросы интересны — задайте их автору статьи, а не кидайтесь на него за то, что он не ответил на все мыслимые и немыслимые вопросы в короткой записке. Автор статьи рассказывает, что для использования внутри Google-а, им такого количества 9-ок достаточно, чтобы пользователи Spanner-а не задумывались о возможных отказах сервиса. Того, что этого достаточно всем, на сколько я вижу, в статье не утверждается.
1. а почему 5 девяток достаточно, а не 6 или 10?
2. а куда делать буква P?
Меня, например, эти вопросы крайне волнуют.
Более того, касательно исчезнувшей P. В статье этому посвящен целый раздел. Где говорится, что на самом деле, строго формально, P никуда не исчезла, и более того эта самая P реально происходила на практике. НО благодаря их героическим усилиям и куче вложенных в инфраструктуру бабок, вероятность этого P настолько низкая, что на фоне всех других ошибок она не выделяется. Подчеркну, в статье сначала прямым текстом говорится, что P есть, а потом уже автор идет в пространные обсуждения о влиянии этого самого P.
А еще волнует вопрос: а с какого перепугу надо переопределять понятия в CAP теореме?
Повторюсь еще раз, авторы не переопределяли понятия CAP теоремы, а прямым текстом указали на то, что они не используют понятия CAP теоремы. Так уж сложилось, что слова availability и consistency — перегруженные слова, они имеют очень много смыслов, и это не вина автора статьи — так сложилось за долго до того, как вышла статья. Более того на сколько я вижу, автор приложил все усилия к тому, чтобы availability и consistency в терминах CAP теоремы не спутали с тем, о чем он говорит большую часть статьи.
Ведь она сформулирована только для определенных понятий, для других понятий нет смысла говорить о CAP теореме.
Автор говорит, что есть CAP теорема, в которой availability имеет строго определенный смысл. А потом говорит, что есть вообще-то еще и high availability, которая не подпадает под определения CAP теоремы, но важна с практической точки зрения (т. е. говорит то же самое что и вы — когда речь идет о high availability, то это уже не подпадает под влияние CAP теоремы). Одно из утверждений статьи, как раз заключается в том, что кроме мира CAP теоремы с ее понятиями C, A и P, имеет смысл рассматрвать availability и по-другому. Вы оспариваете, то что оценка количества девяток для практического использования имеет смысл? Или вы просто по религиозным соображениям запрещаете обсуждать high availability с ее девятками и availability в терминах CAP теоремы в одной статье (даже при условии, что статья четко разделяет эти смыслы и явно указывает, где и какой используется)?gridem
23.02.2017 22:51Более того, касательно исчезнувшей P. В статье этому посвящен целый раздел. Где говорится, что на самом деле, строго формально, P никуда не исчезла, и более того эта самая P реально происходила на практике. НО благодаря их героическим усилиям и куче вложенных в инфраструктуру бабок, вероятность этого P настолько низкая, что на фоне всех других ошибок она не выделяется. Подчеркну, в статье сначала прямым текстом говорится, что P есть, а потом уже автор идет в пространные обсуждения о влиянии этого самого P.
Если я правильно истолковал ваши слова, то она вроде как есть, но вроде как и нет. Т.е. она должна быть, но ее нет. Не находите это несколько странным? Это вопрос к вам.
Вы оспариваете, то что оценка количества девяток для практического использования имеет смысл?
Нет. Я оспариваю качество определений, вводимые в статье. И как следствие, качество самой статьи.
Для конструктивного общения было бы неплохо, чтобы каждое высказывание типа "Автор статьи рассказывает, что ...", "Автор говорит, что" и т.д. были бы приведены прямые цитаты, доказывающие эти тезисы. Так как большинство таких тезисов спорно.
kmu1990
23.02.2017 23:01Если я правильно истолковал ваши слова, то она вроде как есть, но вроде как и нет. Т.е. она должна быть, но ее нет. Не находите это несколько странным? Это вопрос к вам.
Нет, не правильно. Нет, не нахожу. Прямым текстом в статье говорится, что P есть точка. Подтверждаю цитатой:
The purist answer is “no” because partitions can happen and in fact have happened at Google, and during
(some) partitions, Spanner chooses C and forfeits A. It is technically a CP system. We explore the impact
of partitions below.
Нет. Я оспариваю качество определений, вводимые в статье. И как следствие, качество самой статьи.
До сих пор вы, более или менее, оспаривали определение Availability. В статье говорится что они подразумевают под Availability 5 девяток и больше — конкретное численное значение, вам оно может не нравится, вам может быть не достаточно 5 девяток, но определили для целей статьи они Availability вполне конкретно и не двусмысленно. Итого: считаю претензии к качеству необоснованными.
Для конструктивного общения было бы неплохо, чтобы каждое высказывание типа «Автор статьи рассказывает, что ...», «Автор говорит, что» и т.д. были бы приведены прямые цитаты, доказывающие эти тезисы. Так как большинство таких тезисов спорно.
Для конструктивного общения было бы полезно, если бы вы указали, какие тезисы выглядят спорно, чтобы я мог их защищать.gridem
03.03.2017 13:52Нет, не правильно. Нет, не нахожу. Прямым текстом в статье говорится, что P есть точка.
У вас проблемы с удержанием контекста. Речь про "effective AC", в этой фразе нет P, хотя она должна быть, согласно определениям.
Для конструктивного общения было бы полезно, если бы вы указали, какие тезисы выглядят спорно, чтобы я мог их защищать.
Это работает в другую сторону. Тот, кто приводит аргументацию, её и подкрепляет. Например, я в своей статье сначала привожу дословную цитату, а затем начинаю её разбирать.
Если же приписывать статье всякое без ссылок — то это очень странный способ вести дискуссию.
kmu1990
03.03.2017 14:17У вас проблемы с удержанием контекста. Речь про «effective AC», в этой фразе нет P, хотя она должна быть, согласно определениям.
Это у вас проблемы с удержанием контекста, или памятью, или чтением, или не знаю еще с чем… Потому как я вам уже несколько раз упоминал, что «effectively CA» не использует термины CAP-теоремы. Вы цитат подтверждающих свою позицию не привели, а я привел.
Это работает в другую сторону. Тот, кто приводит аргументацию, её и подкрепляет. Например, я в своей статье сначала привожу дословную цитату, а затем начинаю её разбирать.
Если же приписывать статье всякое без ссылок — то это очень странный способ вести дискуссию.
1. Я отказывался подкреплять аргументацию? Нет я попросил вас указать, подкрепления каких именно утверждений вы хотите услышать. Вам стоит быть внимательнее, чтобы не начать оспаривать утверждения, которых я не делал (как вы уже это делали относительно стаьти).
2. Советую вам воспользоваться вашим же советом и перестать гадать, а начать приводить цитаты из статьи. Начните с цитаты, которая подвердит, что «effectively CA» и использует определения CAP-теоремы, чтобы ваши доводы о необходимости P, согласно определениям CAP-теоремы, имели разумное подкрепление в статье.gridem
03.03.2017 15:16«effectively CA» не использует термины CAP-теоремы.
Допустим. Не могли бы вы привести тогда:
- Прямую цитату, подтверждающую ваши слова о том, что они не используют термины CAP-теоремы.
- Цитату, где бы определялось понятие «effectively CA», т.е. раскрывался бы ясный смысл букв C и A, используемые в понятии.
kmu1990
03.03.2017 15:371. Утверждение, что Spanner CP с точки зрения CAP-теоремы, и значит не CA с точки зрения CAP-теоремы:
The purist answer is “no” because partitions can happen and in fact have happened at Google, and during (some) partitions, Spanner chooses C and forfeits A. It is technically a CP system.
2. Прямое утверждение, что под A не подразумевается тотальная доступность, а вместо этого имеется ввиду высокая доступность с каким-то там количеством девяток:
This does not imply 100% availability (and Spanner does not and will not provide it), but rather something like 5 or more “9s” (1 failure in 10^5 or less).
Теперь про цитату про определение «effectively CA», как я уже упоминал выше — это не определение, автор не вводит новых понятий. Но цитата выше явно указывает на то, что подразумевается под A. Конкретного указания на используемую модель консистентности нет, кроме того, что она строгая:
As with most ACID databases, Spanner uses two-phase commit (2PC) and strict two-phase locking to ensure isolation and strong consistency.
А слову effectively собственно посвящена большая часть статьи:
If its actual availability is so high that users can ignore outages, then Spanner can justify an “effectively CA” claim.
Далее автор рассказывает как достигается высокая доступность при наличии P, я не буду приводить конкретные цитаты, потому что этому посвящена большая часть статьи. Я приведу только тезисы, если вы не согласны с тем, что в статье присутсвует такой тезис, то укажите, я подберу цитаты из статьи:
1. P случаются, но редко, благодаря супер-пупер крутой Google-овой сети и наученным инженерам;
2. даже если P произошел, все еще можно обслуживать какие-то запросы, даже на стороне minority;
3. если произошел P, то есть вероятность, что сетевая инфраструктура так повреждена, что пользователь просто не может послать запрос;
4. статистика по инцидентам со Spanner-ом показывает, что проблемы с сетью не являются самым частым инцидентом при работе Spanner.gridem
03.03.2017 15:49-1Прямое утверждение, что под A не подразумевается тотальная доступность, а вместо этого имеется ввиду высокая доступность с каким-то там количеством девяток:
Изначальный ваш тезис был "«effectively CA» не использует термины CAP-теоремы". Мне не очень понятно, как он в конце концов свелся к изменению определения для A. Т.е. я не вижу утверждения о том, что буква C используется в другом контексте. Или С использует термин из CAP теоремы? Хочется тут большей определенности, т.е. все ли буквы в контексте «effectively CA» не используют термины CAP-теоремы или только некоторые?
Теперь про цитату про определение «effectively CA», как я уже упоминал выше — это не определение, автор не вводит новых понятий.
Для меня «effectively CA» — это новый термин, т.к. до этого я слышал CA в рамках CAP теоремы. Если мне теперь вводят нечто типа «effectively CA», то я хочу понимания, что означает C и A. Сюда по вашим цитатам, вы так и не смогли найти явного объяснения этих букв и привести соответствующую цитату, объясняющую, что означает буква C из «effectively CA».
kmu1990
03.03.2017 15:56-1Изначальный ваш тезис был "«effectively CA» не использует термины CAP-теоремы". Мне не очень понятно, как он в конце концов свелся к изменению определения для A. Т.е. я не вижу утверждения о том, что буква C используется в другом контексте. Или С использует термин из CAP теоремы? Хочется тут большей определенности, т.е. все ли буквы в контексте «effectively CA» не используют термины CAP-теоремы или только некоторые?
Ок, поясничайте дальше.
Для меня «effectively CA» — это новый термин, т.к. до этого я слышал CA в рамках CAP теоремы. Если мне теперь вводят нечто типа «effectively CA», то я хочу понимания, что означает C и A. Сюда по вашим цитатам, вы так и не смогли найти явного объяснения этих букв и привести соответствующую цитату, объясняющую, что означает буква C из «effectively CA».
Судя по всему, вам стоит для начала прочитать статью.
То что подразумевается под A было указано явно — цитату я вам привел. Под C подразумевается одна из форм строгой консистентности — цитату я вам привел. Про effectively я вам тоже цитату привел.
Но если вы хотите поясничать, а не вести конструктивную дискуссию — ваше право. Только я в этом участвовать не буду.
olku
То есть, по Вашему
C согласованность данных — состояние системы, когда действие внешних и внутренних факторов не приводит к ухудшению её функционирования.
A доступность — способность выполнять свои функции, несмотря на полученные повреждения.
P устойчивость к разделению — свойство выполнять свои функции во времени.
Статья хорошая, теоретический вывод — чушь. Извините.
gridem
Я не очень понял, откуда взяты эти определения. В моей статье их точно нет.
Извините.
olku
Из определений этих понятий, Википедия устроит? Зачем понадобилась подмена смыслов — непонятно.
gridem
А статью пробовали почитать? Говорят, иногда помогает.
olku
Ответ в первом комменте. Все чаще на Хабре появляется «научпоп», где авторам даже значения терминов лень посмотреть.
gridem
Вы написали:
Это не по моему, а по вашему. Я такие определения не давал.
Посмотреть в википедии? Вы это серьезно? Т.е. ссылки на серьезные научные публикации прошли мимо вас?
olku
разве не ваш вывод, подменящий один смысл терминов другим? Серьезная научная публикация. :))
gridem
Т.е. по вашему, если я скажу, что "Ту-154 — это самолет", то это будет подмена понятий?
Оригинально! Пишите еще.
olku
Недостаточно ясно? ОК, в Вашем выводе заменяем акронимы и термины их настоящими значениями. Получается чушь? Потому что она и есть. Впрочем, дисскуссия себя исчерпала. Статья, повторяю, хорошая, а выводы… как у «британских ученых» :)
gridem
Думаю, что стоит разъяснить подробнее, что имеется в виду.
Короткие и емкие определения:
Безопасность — плохое не происходит
Живучесть — хорошее происходит
Теперь попытаемся понять, что же такое консистентность? К чему её стоит отнести? Консистентность — это про сохранение внутренних инвариантов системы, т.е. плохое — это нарушение инварианта. Соответственно, его сохранение — это безопасность.
Что такое доступность? Это свойство системы отвечать на запросы. Если нет доступности, то система свои инварианты сохраняет, однако ничего полезного не делает. Поэтому доступность позволяет делать что-то хорошее, полезное. Следовательно, доступность — это свойство живучести системы.
Любые требования к распределенным алгоритмам можно отнести либо к живучести, либо к безопасности.
Как-то так.
serg_p
А в чём хорошая???? Как на меня каша из эмоций