Comme déjà dit, ton besoin semble t’orienter naturellement vers de la base documentaire. Après, je dis « ton besoin », mais ce n’est pas réellement ton besoin que tu nous as présenté, mais plutôt tes pré-choix ;)

La bonne manière pour choisir son moteur c’est plutôt de se demander de quelle façon on manipule les données. Là tu as effectivement parler de champs dont la valeur dépend d’autres champs, mais ça à la limite c’est hors-sujet: soit c’est du côté de l’application et on se fout du mode de stockage, soit c’est pré-calculé et ce n’est qu’un champ parmi d’autres et là encore on se fout du stockage. Ce n’est pas un cas qui permet de discriminer les solutions qui s’offrent à toi.

Tu as énoncé des besoins techniques qui permettront sans doute d’éliminer certaines solutions.

Après pour le choix final, à mon avis les bonnes questions sont plutôt:
* Est-ce que j’ai besoin de sortir des statistiques à partir des documents (par exemple combien de fois tel livre a été lu, et par quel groupe) ? Comment souhaité-je remplir ces statistiques ? À quelle fréquence doivent-elles être à jour ?
* Est-ce que j’ai besoin de résoudre certaines relations (par exemple les livres par le(s) même(s) auteur(s), les livres traitant du même sujet) ? Ça permet généralement de définir en plus comment on va modéliser les données.

Bref, plutôt des questions sur la façon dont seront utilisées fonctionnellement les données, qui permettra de savoir sur quel cas se concentrer et permettra de définir le choix idéal comme étant le moteur de stockage gérant le mieux ces choix.

Cela dit ton besoin de réplication et de disponibilité semble t’orienter vers du NoSQL. Tu n’auras pas forcément envie de te retourner complètement l’esprit donc on peut virer les key/value et les bases graphes, qui obligent à changer complètement notre mode de réflexion lors de la modélisation.
Une base documentaire sera plus simple à utiliser et le modèle sera plus simple à concevoir.

Du coup on revient aux classiques MongoDB ou CouchDB (je ne t’ai donc pas plus avancé que les commentaires précédents, mais tu sais déjà un peu mieux pourquoi on arrive à ce duo ;)).

Pour résumer ce que je connais de leurs différences (les articles cités par CrEv complèteront):
* CouchDB est à mon avis bien plus complexe d’utilisation, le mode de requêtage par vue est vraiment difficile à appréhender au début, la courbe d’apprentissage est plus raide que MongoDB.
* CouchDB gère *réellement* les fichiers attachés. Ce sont des entités bien définies, et c’est plus simple à gérer que GridFS (je ne sais pas si tu as ce besoin).
* CouchDB versionne nativement les documents. C’est cool :)

Pour le reste je sais que MongoDB gère les index, qu’il a un systême de procédures stockées ultra simple (tu sauves une fonction JS dans ta base…) qui pourrait bien te servir pour tes calculs de champ composé. Je ne connais pas assez CouchDB pour te dire s’il bénéficie aussi de ces fonctionnalités ou pas.