Une technologie intelligente pour une industrie manufacturière forte avec une production ininterrompue 24h/24 et 7j/7 de solutions IIoT pour les entreprises.
Tous les cas d’usage ne nécessitent pas la même approche. Dans ce blog, nous présentons un aperçu de certains critères à prendre en compte lors du choix d’une ou plusieurs bases de données. Nous abordons également le théorème CAP comme outil pour guider les discussions sur la cohérence versus la disponibilité pour une base de données particulière.
Pour avoir un aperçu de la vaste gamme de types de bases de données existants, lisez notre blog sur << le paysage NoSQL >>.
Même pour nos propres produits et applications, nous n’utilisons pas une seule base de données. La conception pour la résilience, la performance et la scalabilité est au cœur de nos solutions. Chez sAInce.io, nous choisissons également la base de données adaptée à chaque cas d’usage.
Quels critères sont importants lors de la sélection d’un système de base de données particulier ou de plusieurs systèmes pour différents cas d’usage?
Les RDBMS sont excellents. Une base de données relationnelle est auto-descriptive. Le schéma de la base de données peut être défini avec ses relations et contraintes entre lignes et tables.
Nous pouvons nous appuyer sur la fonctionnalité de la base relationnelle (et non sur le code applicatif) pour faire respecter le schéma et préserver l’intégrité référentielle des données au sein de la base.
Et la plupart d’entre elles montent bien en puissance verticale. Cependant, il existe une limite : il est impossible de scaler horizontalement, seulement verticalement. Donc, si vous avez besoin d’une scalabilité illimitée et que vous construisez une application pour la croissance, vous aurez besoin de scalabilité horizontale à un moment donné.
Des fournisseurs comme Oracle et IBM ont fourni d’énormes efforts la dernière décennie pour faire évoluer leurs RDBMS sur du matériel haute performance et verticalement scalable, comme Oracle EXADATA et IBM Pure Analytics (anciennement Netezza). Cependant, si vous vouliez scaler, il fallait acheter un appliance matériel plus puissant. La scalabilité n’est donc pas une fonctionnalité plug-in.
Avec le scaling horizontal, vous ajoutez de nouveaux nœuds au cluster de machines qui exécutent votre système de base de données et vous montez en puissance en conséquence. Plus de puissance, plus de mémoire, plus d’espace disque. En quelques clics, c’est fait (si c’est basé sur le cloud).
Souhaitons-nous que nos données soient disponibles 24h/24 et 7j/7, quoi qu’il arrive ? Dans ce cas, nous avons besoin d’un système de base de données capable de se répliquer entre différents sites physiques et pouvant basculer en une seconde d’un master à un autre master.
Ou tolérons-nous une certaine indisponibilité ? Dans ce cas, un système master/esclave pourrait être suffisant pour la tâche.
La cohérence est l’un des éléments clés de la conformité ACID. ACID signifie Atomic, Consistent, Isolated et Durable.
ACID vise à garantir la validité des données malgré les erreurs, les pannes électriques et autres défauts. Dans le contexte des bases de données, une séquence d’opérations qui respecte les propriétés ACID (perçue comme une seule opération logique sur les données) s’appelle une transaction.
Atomicité garantit que chaque transaction est traitée comme une unité unique : elle réussit complètement ou échoue complètement.
Cohérence signifie qu’une transaction ne peut amener la base de données que d’un état valide à un autre. Toutes les contraintes et relations implémentées par la base de données sont respectées, ce qui empêche la corruption des données par une transaction illégale.
Isolation assure que l’exécution simultanée de transactions laisse la base de données dans le même état que si elles avaient été exécutées séquentiellement. L’isolation est l’objectif principal du contrôle de concurrence.
Durabilité garantit qu’une fois qu’une transaction est validée (commit), elle reste validée même en cas de panne système.
Imaginez un scénario avec un serveur de base de données en Europe et un autre aux États-Unis, tous deux synchronisés. Les utilisateurs en Europe utilisent le serveur européen, et ceux aux États-Unis le serveur américain.
Mais supposons qu’il y ait une panne de communication entre les deux serveurs. Veut-on garantir la cohérence des données ? Refusons-nous les mises à jour sur les deux systèmes afin que toutes les données restent cohérentes ? Ou utilisons-nous l’un des systèmes comme source de vérité (le master) et dirigeons-nous tous les utilisateurs vers ce système ? Les utilisateurs peuvent continuer à lire et écrire, mais lorsque la communication est rétablie, les deux systèmes devront être resynchronisés. Les deux systèmes seront ainsi finalement cohérents.
Ou sacrifions-nous la cohérence et laissons les deux systèmes fonctionner, appliquer les mises à jour et essayons de fusionner les mises à jour plus tard lorsque la communication est rétablie ?
Une logique similaire s’applique aux données distribuées : les bases NoSQL peuvent distribuer et répliquer les données entre différents nœuds. Comment gérer la cohérence ? Attendons-nous que tous les nœuds confirment la transaction ou appliquons-nous un certain quorum ?
Avons-nous besoin de cohérence immédiate ou de cohérence éventuelle ? Dans de nombreux cas d’usage, la cohérence éventuelle est suffisante.
Par exemple, Amazon DynamoDB, un key-value store bien connu, fournit par défaut une cohérence éventuelle pour les lectures et écritures, sacrifiant ainsi la cohérence au profit de la disponibilité.
Cependant, il est possible de choisir des lectures fortement cohérentes (pas les écritures – les écritures restent toujours eventually consistent dans DynamoDB), au détriment de la disponibilité. Les lectures fortement cohérentes renverront une erreur en cas de retard réseau ou de panne si la lecture échoue.
Dans Cassandra, un célèbre wide-column store, il est possible de configurer complètement la gestion de la cohérence : cela dépend du niveau de cohérence choisi et du nombre de réplicas dans le cluster. Par défaut, Cassandra sacrifie également la cohérence au profit de la disponibilité : si le système écrit les données sur un seul replica, la transaction est considérée comme terminée. Il est cependant possible de choisir une cohérence plus forte et de sacrifier la disponibilité en exigeant que tous les nœuds réplicas d’une partition confirment l’écriture avant de valider la transaction. Cassandra offre ainsi un large spectre de niveaux de cohérence intermédiaires en ajustant la configuration de cohérence.
Dans certains cas, nous ne voulons pas être limités par un schéma strict et nous souhaitons être flexibles dans la structure de nos données. Dans ce cas, nous aimons probablement JSON (JavaScript Object Notation) et nous voulons utiliser un système de base de données capable de stocker nativement des objets JSON. Peut-être souhaitons-nous que le système respecte un certain schéma JSON lors des requêtes, etc.
Mais nous voulons cette flexibilité de pouvoir stocker nos données dans n’importe quelle structure que nous voulons.
Les object stores (également appelés stores orientés document) offrent cette fonctionnalité. Exemples : MongoDB et CosmosDB.
Ou peut-être voulons-nous un système capable de nous fournir un schéma strict comme dans le monde RDBMS, tout en offrant une certaine flexibilité pour contourner ce schéma strict. Dans ce cas, nous opterions pour un DBMS hybride comme PostgreSQL. PostgreSQL est relationnel dans son cœur, mais offre des fonctionnalités très puissantes qui étendent le cœur relationnel, par exemple avec le support JSON.
Les temps où les utilisateurs acceptaient un délai de plus de 10 secondes avant qu’un système ne réponde sont révolus. Aujourd’hui, nous voulons un accès rapide aux données et/ou une ingestion rapide des données. Selon le cas d’usage, nous choisirons un système de base de données plutôt qu’un autre.
Dans certains cas, nous avons besoin de temps de réponse en microsecondes, ce qui ne peut être atteint uniquement par des opérations d’entrée/sortie sur disque. Dans ces cas, nous avons besoin d’une base de données en mémoire qui fournit des ensembles de données que nous pouvons exploiter via un stockage intensif en RAM.
Quel type de données allons-nous stocker ? Les données temporelles ont des exigences différentes des données de nomenclature, des données clients, etc.
Les données IoT en séries temporelles ne nécessitent généralement pas de mises à jour, mais un enregistrement et un accès rapides. Si nous devions capturer toutes les relations de nos amis Facebook et leurs connexions, nous aurions également des exigences différentes. Nous voulons pouvoir naviguer rapidement d’un nœud à l’autre, et ce, parmi tous nos amis potentiels dans le monde !
Le type de données que nous souhaitons stocker et le type de requêtes que nous devons fournir sur ces données auront donc un impact sur notre choix de base de données.
Souhaitons-nous externaliser la maintenance et le support de nos bases de données à une entreprise externe ? Allons-nous fournir notre propre infrastructure sur site ou héberger le système sur une infrastructure cloud ?
La prise en charge des systèmes de base de données sur site entraîne également des coûts : formation de nos employés IT, coûts matériels purs, licences, etc.
Il en va de même si nous voulons monter en puissance sur site. Nous devons étendre l’infrastructure et configurer nos systèmes de base de données pour augmenter dynamiquement leur capacité. Cela contraste avec l’infrastructure cloud, où l’extension prend quelques minutes et se fait sans aucune interruption.
Le théorème CAP, une théorie en technologie informatique développée à l’origine par Eric Brewer, stipule qu’un système informatique distribué ne peut pas garantir simultanément l’état optimal des trois critères suivants :
Cohérence (Consistency)
Disponibilité (Availability)
Tolérance aux partitions (Partition Tolerance)
Une cohérence optimale signifie que le système possède à tout moment le même état. Ainsi, tous les clients ont la même vue sur le même état en tout temps. Chaque lecture reçoit donc la dernière écriture ou une erreur.
Une disponibilité optimale signifie que le système existe et que les mises à jour peuvent être effectuées à tout moment. Il n’y a donc aucune interruption. Chaque requête reçoit une réponse (non erronée), sans garantie qu’elle contienne la dernière écriture.
Une tolérance aux partitions optimale signifie que si un système est composé de n parties (également appelées partitions), il continue de fonctionner en n parties si la communication entre elles est interrompue. Le système continue de fonctionner malgré un nombre arbitraire de messages perdus (ou retardés) par le réseau entre les nœuds.
Le théorème CAP implique qu’en présence d’une partition réseau, il faut choisir entre cohérence et disponibilité.
Ainsi, lorsqu’une panne de partition réseau survient, doit-on :
Annuler l’opération et ainsi réduire la disponibilité tout en assurant la cohérence
Poursuivre l’opération et ainsi garantir la disponibilité mais prendre le risque d’incohérence
Parfois, le théorème CAP est utilisé pour montrer comment les solutions de bases de données se positionnent par rapport à ce triangle. Cela peut être un peu trompeur, car la plupart des systèmes de base de données ont en réalité différentes configurations permettant de sacrifier soit la disponibilité, soit la cohérence.
Dans l’image ci-dessous, nous positionnons les différentes configurations de cohérence applicables à DynamoDB, comme mentionné précédemment. Dans ce contexte, le théorème CAP a cependant beaucoup de valeur.
Le triangle CAP est donc un outil intéressant pour comprendre les différentes configurations possibles pour un système de base de données particulier.
Revisons le tableau que nous avions utilisé dans un précédent blog sur les bases de données NoSQL et étendons-le avec quelques exemples de cas d’utilisation applicables. Vous pouvez utiliser ce tableau comme une sorte de guide général.
Cependant, comme mentionné précédemment, chaque cas d’utilisation doit être traité en tenant compte de ses exigences spécifiques. Complétez le tableau ci-dessous avec les critères de sélection mentionnés ci-dessus et vous aurez une approche bien fondée pour commencer à sélectionner la base de données adaptée à vos besoins.
