Comment sauvegarder les bases de données Cassandra (Cassandra databases)

Face à des données de plus en plus nombreuses, souvent non structurées, il est difficile de se contenter d’un stockage dans une base de données relationnelle classique avec une structure de table fixe. À mesure que les entreprises migrent leurs applications et leurs données vers le cloud, elles investissent dans le développement d’applications cloud natives, modernes, qui doivent être rapidement déployées. Ces applications ont besoin d’un data store agile, flexible et très performant. C’est là que les bases de données non relationnelles NoSQL (« pas seulement SQL »), telles qu’Apache Cassandra, entrent en scène.

Une base de données Cassandra est un ensemble de données à gros volume, particulièrement adapté à des scénarios d’entreprise tels que l’Internet des Objets (IdO) et la personnalisation. Cassandra utilise des données en familles de colonnes, semblables aux tables des bases de données relationnelles. Ces familles contiennent des colonnes et des lignes, chaque ligne ayant sa propre clé. Il est possible d’ajouter des colonnes à la volée et d’y accéder à l’aide du langage de requête Cassandra (CQL), dont la syntaxe est similaire à SQL. Cassandra étant une base de données non relationnelle, elle emploie des méthodes différentes de stockage et de récupération des données.

De même, les bases de données NoSQL nécessitent une solution de protection et de sauvegarde des données différente. Les méthodes de sauvegarde traditionnelles répondent aux exigences d’applications structurées, sur des bases de données relationnelles utilisant un stockage partagé. Elles ne sont pas capables de prendre en charge les exigences de sauvegarde ponctuelle des applications modernes adossées à des bases de données distribuées NoSQL telles que Cassandra.

Dans l’idéal, les entreprises qui déploient des applications NoSQL doivent mettre en place à la fois des solutions de sauvegarde et de réplication pour protéger correctement leurs données.

Exigences de sauvegarde d’une base de données Cassandra

S’il existe des outils de sauvegarde natifs, ils ne sont pas parfaitement adaptés aux variations architecturales des bases de données Cassandra. Voici certaines des principales exigences de sauvegarde et de reprise de Cassandra.

Exigence n°1 – Des sauvegardes ponctuelles. Les outils de sauvegarde de base de données natifs prennent des snapshots au niveau des nœuds, qui sont des sauvegardes locales. Mais cette méthode est sujette aux erreurs, et n’est pas évolutive. De plus, elle n’assure pas les sauvegardes ponctuelles dont vous aurez besoin pour restaurer vos activités en cas de perte de données.

Exigence n°2 – Une reprise à tout point dans le temps. Les entreprises doivent régulièrement mettre à jour leurs clusters de test et de développement à partir des dernières données de protection, et permettre ainsi l’intégration continue (CI) et le développement continu (CD). Ces clusters présentent diverses topologies, avec des nombres de nœuds différents des clusters de base de données de production. Il faut plusieurs heures, voire plusieurs jours pour mettre à jour chacun d’entre eux à l’aide de solutions natives, ce qui affecte la productivité des développeurs.

Exigence n°3 – Un masquage des données. Les outils natifs ne permettent pas de masquer des colonnes particulières lors de la récupération de données confidentielles. Cette lacune peut avoir une incidence négative pour les entreprises qui manipulent des données sensibles, par exemple les informations personnelles identifiables.

Exigence n°4 – Gestion des défaillances de nœuds pendant la sauvegarde et la reprise. Avec une solution native, en cas d’échec d’un nœud source pendant la sauvegarde, les opérations pour ce nœud sont interrompues, ce qui peut provoquer des pertes de données ou des incohérences dans un ensemble de données sauvegardées. Votre solution de sauvegarde de base de données doit fonctionner de manière optimale dans ce genre de situation.

Exigence n°5 – Prise en charge de la durée de vie (TTL) des données. Il n’est pas possible d’adapter la durée de vie des données pendant la restauration à l’aide d’une solution de sauvegarde native. Si cette durée de vie se termine durant ce laps de temps, les données restaurées sont automatiquement considérées comme expirées par Cassandra.

Exigence n°6 – Protection des données granulaires. Les solutions natives assurent essentiellement des sauvegardes au niveau de l’espace clé seulement, sans possibilité de les réaliser au niveau des familles de colonnes. Les familles de colonnes dans un espace clé donné seront donc sauvegardées à la même fréquence, avec la même règle de rétention. Même les familles de colonnes qui ne sont pas nécessaires seront sauvegardées si elles se trouvent dans le même espace clé.

Exigence n°7 – Stockage efficace des sauvegardes de base de données. Les solutions de stockage natives peuvent augmenter vos frais de stockage. Par exemple, toutes les copies de répliques sont conservées dans votre stockage de sauvegarde ; ces sauvegardes sont conservées sur des nœuds Cassandra ainsi que sur un système secondaire (à titre facultatif). De plus, les SSTables compactées et nouvellement générées (fichiers de données immuables que Cassandra utilise pour conserver des données sur disque) sont sauvegardées, en plus de la SSTable d’où elles proviennent. Toutes ces activités entraînent des coûts de stockage plus élevés sur les sauvegardes de bases de données.

Rubrik Mosaic pour les sauvegardes de base de données NoSQL

Rubrik Mosaic est un logiciel conçu spécifiquement pour résoudre les problématiques de sauvegarde et de reprise des bases de données NoSQL modernes et des systèmes de fichiers de mégadonnées. Il prend en compte, entre autres, les exigences de sauvegarde pour Apache Cassandra indiquées ici. 

Rubrik Mosaic :

• Assure des sauvegardes ponctuelles à intervalles personnalisés.

• Gère des flux de données parallèles vers un stockage secondaire. La cohérence des sauvegardes est garantie quelle que soit la taille du cluster Cassandra.

• S’appuie sur une technologie de déduplication sémantique brevetée pour réduire vos coûts de stockage cloud et on-premise jusqu’à 70 %.

• Automatise l’actualisation test/dév avec un niveau de granularité allant jusqu’à la famille de colonnes, tout en bénéficiant d’une mobilité entre plusieurs clouds. La topologie « any-to-any » permet de restaurer des données depuis/vers des clusters disparates.

• Assure une prise en charge avancée de la durée de vie des données.

Découvrez comment Rubrik peut protéger vos données Cassandra, et consultez notre livre blanc intitulé Guide définitif de la sauvegarde et de la reprise pour Cassandra.