2 raisons pour lesquelles une base de données fédérée n'est pas si slam-dunk

C'est souvent le premier problème que vous résolvez lors du passage au cloud: votre entreprise utilise des dizaines, parfois des centaines de bases de données hétérogènes différentes, et vous devez maintenant les lier dans des centaines de vues virtuelles des données dans le cloud.

Ce qui est bien à ce sujet, c'est que vous n'avez pas besoin de migrer vers de nouvelles bases de données, ni même de déplacer les données de l'endroit où elles sont actuellement hébergées dans le cloud. Après tout, il peut y avoir des applications qui dépendent de ces données, et la dernière chose que vous voulez faire est de stocker des données redondantes.

Alors, vous fédérez. Cela vous donne une centralisation logique des données sans avoir à changer où les données sont physiquement stockées, dans le cloud ou non.

Mais pas si vite. Il y a des obstacles à considérer. Voici mes deux meilleurs.

Tout d'abord, la performance. Vous pouvez certainement mélanger les données d'une base de données basée sur des objets, une base de données relationnelle et même des données non structurées, en utilisant une vue centralisée et virtualisée basée sur les métadonnées. Mais votre capacité à exécuter des requêtes en temps réel sur ces données, dans un laps de temps raisonnable, est une autre histoire.

Le sale petit secret des systèmes de bases de données fédérées (cloud ou non) est qu'à moins que vous ne soyez prêt à consacrer le temps nécessaire à l'optimisation de l'utilisation de la base de données virtuelle, des problèmes de performances sont susceptibles d'apparaître et d'utiliser une base de données fédérée , eh bien, inutile. En passant, placer la base de données fédérée dans le cloud ne vous aidera pas, même si vous ajoutez plus de stockage virtuel et calculez pour essayer de forcer les performances.

La raison en est que tant de choses doivent se passer en arrière-plan simplement pour mettre en place les données provenant de nombreuses sources de bases de données différentes. Ces problèmes sont généralement résolus en déterminant une bonne conception de base de données fédérée, en ajustant la base de données et en limitant le nombre de bases de données physiques pouvant être impliquées dans un seul modèle d'accès. J'ai constaté que la limite est généralement de quatre ou cinq.

Deuxièmement, la sécurité. Je suis presque sûr que la plupart des bases de données fédérées basées sur le cloud fonctionnant dans le cloud ont une vulnérabilité qui peut être exploitée maintenant, et la plupart des entreprises qui possèdent les données ne le savent pas.

La cause est la même que celle des problèmes de performances: il y a tellement de pièces mobiles qu'il est difficile de s'assurer que toutes les données, points d'accès, métadonnées, etc., sont verrouillés mais en même temps facilement accessibles.

Bien que vos systèmes utilisant des bases de données fédérées puissent chiffrer les données au repos, ils ne chiffrent souvent pas les données en vol. Ou, si vous cryptez des données en vol, vous ne cryptez probablement pas les données au repos. Ou bien, il existe un chemin direct vers la base de données physique qui contourne l'architecture de la base de données fédérée et la sécurité qu'elle fournit.

À ce jour, je n'ai pas vu de base de données fédérée avec une sécurité centralisée solide qui fonctionne à la fois sur les couches de base de données virtuelle et physique. Alors, occupez-vous à boucher ces trous!