Databases for Cassandra

De son nom complet Apache Cassandra, ce système de gestion de bases de données (SGBD) NoSQL open source stocke les données sous forme de clé-valeur. De plus, il stocke et manipule les données pour les restructurer. Cassandra possède son propre langage pour effectuer des requêtes : le Cassandra Query Language (CQL). Ce dernier fonctionne sur l’ensemble des systèmes d’exploitation, ce qui en fait une solution flexible.

Ce service est une DBaaS (Database-as-a-Service). Réparti entre plusieurs de nos instances Public Cloud, il est fourni comme un service clés en main. Il vous facilite le travail, car nous nous occupons de sa gestion et de son administration (configuration, maintenance, sauvegarde, sécurité et évolutivité). En résumé, il s’agit d’un service de bases de données cloud qui vous fait gagner du temps.

C’est possible une fois que vous avez téléchargé et déployé la dernière version du JDK Java. Cependant, vous devrez effectuer toutes les missions de gestion et d’administration de vos bases de données. Vous ne bénéficierez donc pas des fonctionnalités que nous fournissons dans notre service clés en main.

Initialement déployé par un grand nom de l’industrie IT, puis portée depuis 2008 par la fondation Apache, Cassandra est désormais le second moteur le plus utilisé au monde selon les derniers recensements. Ce phénomène s’explique par l’accent mis sur la performance et la haute disponibilité, avec un mode distribué permettant de minimiser, voire de supprimer, les Single Points of Failure (SPOF).

Cassandra est une base de données NoSQL. Elle est conçue pour gérer de grandes quantités de données réparties sur plusieurs serveurs sans point de défaillance unique.

Cassandra est utilisé pour des applications nécessitant une grande évolutivité et une haute disponibilité sans compromettre la performance en lecture et écriture. Cette solution est idéale pour les applications de télémétrie, les systèmes de gestion de données de médias sociaux, les services de messagerie et les scénarios où la vitesse et la fiabilité des opérations de données sont critiques.

Ces deux moteurs de bases de données proposent des avantages différents, bien que tous les deux fassent partie des bases de données NoSQL. L’une des différences réside dans le langage utilisé pour les requêtes. MongoDB repose sur une syntaxe proche du JavaScript, tandis que Cassandra est plus singulier, avec l’utilisation du CQL qui lui est propre.

On note également une différence dans la gestion de la redondance d’un cluster : MongoDB possède toujours un serveur maître et des serveurs secondaires prêts à prendre le relais, tandis que Cassandra utilise un modèle différent qui s’appuie sur de multiples nœuds maîtres au sein du même cluster.

Chacune représente un pack Cassandra précis sur Public Cloud et comprend des fonctionnalités variables qui répondent à des applications différentes. Celles-ci peuvent concerner la taille du cluster, le nombre de nœuds dans le cluster, le réseau, l’évolutivité ou encore la haute disponibilité.

Non. Votre service dispose d’une ou plusieurs instances Public Cloud qui l’exécutent et qui sont dotées d’un espace de stockage dédié individuel. De cette manière, vous seul contrôlez vos données.

C’est possible. En effet, s’il s’avère que vos besoins en matière de RAM ou d’espace de stockage augmentent, vous pouvez choisir des nœuds avec une plus grande capacité. Sachez cependant qu’il n’est pas possible de revenir à un nœud de capacité inférieure.

Oui. Nous fournissons une sauvegarde automatisée pour chaque offre. Cependant, les politiques de conservation par défaut diffèrent selon la formule choisie. Nous vous conseillons donc d’étudier l’ensemble de nos offres avant d’arrêter votre choix.

Nous effectuons toutes les missions de gestion et d’administration de la base de données pour vous. Ainsi, vous n’avez pas à vous soucier de la mise en place, de la maintenance, de la sécurité, de la sauvegarde ni de l’évolutivité. C’est ce service managé que nous facturons pour vous éviter ces contraintes.

Oui. Vous pouvez connecter votre base de données à votre serveur via un réseau public ou privé. Toutefois, vous devrez le faire vous-même et vous devrez également gérer et administrer votre base de données par vos propres moyens.

Découvrez la résilience des déploiements dans notre guide dédié.

Les régions 1-AZ utilisent une zone de disponibilité unique avec un ou plusieurs centres de données. Même si elles offrent une protection contre les pannes de serveurs et de pilotes, elles peuvent être vulnérables aux pannes de centres de données. Cela peut affecter l’accès en cas de défaillance du centre de données d’hébergement.

En comparaison, les régions 3-AZ se composent de 3 zones de disponibilité indépendantes, chacune isolée en matière d’alimentation, de refroidissement et de réseau, offrant ainsi une véritable isolation des pannes. Cette architecture permet la disponibilité du service même en cas de panne d’une zone entière.

Gardez l’esprit tranquille grâce à des engagements de niveau de service (Accord de niveau de service (SLA)) de 99,99 %.

Oui ! La migration est tout à fait possible d’une région 1-AZ vers une région 3-AZ.

Vous pouvez connecter des régions 1-AZ à des régions 3-AZ via une connectivité privée afin d’optimiser la complexité et le coût de vos déploiements d’infrastructure.