Comment choisir un magasin de données pour la prochaine nouveauté brillante

Remarque : Il s'agit d'un article de blog technique rédigé par l'ingénieur principal Silvia Botros et paru pour la première fois sur le blog Sysadvent le 25 décembre 2017.

Les bases de données peuvent être difficiles. Vous savez ce qui est plus difficile ? En choisir un en premier lieu. C'est un défi, que vous soyez dans une nouvelle entreprise qui cherche toujours son produit/marché adapté ou dans une entreprise qui a trouvé son public et qui élargit simplement son offre de produits.

Lors de la construction d'une nouvelle chose, l'une des toutes premières parties de ce processus de conception est de savoir quels magasins de données devons-nous utiliser et doit-il s'agir d'un simple ou d'un pluriel ? Devrions-nous utiliser des magasins relationnels ou devons-nous choisir un magasin de valeur clé ? Qu'en est-il des options temporelles ? Doit-on aussi saupoudrer dans certains log replay distribués ?

Alors. De nombreux. Choix…

Je vais essayer dans cet article de décrire un processus qui, espérons-le, guidera cette décision et, le cas échéant, d'expliquer comment la taille et la maturité de votre organisation peuvent avoir un impact sur cette décision.

Exigences de base

Les données sont la pierre angulaire de tout produit. Même si nous prévoyons dans la conception d'utiliser une technologie de pointe pour stocker l'état de l'application (parce que MySQL ou Postgres ne sont plus "cool"), tout ce que nous choisissons est toujours un magasin de données et nécessite donc que nous appliquions de la rigueur lorsque faire notre sélection.

La chose importante à retenir est que rien n'est gratuit. Tous les magasins de données sont livrés avec des compromis et si vous n'êtes pas explicite sur les compromis que vous prenez en tant que risque commercial, vous prendrez un risque inconnu qui se manifestera au pire moment possible.

Il est peu probable que votre chef de produit sache ou même ait besoin de se soucier de ce que vous utilisez pour votre magasin de données, mais il déterminera les besoins qui réduisent la liste des options. Parfois, même cela nécessite un coup de pouce de la part de l'équipe de développement. Voici une liste de choses que vous devez demander à l'équipe produit pour vous aider à choisir vos options :

• Taux de croissance : comment les données elles-mêmes ou l'accès à celles-ci devraient-ils évoluer au fil du temps ?
• Comment l'équipe de facturation utilisera-t-elle ces nouvelles données ?
• Comment l'équipe ETL utilisera-t-elle ces données ?
• Quelles exigences de précision/cohérence sont attendues pour cette nouvelle fonctionnalité ?
• Quel laps de temps pour cette cohérence est acceptable ? La correction post-traitement est-elle acceptable ?

Trouver le contexte qui n'est pas dit

Le choix du magasin de données n'est pas un choix réservé au DBA ou à l'équipe Ops ou même simplement à l'ingénieur qui écrit le code.

Les organisations matures avec un marché adressable connu doivent prendre une décision de la part des parties prenantes de l'ensemble de l'organisation.

Si les exigences de l'équipe produit correspondent à une douzaine de magasins de données, comment déterminez-vous les exigences qui ne sont pas explicitement indiquées ?

Vous devez faire ressortir les exigences tacites dès que possible, car c'est la voie vers l'échec des attentes sur toute la ligne.

Beaucoup de choses sous-entendues peuvent vous faire échouer dans ce piège du « trop de choix ». Cela inclut, mais n'est pas limité à :

• Listes de fonctionnalités incomplètes
• Exigences de performance qui ne sont pas explicitement répertoriées
• Besoins de cohérence assumés
• Taux de croissance non précisé
• Besoins de facturation ou de requête ETL qui ne sont pas encore disponibles/connus

Ce sont toutes des façons possibles qui peuvent laisser une équipe d'ingénieurs tourner la page trop longtemps en examinant une longue liste de choix de magasins de données simplement parce que les critères explicites avec lesquels ils travaillent sont trop permissifs ou incomplets.

Pour les produits plus « nouveaux », comme je l'ai mentionné précédemment, votre objectif est la flexibilité. Ainsi, un magasin de données à usage plus général et de qualité connue vous aidera à vous rapprocher d'un livrable, sachant qu'en fin de compte, vous devrez peut-être passer à un magasin de données plus adapté à votre nouvelle échelle.

Faites votre liste

Il est temps de filtrer les solutions potentielles en fonction de votre liste d'exigences. La liste résultante ne doit pas contenir plus d'une poignée de magasins de données possibles. Si la liste des bases de données potentielles que vous pouvez utiliser est plus longue, vos exigences sont trop permissives et vous devez revenir en arrière et trouver plus d'informations.

Pour les entreprises plus jeunes et moins matures, les exigences en matière de stockage de données sont le domaine le plus inconnu. Vous construisez peut-être une nouvelle chose que personne n'offre pour l'instant et donc des choses comme la taille totale du marché adressable et le taux de croissance peuvent être relativement inconnues et difficiles à quantifier.

Dans ce cas, ce dont vous avez besoin est de ne pas vous contraindre trop tôt dans la vie de votre nouvelle entreprise en utilisant un datastore one trick pony. Oui, à un moment donné, vos données augmenteront de manière nouvelle et inattendue, mais ce dont vous avez besoin en ce moment, c'est de la flexibilité lorsque vous essayez de trouver votre créneau de marché et d'apprendre à quoi ressemblera la croissance de vos données et quelles fonctionnalités d'évolutivité spécifiques deviendront cruciales pour votre croissance.

Si vous êtes une grande entreprise avec un nombre croissant de clients payants, votre tâche ici consiste à réduire la liste d'options de préférence aux magasins de données que vous possédez déjà et que vous gérez. Lorsque vous avez déjà beaucoup de clients payants, le risque d'ajouter de nouveaux magasins de données avec lesquels votre équipe n'est pas familière devient plus élevé et, selon le contexte des données, tout simplement inacceptable.

Une autre chose à garder à l'esprit est de savoir quels outils existent déjà pour les magasins de données et ce que l'adoption d'un nouveau signifierait en ce qui concerne le travail initial que votre équipe doit faire. Gestion de configuration, scripts de sauvegarde, scripts de récupération de données, nouveaux contrôles de surveillance, nouveaux tableaux de bord à construire et à se familiariser. La liste des coûts opérationnels d'un nouveau magasin de données, quel que soit le risque, n'est pas triviale.

Choisissez votre poison

Voici donc un secret mal gardé auquel les DBA s'accrochent. Les bases de données sont toutes terribles à quelque chose. Il y a même tout un théorème à ce sujet. Pas seulement les bases de données au sens traditionnel, mais toute technologie qui stocke l'état sera horrible d'une manière unique à la façon dont vous l'utilisez.

C'est juste un fait de la vie que vous feriez mieux d'intérioriser maintenant. Non, je ne dis pas que vous devriez éviter d'utiliser l'une de ces technologies, je dis de garder vos attentes saines et sachez que VOUS et seulement vous et votre équipe possédez en fin de compte la tenue des promesses que vous faites.

Qu'est-ce que cela signifie en termes non abstraits ? Une fois que vous avez une idée précise des magasins de données qui feront partie de ce que vous construisez, vous devez commencer par connaître les faiblesses de ces magasins de données. Ces faiblesses incluent, mais ne sont pas limitées à :

• Cette banque de données fonctionne-t-elle bien sous les requêtes d'analyse ?
• Cette banque de données s'appuie-t-elle sur un protocole de potins pour la réplication des données ? si oui, comment gère-t-il les partitions réseau ? Combien de données sont impliquées dans ces commérages ?
• Ce magasin de données a-t-il un point de défaillance unique ?
• Dans quelle mesure les conducteurs de la communauté sont-ils matures pour lui parler ou avez-vous besoin de rouler vous-même ?
• Cette liste peut être énorme

Réfléchir aux faiblesses des solutions potentielles encore sur votre liste devrait supprimer plus d'options de la liste. C'est maintenant la réalité qui répond aux nobles promesses de la technologie.

Feuille de calcul et cuisson!

Une fois que votre liste de choix est réduite à une petite poignée, il est temps de les mettre tous dans une feuille de calcul et de commencer à creuser un peu plus. Vous avez besoin d'une colonne pour et d'une colonne contre et à ce stade, vous devrez passer du temps dans la documentation de chaque base de données pour découvrir des détails pratiques sur la façon d'effectuer certaines tâches.

S'il s'agit de données dont vous vous attendez à avoir un taux de croissance élevé, vous devez savoir laquelle de ces options est la plus facile à mettre à l'échelle. S'il s'agit d'une fonctionnalité qui effectue beaucoup de recherches floues, vous devez savoir quelle banque de données peut mieux gérer les analyses ou la recherche dans un grand nombre de lignes et avec quelle conception. L'objectif à ce stade est de réduire la liste à idéalement 2 ou 3 options via la documentation seule, car si cette nouvelle fonctionnalité est suffisamment critique pour le succès de l'entreprise, vous devrez comparer les trois.

Pourquoi référence tu dis ? Parce qu'il n'y a pas 2 entreprises qui utilisent le même magasin de données de la même manière. Parce que parfois la documentation implique des mises en garde qui ne sont exposées que dans les récits de guerre des autres.

Parce que personne d'autre que vous ne détient la stabilité, la fiabilité et la prévisibilité de ce magasin de données.

Concevez votre benchmark à l'avance. Idéalement, vous configurez une instance complète des magasins de données de votre liste avec des spécifications de niveau de production et produisez des données de test qui ne sont pas trop petites pour rendre les tests de charge inutiles. Assurez-vous non seulement de comparer la "charge normale", mais également de tester certains scénarios de défaillance.

L'espoir est que grâce à la référence, vous pouvez découvrir toutes les mises en garde suffisamment graves pour vous obliger à revoir la liste d'options maintenant au lieu de plus tard lorsque tout le code est écrit et que vous êtes maintenant à la phase d'exercice d'incendie avec beaucoup de temps et l'effort consacré au choix que vous avez fait.

Documentez votre choix

Quoi que vous fassiez, vous devez documenter et diffuser en interne la méthode par laquelle vous avez atteint votre choix et les alternatives qui ont été étudiées sur le chemin de cette décision. En supposant qu'il existe un plan d'architecture global de la création de cette nouvelle fonctionnalité et de tous ses composants, vous vous assurez de créer une section dédiée au magasin de données qui alimente cette nouvelle fonctionnalité avec des liens vers tous les benchmarks effectués pour prendre la décision à laquelle l'équipe est parvenue. .

Ce n'est pas seulement pour le bénéfice des futures nouvelles recrues, mais aussi pour le bénéfice de votre équipe maintenant. Un document que les gens peuvent lire de manière asynchrone et développer des opinions sur fournit un moyen de garder le processus de décision transparent, de développer un sentiment de meilleure intention parmi les membres de l'équipe et peut susciter des critiques à partir de perspectives que vous n'aviez pas prévues.

Plats à emporter

Ces étapes ne mèneront pas seulement à des décisions fondées sur des données lors de la croissance de l'offre commerciale, mais conduiront également à une infrastructure robuste et à une approche plus disciplinée quant au moment et à l'endroit où vous utiliserez un domaine de technologies en constante évolution pour apporter de la valeur à votre paiement. les clients.