2 razones por las que una base de datos federada no es tan sencilla

A menudo, es el primer problema que resuelve al migrar a la nube: su empresa utiliza docenas, en ocasiones cientos, de diferentes bases de datos heterogéneas, y ahora necesita unirlas en cientos de vistas virtuales de los datos en la nube.

Lo bueno de esto es que no necesita migrar a nuevas bases de datos, o incluso mover los datos desde donde se encuentran actualmente alojados en la nube. Después de todo, puede haber aplicaciones que dependan de esos datos y lo último que desea hacer es almacenar datos redundantes.

Entonces, te federas. Eso le brinda una centralización lógica de los datos sin tener que cambiar dónde se almacenan físicamente los datos, en la nube o no.

Pero no tan rápido. Hay obstáculos a considerar. Aquí están mis dos mejores.

Primera representación. Sin duda, puede mezclar datos de una base de datos basada en objetos, una base de datos relacional e incluso datos no estructurados, utilizando una vista basada en metadatos centralizada y virtualizada. Pero su capacidad para ejecutar consultas en tiempo real sobre esos datos, en un período de tiempo razonable, es otra historia.

El pequeño secreto sucio sobre los sistemas de bases de datos federadas (en la nube o no) es que, a menos que esté dispuesto a dedicar el tiempo necesario para optimizar el uso de la base de datos virtual, es probable que surjan problemas de rendimiento que hagan que el uso de una base de datos federada , bueno, inútil. Por cierto, poner la base de datos federada en la nube no lo ayudará, incluso si agrega más almacenamiento virtual y computación para tratar de forzar el rendimiento.

La razón es que tienen que suceder muchas cosas en segundo plano solo para que los datos estén en su lugar de muchas fuentes de bases de datos diferentes. Por lo general, estos problemas se solucionan al determinar un buen diseño de base de datos federada, ajustar la base de datos y poner límites a la cantidad de bases de datos físicas que pueden participar en un solo patrón de acceso. Descubrí que el límite suele ser cuatro o cinco.

Segundo, seguridad. Estoy bastante seguro de que la mayoría de las bases de datos federadas basadas en la nube que se ejecutan en la nube tienen una vulnerabilidad que puede explotarse ahora, y la mayoría de las empresas que poseen los datos no lo saben.

La causa es la misma que por lo general tiene problemas de rendimiento: hay tantas partes móviles que es difícil asegurarse de que todos los datos, puntos de acceso, metadatos, etc., estén bloqueados pero al mismo tiempo sean fácilmente accesibles.

Si bien sus sistemas que utilizan bases de datos federadas pueden cifrar los datos en reposo, a menudo no cifran los datos en tránsito. O, si encripta datos en tránsito, probablemente no esté encriptando datos en reposo. O existe una ruta directa a la base de datos física que pasa por alto la arquitectura de la base de datos federada y la seguridad que proporciona.

Hasta la fecha, no he visto una base de datos federada con una seguridad centralizada sólida que funcione tanto en la capa de base de datos virtual como en la física. ¡Así que ocúpate de tapar esos agujeros!