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.
Elección del tipo de instancia de base de datos de Neptune correcto
Amazon Neptune dispone de varios tamaños y familias de instancias diferentes, que ofrecen distintas capacidades que se adaptan a diferentes cargas de trabajo de gráficos. El objetivo de esta sección es ayudarle a elegir el mejor tipo de instancia para sus necesidades.
Para conocer los precios de cada tipo de instancia de estas familias, consulte la página de precios de Neptune
Información general sobre la asignación de recursos de instancias
Cada tipo y tamaño de instancia de Amazon EC2 que se utiliza en Neptune tiene una cantidad definida de computación (vCPU) y memoria del sistema. El almacenamiento principal de Neptune es externo a las instancias de base de datos de un clúster, lo que permite que la capacidad de procesamiento y almacenamiento se escale de forma independiente.
Esta sección se centra en cómo se pueden escalar los recursos de computación y en las diferencias entre cada una de las distintas familias de instancias.
En todas las familias de instancias, los recursos de vCPU se asignan para admitir dos (2) subprocesos de ejecución de consultas por vCPU. Esta capacidad viene determinada por el tamaño de la instancia. Al determinar el tamaño adecuado de una instancia de base de datos de Neptune específica, debe tener en cuenta la posible simultaneidad de la aplicación y la latencia media de las consultas. Puede calcular la cantidad de vCPU necesaria de la siguiente manera, donde la latencia se mide como la latencia media de consultas en segundos y la simultaneidad se mide como el número objetivo de consultas por segundo:
nota
En determinadas circunstancias, las consultas de SPARQL, las consultas de openCypher y las consultas de lectura de Gremlin que utiliza el motor de consultas de DFE pueden emplear más de un subproceso de ejecución por consulta. Al dimensionar inicialmente el clúster de base de datos, comience con la suposición de que cada consulta consume un único subproceso de ejecución por ejecución y escale verticalmente si observa una contrapresión en la cola de consultas. Esto se puede observar mediante el uso de /sparql/status las API /gremlin/status/oc/status, o también se puede observar mediante la métrica. MainRequestsPendingRequestsQueue CloudWatch
La memoria del sistema de cada instancia se divide en dos asignaciones principales: la caché del grupo de búferes y la memoria de subprocesos de ejecución de consultas.
Aproximadamente dos tercios de la memoria disponible de una instancia se asigna a la caché del grupo de búferes. La caché del grupo de búferes se usa para almacenar en caché los componentes del gráfico utilizados más recientemente para acceder más rápidamente a las consultas que acceden repetidamente a esos componentes. Las instancias con una mayor cantidad de memoria del sistema tienen cachés de grupos de búferes más grandes que pueden almacenar una mayor parte del gráfico de forma local. Un usuario puede ajustar la cantidad adecuada de caché del búfer agrupado supervisando las métricas de aciertos y errores de caché disponibles en el búfer. CloudWatch
Es posible que desee aumentar el tamaño de la instancia si la tasa de aciertos de caché desciende por debajo del 99,9 % durante un período de tiempo constante. Esto sugiere que el conjunto de búferes no es lo suficientemente grande y que el motor tiene que buscar datos del volumen de almacenamiento subyacente con una frecuencia que no es eficiente.
El tercio restante de la memoria del sistema se distribuye de manera uniforme entre los subprocesos de ejecución de consultas, con algo de memoria restante para el sistema operativo y un pequeño grupo dinámico para que los subprocesos la utilicen según sea necesario. La memoria disponible para cada subproceso aumenta ligeramente de un tamaño de instancia a otro hasta llegar a un tipo de instancia 8xl, a cuyo tamaño la memoria asignada por subproceso alcanza el máximo.
El momento de añadir más memoria de subprocesos es cuando se encuentra con una OutOfMemoryException (OOM). Las excepciones OOM se producen cuando un subproceso necesita más memoria que la máxima que se le ha asignado (esto no es lo mismo que toda la instancia se quede sin memoria).
Tipos de instancias t3 y t4g
La familia de instancias t3 y t4g es una opción económica para empezar a utilizar una base de datos de gráficos y también para el desarrollo y las pruebas iniciales. Estas instancias son aptas para la oferta de capa gratuita
Las instancias t3 y t4g solo se ofrecen en la configuración de tamaño medio (t3.medium y t4g.medium).
No se han diseñado para utilizarse en un entorno de producción.
Dado que estas instancias tienen recursos muy limitados, no se recomiendan para probar el tiempo de ejecución de las consultas o el rendimiento general de la base de datos. Para evaluar el rendimiento de las consultas, actualice a una de las otras familias de instancias.
Familia r4 de tipos de instancias
EN DESUSO: la familia r4 se ofreció en 2018 cuando se lanzó Neptune, pero ahora los tipos de instancias más recientes tienen una relación precio-rendimiento mucho mejor. A partir de la versión 1.1.0.0 del motor, Neptune ya no admite tipos de instancias r4.
Familia r5 de tipos de instancias
La familia r5 contiene tipos de instancias optimizadas para memoria que funcionan bien en la mayoría de los casos de uso de gráficos. La familia r5 contiene tipos de instancias desde r5.large hasta r5.24xlarge. Escalan linealmente el rendimiento de computación a medida que aumenta el tamaño. Por ejemplo, un r5.xlarge (4 vCPU y 32 GiB de memoria) tiene el doble de vCPU y memoria que un r5.large (2 vCPU y 16 GiB de memoria), y un r5.2xlarge (8 vCPU y 64 GiB de memoria) tiene el doble de vCPU y memoria que un r5.xlarge. Puede esperar que el rendimiento de las consultas se escale directamente con la capacidad de computación con tipos de instancias de hasta r5.12xlarge.
La familia de instancias r5 tiene una arquitectura de CPU Intel de 2 sockets. Los tipos r5.12xlarge y los más pequeños utilizan un solo socket y la memoria del sistema es propiedad de ese procesador de un solo socket. Los tipos r5.16xlarge y r5.24xlarge utilizan los dos sockets y la memoria disponible. Dado que se requiere cierta sobrecarga en la administración de la memoria entre dos procesadores físicos de una arquitectura de 2 sockets, las ganancias de rendimiento si se escala verticalmente de un tipo de instancia r5.12xlarge a un r5.16xlarge o r5.24xlarge no son tan lineales como las que se obtienen escalando verticalmente los tamaños más pequeños.
Familia r5d de tipos de instancias
Neptune tiene una característica de caché de búsqueda que se puede utilizar para mejorar el rendimiento de las consultas que necesitan recuperar y devolver un gran número de valores de propiedades y literales. Esta característica la utilizan principalmente los clientes con consultas que necesitan devolver muchos atributos. La caché de búsqueda mejora el rendimiento de estas consultas al obtener estos valores de atributos de forma local en lugar de buscarlos una y otra vez en el almacenamiento indexado de Neptune.
La caché de búsqueda se implementa mediante un volumen de EBS asociado a NVMe en un tipo de instancia r5d. Se habilita mediante un grupo de parámetros de un clúster. A medida que los datos se obtienen del almacenamiento indexado de Neptune, los valores de las propiedades y los literales de RDF se almacenan en caché en este volumen de NVMe.
Si no necesita la característica de caché de búsqueda, utilice un tipo de instancia r5 estándar en lugar de r5d para evitar el mayor costo que supone r5d.
La familia r5d tiene tipos de instancias del mismo tamaño que la familia r5, desde r5d.large hasta r5d.24xlarge.
Familia r6g de tipos de instancias
AWS ha desarrollado su propio procesador basado en ARM, llamado Gravitonr6g utiliza el procesador Graviton2. En nuestras pruebas, el procesador Graviton2 ofrece un rendimiento entre un 10 y un 20 % mejor para las consultas gráficas de estilo OLTP (restringidas). Sin embargo, las consultas más grandes, tipo OLAP, pueden tener un rendimiento ligeramente inferior con los procesadores Graviton2 que con los procesadores Intel, debido a que el rendimiento de paginación de memoria es ligeramente inferior.
También es importante tener en cuenta que la familia r6g tiene una arquitectura de un solo socket, lo que significa que el rendimiento se escala linealmente con la capacidad de computación, desde un r6g.large a un r6g.16xlarge (el tipo más grande de la familia).
Familia r6i de tipos de instancias
Las instancias Amazon R6i
Familia x2g de tipos de instancias
Algunos casos de uso de gráficos tienen mejor rendimiento cuando las instancias tienen cachés de grupos de búferes más grandes. La familia x2g se lanzó para facilitar mejor esos casos de uso. La x2g familia tiene una relación de memory-to-v CPU mayor que la familia or. r5 r6g Las instancias x2g también utilizan el procesador Graviton2 y tienen muchas de las mismas características de rendimiento que los tipos de instancias r6g, además de una memoria caché de grupos de búferes más grande.
Si tiene tipos de instancias r5 o r6g con un bajo uso de la CPU y una alta tasa de errores de caché del grupo de búferes, pruebe a usar la familia x2g en su lugar. De esta forma, conseguirá la memoria adicional que necesita sin tener que pagar más capacidad de CPU.
Tipo de instancia serverless
La característica Neptune sin servidor puede escalar el tamaño de la instancia de forma dinámica en función de las necesidades de recursos de la carga de trabajo. En lugar de calcular cuántas vCPU se necesitan para su aplicación, Neptune sin servidor le permite establecer unos límites inferior y superior en la capacidad de computación (medidos en unidades de capacidad de Neptune) para las instancias de su clúster de base de datos. Los costos de las cargas de trabajo con distintos usos se pueden optimizar si se utilizan instancias sin servidor en lugar de aprovisionadas.
Puede configurar instancias aprovisionadas y sin servidor en el mismo clúster de base de datos para lograr una configuración con una relación costo-rendimiento óptima.
