Estoy dispuesto a almacenar un Property Graph en HBase. Un Property Graph es un gráfico de nodos y los bordes tienen propiedades y múltiples bordes pueden vincular la misma tupla de nodos siempre que los bordes pertenezcan a diferentes tipos.Modelo de datos para Property Graph sobre HBase/Cassandra
Mi patrón de consulta será pedir propiedades y vecindad o atravesar el gráfico. Un ejemplo es: Vertex [name = claudio] => OutgoingEdge [knows] => Vertex [gender = female], que me dará todas las mujeres que le gustan a claudio.
Sé que una base de datos de gráficos hace justamente esto, pero generalmente no se escalan en nodos múltiples en el caso de un gran conjunto de datos. Así que estoy dispuesto a implementar esto en un NoSQL ColumnStore (HBase, Cassandra ...)
Mi modelo de datos a continuación.
vértices Tabla:
clave: vertexid (UUID)
"Propiedades": familiares < nombre de la propiedad > => < valor de la propiedad >, ...
Familia "OutgoingEdges:": clave <borde> => < otra vertexid >, ...
familia "IncomingEdges:": igual que los bordes salientes ...
Esta tabla me permite a buscar rápidamente las propiedades de un vértice y su lista de adyacencia. No puedo usar el vertexid como el otro punto final porque los bordes múltiples (con diferentes tipos) pueden conectar los mismos dos vértices .
bordes de la mesa:
clave: clave borde (compuesto (< fuente vertexid >, < destino vertexid >, < nombretipo borde >)) (es decir vertexid1_vertexid2_knows)
familiares "Propiedades:": nombre <propiedad> => < valor de la propiedad >, ...
Esta tabla me permite buscar rápidamente las propiedades de un borde.
Bordes Tipos:
clave: compuestos (< fuente vertexid >, "fuera | in", < borde nombretipo >) (es decir vertexid1_out_knows)
Familia "Vecino": < destino vertexid > => null, ...
Esta tabla me permite buscar/SCAN para bordes que son ya sea entrante o saliente desde un vértice y pertenecen al tipo específico y sería el núcleo de la traversin g capacidad de la API (por lo que quiero que sea tan rápido como posible tanto en términos de E/S de red (RPC), E/S de disco (buscar)). Es también debe "escalar" en el tamaño del gráfico, lo que significa que con el crecimiento del gráfico el costo de este tipo de operación debe depender de el número de bordes salientes del vértice y no en el número total de vértices y bordes. El ejemplo anterior consideraría vertexid1 el vértice de origen con nombre de propiedad: claudio escanearía vertexid1_out_knows y recibiría la lista de los vértices conectados. Después de eso, puedo escanear en la columna "Propiedades: sexo" en estos vértices y buscar aquellos que tienen el valor "femenino".
Preguntas:
1) General: ¿Ves un mejor modelo de datos para las operaciones de mi?
2) ¿Puedo colocar todo en una tabla donde para ciertas claves algunas familias estarían vacías (es decir, la familia "OutgoingEdges:" no daría sentido a para los bordes)? Me gustaría porque, como puedes ver, todas las claves están compuestas por el prefijo vertexid uuid, por lo que serían muy compactas y se adaptarían principalmente al mismo servidor de regiones.
3) Supongo que para el escaneo haré un uso extenso de los filtros. I supongo que el filtro regexp será mi amigo. ¿Le preocupa el rendimiento de los filtros aplicado a este modelo de datos?