Su enfoque es realmente bueno. Algunos marcos populares como Compass están realizando lo que usted describe en un nivel inferior para reflejar automáticamente los cambios de índice que se han realizado a través del marco ORM (consulte http://www.compass-project.org/overview.html).
Además de lo que usted describe, también volvería a indexar regularmente todos los datos que viven en MongoDB para garantizar que tanto Solr como Mongo estén sincronizados (probablemente no tanto como podría pensar, dependiendo de la cantidad de documento, la cantidad de campos, la cantidad de tokens por campo y el rendimiento de los analizadores:a menudo creo un índice de 5 a 8 millones de documentos (alrededor de 20 campos, pero los campos de texto son cortos) en menos de 15 minutos con analizadores complejos, solo asegúrese su búfer RAM no es demasiado pequeño y no confirme/optimice hasta que se hayan agregado todos los documentos).
En cuanto al rendimiento, una confirmación es costosa y una optimización es muy costosa. Dependiendo de lo que más le importe, puede cambiar el valor de mergefactor en Solrconfig.xml (los valores altos mejoran el rendimiento de escritura mientras que los valores bajos mejoran el rendimiento de lectura, 10 es un buen valor para empezar).
Parece tener miedo del tiempo de creación del índice. Sin embargo, dado que el almacenamiento de índices de Lucene se basa en segmentos, el rendimiento de escritura no debería depender demasiado del tamaño del índice (http://lucene.apache.org/java/2_3_2/fileformats.html). Sin embargo, el tiempo de calentamiento aumentará, por lo que debe asegurarse de que
- hay consultas típicas (especialmente para ordenar con el fin de cargar los cachés de campo) pero no demasiado complejas en los parámetros firstSearcher y newSearcher en su archivo de configuración solrconfig.xml,
- useColdSearcher está configurado para
- falso para tener un buen rendimiento de búsqueda, o
- verdadero si desea que los cambios realizados en el índice se tengan en cuenta más rápido al precio de una búsqueda más lenta.
Además, si es aceptable para usted si los datos se pueden buscar solo unos pocos X milisegundos después de que se hayan escrito en MongoDB, puede usar la función commitWithin de UpdateHandler. De esta forma, Solr tendrá que comprometerse con menos frecuencia.
Para obtener más información sobre los factores de rendimiento de Solr, consulte http://wiki.apache.org/solr/SolrPerformanceFactors
Para eliminar documentos, puede hacerlo por ID de documento (como se define en schema.xml) o por consulta :http://lucene.apache.org/solr/api/org/apache/solr/client/solrj/SolrServer.html
