Това е страхотен въпрос, нещо, над което съм размишлявал доста. Ще обобщя научените уроци:
-
Можете лесно да използвате Lucene/Solr вместо MongoDB за почти всички ситуации, но не и обратното. Публикацията на Grant Ingersoll го обобщава тук.
-
MongoDB и т.н. изглежда служат за цел, където няма изискване за търсене и/или фасетиране. Изглежда, че е по-прост и може би по-лесен преход за програмисти, които се детоксикират от света на RDBMS. Освен ако човек не е свикнал с това Lucene &Solr имат по-стръмна крива на обучение.
-
Няма много примери за използване на Lucene/Solr като хранилище за данни, но Guardian постигна известен напредък и обобщи това в отличен слайд-дек, но те също не се ангажират напълно да прескачат изцяло Solr и да „разследват“ комбинирането на Solr с CouchDB.
-
Накрая ще предложа нашия опит, който за съжаление не може да разкрие много за бизнес казуса. Работим в мащаб от няколко TB данни, приложение в почти реално време. След като проучих различни комбинации, реших да се придържам към Solr. Засега не съжалявате (6 месеца и се брои) и не виждам причина да преминете към друг.
Резюме:ако нямате изискване за търсене, Mongo предлага прост и мощен подход. Ако обаче търсенето е от ключово значение за вашето предложение, вероятно е по-добре да се придържате към една технология (Solr/Lucene) и да я оптимизирате по дяволите – по-малко движещи се части.
Моите 2 цента, надявам се, че помогна.
