Comments 77
В каких реальных приложениях допустимо это «Partition Tolerance»? В какой предметной области?
В бухгалтерии недопустимо, например. Если нет доступа к данным о предидущих платежах контрагентов то новые сделки регистрировать невозможно (вдруг он уже должен).
В бухгалтерии недопустимо, например. Если нет доступа к данным о предидущих платежах контрагентов то новые сделки регистрировать невозможно (вдруг он уже должен).
Тут даже вопрос о допустимости немного в другом смысле. А именно в том, случается он или нет. Т.е. жертвовать Partition Tolerance имеется ввиду, разделение системы (читайте отказы компонент) никогда не происходит. Если же это произошло, значит вы уже им не жертвуете а имеете, тогда остается выбрать еще только что-то одно: согласованность или доступность. Вот это для меня самый сложный логический момент, который, я честно говоря не до конца могу сформулировать.
в бухгалтерии этого просто нет. Такова предметная область. Нет доступа к части данных — работа невозможна, все идут на обед.
Это возможно, скажем, в твиттере. Ну отвалится часть пользователей, скажем, вся Южная Америка — ничего, остальные без них постить смогут. Если кому надо в юж.америку твиттить — подождут. Нет в твиттере чётких требований к доступности.
В большинстве реальных приложений это недопустимо.
Это возможно, скажем, в твиттере. Ну отвалится часть пользователей, скажем, вся Южная Америка — ничего, остальные без них постить смогут. Если кому надо в юж.америку твиттить — подождут. Нет в твиттере чётких требований к доступности.
В большинстве реальных приложений это недопустимо.
Нет доступа к части данных — работа невозможна < — а почему нет? Потому что свич сломался, например, и доступа к данным нет. Т.е. Partion случился. В этом случае вы выбираете CP и жертвуете A (avalability) и идете на обед. Т.е. при случившихся проблемах, вы решаете оставить согласованность, тем что прекращаете работать и отказываетесь от доступности. Это я и хотел описать.
я намекаю что это допустимо только в небольшом круге задач
Немного не понял, на что вы намекаете. Можно пожалуйста еще раз? :)
Я утверждаю, что невозможно написать распределенную систему, которая поддерживает в полной мере и Avalability и Consistency. В двух ваших примерах, нет avalability, так как есть промежуток времени, когда некоторые пользователи не могут работать с системой.
Я утверждаю, что невозможно написать распределенную систему, которая поддерживает в полной мере и Avalability и Consistency. В двух ваших примерах, нет avalability, так как есть промежуток времени, когда некоторые пользователи не могут работать с системой.
А например система совместной работы над документами вроде Google Docs. Упала скажем межконтинентальная связь, пользователи Европы работают над своими документами, Америки над своими. Avalability выполнено. Любые попытки пользователем с Европы закоммитить например ранее открытые документы которые лежат на серверах в Америке неудачны. Consistency выполнено. Partition Tolerance не выполнено.
Вот тут как раз и недопонимание формулировки («Partition Tolerance не выполнено»). Я не говорю, что Вы его недопонимаете. Я думаю, что я его недопонимаю. Но на сколько я понял, в вашем примере как раз Partition Tolerance присутствует, т.е. система работает при разрыве межконтинентальной связи. Так как Partition Tolerance присутствует, то возможно обеспечить только что-нибудь одно. В вашем примере — это согласованность. Отличный пример, подтверждающий мой топик :) Разве нет?
Давай скажем сразу, что если данные не дублируются между нодами в США и Европе, т.е. некоторые данные лежат только в США, некоторые только в Европе, то у нас в принципе не может быть PT и A — так как при потере связи между континентами, у нас для пользователей как Европы, так и США часть данных будет недоступно в принципе.
Поэтому, нам очевидно надо чтобы данные дублировались на нодах в США и Европе. Сеть падает. Дальше два варианта.
Либо пользователи из США и Европы независимо редактируют данные в своих сегментах, после восстановаления соединения между разными копиями идет конфликт, нужен мерж. Опять же, это то, что берет за основу модель, придуманная Амазоном в своей платформе Dynamo — BASE. Eventually consistent. Т.е., чуть упрощенно, мы делаем асинхронную репликацию изменений в копиях с отложенным разрешением конфликтов. Мы позволяем то, что в некоторые моменты времени данные в разных копиях НЕ консистентны.
Либо, мы говорим, что ради обеспечения немедленной и постоянной Consistency, все запросы на редактирование тех данных, которые имеют копии в разрозненных сегментах, блокируются до тех пор, пока соединение не восстановится. Т.е., у нас нет Availability. Это, как я понимаю, например, модель двухфазного коммита распределенных транзакций. Это то, как работает синхронная репликация (например, в БД Oracle и банкоматах — вам не закоммитят транзакцию и не отдадут деньги до тех пор, пока основной сервер БД и stand-by сервер(а) не подтвердят коммит транзакции).
Поэтому, нам очевидно надо чтобы данные дублировались на нодах в США и Европе. Сеть падает. Дальше два варианта.
Либо пользователи из США и Европы независимо редактируют данные в своих сегментах, после восстановаления соединения между разными копиями идет конфликт, нужен мерж. Опять же, это то, что берет за основу модель, придуманная Амазоном в своей платформе Dynamo — BASE. Eventually consistent. Т.е., чуть упрощенно, мы делаем асинхронную репликацию изменений в копиях с отложенным разрешением конфликтов. Мы позволяем то, что в некоторые моменты времени данные в разных копиях НЕ консистентны.
Либо, мы говорим, что ради обеспечения немедленной и постоянной Consistency, все запросы на редактирование тех данных, которые имеют копии в разрозненных сегментах, блокируются до тех пор, пока соединение не восстановится. Т.е., у нас нет Availability. Это, как я понимаю, например, модель двухфазного коммита распределенных транзакций. Это то, как работает синхронная репликация (например, в БД Oracle и банкоматах — вам не закоммитят транзакцию и не отдадут деньги до тех пор, пока основной сервер БД и stand-by сервер(а) не подтвердят коммит транзакции).
Zorkus, извините, не совсем понимаю к чему Вы апеллируете. Вы приводите два дизайна систем: CP и AP, где жертвуется доступностью или согласованностью, соответственно. Я себе очень хорошо, как можно построить такие системы. Я не могу себе представить CA систему, где есть и доступность и согласованность на 100%.
Ну я просто привел дополнительный пример, не ответ на ваш вопрос, извините.
Вот цитата по ссылке выше:
Drop Partition Tolerance
If you want to run without partitions you have to stop them happening. One way to do this is to put everything (related to that transaction) on one machine, or in one atomically-failing unit like a rack. It's not 100% guaranteed because you can still have partial failures, but you're less likely to get partition-like side-effects. There are, of course, significant scaling limits to this.
Т.е. по сути, CA система не может быть распределенной в реальном мире, я это понимаю так. По крайней мере, распределенной в смысле хранения данных на разных узлах сети. Возможно, системы типа Oracle RAC можно назвать в каком-то узком смысле распределенными системами с CA — там есть много процессинговых нодов, но один сторидж под ними, и копии данных управляются ASM-ом на уровне ниже самих нодом… мне надо это обдумать самому. Не думал об RAC с этой точки зрения.
Вот цитата по ссылке выше:
Drop Partition Tolerance
If you want to run without partitions you have to stop them happening. One way to do this is to put everything (related to that transaction) on one machine, or in one atomically-failing unit like a rack. It's not 100% guaranteed because you can still have partial failures, but you're less likely to get partition-like side-effects. There are, of course, significant scaling limits to this.
Т.е. по сути, CA система не может быть распределенной в реальном мире, я это понимаю так. По крайней мере, распределенной в смысле хранения данных на разных узлах сети. Возможно, системы типа Oracle RAC можно назвать в каком-то узком смысле распределенными системами с CA — там есть много процессинговых нодов, но один сторидж под ними, и копии данных управляются ASM-ом на уровне ниже самих нодом… мне надо это обдумать самому. Не думал об RAC с этой точки зрения.
Availability здесь нет, так как пользователю из Европы недоступны все данные, которые лежат на тех нодах, которые в Америки.
Если рассматривать случай, когда пользователь из Америки и пользователь из Европы работают над одними и теми же документами., то это тоже не совсем так. Availability действительно выполнено, посколько оба пользователя могут раздельно работать над свомими версиями документов, своими порциями данных. Partition Tolerance тоже выполнено — при падении соединения между сегментами, оба пользователя по прежнему могут выполнять свои базовые функции.
Consistency НЕ выполнено — версии над которыми работаю два пользователя, разные с момента падения сети между сегментами. И между ними после восстановления сегмента потребуется merge, потребуется возможно одну из версий документа отбросить, чтобы выполнилось требования BASE (eventually consistent.)
Если рассматривать случай, когда пользователь из Америки и пользователь из Европы работают над одними и теми же документами., то это тоже не совсем так. Availability действительно выполнено, посколько оба пользователя могут раздельно работать над свомими версиями документов, своими порциями данных. Partition Tolerance тоже выполнено — при падении соединения между сегментами, оба пользователя по прежнему могут выполнять свои базовые функции.
Consistency НЕ выполнено — версии над которыми работаю два пользователя, разные с момента падения сети между сегментами. И между ними после восстановления сегмента потребуется merge, потребуется возможно одну из версий документа отбросить, чтобы выполнилось требования BASE (eventually consistent.)
Да, вероятно вы правы, я предполагал что если случается сбой, пользователи США работавшие до этого с документом созданным пользователем Европы работают не со своей версией документа, они вообще не могут дальше работать над этим документом в угоду Consistency (пусть лучше такой возможности не будет чем возникнет несогласованность). Но могут работать с другими, которые лежат на на серверах США. Никакого мержа в таком случае не будет после восстановления связи потому что мы отказались от Partition Tolerance.
UFO just landed and posted this here
Нет доступа — это вопрос к availability.
> В бухгалтерии недопустимо, например. Если нет доступа к данным о предидущих платежах контрагентов то новые сделки регистрировать невозможно (вдруг он уже должен).
Ну конечно. А до появления сетей и компьютеров как жили?
В городе N ты закупил товар, в городе M ты тоже закупил товар, а в городе K ничего не знают о твоих долгах и ты и там закупил товар. Синхронизация между N, M и K произойдет гораздо позже и тебя выловят, но вообще, что бы дальше закупаться в N, M и K, ты вначале будешь должен расплатиться за покупки в каждой из партиций по отдельности, за свои части товара. Вполне себе партиции, вполне себе работоспособные.
Ну конечно. А до появления сетей и компьютеров как жили?
В городе N ты закупил товар, в городе M ты тоже закупил товар, а в городе K ничего не знают о твоих долгах и ты и там закупил товар. Синхронизация между N, M и K произойдет гораздо позже и тебя выловят, но вообще, что бы дальше закупаться в N, M и K, ты вначале будешь должен расплатиться за покупки в каждой из партиций по отдельности, за свои части товара. Вполне себе партиции, вполне себе работоспособные.
Почему вы не можете представить себе AP или CP системы?
Первый случай: жили себе две ноды (A, B) с данными далеко друг от друга, реплицировались и все было хорошо, но в один прекрасный момент связь между ними пропала. Клиент C1 подключился к ноде A и что-то наменял, поскольку у нас система всегда доступна и терпима к разделению (AP) она это и позволила сделать. Клиент C2 в это же время подключился к ноде B и тоже что-то поменял. Данные принялись обоими нодами и доступны для клиентов которые подключаются просто они разные на разных узлах (несогласованы).
Во втором случае имеем CP систему: каждый раз при записи на любую ноду они перепроверяют согласованность данных с другими, в случае сбоя сети между теми же нодами A и B, все попытки считать данных с любой из нод закончатся успехом так как система терпима к разделению, но попытки записи будут неудачны до тех пор пока система не сможет убедиться в собственной целостности.
Жертвуя терпимостью к сбоям мы по сути горизонтально разделяем данные по нодам. Это приводит к тому что когда связь между A и B пропадает часть данных что лежит на B недоступна для клиентов подключившихся к A и наоборот. Если например пользователь обновляет данные которые лежат на A — все хорошо (доступность), любые попытки чтения или обновления даных лежащих на B — ошибка (невозможно проверить целостность).
По крайней мере так это понимаю я.
Первый случай: жили себе две ноды (A, B) с данными далеко друг от друга, реплицировались и все было хорошо, но в один прекрасный момент связь между ними пропала. Клиент C1 подключился к ноде A и что-то наменял, поскольку у нас система всегда доступна и терпима к разделению (AP) она это и позволила сделать. Клиент C2 в это же время подключился к ноде B и тоже что-то поменял. Данные принялись обоими нодами и доступны для клиентов которые подключаются просто они разные на разных узлах (несогласованы).
Во втором случае имеем CP систему: каждый раз при записи на любую ноду они перепроверяют согласованность данных с другими, в случае сбоя сети между теми же нодами A и B, все попытки считать данных с любой из нод закончатся успехом так как система терпима к разделению, но попытки записи будут неудачны до тех пор пока система не сможет убедиться в собственной целостности.
Жертвуя терпимостью к сбоям мы по сути горизонтально разделяем данные по нодам. Это приводит к тому что когда связь между A и B пропадает часть данных что лежит на B недоступна для клиентов подключившихся к A и наоборот. Если например пользователь обновляет данные которые лежат на A — все хорошо (доступность), любые попытки чтения или обновления даных лежащих на B — ошибка (невозможно проверить целостность).
По крайней мере так это понимаю я.
Не, тут подмена понятий.
Цитируя статью:
то есть, жертвование Partition Tolerance означает признание того факта, что потеря сообщений между компонентами влияет на работоспособность. И оно ни в коем случае не означает что потерь не происходит вообще.
И, кстати, это не абсолютно. Так же как Availability может быть 99% или 99.999% или Consistency может быть «через 5мс», так же и PA может быть «при потере не более 49% узлов кластера» (например).
Цитируя статью:
Partition Tolerance. Потеря сообщений между компонентами системы не влияет на работоспособность системы.
то есть, жертвование Partition Tolerance означает признание того факта, что потеря сообщений между компонентами влияет на работоспособность. И оно ни в коем случае не означает что потерь не происходит вообще.
И, кстати, это не абсолютно. Так же как Availability может быть 99% или 99.999% или Consistency может быть «через 5мс», так же и PA может быть «при потере не более 49% узлов кластера» (например).
Про то что между доступностью и согласованностью можно двигаться в процентах, я абсолютно согласен. Я пытался явно написать в статье, что невозможно полностью (100%) удовлетворить оба случая.
Кластер развалился на 3 части, кажный бранч компании работал со своим бранчем, связь восстановилась, что произойдет в этом случае?
В случае Riak я вижу, что там и C и A и P выполняются, но только P выполняется на 100 процентов.
В случае Riak я вижу, что там и C и A и P выполняются, но только P выполняется на 100 процентов.
ну мало ли что может произойти.
Случай 1: кластер не поддерживает Partition Tolerance, то есть это CA-система, которая, согласно автору статьи, «не может существовать».
В этом случае система, при потере сообщений между компонентами системы, она становится неработоспособной. Например, каждая из трех частей кластера работает совершенно независимо, как отдельная «система», и обратно они не соединяются. Только вручную.
Случай 2: кластер пытается поддерживать Partition Tolerance, но только если больше половины осталось в контакте, тогда, например, все три части отказываются работать, так как каждая часть в отдельности меньше половины, и она думает что оставшиеся две трети продолжат работу.
Случай 3: связь между нодами прервалась, но особый канал повышенной надежности между нодами и арбитратором остался. Ну, тут все просто.
И так далее, можно много чего придумать.
Случай 1: кластер не поддерживает Partition Tolerance, то есть это CA-система, которая, согласно автору статьи, «не может существовать».
В этом случае система, при потере сообщений между компонентами системы, она становится неработоспособной. Например, каждая из трех частей кластера работает совершенно независимо, как отдельная «система», и обратно они не соединяются. Только вручную.
Случай 2: кластер пытается поддерживать Partition Tolerance, но только если больше половины осталось в контакте, тогда, например, все три части отказываются работать, так как каждая часть в отдельности меньше половины, и она думает что оставшиеся две трети продолжат работу.
Случай 3: связь между нодами прервалась, но особый канал повышенной надежности между нодами и арбитратором остался. Ну, тут все просто.
И так далее, можно много чего придумать.
Система, в которой пожертвовали partition tolerance — это любая централизованная система.
Можете привести пример как устроена распределенная централизованная система, в которой достигли доступности и согласованности на 100%?
бухгалтерия 8)
всегда доступно, всегда согласованно, ничего не теряется. Работает одинаково как в международных компаниях так и в магазинчике на углу.
Но дорого.
всегда доступно, всегда согласованно, ничего не теряется. Работает одинаково как в международных компаниях так и в магазинчике на углу.
Но дорого.
Распределённая и централизованная — это антонимы :-)
Я пытался сказать, что область применения CAP-теоремы не ограничивается только распределёнными системами. И что классические SQL-хранилища — это как раз решение с максимизацией консистентности и доступности информации, в ущерб её разделяемости.
Я пытался сказать, что область применения CAP-теоремы не ограничивается только распределёнными системами. И что классические SQL-хранилища — это как раз решение с максимизацией консистентности и доступности информации, в ущерб её разделяемости.
Вот и я так подумал, что это антонимы, поэтому и спросил в таком ключе :)
А вот с тем что область применения CAP теоремы шире, я на согласен. Ведь, везде говориться что CAP теорема сформулирована именно для распределенных систем.
А вот с тем что область применения CAP теоремы шире, я на согласен. Ведь, везде говориться что CAP теорема сформулирована именно для распределенных систем.
Собственно в той же википедии написано, что
CA
Система, во всех узлах которой данные согласованы и обеспечена доступность, жертвует устойчивостью к распаду на секции. Такие системы возможны на основе технологического программного обеспечения, поддерживающего транзакционность в смысле ACID.
Вы сейчас о чем? Раз вы пишете в этой ветке обсуждений, то Вы все еще говорите о том применима ли CAP теорема для не распределенных систем. Так в той же википедии и написано: «эвристическое утверждение о том, что в любой реализации распределённых (sic!) вычислений возможно обеспечить не более двух из трёх следующих свойств»
Если же Вы это приводите в качестве контраргумента, что распределенные системы существуют, то приведите общее описание такой системы, которая может этого достичь. Цитируемая строчка из википедии, мне не дает понять как такую систему построить.
Если же Вы это приводите в качестве контраргумента, что распределенные системы существуют, то приведите общее описание такой системы, которая может этого достичь. Цитируемая строчка из википедии, мне не дает понять как такую систему построить.
Я утверждал и продолжаю утверждать, что CAP-теорема применима не только к распределённым системам, но и к централизованным. При этом я говорю, что жертвование разделяемостью возможно в случае централизованных систем (в частности традиционным RDBMS), и в качестве примера привожу подтверждающую, как мне кажется, цитату из википедии.
Собственно, я согласен с вами, что обеспечить ACID-транзакционность в распределённой системе, как минимум, очень сложно. Отличие моей позиции только в границах применимости CAP-теоремы.
Однако, вот в этом перечислении (No)SQL систем примеры CA-систем приведены, и это не только традиционные RDBMS (так, там перечислены Aster Data, Greenplum и Vertica). Правда сам я с этими системами не работал, поэтому никак не могу их прокомментировать.
Собственно, я согласен с вами, что обеспечить ACID-транзакционность в распределённой системе, как минимум, очень сложно. Отличие моей позиции только в границах применимости CAP-теоремы.
Однако, вот в этом перечислении (No)SQL систем примеры CA-систем приведены, и это не только традиционные RDBMS (так, там перечислены Aster Data, Greenplum и Vertica). Правда сам я с этими системами не работал, поэтому никак не могу их прокомментировать.
Я абсолютно согласен, что построить нераспределнную систему CA, в терминах обсуждаемой теоремы можно. Я просто говорю, что она формулировалась именно для распределенных систем, что и хотел обсудить в этом топике.
Я с вами не спорю, просто доп. примеры привожу. Я вообще не могу понять, как понятие PT имеет смысл в практическом мире для распределенных систем.
Я тоже, об этом и хотел написать :)
Устойчивость к разделению системы или даже недоступности какой-то части
— возьмём тот же твиттер. Что будет если данные пользователей за прошлый год станут недоступными? Да ничего не будет. Пёс с ними, их никто не смотрит. Это и есть устойчивость к потере данных.
— возьмём тот же твиттер. Что будет если данные пользователей за прошлый год станут недоступными? Да ничего не будет. Пёс с ними, их никто не смотрит. Это и есть устойчивость к потере данных.
Я тут так понимаю тут зависит от того, что в этом случае показывает Twitter. Если он показывает, ой извините у нас поломка, я вам не могу показать данные, которые на самом деле у меня есть, то это отказ в обслуживании, т.е. потеря avalability.
Если же он просто тупо их отрезает, делая вид, что их никогда не было, это наверное уже можно посмотреть как потерю consistency.
Кто как думает?
Если же он просто тупо их отрезает, делая вид, что их никогда не было, это наверное уже можно посмотреть как потерю consistency.
Кто как думает?
ACID-транзакционность обеспечивается только синхронной репликацией (двухфазным коммитом транзакций), при которой страдает Availability.
Это из нее следствие?
Быстро, качественно, недорого. Выбирайте любые ДВА пункта.
Быстро, качественно, недорого. Выбирайте любые ДВА пункта.
Кстати, мне кажется, вы не совсем правильно понимаете availability. Т.е. сначала вы пишете правильные слова про доступность информации, а потом почему-то начинаете говорить про недоступность системы. Но ведь если система в какой-то момент не работает, то это совсем не говорит о том, что она не обеспечивает доступность информации, когда работает. И availability — это про логическое устройство системы, а не про её работоспособность в какой-то момент.
На мой взгляд просто немного смешаны понятия в самой теореме, поэтому и неочевидно. PT находится уровнем несколько выше C/A, т.е. C/A действуют внутри принятого или не принятого PT. И если вы не поддерживаете PT, то при разрыве системы на партиции, вы не обязаны соблюдать C/A между ними — только внутри каждой партиции.
Пример CA системы будет такой:
Мастер-копия базы и несколько read-only подчиненных. Мастер-сервер считаем отказоустойчивым внутри. Подчинённый сервер при отсутствии связи с мастером блокируется и перестаёт отдавать данные (чтобы обеспечить consistency). Система в целом — доступна, целостность — соблюдается.
Мастер-копия базы и несколько read-only подчиненных. Мастер-сервер считаем отказоустойчивым внутри. Подчинённый сервер при отсутствии связи с мастером блокируется и перестаёт отдавать данные (чтобы обеспечить consistency). Система в целом — доступна, целостность — соблюдается.
Расскажите как в описанной системе происходит запись. Давайте для упрощения пусть у нас будет один мастер и одна read-only нода. Как данные, записанные на мастер, попадают в read-only копию, и что произойдет в момент когда связь между мастером и read-only копией потеряется, а между клиентом и read-only останется?
Так же что значит мастер отказоустойчивый внутри? Т.е. они никогда не падает? Такого не бывает.
Так же что значит мастер отказоустойчивый внутри? Т.е. они никогда не падает? Такого не бывает.
Неработающий мастер=неработающая система. Это к CAP-теореме не относится.
Данные попадают синхронно, например с помощью синхронной репликации или 2PC.
Если связи с мастером нет — то слейв блокируется, то есть сессия клиента обрывается.
Данные попадают синхронно, например с помощью синхронной репликации или 2PC.
Если связи с мастером нет — то слейв блокируется, то есть сессия клиента обрывается.
Раз сессия клиента обрывается, то записи он не может осуществлять, значит 100% доступности нет.
«Неработающий мастер=неработающая система. Это к CAP-теореме не относится.» Ну как не относиться. Здесь получается single point of failure, от которого распределенные системы позволяют опять же избавиться. Разве это не получается, что 100% доступности опять нет?
При такой логике мы сваливаемся к централизованной системе в итоге, а не распределенной. А топик именно об распределенных системах.
«Неработающий мастер=неработающая система. Это к CAP-теореме не относится.» Ну как не относиться. Здесь получается single point of failure, от которого распределенные системы позволяют опять же избавиться. Разве это не получается, что 100% доступности опять нет?
При такой логике мы сваливаемся к централизованной системе в итоге, а не распределенной. А топик именно об распределенных системах.
По-моему то, что вы считаете распределенной системой и является свойством PT :)
Ну есть и PA. В комментариях даже было несколько примеров. А вот CA ни одной не было.
PT=partition tolerance. Т.е. вы любую систему, не обладающую PT будете считать централизованной.
Сорри, неправильно прочитал ваш предыдущий коммент.
Ну что-то вроде этого. Надеялся, что кто-то меня переубедит, но как-то не переубедили пока:)
Ну что-то вроде этого. Надеялся, что кто-то меня переубедит, но как-то не переубедили пока:)
Переубедили в чём? В том что распределённые системы не могут быть CA?
Ну с этим вроде никто не спорит уже. Скорее четко объяснили, зачем P введена в CAP-теореме.
вы просто своеобразно понимаете понятие «распределённая система». Например SMP и NUMA архитектуры тоже распределённые, но при этом они CA. Скажете, что они бесполезны?
Ну я специально сузил область рассуждений до распределенных хранилищ данных, возможно в этом дело.
в примере, который приводится в статье (http://codahale.com/you-cant-sacrifice-partition-tolerance/, после But Never Both) можно сделать систему CA — добавить в нее роутер, который перенаправляет запросы, отправленные на C на остальные узлы.
эээ… Ну в этом случае изменения применяться на {A,B} и будут не консистенты с нодой С.
Нода C в этом случае работать не будет. Заработает она только когда восстановится связь и она синхронизируется с {A,B}. Главная сложность тут в том, как определить, что произошел partition и корректно реализовать fence/unfence узла.
Я весь внимания как Вы это будете делать.
Это уже специфика конкретной системы. Вот примеры:
oss.oracle.com/projects/ocfs2/dist/documentation/v1.2/ocfs2_faq.html#QUORUM
www.clusterlabs.org/doc/crm_fencing.html
www.dba-oracle.com/t_rac_cluster_fencing.htm
oss.oracle.com/projects/ocfs2/dist/documentation/v1.2/ocfs2_faq.html#QUORUM
www.clusterlabs.org/doc/crm_fencing.html
www.dba-oracle.com/t_rac_cluster_fencing.htm
Я больше чем уверен, что любой дизайн в общем виде можно очень просто объяснить на пальцах. Но раз вы просто кидаете ссылки, то я что-нибудь одно постараюсь сегодня посмотреть и завтра отпишусь.
Спасибо за ссылки. Ознакомился с понятием fencing, но как на основе его сделать CA систему там, к сожалению не написано. Посмотрите, я апдейт в конце топика написал. Вобщем попытки построить CA систему, в который возможны потери между компонентами системы, значит опровергнуть CAP-теорему, думаю не стоит больше этим заниматься.
собственно эти 3 системы — OCFS2, linux-ha и RAC считаются CA.
Они не могут работать при network partition, но могут переконфигурироваться так, чтобы продолжать работу. Это занимает какое-то время, но для достаточно большого времени ожидания запросы будут обработаны и консистентность не будет нарушена.
Они не могут работать при network partition, но могут переконфигурироваться так, чтобы продолжать работу. Это занимает какое-то время, но для достаточно большого времени ожидания запросы будут обработаны и консистентность не будет нарушена.
Наверное, надо закрывать топик. Написал вконец поста апдейт.
> Она довольно давно доказана
Когда и кем?
Когда и кем?
mantonov.blogspot.com/2012/01/cap.html — я тут обобщил свои комментарии, + добавил еще некоторые свои мысли по этому поводу, с примерами.
Я смотрю данный топик побудил уже третью публикацию о CAP-теореме, что меня конечно же не может не радовать. Я сначала сомневался, писать или нет об этом всём. Думал закидают же тухлыми помидорами. Ан нет, действительно нашлось о чем поговорить!
Господа, ощущение что нам нужен еще один топик для продолжения обсуждения, или даже два. Обзор стратегий разрешения конфликтов для обеспечения, собственно, Eventual Consistency, и обзор борьбы со brainsplit-ом (кворумы и прочее, какие техники применяются в распределенныхт системах, например, в Oracle Coherence).
«Здесь очень важный момент состоит в том, что если какие-то компоненты выходят из строя, то это тоже подпадает под этот случай, так как можно считать, что данные компоненты просто теряют связь со всей остальной системой»
Мне кажется это не совсем корректное дополнение к теореме, т.к. упавшая нода не функционирует и соответственно не может обрабатывать данные (split brain при этом не происходит). По одной из приведённых вами ссылок об этом тоже явно говорится: codahale.com/you-cant-sacrifice-partition-tolerance/#errata10221010
Мне кажется это не совсем корректное дополнение к теореме, т.к. упавшая нода не функционирует и соответственно не может обрабатывать данные (split brain при этом не происходит). По одной из приведённых вами ссылок об этом тоже явно говорится: codahale.com/you-cant-sacrifice-partition-tolerance/#errata10221010
Sign up to leave a comment.
Недопонимание CAP-теоремы