Diferencias arquitectónicas entre Neptune y Neo4j - Amazon Neptune

Las traducciones son generadas a través de traducción automática. En caso de conflicto entre la traducción y la version original de inglés, prevalecerá la version en inglés.

Diferencias arquitectónicas entre Neptune y Neo4j

Cuando los clientes se plantean por primera vez migrar una aplicación de Neo4j a Neptune, a menudo resulta tentador realizar una like-to-like comparación basada en el tamaño de la instancia. Sin embargo, las arquitecturas de Neo4j y Neptune tienen diferencias fundamentales. Neo4j se basa en un all-in-one enfoque en el que la carga de datos, los datosETL, las consultas a las aplicaciones, el almacenamiento de datos y las operaciones de administración se realizan en el mismo conjunto de recursos informáticos, como las instancias. EC2

Neptune, por el contrario, es una base de datos gráfica OLTP enfocada en la que la arquitectura separa las responsabilidades y donde los recursos se desacoplan para que puedan escalarse de forma dinámica e independiente.

Al migrar de Neo4j a Neptune, determine los requisitos de durabilidad, disponibilidad y escalabilidad de los datos de la aplicación. La arquitectura de clústeres de Neptune simplifica el diseño de aplicaciones que requieren una alta durabilidad, disponibilidad y escalabilidad. Una vez que comprenda la arquitectura de clústeres de Neptune, podrá diseñar una topología de clústeres de Neptune que haga frente a estos requisitos.

La arquitectura de clústeres de Neo4j

Muchas aplicaciones de producción utilizan la agrupación en clústeres causal de Neo4j para proporcionar durabilidad, alta disponibilidad y escalabilidad de los datos. La arquitectura de agrupación en clústeres de Neo4j utiliza instancias de servidor de núcleo e instancias de réplica de lectura:

  • Los servidores de núcleo garantizan la durabilidad de los datos y la tolerancia a los errores al replicar los datos mediante el protocolo Raft.

  • Las réplicas de lectura utilizan el envío de registros de transacciones para replicar datos de forma asíncrona para cargas de trabajo de alto rendimiento de lectura.

Cada instancia de un clúster, ya sea un servidor de núcleo o una réplica de lectura, incluye una copia completa de los datos del gráfico.

Arquitectura de clústeres de Neptune

Un clúster de Neptune consta de una instancia de escritor principal y hasta 15 instancias de réplica de lectura. Todas las instancias del clúster comparten el mismo servicio de almacenamiento distribuido subyacente que es independiente de las instancias.

  • La instancia de escritor principal coordina todas las operaciones de escritura en la base de datos y se puede escalar verticalmente para ofrecer un soporte flexible a diferentes cargas de trabajo de escritura. También admite operaciones de lectura.

  • Las instancias de réplica de lectura admiten operaciones de lectura del volumen de almacenamiento subyacente y permiten escalar horizontalmente para admitir cargas de trabajo de lectura elevadas. También proporcionan alta disponibilidad al servir como destinos de conmutación por error para la instancia principal.

    nota

    En el caso de cargas de trabajo de escritura intensas, se recomienda escalar las instancias de réplica de lectura para que tengan el mismo tamaño que la instancia de escritor, con el fin de garantizar que los lectores puedan mantener la coherencia con los cambios realizados en los datos.

  • El volumen de almacenamiento subyacente escala la capacidad de almacenamiento automáticamente a medida que aumentan los datos de la base de datos, hasta 128 tebibytes (TiB) de almacenamiento.

Los tamaños de las instancias son dinámicos e independientes. Se puede cambiar el tamaño de cada instancia mientras el clúster esté en ejecución, y las réplicas de lectura se pueden añadir o eliminar mientras el clúster esté en ejecución.

La característica Neptune sin servidor puede escalar y reducir verticalmente de forma automática su capacidad de cómputo a medida que la demanda aumenta y disminuye. Esto no solo reduce la sobrecarga administrativa, sino que también permite configurar la base de datos para gestionar los grandes picos de demanda sin que disminuya el rendimiento ni sea necesario un aprovisionamiento excesivo.

Puede detener un clúster de Neptune durante un máximo de siete días.

Neptune también admite el escalado automático para ajustar automáticamente los tamaños de las instancias de lector en función de la carga de trabajo.

Con la característica de base de datos global de Neptune, puede duplicar un clúster en otras cinco regiones como máximo.

Neptune también ofrece tolerancia a errores por diseño:

  • El volumen del clúster que proporciona almacenamiento de datos a todas las instancias del clúster abarca varias zonas de disponibilidad (AZs) en una sola. Región de AWS Cada zona de disponibilidad incluye una copia completa de los datos del clúster.

  • Si la instancia principal deja de estar disponible, Neptune realiza automáticamente la conmutación por error a una réplica de lectura existente sin pérdida de datos, normalmente en menos de 30 segundos. Si no hay réplicas de lectura en el clúster, Neptune aprovisiona automáticamente una nueva instancia principal, una vez más, sin pérdida de datos.

Lo que todo esto significa es que, al migrar de un clúster causal de Neo4j a Neptune, no es necesario diseñar la topología del clúster de forma explícita para lograr alta disponibilidad y durabilidad de los datos. Esto le permite ajustar el tamaño del clúster a las cargas de trabajo de lectura y escritura previstas y a cualquier requisito de mayor disponibilidad que pueda tener de varias maneras:

  • Para escalar las operaciones de lectura, añada instancias de réplica de lectura o habilite la funcionalidad Neptune sin servidor.

  • Para mejorar la disponibilidad, distribuya la instancia principal y lea las réplicas del clúster en varias zonas de disponibilidad ()AZs.

  • Para reducir el tiempo de conmutación por error, aprovisione al menos una instancia de réplica de lectura que pueda servir como destino de conmutación por error para la principal. Puede determinar el orden en que se promueven las instancias de réplicas de lectura a la principal tras un error mediante la asignación de una prioridad a cada réplica. Una práctica recomendada es asegurarse que un destino de conmutación por error tenga una clase de instancia capaz de gestionar la carga de trabajo de escritura de la aplicación si se promociona a principal.