2010-02-15 9 views
8

He venido implementando MS Search Server 2010 y hasta ahora es realmente bueno. Estoy haciendo las consultas de búsqueda a través de su servicio web, pero debido a la inconsistente results, im pensando en el almacenamiento en caché el resultado en su lugar.Almacenamiento de resultados de la búsqueda para paginación y la clasificación

El sitio es una intranet pequeña (500 empleados), por lo que no debería haber ningún problema, pero me gustaría saber qué enfoque tomaría si fuera un sitio más grande.

He buscado en Google un poco, pero havent realmente venir nada específico. Entonces, algunas preguntas:

  • ¿Qué otros enfoques existen? ¿Y por qué son mejores?
  • ¿Cuánto cuesta para almacenar un DataView de 400-500 filas? ¿Qué tamaños son factibles?
  • Otros puntos que deben tener en cuenta.

Cualquier entrada es bienvenido :)

+0

¿Has mirado Apache SOLR? –

Respuesta

2

Necesita emplear muchas técnicas para lograr esto con éxito.

Primero, necesita algún tipo de capa de persistencia. Si está utilizando un sitio web simple antiguo, entonces la sesión del usuario sería la capa más lógica para usar. Si está utilizando servicios web (es decir, sin sesión) y simplemente realiza llamadas a través de un cliente, entonces aún necesita algún tipo de capa de aplicación (una especie de sesión compartida) para sus servicios. ¿Por qué? Esta capa albergará tu caché de resultados de base de datos.

En segundo lugar,, necesita una forma de almacenar los resultados en caché en cualquier contenedor que esté utilizando (sesión o capa de aplicación de servicios web). Puede hacerlo de varias maneras ... Si la consulta es algo que cualquier usuario puede hacer, un simple hash de la consulta funcionará y podrá compartir este resultado almacenado entre otros usuarios. Probablemente todavía desee algún tipo de GUID para el resultado, de modo que pueda pasar esto en su aplicación cliente, pero será útil tener una búsqueda hash de las consultas a los resultados. Si estas consultas son únicas, puede usar el GUID exclusivo para el resultado de la consulta y pasarlo a la aplicación cliente. Esto es para que pueda realizar su función de almacenamiento en caché ...

El mecanismo de almacenamiento en caché puede incorporar algún tipo de búfer de longitud fija o cola ... para que los resultados antiguos se eliminen automáticamente a medida que se agreguen nuevos. Entonces, si aparece una consulta que es una falta de caché, se ejecutará normalmente y se agregará a la memoria caché.

Tercer, se le va a querer alguna manera a la página de su objeto de resultado ... el iterador funciona bien aquí, aunque probablemente algo más simple podría funcionar ... como buscar a X cantidad de resultados comenzando en el punto Y. Sin embargo, el patrón Iterator sería mejor, ya que podría eliminar el mecanismo de almacenamiento en caché más adelante y la página directamente desde la base de datos, si así lo desea.

Cuarto,, necesita algún tipo de mecanismo de precarga (como se sugirió). Debería iniciar un hilo que hará la búsqueda completa, y en su hilo principal solo haga una búsqueda rápida con el número X superior de artículos. Esperemos que para cuando el usuario intente buscar, el segundo subproceso estará terminado y su resultado completo ahora estará en la memoria caché. Si el resultado no está listo, puede incorporar una lógica de pantalla de carga simple.

Esto debería ayudarte un poco ... házmelo saber si quieres aclaración/más detalles sobre cualquier pieza en particular.

Te dejo con algunos consejos más ...

  1. Usted no quiere estar enviando todo el resultado a la aplicación de cliente (si está usando Ajax o algo así como una aplicación para el iPhone). ¿Por qué? Bueno, porque eso es una gran pérdida. Es probable que el usuario no vaya a buscar todos los resultados ... ahora simplemente envió más de 2MB de campos de resultados para nada.

  2. Javascript es un lenguaje impresionante, pero recuerde que sigue siendo un lenguaje de scripting del lado del cliente ... no desea retrasar demasiado la experiencia del usuario enviando grandes cantidades de datos para que su cliente Ajax maneje. Simplemente envíe el resultado obtenido previamente a su cliente y los resultados de página adicionales como las páginas del usuario.

  3. Abstraction abstraction abstraction ... desea abstraer la caché, la consulta, la búsqueda, la obtención previa ... tanto como pueda. ¿Por qué? Bueno, digamos que desea cambiar las bases de datos o desea crear una página directamente desde la base de datos en lugar de usar un objeto de resultado en la memoria caché ... bueno, si lo hace bien, es mucho más fácil cambiarlo más adelante. Además, si utiliza servicios web, muchas otras aplicaciones pueden hacer uso de esta lógica más adelante.

Ahora, probablemente sugerí una solución sobre-diseñada para lo que necesita :). Pero, si puede lograr esto utilizando todas las técnicas correctas, aprenderá muchísimo y tendrá una muy buena base en caso de que desee extender la funcionalidad o reutilizar este código.

Avíseme si tiene alguna pregunta.

+0

Me olvidé de responder. Lo siento. Utilicé el almacenamiento en caché para las llamadas al servicio web y la sesión para las búsquedas en el servidor web. Gracias por la extensa respuesta, ¡realmente útil! – Mattias

0

Tengo que admitir que no soy terriblemente familiarizado con MS servidor de búsqueda por lo que este puede no ser aplicable. A menudo he tenido situaciones en las que una aplicación tenía que buscar entre cientos de millones de registros conjuntos de resultados que necesitaban ordenarse, paginarse y sub-buscarse en un servidor SQL. En general, lo que hago es tomar un enfoque de dos pasos. Primero tomo los primeros resultados "x" que deben mostrarse y los envío al navegador para una visualización rápida. En segundo lugar, en otro hilo, termino la consulta completa y muevo los resultados a una tabla temporal donde pueden almacenarse y recuperarse más rápidamente. Cualquier consulta dada puede tener miles o decenas de miles de resultados, pero en comparación con los cientos de millones o incluso miles de millones de registros totales, este subconjunto más pequeño se puede manipular muy fácilmente desde la tabla temporal. También pone menos énfasis en las otras tablas cuando ocurren consultas. Si el usuario necesita una segunda página de registros, o necesita ordenarlos, o simplemente quiere un subconjunto de la consulta original, todo esto se extrae de la tabla temporal.

Luego, Logic debe ponerse en marcha para verificar si hay tablas temporales obsoletas y eliminarlas. Esto es bastante simple y dejo que SQL Server maneje esa funcionalidad. Finalmente, la lógica tiene que establecerse para cuando la consulta original cambie (cambios significativos en el perímetro) para que un nuevo conjunto de datos pueda extraerse y colocarse en una nueva tabla temporal para consultas adicionales. Todo esto es relativamente simple.

Los usuarios están tan acostumbrados a dividir los segundos tiempos de retorno de sitios como google y este modelo me da la suficiente flexibilidad para lograrlo sin necesitar el software y hardware especializado que utilizan.

Espero que esto ayude un poco.

0

La respuesta de Tim es una gran manera de manejar las cosas si tiene la capacidad de ejecutar la consulta inicial en un segundo hilo y la lógica (paginación/clasificación/filtrado) que se aplicará a los resultados requiere acción en el servidor. ... de lo contrario ...

Si puede usar AJAX, se podría llamar a un conjunto de resultados de 500 filas en la página y paginarlo u ordenarlo en el cliente. Esto puede llevar a algunas características realmente interesantes ... ¡revisa las soluciones de cuadrícula de datos de jQueryUI y Dojo para inspirarte!

Y para funciones realmente intensivas como filtros arbitrarios de expresiones regulares y reordenar columnas de arrastrar y soltar, puede liberar totalmente el servidor.

Cargar los datos en el navegador de una sola vez también le permite llamar los datos de apoyo (vistas previas de página, etc.) a medida que el usuario los "solicita" ....

El problema principal es limitar los datos que devuelve por resultado a lo que realmente usará para sus géneros y filtros.

Las posibilidades son infinitas :)

+0

Pero, afortunadamente, su algoritmo de búsqueda ofrece buenos resultados desde el principio, por lo que estaría cargando 490 resultados e imágenes de vista previa innecesariamente –

1

Suena como la parte lenta de la búsqueda es la búsqueda de texto completo, no el resultado de recuperación. ¿Qué tal el almacenamiento en caché de los ID de registro de recursos resultantes? Además, dado que es posible que las consultas de búsqueda a menudo estén duplicadas, almacene un hash de la consulta de búsqueda, la consulta y los recursos coincidentes. Luego puede recuperar la siguiente página de resultados por ID. Funciona con AJAX también.

Dado que es una intranet y puede controlar los recursos buscados, incluso puede precomputar una coincidencia de recurso nuevo o actualizado con consultas populares durante el tiempo de inactividad.

Cuestiones relacionadas