2012-08-21 8 views
8

Tengo que implementar el índice Solr en Sitecore y me gustaría saber cuál es el mejor enfoque?Cómo implementar Solr en Sitecore

me miraron siguientes enfoques:

  1. captura publicar evento final (u otros eventos) y luego haga elemento a Solr índice
  2. Implementar rastreador base de datos personalizada y obtener todos los cambios de tabla de historial. Luego, usando datos de inserción de índice personalizado para solr.

El segundo enfoque suena como un camino a seguir (en mi opinión). En este caso, ¿necesito crear un nuevo índice de búsqueda o un administrador de búsqueda?

Si alguien lo ha hecho antes, ¿puede orientarme en la dirección correcta? Además, si pudiera publicar algunos enlaces a artículos sobre la implementación de sitecore-solr.

ACTUALIZACIÓN Ok, después de leer la documentación Sitecore esto es lo que ocurrió:

  1. Crear su clase SolrConfiguration personalizada donde se puede establecer propiedades como solrserviceurl, agregar índices y su definición (Solr personalizada índices)

  2. Crea SolrIndex y agrégala (en el archivo de configuración) a SolrConfiguration. Qué instanciación, solrindex debería suscribirse al evento AddEntry del Sitecore History Manager y comunicarse con los rastreadores de solr.

  3. Crea un procesador personalizado y engancha en la tubería de inicialización del sitecore. Procesador debe inicializar SolrConfiguration (del paso 1)

  4. Como todo en la configuración del archivo en será construir utilizando refrection, se puede obtener instancia de su cofiguration basado en el archivo de configuración

¿qué le parece me gusta. ¿Puedo tener algún comentario por favor?

Respuesta

2

Hemos hecho esto en algunos sitios y tienden a tener un índice nuevo "publicado" Solr y el índice de "inédito"

Interrumpimos:

OnItemSaving

Evento para empujar cosas en el índice no publicado (puede que no lo necesite, depende si quiere cosas en modo de vista previa)

OnPublishItemProcessed

Procesamos adiciones y actualizaciones en el índice publicado aquí, no estoy seguro de lo que hacemos aquí sobre las eliminaciones sin cavar a la derecha en el código, pero sin duda tratar con supresiones en el OnItemDelete (mencionado más adelante)

OnItemDelete

Interrumpimos aquí para eliminar las cosas desde el índice publicado no publicado y (creo que eliminamos del índice publicado aquí porque Sitecore hace publicada el nodo padre con el fin de publicar a cabo supresiones en la base de datos web)

Espero que ayude, publicaría el código si pudiera (pero me molestaría).

+0

Hola, me gusta este enfoque sin embargo. La recomendación dice que los eventos deben usarse para operaciones simples y rápidas relacionadas con los ítems (corrígeme si estoy equivocado). Sé que funciona bien si te suscribes a eventos y actualizas tu índice de sol, pero ¿tiene algún problema de rendimiento? –

+0

No hemos tenido ningún problema de rendimiento informado y ha implementado algunos sitios web grandes que hemos trabajado (que tienen MUCHO contenido). –

+0

No he visto esto en detalle todavía pero este https://github.com/jerrong/Sitecore-Item-Buckets parece muy, muy interesante y podría valer la pena investigarlo. (Ahhh parece que es Sitecore 6.5 solamente, ¿pero podría ser bueno para usted?) –

2

Además de la respuesta ya publicada (que creo que es una buena manera de hacer las cosas) voy a compartir cómo lo hacemos.

Básicamente, solo echamos un vistazo al rastreador de la base de datos Sitecore y decidimos hacer algo así como cómo lo estaba haciendo.

Utilizamos una versión significativamente modificada del Custom Item Generator para facilitar el mapeo entre objetos muy tipados y un objeto que tiene propiedades que corresponden a nuestro esquema de Solr. Para la comunicación real con Solr usamos SolrNet.

La idea general es que recorremos todos los elementos (empezando por la raíz del sitio) recursivamente y los asignamos al tipo apropiado según su plantilla. Luego pasamos por un proceso de indexación para ese artículo (algunos elementos necesitan indexar varios documentos a Solr en nuestra implementación).

Este enfoque funciona muy bien para nosotros, excepto que señalaré que, debido a que indexamos todo a la vez, tiende a introducir un ligero lapso de tiempo entre la publicación y el sitio que refleja los cambios realizados en el índice. Un descuido que hicimos al principio, pero que pronto trabajaremos para solucionarlo, es que no tenemos un índice "no publicado" (lo que significa que debemos publicar el sitio para ver las actualizaciones). En realidad, no afecta mucho nuestra solución, pero definitivamente puedo ver dónde podrían estar los demás, así que tenlo en cuenta.

No deseamos particularmente eliminar la eliminación de elementos del índice, por lo que hacemos la indexación como un evento de publicación: final.

Espero que esta información adicional lo ayude. Hasta donde sé, no hay mucha información sobre esta combinación específica de productos, pero puedo decir que definitivamente es posible y bastante útil.

+0

Eso también funciona (probado este enfoque), pero no suena bien: el rastreador de la base de datos debe agregarse a un índice (que es un lucene index), lo que significa que seguirás actualizando 2 índices ... o después de actualizar tu índice de solr, ¿cancelas el trabajo y, por lo tanto, no se agregará el registro a tu índice sitecore lucene? –

+0

La implementación de Solr está funcionando independientemente del índice de Sitecore Lucene. Para aclarar, solo tomamos el rastreador de la base de datos como inspiración (específicamente, el enfoque para reunir los elementos para la indexación). No utilizamos activamente el índice de Sitecore Lucene para nada. Como dije antes, solo tenemos un índice (se agregará un segundo en el futuro) y a través de la configuración le pedimos que indexe la base de datos web. –

+0

¿Notó algún problema de rendimiento? Además, ¿cómo manejaste el índice de reconstrucción? –