Transition d'un modèle SGBDR vers HBase - indicateurs

Si vous êtes confronté à la phase de conception de votre application et que vous pensez que HBase conviendrait parfaitement, la conception de vos clés de ligne et de votre schéma pour s'adapter au modèle et à l'architecture HBase est la bonne approche. Cependant, il est parfois judicieux de déplacer une base de données initialement conçue pour un SGBDR vers HBase.

Un scénario courant où cette approche est logique est une instance de base de données MySQL qui a atteint ses limites d'extensibilité. Des techniques existent pour mettre à l'échelle horizontalement une instance de MySQL ( sharding, en d'autres termes) mais ce processus est généralement lourd et problématique car MySQL n'a tout simplement pas été conçu pour le sharding.

La transition du modèle relationnel au modèle HBase est une discipline relativement nouvelle. Cependant, certains modèles de pensée établis émergent et se sont fusionnés en trois principes clés à suivre lors de l'approche d'une transition. Ces principes sont dénormalisation, duplication, et clés intelligentes (DDI) .

• Dénormalisation: Le modèle de base de données relationnelle dépend de a) un schéma de base de données normalisé et b) des jointures entre les tables pour répondre aux opérations SQL. La normalisation de la base de données est une technique qui protège contre la perte de données, la redondance et d'autres anomalies au fur et à mesure que les données sont mises à jour et récupérées.

  Les experts suivent un certain nombre de règles pour arriver à un schéma de base de données normalisé (et la normalisation de la base de données est une étude complète), mais le processus consiste généralement à diviser entre eux. La dénormalisation de base de données est l'opposé de la normalisation, où des tables plus petites et plus spécifiques sont jointes dans des tables plus grandes et plus générales.

  Il s'agit d'un modèle courant lors de la transition vers HBase, car les jointures ne sont pas fournies entre les tables et les jointures peuvent être lentes, car elles impliquent des opérations disque coûteuses. Protéger contre les anomalies de mise à jour et de récupération est maintenant le travail de votre application cliente HBase, puisque les protections offertes par la normalisation sont nulles et non avenues.

• Duplication: Lorsque vous dénormaliserez votre schéma de base de données, vous finirez probablement par dupliquer les données car cela peut vous éviter des opérations de lecture coûteuses sur plusieurs tables. Ne soyez pas préoccupé par le stockage supplémentaire (dans la mesure bien sûr); vous pouvez utiliser l'évolutivité automatique de HBase à votre avantage.

  Sachez cependant que votre application cliente devra effectuer un travail supplémentaire pour dupliquer les données et rappelez-vous que HBase ne fournit que des opérations atomiques de niveau ligne non croisées (à l'exception de la HBASE-5229 JIRA) ou table.

• Touches intelligentes: Comme les données stockées dans HBase sont triées par clé de ligne et que la clé de ligne est le seul index natif fourni par le système, une conception intelligente de la clé peut faire une énorme différence. Par exemple, votre clé de ligne peut être une combinaison d'un numéro de commande de service et du numéro d'identification du client qui a passé la commande de service.

  Cette conception de clé de ligne vous permet de rechercher des données liées à l'ordre de service ou de rechercher des données relatives au client à l'aide de la même clé de ligne dans la même table. Cette technique sera plus rapide pour certaines requêtes et évitera les jointures coûteuses.

Pour clarifier ces schémas de pensée particuliers, prenez un tableau d'informations sur les coordonnées du client et placez-le dans le contexte d'une base de données de commandes de services type. La figure montre à quoi pourrait ressembler un schéma de base de données d'ordres de service normalisé.

En suivant les règles de normalisation du SGBDR, configurez l'exemple de table Informations sur le contact client afin qu'il soit distinct du tableau des ordres de service afin d'éviter de perdre des données client lorsque les ordres de service sont fermés et éventuellement supprimés. Adoptez la même approche pour la table Produits, ce qui signifie que de nouveaux produits peuvent être ajoutés à la base de données fictive indépendamment des ordres de service.

En s'appuyant sur les opérations de jointure RDBMS, ce schéma prend en charge les requêtes qui révèlent le nombre de commandes de service ouvertes par rapport à un produit particulier ainsi que l'emplacement du client où le produit est utilisé.

Tout va bien, mais c'est un schéma que vous utiliseriez avec RDBM. Comment faites-vous passer ce schéma à un schéma HBase? La figure suivante illustre un schéma possible de HBase - celui qui suit le modèle de conception DDI.

Le tableau Informations sur le contact client a été dénormalisé en incluant le nom du client et les informations de contact à la place des clés étrangères utilisées précédemment. En outre, les données sont dupliquées en conservant le tableau Informations sur les contacts du client tel quel. Les jointures entre la table Order Order et Customer Contact Information ne sont plus nécessaires.

De plus, une clé intelligente a été utilisée pour combiner le numéro de produit avec le numéro de client pour former le numéro de commande (A100 | 00001, par exemple). Grâce à cette clé intelligente, le tableau des commandes de service peut fournir des rapports essentiels sur les défaillances des produits et les clients qui rencontrent actuellement des problèmes de produit.

Toutes ces requêtes peuvent toutes être supportées par HBase dans un mode atomique de niveau ligne pour l'application. Parce que vous savez que HBase commande les clés de ligne et les trie d'une manière lexicographique, votre application peut émettre des hypothèses éclairées sur la localité de données lors de l'émission d'analyses pour la création de rapports. (Tous les numéros de produits de la série A * seront stockés ensemble, par exemple.)

La base de données des commandes de service représentée par le schéma HBase est un exemple relativement simple, mais elle illustre comment HBase peut, dans certains cas, se croiser avec le monde RDBMS et fournir une valeur significative. Si l'entreprise fictive dispose de téraoctets ou même de pétaoctets de données d'appel de service à stocker, HBase ferait une énorme différence en termes de coût, de fiabilité, de performance et d'évolutivité.

Vous pouvez, bien sûr, concevoir le schéma HBase de votre commande de service de plusieurs manières différentes. Certes, la conception dépend des requêtes qui doivent être prises en charge, mais vous avez la possibilité de transférer certaines bases de données relationnelles vers des applications HBase très puissantes pour la production, tant que vous maîtrisez l'architecture HBase et le modèle de conception DDI.

Cet exemple suppose que les requêtes ont été exécutées par une application Java utilisant les API client HBase, ou peut-être via un autre langage utilisant Apache Thrift. Ce modèle d'application peut très bien répondre aux exigences et fournir des options de performance et de personnalisation utiles pour la société de services fictifs.