Vidéo: MongoDB Atlas: Deploy a free database cluster in minutes. 2024
Les bases de données NoSQL sont bien adaptées aux très grands ensembles de données. Les clones Bigtable comme HBase ne font pas exception. Vous voudrez probablement utiliser plusieurs serveurs de produits de base peu coûteux dans un seul cluster plutôt qu'une machine très puissante. C'est parce que vous pouvez obtenir une meilleure performance globale par dollar en utilisant de nombreux serveurs de base, plutôt que d'un serveur unique, puissant et beaucoup plus coûteux.
En plus de pouvoir évoluer rapidement, les serveurs peu coûteux peuvent également améliorer la résilience de votre service de base de données et ainsi éviter les pannes matérielles. C'est parce que vous avez d'autres serveurs pour prendre en charge le service si la carte mère d'un seul serveur tombe en panne. Ce n'est pas le cas avec un seul grand serveur.
La figure montre une configuration HBase hautement disponible avec un exemple de répartition des données entre serveurs.
Le diagramme montre deux nœuds (HRegionServers) dans une configuration hautement disponible, chacun agissant comme une sauvegarde pour l'autre.
Dans de nombreuses configurations de production, il se peut que vous ayez besoin d'au moins trois nœuds pour une haute disponibilité afin de pouvoir gérer deux défaillances de serveur proches les unes des autres. Ce n'est pas aussi rare que vous le pensez! Les conseils varient selon Bigtable; par exemple, HBase recommande au minimum cinq nœuds pour un cluster:
-
Chaque serveur de région gère son propre jeu de clés.
La conception d'une stratégie d'allocation de clé de ligne est importante car elle dicte la manière dont la charge est répartie dans le cluster.
-
| Chaque région gère son propre journal d'écriture et son propre magasin en mémoire.
Dans HBase, toutes les données sont écrites dans un magasin en mémoire, et plus tard, ce magasin est vidé sur le disque. Sur le disque, ces magasins sont appelés fichiers de stockage .
HBase interprète les fichiers de stockage comme des fichiers uniques, mais en réalité, ils sont répartis par morceaux sur un système de fichiers distribués Hadoop (HDFS). Cela permet une grande vitesse d'acquisition et de récupération car toutes les opérations d'E / S étendues sont réparties sur de nombreuses machines.
Pour optimiser la disponibilité des données, Hadoop conserve par défaut trois copies de chaque fichier de données. Les grandes installations ont
-
Une copie primaire
-
Une réplique dans le même rack
-
Une autre réplique dans un autre rack
Avant Hadoop 2. 0, les Namenodes ne pouvaient pas être rendus hautement disponibles. Ceux-ci maintenaient une liste de tous les serveurs actifs dans le cluster. Ils étaient donc un seul point d'échec. Depuis Hadoop 2. 0, cette limite n'existe plus.
