ColumnType ou comment ranger ses colonnes

Comme cela faisait quelques mois que je n'avais rien écrit sur ce blog j'avais laissé passé l'introduction de nouveaux types de données pour les Columns et SuperColumns de Cassandra.

1. Presentation

Rappelons que dans chaque clef (key) les columns et SuperColumns sont triés selon un certain schéma qu'il faut donner au début, lors de la création de la base de données. Il existe un nombre limités de schéma. Depuis la version 0.6.1 deux nouveaux schémas ont été introduits je vais donc les passer en revue les six schémas de tri de columns utilisables :

• BytesType : Simple tri par byte et leur poids respectif. Rien de plus à dire
• AsciiType : Une chaîne de caractères codée en ASCII. Je vois mal pourquoi cette fonctionnalité a été rajoutée mise à part pour assurer la compatibilité avec des vieux systèmes. Je lui préfère largement le columnType "UTF8Type"
• UTF8Type Une chaîne de caractères codée en UTF8.
• LongType : Un entier de type long (codé sur 64 bits). Dans ce cas la column 8 viendra après la column 7 qui viendra après la column 6, qui viendra après la column 1 etc...
• LexicalUUIDType : Un UUID trié par ordre lexical. J'ai encore du mal à voir l'intérêt, mais il y en a sûrement.
• TimeUUIDType : Une donnée qui est codée sur 128 bits : 64 bits pour un nombre random et 64 bits pour un entier qui dénote l'heure en millisecondes à laquelle le TimeUUID a été créé. Ce ColumnType est peut être le plus utile de tous

  2.Quelques cas pratiques 

    i) Tri par date :
Ce premier cas est un cas tres courant, cela correspond a avoir les columns triées par ordre chronologique ( chronologique inversé). Dans le cas de SQL on peut par exemple insérer un Timestamp (un entier de 64 bits ) qui va correspond à la date à laquelle on a fait l'insertion. Ensuite SQL se chargerait de trier tout ça.
Dans le cas de Cassandra on peut faire la même chose. Mais comme toujours les choses ont été vues en grand et la question se pose : "Qu'arrive-t-il lorsque deux insertion se font à la même milliseconde ?". La réponse la plus simple est que le serveur va écraser une des deux données. Afin d'éviter ce genre de problème Cassandra peut utiliser un TimeUUIDType, la chance de tomber sur deux TimeUUIDType en les générant à la même seconde est de 1/(18,446,744,073,709,551,616) soit 10e-19.



    ii) Tri par rang

Cas : L'école MachinTruc utilise Cassandra pour ses élèves et elle souhaite avoir une clef "Rang" (Rappelez vous avec Cassandra les clefs sont des String) dans laquelle elle tri ses élèves par rang. On veut en une requête s'assurer qu'on obtiendra les 5 premiers élèves ou les 10 premiers.

Quel ColumnType utiliser ?
Réponse : LongType évidemment !
La structure pourrait avoir cette forme
key:"Rang"{
  Column:1{
    Value:"Pierre"}
  Column:2{
    Value:"Marie"}
  ...
}

    iii) Tri par nom noms

Cas : L'école MachinTruc désire avoir une clef qui représente une matière et une année dans laquelle elle range ses élèves par nom et dans la valeur de la columne la note qu'a eu l'élève.
On crée donc une ColumnFamily avec comme ColumnType UT8Type et on aura les données ordonnées de cette façon (après insertion bien sûr) :


key:"Biologie2010"{
  Column:"Marie"{
    Value:"20"}
  Column:"Pierre"{
    Value:"15"}
Column:"Zora"{
    Value:"16"}
  ...

}


key:"Physique2010"{
  Column:"Marie"{
    Value:"12"}
  Column:"Pierre"{
    Value:"11"}
Column:"Zora"{
    Value:"7"}
  ...

}



____________________________
Vous pouvez m'envoyer vos idées de cas d'utilisation dans les commentaires et j'essaierai de les étudier et de poster la réponse.

A bientôt !