Dans l'article d'aujourd'hui, parlons de l'architecture HBase. Penchons-nous sur les bases de HBase avant d'approfondir l'architecture HBase.
HBase - Les bases:
HBase est un magasin open-source, NoSQL, distribué, non relationnel, versionné, multidimensionnel, orienté colonnes qui a été modélisé sur Google BigTable qui s'exécute au-dessus de HDFS. «NoSQL» est un terme large signifiant que la base de données n'est pas un SGBDR qui prend en charge SQL comme principal langage d'accès. Mais il existe de nombreux types de bases de données NoSQL et Berkeley DB est un bon exemple de base de données NoSQL locale, alors que HBase est une base de données largement distribuée.
HBase fournit toutes les fonctionnalités de Google BigTable. Cela a commencé comme un projet de Powerset visant à traiter d'énormes quantités de données pour la recherche en langage naturel. Il a été développé dans le cadre du projet Hadoop d'Apache et fonctionne sur HDFS (Hadoop Distributed File System). Il fournit des moyens tolérants aux pannes de stocker de grandes quantités de données rares. HBase est vraiment plus un «magasin de données» qu'une «base de données» car il manque de nombreuses fonctionnalités disponibles dans le SGBDR, telles que les colonnes typées, les index secondaires, les déclencheurs et les langages de requête avancés, etc.
Dans les bases de données orientées colonnes, la table de données est stockée sous forme de sections de colonnes de données plutôt que de lignes de données. Le modèle de données de la base de données orientée colonnes comprend le nom de la table, la clé de ligne, la famille de colonnes, les colonnes et l'horodatage. Lors de la création de tables dans HBase, les lignes seront identifiées de manière unique à l'aide des clés de ligne et de l'horodatage. Dans ce modèle de données, la famille de colonnes est statique tandis que les colonnes sont dynamiques. Examinons maintenant l'architecture HBase.
Quand opter pour HBase?
HBase n'est une bonne option que lorsqu'il y a des centaines de millions ou des milliards de lignes. HBase peut également être utilisé à certains endroits lorsque l'on envisage de passer d'un SGBDR à HBase comme une refonte complète par opposition à un port.En d'autres termes, HBase n'est pas optimisé pour les applications transactionnelles classiques ou même l'analyse relationnelle. Ce n'est pas non plus un substitut complet pour HDFS lors de la création de gros lots MapReduce. Alors pourquoi devriez-vous opter pour HBase ?? Si votre application a un schéma variable où chaque ligne est légèrement différente, vous devriez regarder HBase.
Architecture HBase:
La figure suivante explique clairement l'architecture HBase.
quelles sont les instances en java
Dans HBase, il existe trois composants principaux: Maître, serveur de région et gardien de zoo . Les autres composants sont Memstore, HFile et WAL.
Comme HBase fonctionne au-dessus de HDFS, il utilise l'architecture maître-esclave dans laquelle le HMaster sera le nœud maître et les serveurs de région sont les nœuds esclaves. Lorsque le client envoie une demande d'écriture, HMaster obtient cette demande et la transmet au serveur de région concerné.
Serveur de région:
C'est un système qui agit comme un nœud de données. Lorsque le serveur de région (RS) reçoit une demande d'écriture, il dirige la demande vers une région spécifique. Chaque région stocke un ensemble de lignes. Les données de lignes peuvent être séparées en plusieurs familles de colonnes (CF). Les données d'un CF particulier sont stockées dans HStore qui se compose de Memstore et d'un ensemble de HFiles.
Que fait Memstore?
Memstore garde une trace de tous les journaux pour les opérations de lecture et d'écriture qui ont été effectuées dans ce serveur de région particulier. À partir de là, nous pouvons dire qu'il agit de la même manière qu'un nœud de nom dans Hadoop. Memstore est un stockage en mémoire, par conséquent le Memstore utilise le stockage en mémoire de chaque nœud de données pour stocker les journaux. Lorsque certains seuils sont atteints, les données Memstore sont vidées dans HFile.
L'objectif principal de l'utilisation de Memstore est la nécessité de stocker des données sur DFS triées par clé de ligne. Comme HDFS est conçu pour les lectures / écritures séquentielles, sans aucune modification de fichier autorisée, HBase ne peut pas écrire efficacement les données sur le disque au fur et à mesure de leur réception: les données écrites ne seront pas triées (lorsque l'entrée n'est pas triée), ce qui signifie qu'elles ne seront pas optimisées pour l'avenir récupération. Pour résoudre ce problème, les tampons HBase ont reçu les dernières données en mémoire (dans Memstore), les «trient» avant le vidage, puis les écrivent dans HDFS à l'aide d'écritures séquentielles rapides. Par conséquent, HFile contient une liste de lignes triées.
Chaque fois que le flush Memstore se produit, un HFile créé pour chaque CF et des flushs fréquents peuvent créer des tonnes de HFiles. Étant donné que pendant la lecture, HBase devra examiner de nombreux fichiers HFiles, la vitesse de lecture peut en souffrir. Pour éviter d'ouvrir trop de fichiers HFiles et éviter une détérioration des performances de lecture, le processus de compactage HFiles est utilisé. HBase compactera périodiquement (lorsque certains seuils configurables sont atteints) plusieurs fichiers HFiles plus petits en un grand. De toute évidence, plus il y a de fichiers créés par les vidages Memstore, plus le système a du travail (charge supplémentaire). De plus, alors que le processus de compactage est généralement effectué en parallèle avec le traitement d'autres requêtes et lorsque HBase ne peut pas suivre le compactage des fichiers HFiles (oui, il existe également des seuils configurés pour cela), il bloquera à nouveau les écritures sur RS. Comme nous l'avons vu ci-dessus, cela est hautement indésirable.
Nous ne pouvons pas être sûrs que les données seront persistantes dans Memstore. Supposons qu'un datanode particulier est en panne. Ensuite, les données qui résident dans la mémoire de ce nœud de données seront perdues.
Pour surmonter ce problème, lorsque la demande provient du maître, elle a également été écrite dans WAL. WAL n'est rien d'autre que Écrire des journaux d'avance qui réside sur le HDFS, un stockage permanent. Maintenant, nous pouvons nous assurer que même si le nœud de données est en panne, les données ne seront pas perdues, c'est-à-dire. nous avons la copie de toutes les actions que vous êtes censé faire dans le WAL. Lorsque le nœud de données est actif, il exécute à nouveau toutes les activités. Une fois l'opération terminée, tout est vidé de Memstore et WAL et est écrit dans HFile afin de s'assurer que nous ne manquons pas de mémoire.
Prenons un exemple simple que je veux ajouter à la ligne 10, puis que la demande d'écriture entre, elle dit qu'elle donne toutes les métadonnées au Memstore et au WAL. Une fois que cette ligne particulière est écrite dans HFile, tout dans Memstore et WAL est vidé.
Gardien du zoo:
HBase est intégré à Zoo keeper. Lorsque je démarre HBase, l'instance Zoo keeper est également démarrée. La raison en est que le gardien du zoo nous aide à garder une trace de tous les serveurs de région qui sont là pour HBase. Zoo keeper garde une trace du nombre de serveurs de région présents, des serveurs de région à partir de quel nœud de données vers quel nœud de données. Il garde la trace des plus petits ensembles de données où Hadoop est absent. Cela réduit les frais généraux en plus de Hadoop qui garde la trace de la plupart de vos métadonnées. Par conséquent, HMaster obtient les détails des serveurs de la région en contactant le gardien du zoo.
Vous avez une question pour nous? Mentionnez-les dans la section commentaires et nous vous recontacterons.
Articles Similaires: