De même que la prophétesse de Troie de laquelle elle tire son nom, Apache Cassandra a vu quelques mythes et légendes la toucher. Comme beaucoup de mythes, ceux-ci proviennent d'un fond de vérité, mais ils sont dépassés par les améliorations et les évolutions de Cassandra. Dans cet article, je discuterais cinq sujets d'inquiétude répandus et je clarifierais la confusion.
Mythe : Cassandra est un dictionnaire de dictionnaires
Alors que les applications utilisant Cassandra devenaient plus complexes, le typage de schéma et de données rendait le développement et la maintenance plus faciles que "tout est un tampon d'octets" ou "tout est une chaîne de caractères".
Actuellement, la meilleure façon de se représenter le modèle de données de Cassandra est celle des tables et des lignes. Les colonnes de Cassandra sont similaires à une base de données relationnelle en ce qu'elles sont typées fortement et indexables.
Vous pourriez aussi avoir entendu :
- "Cassandra est une base de données colonnes." Les bases de données colonnes stockent ensemble l'intégralité des valeurs d'une colonne donnée sur le disque. C'est approprié pour une charge associée à un entrepôt de données, mais pas pour l'exécution d'applications qui nécessitent un accès rapide à des lignes spécifiques.
- "Cassandra est une base de données wide-row" Il y a un fond de vérité, qui est que le moteur de stockage de Cassandra est inspiré de Bigtable, l'ancêtre des bases de données wide-row. Mais ces dernières couplent trop leur modèle de données avec le moteur de stockage, ce qui est facile à implémenter mais qui rend le développement plus difficile et empêche de nombreuses optimisations.
L'une des raisons pour lesquelles nous nous sommes éloignés des "tables et des lignes" est que les tables de Cassandra ont des différences subtiles avec les colonnes relationelles qui vous sont familières. En premier lieu, le premier élément d'une clé primaire est la clé de partition. Les lignes de la même partition sont la propriété des mêmes serveurs, et les partitions sont regroupées sur la même de serveurs.
En second lieu, Cassandra ne supporte ni les jointures, ni les sous-requêtes, car les jointures sur des machines différentes dans un système distribué ne sont pas performantes. Pour y remédier, Cassandra encourage la dénormalisation pour récupérer les données nécessaires d'une table unique, et procure des outils comme les collections pour la faciliter.
Par exemple, l'exemple de code suivant présente une table d'utilisateurs :
CREATE TABLE users (
user_id uuid PRIMARY KEY,
name text,
state text,
birth_year int
);
La plupart des services modernes comprennent que les utilisateurs ont plusieurs adresses mail. Dans le monde relationnel, nous ajouterions une relation un-à-plusieurs et nous corellerions les utilisateurs et les adresses par une jointure, comme dans l'exemple suivant :
CREATE TABLE users_addresses (
user_id uuid REFERENCES users,
email text
);
SELECT *
FROM users NATURAL JOIN users_addresses;
Dans Cassandra, nous dénormaliserions en ajoutant les adresses mail dictement à la table des utilisateurs. Une collection de type set est parfaite pour cela :
ALTER TABLE users ADD email_addresses set<text>;
Nous pourrions alors ajouter les adresses à l'enregistrement d'un utilisateur ainsi :
UPDATE users
SET email_addresses = {‘jbe@gmail.com’, ‘jbe@datastax.com’}
WHERE user_id = ‘73844cd1-c16e-11e2-8bbd-7cd1c3f676e3’
Consultez la documentation pour plus d'informations sur le modèle de données de Cassandra, y compris les données auto-expirables et les compteurs distribués.
Mythe : les lectures Cassandra sont lentes
Alors que le moteur de stockage structuré en log implique qu'il ne cherche pas les mises à jour sur le disque dur ou qu'il ne cause pas d'amplification d'écriture sur les disques à état solide, il est également rapide en lecture.
Voici les métriques de débit de lecture et d'écriture en accès aléatoire, de balayages séquentiels et les charges de lecture/écriture mixtes provenant des résultats de référence NoSQL de l'université de Toronto :
La référence principale comparant Cassandra, HBase et MongoDB corrobore ces résultats.
Comme cela fonctionne-t'il ? A un très haut niveau, le moteur de stockage de Cassandra est similaire à Bigtable et utilise une partie de la même terminologie. Les mises à jour sont annexées à la liste des commits, puis collectées à une "table-mémoire" qui est potentiellement écrite sur le disque et indexée comme un "sstable:"
Les moteurs de stockage structurés en log naïfs ont effectivement tendance à être plus lents en lecture, pour la même raison qu'ils sont rapides en écriture : les nouvelles valeurs dans les lignes ne remplacent pas celles existantes, mais doivent être fusionnées en tâche de fond par compactage. De fait, dans le pire des cas, vous devrez vérifier plusieurs sstables pour récupérer toutes les colonnes d'une ligne "fragmentée" :
Cassandra effectue quelques améliorations à cette conception de base pour atteindre de bonnes performances en lecture :
- Les stratégies de compactage sont enfichables. LeveledCompactionStrategy, par exemple, optimise les lectures par la combinaison aggressive de sstables qui se chevauchent.
- Cassandra vérifie les sstables dans l'ordre chronologique inverse ; en requêtant SELECT x, y FROM foo WHERE key = 42, une fois que Cassandra a trouvé les valeurs écrites les plus récemment pour x et y, elle n'a plus à vérifier des sstables plus anciens. L'application du même principe aux balayages télémétriques est légèrement plus compliqué mais toutefois possibe.
- Si l'on assiste à des lectures depuis plusieurs sstables, nous ré-écrivons le résultat défragmenté au moment de la lecture, de telle manière que des lectures consécutives n'auront à en vérifier qu'une seule.
- Une fois la partition accédée, son index est caché et les lignes qui le composent peuvent être accédées au sein d'une seule recherche (par sstable).
- Les méta-données du moteur de stockage sont conservées en dehors de la pile, pour éviter les problèmes de performance dus au ramasse-miettes.
Mythe : l'utilisation de Cassandra est complexe
Il existe trois aspects dans l'exécution d'un système distribué qui le rend plus compliqué que l'exécution d'une base de données sur une unique machine :
- Configuration et déploiement initial
- Maintenance de routine, comme la mise à jour, l'ajout de nouveaux noeuds et le remplacement de ceux en défaut
- Dépannage
Cassandra est un système complètement distribué : chaque machine appartenant à une grappe a le même rôle. Il n'existe pas de serveurs de méta-données qui doive tout mettre en mémoire. Il n'y a pas de serveurs de configuration à répliquer. Pas de maîtres, ni de basculement. Cela rend chaque aspect de l'exécution de Cassandra plus simple que les alternatives. Cela veut dire aussi que la mise en place d'une grappe d'un seul noeud pour le développement et le test est trivial, et qu'il se comporte exactement de la même manière qu'une grappe complète d'une douzaine de noeuds.
En un sens, le déploiement initial est la problématique la moins importante : toutes choses égales par ailleurs, même la mise en place relativement complexe d'un système sera finalement un point dérisoire comparé à la durée de vie du système, et des outils d'installation automatisée peuvent masquer les détails les plus pénibles. Cependant, si vous ne comprenez pas suffisamment un système pour l'installer manuellement, vous aurez assurément de gros soucis ensuite pour assurer des dépannages qui nécessitent une compréhension bien plus profonde de tous les rouages du système.
Je vous conseillerais donc d'être sûrs de maîtriser la phase d'installation, comme dans cet exemple de deux minutes expliquant la mise en place d'une grappe Cassandra, avant de vous en remettre à des outils comme Windows MSI Installer, l'allocation OpsCenter ou l'AMI auto-configurable.
Cassandra simplifie la maintenance de routine. Les montées de version peuvent être réalisées noeud par noeud. Lorsqu'un noeud est hors-service, d'autres noeuds vont sauvegarder les mises à jour que celui-ci n'a pas traitées, et les transmettre quand il sera disponible à nouveau. L'ajout de nouveaux noeuds est parallélisé à travers la grappe ; il n'est pas nécessaire de les ré-équilibrer par la suite.
Même la résolution de pannes imprévues et plus longues reste simple. La réparation active de Cassandra est similaire à rsync pour les bases de données et ne transfère que les données manquantes en conservant le trafic réseau à un niveau minimal. Vous pourriez même ne pas remarquer que quelque chose s'est produit si vous ne prêtez pas une attention particulière.
L'expertise de Cassandra en matière de support des centres de données multiples permet même de survivre à l'effondrement d'une région entière AWS ou à la perte d'un centre de données dans une tornade.
En dernier lieu, l'OpsCenter DataStax simplifie la résolution des pannes en permettant la visualisation des métriques les plus importantes de votre grappe en un coup d'oeil, ce qui permet de corréler simplement l'historique des activités avec les évènements ayant causé la dégradation de service. La distribution Cassandra DataStax Edition Communautaire inclut une version "allégée" de OpsCenter, gratuite pour une utilisation en production. DataStax Enterprise inclut également la sauvegarde et la restauration planifiées, les alertes configurables et plus encore.
Le développement avec Cassandra est difficile
L'API Thrift originale pour Cassandra parvenait à fournir une base transversale avec un minimum d'efforts, mais le résultat était difficilement exploitable. CQL, le dialect SQL de Cassandra l'a remplacé avec une interface simplifiée, une courbe d'apprentissage plus douce et un protocole asynchrone.
CQL était disponible depuis deux ans pour les pionners sous la version 0.8 ; avec la mise à disposition de la version 1.2 en janvier, CQL est prêt pour la production, avec beaucoup de pilotes et de meilleures performances que Thrift. DataStax supporte également de manière officielle les pilotes SQL les plus populaires, ce qui permet d'éviter le manque de support sur les pilotes Thrift de la part de la communauté.
Les présentations (un, deux) de Patric McFadin sur les Prochains Modèles de Données d'Excellence sont une bonne introduction à CQL après les bases de la documentation.
Cassandra est encore complètement nouveau
D'un point de vue open source, Apache Cassandra a maintenant bientôt cinq ans et a plusieurs versions, avec la version 2.0 en juillet. D'un point de vue entreprise, DataStax fournit DataStax Enterprise, qui inclut une version certifiée de Cassandra, testée, référencée et approuvée pour les environnements de production.
Les entreprises ont compris leur intéret à utiliser Cassandra. Plus de 20 des entreprises du Fortune 100 dépendent de Cassandra pour leurs applications sensibles dans presque tous les domaines, dont la finance, la santé, le commerce, les loisirs, la publicité en-ligne et la mercatique.
Le plus souvent la migration vers Cassandra s'effectue lorsque la technologie en place ne peut monter en charge pour répondre aux demandes des applications modernes qui utilisent un gros volume de données. Netflix, l'application cloud la plus importante au monde, a migré 95% de ses données d'Oracle à Cassandra. Barracuda Networks a remplacé MySQL par Cassandra car MySQL ne pouvait gérer le volume de requêtes nécessaires pour combattre les spammers modernes. OOyala gère deux millions de points de données chaque jour, avec un déploiement de Cassandra de plus de deux pétaoctets.
Cassandra améliore et remplace également les bases de données relationelles historiques qui se sont révélées trop coûteuses à gérer ou à maintenir. Le projet initial de Constant Contact a pris trois mois et 250 000$ avec Cassandra contre neuf mois et 2 500 000$ avec leurs SGBDS traditionnelles. Aujourd'hui, ils font confiance à Cassandra pour leurs six grappes et leurs +100To de données.
Beaucoup d'autres exemples peuvent être trouvés dans les études de cas de DataStax et dans les interviews d'utilisateurs de Planète Cassandra.
Pas un mythe : le Cassandra Summit 2013 à San Francisco
Ce fut le meilleur moyen d'en apprendre plus sur Cassandra grâce aux interventions de plus de 1100 participants et 65 sessions d'Accenture, Barracuda Networks, Mountain Capital, Comcast, Constant Contact, eBay, Fusion-io, Intuit, Netflix, Sony, Splunk, Spotify, Walmart et bien d'autres. Les présentations sont déjà là ; suivez Planète Cassandra pour être avertis de la disponibilité de nouvelles vidéos.
A propos de l'auteur
Jonathan Ellis est DSI et co-fondateur de DataStax. Avant DataStax, il a beaucoup travaillé avec Apache Cassandra quand il était employé à Rackspace. Avant Rackspace, Jonathan a construit un système de stockage de plusieurs pétaoctets basé sur l'encodage Reed-Solomon pour le fournisseur de sauvegarde Mozy.