Dans HBase - les nuls

Les serveurs RegionServers sont une chose, mais vous devez également examiner le fonctionnement de chaque région. Dans HBase, une table est à la fois répartie sur un certain nombre de RegionServers et composée de régions individuelles. Lorsque les tables sont divisées, les divisions deviennent des régions. Les régions stockent une plage de paires clé-valeur et chaque RegionServer gère un nombre configurable de régions.

Mais à quoi ressemblent les différentes régions? HBase est un magasin de données axé sur les familles de colonnes. Comment les régions individuelles stockent-elles les paires valeur / clé en fonction des familles de colonnes auxquelles elles appartiennent? La figure suivante commence à répondre à ces questions et vous aide à digérer plus d'informations vitales sur l'architecture de HBase.

HBase est écrit en Java - comme la grande majorité des technologies Hadoop. Java est un langage de programmation orienté objet et une technologie élégante pour l'informatique distribuée. Donc, alors que vous continuez à en savoir plus sur HBase, souvenez-vous que tous les composants de l'architecture sont en fin de compte des objets Java.

Tout d'abord, la figure précédente donne une bonne idée de ce à quoi ressemblent les objets de la région, en général. Il indique également que les régions séparent les données dans les familles de colonnes et stockent les données dans HDFS à l'aide d'objets HFile.

Lorsque les clients mettent des paires valeur / clé dans le système, les clés sont traitées de sorte que les données soient stockées en fonction de la famille de colonnes à laquelle appartient la paire. Comme le montre la figure, chaque objet de stockage de la famille de colonnes possède un cache de lecture appelé BlockCache et un cache d'écriture appelé MemStore. Le BlockCache aide avec les performances de lecture aléatoire.

Les données sont lues dans des blocs à partir de HDFS et stockées dans le BlockCache. Les lectures ultérieures des données - ou des données stockées à proximité - seront lues à partir de la RAM au lieu du disque, améliorant ainsi les performances globales. Le Write Ahead Log (WAL, en abrégé) garantit que vos écritures HBase sont fiables. Il y a un WAL par RegionServer.

Tenez toujours compte de la loi du fer de l'informatique distribuée: un échec n'est pas une exception: c'est la norme, en particulier lors du regroupement de centaines, voire de milliers de serveurs. Google a suivi la loi de fer dans la conception de BigTable et HBase a emboîté le pas.

Lorsque vous écrivez ou modifiez des données dans HBase, les données sont d'abord conservées dans le WAL, qui est stocké dans HDFS, puis les données sont écrites dans le cache MemStore. À des intervalles configurables, les paires clé-valeur stockées dans le MemStore sont écrites dans HFiles dans le HDFS et ensuite les entrées WAL sont effacées.

Si une erreur survient après , le WAL initial écrit mais avant le dernier MemStore écrit sur le disque, le WAL peut être relu pour éviter toute perte de données.

Trois objets HFile sont dans une famille de colonnes et deux dans l'autre. La conception de HBase consiste à vider les données de la famille de colonnes stockées dans le MemStore à un fichier HFile par vidage. Ensuite, à des intervalles configurables, les HFiles sont combinés en HFiles plus grands. Cette stratégie met en file d'attente l'opération de compactage critique dans HBase.