Meilleures pratiques pour l'optimisation des performances de lecture dans les Replica Sets

Les Replica Sets MongoDB sont fondamentaux pour garantir la haute disponibilité et la redondance des données dans les environnements de production. Bien que le basculement et la durabilité soient des avantages clés, des Replica Sets mal configurés peuvent introduire une latence de lecture significative, ralentissant les applications qui dépendent d'une récupération rapide des données. L'optimisation des performances de lecture implique un réglage minutieux de la manière dont les données sont répliquées, de la manière dont les lectures sont distribuées entre les membres et des garanties de cohérence dont votre application a réellement besoin.

Ce guide explore les paramètres de configuration cruciaux, y compris les préoccupations de lecture (read concerns), les préoccupations d'écriture (write concerns) et les mécanismes de synchronisation, qui ont un impact direct sur la vitesse des requêtes dans un Replica Set MongoDB. En mettant en œuvre ces meilleures pratiques, vous pouvez maximiser le débit des requêtes et minimiser la latence sur votre cluster distribué.

Comprendre le chemin de lecture dans les Replica Sets

Dans un déploiement de Replica Set standard, un membre est désigné comme primaire, gérant toutes les écritures. Les membres restants sont des secondaires, qui répliquent de manière asynchrone les données du primaire. Les lectures d'application peuvent être dirigées vers le primaire ou distribuées sur les secondaires, en fonction de la configuration.

Optimiser les lectures signifie équilibrer le besoin de cohérence immédiate des données (qui nécessite souvent de lire à partir du primaire) par rapport au désir de décharger le trafic du primaire (en lisant à partir des secondaires).

1. Utilisation stratégique des Read Concerns

Le Read Concern définit le degré de cohérence des données requis pour les opérations de lecture. Définir un read concern trop strict lorsqu'un read concern plus souple suffit est une cause fréquente de latence de lecture, car il peut forcer l'opération à attendre des confirmations de plusieurs nœuds.

Read Concerns disponibles

MongoDB propose plusieurs read concerns, chacun échangeant latence contre durabilité/cohérence :

Read Concern	Description	Cas d'utilisation
`strong`	Retourne les données garanties d'être durables sur la majorité des nœuds de vote. Cohérence la plus élevée.	Transactions critiques où la perte de données ne peut être tolérée.
`majority`	Retourne les données reconnues comme validées par une majorité de nœuds de vote. Défaut standard.	Lectures générales nécessitant une haute durabilité.
`local`	Retourne les données les plus récentes disponibles sur le membre lu, quelle que soit la confirmation d'écriture.	Lectures qui peuvent tolérer des données légèrement obsolètes (par exemple, compteurs de tableau de bord).
`linearizable`	Garantit que l'opération de lecture reflète le résultat de toutes les opérations d'écriture précédentes qui se sont terminées avec succès avant que la lecture ne soit initiée. (Nécessite un write concern majoritaire).
Latence très élevée due à la coordination.	Lectures qui doivent voir le dernier résultat d'écriture immédiatement.

Astuce d'optimisation : Utiliser `local` ou `majority` par défaut

Pour les lectures non critiques (comme le chargement de données de configuration mises à jour infrequently ou de résultats mis en cache), utilisez le read concern local sur les secondaires. Cela évite tout délai de synchronisation.

Exemple : Définir le Read Concern au niveau de la session

// Définit le read concern sur 'local' pour cette session spécifique
const session = mongoClient.startSession({ readConcern: { level: "local" } });

// Opération find utilisant la session
db.collection('mydata').find().session(session).toArray();

Avertissement : Lire avec le read concern local sur un secondaire peut entraîner la lecture de données qui n'ont pas encore été répliquées, ce qui conduit à des résultats obsolètes.

2. Distribution des lectures sur les secondaires

Par défaut, MongoDB dirige les lectures vers le primaire. Pour augmenter la capacité de lecture, vous devez explicitement diriger les lectures vers les secondaires en utilisant les paramètres de Read Preference.

Comprendre la Read Preference

La Read Preference dicte quels membres du Replica Set sont éligibles pour satisfaire les requêtes de lecture et dans quel ordre ils doivent être choisis.

Les Read Preferences courantes incluent :

primary: (Défaut) Seul le primaire est éligible.
primaryPreferred: Tente d'abord le primaire ; se rabat sur un secondaire si le primaire n'est pas disponible.
secondary: Seuls les secondaires sont éligibles. Si aucun secondaire n'est disponible, l'opération échoue.
secondaryPreferred: Préfère les secondaires ; se rabat sur le primaire si aucun secondaire n'est disponible.
nearest: Choisit le membre (primaire ou secondaire) avec la latence réseau la plus faible par rapport au client.

Astuce d'optimisation : Utiliser `secondaryPreferred` ou `nearest`

Pour la plupart des applications à forte charge de lecture, l'utilisation de secondaryPreferred vous permet de distribuer la charge des requêtes sur tous les secondaires disponibles, réduisant considérablement la charge sur le primaire.

Si vous avez des serveurs d'application géographiquement distribués, nearest est souvent le meilleur choix, car il minimise la latence réseau pour le client, même s'il accède occasionnellement au primaire.

Exemple : Connexion avec secondaryPreferred

Lorsque vous connectez votre pilote d'application, spécifiez la read preference :

const uri = "mongodb://host1,host2,host3/?replicaSet=rs0&readPreference=secondaryPreferred";
// Ou en utilisant les options de connexion dans la configuration du pilote
const options = {
  readPreference: "secondaryPreferred"
};

3. Gestion de la synchronisation et du décalage des secondaires

Si vous redirigez les lectures vers les secondaires, les performances de ces lectures dépendent entièrement de la rapidité avec laquelle les secondaires rattrapent le primaire. Un délai de réplication élevé signifie que les secondaires servent des données obsolètes, ou si le délai est trop important, les lectures peuvent échouer ou expirer.

Surveillance du délai de réplication

Surveillez toujours la différence optimeDate entre le primaire et les secondaires. Des outils comme rs.printReplicationInfo() ou des systèmes de surveillance (par exemple, MongoDB Cloud Manager/Ops Manager) sont essentiels.

// À exécuter sur un membre secondaire
rs.printReplicationInfo()

// Vérifier le délai indiqué
// Rechercher le champ 'secsBehindPrimary'.

Impact du Write Concern sur les performances des secondaires

Bien que cet article se concentre sur les lectures, des paramètres de write concern élevés peuvent avoir un impact indirect sur les performances de lecture en ralentissant le primaire, ce qui à son tour fait que les secondaires prennent du retard.

Par exemple, exiger une confirmation d'écriture w: 'majority' signifie que le primaire doit attendre que la majorité des nœuds reconnaissent l'écriture avant de pouvoir continuer. Si les accusés de réception sont lents (en raison d'une saturation du réseau ou de secondaires surchargés), l'ensemble du pipeline de réplication ralentit.

Meilleure pratique pour le Write Concern (Optimisation indirecte des lectures) : Assurez-vous que votre write concern est correctement défini. Si vous avez de nombreux secondaires, l'utilisation d'une valeur w: plus faible (par exemple, w: 2 au lieu de w: majority) peut accélérer la capacité du primaire à appliquer les écritures, aidant ainsi les secondaires à rester à jour.

4. Indexation et optimisation des requêtes

Aucun paramètre de configuration ne peut compenser une requête mal écrite. Le principe fondamental des lectures rapides reste un index solide.

Considérations clés sur l'indexation

Requêtes couvertes (Covered Queries) : Concevez des requêtes qui peuvent être entièrement satisfaites par un index sans avoir à récupérer de documents sur le disque. Ce sont les lectures les plus rapides possibles.
Alignement des index : Assurez-vous que les index correspondent aux champs utilisés dans vos clauses find(), sort() et projection().
Éviter les scans de collection (Collection Scans) : Vérifiez toujours dans le profiler de requêtes que les opérations de lecture utilisent des index (IXSCAN) au lieu d'effectuer des scans complets de collection (COLLSCAN).

Réglage des délais d'attente des requêtes (Query Timeouts)

Si une application accède à un secondaire très en retard, la requête peut expirer. Configurez des délais d'attente raisonnables dans votre application pour gérer gracieusement un décalage temporaire, en vous rabattant éventuellement sur le primaire ou en réessayant plus tard, au lieu de rester bloqué indéfiniment.

Résumé des étapes d'optimisation des lectures

Pour obtenir des performances de lecture optimales dans votre Replica Set MongoDB, suivez ces étapes concrètes :

Identifier les types de lectures : Classez les lectures en deux groupes : celles qui nécessitent une forte cohérence (utilisez Primary/Strong Read Concern) et celles qui tolèrent une cohérence éventuelle (utilisez Secondaries/Local Read Concern).
Configurer la Read Preference : Définissez la chaîne de connexion ou les options de session pour utiliser secondaryPreferred ou nearest pour la majorité du trafic applicatif.
Surveiller le décalage : Surveillez en permanence le décalage de réplication (secsBehindPrimary). Si le décalage est constamment élevé, enquêtez sur les problèmes matériels ou réseau des secondaires.
Examiner les Write Concerns : Assurez-vous que les write concerns ne ralentissent pas indûment le primaire, ce qui prive les secondaires de données fraîches.
Indexer minutieusement : Vérifiez que tous les chemins de lecture fréquemment exécutés sont couverts par des index efficaces.