Quelles sont les clés utilisées dans la blockchain levelDB (c'est-à-dire quelles sont les paires clé : valeur)  ?


OK je sais que je ne devrais pas vraiment répondre à ma propre question mais. en l’absence de réponse à cette question, j’ai un peu chassé.

Github a fourni la réponse dans un fichier trouvé dans le référentiel bitcoin-leveldb.

txt

En bref, il n’y a pas de table facilement descriptible comme une structure. Il y en a plusieurs, dois-je les appeler des structures « imbriquées » dans la base de données, y compris le fait que la base de données stocke physiquement les données dans des fichiers logiques séparés.

Quelles sont les clés utilisées dans la blockchain levelDB (c'est-à-dire quelles sont les paires clé : valeur)  ?

txt à partir de cet article.

(taille fixe. Chacun de ces pointeurs est appelé BlockHandle et contient les informations suivantes  : offset  : varint64 taille  :://developers./protocol-buffers/docs/encoding#varints pour une explication du format varint64. (1) La séquence de paires clé/valeur dans le fichier est stockée dans un ordre trié et partitionnée en une séquence de blocs de données. Ces blocs se succèdent au début du fichier.cc, puis éventuellement compressé. (2) Après les blocs de données. Les types de blocs méta pris en charge sont décrits ci-dessous. D’autres types de méta-blocs pourraient être ajoutés à l’avenir.cc, puis éventuellement compressé. (3) Un bloc « métaindex ». Il contient une entrée pour chaque autre bloc méta où la clé est le nom du bloc méta et la valeur est un BlockHandle pointant vers ce bloc méta. (4) Un bloc « index ». Ce bloc contient une entrée par bloc de données, où la clé est une chaîne >= dernière clé dans ce bloc de données et avant la première clé dans le bloc de données successif. La valeur est le BlockHandle pour le bloc de données. (6) À la toute fin du fichier se trouve un pied de page de longueur fixe qui contient le BlockHandle des blocs de métaindex et d’index ainsi qu’un nombre magique. caractère; //: char; // Poignée de bloc pour le rembourrage d’index  : char; // octets mis à zéro pour obtenir une longueur fixe // (40==2*BlockHandle ::kMaxEncodedLength) magic  : fixed64 ; // == 0xdb4775248b80fb57 (petit boutiste)

Métabloc « filtrer »

Si un « FilterPolicy » a été spécifié lors de l’ouverture de la base de données, un bloc de filtre est stocké dans chaque table. Le bloc « metaindex » contient une entrée qui mappe de « filter. » au BlockHandle pour le bloc de filtre où «  » est la chaîne renvoyée par la méthode « Name() » de la politique de filtrage. Le bloc de filtre stocke une séquence de filtres, où le filtre i contient la sortie de FilterPolicy ::CreateFilter() sur toutes les clés stockées dans un bloc dont le décalage de fichier se situe dans la plage

Actuellement, « base » est de 2 Ko. Ainsi, par exemple, si les blocs X et Y commencent dans la plage , toutes les clés de X et Y seront converties en un filtre en appelant FilterPolicy ::CreateFilter(), et le filtre résultant sera stocké en tant que premier filtre dans le bloc de filtre. Le bloc de filtre est formaté comme suit  :

4 octets

4 octets

4 octets..

4 octets

4 octets lg(base) : 1 octet Le tableau de décalage à la fin du bloc de filtre permet un mappage efficace d’un décalage de bloc de données au filtre correspondant.

Méta-bloc « statistiques »

Ce méta-bloc contient un tas de statistiques. La clé est le nom de la statistique. La valeur contient la statistique. TODO(postrelease)  : enregistrer les statistiques suivantes. taille des données taille de l’index taille de la clé (non compressée) taille de la valeur (non compressée) nombre d’entrées nombre de blocs de données