Quelle architecture NoSQL utiliseriez-vous pour une application comme Google Reader (copie un à un)?Architecture NoSQL pour application comme Google Reader
Je considère MongoDB, Cassandra, CouchDB, Redis, HBase et Riak.
Répondez facilement, utilisez celui qui vous convient le mieux.
La réponse la plus complexe réside vraiment dans les détails de ce que Google Reader peut faire. Une fonctionnalité que vous voudrez probablement est plusieurs index.
Chaque entrée RSS va avoir une clé unique, un utilisateur, un ts, un drapeau de lecture et certaines catégories. Lorsque vous traitez des bases de données à base de documents ou de valeurs-clés, il est généralement facile d'obtenir la clé. Mais quelle est la première requête que vous allez vraiment exécuter? Liste par utilisateur, ts, lu.
Eh bien, cela va avoir besoin d'un index secondaire. AFAIK riak et redis ne supporte pas du tout. CouchDB et Cassandra semblent avoir quelques contournements (vues), mais ce n'est toujours pas facile. MongoDB prend en charge les index secondaires "out of the box".
Dès le départ, vous facilitez l'utilisation de MongoDB.
Mongo possède également une série de atomic operations qui facilite la mise à jour des données de manière asynchrone.
+1, la technologie est presque toujours secondaire au programmeur et à l'expertise que vous possédez. – JasonSmith
Mais pour mémoire, les vues CouchDB * sont des * index secondaires! – JasonSmith
Cette question a besoin d'un peu plus de substance avant qu'elle ne soit utile. –
J'ai commencé à écrire une réponse, puis j'ai réalisé que sur la base d'une telle exigence générique, vous pourriez faire un cas pour l'un de ceux-ci. Personnellement, je choisirais MongoDB - il fonctionne très bien pour stocker des documents et les inserts sont très bon marché/rapide (et avec une application comme celle-ci, vous finirez par faire plus d'inserts puis de lectures). Mais je pourrais aussi faire un cas pour CouchDB, Redis ou Riak. –