Последнее время увлекаюсь системами с одно ранговой репликацией. Например Master-master. К сожалению основными примерами применения таких систем являются Одноклассники, Фесбук, да Твитер. Вроде бы современные алгоритмы, позволяют писать даже финансовый учет. Напрмер гранола и рафт Но при попытке найти примеры использования, создается впечатление что концепция эктив-эктив просто не пригодна для написания хоть сколько сложной бизенс-логики. Все практические применения работают на eventual-consistency, и обеспечивают лайки котиков. О остальных местах, для отказоустойчивости делается холодный резерв, разной степени "холодности". Не ужели active-active не пригоден для таких систем?
Вообще есть хоть одна фирма, со сложной бизнес логикой, использующая Active-Active? Например финансовой сферы? Тема конечно интересная но складывается впечатление, что кроме пары полу-домашних pet-проектов применить ее не где.
Re: Active-active системы только для лайков котиков?
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Finder_b, Вы писали:
F_>>Все практические применения работают на eventual-consistency, и обеспечивают лайки котиков.
W>Так тебе не нравится первое или второе? Какой именно контрпример тебе нужен?
Почему ты так решил? Просто eventual-consistency для лайков котиков — это самый простой алгоритм. И то используется только социальными сетями. Не ужели только социальные сети заботятся о высокой доступности, а остальным плевать на своих клиентов?
Re[2]: Active-active системы только для лайков котиков?
Здравствуйте, Ночной Смотрящий, Вы писали:
НС>Здравствуйте, Finder_b, Вы писали:
F_>>Все практические применения работают на eventual-consistency
НС>САР теорему никто пока не отменял.
Вообще отменили. Притом, еще до ее появления. Семейство алгоритмов Paxos (я выше приводил пару примеров) именно этим и занимается. Да есть ограничения, напрмер: При партиционировании доступность будет сохранятся только в большей половине кластера. А если разделить кластер ровно пополам, то не где не будет доступности.
Доступность пропадет при отказе половины нод и больше.
Даже гарантия работоспособности при отказе половины нод, очень трудно достижима. Скорее правильно говорить о любом количестве нод в одном датаценте.
Большинство алгоритмов имеют факториальную сложность. К счастью обычно, это либо факториал от числа датацентров, либо фактриал от числа нод, но только при смене конфигурации кластера.
Если менять конфигурацию кластера во время аварии, то сохранение consistency переходит в разряд черной магии.
И т.д.
Но в целом достигается именно то что нужно. При отказе оборудования, сбоях сети и т.п. для клиентов сервис остается доступным и консистентным. То что это справедливо не для все частей системы, пользователям на это начхать с высокой колокольни.
Здравствуйте, Finder_b, Вы писали:
F_>>>Все практические применения работают на eventual-consistency НС>>САР теорему никто пока не отменял. F_>Вообще отменили. Притом, еще до ее появления. Семейство алгоритмов Paxos (я выше приводил пару примеров) именно этим и занимается. Да есть ограничения, напрмер: F_>* При позиционировании доступность будет сохранятся только в большей половине кластера. А если разделить кластер ровно пополам, то не где не будет доступности.
Что и требовалось показать.
F_>* Доступность пропадет при отказе половины нод и больше.
Сфероиппологическая доступность — для сферических коней, а не обычных пользователей.
F_>Но в целом достигается именно то что нужно. При отказе оборудования, сбоях сети и т.п. для клиентов сервис остается доступным и консистентным. То что это справедливо не для все частей системы, пользователям на это начхать с высокой колокольни.
Только если они лайкают котиков. Иначе им нужны более осмысленные гарантии.
Здравствуйте, Finder_b, Вы писали:
F_>Почему ты так решил? Просто eventual-consistency для лайков котиков — это самый простой алгоритм. И то используется только социальными сетями. Не ужели только социальные сети заботятся о высокой доступности, а остальным плевать на своих клиентов?
Твоя постановка вопроса стала еще более непонятной. Попробуй переформулировать.
Re: Active-active системы только для лайков котиков?
Здравствуйте, Finder_b, Вы писали:
F_>Последнее время увлекаюсь системами с одно ранговой репликацией. Например Master-master. К сожалению основными примерами применения таких систем являются Одноклассники, Фесбук, да Твитер. Вроде бы современные алгоритмы, позволяют писать даже финансовый учет. Напрмер гранола и рафт Но при попытке найти примеры использования, создается впечатление что концепция эктив-эктив просто не пригодна для написания хоть сколько сложной бизенс-логики. Все практические применения работают на eventual-consistency, и обеспечивают лайки котиков. О остальных местах, для отказоустойчивости делается холодный резерв, разной степени "холодности". Не ужели active-active не пригоден для таких систем?
F_>Вообще есть хоть одна фирма, со сложной бизнес логикой, использующая Active-Active? Например финансовой сферы? Тема конечно интересная но складывается впечатление, что кроме пары полу-домашних pet-проектов применить ее не где.
У бизнеса свой взгляд на этот счет. Вот откажет бухгалтерия в местной пятёрочке, на ушах будет стоять только этот магазин, тысячи других продолжат работу, а раз в определенный интервал времени отчеты со всех магазинов собираются в одном месте и анализируются. Смысл в том, что технические отказы неизбежны, нужно минимизировать их стоимость, поэтому супернавороченная система может уступать простой из-за высокой стоимости отказа, стоимости разработки и стоимости обслуживания.
P.S. Как там на самом деле в пятерочках не знаю, привел только для примера того, что бизнес смотрит на эти вещи иначе.
Программа – это мысли спрессованные в код
Re[4]: Active-active системы только для лайков котиков?
Здравствуйте, wildwind, Вы писали:
W>Здравствуйте, Finder_b, Вы писали:
F_>>Почему ты так решил? Просто eventual-consistency для лайков котиков — это самый простой алгоритм. И то используется только социальными сетями. Не ужели только социальные сети заботятся о высокой доступности, а остальным плевать на своих клиентов?
W>Твоя постановка вопроса стала еще более непонятной. Попробуй переформулировать.
Я не помнимаю по чему active-active в режиме чтение-запись, используется только социальными сетями, и не используется в серьезных организациях. Может есть технологические ограничения, о которых я не знаю. Например система получается слишком сложной. Или просто всем безразлично удобство пользователей?
Re[4]: Active-active системы только для лайков котиков?
Здравствуйте, netch80, Вы писали:
N>Здравствуйте, Finder_b, Вы писали:
F_>>>>Все практические применения работают на eventual-consistency НС>>>САР теорему никто пока не отменял. F_>>Вообще отменили. Притом, еще до ее появления. Семейство алгоритмов Paxos (я выше приводил пару примеров) именно этим и занимается. Да есть ограничения, напрмер: F_>>1. При позиционировании доступность будет сохранятся только в большей половине кластера. А если разделить кластер ровно пополам, то не где не будет доступности. N>Что и требовалось показать.
Гм, что именно? Что такую систему нужно разворачивать в нечетном числе датаценторов, чтобы ее не возможно было разделить точно пополам?
F_>>2. Доступность пропадет при отказе половины нод и больше. N>Сфероиппологическая доступность — для сферических коней, а не обычных пользователей.
Понятие доступность весьма четко определено в сфере ИТ. Или ты разделяеш доступность на сфероиппологическую, и конкретную доступность, для конкретных пацанов?
F_>>Но в целом достигается именно то что нужно. При отказе оборудования, сбоях сети и т.п. для клиентов сервис остается доступным и консистентным. То что это справедливо не для все частей системы, пользователям на это начхать с высокой колокольни. N>Только если они лайкают котиков. Иначе им нужны более осмысленные гарантии.
А что ты подразумеваеш под осмысленными гарантиями. Раз тебя не устраивать работоспособность после падения половины серверов, то возможно это работоспособность ситемы после падения всех ее серверов?
F_>>Вообще есть хоть одна фирма, со сложной бизнес логикой, использующая Active-Active? Например финансовой сферы? Тема конечно интересная но складывается впечатление, что кроме пары полу-домашних pet-проектов применить ее не где. Q>У бизнеса свой взгляд на этот счет. Вот откажет бухгалтерия в местной пятёрочке, на ушах будет стоять только этот магазин, тысячи других продолжат работу, а раз в определенный интервал времени отчеты со всех магазинов собираются в одном месте и анализируются. Смысл в том, что технические отказы неизбежны, нужно минимизировать их стоимость, поэтому супернавороченная система может уступать простой из-за высокой стоимости отказа, стоимости разработки и стоимости обслуживания.
В целом с тобой согласен. Но ведь кроме бухгалтерии, может упасть сервер кассовых апаратов. Покупатели будут очень не довольны. Или сервер кторый обрабатывает транзакции с карт. Или интернет банк. А это потери тысяч клиентов. По чему нет упоминаний об active-active в таких областях?
Re[3]: Active-active системы только для лайков котиков?
Здравствуйте, Finder_b, Вы писали:
F_>Здравствуйте, Qulac, Вы писали:
F_>>>Вообще есть хоть одна фирма, со сложной бизнес логикой, использующая Active-Active? Например финансовой сферы? Тема конечно интересная но складывается впечатление, что кроме пары полу-домашних pet-проектов применить ее не где. Q>>У бизнеса свой взгляд на этот счет. Вот откажет бухгалтерия в местной пятёрочке, на ушах будет стоять только этот магазин, тысячи других продолжат работу, а раз в определенный интервал времени отчеты со всех магазинов собираются в одном месте и анализируются. Смысл в том, что технические отказы неизбежны, нужно минимизировать их стоимость, поэтому супернавороченная система может уступать простой из-за высокой стоимости отказа, стоимости разработки и стоимости обслуживания. F_>В целом с тобой согласен. Но ведь кроме бухгалтерии, может упасть сервер кассовых апаратов. Покупатели будут очень не довольны. Или сервер кторый обрабатывает транзакции с карт. Или интернет банк. А это потери тысяч клиентов. По чему нет упоминаний об active-active в таких областях?
Там на кассах системник стоит, в нем наверное коды и цены товаров хранятся. Если имеется в виду "горячию" замену серверов при отказе, то наверняка для этого что ни будь используется, только это не относится к архитектуре, просто у нас несколько серверов работают как один, но более надежный, поэтому наверное и не упоминают.
Программа – это мысли спрессованные в код
Re[3]: Active-active системы только для лайков котиков?
Здравствуйте, Finder_b, Вы писали:
W>>Так тебе не нравится первое или второе? Какой именно контрпример тебе нужен? F_>Почему ты так решил? Просто eventual-consistency для лайков котиков — это самый простой алгоритм. И то используется только социальными сетями. Не ужели только социальные сети заботятся о высокой доступности, а остальным плевать на своих клиентов?
В целом, да.
Там где нужна гарантированная целостность (финансы, логистика, ...), обычно не такой большой объём транзакций.
Sapienti sat!
Re[5]: Active-active системы только для лайков котиков?
Здравствуйте, Finder_b, Вы писали:
F_>Я не помнимаю по чему active-active в режиме чтение-запись, используется только социальными сетями, и не используется в серьезных организациях. Может есть технологические ограничения, о которых я не знаю. Например система получается слишком сложной.
Во-первых, не только соцсетями. Я тебе привел ссылку с примерами других систем. Ограничения, конечно, есть, в том числе и сложность. Прежде всего, иметь и поддерживать один узел в прнципе проще, чем несколько. И дешевле. Во многих случаях просто нет большой нужды в распределенности.
F_>Или просто всем безразлично удобство пользователей?
Здравствуйте, Finder_b, Вы писали:
F_>Последнее время увлекаюсь системами с одно ранговой репликацией. Например Master-master. К сожалению основными примерами применения таких систем являются Одноклассники, Фесбук, да Твитер. Вроде бы современные алгоритмы, позволяют писать даже финансовый учет. Напрмер гранола и рафт Но при попытке найти примеры использования, создается впечатление что концепция эктив-эктив просто не пригодна для написания хоть сколько сложной бизенс-логики. Все практические применения работают на eventual-consistency, и обеспечивают лайки котиков. О остальных местах, для отказоустойчивости делается холодный резерв, разной степени "холодности". Не ужели active-active не пригоден для таких систем?
F_>Вообще есть хоть одна фирма, со сложной бизнес логикой, использующая Active-Active? Например финансовой сферы? Тема конечно интересная но складывается впечатление, что кроме пары полу-домашних pet-проектов применить ее не где.
Несколько реплик (slave-вов) с выборами, в случае отвала чего-то, требует, во первых, в миллион раз меньше ресурсов на востановление в случае чего.
Что бы это знать не нужно быть узким специалистом.
А во вторых ты жалуешся на решение проблемы, а проблему так и не описал. чем этот active-active хорош?
Здравствуйте, Finder_b, Вы писали:
F_>Вообще есть хоть одна фирма, со сложной бизнес логикой, использующая Active-Active? Например финансовой сферы? Тема конечно интересная но складывается впечатление, что кроме пары полу-домашних pet-проектов применить ее не где.
В целом, какой-нибудь банк имеет с одного пользователя много-много долларов в год, а какой-нибудь фейсбук нет. Поэтому фейсбуку приходится искать экономичное решение, в отличии от. Ну и надо понимать, банки и прочий финансовый сектор — ребята очень консервативные, используют технологии, которые до них уже пару-тройку десятков лет кто-нибудь обкатывал.
Ну а так, Bitcoin вроде попадает под твой вопрос, не?
Re[4]: Active-active системы только для лайков котиков?
Здравствуйте, netch80, Вы писали:
F_>>Но в целом достигается именно то что нужно. При отказе оборудования, сбоях сети и т.п. для клиентов сервис остается доступным и консистентным. То что это справедливо не для все частей системы, пользователям на это начхать с высокой колокольни.
N>Только если они лайкают котиков. Иначе им нужны более осмысленные гарантии.
Ну в принципе, надо сказать, если мне банкомат выдал меньше бумажек, чем обещал (и списал со счета), то мне, по большому счету, все равно, CAP теорема в этом виновата, или вожделенная бумажка механически застряла внутри банкомата.
Жене однажды банкомат недосыпал денег. Заявление в банк она писала, получила ответ, что банкомат инкассировали, и бесхозных денег в нем не нашли, так что она со своими претензиями может пойти, куда подальше.
Re[5]: Active-active системы только для лайков котиков?
Здравствуйте, Pzz, Вы писали:
F_>>>Но в целом достигается именно то что нужно. При отказе оборудования, сбоях сети и т.п. для клиентов сервис остается доступным и консистентным. То что это справедливо не для все частей системы, пользователям на это начхать с высокой колокольни. N>>Только если они лайкают котиков. Иначе им нужны более осмысленные гарантии. Pzz>Ну в принципе, надо сказать, если мне банкомат выдал меньше бумажек, чем обещал (и списал со счета), то мне, по большому счету, все равно, CAP теорема в этом виновата, или вожделенная бумажка механически застряла внутри банкомата.
В случае банкомата, скорее всего, начальное списание делается жёстко онлайн (если пропала связь, то он прерывает пробу), но с момента подтверждения блоком выдачи, что у него сформирован пакет бумажек на выдачу — то в нём ставится факт выдачи в очередь, которая фиксируется на диск и потом при подъёме связи досинхронизуется.
Связи между системами, в пределах которых проходят транзакции — между банками, а часто и между их частями — делаются аналогично: постоянный канал обмена сообщениями, уникальные идентификаторы, статусы частично выполненных операций и обновление статусов по приходу квитанций от удалённого исполнителя.
Pzz>Жене однажды банкомат недосыпал денег. Заявление в банк она писала, получила ответ, что банкомат инкассировали, и бесхозных денег в нем не нашли, так что она со своими претензиями может пойти, куда подальше.
Не выдали совсем или выдали меньше?
Это вообще отдельная тема: могла и секьюрити смошенничать, часть могла застрять и быть довыданным кому-то ещё, могли внешние мошенники поставить блокировку на лоток (работает со многими старыми исполнениями).
The God is real, unless declared integer.
Re[5]: Active-active системы только для лайков котиков?
Здравствуйте, Finder_b, Вы писали:
F_>>>>>Все практические применения работают на eventual-consistency НС>>>>САР теорему никто пока не отменял. F_>>>Вообще отменили. Притом, еще до ее появления. Семейство алгоритмов Paxos (я выше приводил пару примеров) именно этим и занимается. Да есть ограничения, напрмер: F_>>>1. При позиционировании доступность будет сохранятся только в большей половине кластера. А если разделить кластер ровно пополам, то не где не будет доступности. N>>Что и требовалось показать. F_>Гм, что именно? Что такую систему нужно разворачивать в нечетном числе датаценторов, чтобы ее не возможно было разделить точно пополам?предпа
В первую очередь, что возможен такой уровень потери доступности, при котором система перестаёт работать, несмотря на доступность части узлов (включая тот, через который конкретный клиент входит в неё).
Во вторую очередь — то, что в Paxos есть только гарантия "сойтись когда-нибудь в будущем", без конкретики, в то время как любые реальные задачи предполагают конкретное фиксированное ограничение времени, в течение которого запрошенное изменение должно быть финализировано у всех.
Здесь уже было несколько обширных серьёзных обсуждений CAP, и одним из ключевых аспектов интерпретации было как раз то, что делать с "eventual consistency" при отсутствии внятных гарантированных ограничений на сходимость.
И это ещё не начали вспоминать проблему транзакционности групповых изменений: все осмысленные теоретические результаты сейчас строятся в таких изменениях, которые для ACID-like транзакционности или имеют размер добавления/изменения/удаления одного ключа, или могут зафейлиться на заметной части участников просто из-за нормального конкурирующего изменения (например, где мы условием ставим что какой-нибудь sum() по подвыборке равен конкретному значению, это равенство не выполняется нигде, кроме ближайшего узла).
