Riak va sortir une version 2 sous peu , pas une version arbitraire et non justifiée comme l'avait fait Mongodb, une vraie, une jolie version 2, avec de vrais bouts de changements dedans. Des améliorations, mais aussi des changements d'avis, et de vraies nouveautés.
Administrations
Les priorités de Riak restent les mêmes, il commence par faire peu de choses, mais bien, ensuite, il expérimente des nouveautés, quelques aller-retour pour affiner, et si ça fonctionne, il les intègre. Plusieurs implémentations sont souvent mise à dispositions pour proposer une réponse adéquat aux différent contextes. La cible à chouchouter est toujours l'administrateur système. La stabilité et la résilience sont les fondements de Riak, au détriment des fonctionnalités. Les erlangueries pour la configuration ont disparu, la partie tuning (Leveldb en particulier) s'est simplifiée. Des réglages spécifiques à la réplication inter data center sont apparus, mais restent dans le giron de la gamme "entreprise", non libre.
Authentification
Riak a maintenant un système d'authentification . Il faut reconnaitre qu'avant, c'était un peu la fête, toute la sécurité était déléguée à la couche applicative. Maintenant, Riak rentre dans le rang, on retrouve la pile traditionnelle, à base de compte utilisateur, de mot de passe hashé, de masque IP, mais aussi de certificats SSL (client et serveur), de PAM et de ce que vous voulez, une API de plugin est disponible.
Cohérence
Il est maintenant possible pour un bucket (l'équivalent d'une table, pour simplifier) d'être "eventualy concistent" (cohérent à terme) ou "strongly concistent" (fortement cohérent). Le eventualy concistent est une des vraies nouveautés du NoSQL, mais aussi une source d'angoisse sans fin pour les gens habitués aux promesses ACID du classique SQL. Il faut reconnaitre en toute bonne foi que la grande majorité des projets n'ont ni les volumes, ni les débits nécessitant le sacrifice de la garantie immédiate de la cohérence des données. Pour arriver à saturer un bon vieux mysql/postgres, il faut commencer à taper fort, ou faire n'importe quoi, comme y stocker des logs. Bref, le théorème du CAP est toujours invaincu, mais il est pratique de pouvoir faire le choix "2 parmi 3" de manière fine, et explicite.
Indexation
Riak propose un index. Le résultat est mitigé. Étendre son usage à de la recherche full text s'est avéré être dramatique. Il faut reconnaitre que traiter du texte en Erlang est juste une punition. Donc, plutôt que de continuer le massacre, Riak 2 a tout simplement intégré Solr pour indexer textes, xml et autres json. Solr 4 a fait des choix plutôt violents pour gérer la notion de cluster : Zookeeper (Solr 3 faisait honteusement du rsync). C'est une des différences majeures avec Elastic Search, en fait, l'autre service basé sur l'irremplaçable Lucene. Riak n'aime pas la violence et ne fait pas confiance aux bricolages en Java pour paraphraser LA fonctionnalité indétrônable de Erlang OTP : la gestion du cluster. Techniquement, le coeur de Riak est une base clef-valeur accompagnée d'une gestion master less du cluster avec un keyring. Bref, aucune place pour Zookeeper, Riak se charge de clusteriser Solr. Le produit gagne ainsi en cohérence et en résilience. Toute la partie requête est confiée à Solr, Riak se contente de coordonner l'ensemble, et les utilisateurs le considèrent donc comme un serveur Solr standard.
Typage de données
La vraie nouveauté de Riak 2 est l'apparition de type de donnée . Toutes les bases NoSQL tombent dans le piège, elle commence par ne fournir que du blob comme type de valeurs, et laissent les développeurs se battre avec ça. Ensuite, le "eventualy concistent" commence à faire son oeuvre. Comment ajoute-t-on des éléments dans une liste, comment incrémenter un compteur, comment inverser un booléen, comment ne modifier qu'un attribut d'un élément sans tout écraser les valeurs? Tout ce genre de petites questions qui rappellent les l'ACID a finalement quelques intérêts. Mongo est le meilleur exemple d'implémentation pour répondre à ce genre de questions, mais comme il est fortement cohérent, lui, c'est de suite plus simple. Redis propose aussi des primitives sympathiques et efficaces, mais il a les mêmes contraintes, exécution séquentielle sur un seul thread, réplication en master/slave. CouchDB colle un verrou (optimiste) systématiquement. Bref, tout le monde répond à cette problématique, mais sans trop de challenge, tant que l'on reste dans les bases fortement cohérente. Pour les bases "eventualy consistant" le challenge est tout autre, et il faut passer par des states box, la recherche de concensus de Paxos, des historiques de modification, et des résolutions de conflit à la lecture. Riak 2 propose tout un ensemble cohérent et indispensable de primitives pour gérer les cas classiques d'accès concurrents.
Riak 2 laisse présager de belles choses à venir , il a toujours sa jolie place dans l'environnement un peu confus des bases NoSQL. En proposant la fiabilité de l'Erlang tout en bataillant vaillamment pour en corriger son étrangeté, il se positionne sans problème comme le plus abordable des "gros culs", le ticket d'entrée reste quand même 5 machines pour pouvoir dormir tranquille. Sa facilité d'administration, sa résliance et sa rapidité de redimensionnement sont maintenant largement reconnues. Reste à trouver un besoin pour déployer ce si beau jouet.
