Comment choisir la bonne base de données pour votre application

Choisir la «bonne» base de données peut souvent être essentiel au succès d'une application. Plutôt que de suivre les conseils des fournisseurs ou d'utiliser une base de données parce que vous l'avez déjà, il est utile de considérer l'objectif fondamental et les exigences du magasin de données.

Voici les questions les plus importantes à se poser lorsque vous choisissez une base de données:

  • Quelle quantité de données prévoyez-vous stocker lorsque l'application sera mature?
  • Combien d'utilisateurs prévoyez-vous gérer simultanément à la charge de pointe?
  • De quelle disponibilité, évolutivité, latence, débit et cohérence des données votre application a-t-elle besoin?
  • À quelle fréquence vos schémas de base de données changeront-ils?
  • Quelle est la répartition géographique de votre population d'utilisateurs?
  • Quelle est la «forme» naturelle de vos données?
  • Votre application nécessite-t-elle un traitement des transactions en ligne (OLTP), des requêtes analytiques (OLAP) ou les deux?
  • Quel rapport de lectures / écritures attendez-vous en production?
  • Avez-vous besoin de requêtes géographiques et / ou de requêtes en texte intégral?
  • Quels sont vos langages de programmation préférés?
  • Avez-vous un budget? Si oui, couvrira-t-il les licences et les contrats de support?
  • Existe-t-il des restrictions légales sur le stockage de vos données?

Développons ces questions et leurs implications.

Combien de données allez-vous stocker?

Si votre estimation est en gigaoctets ou moins, presque toutes les bases de données traiteront vos données et les bases de données en mémoire sont tout à fait réalisables. Il existe encore de nombreuses options de base de données pour gérer les données dans la plage de téraoctets (milliers de gigaoctets).

Si votre réponse est en pétaoctets (millions de gigaoctets) ou plus, seules quelques bases de données vous seront utiles, et vous devez être préparé à des coûts de stockage de données importants, soit en dépenses d'investissement pour le stockage sur site, soit en dépenses d'exploitation pour stockage en ligne. À cette échelle, vous souhaiterez peut-être un stockage hiérarchisé afin que les requêtes sur des données «en direct» puissent s'exécuter en mémoire ou sur des disques SSD locaux pour plus de vitesse, tandis que l'ensemble de données complet réside sur des disques rotatifs pour des raisons d'économie.

Combien d'utilisateurs simultanés?

L'estimation de la charge de plusieurs utilisateurs simultanés est souvent traitée comme un exercice de dimensionnement du serveur à effectuer juste avant d'installer votre base de données de production. Malheureusement, de nombreuses bases de données ne peuvent tout simplement pas gérer des milliers d'utilisateurs interrogeant des téraoctets ou des pétaoctets de données, en raison de problèmes de mise à l'échelle.

L'estimation des utilisateurs simultanés est beaucoup plus facile pour une base de données utilisée par les employés que pour une base de données publique. Pour ce dernier, vous devrez peut-être avoir la possibilité de passer à plusieurs serveurs pour des charges imprévues ou saisonnières. Malheureusement, toutes les bases de données ne prennent pas en charge la mise à l'échelle horizontale sans partitionnement manuel fastidieux des grandes tables.

Quelles sont vos exigences en matière de «-ilité»?

Dans cette catégorie, j'inclus la disponibilité, l'évolutivité, la latence, le débit et la cohérence des données, même si tous les termes ne se terminent pas par «-ility».

La disponibilité est souvent un critère clé pour les bases de données transactionnelles. Bien que toutes les applications n'aient pas besoin de fonctionner 24h / 24 et 7j / 7 avec une disponibilité de 99,999%, certaines le font. Quelques bases de données cloud offrent une disponibilité «cinq-neuf», tant que vous les exécutez dans plusieurs zones de disponibilité. Les bases de données sur site peuvent généralement être configurées pour une haute disponibilité en dehors des périodes de maintenance planifiées, en particulier si vous pouvez vous permettre de configurer une paire de serveurs actif-actif.

L'évolutivité, en particulier l'évolutivité horizontale, a toujours été meilleure pour les bases de données NoSQL que pour les bases de données SQL, mais plusieurs bases de données SQL rattrapent leur retard. L'évolutivité dynamique est beaucoup plus facile à réaliser dans le cloud. Les bases de données avec une bonne évolutivité peuvent gérer de nombreux utilisateurs simultanés en augmentant ou en augmentant jusqu'à ce que le débit soit suffisant pour la charge.

La latence fait référence à la fois au temps de réponse de la base de données et au temps de réponse de bout en bout de l'application. Idéalement, chaque action de l'utilisateur aura un temps de réponse inférieur à la seconde; cela se traduit souvent par la nécessité pour la base de données de répondre en moins de 100 millisecondes pour chaque transaction simple. Les requêtes analytiques peuvent souvent prendre quelques secondes ou minutes. Les applications peuvent préserver le temps de réponse en exécutant des requêtes complexes en arrière-plan.

Le débit d'une base de données OLTP est généralement mesuré en transactions par seconde. Les bases de données à haut débit peuvent prendre en charge de nombreux utilisateurs simultanés.

La cohérence des données est généralement «forte» pour les bases de données SQL, ce qui signifie que toutes les lectures renvoient les dernières données. La cohérence des données peut aller de «éventuelle» à «forte» pour les bases de données NoSQL. La cohérence finale offre une latence plus faible, au risque de lire des données obsolètes.

La cohérence est le «C» dans les propriétés ACID requis pour la validité en cas d'erreurs, de partitions réseau et de coupures de courant. Les quatre propriétés ACID sont l'atomicité, la cohérence, l'isolement et la durabilité.

Vos schémas de base de données sont-ils stables?

S'il est peu probable que vos schémas de base de données changent de manière significative au fil du temps et que vous souhaitez que la plupart des champs aient des types cohérents d'un enregistrement à l'autre, les bases de données SQL seraient un bon choix pour vous. Sinon, les bases de données NoSQL, dont certaines ne prennent même pas en charge les schémas, pourraient être meilleures pour votre application. Il existe cependant des exceptions. Par exemple, Rockset permet les requêtes SQL sans imposer un schéma fixe ou des types cohérents sur les données qu'il importe.

Répartition géographique des utilisateurs

Lorsque les utilisateurs de votre base de données sont partout dans le monde, la vitesse de la lumière impose une limite inférieure de latence de la base de données pour les utilisateurs distants, sauf si vous fournissez des serveurs supplémentaires dans leurs régions. Certaines bases de données permettent des serveurs en lecture-écriture distribués; d'autres proposent des serveurs distribués en lecture seule, toutes les écritures étant forcées de passer par un seul serveur maître. La distribution géographique rend encore plus difficile le compromis entre cohérence et latence.

La plupart des bases de données qui prennent en charge des nœuds distribués à l'échelle mondiale et une cohérence forte utilisent des groupes de consensus pour accélérer les écritures sans dégrader sérieusement la cohérence, en utilisant généralement les algorithmes Paxos (Lamport, 1990) ou Raft (Ongaro et Ousterhout, 2013). Les bases de données NoSQL distribuées qui sont finalement cohérentes utilisent généralement une réplication peer-to-peer sans consensus, ce qui peut entraîner des conflits lorsque deux répliques reçoivent des écritures simultanées sur le même enregistrement, conflits qui sont généralement résolus de manière heuristique.

Forme des données

Les bases de données SQL stockent classiquement des données fortement typées dans des tables rectangulaires avec des lignes et des colonnes. Ils s'appuient sur des relations définies entre les tables, utilisent des index pour accélérer les requêtes sélectionnées et utilisent JOINS pour interroger plusieurs tables à la fois. Les bases de données de documents stockent généralement du JSON faiblement typé qui peut inclure des tableaux et des documents imbriqués. Les bases de données de graphes stockent des sommets et des arêtes, des triplets ou des quads. Les autres catégories de bases de données NoSQL incluent les magasins de valeurs-clés et de colonnes.

Parfois, les données sont générées sous une forme qui fonctionnera également pour l'analyse; parfois ce n'est pas le cas et une transformation sera nécessaire. Parfois, un type de base de données est construit sur un autre. Par exemple, les magasins clé-valeur peuvent sous-tendre presque tous les types de bases de données.

OLTP, OLAP ou HTAP?

Pour déchiffrer les acronymes ci-dessus, la question est de savoir si votre application a besoin d'une base de données pour les transactions, l'analyse ou les deux. Le besoin de transactions rapides implique une vitesse d'écriture rapide et des index minimaux. Une analyse nécessaire implique une vitesse de lecture rapide et de nombreux index. Les systèmes hybrides utilisent diverses astuces pour prendre en charge les deux exigences, notamment le fait d'avoir un magasin transactionnel principal alimentant un magasin d'analyse secondaire par réplication.

Ratio lecture / écriture

Certaines bases de données sont plus rapides lors des lectures et des requêtes, et d'autres sont plus rapides lors des écritures. Le mélange de lectures et d'écritures que vous attendez de votre application est un nombre utile à inclure dans vos critères de sélection de base de données et peut guider vos efforts d'analyse comparative. Le choix optimal du type d'index diffère entre les applications lourdes en lecture (généralement un arbre B) et les applications lourdes en écriture (souvent un arbre de fusion structuré en log, alias arbre LSM).

Index et requêtes géospatiales

Si vous disposez de données géographiques ou géométriques et que vous souhaitez effectuer des requêtes efficaces pour rechercher des objets à l'intérieur d'une limite ou des objets à une distance donnée d'un emplacement, vous avez besoin d'index différents de ceux des données relationnelles classiques. Un arbre R est souvent le choix préféré pour les index géospatiaux, mais il existe plus d'une douzaine d'autres structures de données d'index géospatial possibles. Il existe quelques dizaines de bases de données qui prennent en charge les données spatiales; la plupart prennent en charge tout ou partie du standard Open Geospatial Consortium.

Index et requêtes en texte intégral

De même, une recherche de texte intégral efficace dans les champs de texte nécessite des index différents de ceux des données relationnelles ou géospatiales. En règle générale, vous créez un index de liste inversé de mots tokenisés et effectuez une recherche pour éviter d'effectuer une analyse de table coûteuse.

Langages de programmation préférés

Alors que la plupart des bases de données prennent en charge les API pour de nombreux langages de programmation, le langage de programmation préféré dans votre application peut parfois influencer votre choix de base de données. Par exemple, JSON est le format de données naturel pour JavaScript, vous pouvez donc choisir une base de données qui prend en charge le type de données JSON pour une application JavaScript. Lorsque vous utilisez un langage de programmation fortement typé, vous souhaiterez peut-être choisir une base de données fortement typée.

Contraintes budgétaires

Le prix des bases de données varie de gratuit à très cher. De nombreuses bases de données ont à la fois des versions gratuites et payantes, et ont parfois plus d'un niveau d'offre payante, par exemple en proposant une version Entreprise et des temps de réponse de service différents. De plus, certaines bases de données sont disponibles dans le cloud à des conditions de paiement à l'utilisation.

Si vous choisissez une base de données gratuite et open source, vous devrez peut-être renoncer à l'assistance du fournisseur. Tant que vous avez une expertise en interne, cela peut être très bien. D'un autre côté, il peut être plus productif pour vos employés de se concentrer sur l'application et de laisser l'administration et la maintenance de la base de données aux fournisseurs ou aux fournisseurs de cloud.

Restrictions légales

Il existe de nombreuses lois sur la sécurité et la confidentialité des données. Dans l'UE, le RGPD a de vastes implications pour la confidentialité, la protection des données et la localisation des données. Aux États-Unis, la HIPAA réglemente les informations médicales et la GLBA réglemente la manière dont les institutions financières traitent les informations privées des clients. En Californie, le nouveau CCPA améliore les droits à la vie privée et la protection des consommateurs.

Certaines bases de données sont capables de traiter les données d'une manière conforme à tout ou partie de ces réglementations, à condition de suivre les meilleures pratiques. D'autres bases de données présentent des failles qui rendent très difficile leur utilisation pour des informations personnellement identifiables, quelle que soit votre attention.

Honnêtement, c'était une longue liste de facteurs à considérer lors du choix d'une base de données, probablement plus que ce que vous préféreriez considérer. Néanmoins, il vaut la peine d'essayer de répondre à toutes les questions au mieux des capacités de votre équipe avant de risquer d'engager votre projet dans ce qui s'avère être une base de données inadéquate ou excessivement chère.