¿Cuándo usar definitivamente SOLR sobre Lucene en una compilación de Sitecore 7?

sitecore7 (3)

Mi cliente no tiene el presupuesto para instalar y mantener un servidor SOLR para usar en su entorno de producción. Si entiendo correctamente la API de búsqueda de contenido de Sitecore 7, no es una gran cosa configurar las cosas para usar a Lucene en su lugar. En su mayor parte, la configuración será similar y el código será el mismo, y un servidor SOLR se puede intercambiar más adelante.

La compilación del sitio tiene

página de búsqueda facetada
listado de componentes en el aterrizaje y en otras páginas que aprovecharán la API de búsqueda de contenido
cubos con facetas personalizadas

El sitio tiene alrededor de 5,000 páginas y componentes que no incluyen elementos de la biblioteca multimedia. ¿Hay alguna preocupación acerca de simplemente usar Lucene?

La pregunta principal es cuándo, durante su fase de arquitectura o diseño, ¿sabe que definitivamente debería elegir SOLR sobre Lucene? ¿Cuáles son las principales señales que te llevan a recomendar eso?

Creo que si está tratando con un cliente con un presupuesto limitado, Lucene funcionará perfectamente bien y se desempeñará excelentemente para la escala de las cosas que está haciendo. Todas las cosas que usted menciona son totalmente compatibles con la implementación en Lucene.

En un escenario de Sitecore comenzaría a considerar Solr si:

Debe indexar un gran número de elementos, por ejemplo, 50 mil hacia arriba. Lucene está contenta con este tipo de números, pero Solr ha mejorado el almacenamiento en caché de consultas y está diseñado para estos grandes números de artículos.
La capacidad de recuperación del nivel de búsqueda es de la máxima importancia comercial (es decir, el sitio se basa exclusivamente en la búsqueda): Solr proporciona un sistema de replicación / fragmentación y conmutación por error más robusto con SolrCloud.
La reutilización del nivel de búsqueda en otra aplicación es importante (no Sitecore): Solr es una aplicación de búsqueda, por lo que se puede acceder a través de HTTP con XML / JSON, etc., lo que facilita la integración con los sistemas externos.
Necesitas alguna característica adicional específica de Solr que Lucene no tenga.

.. pero como dice si desea cambiar a Lucene por Solr en una fase posterior, hemos trabajado arduamente para asegurarnos de que el proceso sea lo más sencillo posible. Vale la pena señalar algunos puntos aquí:

Si bien las consultas de LINQ seguirán siendo las mismas, su configuración será ligeramente diferente y necesitará atención en todo el puerto.
Es importante saber cómo funciona Solr como una aplicación y cómo funciona el esquema, pero hay algunos libros excelentes y una gran cantidad de conocimientos.
Solr tiene analizadores y mecanismos de calificación ligeramente nuevos (más nuevos), por lo que los resultados de búsqueda pueden ser ligeramente diferentes (a veces los clientes pueden alarmarse con esto: P)

... pero creo que estas son cosas que puede acumular con el tiempo y evaluar con el cliente. Estoy seguro de que hay más puntos aquí y otros pueden participar si piensan en ellos. Espero que esto ayude :)

Recomendaría planificar un plan de escape de Lucene tan pronto como empieces a pensar en varios CD y esta es la razón:

A) Cada servidor tiene que mantener su propia copia de índice:

Cualquier reinicio inesperado puede hacer que algunos documentos no se agreguen al índice en el cuadro, lo que hace que los índices sean diferentes de un servidor a otro. Eso llevaría a la misma página mostrando diferente por CDs
Cada servidor debe realizar actualizaciones de índice: use la CPU y el espacio en disco; la tasa de respuesta cae después de que la operación de publicación ha terminado = /
De acuerdo con la guía de seguridad, los CD deben tener eliminada la interfaz de usuario de Sitecore Shell, por lo que el índice no se puede reconstruir fácilmente desde el Panel de control = /

B) Lucene no está diseñada para grandes volúmenes de contenido. Cada operación de búsqueda hace aproximadamente lo siguiente:

Cree una matriz con un tamaño igual al número total de documentos en el índice
Si el documento coincide con la búsqueda, establezca la marca en la matriz

Si bien esto funciona como un encanto para los índices de tamaño bajo (~ 10K elementos), una gran degradación del rendimiento se produce una vez que el volumen de contenido crece.

La matriz asignada termina en el montón de objetos grandes que no se compacta de forma predeterminada, por lo que se fragmenta rápidamente.

Guión:

Realice la búsqueda de documentos de 100K -> enorme matriz creada en la memoria
Realizar una búsqueda más en otro hilo -> una matriz enorme más creada
Actualizar índice -> ahora 100K + 10 documentos
La primera operación se completó; LOH tiene espacio para una matriz de 100K
Seach disparó de nuevo -> 100K + 10 matriz se creará; El ''agujero'' de la memoria liberada no es lo suficientemente grande, por lo que se solicita más RAM.
El proceso w3wp.exe sigue consumiendo más y más RAM

Este es el caso común de la Agregación de Analytics ya que un índice está siendo poblado por múltiples hilos a la vez. Verás una gran cantidad de RAM utilizada después de un tiempo en la instancia de procesamiento.

C) El último lanzamiento de Lucene.NET se realizó hace 5 años.

Mientras que SOLR se está desarrollando activamente.

Cuanto antes haga el cambio a SOLR, más fácil será.

Stephen prácticamente cubrió la pregunta, pero solo quería agregar otro escenario. Debe tener en cuenta la configuración del servidor en su entorno de producción. Si va a utilizar varios servidores de entrega de contenido detrás de un equilibrador de carga, consideraría Solr desde el principio, ya que tratar de asegurarse de que el índice de Lucene en cada servidor de entrega esté sincronizado el 100% del tiempo puede ser doloroso.