full text search - español - ¿Cómo configurar Lucene/Solr para una aplicación web B2B?

localhost:8983/solr/

Question

Dado:

• 1 base de datos por cliente (cliente comercial)
• 5000 clientes
• Los clientes tienen entre 2 y 2000 usuarios (promedio es ~ 100 usuarios / cliente)
• 100k a 10 millones de registros por base de datos
• Los usuarios necesitan buscar esos registros con frecuencia (es la mejor manera de navegar por sus datos)

Información posiblemente relevante:

• Varios clientes nuevos cada semana (en cualquier momento durante el horario comercial)
• Múltiples servidores web y servidores de bases de datos (los usuarios pueden iniciar sesión a través de cualquier servidor web)
• Sigamos siendo agnósticos de lenguaje o marca sql, ya que Lucene (y Solr) tienen una amplia gama de soporte

Por ejemplo:

Joel Spolsky dijo en Podcast # 11 que su producto de aplicación web alojado, FogBugz On-Demand, usa Lucene. Él tiene miles de clientes a pedido. Y cada cliente tiene su propia base de datos.

Usan un índice por cliente y lo almacenan en la base de datos del cliente . No estoy seguro de los detalles. Y no estoy seguro si este es un mod serio para Lucene.

La pregunta:

¿Cómo se configuraría la búsqueda de Lucene para que cada cliente solo pueda buscar dentro de su base de datos?

¿Cómo configuraría el índice (es)?
¿Dónde almacena los índices?
¿Necesitarías agregar un filtro a todas las consultas de búsqueda?
Si un cliente cancela, ¿cómo eliminaría su (parte del) índice? (Esto puede ser trivial, no estoy seguro aún)

Soluciones posibles:

Haga un índice para cada cliente (base de datos)

• Pro: la búsqueda es más rápida (que el método de un índice para todos). Los índices son relativos al tamaño de los datos del cliente.
• Con: no estoy seguro de lo que esto implica, ni sé si esto está más allá del alcance de Lucene.

Tener un único y gigantesco índice con un campo de nombre de base de datos. Siempre incluya database_name como un filtro.

• Pro: No estoy seguro. Tal vez sea bueno para el soporte técnico o el departamento de facturación para buscar información en todas las bases de datos.
• Con: La búsqueda es más lenta (que el método de índice por cliente). Seguridad defectuosa si se eliminó el filtro de consulta.

Una última cosa:
También aceptaría una respuesta que utiliza Solr (la extensión de Lucene). Tal vez es más adecuado para este problema. No es seguro.

Answer 1

Todavía no tengo claro exactamente qué bases de datos de 5K están buscando los usuarios, por qué necesita Lucene y el tamaño de los datos en cada base de datos. Pero tomaré un golpe de todos modos:

1. Debería estar mirando el Solr Multicore (cada núcleo = 1 índice) y tiene una URL única para consultar. La autenticación seguirá siendo un problema y una forma (incierta) de abordarlo sería hacer que la URL sea difícil de adivinar.

2. Sus servidores web pueden consultar la instancia / núcleo Solr dependiendo de a qué tienen acceso.

Sugeriría mantenerse alejado del enfoque de filtro y crear un índice enorme que combine todas las bases de datos.

HTH

Answer 2

Shalin Shekhar Mangar me respondió en la lista de correo de Solr y por correo privado. Shalin es colaborador de Solr y autor del próximo libro Solr in Action .

Su respuesta en la lista de correo:

¿Cómo configuraría el índice (es)?

Vería configurar múltiples núcleos para cada cliente. Es posible que deba configurar esclavos también según el tráfico de búsqueda.

¿Dónde almacena los índices?

La configuración de núcleos de 5K en una caja no funcionará. Por lo tanto, deberá dividir los clientes en varias casillas, cada una con un subconjunto de núcleos.

¿Necesitarías agregar un filtro a todas las consultas de búsqueda?

No, pero deberás enviar la consulta al host correcto (quizás un DB de mapeo ayudará)

Si un cliente cancela, ¿cómo eliminaría su (parte del) índice? (Esto puede ser trivial, no estoy seguro aún)

Con diferentes núcleos para cada cliente, esto sería bastante fácil.

Su respuesta por correo electrónico:

Trabajé en un caso de uso similar en el pasado y utilizamos el enfoque de múltiples núcleos con algunas optimizaciones pesadas en el lado de Solr. Ver http://wiki.apache.org/solr/LotsOfCores - Todavía no he podido llevar estos cambios a Solr.

Answer 3

Me convocaste desde el StackExchange de FogBugz. Mi nombre es Jude, soy el arquitecto de búsqueda actual de FogBugz.

A continuación, presentamos un resumen de cómo se configura la arquitectura de búsqueda de FogBugz On Demand [1]:

• Por razones relacionadas con la portabilidad de los datos, la seguridad, etc., mantenemos separadas todas nuestras bases de datos e índices a pedido.
• Si bien usamos Lucene (Lucene.NET, en realidad), modificamos su back-end de manera bastante sustancial para que pueda almacenar su índice completamente en la base de datos. Además, se mantiene un caché local en cada host de web, de modo que siempre que sea posible se pueden evitar los accesos innecesarios a la base de datos.
• Nuestros filtros son casi totalmente de base de datos (ya que son utilizados por aspectos de FogBugz fuera de la búsqueda), por lo que nuestro analizador de búsqueda separa las consultas en componentes de texto completo y no de texto completo, ejecuta las búsquedas y combina los resultados. Esto es un poco desafortunado, ya que anula muchas optimizaciones útiles que Lucene es capaz de hacer.

Hay algunos beneficios de lo que hemos hecho. Administrar las cuentas es bastante simple, ya que los datos del cliente y su índice se almacenan en el mismo lugar. Sin embargo, también hay algunos aspectos negativos, como un conjunto de búsquedas de casos muy molestos que no alcanzan nuestros estándares mínimos. Retrospectivamente, nuestra búsqueda fue genial y bien hecha para su tiempo. Si tuviera que hacerlo de nuevo, sin embargo, desalentaría este enfoque .

Simplemente, a menos que su dominio de búsqueda sea muy especial o esté dispuesto a dedicar un desarrollador a una búsqueda increíblemente rápida, es probable que lo supere un excelente producto como ElasticSearch, Solr o Xapian.

Si estuviera haciendo esto hoy, a menos que mi dominio de búsqueda fuera extremadamente específico, probablemente usaría ElasticSearch, Solr o Xapian para mi solución de búsqueda de texto completo respaldada por una base de datos. En cuanto a eso, eso depende de sus necesidades auxiliares (plataforma, tipo de consultas, extensibilidad, tolerancia para un conjunto de peculiaridades sobre otro, etc.)

Sobre el tema de un índice grande versus muchos (!) Índices dispersos: ambos pueden funcionar. Creo que la decisión realmente radica en qué tipo de arquitectura está buscando construir y qué tipo de rendimiento necesita. Puede ser bastante flexible si decide que una respuesta de búsqueda de 2 segundos es razonable, pero una vez que comienza a decir que cualquier cosa superior a 200 ms es inaceptable, sus opciones comienzan a desaparecer rápidamente. Si bien mantener un solo índice de búsqueda grande para todos sus clientes puede ser mucho más eficiente que manejar muchos índices pequeños, no es necesariamente más rápido (como usted señaló). Personalmente, creo que, en un entorno seguro, no debe subestimarse el beneficio de mantener separados los datos de sus clientes. Cuando su índice se corrompe, no detendrá la búsqueda; pequeños errores tontos no expondrán datos confidenciales; las cuentas de usuario se mantienen modulares; es más fácil extraer un conjunto de cuentas y colocarlas en un nuevo servidor; etc.

No estoy seguro de que eso haya respondido a su pregunta, pero espero que al menos haya satisfecho su curiosidad :-)

[1]: en 2013, FogBugz comenzó a impulsar sus capacidades de búsqueda y filtrado con ElasticSearch. Nos gusta.