Возможная последовательность

Question

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

Я ищу реальный совет, лучшие практики и хит-парады, которые нужно учитывать при работе с распределенными / документными базами данных. И особенно в областях, связанных с приложениями электронной коммерции (в стиле корзины покупок), которые традиционно проще собрать вместе с реляционной базой данных.

Я понимаю, что использование этих типов БД является сложной задачей, но эй, Google и E-bay используют их, поэтому они не могут быть такими сложными ;-) Любой совет будет оценен.

Answer 1

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

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

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

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

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

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

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

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

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

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

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

Answer 2

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

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

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

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

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

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

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

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

Answer 3

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

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

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

Answer 4

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

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

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