Indexación Neo4j (con Lucene): ¿una buena forma de organizar los "tipos" de nodos?

Question

Esto es más bien más una pregunta de Lucene, pero está en el contexto de una base de datos neo4j.

Tengo una base de datos que está dividida en aproximadamente 50 tipos de nodos (por lo tanto, "colecciones" o "tablas" en otros tipos de dbs). Cada uno tiene un subconjunto de propiedades que deben indizarse, algunas comparten el mismo nombre y otras no.

Al buscar, siempre quiero encontrar nodos de un tipo específico, nunca en todos los nodos.

puedo ver tres formas de organizar esta:

• un índice por tipo, propiedades del mapa de forma natural a los campos de índice: índice de 'foo', 'id'='1234'.

• Un índice global único, cada campo se asigna a un nombre de propiedad, para distinguir el tipo incluirlo como parte del valor ('id'='foo:1234') o verificar los nodos una vez que se devuelven (espero que los duplicados sean muy raros)

• Un solo índice, tipo es parte del nombre del campo: 'foo.id'='1234'.

Una vez creada, la base de datos es de sólo lectura.

¿Hay algún beneficio para uno de ellos, en términos de conveniencia, tamaño/eficiencia de caché o rendimiento?

Según tengo entendido, para la primera opción, neo4j creará un índice físico separado para cada tipo, que parece no ser óptimo. Para el tercero, termino con la mayoría de los documentos de lucene teniendo solo un pequeño subconjunto de los campos, no estoy seguro si eso afecta algo.

Answer 1

Un solo índice será más pequeño que varios pequeños índices, porque algunos datos, como el diccionario, se compartirán. Sin embargo, dado que una búsqueda de diccionario de términos es una operación O (lg (n)), una búsqueda en un diccionario de términos más grandes podría ser un poco más lenta. (Si tiene 50 índices, esto solo requerirá 6 (2^6> = 50) más comparaciones, es probable que no note ninguna diferencia.)

Otra ventaja de un índice más pequeño es que el caché del sistema operativo es probable que las consultas se ejecuten más rápido.

En lugar de las opciones 2 y 3, lo haría índice dos campos diferentes id y type y búsqueda de (id: Identificación Y type: TIPO), pero no sé si es posible con Neo4j.

Answer 2

spring-data-neo4j está utilizando el primer enfoque: crea un índice diferente para cada tipo. Así que supongo que es una buena opción para el escenario general. Pero en su caso particular podría ser subóptimo, como usted dice. Me gustaría ejecutar algunos puntos de referencia para medir el rendimiento.

Las otras dos, por cierto, parecen un poco artificiales. Posiblemente esté indexando información completamente no relacionada en el mismo índice, lo cual no suena bien.

Answer 3

Me encontré con este problema recientemente cuando estaba construyendo un adaptador de conexión ActiveRecord para Neo4j sobre REST, para ser utilizado en un proyecto de Rails. Desde ActiveRecord y ActiveRelation, ambos tienen un acoplamiento ajustado con sintaxis SQL, se hizo difícil ajustar todo en NoSQL.Puede que no sea la mejor solución, pero aquí es cómo lo resolví:

1. Creado un índice llamado model_index el cual indexa linfáticos de dos llaves, type y model
2. búsqueda en el índice con type clave sucede actualmente con sólo un valor model . Esto se introdujo principalmente para lograr una funcionalidad SQL SHOW TABLES que me permita obtener una lista de todos los modelos presentes en el gráfico.
3. Búsqueda de índice con model La clave se lleva a cabo con los valores correspondientes a los diferentes nombres de modelo en mi sistema. Esto es principalmente para lograr la funcionalidad DESC <TABLENAME>.
4. Con cada creación de tabla como en CREATE TABLE, se crea un nodo con atributos de definición de tabla que se almacenan en propiedades de nodo.
5. El nodo creado está indexado en model_index con type:model y model:<model-name>. Esto habilita el modelo recién creado en la lista de 'tablas' y también permite que uno llegue directamente al nodo modelo mediante una búsqueda de índice con la clave model.
6. Para cada registro creado por model (escriba en su caso), se crea un borde saliente etiquetado instances dirigido desde el nodo modelo a este nuevo registro. v[123] :=> [instances] :=> v[245] donde v [123] representa el nodo modelo y v [245] representa un registro del tipo v [123].
7. Ahora, si desea obtener todas las instancias de un tipo especificado, puede buscar model_index con model:<model-name> para llegar a un nodo modelo y luego buscar todos los nodos adyacentes sobre un borde saliente etiquetado instances. Las búsquedas filtradas se pueden lograr mediante la aplicación de filtros y otros recorridos complejos.

La solución anterior impide que el modelo_índice se obstruya, ya que contiene 2x y logra una búsqueda efectiva de registros mediante una búsqueda de índice y un recorrido de un nivel.

Aunque en su caso, los nodos de diferentes tipos no son adyacentes entre sí, incluso si usted quisiera hacerlo, puede determinar el tipo de cualquier nodo arbitrario simplemente buscando su nodo adyacente con un borde entrante etiquetado instances . Además, estoy considerando incorporar el patrón SpringDataGraph de almacenar una propiedad __type__ en cada nodo de instancia para evitar esta búsqueda de nodo adyacente.

Actualmente estoy traduciendo AREL a scripts de Gremlin para casi todo. Puede encontrar el código fuente de mi adaptador de AR en https://github.com/yournextleap/activerecord-neo4j-adapter

Espero que esto ayude, ¡Salud! :)