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à.
Preparatevi per la crescita
Quando si utilizza con successo il modello di pool, alla fine si superano le dimensioni di un singolo cluster Neptune. I tenant crescono, o il numero di tenant cresce, e la velocità di acquisizione dei dati necessari per tutti i clienti supera la capacità del cluster. Quando ciò si verifica, dovrai suddividere i clienti in più cluster. Progetta questa configurazione in anticipo invece di provare ad adattarla successivamente. Anche se la tua scala iniziale prevede l'utilizzo di un solo cluster, simula i componenti necessari per indirizzare i tenant su più cluster in futuro, quando raggiungerai tale scala.
Se la tua soluzione richiede più risorse in base alle dimensioni del locatario, preparati anche alla sua crescita. Se diversi clienti di un singolo cluster crescono in modo significativo, quel cluster potrebbe non supportare più i tuoi requisiti. Progetta una strategia per spostare i tenant in un altro cluster o dividere in due un cluster esistente utilizzando la funzionalità di clonazione Amazon Neptune DB.
Acquisisci familiarità con il protocollo Copy-on-Write Neptune, che può farti risparmiare denaro quando implementi la clonazione del DB. Se dividi un cluster a causa di colli di bottiglia di ingestione, potrebbe essere più efficiente non eliminare i dati dai cluster, a condizione che le tue politiche lo consentano. I due cluster condivideranno una pagina di dati se questa rimane invariata, ma non se la pagina di dati è stata modificata (perché alcuni dati in essa contenuti sono stati eliminati).
Nota
Questa guida si applica alla versione di Neptune più recente al momento della stesura di questo documento, che è la versione 1.3.1 di Neptune. Questa guida potrebbe cambiare nelle versioni future con l'evoluzione del livello di archiviazione di Neptune.
Limitazioni per gli scenari multi-tenancy
Tieni presente che alcune funzionalità di Neptune non sono progettate per scenari multi-tenancy. I tenant non dovrebbero avere accesso diretto agli endpoint Neptune in un modello di pool perché queste strategie multi-tenancy non vengono applicate a livello di database. Mantenete sempre una sorta di proxy tra i vostri clienti e l'endpoint Neptune che applichi i design descritti in questo documento. Alcuni esempi di tale proxy sono i seguenti:
-
Aggiungere i filtri di etichetta nel livello client
-
Disporre di un'API che associa il token di autenticazione a un ID tenant e inserisce questo filtro nella query
Queste linee guida si applicano anche per offrire ai clienti l'accesso diretto a funzionalità come i notebook Neptune Graph, Neptune Graph-Explorer o Neptune Streams.