Подписка на RSS

Метка «CAP»

Еще в этой серии:

В части 1 мы рассмотрели классы поведения C и A. Для класса A нам нужны более слабые ограничения согласованности. Это не означает, что система должна быть полностью некорректной, но означает, что нам нужно в некоторой мере ослабить согласованность модели.

Amazon популяризировал концепцию «Конченой согласованности». Вот их определение: система хранения гарантирует, что если не было новых обновлений объекта, в конечном счете все точки доступа будут возвращать последнее обновленное знчение.

Для распределенных баз данных модели согласованности — очень важная тема. Мы бы хотели изучить этот вопрос немного глубже в виде серии статей, описывающих проблему с точки зрения, какую модель в каких случая правильно применять. Пожалуйста, присоединяйтесь и помогите нам с помощью комментариев.
Несколько недель назад, обдумывая какую систему регистрации/обнаружения сервисов использовать для платформы развертывания масштабируемых приложений, я осознал, что для организаций среднего размера со сложным набором сервисов единственный вариант — построение с нуля.

Я также обнаружил, что многие пользователи AWS/EC2 уже используют S3 и SimpleDB для публикации/обнаружения сервисов. Это исследование в конечном счете привело меня к рассмотрению Cassandra в качестве хранилища данных для реестра сервисов в корпоративной сети.