Transition des anciennes bases de données vers une architecture de données moderne

La bonne nouvelle : là est une combinaison de technologies de bases de données adaptées aux besoins précis de votre organisation en matière de données. Mais la prolifération de solutions de données spécialement conçues signifie que choisir votre stratégie de transition de données signifie faire vos devoirs. Bien que cet article ne prenne pas cette décision à votre place, il vous permettra, espérons-le, de comprendre rapidement ce à quoi vous devez penser lorsque vous planifiez vos initiatives de modernisation des données.

Introduction rapide aux bases de données et à l’architecture des données

Dès l’avènement des ordinateurs dans les années 1950, il y avait un besoin de manipuler les données. Initialement, les données étaient stockées dans les programmes informatiques ou les algorithmes eux-mêmes. Mais à mesure que la complexité de l’analyse et la quantité de données augmentaient, il était nécessaire de stocker, de gérer et d’accéder aux données en externe.

Charles W. Bachman est crédité de la conception du premier système de gestion de base de données (SGBD) dans les années 1960. L’approche s’est avérée populaire et de nombreuses sociétés commerciales, comme IBM, ont créé leur propre version (comme IBM Information Management). Au fur et à mesure que les ordinateurs devenaient populaires auprès des entreprises, de nouvelles façons de standardiser le stockage et l’accès aux bases de données ont été développées.

Une véritable révolution dans la gestion des bases de données est venue d’EF Codd en 1970. Codd a proposé un modèle relationnel de données (RDBMS). Ce modèle organise les données en lignes et en colonnes, appelées tables. Chaque ligne du tableau comporte de nombreuses colonnes et une clé unique pour y accéder. Les lignes d’une table peuvent être liées à des lignes d’autres tables. En un instant, la complexité des ensembles de données a été réduite à de simples relations entre les tables. IBM a également introduit un moyen standard d’accéder aux données dans les tables, appelé le langage de requête structuré (SQL). De nombreuses bases de données relationnelles populaires et commerciales sont arrivées sur le marché, notamment DB2 et Oracle.

Pourquoi les bases de données se sont modernisées et pourquoi les décisions relatives aux données sont plus critiques que jamais

La facilité de stockage, la possibilité de connecter des ensembles de données et la manière standard d’accéder aux données ont fait des bases de données relationnelles un énorme succès. Les bases de données relationnelles (RDBMS) ont dominé la gestion des données pendant près de 30 ans – de 1970 à 2000. Le millénaire, cependant, a apporté un énorme changement dans le volume, la variété et la vitesse des données. L’évolution a remis en question les fondements des bases de données relationnelles en introduisant :

1. 1. 1. Structuré vs. données non structurées – Les données structurées étaient principalement composées de lignes et de colonnes, mais leur domination a été remise en question par la génération de nouveaux types de données, comme les flux Twitter, les fichiers mp3, les vidéos, les données de séries chronologiques, les données graphiques, etc. Les SGBDR traditionnels n’étaient pas adaptés pour stocker ces types de types de données.
      2. Volume limité vs volume illimité de données – La vague RDBMS a fait face à une grande quantité de données structurées de certains secteurs, comme la finance et la vente au détail, mais elle était encore limitée à des téraoctets et des pétaoctets sur plusieurs années. Le nouveau millénaire a vu une croissance quotidienne ou hebdomadaire des données en téraoctets pour des cas d’utilisation tels que les journaux Facebook, les flux Twitter ou les voitures autonomes.
      3. Lot vs. données en continu – Certaines applications nécessitaient que les données soient traitées sous forme de flux en temps réel ; par exemple, les flux Twitter ou les journaux Web pour un moteur de recommandation. Ceci était différent du traitement par lots traditionnel dans les bases de données relationnelles.
      4. Sur site vs. données en nuage – Le millénaire a également introduit la technologie cloud qui a résolu la disponibilité, l’évolutivité et la fiabilité des solutions de base de données existantes. Cela a également introduit des considérations de gestion des données hybrides, car les données étaient dispersées dans plusieurs environnements sur site et dans le cloud.

Les caractéristiques ci-dessus des données rendues par le modèle RDBMS sont obsolètes – ou, du moins, très limitées dans leur portée. Bien sûr, les données structurées sont toujours essentielles pour de nombreuses fonctions opérationnelles telles que la gestion des finances et des commandes, mais les nouveaux types de bases de données posent un défi important au SGBDR. Différents types de données et leurs applications nécessitent une technologie de base de données différente, comme avoir le bon outil pour le bon cas d’utilisation. Lorsque vous construisez une maison, vous utilisez toutes sortes d’outils – un marteau, une perceuse, un tournevis, une clé, etc. De même, lorsque vous construisez un système de gestion de base de données, vous devez utiliser les bonnes bases de données pour le bon cas d’utilisation – c’est aussi appelé le architecture polyglotte. Plusieurs technologies de bases de données, collectivement appelées bases de données « NoSQL », ont vu le jour après le millénaire : magasins clé-valeur, bases de données de graphes, bases de données en colonnes, bases de données de type document, bases de données de séries temporelles, etc. Ce tableau, illustré ci-dessous, aide à montrer comment les types de base de données s’intègrent dans la fonctionnalité souhaitée.

L’essor de l’open source

Vous avez peut-être remarqué une tendance importante dans les solutions de bases de données ci-dessus – alors que l’ère du SGBDR était dominée par quelques bases de données propriétaires comme DB2, Oracle, Informix, les bases de données NoSQL sont principalement des bases de données open source. La plupart des bases de données NoSQL les plus populaires et des technologies associées sont open source, comme Hadoop, Cassandra, Kafka, OpenSearch, Redis, Spark et bien d’autres. Ces technologies open source sont entièrement gratuites pour tout individu ou entreprise. Il n’y a aucun des coûts de licence ou de verrouillage du fournisseur qui prévalaient dans les technologies RDBMS comme Oracle.

Cependant, la popularité des technologies open source a motivé plusieurs nouveaux fournisseurs à gagner de l’argent avec les technologies open source. Certains de ces fournisseurs ont ajouté de nouvelles fonctionnalités au logiciel de base et ont commencé à facturer des frais de licence, tandis que d’autres ont introduit de nouvelles technologies qui ne sont open source que de nom. Pour toute entreprise de transition ou de migration vers la couche de données, il est essentiel de comprendre le nouvel écosystème open source pour tirer le meilleur parti de ces technologies.

L’écosystème open source peut être divisé en trois types de fournisseurs :

1. 1. 1. Open-Core – La technologie de base de données de base utilisée est open-source, mais ces fournisseurs ajoutent des fonctionnalités propriétaires en plus de l’open-core et commencent à facturer des frais de licence. Il peut rapidement devenir flou (parfois intentionnellement) quant à ce qui est ouvert et ce qui est propriétaire, et le fournisseur se concentre uniquement sur le fait de vous faire passer du véritable open-source à sa version sous licence.
      2. Code ouvert – Certaines solutions de données introduisent une nouvelle technologie qu’elles appellent open-source, mais elle utilise des licences logicielles plus restrictives, telles que SSPL. Ces licences interdisent les alternatives commerciales. Techniquement, n’importe qui peut télécharger et consulter le code (c’est-à-dire le code ouvert), mais toute modification ou amélioration reste la propriété du titulaire de la licence commerciale.
      3. Open source – Il existe peu de fournisseurs qui prennent en charge les véritables technologies open source telles que Cassandra, Redis et autres. Ils offrent des services tels que le support et les plates-formes gérées, mais diffèrent en ne facturant pas de frais de licence pour aucune des technologies (le code utilisé reste donc entièrement open source et portable).