¿Cómo configurar Lucene / Solr para una aplicación web B2B?

Question

Teniendo en cuenta:

• 1 base de datos por cliente (cliente de negocios)
• 5000 clientes
• Los clientes tienen entre 2 y 2.000 usuarios (AVG es ~ 100 usuarios / clientes)
• 100 mil a 10 millones de registros por base de datos
• Los usuarios tienen que buscar los registros de frecuencia (que es la mejor forma de navegar por sus datos)

Posiblemente información relevante:

• Varios nuevos clientes cada semana (en cualquier momento durante el horario comercial)
• Múltiples servidores web y servidores de bases de datos (los usuarios pueden acceder a través de cualquier servidor web)
• Vamos estancia agnóstico del lenguaje SQL o marca, ya que Lucene (y Solr) tienen una amplitud del apoyo

Por ejemplo:

dijo

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

índice por cliente y almacenarla en la base de datos del cliente . No estoy seguro de los detalles. Y no estoy seguro si esto es un mod seria a Lucene.

La Pregunta:

¿Cómo configuración Lucene búsqueda para que cada cliente sólo puede buscar dentro de su base de datos?

¿Cómo usted de configuración del índice (es)?
¿Dónde guarda el índice (es)?
Se necesita para añadir un filtro a todas las consultas de búsqueda?
Si un cliente cancela, ¿cómo eliminar su (parte del) índice? (Esto puede ser trivial - no estoy seguro todavía)

Posibles soluciones:

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

• Pro: La búsqueda es más rápida (de un índice para todos método). Los índices son en relación con el tamaño de los datos del cliente.
• En contra:. No estoy seguro de lo que esto implica, ni sé si esto está fuera del alcance de Lucene

Tener un índice único, gigantesco con un campo nombre_basedatos. Siempre incluya database_name como un filtro.

• Pro: No estoy seguro. Quizás sea bueno para el soporte técnico o departamento de facturación para buscar todas las bases de datos para obtener información.
• En contra: La búsqueda es más lento (que el método de índice por cliente). de seguridad con fallos si filtro de consulta eliminado.

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

Answer 1

me llamó desde el FogBugz StackExchange. Mi nombre es Judas, yo soy el arquitecto actual búsqueda de FogBugz.

He aquí un esbozo de cómo la arquitectura de búsqueda Demanda FogBugz En está configurado [1]:

• Por razones relacionadas con la portabilidad de datos, seguridad, etc., mantenemos todas nuestras bases de datos e índices separadas On Demand.
• Si bien utilizamos Lucene (Lucene.NET, en realidad), hemos modded su backend bastante sustancial para que pueda almacenar su índice en su totalidad en la base de datos. Además, una caché local se mantiene en cada servicio de hosting para que los accesos de bases de datos innecesarios pueden evitarse siempre que sea posible.
• Nuestros filtros son casi en su totalidad la base de datos del lado (ya que son utilizados por los aspectos de FogBugz exterior de búsqueda), por lo que las consultas de nuestra búsqueda del analizador se separa en componentes de texto completo y no a texto completo, ejecuta las operaciones de búsqueda y cosechadoras Los resultados. Esto es un poco lamentable, ya que anula muchas optimizaciones útiles que Lucene es capaz de hacer.

Hay algunas ventajas a lo que hemos hecho. La gestión de las cuentas es bastante simple, ya que los datos del cliente y su índice se almacenan en el mismo lugar. Hay algunos aspectos negativos también, sin embargo, como un conjunto de búsquedas de casos de borde muy molestos, que Underperform nuestros estándares mínimos. Retrospectivamente, nuestra búsqueda fue fresco y bien hecho para su época. Si tuviera que hacerlo de nuevo, sin embargo, yo desalentar este enfoque .

Simplemente, a menos que su dominio de búsqueda es muy especial o estás dispuesto a dedicar un desarrollador para buscar increíblemente rápido, lo que probablemente va a ser superado por un excelente producto como Elasticsearch, Solr o Xapian.

Si yo estuviera haciendo esto hoy en día, a menos que mi dominio de búsqueda fue muy específica, que probablemente utilice Elasticsearch, Solr o Xapian para mi solución Base de datos respaldados por búsqueda de texto completo. En cuanto a que, que depende de sus necesidades auxiliares (plataforma, tipo de consultas, extensibilidad, la tolerancia para un conjunto de peculiaridades sobre otro, etc.)

Sobre el tema de un índice grande en comparación con muchos dispersos índices (!): Ambos trabajan lata. Creo que la decisión realmente mentiras con qué tipo de arquitectura que está buscando para construir, y qué tipo de rendimiento que necesita. Puede ser bastante flexible si usted decide que 2 segundos de respuesta de búsqueda es razonable, pero una vez que comience diciendo que algo más de 200 ms es inaceptable, las opciones comienzan a desaparecer con bastante rapidez. Mientras se mantiene un único y gran índice de búsqueda para todos sus clientes puede ser mucho más eficiente que manejar una gran cantidad de índices pequeños, que no es necesariamente más rápido (como usted ha señalado). Personalmente, creo que, en un entorno seguro, el beneficio de mantener sus datos de cliente separado no debe ser subestimado. Cuando el índice se corrompe, no va a traer toda búsqueda a un alto; tontas pequeños insectos no van a exponer los datos sensibles; cuentas de usuario modular- estancia es más fácil de extraer un conjunto de cuentas y plop ellos en un nuevo servidor; etc.

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

[1]: En 2013, se inició la alimentación de FogBugz su búsqueda y capacidades de filtrado con Elasticsearch. Nos gusta.

Answer 2

Shalin Shekhar Mangar me respondió en el Solr fácil de lista de correo y por correo electrónico privado. Shalin es un contribuyente a Solr y autor del próximo libro Solr en Acción .

Su respuesta en la lista de correo:

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

  

me vería en la creación de múltiples núcleos para cada cliente. Es posible que tenga que configurar   esclavos, así como en función del tráfico de búsqueda.

¿Dónde se almacena el índice (es)?

  

Configuración de 5K núcleos en una caja no va a funcionar. Por lo que tendrá a la partición   los clientes en múltiples cajas tienen cada uno un subconjunto de núcleos.

se necesita para añadir un filtro a todas las consultas de búsqueda?

  

No, pero usted tendrá que enviar la consulta al host correcto (tal vez una   mapeo DB ayudará a)

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

  

Con diferentes núcleos para cada cliente, this'd ser bastante fácil.

Su respuesta por correo electrónico:

  

He trabajado en un caso de uso similar en el pasado y se utilizó el enfoque multi-núcleo con algunas optimizaciones pesados ??en el lado Solr. Ver http://wiki.apache.org/solr/LotsOfCores - no he sido capaz de empujar estos cambios en Solr todavía.

Answer 3

Estoy todavía no está claro de qué es exactamente de las bases de datos 5K usuarios están buscando, por las que necesita Lucene, y los tamaños de los datos en cada base de datos. Pero voy a tomar un golpe de todas formas:

1. Usted debe estar buscando en Multicore Solr (cada núcleo 1 = índice) y que tiene una URL única para consulta. Autenticación seguirá siendo un problema y una forma (hacker) que abordarlo sería hacer la URL difícil de adivinar.

2. Sus servidores web pueden consultar la instancia Solr / núcleo en función de lo que tienen acceso a.

Yo te sugeriría que mantenerse alejado del enfoque de filtro y la creación de un gran índice que combina todas las bases de datos.

HTH