Forum aux questions sur le cache intégré d’Azure Cosmos DB

  • Article

S’APPLIQUE À : NoSQL

Le cache intégré Azure Cosmos DB est un cache en mémoire intégré à Azure Cosmos DB. Cet article répond aux questions fréquemment posées sur le cache intégré Azure Cosmos DB.

Forum aux questions

Pourquoi le cache intégré a-t-il besoin d’une passerelle dédiée ?

Si vous êtes connecté à Azure Cosmos DB à l’aide du mode passerelle, vous avez utilisé la passerelle standard. Tandis que le principal Azure Cosmos DB (le débit et le stockage configurés) ont une capacité dédiée par conteneur, la passerelle standard est partagée entre plusieurs clients. Il est pratique pour de nombreux clients de partager une passerelle standard, car les ressources de calcul consommées par chaque client individuel sont minimes. Étant donné que le cache intégré est spécifique à votre compte Azure Cosmos DB et qu’il nécessite beaucoup de ressources processeur et de mémoire, il nécessite des nœuds de passerelle dédiés.

Qu’est-ce qu’une passerelle dédiée ?

Une passerelle dédiée est un calcul côté serveur qui est un serveur frontal pour les données d’un compte Azure Cosmos DB. Lorsque vous vous connectez à votre point de terminaison de passerelle dédié avec le mode passerelle, votre application envoie une demande à la passerelle dédiée, qui achemine ensuite la demande vers différentes partitions du principal. L’utilisation du mode direct avec la passerelle dédiée est prise en charge, mais ces demandes n’utilisent pas le cache intégré.

L’utilisation de la passerelle dédiée offre-t-elle d’autres avantages en matière de performances par rapport à l’utilisation de la passerelle standard ?

En général, les demandes acheminées par la passerelle dédiée auront une latence légèrement inférieure et cohérente par rapport aux demandes acheminées par la passerelle standard. Même les demandes qui n’utilisent pas le cache intégré auront toujours une latence légèrement inférieure à celle de la passerelle standard.

Quel type de latence dois-je attendre du cache intégré ?

Une requête traitée par le cache intégré est rapide, car les données mises en cache sont stockées en mémoire sur la passerelle dédiée, plutôt que sur le back-end.

Pour les lectures de points mis en cache, vous devez vous attendre à une latence médiane de 2 à 4 ms. Pour les requêtes mises en cache, la latence dépend de la requête. Le cache de requêtes fonctionne en mettant en cache la réponse du moteur de requête pour une requête particulière. Cette réponse est ensuite renvoyée côté client vers le SDK pour traitement. Pour les requêtes simples, un travail minimal dans le SDK est requis et des latences médianes de 2 à 4 ms sont typiques. Des requêtes plus complexes avec GROUP BY ou DISTINCT nécessitent davantage de traitement dans le SDK, et la latence peut être plus élevée, même avec le cache de requêtes.

Si vous vous connectiez précédemment à Azure Cosmos DB en mode direct et que vous passez à une connexion avec passerelle dédiée, vous pourriez observer une légère augmentation de la latence pour certaines requêtes. L’utilisation du mode passerelle requiert l’envoi d’une requête à la passerelle (dans ce cas, la passerelle dédiée), puis l’acheminement approprié vers le serveur principal. Le mode direct, comme son nom l’indique, permet au client de communiquer directement avec le principal, en évitant un saut supplémentaire. Il n’existe aucun contrat SLA de latence pour les demandes utilisant la passerelle dédiée.

Si votre application utilisait précédemment le mode direct, les avantages de la latence du cache intégré ne seront significatifs que dans les scénarios suivants :

  • Latence de lecture de points pour les éléments volumineux (> 16 Ko)
  • Requêtes à RU élevées ou complexes

Si votre application utilisait précédemment le mode passerelle avec la passerelle standard, le cache intégré offre des réductions de latence dans presque tous les scénarios.

Le contrat SLA de disponibilité d’Azure Cosmos DB s’étend-il à la passerelle dédiée et au cache intégré ?

Pour les scénarios nécessitant une haute disponibilité et pour être couverts par le contrat SLA de disponibilité Azure Cosmos DB, vous devez provisionner au moins 3 nœuds de passerelle dédiée. Par exemple, si un nœud de passerelle dédiée est nécessaire en production, vous devez provisionner deux nœuds de passerelle dédiée supplémentaires pour tenir compte des interruptions de service potentielles, des pannes et des mises à niveau. Si un seul nœud de passerelle dédiée est provisionné, vous perdez temporairement la disponibilité dans ces scénarios. De plus, assurez-vous que votre passerelle dédiée dispose de suffisamment de nœuds pour servir votre charge de travail.

Le cache intégré est actuellement disponible uniquement pour l’API pour NoSQL. Envisagez-vous également de le proposer pour d’autres API ?

Le développement du cache intégré au-delà de l’API pour NoSQL est planifié à long terme, mais n’entre pas dans le cadre initial du cache intégré.

Quelle est la cohérence prise en charge par le cache intégré ?

Le cache intégré prend en charge la session et la cohérence éventuelle. Vous pouvez également configurer le MaxIntegratedCacheStalenessfacultatif, qui place une limite supérieure sur les données mises en cache.

Étapes suivantes