C'est une excellente question, sur laquelle j'ai beaucoup réfléchi. Je vais résumer mes leçons apprises :
-
Vous pouvez facilement utiliser Lucene/Solr au lieu de MongoDB pour à peu près toutes les situations, mais pas l'inverse. Le post de Grant Ingersoll le résume ici.
-
MongoDB, etc. semble servir un objectif où il n'y a aucune exigence de recherche et/ou de facettage. Cela semble être une transition plus simple et sans doute plus facile pour les programmeurs qui se désintoxiquent du monde RDBMS. À moins d'y être habitué, Lucene et Solr ont une courbe d'apprentissage plus abrupte.
-
Il n'y a pas beaucoup d'exemples d'utilisation de Lucene/Solr en tant que magasin de données, mais Guardian a fait des progrès et résume cela dans un excellent jeu de diapositives, mais ils ne s'engagent pas non plus à sauter totalement sur le train en marche de Solr et à "enquêter" sur la combinaison de Solr avec CouchDB.
-
Enfin, j'offrirai notre expérience, malheureusement, je ne peux pas en dire beaucoup sur l'analyse de rentabilisation. Nous travaillons à l'échelle de plusieurs To de données, une application quasi temps réel. Après avoir étudié diverses combinaisons, a décidé de s'en tenir à Solr. Aucun regret jusqu'à présent (6 mois et plus) et je ne vois aucune raison de passer à un autre.
Résumé :si vous n'avez pas d'exigence de recherche, Mongo propose une approche simple et puissante. Cependant, si la recherche est la clé de votre offre, vous feriez probablement mieux de vous en tenir à une seule technologie (Solr/Lucene) et de l'optimiser au maximum - moins de pièces mobiles.
Mes 2 centimes, j'espère que ça a aidé.
