Lorsque l'on insère une donnée dans HBase, la précédente version, si elle existe, n'est pas écrasée. HBase comme son mentor BigTable peut gérer plusieurs versions du contenu d'une même cellule.
Pour ceux qui se demandent comment exploiter au mieux cette capacité de HBase voici un conseil de Bill Graham sur la mailing list HBase :
Pour résumer les versions multiples d'une même cellule ne sont pas faites pour faire du mapping de données de type one-to-many. Dans ce dernier cas il ne faudra pas hésiter à créer plusieurs lignes ou ajouter des colonnes car contrairement à une base de donnée classique ajouter une colonne à une table HBase ne coûte rien (il ne faut donc pas s'en priver).
Il ne faut pas oublier qu'à l'origine cette fonctionnalité de "version de cellule" a été introduite dans la base de donnée BigTable de Google pour conserver un historique des évolutions des sites qui sont indexés par Google.
Il existe pourtant des cas où cela peut être nécessaire et astucieux : le meilleur exemple est sans doute Facebook et son nouveau système de messagerie (qui repose sur HBase) dans lequel on se sert de l'identifiant du message comme numéro de version et signifier la présence d'un mot dans le contenu du message :
Dans l'exemple ci dessus les messages msgid1 et msgid3 de l'utilisateur userid contiennent les mots mot1 et mot2. La valeur de la cellule, la donnée, n'est que la position ('offset') du mot dans le message. Il est alors facile pour Facebook de trouver les messages d'un utilisateur qui contiennent un mot voire même une succession précise de mots en exploitant les offsets.
D'un point de vu technique le principal reproche que l'on pourrait faire à ce type d'usage est que toutes les données d'un même utilisateur vont être stockées dans le même FileStore. Comme toutes ces données ne seront liées qu'à une seule clé il ne sera pas possible de les éclater par la suite sur plusieurs nœux. Les ingénieurs de Facebook ont du calculer que si ils s'en tenaient à stocker un 'offset', c'est à dire l'endroit dans le message où le mot apparaît alors cela devait être acceptable.
Dans HBase il n'est pas conseillé de garder plus d'une centaine de versions, il existe quelques subtilités à connaitre lorsque l'on joue avec les versions, la page http://hbase.apache.org/book.html#versions est un bon début pour approfondir le sujet en s'aidant du glossaire si nécessaire.
Pour ceux qui se demandent comment exploiter au mieux cette capacité de HBase voici un conseil de Bill Graham sur la mailing list HBase :
"[...] Once someone realizes that you can store multiple values for the same cell, each with a timestamp there can be a natural tendency to think "hey, I can store a one-to-many using multiple version of a cell". That's not the intent of versioned cell values.
Versioned cell values can be thought of as a way to keep a history of change for a single entity that at any given time only has one value. Like keeping track of a state change over time. For a one-to-many relationship (i.e., a user with many events), favor either multiple rows or multiple columns instead."
Pour résumer les versions multiples d'une même cellule ne sont pas faites pour faire du mapping de données de type one-to-many. Dans ce dernier cas il ne faudra pas hésiter à créer plusieurs lignes ou ajouter des colonnes car contrairement à une base de donnée classique ajouter une colonne à une table HBase ne coûte rien (il ne faut donc pas s'en priver).
Il ne faut pas oublier qu'à l'origine cette fonctionnalité de "version de cellule" a été introduite dans la base de donnée BigTable de Google pour conserver un historique des évolutions des sites qui sont indexés par Google.
Il existe pourtant des cas où cela peut être nécessaire et astucieux : le meilleur exemple est sans doute Facebook et son nouveau système de messagerie (qui repose sur HBase) dans lequel on se sert de l'identifiant du message comme numéro de version et signifier la présence d'un mot dans le contenu du message :
 |
| Modèle de donnée du nouveau système de messagerie facebook d'après http://www.slideshare.net/brizzzdotcom/facebook-messages-hbase |
D'un point de vu technique le principal reproche que l'on pourrait faire à ce type d'usage est que toutes les données d'un même utilisateur vont être stockées dans le même FileStore. Comme toutes ces données ne seront liées qu'à une seule clé il ne sera pas possible de les éclater par la suite sur plusieurs nœux. Les ingénieurs de Facebook ont du calculer que si ils s'en tenaient à stocker un 'offset', c'est à dire l'endroit dans le message où le mot apparaît alors cela devait être acceptable.
Dans HBase il n'est pas conseillé de garder plus d'une centaine de versions, il existe quelques subtilités à connaitre lorsque l'on joue avec les versions, la page http://hbase.apache.org/book.html#versions est un bon début pour approfondir le sujet en s'aidant du glossaire si nécessaire.
Comments
Post a Comment