FAQ CassandraConsultez toutes les FAQ

Les principales caractéristiques de la base de données NoSQL Cassandra sont définies ci-dessous.

• Tolérance aux pannes : les données d'un nœud (un nœud est une instance de Cassandra) sont automatiquement répliquées vers d'autres nœuds (différentes machines). Ainsi, si un nœud est hors service, les données présentes sont disponibles à travers d'autres nœuds. Le terme de facteur de réplication désigne le nombre de nœuds où la donnée est répliquée. Par ailleurs, l'architecture de Cassandra définit le terme de cluster comme étant un groupe d'au moins deux nœuds et un data center comme étant des clusters délocalisés. Cassandra permet d'assurer la réplication à travers différents data centers. Les nœuds qui sont tombés peuvent être remplacés sans indisponibilité du service.
• Décentralisé : dans un cluster tous les nœuds sont égaux. Il n'y pas de notion de maître, ni d'esclave, ni de processus qui aurait à sa charge la gestion, ni même de goulet d'étranglement au niveau de la partie réseau. Nous étudierons dans un prochain article lié à la scalabilité le protocole GOSSIP utilisé pour découvrir la localisation et les informations sur l'état des nœuds d'un cluster.
• [b]Modèle de données riche : le modèle de données proposé par Cassandra, basé sur la notion de clé/valeur, permet de développer de nombreux cas d'utilisation dans le monde du Web.
• Élastique : la scalabilité est linéaire. Le débit d'écriture et de lecture augmente de façon linéaire lorsqu'un nouveau serveur est ajouté dans le cluster. Par ailleurs, Cassandra assure qu'il n'y aura pas d'indisponibilité du système ni d'interruption au niveau des applications.
• Haute disponibilité : possibilité de spécifier le niveau de cohérence concernant la lecture et l'écriture. On parle alors de Tuneable Consistency. Apache Cassandra ne dispose pas de transaction. L'écriture des données est très rapide comparée au monde des bases de données relationnelles.
  

Dans les applications du monde du Web, type Facebook par exemple, les données ne sont pas décrites de la même façon. L'utilisation des bases de données relationnelles n'est pas toujours appropriée. En effet cela conduirait à stocker des données avec de nombreuses valeurs nulles. C'est dans cet objectif que des modèles de données proches de celui de Cassandra ont été développés.

Par ailleurs, dans une base de données relationnelle classique, il est d'usage de normaliser les données afin d'éviter la redondance de celles-ci et les problèmes inhérents liés aux mises à jour. Les données sont ainsi structurées d'une certaine façon qui implique à la lecture de passer par des jointures pour obtenir les résultats souhaités. Apache Cassandra, du fait de son caractère décentralisé sur plusieurs machines, ne le permet pas. L'idée de faire une jointure sur plusieurs machines n'aurait alors aucun sens. Au contraire Apache Cassandra va vous obliger à dénormaliser un maximum. Ainsi, le gros du travail sur les données se fera pendant la phase d'écriture. Pour cela, les données sont alors regroupées dans des familles de colonnes (column families). Par conséquent, lors de la conception de votre base de données sur Apache Cassandra, vous aurez plus tendance à concevoir votre modèle de données en fonction des requêtes que vous souhaitez faire. La manière d'écrire des données se fera donc pour assurer une meilleure lecture.

Initialement basée sur Big Table de Google, Apache Cassandra stocke les données dans une suite triée de couples clé/valeur. On classifie ainsi Cassandra comme une base de données NoSQL orientée colonne, sans aller jusqu'au stockage physique en colonne.

Une colonne est la plus petite unité du modèle de données de Cassandra. C'est un triplet contenant un nom, une valeur et un timestamp. Ce dernier sert à déterminer la mise à jour la plus récente. La taille du nom peut atteindre jusqu'à 64 ko. La valeur, quant à elle, peut contenir 2 Go de données.

La valeur n'est pas obligatoire. Son omission peut conduire à une amélioration des performances. Le nom de la colonne peut être considéré comme une valeur.

La case valeur peut contenir plusieurs valeurs. C'est le cas, par exemple, d'une collection de chaînes de caractères.

Une colonne a un type appelé comparator. Une valeur a également un type appelé validator.

Une ligne est composée d'un ensemble de colonnes. Elle est identifiée par une clé. Une clé peut contenir jusqu'à 64 ko de données et jusqu'à deux milliards de colonnes. Il est possible d'utiliser des colonnes comme clé primaire.

Une famille de colonnes ou column family en anglais est un regroupement logique de lignes. Pour faire le parallèle avec le monde des bases de données relationnelles, une famille de colonnes est en quelque sorte une table.

Lors de la définition d'une famille de colonnes, vous pouvez y ajouter des informations concernant les métadonnées des colonnes. Ces informations peuvent être utilisées pour renseigner le nom et le type des colonnes. Toutefois c'est au moment de l'ajout d'une ligne que vous choisirez quelles sont les colonnes à exploiter.

C'est ainsi que Cassandra distingue deux types de famille de colonnes :

• statique : les colonnes sont définies lors de la création ou modification de la famille de colonnes ;
• dynamique : les colonnes sont définies lors de la création ou modification d'une ligne.

Le Keyspace est un regroupement de familles de colonnes. Il s'agit d'une sorte de schéma, si on compare au monde des bases de données relationnelles.

[Traduction de la FAQ officielle]

Les seeds (terme signifiant graine ou semence) sont utilisés durant le démarrage pour découvrir le cluster.
Si vous configurez certains nœuds comme des seeds, les nœuds de votre anneau auront tendance à envoyer plus souvent des messages de rumeurs à ces nœuds, plutôt qu’aux autres noeuds (voir ArchitectureGossip pour les détails). Autrement dit, les seeds jouent le rôle de concentrateur (hub) du réseau de rumeurs,ils permettent de propager plus rapidement aux autres nœuds les changement d’état d’un nœud.
Lors de leur démarrage initial (bootstrap), les nouveaux nœuds s’adressent aux seeds pour connaître les autres nœuds de l’anneau. Quand vous ajoutez un nouveau nœud dans l’anneau, vous devez spécifier au moins un seed actif à contacter. Une fois que le nœud a rejoint l’anneau, il aura connaissance des autres nœuds, il n’y a donc plus besoin de seed au prochain redémarrage.
Les versions récentes de Cassandra conservent la topologie en cluster, qui rend les seeds moins importants qu’ils ne l’étaient à l’époque des versions 0.6.X, dans lesquelles ils étaient utilisés à chaque démarrage.
Vous pouvez faire d’un nœud un seed à n’importe quel moment. Les nœuds seed n’ont rien de spécial. Si vous mettez un nœud dans la liste des seeds, ce sera un seed, rien de plus.
Les seeds ne sont pas en bootstrap automatique (autrement dit, si un nœud figure dans sa propre liste de seeds, il ne transférera pas de données à lui-même). Si vous désirez ce comportement, faites d’abord le démarrage initial du nœud, puis ajoutez-le seulement ensuite à la liste des seeds. Si vous n'avez pas de données (nouvelle installation), vous n'avez pas du tout à vous soucier de bootstrap ou d’autobootstrap.
Recommandations sur les seeds :

• choisissez au moins deux nœuds seed par data center ;
• synchronisez la liste des seeds avec tous les nœuds.
  

[Traduction de la FAQ officielle]

Cassandra écrit d’abord sur les CommitLog, puis sur une structure appelée Memtable. Quand la Memtable est pleine, elle est recopiée sur le disque dans une SSTable.
Pour plus d’information, voir MemtableSSTable.

[Traduction de la FAQ officielle]

Voir http://planetcassandra.org/Company/V...?IndustryId=-1.

[Traduction de la FAQ officielle]

Envoyer un email à : user-unsubscribe@cassandra.apache.org.