Voldemort, en lecture seule (2/3)

Précédemment, nous avons vu l’intérêt de Voldemort pour stocker vos recommandations quotidiennes. Il est maintenant temps de mettre les mains dans le cambouis en commençant par installer Voldemort en lecture seule.

Un premier lancement

La première étape est de récupérer la dernière version de voldemort (1.3.0) sur code.google.com. Historiquement, le code était hébergé sur code.google.com puis le projet fut migré sur github. Cependant, ce dernier n’autorisant plus le téléchargement des binaires, cette partie fut de nouveau migrée vers code.google.com. Ne vous inquiétez donc pas en regardant l’historique des versions.

Une fois l’archive décompressé, vous verrez un dossier config contenant différentes configurations de test. Lançons donc le serveur une première fois par acquis de conscience.

bin/voldemort-server.sh config/single_node_cluster > /tmp/voldemort.log &

L’archive contenant également un client de type console, lançons celui ci pour vérifier l’état du serveur.

bin/voldemort-shell.sh test tcp://localhost:6666
 Established connection to test via tcp://localhost:6666
> get "mykey"
null
> put "mykey" "myvalue"
> get "mykey"
version(0:1) ts:1367501231872: "myvalue"
> put "mykey" "mynewvalue"
> get "mykey"
version(0:2) ts:1367501252890: "mynewvalue"
> delete "mykey"
> get "mykey"
null
> exit
k k thx bye.

Nous avons fait le tour des commandes importantes, à savoir : put, get et delete. Nous pouvons désormais arrêter le serveur et nous concentrer sur la configuration de Voldemort en lecture seule.

bin/voldemort-stop.sh

La configuration cible

A coté du dossier config/single_node_cluster, créons un autre dossier. Par exemple, config/xro pour ‘xebia read only’ (mais  le nom est bien sur libre). A l’intérieur de celui-ci, il va falloir créer un autre dossier config (le nom est cette fois ci important) contenant trois fichiers : cluster.xml, stores.xml et server.properties.

cluster.xml

Comme son nom l’indique, il s’agit de la configuration du cluster lui-même et sera donc le même sur tous les nœuds du cluster. Il permet de spécifier les nœuds, leurs ports et quelles partitions ils servent.

<cluster>
 <!-- The name is just to help users identify this cluster from the gui -->
 <name>mycluster</name>
 <server>
  <!-- The node id is a unique, sequential id beginning with 0 that identifies each server in the cluster-->
  <id>0</id>
  <host>localhost</host>
  <http-port>8081</http-port>
  <socket-port>6666</socket-port>
  <!-- A list of data partitions assigned to this server -->
  <partitions>0, 1</partitions>
 </server>
</cluster>

Nous partons ici sur un cluster composé d’un seul nœud et servant toutes les données, qui seront séparées en deux partitions. A noter : le nombre de partitions ne peut être changé par la suite. Avant de passer sur une installation pérenne, pour des raisons de performances, il est donc important de fixer avec précaution le nombre de partitions qui dépendront du nombre de nœuds mais également du volume des données et des patterns d’accès. Hormis cette limitation, Voldemort possède une administration et un monitoring assez avancés.

stores.xml

Tout comme le précédent fichier, celui-ci est identique sur tous les nœuds du cluster. Il va définir les stores. En grosse approximation, on peut dire qu’un store correspond à une table dans le monde relationnel. Ce fichier va permettre de définir les types des clefs et des valeurs. L’API effectuera alors la sérialisation/desérialisation de façon transparente. Il faut également spécifier l’implémentation du stockage (bdb, mysql, memory, readonly ou cache) ainsi que comment est gérée la cohérence des données (nombres d’écritures, nombre de lectures, nombre de réplications).

<stores>
 <store>
  <name>mymovies</name>
  <persistence>read-only</persistence>
  <routing>client</routing>
  <replication-factor>1</replication-factor>
  <required-reads>1</required-reads>
  <required-writes>1</required-writes>
  <key-serializer>
   <type>string</type>
  </key-serializer>
  <value-serializer>
   <type>avro-generic</type>
   <schema-info>{"type": "array", "items": "long"}</schema-info>
  </value-serializer>
 </store>
</stores>

Nous partons ici sur une implémentation readonly du stockage. Pour cette raison, la configuration de cohérence n’a pas beaucoup d’intérêt. A titre d’exemple, nous allons stocker l’association entre un utilisateur (en tant que string) à une liste de films (en tant que liste d’identifiants techniques : des longs). On garde la clef comme une string afin de pouvoir aisément tester par le client. On pourrait tout aussi bien avoir une clef composite stockée sous format avro. L’utilisation d’avro pour la valeur permet de valider le document grâce au schéma mais aussi de profiter d’un encoding binaire efficace (variable-length zig-zag) tout en sachant que l’on est capable d’écrire ce format depuis hadoop (en java) mais aussi capable de le lire par un client dans un des nombreux langages supportés par avro : C, C++, C#, Perl, Python, Ruby, PHP. Nous utilisons ici avro-generic qui permet de mapper le schema sur un graphe d’objets génériques c’est à dire sans génération de code. Pour des raisons de performance, il pourrait être intéressant d’évaluer le gain apporté par la génération de code (avro-specifique).

server.properties

Ce fichier définit enfin la configuration propre au nœud. La configuration ayant des valeurs par défaut saines, il faut juste activer le stockage readonly. C’est une duplication d’information par rapport à la configuration des stores qui est nécessaire.

# The ID of *this* particular cluster node (different for each node in cluster)
node.id=0
enable.readonly.engine=true
file.fetcher.class=voldemort.store.readonly.fetcher.HdfsFetcher

validation

Tout est enfin prêt. Afin de valider, il suffit de lancer le serveur une nouvelle fois et de s’y connecter avec le client. Il ne sera bien sûr pas possible d’ajouter des données mais le serveur va créer par lui-même les fichiers (données et index) vides nécessaires.

bin/voldemort-server.sh config/xro > /tmp/voldemort.log &
bin/voldemort-shell.sh mymovies tcp://localhost:6666

A noter : le répertoire de configuration a changé et le client ne vise plus le même store.  On remarquera que les fichiers (données et index) ont bien été créés dans le dossier config/xro/data/read-only/mymovies/latest.

Nous avons désormais une installation fonctionnelle de Voldemort en lecture seule. Bien sur en l’état, sans donnée, elle ne présente pas beaucoup d’intérêt. Et c’est pourquoi il faut continuer le pas à pas avec la génération de ces fichiers depuis Hadoop et leur import. La procédure sera détaillée dans le prochain article.