Добрый день, мои дорогие любители архитектуры распределенных систем.
Сразу накидаю ссылочек, кто хочет интересное чтиво.
http://martinfowler.com/bliki/CQRS.html
http://habrahabr.ru/post/146429/
http://habrahabr.ru/post/149464/
http://blog.jonathanoliver.com/2011/05/why-i-still-love-cqrs-and-messaging-an...
http://msdn.microsoft.com/en-us/library/jj554200.aspx
Вкратце. CQRS - более общий вариант CRUD, мы не обязательно в DAO записываем те же обЪекты что и читаем (Entities). Вместо этого отправляем асинхронные Command и через время, когда он раздуплится, можем делать Query. Тоесть вместо одного DAO у нас Read Model и Write Model.
Event Sourcing, Write Model. У нас нет сущностей, есть Aggregate, которые реально не сохранены в базе, но определяются общим ID. Так вот, когда мы получаем Command на определенный ID, то мы достаем предыдущие Command на этот ID, реплеим их в памяти, они имеют доступ к общему обьекту Aggregate, который конструируется с нуля поглощая эти Command. Потом мы добавляем к нему новый Command и сохраняем его в базу.
Добавление последнего Command порождает много Event, которые разлетаются к чертям асинхронно во все стороны и там какие-то куски кода сферически в вакууме обновляют Read Model. Например в реальном времени обновляют таблицы, делают real time MapReduce, обновляют карту мира, пишут письма, пофиг.
Read Model может быть бесконечно разнообразным и его можно стереть, перепрограммировать и воспроизвести заново все Event. Их можно добавлять потом и делать сколько угодно штук. Они могут быть даже не в вашей компании. С письмами повторную отправку иногда нужно отключать.
А теперь вопрос. Какая СУБД, желательно из бесконечно масштабируемых, для такого подходит.
Mongo, РСУБД прямо утыканы single point of failure, так что отбросим пока.
Cassandra. Идеально, неубиенная, линейно масштабируется, no single point of failure. Первый ключ (parition/row key) - command id. Второй, поддающийся сортировке - timestamp. Но все омрачает один факт. Не смотря на рекламу что с помощью R+W>N можно достичь strong consistency, это простите брехня. Потому что нет rollback, и потом вылазят проблемы что если write неуспешен, то некоторые чтения могут все же увидеть новые данные. А следующее чтение - старые. А потом опять новые. Нужно просто правильные узлы выбирать. Для вебни - самое то. Но когда CQRS+Event Sourcing система будет наивно колбасить миллион комманд в автоматическом режиме, то может неслабо бабахнуть.
Riak - то же самое вроде, не? Очень хотел бы послушать.
HBase? Очень мало знаю о этой СУБД.
Короче нужна кассандра с роллбеком
