Какая архитектура NoSQL вы бы использовали для приложения, такого как Google Reader (один к одному экземпляру)?Архитектура NoSQL для приложения, такого как Google Reader
Я рассматриваю MongoDB, Cassandra, CouchDB, Redis, HBase и Riak.
Простой ответ, используйте тот, с которым вам больше всего нравится.
Более сложный ответ на самом деле заключается в деталях того, что может сделать Google Reader. Одна функция, которую вы, вероятно, захотите, это несколько индексов.
Каждая запись RSS будет иметь уникальный ключ, пользователь, ts, флаг чтения и некоторые категории. При работе с документами или базами данных с ключом, как правило, легко получить ключ. Но каков первый запрос, который вы действительно собираетесь запустить? Список пользователя, ts, read.
Ну, это потребует вторичного индекса. AFAIK riak и redis не поддерживайте это вообще. CouchDB и У Cassandra, похоже, есть некоторые обходные пути (взгляды), но это все еще непросто. MongoDB поддерживает вторичные индексы «out of the box».
Так что сразу с места в карьер, вы упрощаете его работу с MongoDB.
У Mongo также есть серия atomic operations, что упрощает обновление данных асинхронно.
+1, технология почти всегда является второстепенной для программиста и вашего опыта. – JasonSmith
Но для записи, CouchDB просмотров * являются * вторичными индексами! – JasonSmith
Этот вопрос нуждается в немного больше вещества, прежде чем он будет полезен. –
Я начал писать ответ, тогда я понял, что, основываясь на таком общем требовании, вы можете сделать дело для любого из них. Я бы лично выбрал MongoDB - он отлично работает для хранения документов, а вставки очень дешево/быстро (и с таким приложением вы в конечном итоге будете делать больше вставок, а затем читаете). Но я мог бы сделать дело для CouchDB, Redis или Riak. –