Pour plus d’informations sur la persistance dans Cassandra et d’autres bases de données NoSQL, consultez Qu’est-ce que NoSQL ?
Comprendre la signification de la persistance est important pour évaluer différents systèmes de stockage de données. Compte tenu de l’importance du stockage de données dans la plupart des applications modernes, faire un choix mal informé pourrait entraîner des temps d’arrêt importants ou une perte de données. Dans cet article, nous discuterons des approches de conception de persistance et de stockage de données et fournirons quelques informations sur celles-ci dans le contexte de Cassandra.
La persistance est « la continuation d’un effet après l’élimination de sa cause ». Dans le contexte du stockage de données dans un système informatique, cela signifie que les données survivent une fois le processus avec lequel elles ont été créées terminé. En d’autres termes, pour qu’un magasin de données soit considéré comme persistant, il doit écrire dans un stockage non volatil.
Si vous avez besoin de persistance dans votre magasin de données, vous devez également comprendre les approches de conception à quatre personnes qu’un magasin de données peut adopter et comment (ou si) ces conceptions fournissent de la persistance:
-
Pure en mémoire, pas de persistance du tout, comme les memcaches ou les Scalaris
-
En mémoire avec des instantanés périodiques, tels que Oracle Coherence ou Redis
-
Basé sur disque avec des écritures de mise à jour sur place, telles que MySQL ISAM ou MongoDB
-
Basé sur Commitlog, comme toutes les bases de données OLTP traditionnelles (Oracle, SQL Server, etc.)
Les approches en mémoire peuvent atteindre une vitesse fulgurante, mais au prix d’être limitées à un ensemble de données relativement petit. La plupart des charges de travail ont un sous-ensemble « chaud » (actif) relativement petit de leurs données totales; les systèmes qui nécessitent que l’ensemble de données entier tienne en mémoire plutôt que la partie active conviennent bien aux caches mais conviennent mal à la plupart des autres applications. Étant donné que les données sont uniquement en mémoire, elles ne survivront pas à la fin du processus. Par conséquent, ces types de magasins de données ne sont pas considérés comme persistants.
Le moyen le plus simple d’ajouter de la persistance à un système en mémoire consiste à effectuer des instantanés périodiques sur le disque à un intervalle configurable. Ainsi, vous pouvez perdre jusqu’à la valeur des mises à jour de cet intervalle.
Les systèmes de mise à jour sur place et basés sur commitlog stockent immédiatement dans la mémoire non volatile, mais seule la persistance basée sur commitlog offre une durabilité – le D dans ACID – à chaque écriture persistante avant que le succès ne soit renvoyé au client.
Cassandra implémente une conception de persistance basée sur le journal de validation, mais fournit en même temps des niveaux de durabilité accordables. Cela vous permet de décider quel est le bon compromis entre sécurité et performance. Vous pouvez choisir, pour chaque opération d’écriture, d’attendre que cette mise à jour soit mise en mémoire tampon, écrite sur disque sur une seule machine, écrite sur disque sur plusieurs machines ou même écrite sur disque sur plusieurs machines dans différents centres de données. Ou, vous pouvez choisir d’accepter les écritures le plus rapidement possible, en accusant réception immédiatement avant même qu’elles ne soient complètement désérialisées du réseau.
Au bout du compte, vous êtes le seul à savoir quel est le bon compromis performance / durabilité pour vos données. Prendre une décision éclairée sur les technologies de stockage de données est essentiel pour résoudre ce compromis selon vos conditions. Parce que Cassandra offre une telle facilité d’accord, c’est un choix logique pour les systèmes ayant besoin d’un magasin de données durable et performant.