A l'occasion de son intervention lors de la QCon de New-York du mercredi 11 juin, Jeff Johnson, qui fait partie du core data group de Facebook, a annoncé la sortie d'Apollo, la base NoSQL de Facebook dans le style de Paxos. Écrite en C++11 et basée sur le framework Apache Thrit 2 RPC, Apollo est un système de stockage hiérarchique dans lequel toutes les données sont découpées en fragments, d'une manière très analogue aux serveurs de région de HBase. Comme Johnson nous l'explique, son point fort est son stockage online sur supports à faible latence - en particulier sur des supports Flash ou en mémoire.
Apollo adopte une approche différente de celle des bases orientées document, ou clé-valeur, Apollo met l'accent sur les structures de données mutables. Ce qui vous permet de représenter des maps, des files, des arbres, et ainsi de suite, aussi bien que des clés-valeurs. Dans le système, les fragments de données individuelles sont plutôt petits - de 1 octet à 1Mo, pour une taille totale allant de 1Mo à plus de 10Po. Le nombre de serveurs supportés va de 3 à plusieurs milliers.
Chaque fragment dispose de quatre composants. Le premier est un protocole de quorum qui est basé sue Raft, un puissant protocole de consensus qui nous vient de Stanford. Jonhson a expliqué qu'un des points que son équipe avait particulièrement apprécié dans Raft était que le processus de récupération à la suite de la perte du leader était réellement bien défini, dans la mesure où il entraîne une modification du quorum. Selon ses propres mots, ça n'est pas beaucoup plus simple que de travailler avec un multi-paxos :
Nous avons du développer beaucoup de choses - tout ce qui permet les écritures asynchrones et les lectures sur les disques qui essayent de gérer les cas où l'ordre des écritures est modifié lors de la lecture parce que le serveur est en train de gérer d'autres tâches ou que les disques sont lents, un système de détection des données corrompues, et bien d'autres choses encore.
Le second composant est le stockage. A l'heure ou nous écrivons ces lignes, le stockage est basé sur RocksDB, une base de données orientée clé-valeur qui s'appuie sur LevelDB de Google. Bien qu'il s'agisse d'une base de données orientée clé-valeur, Facebook l'utilise pour émuler d'autres structures de données. Apollo a été conçu pour être agnostique au système de stockage, l'équipe est en train d'ajouter le support de MySQL comme moteur de stockage alternatif.
Le troisième composant est l'API cliente qui expose les méthodes read() et write(). Toutes les opérations qui sont effectuées par Apollo sont, à l'échelle d'un Shard, atomiques, vous posez des pré-conditions, et si elles sont satisfaites, la lecture ou l'écriture est mise en oeuvre. Par exemple :
read(conditions : {map(m1).contains(x)},
reads : {deque(d2).back()})
"Si la map m1 contient la valeur x, alors retourne-moi la valeur qui est à la fin de la deque d2".
Vous pouvez combiner autant de conditions que vous le souhaitez et autant de lectures que vous voulez.
Les opérations d'écriture sont très semblables et vous permettent d'écrire des conditions :
write(conditions : {ver(k1) == v}, reads : {},
writes : {val(k1) := x})
Les derniers des quatre composants d'un fragment sont les Fault Tolerant State Machines (FTSM, machines à états tolérantes aux pannes). Elles sont principalement destinées à être utilisées par le code système, mais il est possible de l'utiliser dans le code client. Chaque FTSM est gérée par un fragment de telle sorte que, par exemple, si un fragment est réparti sur trois machines, le même code sera exécuté en parallèle sur les trois machines. Elles ont la possibilité d'accéder aux données persistantes qui sont locales à chaque machine. Plus important, si un noeud meurt, le code continue à s'exécuter dans un ordre approprié sur lequel les autres noeuds s'accordent.
Entre autres choses, les machines à états sont utilisées pour la répartition de charge, les migrations de données, la création ou la destruction de fragments, la coordination des transactions inter-fragments. Les machines à états peuvent entraîner des effets de bords, elles peuvent, par exemple, envoyer des requêtes RPC à des machines distantes, mais dès qu'elles doivent apporter des modifications aux données persistantes, elles doivent les soumettrent à Raft afin d'avoir l'accord des autres serveurs.
Apollo n'est à l'heure actuelle pas encore utilisé en production chez Facebook, mais la firme réfléchit sérieusement à Apollo pour remplacer certains cas d'utilisation de memcached, Johnson a été clair sur le fait que Facebook utilisait beaucoup memcached. "Plus généralement", Johnson a déclaré à InfoQ "nous regardons un certain nombre de solutions de stockage en mémoire chez Facebook, que ce soit de nouveaux systèmes ou des systèmes pour remplacer ceux qui existent déjà, en faisant des comparaisons points par points avec les systèmes en place".
La société prévoit aussi d'utiliser Apollo comme un système fiable de queuing pour les messages sortants vers iOS, Android et prestataires SMS, et pour améliorer les temps de calcul des analyses.
Apollo est toujours en phase de développement et n'a pas été livré en open source bien que Johnson eut déclaré que Facebook y songeait et voudrait le faire. La présentation de Johnson est actuellement disponible pour les participants à la QCon et sera publiée pour tout le monde via InfoQ en temps voulu.