Meilleures pratiques en matière de cluster élastique Amazon DocumentDB

Utilisez une clé de hachage uniformément distribuée pour répartir vos données sur tous les fragments de votre cluster (évitez les touches de raccourci).

Utilisez votre clé de partition dans toutes les requêtes read/update /delete pour éviter les requêtes de collecte par dispersion.

Évitez les clés de partition imbriquées lorsque vous effectuez des opérations read/update /delete.

Lorsque vous effectuez des opérations par lots, définissez ordered sur false pour que toutes les partitions puissent s'exécuter en parallèle et améliorer les latences.

Surveillez le nombre de connexions et la fréquence à laquelle de nouvelles connexions sont ouvertes et fermées.

Répartissez vos connexions sur tous les sous-réseaux de la configuration de votre application. Si votre cluster est configuré dans plusieurs sous-réseaux mais que vous n'utilisez qu'un sous-ensemble de ces sous-réseaux, il se peut que votre nombre maximum de connexions soit limité.

Lorsque vous travaillez avec des collections non partitionnées, pour répartir la charge, essayez de conserver les collections non partitionnées les plus utilisées dans différentes bases de données. Les clusters élastiques Amazon DocumentDB placent les bases de données sur différentes partitions et co-localisent les collections non partitionnées de la même base de données sur la même partition.

Les opérations de dimensionnement peuvent provoquer une brève période d'erreurs intermittentes de base de données et de réseau. Dans la mesure du possible, évitez de monter à l'échelle pendant les heures de pointe. Essayez de procéder à une mise à l'échelle pendant les périodes de maintenance.

Il est préférable d'augmenter ou de diminuer la capacité des partitions (en modifiant le nombre de processeurs virtuels par partition) pour augmenter le calcul plutôt que d'augmenter ou de diminuer le nombre de partitions, car cela est plus rapide et réduit la durée des erreurs intermittentes de base de données et de réseau.

Lorsque vous anticipez une croissance, privilégiez l'augmentation du nombre de fragments plutôt que la capacité des fragments. Cela vous permet de faire évoluer votre cluster en augmentant la capacité des partitions pour les scénarios dans lesquels vous devez évoluer rapidement.

Surveillez vos politiques en matière de nouvelles tentatives côté client et réessayez avec un temps d'attente et une instabilité exponentiels pour éviter de surcharger votre base de données en cas d'erreur lors de la mise à l'échelle.

La modification du nombre de partitions peut prendre du temps car les données doivent être déplacées en toute sécurité d'une partition à l'autre. Pour minimiser les risques d'erreurs, n'arrêtez pas et n'apportez aucune autre modification à l'état du cluster pendant que la modification est en cours.

Suivez le ratio maximal/moyenne de vos indicateurs par fragment pour déterminer si vous conduisez un trafic irrégulier (ayez un point chaud). key/hot Les indicateurs clés permettant de suivre les ratios maximal/moyenne sont les suivants :