Bases relationnelles, NoSQL, In-Memory, Cloud, DBaaS... Difficile d'y voir clair dans les dédales du marché des bases de données, dont l'évolution, ces dernières années, s'est avérée spectaculaire.
La carte du paysage des bases de données, publiée par le cabinet 451Research en janvier 2016, frappe par sa complexité : pas moins de 386 produits constituent aujourd'hui le marché des bases de données. Un marché en pleine explosion, qui a vu le développement d'un nombre croissant de nouvelles technologies, en réponse à des problèmes de niches.
La première carte, publiée en 2011, comptait à peine six catégories. Cinq ans plus tard, on en dénombre une vingtaine, les relations entre les fournisseurs étant elles-mêmes désormais tridimensionnelles.
Comment s'y retrouver au milieu de cette pléthore de solutions ? De combien de bases de données avez-vous réellement besoin ? Et pour quel(s) usage(s) ?
La première carte, publiée en 2011, comptait à peine six catégories. Cinq ans plus tard, on en dénombre une vingtaine, les relations entre les fournisseurs étant elles-mêmes désormais tridimensionnelles.
Comment s'y retrouver au milieu de cette pléthore de solutions ? De combien de bases de données avez-vous réellement besoin ? Et pour quel(s) usage(s) ?
Pérennité : le dernier qui a parlé n'a pas forcément raison
L'explosion de fournisseurs au sein d'un secteur, a fortiori dans un secteur en rapide mutation comme celui des bases de données s'accompagne bien souvent d'une tendance hélas inévitable : toute solution destinée à résoudre un problème est obsolète au moment même de sa création. Si bien qu'il est impossible de savoir, parmi les jeunes pousses spécialisées en base de données qui ont vu le jour ces dernières années, combien existeront encore dans trois ans. Nous avons vu des entreprises technologiques disparaître aussi vite qu'elles étaient apparues sur de nombreux autres marchés, et le domaine des bases de données ne fait pas exception à cette sélection naturelle.
Que faire, alors, lorsqu'un projet court sur plusieurs décennies ? Comment s'assurer que la plateforme choisie s'inscrit bien dans la durée ? Sur quel critère prendre sa décision ?
L'une des questions essentielles à se poser est de savoir si la dernière technologie « à la mode » existera encore dans quelques années. Et à y regarder de plus près, on s'aperçoit que les plateformes dernier cri ne sont pas toujours les plus fiables ni les plus évolutives. Que leur modèle de données n'est pas toujours le plus abouti ni le plus efficient. Alors que les systèmes proposés il y a 20 ou 30 ans par des entreprises bien établies, et les investissements consentis dans ces systèmes, laissent à penser que le langage SQL est loin de vivre ses dernières heures.
Que faire, alors, lorsqu'un projet court sur plusieurs décennies ? Comment s'assurer que la plateforme choisie s'inscrit bien dans la durée ? Sur quel critère prendre sa décision ?
L'une des questions essentielles à se poser est de savoir si la dernière technologie « à la mode » existera encore dans quelques années. Et à y regarder de plus près, on s'aperçoit que les plateformes dernier cri ne sont pas toujours les plus fiables ni les plus évolutives. Que leur modèle de données n'est pas toujours le plus abouti ni le plus efficient. Alors que les systèmes proposés il y a 20 ou 30 ans par des entreprises bien établies, et les investissements consentis dans ces systèmes, laissent à penser que le langage SQL est loin de vivre ses dernières heures.
Scalabilité : horizontale, verticale ou mixte ?
En matière de configuration de plateformes de données, deux approches radicalement différentes se démarquent : d'un côté les longueurs parallèles de faible niveau (approche horizontale), de l'autre la mise en file en attente de centaines de milliers de transactions sur un verrou ou une ressources unique (approche verticale). Des besoins en systèmes de scale-up et scale-out massifs se font clairement ressentir.
Laquelle de ces deux options est pour vous la plus pertinente ? De la capacité morcelée en éléments de la taille d'un byte ? Des systèmes de très grande taille ? Ou un mélange des deux ?
Il n'est pas seulement question ici de charge de travail, mais aussi de coût total de possession. Si vous déployez douze systèmes plus petits plutôt qu'un système plus grand, les besoins de prise en charge et d'alimentation ne sont pas les mêmes. Sans compter l'écart de coûts au moment du déploiement, du développement et de l'exploitation. Les objectifs commerciaux de chaque organisation, de même que sesprérequis en termes de bases de données, sont uniques. Et doivent être sans cesse réévalués pour s'assurer d'être correctement adressés.
Laquelle de ces deux options est pour vous la plus pertinente ? De la capacité morcelée en éléments de la taille d'un byte ? Des systèmes de très grande taille ? Ou un mélange des deux ?
Il n'est pas seulement question ici de charge de travail, mais aussi de coût total de possession. Si vous déployez douze systèmes plus petits plutôt qu'un système plus grand, les besoins de prise en charge et d'alimentation ne sont pas les mêmes. Sans compter l'écart de coûts au moment du déploiement, du développement et de l'exploitation. Les objectifs commerciaux de chaque organisation, de même que sesprérequis en termes de bases de données, sont uniques. Et doivent être sans cesse réévalués pour s'assurer d'être correctement adressés.
Cloud : une question de coût/bénéfice
Pour nombre d'entreprises qui envisagent d'évoluer vers un Cloud public, les principales interrogations tournent autour, d'une part du prix à payer pour bénéficier d'un certain niveau de service, d'autre part de la rapidité d'évolution des fournisseurs Cloud pour fournir le service attendu.
A combien s'élèvera la facture lors du déploiement dans le Cloud ? Quid des questions de sécurité et de responsabilité ?
La majorité des entreprises ont aujourd'hui recours à un logiciel reposant sur le Cloud dans le cadre d'au moins une application critique. La tolérance face au risque diminue à mesure que le rapport coût/bénéfice devient plus attrayant.
A combien s'élèvera la facture lors du déploiement dans le Cloud ? Quid des questions de sécurité et de responsabilité ?
La majorité des entreprises ont aujourd'hui recours à un logiciel reposant sur le Cloud dans le cadre d'au moins une application critique. La tolérance face au risque diminue à mesure que le rapport coût/bénéfice devient plus attrayant.
DBaaS : une base de données indépendante ?
Les DBaaS (Database as a Service) font de plus en plus parler d'elles. Amazon, Google et Oracle en tête, le nombre de fournisseurs de DBaaS ne cesse de croître. Ils proposent pour la plupart un éventail complet de fonctionnalités, de la reprise d'activité après incident à la capacité pure et simple d'analyses. Notons toutefois que 451Research a décelé un virage très lent dans les déploiements des bases de données indépendamment du déploiement d'applications dans le Cloud.
Concevez-vous la DBaaS indépendamment de votre application ? Quels types d'applications sont susceptibles, selon vous, de recourir à une DBaaS ? La base de données doit-elle faire partie de l'application ?
Reste la question des juridictions locales, et de leur impact sur la manière dont les plateformes de données sont sélectionnées dans certains pays. Autant de problématiques qu'il faut anticiper avant de prendre une décision.
Concevez-vous la DBaaS indépendamment de votre application ? Quels types d'applications sont susceptibles, selon vous, de recourir à une DBaaS ? La base de données doit-elle faire partie de l'application ?
Reste la question des juridictions locales, et de leur impact sur la manière dont les plateformes de données sont sélectionnées dans certains pays. Autant de problématiques qu'il faut anticiper avant de prendre une décision.
Vers la prochaine génération de bases de données
Parce que les décisions, dans toute organisation, sont désormais fondées sur les données, on parle de plus en plus de bases de données universelles : une base de données multi-modèles unique, capable de stocker tout type de structures de données et de gérer des charges de travail multiples (traitement et analyses de transactions), sans pour autant sacrifier la fiabilité des transactions (propriétés ACID) ni l'interopérabilité des systèmes. L'évolution du marché des bases de données ne devrait en effet pas impacter la pérennité des applications.
De combien de bases de données avez-vous besoin ? La question devrait plutôt être : sur quelles bases de données seriez-vous prêt à parier l'avenir de vos applications les plus critiques ?
De combien de bases de données avez-vous besoin ? La question devrait plutôt être : sur quelles bases de données seriez-vous prêt à parier l'avenir de vos applications les plus critiques ?
Envoyer à un ami
Version imprimable
Partager