Gestion des clés dans NoSQL - les nuls

Les capacités de lecture rapide des magasins de valeurs-clés résultent de l'utilisation de clés bien définies. Ces clés sont généralement hachées, ce qui donne à un magasin de valeurs-clés un moyen très prévisible de déterminer quelles données de partition (et donc de serveur) résident. Un serveur particulier gère une ou plusieurs partitions.

Une bonne clé vous permet d'identifier de manière unique l'enregistrement unique qui répond à une requête sans avoir à regarder les valeurs de cet enregistrement. Une mauvaise clé nécessitera que votre code d'application interprète votre enregistrement pour déterminer s'il correspond, en fait, à la requête.

Si vous ne concevez pas bien votre clé, vous risquez de vous retrouver avec un serveur ayant une charge disproportionnée par rapport aux autres, conduisant à de mauvaises performances. L'utilisation de l'heure système actuelle en tant que clé, par exemple, pousse toutes les nouvelles données sur le dernier nœud du cluster, ce qui conduit à un scénario de rééquilibrage cauchemardesque.

Partitionnement

La conception de partition est importante car certaines banques de valeurs-clés, telles qu'Oracle NoSQL, n'autorisent pas la modification du nombre de partitions une fois qu'un cluster est créé. Leur distribution à travers les serveurs, cependant, peut être modifiée. Commencez donc avec un grand nombre de partitions que vous pourrez étaler dans le futur.

Un exemple de partitionnement est l'approche cohérente de hachage de Voldemort, comme illustré. Ici, vous voyez les mêmes partitions réparties sur trois serveurs, puis sur quatre serveurs plus tard. Le nombre de partitions reste le même, mais leur allocation est différente entre les serveurs. La même chose est vraie de leurs répliques.

Accès aux données sur les partitions

Les magasins de valeurs-clés sont fortement distribués sans point de défaillance unique. Cela signifie qu'il n'y a pas besoin d'un nœud de coordination maître pour garder une trace des serveurs dans un cluster. La gestion de cluster est effectuée automatiquement par un protocole de conversation entre les nœuds du serveur.

Vous pouvez utiliser une astuce dans le pilote client pour extraire les performances maximales de la récupération et du stockage des clés et des valeurs. Le pilote client surveille les serveurs qui détiennent une gamme de clés. Ainsi, le pilote client sait toujours à quel serveur s'adresser.

La plupart des bases de données, y compris NoSQL, transmettent une requête à tous les membres d'un cluster. Ce cluster accepte l'écriture en interne ou la transmet sous le capot au noeud correct. Cette configuration signifie qu'un voyage réseau supplémentaire entre les nœuds est possible, ce qui peut ajouter à la latence.

Pour éviter la latence de découverte, la plupart des pilotes clients des magasins de valeurs-clés gèrent une liste de métadonnées des nœuds actuels d'un cluster et les plages de clés de partition gérées par chaque nœud.De cette manière, le pilote client peut contacter le serveur correct, ce qui accélère les opérations.

Si un nouveau nœud est ajouté à un cluster et que les métadonnées sont obsolètes, le cluster informe le pilote client, qui télécharge alors les dernières métadonnées de cluster avant de renvoyer la requête au nœud correct. De cette façon, le débit maximal est maintenu avec un minimum de frais généraux pendant le développement. Un autre avantage est qu'il n'est pas nécessaire qu'un équilibreur de charge transmette les requêtes au serveur disponible le moins occupé, seul un serveur (ou un serveur de réplication en lecture) reçoit une requête client, ce qui évite d'avoir à équilibrer la charge..