{"id":55302,"date":"2020-01-17T00:00:00","date_gmt":"2020-01-16T21:00:00","guid":{"rendered":"https:\/\/prohoster.info\/blog\/blog_prohoster\/teoriya-i-praktika-ispolzovaniya-hbase"},"modified":"2020-02-18T14:03:24","modified_gmt":"2020-02-18T11:03:24","slug":"teoriya-i-praktika-ispolzovaniya-hbase","status":"publish","type":"post","link":"https:\/\/prohoster.info\/fr\/blog\/administrirovanie\/teoriya-i-praktika-ispolzovaniya-hbase","title":{"rendered":"Th\u00e9orie et pratique de l'utilisation d'HBase","gt_translate_keys":[{"key":"rendered","format":"text"}]},"content":{"rendered":"

Bonjour ! Je m'appelle Danil Lipovoy, notre \u00e9quipe chez Sbertech a commenc\u00e9 \u00e0 utiliser HBase comme stockage de donn\u00e9es op\u00e9rationnelles. Au cours de son \u00e9tude, nous avons accumul\u00e9 de l'exp\u00e9rience que nous souhaitions syst\u00e9matiser et d\u00e9crire (nous esp\u00e9rons que cela sera utile \u00e0 beaucoup). Toutes les exp\u00e9riences ci-dessous ont \u00e9t\u00e9 r\u00e9alis\u00e9es avec les versions HBase 1.2.0-cdh5.14.2 et 2.0.0-cdh6.0.0-beta1. <\/p>\n

    \n
  1. Architecture g\u00e9n\u00e9rale <\/li>\n
  2. \u00c9criture de donn\u00e9es dans HBASE<\/li>\n
  3. Lecture de donn\u00e9es depuis HBASE<\/li>\n
  4. Mise en cache des donn\u00e9es<\/li>\n
  5. Traitement par lots des donn\u00e9es MultiGet \/ MultiPut<\/li>\n
  6. Strat\u00e9gie de partitionnement des tables en r\u00e9gions (sharding)<\/li>\n
  7. Tol\u00e9rance aux pannes, compactage et localit\u00e9 des donn\u00e9es<\/li>\n
  8. Configurations et performances<\/li>\n
  9. Test de charge<\/li>\n
  10. Conclusions<\/li>\n<\/ol>\n

    <\/a><\/noindex><\/p>\n

    1. Architecture g\u00e9n\u00e9rale<\/h2>\n

    \n\"Th\u00e9orie
    \nUn Master de secours \u00e9coute le heartbeat du ma\u00eetre actif sur le n\u0153ud ZooKeeper et, en cas de disparition, prend les fonctions du ma\u00eetre. <\/p>\n

    2. \u00c9criture de donn\u00e9es dans HBASE<\/h2>\n

    \nCommen\u00e7ons par le cas le plus simple : \u00e9crire un objet cl\u00e9-valeur dans une table \u00e0 l'aide de put(rowkey). Le client doit d'abord d\u00e9terminer o\u00f9 se trouve le serveur de r\u00e9gion racine (Root Region Server - RRS) qui stocke la table hbase:meta. Cette information est obtenue aupr\u00e8s de ZooKeeper. Ensuite, il s'adresse au RRS et lit la table hbase:meta, d'o\u00f9 il extrait l'information sur le RegionServer (RS) responsable du stockage des donn\u00e9es selon la cl\u00e9 rowkey donn\u00e9e dans la table qui l'int\u00e9resse. Pour une utilisation ult\u00e9rieure, la m\u00e9ta-table est mise en cache par le client et donc les acc\u00e8s suivants se font plus rapidement, directement aupr\u00e8s du RS.<\/p>\n

    Ensuite, le RS, ayant re\u00e7u la requ\u00eate, \u00e9crit d'abord celle-ci dans le WriteAheadLog (WAL), ce qui est n\u00e9cessaire pour la r\u00e9cup\u00e9ration en cas de panne. Il enregistre ensuite les donn\u00e9es dans le MemStore. C'est un tampon en m\u00e9moire qui contient un ensemble de cl\u00e9s tri\u00e9es de cette r\u00e9gion. La table peut \u00eatre divis\u00e9e en r\u00e9gions (partitions), chacune d'elles contenant un ensemble de cl\u00e9s disjointes. Cela permet, en pla\u00e7ant les r\u00e9gions sur diff\u00e9rents serveurs, d'obtenir des performances plus \u00e9lev\u00e9es. Cependant, malgr\u00e9 l'\u00e9vidence de cette affirmation, nous verrons par la suite que cela ne fonctionne pas dans tous les cas.<\/p>\n

    Apr\u00e8s avoir plac\u00e9 l'enregistrement dans le MemStore, le client re\u00e7oit une r\u00e9ponse indiquant que l'enregistrement a \u00e9t\u00e9 enregistr\u00e9 avec succ\u00e8s. En r\u00e9alit\u00e9, il est uniquement stock\u00e9 dans le tampon et ne sera \u00e9crit sur le disque qu'apr\u00e8s un certain intervalle de temps ou lorsque celui-ci sera rempli de nouvelles donn\u00e9es. <\/p>\n

    \"Th\u00e9orie
    \nLors de l'op\u00e9ration \u00abDelete\u00bb, il n'y a pas de suppression physique des donn\u00e9es. Elles sont simplement marqu\u00e9es comme supprim\u00e9es, et la destruction effective se produit lors de l'appel \u00e0 la fonction major compact, dont les d\u00e9tails sont donn\u00e9s au point 7.<\/p>\n

    Les fichiers au format HFile s'accumulent dans HDFS et de temps en temps, un processus de minor compact est lanc\u00e9, qui fusionne simplement les petits fichiers en de plus gros, sans rien supprimer. Au fil du temps, cela devient un probl\u00e8me qui se manifeste uniquement lors de la lecture des donn\u00e9es (nous y reviendrons un peu plus tard). <\/p>\n

    En plus du processus de chargement d\u00e9crit ci-dessus, il existe une proc\u00e9dure beaucoup plus efficace, qui constitue sans doute le principal atout de cette base de donn\u00e9es \u2013 BulkLoad. Elle consiste \u00e0 former nous-m\u00eames des HFiles et \u00e0 les d\u00e9poser sur le disque, ce qui permet un excellent passage \u00e0 l'\u00e9chelle et d'atteindre des vitesses tr\u00e8s satisfaisantes. En fait, la limite ici n'est pas HBase, mais les capacit\u00e9s mat\u00e9rielles. Ci-dessous, vous trouverez les r\u00e9sultats de chargement sur un cluster compos\u00e9 de 16 RegionServers et de 16 NodeManagers YARN (CPU Xeon E5-2680 v4 @ 2,40 GHz * 64 threads), version HBase 1.2.0-cdh5.14.2. <\/p>\n

    \"Th\u00e9orie
    \n
    \nIci, on constate qu'en augmentant le nombre de partitions (r\u00e9gions) dans la table, ainsi que le nombre d'ex\u00e9cuteurs Spark, on obtient une augmentation de la vitesse de chargement. La vitesse d\u00e9pend \u00e9galement du volume d'\u00e9criture. Les gros blocs donnent un gain en termes de Mo\/s, tandis que les petits blocs augmentent le nombre d'enregistrements ins\u00e9r\u00e9s par unit\u00e9 de temps, toutes choses \u00e9gales par ailleurs. <\/p>\n

    Il est \u00e9galement possible de lancer le chargement dans deux tables simultan\u00e9ment et de doubler la vitesse. Ci-dessous, on peut voir que l'\u00e9criture de blocs de 10 Ko dans deux tables se fait \u00e0 une vitesse d'environ 600 Mo\/s chacune (soit un total de 1275 Mo\/s), ce qui correspond \u00e0 la vitesse d'\u00e9criture dans une seule table de 623 Mo\/s (voir n\u00b011 ci-dessus).<\/p>\n

    \"Th\u00e9orie
    \nLors du second lancement avec des \u00e9critures de 50 Ko, on constate que la vitesse de chargement n'augmente plus de mani\u00e8re significative, ce qui indique que l'on approche des valeurs limites. Il convient \u00e9galement de noter qu'il n'y a pratiquement pas de charge sur HBASE ici, tout ce qui est requis de lui est d'abord de renvoyer les donn\u00e9es de hbase:meta, puis apr\u00e8s le d\u00e9p\u00f4t des HFiles, de vider les donn\u00e9es du BlockCache et de sauvegarder le buffer MemStore sur le disque, s'il n'est pas vide.<\/p>\n

    3. Lecture des donn\u00e9es depuis HBASE<\/h2>\n

    \nSi l'on consid\u00e8re que toutes les informations de hbase:meta sont d\u00e9j\u00e0 disponibles pour le client (voir point 2), la requ\u00eate est envoy\u00e9e imm\u00e9diatement au RS o\u00f9 la cl\u00e9 d\u00e9sir\u00e9e est stock\u00e9e. Tout d'abord, la recherche s'effectue dans MemCache. Que des donn\u00e9es y soient pr\u00e9sentes ou non, la recherche s'effectue \u00e9galement dans le tampon BlockCache et, si n\u00e9cessaire, dans HFiles. Si des donn\u00e9es sont trouv\u00e9es dans le fichier, elles sont plac\u00e9es dans BlockCache et seront retourn\u00e9es plus rapidement lors de la prochaine requ\u00eate. La recherche dans HFile se fait relativement rapidement gr\u00e2ce \u00e0 l'utilisation du filtre de Bloom, c'est-\u00e0-dire qu'en lisant un petit volume de donn\u00e9es, il d\u00e9termine imm\u00e9diatement si ce fichier contient la cl\u00e9 recherch\u00e9e, et si ce n'est pas le cas, il passe au suivant.<\/p>\n

    \"Th\u00e9orie
    \nApr\u00e8s avoir obtenu des donn\u00e9es de ces trois sources, le RS forme une r\u00e9ponse. En particulier, il peut transmettre plusieurs versions trouv\u00e9es d'un objet si le client a demand\u00e9 la gestion des versions.<\/p>\n

    4. Mise en cache des donn\u00e9es<\/h2>\n

    \nLes tampons MemStore et BlockCache occupent jusqu'\u00e0 80 % de la m\u00e9moire on-heap allou\u00e9e au RS (le reste \u00e9tant r\u00e9serv\u00e9 aux t\u00e2ches de service du RS). Si le mode d'utilisation typique est tel que les processus \u00e9crivent et lisent imm\u00e9diatement ces m\u00eames donn\u00e9es, il est judicieux de r\u00e9duire BlockCache et d'augmenter MemStore, puisque lors de l'\u00e9criture, les donn\u00e9es ne sont pas mises en cache pour la lecture, rendant l'utilisation de BlockCache moins fr\u00e9quente. Le tampon BlockCache se compose de deux parties : LruBlockCache (toujours on-heap) et BucketCache (g\u00e9n\u00e9ralement off-heap ou sur SSD). BucketCache doit \u00eatre utilis\u00e9 lorsque les requ\u00eates de lecture sont tr\u00e8s nombreuses et qu'elles ne tiennent pas dans LruBlockCache, ce qui conduit \u00e0 un travail actif du Garbage Collector. Cependant, il ne faut pas attendre une augmentation radicale des performances gr\u00e2ce \u00e0 l'utilisation du cache de lecture, mais cela sera discut\u00e9 plus en d\u00e9tail au point 8.<\/p>\n

    \"Th\u00e9orie
    \nBlockCache est unique pour tout le RS, tandis que MemStore est sp\u00e9cifique \u00e0 chaque table (un par Column Family).<\/p>\n

    Comment est d\u00e9crit<\/a><\/noindex> En th\u00e9orie, lors de l'\u00e9criture, les donn\u00e9es ne vont pas dans le cache et en effet, les param\u00e8tres CACHE_DATA_ON_WRITE pour la table et \u00ab Cache DATA on Write \u00bb pour le RS sont d\u00e9finis sur false. Cependant, en pratique, si l'on \u00e9crit des donn\u00e9es dans MemStore, puis que l'on les vide sur disque (effa\u00e7ant ainsi ce qu'il y a), puis que l'on supprime le fichier r\u00e9sultant, en effectuant la requ\u00eate get, nous obtenons avec succ\u00e8s les donn\u00e9es. M\u00eame si l'on d\u00e9sactive compl\u00e8tement BlockCache et que l'on remplit la table avec de nouvelles donn\u00e9es, ensuite pour provoquer la vidange de MemStore sur disque, les supprimer et les requ\u00e9rir d'une autre session, elles seront quand m\u00eame extraites de quelque part. Ainsi, HBase conserve non seulement des donn\u00e9es, mais aussi des myst\u00e8res myst\u00e9rieux.<\/p>\n

    hbase(main):001:0> create 'ns:magic', 'cf'\nTable ns:magic cr\u00e9\u00e9e\nTemps d'ex\u00e9cution 1.1533 secondes\nhbase(main):002:0> put 'ns:magic', 'key1', 'cf:c', 'try_to_delete_me'\nTemps d'ex\u00e9cution 0.2610 secondes\nhbase(main):003:0> flush 'ns:magic'\nTemps d'ex\u00e9cution 0.6161 secondes\nhdfs dfs -mv \/data\/hbase\/data\/ns\/magic\/* \/tmp\/trash\nhbase(main):002:0> get 'ns:magic', 'key1'\n cf:c      timestamp=1534440690218, value=try_to_delete_me\n<\/code><\/pre>\n
    \nLe param\u00e8tre \u00ab Cache DATA on Read \u00bb est d\u00e9fini sur false. Si vous avez des id\u00e9es, n'h\u00e9sitez pas \u00e0 en discuter dans les commentaires.<\/p>\n
    5. Traitement par lots de donn\u00e9es MultiGet\/MultiPut<\/h2>\n
    \nLe traitement des requ\u00eates individuelles (Get\/Put\/Delete) est une op\u00e9ration assez co\u00fbteuse, il est donc recommand\u00e9 de les regrouper autant que possible dans une liste, ce qui permet d'obtenir un gain de performance significatif. Cela est particuli\u00e8rement vrai pour les op\u00e9rations d'\u00e9criture, tandis qu'il existe un inconv\u00e9nient lors de la lecture. Le graphique ci-dessous montre le temps de lecture de 50 000 enregistrements depuis MemStore. La lecture a \u00e9t\u00e9 effectu\u00e9e en un seul thread et l'axe horizontal montre le nombre de cl\u00e9s dans la requ\u00eate. Nous pouvons voir qu'en augmentant jusqu'\u00e0 mille cl\u00e9s dans une requ\u00eate, le temps d'ex\u00e9cution diminue, c'est-\u00e0-dire que la vitesse augmente. Cependant, en mode MSLAB par d\u00e9faut, apr\u00e8s ce seuil, il y a une chute radicale des performances, et plus le volume de donn\u00e9es dans l'enregistrement est important, plus le temps d'ex\u00e9cution augmente. <\/p>\n
    \"Th\u00e9orie
    \n
    \nLes tests ont \u00e9t\u00e9 r\u00e9alis\u00e9s sur une machine virtuelle, 8 c\u0153urs, version HBase 2.0.0-cdh6.0.0-beta1.<\/p>\n
    Le mode MSLAB vise \u00e0 r\u00e9duire la fragmentation du tas, qui se produit \u00e0 cause du m\u00e9lange des donn\u00e9es de g\u00e9n\u00e9rations nouvelles et anciennes. Comme solution \u00e0 ce probl\u00e8me, lorsque MSLAB est activ\u00e9, les donn\u00e9es sont plac\u00e9es dans des cellules relativement petites (chunks) et trait\u00e9es par lots. En cons\u00e9quence, lorsque le volume du paquet de donn\u00e9es demand\u00e9 d\u00e9passe la taille allou\u00e9e, les performances chutent rapidement. D'autre part, la d\u00e9sactivation de ce mode n'est pas souhaitable non plus, car cela entra\u00eenera des pauses dues au GC lors de moments de travail intensif avec les donn\u00e9es. Une bonne solution consiste \u00e0 augmenter les volumes des cellules, en cas d'\u00e9criture active par put en m\u00eame temps que la lecture. Il convient de noter que le probl\u00e8me ne se pose pas si, apr\u00e8s l'\u00e9criture, nous ex\u00e9cutons la commande flush qui pousse MemStore sur le disque ou si un chargement est effectu\u00e9 par BulkLoad. Le tableau ci-dessous montre que les requ\u00eates provenant de MemStore de volumes de donn\u00e9es plus importants (et d'un nombre identique) entra\u00eenent un ralentissement. Cependant, en augmentant la taille des chunks, nous ramenons le temps de traitement \u00e0 la normale.<\/p>\n
    \"Th\u00e9orie
    \nEn plus d'augmenter le chunksize, le partitionnement des donn\u00e9es par r\u00e9gions, c'est-\u00e0-dire le splitting des tables, aide. Cela signifie qu'un nombre r\u00e9duit de requ\u00eates est envoy\u00e9 \u00e0 chaque r\u00e9gion, et si elles sont toutes plac\u00e9es dans une cellule, la r\u00e9ponse reste bonne.<\/p>\n
    6. Strat\u00e9gie de partitionnement des tables par r\u00e9gions (splitting)<\/h2>\n
    \n\u00c9tant donn\u00e9 qu'HBase est un stockage cl\u00e9-valeur et que le partitionnement s'effectue selon la cl\u00e9, il est essentiel de r\u00e9partir les donn\u00e9es de mani\u00e8re uniforme sur toutes les r\u00e9gions. Par exemple, le partitionnement d'une telle table en trois parties aura pour r\u00e9sultat que les donn\u00e9es seront r\u00e9parties sur trois r\u00e9gions :<\/p>\n
    \"Th\u00e9orie
    \nIl arrive que cela entra\u00eene un ralentissement drastique si les donn\u00e9es charg\u00e9es par la suite se pr\u00e9sentent sous la forme de valeurs long, majoritairement commen\u00e7ant par un m\u00eame chiffre, par exemple :<\/p>\n
    1000001
    \n1000002
    \n\u2026
    \n1100003<\/p>\n
    Comme les cl\u00e9s sont stock\u00e9es sous forme de tableau d'octets, toutes commenceront de la m\u00eame mani\u00e8re et iront \u00e0 la r\u00e9gion #1 qui contient cette plage de cl\u00e9s. Il existe plusieurs strat\u00e9gies de partitionnement :<\/p>\n
    HexStringSplit \u2013 Transforme la cl\u00e9 en une cha\u00eene avec un encodage hexad\u00e9cimal dans la plage \u00ab00000000\u00bb \u21d2 \u00abFFFFFFFF\u00bb, en remplissant avec des z\u00e9ros \u00e0 gauche.<\/p>\n
    UniformSplit \u2013 Transforme la cl\u00e9 en un tableau d'octets avec un encodage hexad\u00e9cimal dans la plage \u00ab00\u00bb \u21d2 \u00abFF\u00bb, en remplissant avec des z\u00e9ros \u00e0 droite.<\/p>\n
    De plus, il est possible de sp\u00e9cifier n'importe quelle plage ou ensemble de cl\u00e9s pour le partitionnement et de configurer le splitting automatique. Cependant, l'une des approches les plus simples et efficaces est UniformSplit et l'utilisation de la concat\u00e9nation de hachage, par exemple, la paire d'octets la plus significative provenant du passage de la cl\u00e9 par la fonction CRC32(rowkey) et la cl\u00e9 elle-m\u00eame :<\/p>\n
    hash + rowkey<\/p>\n
    Ainsi, toutes les donn\u00e9es seront r\u00e9parties uniform\u00e9ment sur les r\u00e9gions. Lors de la lecture, les deux premiers octets sont simplement ignor\u00e9s, et la cl\u00e9 d'origine reste. De plus, le RS contr\u00f4le le nombre de donn\u00e9es et de cl\u00e9s dans une r\u00e9gion et, si les limites sont d\u00e9pass\u00e9es, divise automatiquement celle-ci en parties. <\/p>\n
    7. R\u00e9silience et localit\u00e9 des donn\u00e9es<\/h2>\n
    \n\u00c9tant donn\u00e9 qu'un seul r\u00e9gion est responsable de chaque ensemble de cl\u00e9s, la solution aux probl\u00e8mes li\u00e9s aux pannes de RS ou \u00e0 la mise hors service consiste \u00e0 stocker toutes les donn\u00e9es n\u00e9cessaires dans HDFS. En cas de panne de RS, le ma\u00eetre le d\u00e9tecte par l'absence de heartbeat sur le n\u0153ud ZooKeeper. Il assigne alors la r\u00e9gion \u00e0 un autre RS, et comme les HFiles sont stock\u00e9s dans un syst\u00e8me de fichiers distribu\u00e9, le nouveau propri\u00e9taire les lit et continue \u00e0 g\u00e9rer les donn\u00e9es. Cependant, comme certaines donn\u00e9es peuvent \u00eatre dans MemStore et n'ont pas encore \u00e9t\u00e9 \u00e9crites dans HFiles, l'historique des op\u00e9rations est restaur\u00e9 \u00e0 l'aide de WAL, qui sont \u00e9galement stock\u00e9s dans HDFS. Apr\u00e8s l'application des modifications, le RS peut r\u00e9pondre aux requ\u00eates, mais le transfert entra\u00eene une s\u00e9paration des donn\u00e9es et des processus de gestion sur diff\u00e9rents n\u0153uds, ce qui diminue la locality. <\/p>\n
    La solution au probl\u00e8me est la compaction majeure \u2013 cette proc\u00e9dure d\u00e9place les fichiers vers les n\u0153uds responsables (l\u00e0 o\u00f9 se trouvent leurs r\u00e9gions), ce qui entra\u00eene une augmentation brutale de la charge sur le r\u00e9seau et les disques durant cette proc\u00e9dure. Cependant, par la suite, l'acc\u00e8s aux donn\u00e9es s'acc\u00e9l\u00e8re consid\u00e9rablement. De plus, la major_compaction fusionne tous les HFiles en un seul fichier au sein de la r\u00e9gion, et nettoie les donn\u00e9es en fonction des param\u00e8tres de la table. Par exemple, il est possible de d\u00e9finir le nombre de versions d'objet \u00e0 conserver ou la dur\u00e9e de vie apr\u00e8s laquelle l'objet est physiquement supprim\u00e9.<\/p>\n
    Cette proc\u00e9dure peut avoir un impact tr\u00e8s positif sur le fonctionnement d'HBase. L'image ci-dessous montre comment la performance a \u00e9t\u00e9 d\u00e9grad\u00e9e en raison de l'\u00e9criture active de donn\u00e9es. On voit ici 40 threads \u00e9crivant dans une table et 40 threads lisant des donn\u00e9es simultan\u00e9ment. Les threads d'\u00e9criture g\u00e9n\u00e8rent de plus en plus de HFiles, qui sont ensuite lus par d'autres threads. En cons\u00e9quence, de plus en plus de donn\u00e9es doivent \u00eatre supprim\u00e9es de la m\u00e9moire, et finalement, le GC commence \u00e0 s'ex\u00e9cuter, paralysant pratiquement tout le processus. Le lancement de la compaction majeure a permis de nettoyer les encombrements g\u00e9n\u00e9r\u00e9s et de restaurer la performance.<\/p>\n
    \"Th\u00e9orie
    \nLe test a \u00e9t\u00e9 r\u00e9alis\u00e9 sur 3 DataNodes et 4 RS (CPU Xeon E5-2680 v4 @ 2,40 GHz * 64 threads). Version HBase 1.2.0-cdh5.14.2<\/p>\n
    Il convient de noter que le lancement de la compaction majeure a \u00e9t\u00e9 effectu\u00e9 sur une table \"vivante\", o\u00f9 des donn\u00e9es \u00e9taient activement lues et \u00e9crites. Il a \u00e9t\u00e9 avanc\u00e9 sur le r\u00e9seau que cela pourrait entra\u00eener une r\u00e9ponse incorrecte lors de la lecture des donn\u00e9es. Un processus a \u00e9t\u00e9 lanc\u00e9 pour g\u00e9n\u00e9rer de nouvelles donn\u00e9es et les \u00e9crire dans la table. Ensuite, il lisait imm\u00e9diatement et v\u00e9rifiait si la valeur obtenue correspondait \u00e0 celle qui avait \u00e9t\u00e9 enregistr\u00e9e. Pendant le fonctionnement de ce processus, la compaction majeure a \u00e9t\u00e9 lanc\u00e9e environ 200 fois sans aucun \u00e9chec enregistr\u00e9. Il est possible que le probl\u00e8me se manifeste rarement et uniquement lors de charges \u00e9lev\u00e9es, il est donc pr\u00e9f\u00e9rable d'arr\u00eater le processus d'\u00e9criture et de lecture de mani\u00e8re planifi\u00e9e et d'effectuer l'entretien sans permettre de telles baisses du GC.<\/p>\n
    De plus, la compaction majeure n'affecte pas l'\u00e9tat du MemStore, pour le vider sur disque et le compacter, il faut utiliser flush (connection.getAdmin().flush(TableName.valueOf(tblName))).<\/p>\n
    8. Param\u00e8tres et performance<\/h2>\n
    \nComme mentionn\u00e9 pr\u00e9c\u00e9demment, HBase montre le plus de succ\u00e8s l\u00e0 o\u00f9 il n'a rien \u00e0 faire, lors de l'ex\u00e9cution du BulkLoad. Cela s'applique d'ailleurs \u00e0 la plupart des syst\u00e8mes et des personnes. Cependant, cet outil est plus adapt\u00e9 \u00e0 l'insertion massive de donn\u00e9es par gros blocs, alors que si le processus n\u00e9cessite l'ex\u00e9cution de plusieurs requ\u00eates concurrentes de lecture et d'\u00e9criture, les commandes Get et Put d\u00e9crites ci-dessus sont utilis\u00e9es. Afin de d\u00e9terminer les param\u00e8tres optimaux, des ex\u00e9cutions ont \u00e9t\u00e9 r\u00e9alis\u00e9es avec diff\u00e9rentes combinaisons de param\u00e8tres de tables et de configurations :<\/p>\n