Возможная последовательность
Я нахожусь на ранних стадиях разработки приложения, которое должно быть высокодоступным и масштабируемым. Я хочу использовать модель данных возможной согласованности для этого по ряду причин. Я знаю и понимаю, почему это непопулярный архитектурный выбор для многих решений, но это важно в моем случае.
Я ищу реальные советы, передовые практики и хит-парады, которые нужно учитывать при работе с распределенными / документными базами данных. И особенно в областях, связанных с приложениями электронной коммерции (в стиле корзины покупок), которые традиционно проще собрать вместе с реляционными базами данных.
Я понимаю, что использование этих типов БД является сложной задачей, но эй, Google и E-bay используют их, поэтому они не могут быть такими сложными;-) Любой совет будет оценен.
4 ответа
Если вы хотите иметь Распределенную Систему (эта "конечная согласованность"), вы нуждаетесь в людях, создаете, обслуживаете и эксплуатируете ее.
Я обнаружил, что есть три класса людей, у которых очень мало проблем с "Возможной последовательностью":
- Люди с солидным опытом работы в распределенных системах. Они узнали о возможных византийских провалах и тому подобное. Если вы понимаете, что Паксос не о праздниках, вы, вероятно, один из них.
- Люди опытные в сетевом программировании. Они могут пропустить теоретические основы, но имеют интуитивное понимание асинхронности и парадигмы "нет глобальных часов и счетчиков". Если у вас есть как минимум 8 книг Ричарда Стивенса, вы, вероятно, одна из них.
- Очень опытные программисты, мало знакомые с RDBMS. На ум приходят ребята из ядра, люди из научных вычислений и игровой индустрии.
В целом, эти люди очень востребованы на рынке труда. Например, около 75% преподавателей в распределенных системах уходят в учреждения, которые управляют большими, самостоятельно разработанными распределенными системами, например, на фондовых биржах.
Все стало несколько проще с такими предложениями, как Hardoop, SimpleDB и CouchDB, но все еще остается большой проблемой что-то построить на технологии распределенных систем.
С другой стороны, СУБД - это очень хорошая инженерная задача. Они хорошо понимают и опыт работы с ними доступен на рынке труда. Есть много приличных инструментов, возможностей обучения и множество высококвалифицированных специалистов, которые можно арендовать каждый час. Так что подумайте дважды, что вы не можете ужиться с подходом RDBMS - возможно, в сочетании с некоторым хитрым обманом. Я обычно указываю студентам на жизненную архитектуру.
Для распределенных баз данных гораздо меньше опыта. Именно поэтому вы нашли так мало советов до сих пор.
Если вы полны решимости использовать "Возможную последовательность", я думаю, что помимо незрелых инструментов, основной проблемой является мышление всех участников. Готовы ли ваши пользователи API (кодировщики) и приложения (ваши сотрудники и ваши клиенты) принять несогласованность? Вы можете скрыть это от определенных классов пользователей? Мы не привыкли к тому, что компьютеры несовместимы. Что-то есть в наличии или нет. "Возможно" - это не тот ответ, которого ожидают пользователи.
Также имейте в виду, что "возможный" может означать очень долгое время для разработчиков алгоритмов. Как долго вы можете принять несоответствие?
Для приложения с корзиной покупок вы можете по-настоящему распространяться: используйте браузер клиентов в качестве хранилища данных. При оформлении заказа вы можете отправить корзину в систему пакетной обработки на стороне сервера. Это означает, что для каталога вам нужна только высокая доступность для чтения (проще), а отправка корзины - очень узкий интерфейс, не требующий транзакций. В дальнейшем обработка заказа не имеет (мягких) требований в реальном времени и, таким образом, становится проще.
Кстати, в прошлый раз, когда я проверял архитектуру E-Bay, они были большими в RDBMS, но с тех пор, возможно, они изменились. (Изменить: это изменилось - см. Комментарии)
Единственное решение вашей проблемы - решить, какие компромиссы в теореме CAP подходят вам, а затем приступить к ее реализации.
Mdorseif имеет большое значение. Существует множество конфигураций того, в какой степени вы компенсируете согласованность, доступность и разделение. У вас есть два основных варианта.
- Идти по пути внутренней распределенной системы (требует много опыта и исследований)
- Проверьте и экспериментируйте с несколькими распределенными базами данных, чтобы решить, что может удовлетворить ваши требования в масштабе.
Это, вероятно, чрезмерное упрощение. Настоящий готовый к производству трубопровод - это экосистема. По крайней мере, вы попадете на правильный путь.
Appnexus - это рекламная платформа, которая использует hbase для обеспечения высокой доступности и согласованности. Они много говорят об этом здесь.
В статье на http://highscaleability.com/ рассказывается, как New York Times внедрила RabbitMQ вместе с Cassandra в глобальной сети для обеспечения отказоустойчивости и высокой доступности.
MongoDB обеспечивает большую гибкость в балансировании согласованности с доступностью с их реализацией проблем записи. У них есть отличная документация, в которой рассказывается, как именно реализовать ее со всеми проблемами (включая разбиение). Они реализуют двухфазную фиксацию для поддержания состояния в сети (на своих серверах конфигурации).
У Google есть отличная статья на эту тему, в их фотонном проекте реализована масштабируемая, высоконадежная система, в основе которой лежит алгоритм paxos, а также несколько других методов. Он также оказывается очень последовательным (со сквозной задержкой около 10 с) и отказоустойчивым, выдерживая региональные сбои.
Все системы основаны на моделях распределенных вычислений, построенных на CAP и BASE. Здесь основной проблемой является то, что если наша система обеспечивает доступность и допуск раздела, мы не можем иметь истинную согласованность, но мы можем иметь конечную согласованность.
Идея возможной согласованности заключается в том, что каждый узел всегда доступен для обслуживания запросов. Как компромисс, модификации данных распространяются в фоновом режиме на другие узлы. Это означает, что в любое время система может быть несовместимой, но данные все еще в значительной степени точны.
Источник: http://www.techspritz.com/eventual-consistency-and-base-model/
Как достичь высокой доступности и масштабируемости с помощью реляционных баз данных хорошо известно, и существует множество знаний о том, как это сделать!
Google - это особый случай, который не распространяется на большинство сайтов, очень очень большие объемы запросов, очень очень большие объемы данных и, самое главное, отсутствие соглашений об уровне обслуживания с большинством своих пользователей. Нет правильного ответа на веб-поиск, только лучшие ответы, для обычного пользователя Google достаточно хорош, если Google пропускает важную страницу из списка поиска, на который вы, как пользователь, не можете пожаловаться.
E-Bay - это совсем другой случай, так или иначе, они убедили пользователей и клиентов принять плохое обслуживание в обмен на теоретически более низкие цены - хорошо для них, но это не вариант для каждого бизнеса.