online - Aspecto de fragmentación Neo4j

neo4j sandbox (2)

Miraba la escalabilidad de Neo4j y leí un documento escrito por David Montag en enero de 2013.

Respecto al aspecto de la fragmentación, dijo que el primer lanzamiento de 2014 vendría con una primera solución.

¿Alguien sabe si fue hecho o su estado si no?

¡Gracias!

TL; DR Con 2018 neo4j días para que neo4j aún no admita la sharding ya que generalmente se considera.

Detalles Neo4j aún requiere que todos los datos se ajusten a un solo nodo. El contenido del nodo se puede replicar dentro de un grupo, pero la fragmentación real no es parte de la imagen.

Cuando neo4j habla de fragmentación, se refieren al almacenamiento en caché de partes de la base de datos en la memoria: diferentes segmentos se almacenan en caché en diferentes nodos replicados. Eso difiere de, por ejemplo, el fragmento de mysql, en el que cada nodo contiene solo una parte de los datos totales.

Aquí hay un resumen de su "toma" en la escalabilidad: su término de producto es "Alta disponibilidad" https://neo4j.com/blog/neo4j-scalability-infographic/

. Tenga en cuenta que la High Availability no debe ser lo mismo que la Scalability : por lo tanto, en realidad no son compatibles con esta última en la comprensión tradicional del término.

Divulgación: estoy trabajando como Vicepresidente de Productos para Neo Technology, el patrocinador de la base de datos de gráficos de código abierto Neo4j.

Ahora que acabamos de lanzar Neo4j 2.0 (¡en realidad 2.0.1 hoy!) Nos estamos embarcando en una versión 2.1 que está orientada principalmente hacia (aún más) el rendimiento y la escalabilidad. Esto aumentará los límites superiores del gráfico a un número efectivamente ilimitado de entidades, y mejorará varias otras cosas.

Permítame establecer un poco de contexto primero, y luego contestar su pregunta.

Como probablemente viste en el documento, la arquitectura de escala horizontal actual de Neo4j permite la escala de lectura, y todas las escrituras se van a masterizar y expandir. Esto le permite una escala de lectura efectivamente ilimitada, y en las decenas de miles de escrituras por segundo.

En términos prácticos, hay clientes de Neo4j de producción (incluidos Snap Interactive y Glassdoor) con alrededor de mil millones de personas en su gráfico social ... en todos los casos detrás de un sitio web activo y muy afectado, siendo manejado por grupos de Neo4j relativamente bastante modestos (no más de 5 instancias). Así que esa es una característica clave: el Neo4j de hoy en día tiene una densidad computacional increíble, por lo que regularmente vemos grupos bastante pequeños que manejan una carga de trabajo de producción sustancialmente grande ... con tiempos de respuesta muy rápidos.

Puede encontrar más información sobre la arquitectura actual aquí: www.neotechnology.com/neo4j-scales-for-the-enterprise/ Y una lista de clientes (que incluye compañías como Wal-Mart y eBay) se puede encontrar aquí: neotechnology.com/customers/ Uno de los proveedores de servicios de paquetería más grandes del mundo utiliza Neo4j para enrutar todos sus paquetes, en tiempo real, con picos de 3000 operaciones de enrutamiento por segundo y cero tiempos de inactividad. (Podría decirse que este es el uso más grande y más crítico del mundo de una base de datos gráfica y de una base de datos NOSQL; aunque desafortunadamente no puedo decir quién es).

Entonces, en cierto sentido, el tl; dr es que si todavía no eres tan grande como Wal-Mart o eBay, entonces probablemente estés bien. Eso lo simplifica demasiado solo un poco. Existe el 1% de los casos en los que ha sostenido cargas de trabajo transaccionales de escritura en los cientos de miles por segundo. Sin embargo, incluso en esos casos a menudo no es lo correcto cargar todos esos datos en el gráfico en tiempo real. Por lo general, aconsejamos a las personas que realicen algún tipo de agregación o filtrado, y que solo traigan las cosas más importantes al gráfico. Intuit dio una buena charla sobre esto. Filtran mil millones de transacciones B2B en un número mucho menor de relaciones de transacciones mensuales agregadas con conteos agregados y montos de moneda por dirección.

Enter sharding ... Sharding ha ganado mucha popularidad en estos días. Esto es en gran parte gracias a las otras tres categorías de NOSQL, donde las uniones son un anti-patrón. La mayoría de las consultas implican leer o escribir una sola pieza de datos discretos. Así como la unión es un antipatrón para almacenes de valores clave y bases de datos de documentos, sharding es un antipatrón para bases de datos de gráficos. Lo que quiero decir con eso es que ... el mejor rendimiento se producirá cuando todos sus datos estén disponibles en la memoria en una sola instancia, ya que saltar de un lado a otro en toda la red cada vez que lea y escriba disminuirá significativamente la velocidad. , a menos que haya sido realmente muy inteligente acerca de cómo distribuir sus datos ... e incluso entonces. Nuestro enfoque ha sido doble:

Haga tantas cosas inteligentes como sea posible para admitir volúmenes de lectura y escritura extremadamente altos sin tener que recurrir a fragmentación. Esto le proporciona la mejor y más previsible latencia y eficiencia. En otras palabras: si podemos ser lo suficientemente buenos para satisfacer sus requisitos sin fragmentar, ese siempre será el mejor enfoque. El enlace anterior describe algunos de estos trucos, incluido el patrón de implementación que le permite fragmentar sus datos en la memoria sin tener que fragmentarlos en el disco (un truco que llamamos fragmentación de caché). Hay otros trucos a lo largo de líneas similares, y más que vienen por el lucio ...
Agregue un patrón de arquitectura secundaria en Neo4j que admita fragmentación. ¿Por qué hacer esto si es mejor evitar la fragmentación? A medida que más personas encuentren más usos para los gráficos y los volúmenes de datos continúen aumentando, creemos que eventualmente será una cosa importante e inevitable. Esto le permitiría ejecutar todo Facebook, por ejemplo, en un clúster Neo4j (uno bastante grande) ... no solo la parte social del gráfico, que podemos manejar hoy. Ya hemos trabajado mucho en esto, y hemos desarrollado una arquitectura que creemos que soporta las muchas consideraciones. Este es un esfuerzo de varios años, y aunque podríamos lanzar fácilmente una versión de Neo4j que se fragmenta de forma ingenua (sin duda sería muy popular), probablemente no lo hagamos. Queremos hacerlo bien, lo que equivale a la ciencia espacial.