Lorsque vous sélectionnez des bases de données pour votre dernier cas d’utilisation (ou que vous en remplacez une qui ne répond pas à vos besoins actuels), la bonne nouvelle ces jours-ci est que vous avez le choix entre de nombreuses options. Bien sûr, c’est aussi la mauvaise nouvelle. Vous avez beaucoup à trier.
Il existe bien plus de bases de données à considérer et à comparer que jamais auparavant. En décembre 2012, à la fin de la première année, DB-Engines.com a commencé à classer les bases de données, ils avaient une liste de 73 systèmes (en hausse significative par rapport aux 18 avec lesquels ils avaient commencé leur liste). En décembre 2022, ils étaient à peine 400 systèmes. Cela représente une explosion cambrienne des technologies de base de données au cours de la dernière décennie. Il existe une vaste mer d’options pour naviguer : SQL, NoSQL et un mélange de bases de données « multi-modèles » qui peuvent être un mélange de SQL et de NoSQL, ou plusieurs modèles de données de NoSQL (combinant deux options ou plus : document, clé-valeur, colonne large, graphique, etc.).
De plus, les utilisateurs ne doivent pas confondre carrément popularité avec aptitude à leur cas d’utilisation. Bien que les effets de réseau aient certainement des avantages (« On ne peut pas se tromper avec X si tout le monde l’utilise »), ils peuvent également conduire à une pensée de groupe, à une innovation étouffante et à la concurrence.
Mon collègue Arthur Pesa et moi avons récemment passé en revue cinq facteurs que les utilisateurs doivent garder au premier plan lors de la présélection et de la comparaison des bases de données.
Les cinq facteurs
Passons directement à la liste.
- Architecture logicielle — La base de données utilise-t-elle les structures de données les plus efficaces, des modèles de données flexibles et des langages de requête riches pour prendre en charge vos charges de travail et vos modèles de requête ?
- Utilisation du matériel — Peut-il tirer pleinement parti des plates-formes matérielles modernes ? Ou laisserez-vous une quantité importante de cycles CPU sous-utilisés ?
- Interopérabilité — Est-il facile de s’intégrer dans votre environnement de développement ? Prend-il en charge vos langages de programmation, vos frameworks et vos projets ? A-t-il été conçu pour s’intégrer à votre architecture de microservices et de diffusion d’événements ?
- RÂPE — Possède-t-il les qualités nécessaires de Fiabilité, Disponibilité, Évolutivité, Facilité de maintenance et, bien sûr, Performance ?
- Déploiement — Cette base de données fonctionne-t-elle uniquement dans un environnement limité, tel que uniquement sur site, ou uniquement dans un seul centre de données ou un seul fournisseur de cloud ? Ou se prête-t-il à être déployé exactement où et comme vous le souhaitez dans le monde ?
Une telle répartition est subjective. Vous pouvez avoir votre propre liste de 4 facteurs, ou 12, ou 20, ou 100 critères. Et, bien sûr, chacun de ces facteurs, comme l’architecture logicielle, se décompose en sous-catégories, telles que « moteur de stockage », « architecture de traitement distribué » et même « langage de requête ». Mais c’est ainsi que je les diviserais en catégories générales.
Architecture logicielle
La considération essentielle ici est « La base de données utilise-t-elle les structures de données les plus efficaces, les modèles de données flexibles et les langages de requête riches pour prendre en charge vos charges de travail et modèles de requête spécifiques ? »
Charge de travail — Avez-vous besoin d’une charge de travail transactionnelle lourde en écriture ou mixte en lecture-écriture ? Ou allez-vous faire une charge de travail analytique principalement lue ? Avez-vous besoin d’une charge de travail hybride avec un mélange de transactions et d’analyses ? Cette charge de travail est-elle en temps réel, par lots ou mixte ? S’agit-il d’un flux constant d’événements par seconde, ou y a-t-il des hausses et des baisses intrajournalières régulières et prévisibles ? Ou peut-être avez-vous besoin de planifier pour faire face aux chocs stochastiques des pics de trafic soudains (par exemple, les dernières nouvelles ou toute autre popularité soudaine d’un disque) ?
Modèle de données — Avez-vous affaire à des paires clé-valeur ? Magasins de colonnes larges (données « clé-clé-valeur » basées sur des lignes) ? Un magasin de colonnes (données en colonnes) ? Document? Graphique? SGBDR (avec tables et JOIN) ? Ou tout à fait autre chose. Avez-vous vraiment le temps et le besoin de créer des données entièrement normalisées, ou allez-vous absorber tellement de données non structurées si rapidement que la normalisation est une course folle, et vous seriez mieux servi avec un modèle de données dénormalisé pour commencer ? Il n’y a pas de « bonne » réponse singulière ici. « Cela dépend » devrait être adopté comme votre mantra.
Langage de requête — Ici, il y a certainement plus de biais. Parce que même si votre équipe d’ingénierie de données peut être en mesure de masquer ou de masquer le modèle de requête back-end, nombre de vos utilisateurs ont leurs propres préjugés et préférences. C’est l’une des principales raisons pour lesquelles SQL reste un tel verrou. Dans le même temps, de nouveaux langages de requête sont disponibles. Certains sont de type SQL, comme le langage de requête Cassandra (CQL) utilisé par Cassandra et ScyllaDB. Il a une familiarité passagère pour les utilisateurs de SQL. Mais ne vous y trompez pas – il n’y a pas de JOIN de table ! Ensuite, il existe une série de nouveaux langages de requête scolaire qui peuvent utiliser, par exemple JSON. C’est ainsi que fonctionnent les requêtes Amazon DynamoDB. Encore une fois, ici, ScyllaDB prend en charge un tel modèle de requête JSON à l’aide de notre interface Alternator, qui est compatible avec DynamoDB. Quelle que soit votre orientation, le langage de requête ne doit pas être une réflexion après coup dans votre réflexion.
Transactions / Opérations / CAP – Qu’est-ce qui est le plus important pour toi? Transactions ACID entièrement cohérentes ? Ou des opérations CRUD de base hautement performantes et hautement disponibles ? Le théorème CAP dit que vous pouvez avoir n’importe lequel de ces trois éléments : cohérence, disponibilité ou tolérance de partition. Considérant que les bases de données distribuées doivent toujours être tolérantes aux partitions, cela vous laisse le choix entre des systèmes orientés cohérence en mode « CP » ou des systèmes orientés disponibilité en mode « AP ». Et dans ces modes, il y a des détails de mise en œuvre à prendre en compte. Par exemple, la façon dont vous obtenez une cohérence forte au sein d’un système distribué peut varier considérablement. Considérez même le choix de divers algorithmes de consensus pour assurer la linéarisabilité, comme Paxos, Raft, Zookeeper (ZAB), etc. Outre les différents algorithmes, chaque implémentation peut varier considérablement d’une autre.
Diffusion des données — Quand vous dites « système distribué », que voulez-vous dire exactement ? Parlons-nous d’un cluster local à centre de données unique ? Ou parlons-nous de clustering multi-centres de données ? Comment se produisent les mises à jour inter-clusters ? Est-il considéré comme un seul cluster logique ou nécessite-t-il des synchronisations inter-cluster ? Comment gère-t-il la localisation des données et, par exemple, la conformité au RGPD ?
Utilisation du matériel
Nous sommes au milieu d’une révolution en cours dans le matériel sous-jacent qui continue de repousser les limites du logiciel. De nombreuses applications logicielles, et de nombreuses bases de données en particulier, sont encore enracinées dans des origines, des conceptions et des présomptions vieilles de plusieurs décennies.
Utilisation/efficacité du processeur — On dit que beaucoup de logiciels fonctionnent mal si l’utilisation du processeur dépasse, disons, 40 % ou 50 %. Cela signifie que vous êtes censé exécuter ce logiciel de manière inefficace, laissant la moitié de votre boîte sous-utilisée régulièrement. En effet, vous payez deux fois l’infrastructure (ou plus) dont vous avez réellement besoin. Il vous incombe donc d’examiner la manière dont votre système gère le traitement distribué.
Utilisation/Efficacité de la RAM — Votre base de données est-elle constamment liée à la mémoire ? Sa mise en cache est-elle trop agressive ou trop gonflée (comme avoir plusieurs couches de mise en cache), gardant les données inutiles en mémoire ? Comment optimise-t-il ses chemins de lecture et d’écriture ?
Utilisation/Efficacité du stockage — Quel format de stockage votre base de données utilise-t-elle ? A-t-il des tables mutables compactes qui peuvent nécessiter des mécanismes de verrouillage de fichiers lourds ? Ou utilise-t-il des tables immuables qui peuvent produire des écritures rapides, mais qui ont un coût d’espace et d’amplification de lecture ? Permet-il un stockage hiérarchisé ? Comment gère-t-il la concurrence ? Les fichiers sont-ils stockés en ligne (bon pour les cas d’utilisation transactionnels) ou en colonne (bon pour l’analyse de données très répétitives) ? Notez qu’il n’y a pas qu’une seule « bonne » réponse. Chaque solution est optimisée pour différents cas d’utilisation.
Utilisation/Efficacité du réseau — Ici, vous devez penser à la fois à l’efficacité des communications du cluster client-serveur, ainsi qu’aux communications intra-cluster. Les modèles client/serveur peuvent être rendus plus efficaces grâce à la concurrence, au regroupement de connexions, etc. Les communications intra-cluster vont du bavardage opérationnel/transactionnel typique (réplication des données dans une mise à jour ou une écriture), ainsi que des tâches administratives telles que le streaming et l’équilibrage des données entre les nœuds lors d’un changement de topologie.
Interopérabilité
Aucune base de données n’est une île. Est-il facile à intégrer dans votre environnement de développement ? Prend-il en charge vos langages de programmation, vos frameworks et vos projets ? A-t-il été conçu pour s’intégrer à votre architecture de microservices et de diffusion d’événements ?
Langages de programmation / Frameworks — À plusieurs reprises, vous entendez « Nous sommes un X boutique », où X représente votre langage ou cadre de programmation préféré. Si votre base de données ne dispose pas du client, du SDK, de la bibliothèque, de l’ORM et/ou d’autres packages requis pour l’intégrer dans ce langage, il se peut qu’il n’existe pas. Pour être juste, l’explosion massive des bases de données est concomitante à l’explosion massive des langages de programmation. Pourtant, il est avantageux d’examiner la prise en charge du langage de programmation pour le client. Notez que c’est ne pas identique au langage dans lequel la base de données peut être écrite (ce qui peut être pris en compte dans son architecture logicielle et son efficacité). Il s’agit uniquement des langues dans lesquelles vous pouvez écrire des applications pour vous connecter à cette base de données principale.
Diffusion d’événements/mise en file d’attente de messages — Les bases de données peuvent être une source unique de vérité, mais ce ne sont pas les seuls systèmes en cours d’exécution dans votre entreprise. En fait, vous pouvez avoir différentes bases de données qui effectuent toutes des transactions, analysent et partagent différentes tranches de l’espace global de données et d’informations de votre entreprise. Le streaming d’événements est le média de plus en plus courant pour les entreprises modernes afin d’éviter les silos de données, et de nos jours, votre base de données n’est aussi bonne que son intégration avec les technologies de streaming d’événements en temps réel et de mise en file d’attente de messages. Votre base de données peut-elle servir à la fois de puits et de source de données ? A-t-il Change Data Capture (CDC) ? Se connecte-t-il à vos technologies préférées de diffusion d’événements et de mise en file d’attente de messages telles qu’Apache Kafka, Apache Pulsar ou RabbitMQ ?
Apis – Pour…