Préparez-vous à la croissance

Lorsque vous utilisez le modèle de pool avec succès, vous finissez par dépasser la taille d'un seul cluster Neptune. Le nombre de locataires augmente, ou le nombre de locataires augmente, et le taux d'ingestion des données nécessaires pour l'ensemble de vos clients dépasse les capacités du cluster. Dans ce cas, vous devrez répartir vos clients sur plusieurs clusters. Concevez cette configuration dès le départ au lieu d'essayer de la modifier ultérieurement. Même si votre échelle initiale consiste à n'utiliser qu'un seul cluster, modélisez les composants dont vous aurez besoin pour acheminer les locataires entre plusieurs clusters à l'avenir lorsque vous atteindrez cette échelle.

Si votre solution nécessite davantage de ressources en fonction de la taille de votre locataire, préparez-vous également à sa croissance. Si plusieurs clients d'un même cluster augmentent de manière significative, ce cluster risque de ne plus répondre à vos besoins. Concevez une stratégie pour déplacer les locataires vers un autre cluster ou diviser un cluster existant en deux à l'aide de la fonctionnalité de clonage de base de données Amazon Neptune.

Familiarisez-vous avec le Copy-on-Write protocole Neptune, qui peut vous faire économiser de l'argent lorsque vous implémentez le clonage de bases de données. Si vous divisez un cluster en raison de problèmes d'ingestion, il peut être plus efficace de ne pas supprimer de données des clusters, à condition que vos politiques le permettent. Les deux clusters partageront une page de données si elle est inchangée, mais pas si la page de données a été modifiée (car certaines données ont été supprimées).

Note

Ces directives s'appliquent à la version la plus récente de Neptune au moment de la rédaction de cet article, à savoir la version 1.3.1 de Neptune. Ces instructions sont susceptibles de changer dans les futures versions au fur et à mesure de l'évolution de la couche de stockage Neptune.

Limites des scénarios de location multiple

Sachez que certaines fonctionnalités de Neptune ne sont pas conçues pour les scénarios de location multiple. Les locataires ne doivent pas avoir un accès direct aux points de terminaison Neptune dans un modèle de pool, car ces stratégies de mutualisation ne sont pas appliquées au niveau de la base de données. Conservez toujours une sorte de proxy entre vos clients et le terminal Neptune qui applique les conceptions décrites dans ce document. Voici quelques exemples d'un tel proxy :

• Ajouter les filtres d'étiquettes dans votre couche client

• Disposer d'une API qui associe le jeton d'authentification à un identifiant de locataire et injecte ce filtre dans la requête

Ces conseils s'appliquent également à l'accès direct aux clients à des fonctionnalités telles que les carnets graphiques Neptune, l'explorateur de graphes Neptune ou Neptune Streams.