lucene.net - query - Indización de Lucene: ¿compartido o aislado por cuenta?

lucene search example

Question

Estoy evaluando Lucene para implementar una función de búsqueda global en una aplicación SaaS.

No queremos que los usuarios vean el contenido de las otras cuentas, por lo que las búsquedas siempre estarán limitadas por cuenta.

¿Es mejor tener un solo índice con un campo de identificación de cuenta o un índice por cuenta? ¿Cuáles son las ventajas y desventajas de cada enfoque?

Mi preocupación es que un índice global podría afectar el rendimiento debido a las frecuentes actualizaciones.

Gracias.

EDITAR

• Número estimado de documentos totales: 500,0000
• Número de cuentas: 4000
• Los datos indexables nunca se comparten entre cuentas
• Los usuarios de la cuenta pueden actualizar sus datos indexables varias veces al día (no más de 100 en la mayoría de los casos)
• La cantidad de datos indexados tiende a ser estable después del proceso de configuración inicial
• Necesitamos almacenar 10-20 campos por documento

Answer 1

Aquí hay algunas cosas en las que pensaría además de los problemas habituales (por ejemplo, actualizaciones de índice y demás):

1. La forma en que lucene devuelve resultados ordenados depende de algunas estadísticas de "todo el corpus", por ejemplo, la cantidad total de documentos en los que aparece un término para ese campo. Entonces, si las estadísticas del índice para el cliente a son inapropiadas para el cliente b, afectará la relevancia para ambos clientes, además de ser un riesgo de seguridad ... si Oscar es lo suficientemente inteligente, realmente puede comenzar a revertir los documentos de Bob debido a la naturaleza del índice invertido: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.159.9682 Probablemente puedas solucionar esto con algo así como este algoritmo de clasificación: https://issues.apache.org/jira / browse / LUCENE-2864
2. Algunas otras cosas en lucene se aplican a un "campo como un todo" o "índice como un todo" y debe saber que no se pueden cambiar realmente por cliente si agrupa índices juntos: cosas como omitTF (si lo configura en un solo documento para un campo, se omite en general para ese campo), similitud (en cualquier versión publicada de lucene, solo puede establecer similitudes en general, para que los clientes no puedan ajustar el ranking modelo), revisión ortográfica (tendría que hackear algo, donde cada cliente tiene su propio índice de corrección ortográfica "filtrado"), ...
3. Por otro lado, si tiene muchos términos, se requiere bastante RAM y al darle a cada cliente su propio índice, necesitará más memoria para mantener el índice de términos en la RAM, para todos los índices. Sin embargo, puede reducir esto un poco ajustando cosas como termIndexInterval / Divisor.

Answer 2

He hecho algunos índices de "seguridad recortada" aquí y allá, definitivamente es posible si está permitido. Dicho esto, mi inclinación general con el tipo de SAAS con múltiples clientes sería separar a los clientes tanto como sea posible por algunas razones:

a) Asegura que los errores de codificación no den lugar a filtraciones de datos, clientes enojados, demandas judiciales y otras cuestiones.
b) Facilita la personalización por cliente: toda la base de código no necesita ocuparse de las solicitudes fubar específicas del cliente
c) Te fuerza a una arquitectura escalable horizontalmente desde el primer día: la escala es fácil si agregar instancias es fácil, ¿no?

Oh, y definitivamente sigue los consejos de Will Hartung: búsqueda de fachada, esas cosas realmente no deberían salir de su capa.

Answer 3

Si fuera yo, si no hay una razón regulatoria por la que no puedas, los incluiría en un solo índice. Este es simplemente mi "no optimizo lo que no tienes que" hablar.

La primera preocupación es simplemente legal: incluso se le permite co-host e intermezclar datos, incluso si está separado por medios lógicos. Eso depende de sus abogados, clientes y acuerdos de servicio. Esto no es una preocupación técnica.

Suponiendo que pueda, la próxima pregunta es qué impacto tendrán los otros usuarios sobre el otro. Si el Usuario A está utilizando el sistema y el Usuario B está en proceso de importar sus documentos de 100K, ¿afectará eso al Usuario A? ¿Está afectando al usuario A debido a cómo funciona Lucene, o simplemente debido a la carga general del sistema que se produce al importar e indexar documentos?

Pruébalo y mira.

La clave es asegurarse de que sus sistemas cliente no accedan directamente a Lucene, sino a través de una fachada de algún tipo. Esta fachada es un lugar perfecto para hacer cumplir la segregación del cliente, y también es un buen lugar para redirigir el tráfico si, en algún momento posterior, decide que necesita fragmentar sus índices.

Tal vez necesites arrancar a un solo usuario pesado. O bien, vende un mayor nivel de tiempo de respuesta a alguien que tiene garantizados más recursos en su SLA, etc.

Pero decidir, en este momento, ¿cuál es el mejor camino? Eh, parece temprano.

500K documentos no son muchos datos para Lucene. Solo asegúrese de tener flexibilidad en su implementación para agregar capacidad más adelante si descubre que hospedarlo todo en una sola instancia no es viable. Y con "añadir capacidad" quiero decir exactamente eso, agrégalo. En realidad, NO IMPLEMENTE, digamos, sharding basado en el cliente. Pero mejor dicho, tenga un buen punto donde PODRÍA implementarse sin volver a hacer un montón de plomería más adelante.