Le traduzioni sono generate tramite traduzione automatica. In caso di conflitto tra il contenuto di una traduzione e la versione originale in Inglese, quest'ultima prevarrà.
Amazon Neptune offre diverse dimensioni e famiglie di istanze, che offrono funzionalità diverse adatte a diversi carichi di lavoro a grafo. In questa sezione è possibile scegliere il tipo di istanza migliore per le tue esigenze.
Per i prezzi di ogni tipo di istanza di queste famiglie, consulta la pagina dei prezzi di Neptune
Panoramica dell'allocazione delle risorse delle istanze
Ogni tipo e dimensione di EC2 istanza Amazon utilizzati in Neptune offre una quantità definita di memoria di calcolo (CPUsv) e di sistema. L'archiviazione primaria di Neptune è esterna alle istanze database in un cluster, il che consente di dimensionare la capacità di calcolo e di archiviazione indipendentemente l'una dall'altra.
Questa sezione si concentra su come dimensionare le risorse di calcolo e sulle differenze tra ciascuna delle varie famiglie di istanze.
In tutte le famiglie di istanze, le risorse vCPU sono allocate per supportare due (2) thread di esecuzione di query per vCPU. Questo supporto è dettato dalla dimensione dell'istanza. Per determinare la dimensione corretta di una determinata istanza database di Neptune, è necessario considerare la possibile concorrenza dell'applicazione e la latenza media delle query. Puoi stimare il numero di v CPUs necessari come segue, dove la latenza viene misurata come latenza media delle query in secondi e la concorrenza viene misurata come il numero target di query al secondo:
vCPUs=(latencyxconcurrency)/2Nota
Le query SPARQL, le query openCypher e le query di lettura Gremlin che utilizzano il motore di query DFE possono, in determinate circostanze, utilizzare più di un thread di esecuzione per query. Quando si dimensiona inizialmente il cluster database, si parte dal presupposto che ogni query consumerà un singolo thread per esecuzione che può essere aumentato se si osserva una contropressione nella coda di query. Questo può essere osservato utilizzando, o /gremlin/status /oc/status /sparql/status APIs, oppure può essere osservato anche utilizzando la metrica. MainRequestsPendingRequestsQueue CloudWatch
La memoria di sistema di ogni istanza è suddivisa in due allocazioni principali: cache del pool di buffer e memoria dei thread di esecuzione delle query.
Circa due terzi della memoria disponibile in un'istanza sono allocati per la cache del pool di buffer. La cache del pool di buffer viene utilizzata per memorizzare nella cache i componenti del grafo utilizzati più di recente per un accesso più rapido alle query che accedono ripetutamente a tali componenti. Le istanze con una maggiore quantità di memoria di sistema dispongono di cache del pool di buffer più grandi in grado di archiviare localmente una parte maggiore del grafo. Un utente può effettuare l'ottimizzazione della quantità appropriata di cache del buffer-pool monitorando le metriche relative agli accessi e gli errori della buffer cache disponibili in. CloudWatch
Può essere necessario aumentare la dimensione dell'istanza se la percentuale di riscontri nella cache scende al di sotto del 99,9% per un periodo di tempo costante. Ciò suggerisce che il pool di buffer non è sufficientemente grande e che il motore deve recuperare i dati dal volume di archiviazione sottostante più spesso di quanto sia efficiente.
Il terzo restante della memoria di sistema è distribuito in modo uniforme tra i thread di esecuzione delle query, con una parte di memoria residua per il sistema operativo e un piccolo pool dinamico che i thread possono utilizzare in base alle esigenze. La memoria disponibile per ogni thread aumenta leggermente da una dimensione di istanza all'altra fino a un tipo di istanza 8xl, dimensione alla quale la memoria allocata per thread raggiunge il massimo.
Il momento di aggiungere altra memoria ai thread è quando si verifica un'eccezione OutOfMemoryException (OOM). Le eccezioni OOM si verificano quando un thread richiede una quantità di memoria superiore a quella massima ad esso allocata. Ciò non significa che l'intera istanza stia esaurendo la memoria.
Tipi di istanza t3 e t4g
La famiglia di istanze t3 e t4g offre un'opzione a basso costo per iniziare a utilizzare un database a grafo e anche per lo sviluppo e i test iniziali. Queste istanze sono idonee per l'offerta gratuita di Neptune
Le istanze t3 e t4g sono disponibili solo nella configurazione di medie dimensioni (t3.medium e t4g.medium).
Non sono destinate all'uso in un ambiente di produzione.
Poiché queste istanze dispongono di risorse molto limitate, non sono consigliate per testare il tempo di esecuzione delle query o le prestazioni complessive del database. Per valutare le prestazioni delle query, esegui l'aggiornamento a una delle altre famiglie di istanze.
Famiglia di tipi di istanza r4
OBSOLETA: la famiglia r4 è stata offerta al momento del lancio di Neptune nel 2018, ma ora i tipi di istanza più recenti offrono un rapporto prezzo/prestazioni molto migliore. A partire dalla versione 1.1.0.0 del motore, Neptune non supporta più i tipi di istanza r4.
Famiglia di tipi di istanza r5
La famiglia r5 contiene tipi di istanza ottimizzata per la memoria che funzionano bene per la maggior parte dei casi d'uso a grafo. La famiglia r5 contiene tipi di istanza da r5.large a r5.24xlarge. Le prestazioni di calcolo di questi tipi di istanza aumentano in modo lineare con l'aumentare delle dimensioni. Ad esempio, un r5.xlarge (4 v CPUs e 32 GiB di memoria) ha il doppio di v CPUs e memoria di an r5.large (2 v CPUs e 16 GiB di memoria) e un r5.2xlarge (8 v CPUs e 64 GiB di memoria) ha il doppio di v CPUs e memoria di anr5.xlarge. Le prestazioni delle query aumentano direttamente con la capacità di calcolo fino al tipo di istanza r5.12xlarge.
La famiglia di istanze r5 ha un'architettura CPU Intel a 2 socket. Il tipo r5.12xlarge e quelli più piccoli utilizzano un socket singolo e la memoria di sistema di proprietà di quel processore a socket singolo. I tipi r5.16xlarge e r5.24xlarge utilizzano entrambi i socket e la memoria disponibile. Poiché è necessario un certo sovraccarico di gestione della memoria tra due processori fisici in un'architettura a 2 socket, i vantaggi in termini di prestazioni che si ottengono passando da un tipo di istanza r5.12xlarge a un tipo di istanza r5.16xlarge o r5.24xlarge non sono così lineari come quelli che si ottengono passando a istanze di dimensioni inferiori.
Famiglia di tipi di istanza r5d
Neptune dispone di una funzionalità di cache di ricerca che può essere utilizzata per migliorare le prestazioni delle query che devono recuperare e restituire un gran numero di valori di proprietà e valori letterali. Questa funzionalità viene utilizzata principalmente dai clienti con query che devono restituire molti attributi. La cache di ricerca migliora le prestazioni di queste query recuperando questi valori degli attributi localmente anziché cercarli ripetutamente nell'archiviazione indicizzata di Neptune.
La cache di ricerca viene implementata utilizzando un volume EBS collegato su un tipo di NVMe istanza. r5d Viene abilitata utilizzando il gruppo di parametri di un cluster. Man mano che i dati vengono recuperati dall'archivio indicizzato di Neptune, i valori delle proprietà e i valori letterali RDF vengono memorizzati nella cache all'interno di questo volume. NVMe
Se non è necessaria la funzionalità di cache di ricerca, utilizza un tipo di istanza r5 standard anziché un tipo r5d, per evitare il costo più elevato del tipo r5d
La famiglia r5d ha tipi di istanza delle stesse dimensioni della famiglia r5, da r5d.large a r5d.24xlarge.
Famiglia di tipi di istanza r6g
AWS ha sviluppato un proprio processore basato su ARM chiamato Gravitonr6g utilizza il processore Graviton2. Nei nostri test, il processore Graviton2 offre prestazioni migliori del 10-20% per le query a grafo di tipo OLTP (vincolate). Le query più grandi, di tipo OLAP, tuttavia, potrebbero essere leggermente meno performanti con i processori Graviton2 rispetto a quelli Intel a causa delle prestazioni di paging della memoria leggermente inferiori.
È anche importante notare che la famiglia r6g ha un'architettura a socket singolo, il che significa che le prestazioni aumentano in modo lineare con la capacità di calcolo da un tipo r6g.large a un tipo r6g.16xlarge (il tipo più grande della famiglia).
Famiglia di tipi di istanza r6i
Le istanze Amazon R6i
Famiglia di tipi di istanza x2g
Alcuni casi d'uso a grafo ottengono prestazioni migliori quando le istanze dispongono di cache del pool di buffer più grandi. La famiglia x2g è stata lanciata per supportare meglio questi casi d'uso. La x2g famiglia ha un memory-to-vCPU rapporto maggiore rispetto alla famiglia or. r5 r6g Anche le istanze x2g utilizzano il processore Graviton2 e hanno molte delle stesse caratteristiche prestazionali dei tipi di istanza r6g, oltre a una cache del pool di buffer più grande.
Se utilizzi tipi di r6g istanze r5 o con un basso utilizzo della CPU e un elevato tasso di errore nella cache con pool di buffer, prova invece a utilizzare la x2g famiglia. In questo modo, otterrai la memoria aggiuntiva di cui hai bisogno senza pagare per una maggiore capacità della CPU.
Tipo di istanza serverless
La funzionalità Neptune Serverless può dimensionare le dimensioni delle istanze in modo dinamico in base alle esigenze di risorse del carico di lavoro. Invece di calcolare quante v CPUs sono necessarie per l'applicazione, Neptune Serverless consente di impostare limiti inferiori e superiori alla capacità di calcolo (misurati in unità di capacità Neptune) per le istanze del cluster DB. I carichi di lavoro con utilizzo variabile possono essere ottimizzati in termini di costi utilizzando istanze serverless anziché istanze con provisioning.
È possibile configurare istanze con provisioning e serverless nello stesso cluster database per ottenere una configurazione ottimale in termini di costi e prestazioni.
