Apache Cassandra : gestion dis­tri­buée de bases de données vo­lu­mi­neuses

Lorsqu’il vous faut gérer de très gros volumes de données, de l’ordre de plusieurs té­raoc­tets, voire pé­taoc­tets, les systèmes de base de données courants sont vite dépassés.

Il est ici question d’ap­pli­ca­tions Big Data spéciales pour les­quelles une évo­lu­ti­vité élevée est très im­por­tante, car il est bien souvent im­pos­sible d’évaluer le volume de données réel à gérer au moment de leur création. L’un des porte-étendards modernes pri­vi­lé­giés de ce domaine est la solution open source Cassandra, ini­tia­le­ment dé­ve­lop­pée pour Facebook.

Apache Cassandra est un système de gestion de bases de données (DBMS) open source pour bases de données struc­tu­rées très vo­lu­mi­neuses. Grâce à la bonne évo­lu­ti­vité du système, ces bases de données peuvent être dis­tri­buées sur plusieurs clusters. C’est pourquoi Cassandra n’est pas lié à un seul serveur.

Cassandra fait partie des bases de données NoSQL orientées en colonnes. Dans ce contexte, NoSQL signifie « Not only SQL », et non « pas SQL ». Con­trai­re­ment aux bases de données SQL typiques, les struc­tures NoSQL pré­sen­tent des avantages con­si­dé­rables pour le trai­te­ment de gros volumes de données, dans la mesure où elles ne sont pas liées aux res­tric­tions du langage de requête SQL (Struc­tu­red Query Language).

Apache Cassandra est doté de son propre langage de requête du nom de Cassandra Query Language (CQL). Celui-ci s’apparente au SQL, mais est pri­vi­lé­gié par les dé­ve­lop­peurs du fait de sa parfaite adé­qua­tion aux par­ti­cu­la­ri­tés de Cassandra.

En tant que base de données NoSQL, Cassandra fonc­tionne selon une approche re­don­dante pour une sécurité renforcée. À l’inverse, la ré­pli­ca­tion des données des systèmes de base de données re­la­tion­nels pose toujours de nouveaux problèmes.

Outre ses dé­ve­lop­peurs originaux, d’autres grandes en­tre­prises, telles qu’IBM, Twitter et Rackspace, l’un des plus im­por­tants pres­ta­taires de services in­for­ma­tiques aux États-Unis, par­ti­ci­pent désormais au dé­ve­lop­pe­ment de Cassandra. La société DataStax apporte également une con­tri­bu­tion sig­ni­fi­ca­tive au projet.

Son modèle com­mer­cial repose, pour l’essentiel, sur une offre d’as­sis­tance payante, des services d’aide à l’ins­tal­la­tion et des for­ma­tions à l’uti­li­sa­tion de la base de données Cassandra.

À ce jour, DataStax prend en charge près de 80 % du dé­ve­lop­pe­ment open source de Cassandra et fournit, avec DataStax En­ter­prise, une solution de base de données com­mer­ciale reposant sur le modèle gratuit usuel de Cassandra.

En tant que système distribué, Cassandra n’utilise pas de maître. Tous les clusters sont dotés d’au­to­ri­sa­tions iden­tiques et peuvent traiter toutes les requêtes de bases de données qui leur sont adressées. Cela permet d’en augmenter con­si­dé­ra­ble­ment les per­for­mances. Les données sont dis­tri­buées sur des nœuds. La facilité d’ajout de nœuds assure la bonne évo­lu­ti­vité du système. Après l’ins­tal­la­tion, il suffit de dis­tri­buer les fichiers de con­fi­gu­ra­tion vers les nouveaux nœuds. Cassandra met ici des outils adaptés à dis­po­si­tion des dé­ve­lop­peurs.

Pour garantir la sécurité et, en cas de besoin, la capacité de res­tau­ra­tion des données, Apache Cassandra dispose d’un système de ré­pli­ca­tion con­fi­gu­rable ajustable aux besoins de l’uti­li­sa­teur. La tolérance aux pannes est limitée par la ré­pli­ca­tion au­to­ma­tique des données entre les nœuds. Les nœuds affectés par une erreur peuvent fa­ci­le­ment être remplacés. Le système reste dis­po­nible pour toutes les requêtes.

Cassandra offre en outre une dis­po­ni­bi­lité et une tolérance à la partition élevées. Selon le théorème CAP in­for­ma­tique, il n’est jamais possible de garantir si­mul­ta­né­ment la cohérence (Con­sis­tency), la dis­po­ni­bi­lité (Avai­la­bi­lity) et la tolérance à la partition (Partition tolerance).

Le cas échéant, la cohérence, c’est-à-dire le fait que tous les nœuds puissent, à tout moment, accéder aux mêmes données, se voit attribuer la priorité la plus faible, comme c’est le cas pour de nombreux systèmes Big Data. En cas de panne, la cohérence peut être ra­pi­de­ment garantie par la res­tau­ra­tion des données. En ce sens, les deux autres ca­rac­té­ris­tiques doivent être assurées en per­ma­nence.

Les bases de données Cassandra sont com­pa­tibles avec le modèle de pro­gram­ma­tion MapReduce développé par Google pour les calculs de gros volumes de données sur des systèmes dis­tri­bués. Le langage de requête de base de données propre CQL (Cassandra Query Language) est spé­cia­le­ment adapté aux struc­tures de données de Cassandra.

L’un des avantages prin­ci­paux de Cassandra est sa bonne évo­lu­ti­vité à un niveau de sécurité très élevé - des con­di­tions élé­men­taires pour les ap­pli­ca­tions Big Data. Pour Cassandra, on parle d’évo­lu­ti­vité ho­ri­zon­tale. Cela signifie que la capacité et la per­for­mance du système peuvent être aug­men­tées par l’ajout de nœuds sup­plé­men­taires.

À l’inverse, pour une évolution verticale du système, le serveur de base de données utilisé doit être doté de pro­ces­seurs plus puissants ou de disques durs plus gros lorsque la per­for­mance ou la capacité n’est plus adaptée aux exigences de l’uti­li­sa­teur. Dans la mesure où il est possible de tra­vail­ler avec du matériel de serveur usuel, l’évolution ho­ri­zon­tale est, dans la plupart des cas, la solution la plus éco­no­mique.

Le modèle de données de Cassandra est fondé sur les Hash-Tables (tables de hachage) mul­ti­di­men­sion­nelles, dans les­quelles chaque ligne peut comporter un nombre infini de colonnes. Con­trai­re­ment à un tableau de base de données classique, ces colonnes n’ont pas besoin d’être iden­tiques pour chaque ligne. Pour les critères de référence et au sein de scénarios d’ap­pli­ca­tion réels, Apache Cassandra convainc en outre par un avantage con­si­dé­rable en matière de vitesse d’ex­ploi­ta­tion par rapport aux autres bases de données NoSQL.

L’un des objectifs prin­ci­paux du dé­ve­lop­pe­ment de Cassandra était de faciliter les re­cherches de messages entrants pour les uti­li­sa­teurs de Facebook. Pour cela, le con­sor­tium utilisait un cluster de plus de 150 nœuds.

Ce n’est pas un hasard si Cassandra, dont les struc­tures de base s’ap­pa­ren­tent à celles d’Amazon Dynamo et Google Bigtable, est désormais l’option pri­vi­lé­giée par les opé­ra­teurs de grands réseaux sociaux au sein desquels de nom­breuses données doivent être mises en réseau entre les uti­li­sa­teurs. Ses clients les plus célèbres sont, entre autres, Twitter, Instagram et Spotify, mais aussi le four­nis­seur de social book­mar­king Digg et l’agré­ga­teur de contenu social Reddit.

De nombreux autres réseaux, ex­ploi­tant de larges volumes de données, se servent de Cassandra comme base de données, tant prin­ci­pale qu’auxi­liaire pour certaines opé­ra­tions. On peut ainsi citer, entre autres, eBay, GitHub, Netflix, The Weather Channel et le Grand col­li­sion­neur de hadrons du Centre européen de recherche nucléaire CERN (env. 30 000 té­raoc­tets de données par an). L’une des ins­tal­la­tions prin­ci­pales de Cassandra est gérée par Apple et compte 75 000 nœuds.

Apache Cassandra peut être exécuté sur des systèmes si­mi­laires à UNIX, de pré­fé­rence sur des serveurs Linux. Il faut en outre avoir accès à l’en­vi­ron­ne­ment Java Runtime, car Cassandra est programmé en Java. Les packs d’ins­tal­la­tion sont dis­po­nibles sous forme de paquets Debian ou RPM sur les serveurs Apache. Pour l’ins­tal­la­tion, ajoutez le ré­fé­ren­tiel adapté. Après l’ins­tal­la­tion, il convient de créer des ré­per­toires de données, cache et pro­to­coles typiques et de les con­fi­gu­rer dans le fichier cassandra.yaml.

Cassandra est ad­mi­nis­tré par ses propres outils de ligne de commande. Le plus important est Shell, le langage de requête de Cassandra cqlsh.

Avec la commande suivante, vous ob­tien­drez un premier aperçu de toutes les commandes possibles :

La vidéo YouTube suivante présente clai­re­ment Apache Cassandra :