Конечная согласованность

Как добиться высокой доступности и масштабируемости с помощью реляционных баз данных, хорошо известно, и есть обширные знания о том, как это сделать!

Google - это особый случай, который не распространяется на большинство сайтов, очень-очень большие объемы запросов, очень-очень большие объемы данных и, самое главное, отсутствие соглашений об уровне обслуживания с большинством его пользователей. Нет правильного ответа на поиск в Интернете, только лучшие ответы, для среднего пользователя Google достаточно хорош, если Google пропускает важную страницу из списка поиска, вы, как пользователь, не можете жаловаться.

E-Bay - это совсем другой случай, каким-то образом они убедили пользователей и клиентов согласиться на плохое обслуживание в обмен на теоретически более низкие цены - им это выгодно, но это не вариант для каждого бизнеса.

Если вы хотите иметь распределенную систему (то есть «конечную согласованность»), вам нужны люди, создающие, обслуживающие и управляющие ею.

Я обнаружил, что есть три класса людей, у которых очень мало проблем с «конечной согласованностью»:

• Люди с солидным опытом работы в распределенных системах. Они узнали о конечной согласованности Византийские неудачи и тому подобном. Если вы понимаете, что Паксос не о праздниках, вы, вероятно, один из них.
• Люди с опытом сетевого программирования. Они могут упустить теоретические основы, но имеют интуитивное понимание асинхронности и парадигмы «отсутствия глобальных часов и счетчиков». Если у вас есть как минимум 8 книг от Ричард Стивенс, вы, вероятно, одна из них.
• Очень опытные программисты, мало знакомые с РСУБД. На ум приходят ребята из ядра, люди из научных вычислений и игровой индустрии.

В целом эти люди очень востребованы на рынке труда. Например, около 75% преподавателей распределенных систем уходят в учреждения, которые используют большие распределенные системы собственной разработки, например фондовые биржи.

Все стало несколько проще с такими предложениями, как Hardoop, SimpleDB и CouchDB, но все еще остается большой проблемой создать что-то на основе технологии распределенных систем.

С другой стороны, РСУБД - прекрасная составляющая инженерии. Их хорошо понимают, и их опыт доступен на рынке труда. Есть много достойных инструментов, возможностей для обучения и много высококвалифицированных специалистов, которых можно нанять почасово. Так что подумайте дважды: у вас не получится использовать подход РСУБД - возможно, в сочетании с хитрым обманом. Я обычно указываю студентам на Архитектура Lifejournal.

Для распределенных баз данных гораздо меньше опыта. Именно по этой причине вы до сих пор нашли так мало советов.

Если вы настроены использовать «конечную согласованность», я думаю, что помимо незрелых инструментов, главная проблема - это образ мышления всех участников. Готовы ли ваши пользователи API (кодировщики) и пользователи приложений (ваши сотрудники и клиенты) принять несоответствие? Можете ли вы скрыть это от определенных классов пользователей? Мы не привыкли считать, что компьютеры несовместимы. Что-то есть в наличии или нет. «Может быть» - не тот ответ, которого ожидают пользователи.

Также имейте в виду, что «в конечном итоге» для разработчиков алгоритмов может означать очень много времени. Как долго вы можете мириться с непоследовательностью?

Для приложения корзины покупок вы можете захотеть стать действительно распределенным: используйте клиентский браузер в качестве хранилища данных. При оформлении заказа вы можете отправить корзину в систему пакетной обработки на стороне сервера. Это означает, что для каталога вам нужно только чтение, высокая доступность (проще), а отправка корзины - это очень узкий интерфейс, не требующий транзакций. Позже обработка заказа не требует (мягкого) реального времени и, следовательно, становится проще.

Кстати: в прошлый раз я проверял архитектуру E-Bay, они были большими в РСУБД, но с тех пор она, возможно, изменилась. (Редактировать: изменилось - см. Комментарии)

Все системы, построенные на моделях распределенных вычислений, построены на CAP и BASE. Здесь основная проблема заключается в том, что если наша система обеспечивает доступность и допуск на разделы, у нас не может быть истинной согласованности, но мы можем иметь согласованность в конечном итоге.

Идея конечной согласованности заключается в том, что каждый узел всегда доступен для обслуживания запросов. В качестве компромисса изменения данных распространяются в фоновом режиме на другие узлы. Это означает, что в любой момент система может быть непоследовательной, но данные по-прежнему в значительной степени точны.

Источник: http://www.techspritz.com/eventual-consistency-and-base-model/

Единственное решение вашей проблемы - решить, какие компромиссы в CAP теорема вам подходят, а затем приступить к его реализации.

mdorseif имеет большое значение. Существует множество вариантов компромисса между согласованностью, доступностью и разделением. У вас есть два основных варианта.

1. Пойдите по пути собственной распределенной системы (требует большого опыта и исследований)
2. Протестируйте и поэкспериментируйте с несколькими распределенными базами данных, чтобы решить, что может удовлетворить ваши требования в качестве масштабируемого.

Вероятно, это чрезмерное упрощение. Настоящий готовый к производству трубопровод - это экосистема. По крайней мере, это приведет вас на верный путь.

Appnexus - это рекламная платформа, которая использует hbase для очень высокой доступности и возможной согласованности. Они много говорят об этом здесь.

статья на http://highscaleability.com описывает, как New York Times реализовала RabbitMQ вместе с Кассандра в глобальной сети для обеспечения отказоустойчивости и высокой доступности.

MongoDB обеспечивает большую гибкость в балансировании согласованности и доступности с их реализацией проблем записи. У них есть отличный документация, который показывает, как именно его реализовать, со всеми подводными камнями (включая разбиение). Они реализуют двухфазная фиксация для поддержания состояния в сети (на своих серверах конфигурации).

У Google есть отличная статья на эту тему, их проект фотон реализует высокомасштабируемую и высоконадежную систему с алгоритм paxos в его основе наряду с несколькими другими методами. Кроме того, он очень согласован (со сквозной задержкой около 10 с) и отказоустойчив, противостоит региональным сбоям.