Здравствуйте, Alex.Che, Вы писали:
>> Судя по официальным докам, в SQL Server нет чексумм для страниц, что не мешает ему входить в тройку лидеров. AC>вот. этим всё и объясняется. AC>"всё чего у нас нету, вам и не нужно..." (с)
Судя по https://docs.oracle.com/cd/B28359_01/server.111/b28318/logical.htm#CIHEIFJC, у Оракла тоже нет чексумм.
Что не мешает и ему входить в тройку лидеров. Ну что, про DB2 будем смотреть, или нуевонах?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>Не знаю. Судя по официальным докам, в SQL Server нет чексумм для страниц, что не мешает ему входить в тройку лидеров.
В тройку лидеров чего?
S>В процитированной вами части работы написано, что checksum помогает отловить ошибки сбоя записи. И, что "Checksum mismatches can be detected anytime a disk block is read".
Pdf-ка статьи гуглится по названию, если что. Я не утверждаю что checksum mismatch нельзя отловить, я лишь утверждаю что не всегда можно восстановить блок (получится URE) и иногда данные просто теряются и ошибка на стороне диска не детектится (тут и ошибки в прошивке и не ECC память на борту некоторых HDD и возможно даже крайне редкие события, вроде такого изменения блока, после которого контрольная сумма сойдется).
S>О, ну вот опять. NoSQL потому что CAP. Ещё раз поясню непонятную мне линию рассуждений: вы утверждаете, что High Availability — это возможность потерять до трети машин, потому что так вам рассказали в CAP. И следом же пишете, что CAP — она вообще не про availability.
Нет, я не утверждаю что это возможность потерять до трети машин. Я говорил про availability в другом контексте.
S>У вас в голове явно есть одновременно два термина availability, с конфликтующими определениями. Availability означает способность выполнять запрошенные операции. То есть если операция отпала по таймауту — это значит, что система non-available. По определению. Поэтому невозможно иметь аvailability без возможности записи/чтения. А у вас получается "прибор работает, но не включается, потому что включается, но не работает".
Вот самое распространенное определение того, что есть availability (из CAP) — "Every request received by a non-failing node in the system must result in a response." (и под response тут имеется ввиду не возврат кода ошибки а ответ о том что все ОК). Это свойство системы, которое заключается в том, что на каждый запрос приходит ответ (если запрос дошел до работающей ноды). Заметь, что свойство никуда не пропадает, если часть машин недоступны. Если мы имеем дело с CP системой (Zookeeper например), то в случае отсутствия кворума мы не сможем ничего сделать (только читать протухшие данные). Если мы имеем дело с AP системой, например с Dinamo — данные будут записаны несмотря ни на что, даже если узел, принявший наш запрос вообще отсоединен от кластера, просто когда он присоединится обратно и мы попробуем прочитать обратно то что было записано — получим конфликт. Это свойство системы не зависит от MTTR вообще никак. Если система является доступной, в нее можно записывать всегда.
Другое определение availability, с которым мне доводилось встречаться (и я думал что ты именно его имеешь ввиду) — это тупо то же самое что и аптайм. Тут мы действительно можем повысить availability поставив дополнительный блок питания, так как вероятность аппаратного сбоя снижается. Но я исхожу из того что а) это само собой разумеется б) в контексте NoSQL availability — свойство системы куда интереснее и полезнее, нежели availability — надежность системы.
При этом одно из второго никак не следует. Можно иметь 100% надежное железо, которое никогда не ломается, все машины кластера могут работать и быть сконфигурированы правильно, при этом система не будет доступной. Вот например Zookeeper кластер — все ноды работают, но часть из них — под высокой нагрузкой, поэтому половина транзакций отваливается. Но при этом с точки зрения надежности и аптайма все хорошо.
S>Она взялась из "минимальной HA" конфигурации. Вы же тут утверждали, что кластер из двух машин не является HA. S>Ну давайте возьмём кластер из 300 машин. Предположим, MTBF у нас — 1 год, а MTTR = 1000 лет. Какова availability этого кластера при эксплуатации в течение неограниченного времени? S>Возьмём двухмашинный кластер. Предположим, MTBF у нас по-прежнему 1 год, а MTTR — 5 минут. Какова availability этого кластера?
Это все понятно, я не спорю с тем что время восстановления после сбоя — важно. Но вот подобные рассуждения про профанации, когда ты используешь тот же MTTR для доказательства, это очень странно. Это же среднее значение, т.е. ни о чем вообще. Вот например эксплуатируем кластер из 3х машин. У нас было два сбоя, первый сбой вылечился простой перезагрузкой за одну минуту, второй сбой — аппаратный, пришлось ждать новый сервер неделю. Какой будет MTTR и будет ли он иметь хоть какой-то практический смысл?
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 системы не могут сохранить согласованность данных даже через любое длительное время.
Здравствуйте, chaotic-kotik, Вы писали: CK>В тройку лидеров чего?
RDBMS.
CK>Pdf-ка статьи гуглится по названию, если что. Я не утверждаю что checksum mismatch нельзя отловить, я лишь утверждаю что не всегда можно восстановить блок (получится URE) и иногда данные просто теряются
Воот. Это мы разобрались с вопросом "можно ли вообще определить, что backup нечитаем". Или вы имели в виду "не пытаясь его восстановить"? Нет, без специальных усилий определить, жив ли ещё backup, невозможно.
CK>и ошибка на стороне диска не детектится (тут и ошибки в прошивке и не ECC память на борту некоторых HDD и возможно даже крайне редкие события, вроде такого изменения блока, после которого контрольная сумма сойдется).
ECC и CRC — это разные вещи. Обнаружить ошибку гораздо легче, чем исправить. Про прозрачное восстановление данных никто и не намекал — это было бы слишком хорошо, чтобы быть правдой.
На практике я пока не видел вменяемых SMART — инструментов (по крайней мере для локального использования). Т.е. в теории у нас есть методика предсказания скорой смерти диска, которая может нам помочь выбрать момент для замены до того, как произойдёт необратимая потеря. Скажем, тулзы от Леново продолжают говорить что SMART Test is Ok даже после того, как на диске перестало читаться 10% секторов.
CK>Вот самое распространенное определение того, что есть availability (из CAP) — "Every request received by a non-failing node in the system must result in a response." (и под response тут имеется ввиду не возврат кода ошибки а ответ о том что все ОК). Это свойство системы, которое заключается в том, что на каждый запрос приходит ответ (если запрос дошел до работающей ноды). Заметь, что свойство никуда не пропадает, если часть машин недоступны. Если мы имеем дело с CP системой (Zookeeper например), то в случае отсутствия кворума мы не сможем ничего сделать (только читать протухшие данные). Если мы имеем дело с AP системой, например с Dinamo — данные будут записаны несмотря ни на что, даже если узел, принявший наш запрос вообще отсоединен от кластера, просто когда он присоединится обратно и мы попробуем прочитать обратно то что было записано — получим конфликт. Это свойство системы не зависит от MTTR вообще никак. Если система является доступной, в нее можно записывать всегда.
Это бесполезное определение, потому что под него либо не попадают вообще никакие системы, либо попадают сразу все — в зависимости от того, что мы считаем за failing node.
Например, вы вспотеете писать веб-сервис, который никогда-никогда-никогда не вернёт 50x ошибку (а must и every — это именно никогда-никогда).
CK>Другое определение availability, с которым мне доводилось встречаться (и я думал что ты именно его имеешь ввиду) — это тупо то же самое что и аптайм. Тут мы действительно можем повысить availability поставив дополнительный блок питания, так как вероятность аппаратного сбоя снижается. Но я исхожу из того что а) это само собой разумеется б) в контексте NoSQL availability — свойство системы куда интереснее и полезнее, нежели availability — надежность системы.
Конечно. Вот та availability, которая принята в CAP — она не может быть high либо low. Она либо есть (что в жизни вы никогда не достигнете), либо её нет (как на самом деле и бывает, жертвуешь ли ты consistency или partition tolerance или не жертвуешь).
CK>При этом одно из второго никак не следует. Можно иметь 100% надежное железо, которое никогда не ломается, все машины кластера могут работать и быть сконфигурированы правильно, при этом система не будет доступной. Вот например Zookeeper кластер — все ноды работают, но часть из них — под высокой нагрузкой, поэтому половина транзакций отваливается. Но при этом с точки зрения надежности и аптайма все хорошо.
Нет. Если у нас 50% запросов получают 50х, то availability будет 50%. Причём неважно, связано это с тем, что у нас каждый вечер ложится блок питания, и запуск его делает Вася, приезжая к 8:00 в датацентр, или с тем, что каждый второй запрос переполняет request queue.
Если у нас запланирован апгрейд нашего единственного сервера раз в квартал, и в течение 24 часов он каждый раз недоступен, то несмотря на 100% надёжное железо Availability никак не сможет быть выше двух девяток.
Чтобы поднять её до трёх девяток, потребуется как минимум две машины, чтобы можно было обслуживать их по очереди. Это как раз самая частая конфигурация для слабонагруженных высокодоступных приложений.
В том-то и коварство CAP, что она применяет категоричные термины там, где нужна некоторая мягкость. В том смысле, что в реальных системах всегда выбирают компромисс — например, жертвуют некоторой долей consistency ради увеличения availability. А в CAP всё тупо — "ой, раз вы требуете availability, то давайте откажемся от consistency, заменив её на eventual consistency".
При этом eventual consistency — тоже оксюморон. Её не имеет смысла обсуждать, не имея количественных метрик. Вот, допустим, если баланс вашего счёта у сотового оператора отстаёт на пять минут от реального времени, то вам, скорее всего, на это наплевать. А вот если окажется, что оператор собирается вам выставлять "потерянные" счета в течение ещё пяти лет после разрыва контракта, то скорее всего это не устроит ни его, ни вас.
Поэтому реализуются компромиссные системы, в которых и availability неполная, и consistency неидеальная.
CK>Это все понятно, я не спорю с тем что время восстановления после сбоя — важно. Но вот подобные рассуждения про профанации, когда ты используешь тот же MTTR для доказательства, это очень странно.
Не для доказательства, а для иллюстрации. Для того, чтобы по честному рассчитать Availability, нужно иметь и модель сбоев, и модель восстановления. MTBF и MTTR подразумевают стохастический характер сбоев, и удобны только тем, что ими легко манипулировать в формулах, и наглядно видеть, как строить надёжные системы из ненадёжных.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
>>> Судя по официальным докам, в SQL Server нет чексумм для страниц, что не мешает ему входить в тройку лидеров. AC>>вот. этим всё и объясняется. AC>>"всё чего у нас нету, вам и не нужно..." (с) S>нуевонах? PAGE_VERIFY
но это не зря, хотя, может быть, невзначай
гÅрмония мира не знает границ — сейчас мы будем пить чай
Здравствуйте, gandjustas, Вы писали:
G>То есть односерверная машина у нас априори available?
Да, но CAP не применяют для анализа односерверных систем. Ну ты можешь попробовать, конечно, но это странно.
G>То есть пофиг что внутри происходит, главное ОК вернуть?
Формально — да.
G>То есть пофиг сколько ждать перед тем как ОК вернуть?
Конечно, тем не менее это не опровергает корректность CAP (это было показано в статье Нэнси Линч и еще какого-то чувака, которую ты в своей статье для хабра цитируешь).
G>И какой смысл в этом определении?
CAP определяет availability как liveness, формально, определение не очень строгое и под него действительно можно подвести все что ты перечислил, но понимается под этим именно liveness. Consistency из CAP определяется как safety (agreement & validity).
На практике это означает, что CP система может обрабатывать запрос на запись или чтение произвольное время, так как на каждый запросу будет запущен раунд консенсуса (raft, zab, paxos), положительный результат при этом не гарантирован, т.е. на свой запрос ты можешь получить ответ, означающий что кворум не получен и запись(или чтение) не прошла. AP система не будет гонять консенсус на каждый запрос чтения/записи, она может, например, в ответ на запрос на запись, записать данные в локальное хранилище, вернуть положительный ответ, а потом, асинхронно (например через gossip протокол) распространить твое изменение по кластеру (или его части).
G>Но это не означает, что потом можно будет прочитать. То есть в грубом приближении AP система это /dev/null.
Можно представить AP систему, работающую как /dev/null, но это не значит, что нельзя создать AP систему, имеющую полезные свойства.
G>Availability это не свойство железа, а свойство системы (железа, каналов связи, логики серверов, логики клиентов). Определяется как процент времени когда система способна отвечать на запросы за разумное (заранее определённое) время и сохранять работоспособность. Для этого нужно в первую очередь поддерживать аптайм железа, чтобы серваки не падали и поддерживать логику работы. G>При этом вовсе не требуется, чтобы на каждый запрос возвращался ОК, вполне возможно повторение запроса на клиенте, если сервер недоступен или отвечает "обратитесь позже". Так устроены многие протоколы от REST до TCP\IP.
Еще раз, мы обсуждаем NoSQL, можно себе представить (легко) систему, которая полностью работоспособна, никаких ошибок нет и в помине, при этом система может быть недоступной в терминах CAP и запрос на запись у тебя будет отваливаться по таймауту иногда. При этом даунтайма нет, каждый хост пингуется, каждый endpoint принимает входящие подключения и отвечает на запросы.
Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success.
G>Availability в CAP — бесполезное на практике свойство и его потеря по факту может не значить вообще ничего. G>Partition tolerance кстати тоже. В большинстве случаев partition tolerant системы не могут сохранить согласованность данных даже через любое длительное время.
Wat?
G>Писал об этом на хабре https://habrahabr.ru/post/231703/
Статья очень спорная.
Вот это понравилось:
Разделение сети — крайне редкое явление в наше время. Гилберт и Линч прямо заявляют, что системы, работающие в локальной сети, можно считать не подверженными разделению.
Статья написана академиками (а не практикующими инженерами) в 2002-м году. В 2014-м году никто в академическом сообществе так больше никто не считал. Рекомендую ознакомиться со статьей Network Is Reliable. Пара цитат:
Stop-the-world garbage collection and blocking for disk I/O can cause runtime latencies on the order of seconds to minutes. As Searchbox IO and several other production users (https://github.com/elasticsearch/elasticsearch/issues/2488) have found, GC (garbage collection) pressure in an ElasticSearch cluster can cause secondary nodes to declare a primary dead and to attempt a new election. Because of nonmajority quorum configuration, ElasticSearch elected two different primaries, leading to inconsistency and downtime. Surprisingly, even with majority quorums, due to protocol design, ElasticSearch does not currently prevent simultaneous master election; GC pauses and high IO_WAIT times due to I/O can cause split-brain behavior, write loss, and index corruption.
On July 18, 2013, Twilio's billing system, which stores account credits in Redis, failed.19 A network partition isolated the Redis primary from all secondaries. Because Twilio did not promote a new secondary, writes to the primary remained consistent. When the primary became visible to the secondaries again, however, all secondaries simultaneously initiated a full resynchronization with the primary, overloading it and causing Redis-dependent services to fail.
The ops team restarted the Redis primary to address the high load. Upon restart, however, the Redis primary reloaded an incorrect configuration file, which caused it to enter read-only mode. With all account balances at zero, and in read-only mode, every Twilio API call caused the billing system to recharge customer credit cards automatically, resulting in 1.1 percent of customers being overbilled over a period of 40 minutes. For example, Appointment Reminder reported that every SMS message and phone call it issued resulted in a $500 charge to its credit card, which stopped accepting charges after $3,500.
Здравствуйте, Sinclair, Вы писали:
CK>>Вот самое распространенное определение того, что есть availability (из CAP) — "Every request received by a non-failing node in the system must result in a response." (и под response тут имеется ввиду не возврат кода ошибки а ответ о том что все ОК). Это свойство системы, которое заключается в том, что на каждый запрос приходит ответ (если запрос дошел до работающей ноды). Заметь, что свойство никуда не пропадает, если часть машин недоступны. Если мы имеем дело с CP системой (Zookeeper например), то в случае отсутствия кворума мы не сможем ничего сделать (только читать протухшие данные). Если мы имеем дело с AP системой, например с Dinamo — данные будут записаны несмотря ни на что, даже если узел, принявший наш запрос вообще отсоединен от кластера, просто когда он присоединится обратно и мы попробуем прочитать обратно то что было записано — получим конфликт. Это свойство системы не зависит от MTTR вообще никак. Если система является доступной, в нее можно записывать всегда. S>Это бесполезное определение, потому что под него либо не попадают вообще никакие системы, либо попадают сразу все — в зависимости от того, что мы считаем за failing node. S>Например, вы вспотеете писать веб-сервис, который никогда-никогда-никогда не вернёт 50x ошибку (а must и every — это именно никогда-никогда).
Ну тут имеется ввиду не это, а гарантия liveness. Процесс должен завершиться за ограниченное время и он не может отвалиться только потому что что-то плохое произошло с другой машиной, а не той, к которой мы обращаемся. СР система может отдуплить запрос по причине того что где-то что-то пошло не так и кворума нет. АР система запишет в любом случае. Ес-но определение относится к идеализированным машинам из CAP, реальная АР система может вернуть ошибку более низкого уровня, если, например, клиент БД неправильно сконфигурирован, соединение с узлом БД разорвалось и тд. Но это ошибка более низкого уровня, а не ошибка уровня приложения "повтори запрос еще раз чуть позже".
S>Конечно. Вот та availability, которая принята в CAP — она не может быть high либо low. Она либо есть (что в жизни вы никогда не достигнете), либо её нет (как на самом деле и бывает, жертвуешь ли ты consistency или partition tolerance или не жертвуешь).
Думаю что это верно. Но на практике, под HA все имеют ввиду разное, но чаще всего не одну только доступность в оригинальном смысле. В общем, когда на сайте rabbit mq описывают HA-кластер rabbit-mq это может означать сильно не то, о чем ты говоришь.
S>В том-то и коварство CAP, что она применяет категоричные термины там, где нужна некоторая мягкость. В том смысле, что в реальных системах всегда выбирают компромисс — например, жертвуют некоторой долей consistency ради увеличения availability. А в CAP всё тупо — "ой, раз вы требуете availability, то давайте откажемся от consistency, заменив её на eventual consistency".
Про это же 100500 статей уже написано. На практике же чистых AP|CP систем практически не бывает. Тот же zookeeper это СР система, но ты можешь легко прочитать stale данные, если захочешь, т.е. запросы на запись работают как СР а на чтение как АР (или как СР, если читать по другому). САР это просто способ описывать все эти компромиссы и особенности.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Ну тут имеется ввиду не это, а гарантия liveness. Процесс должен завершиться за ограниченное время и он не может отвалиться только потому что что-то плохое произошло с другой машиной, а не той, к которой мы обращаемся. СР система может отдуплить запрос по причине того что где-то что-то пошло не так и кворума нет. АР система запишет в любом случае. Ес-но определение относится к идеализированным машинам из CAP, реальная АР система может вернуть ошибку более низкого уровня, если, например, клиент БД неправильно сконфигурирован, соединение с узлом БД разорвалось и тд. Но это ошибка более низкого уровня, а не ошибка уровня приложения "повтори запрос еще раз чуть позже".
Опять какие-то высосанные из пальца термины.
1. "Ограниченное время" — это что? Ограниченное чем? Если мы ограничим его, скажем, миллионом секунд, то даже ручная установка нового сервера в датацентр уложится в норматив.
2. Какое дело клиенту до того, из-за чего отвалился "процесс" — оттого, что другая машина сломалась/оказалась недоступной, или оттого, что внутри этой машины отказал HDD или сетевая карточка?
Вообще, проблемы с коммуникациями в принципе не позволяют отличить ситуацию неработоспособности моей машины от неработоспособности удалённой машины.
CK>Думаю что это верно. Но на практике, под HA все имеют ввиду разное, но чаще всего не одну только доступность в оригинальном смысле.
На практике, можно просто сходить в wikipedia. Там написано самое общепринятое из всех общепринятых определений. CK>В общем, когда на сайте rabbit mq описывают HA-кластер rabbit-mq это может означать сильно не то, о чем ты говоришь.
Ещё раз: термин HA обязан обозначать количественную меру availability. Просто потому, что иначе невозможно говорить о high либо low.
Rabbit-mq описывает, как увеличить availability очередей ровно в том смысле, который туда вкладываю я — потому, что он решает вопрос availability очереди при штатном либо нештатном выключении ноды.
Таким образом, если у вас есть процедуры для достаточно быстрой замены упавших нод, то вы можете обеспечить, в принципе, любые количества девяток после запятой.
Ещё раз повторю очевидную истину, доступную немногим: если у вас таких процедур нет, то никакой HA у вас тоже нету. Если вы запустите кластер из 10 машин с периодом полураспада в полгода, настроите репликацию очереди по 10 экземплярам, и забьёте на обслуживаение, то система нагнётся примерно
S>>В том-то и коварство CAP, что она применяет категоричные термины там, где нужна некоторая мягкость. В том смысле, что в реальных системах всегда выбирают компромисс — например, жертвуют некоторой долей consistency ради увеличения availability. А в CAP всё тупо — "ой, раз вы требуете availability, то давайте откажемся от consistency, заменив её на eventual consistency".
CK>САР это просто способ описывать все эти компромиссы и особенности.
Очень странно приводить бескомпромиссную модель как способ описания компромиссов. Тем более, когда мы сравниваем качественно эквивалентные вещи — к примеру, живую репликацию с бэкапом.
Они отличаются исключительно количественно — по стоимости владения и обеспечиваемому MTTR. А он, в свою очередь, непосредственно влияет на ту самую Availability, которая общепринято эквивалента проценту аптайма.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, chaotic-kotik, Вы писали:
CK>CAP определяет availability как liveness, формально, определение не очень строгое и под него действительно можно подвести все что ты перечислил, но понимается под этим именно liveness. Consistency из CAP определяется как safety (agreement & validity).
То есть ты согласен, что это совсем не тот availability о котом говорят в контексте HA?
И разу следующий вопрос — в чем ценность свойства liveness? Какие гарантии или преимущества оно дает? На практике никаких.
G>>То есть в грубом приближении AP система это /dev/null. CK>Можно представить AP систему, работающую как /dev/null, но это не значит, что нельзя создать AP систему, имеющую полезные свойства.
Можно, нужны будут дополнительные гарантии из области Consistency, которые приведут к противоречию с теоремой.
CK>Еще раз, мы обсуждаем NoSQL, можно себе представить (легко) систему, которая полностью работоспособна, никаких ошибок нет и в помине, при этом система может быть недоступной в терминах CAP и запрос на запись у тебя будет отваливаться по таймауту иногда. При этом даунтайма нет, каждый хост пингуется, каждый endpoint принимает входящие подключения и отвечает на запросы.
И? С точки зрения клиента клиента все равно недоступна система или не может выполнить запрос. С точки зрения cap это разные явления
CK>Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success.
Но тогда появляется гораздо интереснее сценарий.
Ты делаешь checkout и проводишь оплату "внутренней валютой". Транзакция с уменьшением баланса улетает на два сервера, один из которых затупил, а второй подумал, что он уже мастер. После синхронизации у тебя дважды сняли деньги.
Ты же сам привел аналогичный пример ниже.
Для любых данных, которые нельзя терять или искажать такой подход не работает.
G>>Availability в CAP — бесполезное на практике свойство и его потеря по факту может не значить вообще ничего. G>>Partition tolerance кстати тоже. В большинстве случаев partition tolerant системы не могут сохранить согласованность данных даже через любое длительное время. CK>Wat?
Твои примеры ниже прекрасно иллюстрируют что я говорю.
CK>Статья написана академиками (а не практикующими инженерами) в 2002-м году. В 2014-м году никто в академическом сообществе так больше никто не считал. Рекомендую ознакомиться со статьей Network Is Reliable. Пара цитат:
По-моему из этого всего можно сделать вывод, что ни availability, ни partition tolerance в реальном мире не помогают строить надежные системы.
Единственный живой вариант — делать CA системы, то есть кворумы с node majority.
Только при наличии существенных ограничений на функциональность системы можно где-то ослаблять consistency.
Здравствуйте, gandjustas, Вы писали:
CK>>CAP определяет availability как liveness, формально, определение не очень строгое и под него действительно можно подвести все что ты перечислил, но понимается под этим именно liveness. Consistency из CAP определяется как safety (agreement & validity). G>То есть ты согласен, что это совсем не тот availability о котом говорят в контексте HA?
Это не тот availability, о котором пишет статья в википедии вот тут — https://en.wikipedia.org/wiki/High-availability_cluster но в контексте NoSQL важен и этот тоже.
Ес-но, все понимают что надежность всей системы = надежности самого слабого звена, поэтому каким бы хорошим не был твой алгоритм репликации, если ты не позаботился о более базовых вещах (таких как резервное питание), то твой алг. репликации не надежнее этих базовых вещей. Все эти разговоры про САР и NoSQL они очень сильно связаны с HA, так как оно все про избавление от SPOF чаще всего.
G>И разу следующий вопрос — в чем ценность свойства liveness? Какие гарантии или преимущества оно дает? На практике никаких.
На практике, это важно тогда, когда возможность сохранить данные важнее целостности. Данные мониторинга, финансовые данные и прочие области, где свежие данные важнее несвежих, всякие хранилища для которых латентность важнее целостности и тд. Я типичный пример с корзиной приводил, там целостность не важна, если будет конфликт — можно разрешить его на уровне приложения. Обеспечение целостности требует кворума (а это 5-3 раундртипа для paxos-а и не помню сколько для 2PC). А AP система (тот же ES) тупо сохранит локально, а репликация будет выполняться асинхронно, т.е. 1-2 раундтрипа. Плюс, ты тут гарантированно не получишь отлуп из-за того, что произошел конфликт транзакции или что-нибудь в этом духе.
G>Можно, нужны будут дополнительные гарантии из области Consistency, которые приведут к противоречию с теоремой.
Реальные системы обычно и не являются чистыми AP или СР системами. Для разных операций разные гарантиии, например в рамках одной записи могут работать транзакции, но в целом, система может быть eventually consistent (за счет чего и достигается масштабируемость).
CK>>Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success. G>Но тогда появляется гораздо интереснее сценарий. G>Ты делаешь checkout и проводишь оплату "внутренней валютой". Транзакция с уменьшением баланса улетает на два сервера, один из которых затупил, а второй подумал, что он уже мастер. После синхронизации у тебя дважды сняли деньги. G>Ты же сам привел аналогичный пример ниже.
Биллинг можно сделать на чем-нибудь другом. Но можно использовать другую модель данных просто, в которой транзакции не меняют запись в которой содержится текущий счет пользователя а дописывают транзакции пользователя в документ, а текущий счет по этой таблице всегда может быть пересчитан. Многие системы будучи АР и eventually consistent, предоставляют гарантию read you're own writes и serializability операций над одним документом/записью, так что это все довольно тривиально реализуется. Я знаю что в одном крупном банке (не скажу каком) биллинг построен на NoSQL решении а не РСУБД.
G>Для любых данных, которые нельзя терять или искажать такой подход не работает.
G>>>Availability в CAP — бесполезное на практике свойство и его потеря по факту может не значить вообще ничего. G>>>Partition tolerance кстати тоже. В большинстве случаев partition tolerant системы не могут сохранить согласованность данных даже через любое длительное время. CK>>Wat? G>Твои примеры ниже прекрасно иллюстрируют что я говорю.
Как минимум, CAP утверждает что все три свойства нельзя иметь, если сеть разделена, но если все ок (а все ок большую часть времени), можно иметь одновременно и целостность и доступность. Я не понял почему partition tolerant системы не могут сохранить согласованность данных через любое длительное время?
G>По-моему из этого всего можно сделать вывод, что ни availability, ни partition tolerance в реальном мире не помогают строить надежные системы.
Вывод из этого следует такой — нельзя делать системы без partition tolerance.
G>Единственный живой вариант — делать CA системы, то есть кворумы с node majority.
Ну назови хоть одну живую СА систему? Это не работает в реальном мире. СА система, это когда у тебя появляются два мастера, после того как две стойки перестают видеть друг друга на 10 секунд.
G>Только при наличии существенных ограничений на функциональность системы можно где-то ослаблять consistency.
Tradeoff же.
Здравствуйте, chaotic-kotik, Вы писали:
G>>То есть ты согласен, что это совсем не тот availability о котом говорят в контексте HA? CK>Это не тот availability, о котором пишет статья в википедии вот тут — https://en.wikipedia.org/wiki/High-availability_cluster но в контексте NoSQL важен и этот тоже. CK>Ес-но, все понимают что надежность всей системы = надежности самого слабого звена, поэтому каким бы хорошим не был твой алгоритм репликации, если ты не позаботился о более базовых вещах (таких как резервное питание), то твой алг. репликации не надежнее этих базовых вещей. Все эти разговоры про САР и NoSQL они очень сильно связаны с HA, так как оно все про избавление от SPOF чаще всего.
Так всетаки про какой availability идет речь в контексте NoSQL? Который CAP или который общечеловечский?
G>>И разу следующий вопрос — в чем ценность свойства liveness? Какие гарантии или преимущества оно дает? На практике никаких. CK>На практике, это важно тогда, когда возможность сохранить данные важнее целостности.
В этом случае давно придумано решение — сохранять на локальный диск или inprocess базу, а потом синхронизировать. Не нужны никакие nosql движки.
Или другой вариант — пока сервер недоступен хранить в памяти приложения и повторять попытки сохранить надежно. Тоже лучше, чем писать в условно /dev/null.
CK>Данные мониторинга, финансовые данные и прочие области, где свежие данные важнее несвежих, всякие хранилища для которых латентность важнее целостности и тд. Я типичный пример с корзиной приводил, там целостность не важна, если будет конфликт — можно разрешить его на уровне приложения.
Не всегда конфликт можно разрулить на уровне приложения. И что делать в этом случае если у тебя AP система? Молиться?
Если бы клиент мог управлять свойствами системы при записи или можно было бы поделить систему на CA\CP\AP куски заранее, то проблема бы решалась. Но на практике мы этого не видим.
CK>Обеспечение целостности требует кворума (а это 5-3 раундртипа для paxos-а и не помню сколько для 2PC). А AP система (тот же ES) тупо сохранит локально, а репликация будет выполняться асинхронно, т.е. 1-2 раундтрипа. Плюс, ты тут гарантированно не получишь отлуп из-за того, что произошел конфликт транзакции или что-нибудь в этом духе.
и?
G>>Можно, нужны будут дополнительные гарантии из области Consistency, которые приведут к противоречию с теоремой. CK>Реальные системы обычно и не являются чистыми AP или СР системами. Для разных операций разные гарантиии, например в рамках одной записи могут работать транзакции, но в целом, система может быть eventually consistent (за счет чего и достигается масштабируемость).
Прости, но CAP рассматривает свойства бинарно, либо есть, либо нет. Нельзя быть немного беременным.
На практике это означает, что большинство систем только притворяются partition tolerant или имеют это свойство в readonly режиме. А при записи теряют сразу все свойства
CK>>>Вот представь себе веб-приложение — интернет магазин. Ты жмешь кнопку — "добавить в корзину", страница берет и зависает. Даунтайма нет, все работает, просто на хост, на котором крутится БД, пришло очень много запросов и он немного тупит, из-за чего отвечает на запросы с задержкой, из-за чего консенсус долго работает и иногда вообще отваливается. Но если бы система была AP, то запрос на запись пошел бы сразу на несколько хостов и success вернулся бы сразу, как только один из них вернул бы success. G>>Но тогда появляется гораздо интереснее сценарий. G>>Ты делаешь checkout и проводишь оплату "внутренней валютой". Транзакция с уменьшением баланса улетает на два сервера, один из которых затупил, а второй подумал, что он уже мастер. После синхронизации у тебя дважды сняли деньги. G>>Ты же сам привел аналогичный пример ниже.
CK>Биллинг можно сделать на чем-нибудь другом.
Тогда и все остальное можно сделать на другом.
На этом предлагаю закончить.
CK>Как минимум, CAP утверждает что все три свойства нельзя иметь, если сеть разделена, но если все ок (а все ок большую часть времени), можно иметь одновременно и целостность и доступность. Я не понял почему partition tolerant системы не могут сохранить согласованность данных через любое длительное время?
Потому что записи, пришедшие в разные ноды вызовут конфликт и не факт что его вообще можно решить. Eventual consistency реально работает, когда нет записей на протяжении интервала достижения согласованности. Это у Гилберт и Линч написано черным по английскому.
Я на хабре приводил пример с продажей билетов.
G>>По-моему из этого всего можно сделать вывод, что ни availability, ни partition tolerance в реальном мире не помогают строить надежные системы. CK>Вывод из этого следует такой — нельзя делать системы без partition tolerance.
Все указанные в примерах системы были AP
Получается нельзя строить системы без consistency. Ровно о том, что я говорю.
G>>Единственный живой вариант — делать CA системы, то есть кворумы с node majority. CK>Ну назови хоть одну живую СА систему? Это не работает в реальном мире. СА система, это когда у тебя появляются два мастера, после того как две стойки перестают видеть друг друга на 10 секунд.
Node majority это когда новый мастер выбирается N/2+1 голосов. Естественно голосов должно быть нечетное количество. Если две стойки перестали видеть друг друга — два мастера не появится.
За несколько лет сделал более десятка отказоустойчивых SQL Server, которые именно так и работают.
G>>Только при наличии существенных ограничений на функциональность системы можно где-то ослаблять consistency. CK>Tradeoff же.
Существенные ограничения должны идти в начале разговора. Пока они не указаны единственно верное решение — кластеры РСУБД.
Здравствуйте, gandjustas, Вы писали:
G>Так всетаки про какой availability идет речь в контексте NoSQL? Который CAP или который общечеловечский?
Я уже запутался. Я топил за NoSQL и availability в этом контексте, Sinclair за все хорошее и против всего плохого.
G>В этом случае давно придумано решение — сохранять на локальный диск или inprocess базу, а потом синхронизировать. Не нужны никакие nosql движки. G>Или другой вариант — пока сервер недоступен хранить в памяти приложения и повторять попытки сохранить надежно. Тоже лучше, чем писать в условно /dev/null.
Костыль же жуткий. Но пока ты хранишь inprocess — приходят новые данные и ты не можешь их записать, пока не запишешь то что хранишь inprocess. Легко может наступить ситуация, когда у тебя память кончится до того как ты все запишешь. Помимо этого нужно будет как-то прозрачно дать доступ к тому что ты хранишь в памяти. Намного проще писать в эластик, например, и не думать об этом вообще. А если запись отвалилась — то выбрать следующую ноду по round robin и продолжать писать в нее. К тому же, если мы говорим о веб системах, то ты там тупо не сможешь ничего в памяти держать, так как у тебя на каждый запрос создается новый процесс и весь стейт в БД.
G>Не всегда конфликт можно разрулить на уровне приложения. И что делать в этом случае если у тебя AP система? Молиться?
Так никто ведь не заставляет в такой БД хранить такие данные, для которых ты не можешь разрулить конфликт.
G>Если бы клиент мог управлять свойствами системы при записи или можно было бы поделить систему на CA\CP\AP куски заранее, то проблема бы решалась. Но на практике мы этого не видим.
Обычно так и есть. В той же монге, у клиента есть возможноть тупо записать данные в хранилище, как в АР систему, безусловно. А можно сделать CAS update и получить CP систему на уровне одного документа. Или вот zookeeper — по дефолту запись туда — СР, а чтение — АР. На запись запускается консенсус, а на чтение нет, поэтому даже если запись невозможна(отсутствует связь с большинством машин), можно все равно читать старые данные. Но можно читать данные через sync и в этом случае консенсус будет гоняться на чтение и оно будет уже не АР а СР.
CK>>Обеспечение целостности требует кворума (а это 5-3 раундртипа для paxos-а и не помню сколько для 2PC). А AP система (тот же ES) тупо сохранит локально, а репликация будет выполняться асинхронно, т.е. 1-2 раундтрипа. Плюс, ты тут гарантированно не получишь отлуп из-за того, что произошел конфликт транзакции или что-нибудь в этом духе. G>и?
И латентность будет ниже, а пропускная способность выше.
G>Прости, но CAP рассматривает свойства бинарно, либо есть, либо нет. Нельзя быть немного беременным. G>На практике это означает, что большинство систем только притворяются partition tolerant или имеют это свойство в readonly режиме. А при записи теряют сразу все свойства
Не понял ход мысли. Смотри, можно как zookeeper или etcd гонять консенсус для всех транзакций и обеспечивать с его помощью полную линеаризуемость, можно не гонять его для операций чтения, только для записи и получить сериализуемость. Можно разделить данные на части и гонять консенсус только для тех данных, которые должны быть согласованными, а для тех что не должны, можно гонять консенсус параллельно (например можно иметь транзакции, работающие в рамках одной таблицы или одной записи/документа, получится что если мы пишем в два документа, то две параллельные транзакции запустят два независимых инстанса алгоритма консенсуса, это работает быстрее и лучше масштабируется, но нельзя согласовать данные в двух документах).
CK>>Как минимум, CAP утверждает что все три свойства нельзя иметь, если сеть разделена, но если все ок (а все ок большую часть времени), можно иметь одновременно и целостность и доступность. Я не понял почему partition tolerant системы не могут сохранить согласованность данных через любое длительное время? G>Потому что записи, пришедшие в разные ноды вызовут конфликт и не факт что его вообще можно решить. Eventual consistency реально работает, когда нет записей на протяжении интервала достижения согласованности. Это у Гилберт и Линч написано черным по английскому. G>Я на хабре приводил пример с продажей билетов.
И да и нет. Если записи просто изменят значение, то да, будет конфликт. Но ты можешь использовать CRDT и просто добавить данные на обоих нодах, а потом слить все вместе.
CK>>Вывод из этого следует такой — нельзя делать системы без partition tolerance. G>Все указанные в примерах системы были AP
В статье есть примеры и с VoltDB и с монгой.
G>Node majority это когда новый мастер выбирается N/2+1 голосов. Естественно голосов должно быть нечетное количество. Если две стойки перестали видеть друг друга — два мастера не появится.
Это если нет автоскейлинга, заранее известен состав кластера и машины добавляются в него ручками. Ну это работает, я согласен, так можно жить. Но это не CA система. В зависимости от того как ты выбираешь мастера — система может быть СР, так как если поляжет больше половины машин, ты просто не выберешь нового мастера. Я конечно не знаю как там все работает, но подозреваю, что если нет автоскейлинга и failure детектора, то кластер не поймет что для консенсуса нужно меньше машин, а если он есть и алгоритм выбора лидера не partition tolerant, то две независимые части могут выбрать себе по мастеру.
G>За несколько лет сделал более десятка отказоустойчивых SQL Server, которые именно так и работают.
А как данные реплицируются и откуда клиенты читают данные? Просто если стойки друг друга не видят, то где гарантия что ты не прочитаешь устаревшие данные? Данные на slave-е могут быть непротиворечивыми с точки зрения ACID гарантий, но при этом отличаться от мастера.
G>Существенные ограничения должны идти в начале разговора. Пока они не указаны единственно верное решение — кластеры РСУБД.
Я бы сказал что не существует дефолтного решения. РСУБД это клево и очень широко применимо (а многим адептам NoSQL нужно просто выучить SQL наконец и выкинуть монгу на помойку), но не универсально, как и NoSQL решения. Я не могу представить РСУБД кластер, который будет в состоянии заменить наш сетап
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, gandjustas, Вы писали:
G>>В этом случае давно придумано решение — сохранять на локальный диск или inprocess базу, а потом синхронизировать. Не нужны никакие nosql движки. G>>Или другой вариант — пока сервер недоступен хранить в памяти приложения и повторять попытки сохранить надежно. Тоже лучше, чем писать в условно /dev/null. CK>Костыль же жуткий.
Вовсе нет. Во многом даже проще, чем трахаться со скорость. записи в общее хранилище. Только прочитать сразу данные не сможешь.
CK>Но пока ты хранишь inprocess — приходят новые данные и ты не можешь их записать, пока не запишешь то что хранишь inprocess. Легко может наступить ситуация, когда у тебя память кончится до того как ты все запишешь.
Тогда и распределенной базы будет та же проблема.
CK>Помимо этого нужно будет как-то прозрачно дать доступ к тому что ты хранишь в памяти. Намного проще писать в эластик, например, и не думать об этом вообще. А если запись отвалилась — то выбрать следующую ноду по round robin и продолжать писать в нее.
Да, всего-то пару серверов нужно еще, со всеми вытекающими проблемами
CK>К тому же, если мы говорим о веб системах, то ты там тупо не сможешь ничего в памяти держать, так как у тебя на каждый запрос создается новый процесс и весь стейт в БД.
Ты точно делал веб-сервисы? По процессу на запрос это сильно.
G>>Не всегда конфликт можно разрулить на уровне приложения. И что делать в этом случае если у тебя AP система? Молиться? CK>Так никто ведь не заставляет в такой БД хранить такие данные, для которых ты не можешь разрулить конфликт.
Я бы больше сказал, я даже не хочу разруливать конфликты, хочу чтобы конкурентный доступ база на себя взяла, она для этого создана. Внезапно NoSQL при такой постановке вопроса начинают сосать. И сразу вспоминают про CAP.
CK> На запись запускается консенсус, а на чтение нет, поэтому даже если запись невозможна(отсутствует связь с большинством машин), можно все равно читать старые данные. Но можно читать данные через sync и в этом случае консенсус будет гоняться на чтение и оно будет уже не АР а СР.
Когда кто-нить запилит продажу билетов на такой системе я поверю, что она жизнеспособна, пока только голословные заверения.
CK>И латентность будет ниже, а пропускная способность выше.
Про быстродействие еще ни слова не было.
CK>Смотри, можно как zookeeper или etcd гонять консенсус для всех транзакций и обеспечивать с его помощью полную линеаризуемость, можно не гонять его для операций чтения, только для записи и получить сериализуемость. Можно разделить данные на части и гонять консенсус только для тех данных, которые должны быть согласованными, а для тех что не должны, можно гонять консенсус параллельно (например можно иметь транзакции, работающие в рамках одной таблицы или одной записи/документа, получится что если мы пишем в два документа, то две параллельные транзакции запустят два независимых инстанса алгоритма консенсуса, это работает быстрее и лучше масштабируется, но нельзя согласовать данные в двух документах).
Обязательно посмотрю на zookeeper.
CK>И да и нет. Если записи просто изменят значение, то да, будет конфликт. Но ты можешь использовать CRDT и просто добавить данные на обоих нодах, а потом слить все вместе.
Давай подробный сценаий кто к кому и вкакой момент обращается.
CK>>>Вывод из этого следует такой — нельзя делать системы без partition tolerance. G>>Все указанные в примерах системы были AP CK>В статье есть примеры и с VoltDB и с монгой.
Про VoltDB не в курсе, а монго — AP при чтении (возвращает мусор), а при записи вообще гарантий не дает.
G>>Node majority это когда новый мастер выбирается N/2+1 голосов. Естественно голосов должно быть нечетное количество. Если две стойки перестали видеть друг друга — два мастера не появится. CK>Это если нет автоскейлинга, заранее известен состав кластера и машины добавляются в него ручками.
Автоскейлинг мешает знать состав кластера?
CK>Ну это работает, я согласен, так можно жить. Но это не CA система. В зависимости от того как ты выбираешь мастера — система может быть СР, так как если поляжет больше половины машин, ты просто не выберешь нового мастера. Я конечно не знаю как там все работает, но подозреваю, что если нет автоскейлинга и failure детектора, то кластер не поймет что для консенсуса нужно меньше машин, а если он есть и алгоритм выбора лидера не partition tolerant, то две независимые части могут выбрать себе по мастеру.
В реальности вероятность полегания двух машин из трех в кластере мала, менее 0,01%, то есть 4 девятки на них спокойно живут.
G>>За несколько лет сделал более десятка отказоустойчивых SQL Server, которые именно так и работают. CK>А как данные реплицируются и откуда клиенты читают данные? Просто если стойки друг друга не видят, то где гарантия что ты не прочитаешь устаревшие данные? Данные на slave-е могут быть непротиворечивыми с точки зрения ACID гарантий, но при этом отличаться от мастера.
Зависит от конфигурации. Чаще всего синхронная readable реплика. В Always on таких может быть две.
G>>Существенные ограничения должны идти в начале разговора. Пока они не указаны единственно верное решение — кластеры РСУБД. CK>Я бы сказал что не существует дефолтного решения. РСУБД это клево и очень широко применимо (а многим адептам NoSQL нужно просто выучить SQL наконец и выкинуть монгу на помойку), но не универсально, как и NoSQL решения. Я не могу представить РСУБД кластер, который будет в состоянии заменить наш сетап
Я бы сказал что существует, пока нет серьезных оснований использовать что-то другое.
По странному стечению обстоятельств в большинстве случаев использования той же монги её можно было заменить postgres без потери каких либо качеств для программы.
Здравствуйте, gandjustas, Вы писали:
G>Вовсе нет. Во многом даже проще, чем трахаться со скорость. записи в общее хранилище. Только прочитать сразу данные не сможешь.
И как это решает пролему latency? Throughput — да, согласен, можно батчингом на клиенте заниматься. Но это ломает crush recovery и латентность увеличивает.
CK>>Но пока ты хранишь inprocess — приходят новые данные и ты не можешь их записать, пока не запишешь то что хранишь inprocess. Легко может наступить ситуация, когда у тебя память кончится до того как ты все запишешь. G>Тогда и распределенной базы будет та же проблема.
Может конечно. Но тут есть варианты всегда, в тот же HBase можно писать данные так, чтобы нагрузка равномерно распределялась по regionserver-ам. Для этого нужно правильную схему выбрать, вот и вся сложность.
CK>>К тому же, если мы говорим о веб системах, то ты там тупо не сможешь ничего в памяти держать, так как у тебя на каждый запрос создается новый процесс и весь стейт в БД. G>Ты точно делал веб-сервисы? По процессу на запрос это сильно.
Так работает apache с mod_php в prefork MPM режиме. На каждый http реквест запускается новый процесс. Соотв. весь стейт живет в БД и всяких мемкешах и прочих редисах. Я участвовал в разработке веб портала с милионной аудиторией в одной очень известной российской компании.
CK>>И да и нет. Если записи просто изменят значение, то да, будет конфликт. Но ты можешь использовать CRDT и просто добавить данные на обоих нодах, а потом слить все вместе. G>Давай подробный сценаий кто к кому и вкакой момент обращается.
Ты делаешь чекаут и проводишь оплату внутренней валютой. Транзакция не уменьшает баланс, а добавляет операцию в список операций над твоим балансом, commit транзакции выполняется через консенсус (Paxos например). Такое можно нарулить на кассандре, например.
CK>>Это если нет автоскейлинга, заранее известен состав кластера и машины добавляются в него ручками. G>Автоскейлинг мешает знать состав кластера?
Не мешает, просто автоскейлинг означает не только то, что машины могут добавляться в кластер автоматически, но и то, что они оттуда могут точно также выбывать. Допустим у нас 3 машины. Моргнула сеть, машина (мастер), живущая в отдельной стойке, стала недоступна. Но так как этого "не может быть" (система построена из расчета что сеть абсолютно надежна и partition-ов не бывает) система должна решить что эта машина умерла, правильно? И что она в этом случае делает? Логично выбрать нового мастера из оставшихся двух живых и считать что старый мастер покинул кластер (кластер теперь состоит из двух машин). При этом временно изолированный на отдельной стойке мастер продолжает считать себя мастером, недоступные две оставшиеся машины он считает покинувшими кластер (автоскейлинг же).
G>Зависит от конфигурации. Чаще всего синхронная readable реплика. В Always on таких может быть две.
Ну т.е. обычный master-slave без шардинга.
G>По странному стечению обстоятельств в большинстве случаев использования той же монги её можно было заменить postgres без потери каких либо качеств для программы.
Ну монга это вообще булшит, понятно что постгрес лучше. Единственный плюс монги — простота развертывание и настройки, поэтому ее в основном используют для всяких мелких CRUD-ов.
Здравствуйте, chaotic-kotik, Вы писали:
CK>Здравствуйте, gandjustas, Вы писали:
G>>Вовсе нет. Во многом даже проще, чем трахаться со скорость. записи в общее хранилище. Только прочитать сразу данные не сможешь. CK>И как это решает пролему latency? Throughput — да, согласен, можно батчингом на клиенте заниматься. Но это ломает crush recovery и латентность увеличивает.
А есть эта проблема?
Вообще подходы такие:
1) Нужно часто читать и нечасто записывать (типичное приложение) — используем кэш
2) Нужно часто записывать и нечасто читать (ака логи, репортинг) — примитивный сторедж на запись (локальный диск) и асинхронная постобработка
3) Нужно часто читать и писать отдельные куски (соцсети) — разбиваем модель данных на маленькие несвязанные кусочки, кусочки держим и обновляем в кеше, при записи или изолируем IO кусочков (шардинг, разные диски) или применяем метод из 2
4) Нужно часто писать и читать агрегированные данные — stream processing, то есть держим в памяти данные для агрегации, пишем только агрегаты.
Я так понимаю, что мы про пункт №2 сейчас
CK>>>Но пока ты хранишь inprocess — приходят новые данные и ты не можешь их записать, пока не запишешь то что хранишь inprocess. Легко может наступить ситуация, когда у тебя память кончится до того как ты все запишешь. G>>Тогда и распределенной базы будет та же проблема. CK>Может конечно. Но тут есть варианты всегда, в тот же HBase можно писать данные так, чтобы нагрузка равномерно распределялась по regionserver-ам. Для этого нужно правильную схему выбрать, вот и вся сложность.
Опять для простой задачи — "как бы сделать так, чтобы весь поток данных записывался за ограниченное время в случаях отказа\недоступности серверов бд" вы пытаетесь продать решение, которое требует еще несколько серверов. Это приведет или к замедлению за счет кворума или к потере согласованности, что хуже, чем иногда давать клиенту ответ "сейчас не могу, попробуй позже".
CK>>>К тому же, если мы говорим о веб системах, то ты там тупо не сможешь ничего в памяти держать, так как у тебя на каждый запрос создается новый процесс и весь стейт в БД. G>>Ты точно делал веб-сервисы? По процессу на запрос это сильно.
CK>Так работает apache с mod_php в prefork MPM режиме. На каждый http реквест запускается новый процесс. Соотв. весь стейт живет в БД и всяких мемкешах и прочих редисах. Я участвовал в разработке веб портала с милионной аудиторией в одной очень известной российской компании.
Вас никто не заставляет также делать. Пользуйтесь нормальными серверами. IIS например и нормальными базами — SQL Server, а не mysql.
Сразу количество проблем с РСУБД и вебом поубавится и всякие "леворезьбовые" технологии не понадобятся.
CK>>>И да и нет. Если записи просто изменят значение, то да, будет конфликт. Но ты можешь использовать CRDT и просто добавить данные на обоих нодах, а потом слить все вместе. G>>Давай подробный сценаий кто к кому и вкакой момент обращается.
CK>Ты делаешь чекаут и проводишь оплату внутренней валютой. Транзакция не уменьшает баланс, а добавляет операцию в список операций над твоим балансом, commit транзакции выполняется через консенсус (Paxos например). Такое можно нарулить на кассандре, например.
Не так быстро:
1) У тебя есть две ноды, которые асинхронно реплицируют данные и в любой момент может потеряться любое количество пакетов между узлами и клиентами.
2) У тебя есть приложение, которое в момент чекаута добавляет проводку в базу
3) Ты хочешь чтобы транзакция проходила всегда
4) Ты пытаешься добавить проводку сразу в две ноды
5) Но вторая нода оказывается недоступна, там баланс не меняется.
6) В этот же момент с друого сервера приложений отправляется аналогичная команда на снятие внутренней валюты, но для нее теперь певая нода недоступно
7) Получается у тебя две ноды, на одной баланс -50, на второй -70
8) Но на счете всего было 100 до начала двух транзакций.
CAP в этом случае не обманешь. AP системы не подходят для хранения важных данных (которые нельзя исказить, потерять, нарушить инварианты) в принципе. Прикладные механизмы разрешения конфликтов не помогут, ты можешь конфликт обнаружить позже, чем будет принято решение на основании неверных данных.
CK>>>Это если нет автоскейлинга, заранее известен состав клас
тера и машины добавляются в него ручками. G>>Автоскейлинг мешает знать состав кластера? CK>Не мешает, просто автоскейлинг означает не только то, что машины могут добавляться в кластер автоматически, но и то, что они оттуда могут точно также выбывать. Допустим у нас 3 машины. Моргнула сеть, машина (мастер), живущая в отдельной стойке, стала недоступна. Но так как этого "не может быть" (система построена из расчета что сеть абсолютно надежна и partition-ов не бывает) система должна решить что эта машина умерла, правильно? И что она в этом случае делает? Логично выбрать нового мастера из оставшихся двух живых и считать что старый мастер покинул кластер (кластер теперь состоит из двух машин). При этом временно изолированный на отдельной стойке мастер продолжает считать себя мастером, недоступные две оставшиеся машины он считает покинувшими кластер (автоскейлинг же).
Нет, node majority не так работает. Было 9 машин, сеть разделилась на 5 и 4. Там где 4 — не будет кворума, кластер не поднимется.
G>>Зависит от конфигурации. Чаще всего синхронная readable реплика. В Always on таких может быть две. CK>Ну т.е. обычный master-slave без шардинга.
Да. По сути единственно рабочий вариант. Все multimnaster системы страдают от нарушения согласованности, чего в большинстве случаев допускать нельзя.
Шардинг это вообще не про доступность, а про деление нагрузки на разные физические узлы. В случае субд не нужно, они масштабируются путем добавления дисков, а не серверов.
G>>По странному стечению обстоятельств в большинстве случаев использования той же монги её можно было заменить postgres без потери каких либо качеств для программы. CK>Ну монга это вообще булшит, понятно что постгрес лучше. Единственный плюс монги — простота развертывание и настройки, поэтому ее в основном используют для всяких мелких CRUD-ов.
Тем не менее самая массовая NoSQL база.
