Régions en HBase

RegionServers sont une chose, mais il faut aussi jeter un oeil à la façon dont les différentes régions travaillent. Dans HBase, une table est à la fois la propagation à travers un certain nombre de RegionServers ainsi comme étant composé des différentes régions. Comme les tableaux sont divisés, les divisions deviennent régions. Régions stockent une gamme de paires clé-valeur, et chaque RegionServer gère un nombre configurable de régions.

Mais qu'est-ce que les régions individuelles ressemblent? HBase est un magasin de données orientée colonne-famille, alors comment les différentes régions stocker des paires clé-valeur sur la base des familles de poteaux auxquels ils appartiennent? La figure suivante commence à répondre à ces questions et vous aide à digérer des informations plus vitales sur l'architecture de HBase.

image0.jpg

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 le calcul distribué. Donc, comme vous continuez à en savoir plus sur HBase, rappelez-vous que tous les composants de l'architecture sont finalement des objets Java.




Tout d'abord, la figure précédente donne une assez bonne idée de ce que la région objets ressemblent vraiment, de façon générale. Il précise également que les régions de données distinctes en familles colonnes et stockent les données dans le HDFS utilisant des objets HFILE.

Lorsque les clients mettent paires clé-valeur dans le système, les clés sont traitées de sorte que les données sont stockées sur la base de la famille de la colonne paire appartient. Comme le montre la figure, chaque objet de banque de la famille de la colonne dispose d'un cache de lecture appelé le BlockCache et un cache d'écriture appelé le MemStore. Le BlockCache aide avec des performances de lecture aléatoire.

Les données sont lues dans les blocs de la HDFS et stocké dans le BlockCache. Les lectures ultérieures pour les données - ou des données stockées à proximité - sera lue à partir du disque RAM à la place, l'amélioration de la performance globale. The Write Ahead Log (WAL, pour faire court) garantit que vos écritures Hbase sont fiables. Il est l'un WAL par RegionServer.

image1.jpg

Respectez toujours la loi de fer de l'informatique distribuée: Un échec ne fait pas exception - il est la norme, surtout quand le regroupement des centaines voire des milliers de serveurs. Google a suivi la loi de fer dans la conception et BigTable HBase emboîté le pas.

Lorsque vous écrivez ou modifier des données dans HBase, les données sont d'abord persisté à l'WAL, qui est stocké dans le HDFS, puis les données sont écrites dans le cache MemStore. A intervalles configurables, paires clé-valeur stockées dans la MemStore sont écrites HFiles dans le HDFS et ensuite entrées WAL sont effacés.

Si une panne survient après l'écriture initiale WAL mais avant l'MemStore finale écriture sur le disque, l'WAL peut être rejoué pour éviter toute perte de données.

Trois objets HFILE sont dans une famille de la colonne et deux dans l'autre. La conception de HBase est de vider les données de la famille colonnes stockés dans le MemStore une HFILE par chasse. Puis, à intervalles configurables HFiles sont combinés en grandes HFiles. Cette stratégie met en attente l'opération de compactage critique dans HBase.