[English version here]

Vous avez donc une grande idée qui va changer le monde. Comme toute entreprise, startup ou non, vous avez besoin de stocker des données. Heureusement, vous avez l'embarras du choix pour votre base de données... Heureusement ? Pas si sûr ! Avec tous ces choix, comment décider du type de base de données dont vous avez besoin ?

Voici un bref rappel des différents types de bases de données disponibles.

RDBMS, ou Base de données relationnelles, ont une longue histoire et sont très largement utilisées. Elles ont été conçues pour optimiser le stockage des données et pour offrir un contrôle sur vos données, pensez à des concepts comme les clés étrangères, les types et la cohérence.

NoSQL, abréviation de "Not only SQL" (pas seulement SQL), est un terme utilisé pour les systèmes de base de données qui stockent les informations dans une variété de formats afin de répondre aux exigences d'échelle que les bases de données relationnelles traditionnelles ont du mal à satisfaire.

Si les bases NoSQL ont pu résoudre le problème de scalabilité, elles ont aussi fait l’impasse sur tous les concepts de cohérence des données, comme les clés étrangères, les transactions ACID, et la garantie de format. De nos jours, certains moteurs proposent des transactions multi-documents, mais les niveaux d’isolation et les garanties réelles apportées sont un autre sujet !

La dernière option est celle des bases de données SQL Distribué. Le SQL distribué est conçu pour offrir la cohérence, les transactions ACID et l'évolutivité. Toutes les bases de données SQL distribuées ne sont pas égales. Nombre d'entre elles reposent sur des moteurs Postgres ou MySQL en arrière-plan. L'utilisation de clés étrangères ou de transactions peut être compliquée, car le noyau travaille toujours avec des moteurs basés sur une base de données à nœud unique. CockroachDB a été construit dès le départ comme une base de données SQL distribuée.

Explorons ces options.

RDBMS

Les bases de données relationnelles sont bien connues et tres largement utilisées avec nombre d’offres. On y trouve principalement Oracle, SQL Server, MySQL et Postgres par exemple.

Il est simple de trouver une librairie pour utiliser ces dernières quelque soit le langage de programmation utilisé. De plus, nombre de standard sont présents pour aider à la définition du schéma, des migrations ou de la bonne utilisation des données.

Le problème se pose à l'échelle. Ces bases de données ont été conçues pour fonctionner sur un seul nœud. Les données relationnelles sont liées par des définitions de clés étrangères, les transactions sont des verrous sur l'accès aux données. Tout cela fonctionne bien sur un seul nœud, mais c'est une autre histoire de construire quelque chose d'évolutif.

Les solutions sont:

• Vertical scaling
• Sharding

Vertical scaling

La mise à l'échelle verticale consiste, en fait, à augmenter la taille de votre VM ou de votre hôte bare-metal. Plus de processeurs, plus de mémoire, plus de disques, etc. Cette solution est généralement facile lorsque la mise à niveau est suffisamment petite, par exemple passer de 4 vCPU à 8 vCPU.

C’est bien plus complexe et coûteux si l’on atteint des machines de 256 CPUs et 2Tb de RAM. Et cette méthode ne change rien au fait que l’on fonctionne sur un seul noeud pour les écritures. Pour résister aux pannes, il faudra, à minima, 2 machines identiques avec une réplication et un processus de bascule.

Sharding

Le sharding est pire! Il n’apporte pas de solutions en cas de panne d’un noeud principal, il faudra toujours dupliquer ce dernier, tout en apportant de la complexité. Diviser la base de données en parties plus petites semble être une bonne idée, mais cela augmente la complexité du développement et de la gestion.

Chaque shard deviendra un nœud unique de votre base de données, donc si vous voulez être en mesure d'utiliser des transactions et des clés étrangères, vous devez avoir toutes les données concernées dans le même shard. Vous devez également mettre en œuvre un basculement pour chaque shard.

NoSQL

Le NoSQL apporte aussi sont lots de solutions, mais il n’y a pas de standard particulier. Chaque solution s'accompagne de mises en œuvre et de compromis différents, mais elles utilisent généralement plusieurs nœuds pour diffuser les données. Par rapport aux bases de données relationnelles, vous n'avez rien à faire, il suffit de mettre en œuvre un cluster, et toutes les données n'ont pas besoin d'être répliquées sur chaque nœud.

Une conception commune est qu'une base de données NoSQL offrira une facilité de scalabilité et de performance (temps réel). Beaucoup d'entre elles fournissent différentes adaptation du SQL pour interagir avec vos données, ce qui aide les développeurs à réutiliser leurs connaissances.

De plus, elles sont conçues pour survivre aux pannes de nœuds, du moins à la panne d'un seul nœud. Les processus de réplication ne sont pas nécessairement synchrones, pensez pour la performance, mais les données sont répliquées entre les nœuds pour garantir que votre application puisse survivre aux défaillances de la base de données.

Mais le problème principal est que vous n'avez aucune sorte de relation entre les données. Le concept principal est souvent constitué de documents JSON stockés tels quels, tout comme les bases de données objet en leur temps.

Les relations entre les données sont définies par un document de lien ou un document imbriqué. Si votre cas d'utilisation nécessite de découpler le document, vous ne pourrez pas avoir une garantie d'exactitude entre vos données à moins que ce ne soit dans votre code. Vous ne pouvez pas vous fier à une quelconque définition de schéma.

L'autre aspect concerne les transactions. Les fournisseurs proposent des transactions, mais elles concernent principalement les versions de documents et ne sont pas Serializable.

La scalabilité et la performance offerte par les bases NoSQL sont des atouts incroyables, mais il faut souvent adapter son code pour utiliser la librairie de la solution retenue et faire des ajouts afin de garantir la cohérence.

SQL Distribué

Et notre dernier compétiteur, le SQL Distribué! Le SQL Distribué offre une scalabité simple tout en préservant la cohérence des données.

Cela ressemble un peu au meilleur des deux mondes. Et ça l’est, en quelque sorte.

Le SQL Distribué résout les problèmes de scalabité des bases de données relationnelles en adoptant les mécanismes du monde NoSQL tout en garantissant les types de données (le schéma), les transactions et la cohérence.

Le principal compromis ici est la vitesse. Comme les données doivent être répliquées entre les nœuds ET cohérentes, les lois physiques ne peuvent être transgressées. Il est clair que vous ne serez pas en mesure d'atteindre les performances d'une option NoSQL. Si vous comparez une base de données SQL à nœud unique à une base de données SQL distribuée, c'est à coup sûr la dernière qui sera la plus lente sur un faible volume de données.

Le bénéfice vient quand on cherche la cohérence, la qualité, la latence et la facilité de maintenance à l'échelle.

CockroachDB est la base SQL distribué la plus avancée sur le marché actuellement. Elle a été conçue dès le départ pour garantir la conformité ACID ET l'évolutivité. Il n'y a pas de sharding en arrière-plan, mais un véritable clustering de type NoSQL pour vous permettre de bénéficier de tous les avantages d'une base de données relationnelle tout en conservant la facilité d'évolution par simple ajout de noeuds.

Enfin, CockroachDB offre la possibilité de déployer des clusters multi-region (c'est-à-dire un cluster mondial). Les options NoSQL utilisent la réplication asynchrone pour répliquer les données entre l'Europe, les États-Unis et l'Asie-Pacifique. Avec CockroachDB, vous avez la possibilité d'utiliser un seul cluster et de survivre à tout type de panne sans compromettre la cohérence et la disponibilité.

Avec CockroachDB vous avez la possibilité de survivre à tous types de pannes, du noeud à un datacenter complet, sans compromettre la cohérence des données et la disponibilité des applications.

Vous pouvez en découvrir plus sur CockroachDB ici.

Bon alors, je prends quelle base pour mon projet?

Comme vous pouvez le constater, les choix dépendent des attentes à l'égard du produit. Vous attendez-vous à une augmentation considérable de la taille des ensembles de données ? Voulez-vous survivre facilement aux pannes sans casser vos applications ou avec des temps d'arrêt ?

Si vous pensez disposer d'un jeu de données dédié à un pays, avec un petit nombre d'utilisateurs, et d'une application pouvant subir des temps d'arrêt, la base de données relationnelle reste la meilleure solution et la plus simple.

Si vous ne recherchez qu'un temps de réponse inférieur à la milliseconde (c'est-à-dire semblable à celui d'un cache) ou des fonctionnalités spécifiques (recherche plein texte, par exemple), vous devriez vous tourner vers les solutions NoSQL. Vous trouverez certainement l'outil le mieux adapté à votre cas d'usage.

Sinon, CockroachDB est certainement votre meilleure option. Avec un scalabilité horizontale et la garantie de transactions ACID, c’est l’offre la plus simple à opérer et à intégrer en développement. Vous pouvez aussi profitez d’une offre managée avec  Cockroach Cloud, et vous lancez en 5 minutes avec un cluster serverless.