Después de mucho batallar hemos hallado el resultado de este dilema que muchos usuarios de este espacio han tenido. Si quieres aportar algún dato no dejes de aportar tu comentario.
Solución:
¡Definitivamente estás en el camino correcto! 320GB no es enorme para una base de datos, particularmente un DW.
1) La base de datos actual está mal optimizada, poca documentación, tipos de datos subóptimos, índices subóptimos.
Mis pensamientos de novato: ¿No son estos problemas irrelevantes para dividir la base de datos? Son simplemente problemas que deben resolverse por sí mismos de cualquier manera.
Esto es un golpe en el dinero. ¡Dividir una base de datos grande (ish) mal organizada, optimizada y documentada en 7 bases de datos mal organizadas, optimizadas y documentadas es una pérdida de tiempo! ¡Necesitas abordar la raíz del problema!
2) Hay 372 objetos en la base de datos actual, lo que la hace lenta.
Mis pensamientos: Esto difícilmente parece grande en mi opinión.
Una vez más, ¡tienes razón! 372 es positivamente pequeño en términos de cantidad de objetos: muchos servidores grandes tienen decenas de miles. De aquí
La suma del número de todos los objetos de una base de datos no puede superar los 2.147.483.647.
Tus 370 divididos por ~ 2E9 ~ = 1.7E-7, ¡así que no te preocupes por ese puntaje! 🙂
3) Una base de datos es más difícil de documentar y dibujar diagramas de esquema para 7 bases de datos (tendremos vistas que abarcarán varias bases de datos).
Mis pensamientos: …. Esto me parece completamente ridículo, pero tal vez me equivoque. Ya hemos organizado nuestro almacén de datos según 13 esquemas de “sistema de origen”.
Una vez más, estás en lo correcto. Si hay 372 entidades con interrelaciones entre ellas, deberá documentarlas y diagramarlas. Tendrá un grado inherente de complejidad. Lo que tu pueden Lo que hay que hacer es tratar de dividir su sistema general en subsistemas y documentarlos y luego tratar de encajarlos en el panorama general: ¡grandes robles de pequeñas bellotas crecen!
4) Una base de datos dará lugar a más puntos muertos de la base de datos.
– ¿No es este problema también completamente irrelevante para tener varias bases de datos? Tengo entendido que los puntos muertos ocurren en el nivel de la tabla (en realidad, por lo general, incluso solo en el nivel de la fila, pero eh). Incluso entonces, todas nuestras inserciones de datos ocurren a la medianoche, todas nuestras selecciones posteriores al BI ocurren a las 2 am. Tener dos procesos actualizando la misma tabla es irrelevante para múltiples bases de datos, ¿no es así (el punto muerto se produciría de cualquier manera)? Además, personalmente no he visto evidencia de que se produzcan interbloqueos en la mesa durante las operaciones normales.
Lo que perderá en el escenario de múltiples bases de datos son las transacciones ACID dentro del mismo esquema; de acuerdo, puede tener un compromiso de 2 fases, pero no es tan sólido como las transacciones dentro del mismo esquema (en mi humilde opinión). No estoy seguro de una razón válida para dividir las mesas si son necesarias para sus necesidades.
¿Parece estar hablando de escrituras que bloquean las lecturas? Bueno, ¿también parece tener un proceso por lotes a la medianoche seguido de un proceso de consulta a las 02:00? Si puede hacer transacciones / tablas de solo lectura, esto le quitará algo de carga al motor del servidor mientras procesa sus datos. ¡Solo usted puede saber si esto se puede aplicar a su escenario!
5) Propiedad técnica de la base de datos.
Solo nosotros dos trabajamos en la base de datos. Es posible que realmente quiera segregar nuestros ‘feudos’. Realmente, no ha sido un problema, pero ¿no se pueden determinar los permisos de usuario a nivel de esquema de todos modos?
Ciertamente, la propiedad está en el nivel de la tabla y el acceso puede, dependiendo de su servidor / versión, otorgarse en una columna y / o en un nivel de fila, por lo que el negocio de la propiedad es una pista falsa. Si usted es un DBA de servidor que realiza una reorganización (en lugar de simplemente programar copias de seguridad y otras tareas mundanas), entonces necesitará “acceder a todas las áreas”.
Debe tener un comentario en cada tabla y campo de su sistema; puede poner “propiedad” (en el sentido de las cosas de la organización en lugar de en la base de datos) allí; comentar tablas y campos es una excelente primer paso para documentar un sistema: ¡se convierte en autodocumentado!
¿Cuáles SON las razones válidas para dividir un almacén de datos en varias bases de datos?
Puede haber muchas razones: algunas están asociadas con la tenencia múltiple (tanto en términos de recursos de la máquina (CPU, RAM, HDD y red) como en la confidencialidad o los requisitos del cliente. Eche un vistazo aquí y también en Google “tenencia múltiple de la base de datos” o similar. .
Todo el mundo lo dice, pero es una lucha: “la documentación es muy importante”. Como primer paso, documente sus tablas y campos en los comentarios. Produzca diagramas ERD para todos sus subsistemas. No dejes cualquier cosa nuevo en el sistema sin que se hayan implementado estos pasos. ¡Mucha suerte en tu nuevo rol!
Si bien suena como una táctica clásica de hombre de paja adoptada por su colega, ¿podría referirse a la creación de mercados de datos formales cuando dice “dividir el almacén de datos”?
Los dos enfoques principales del almacenamiento de datos se atribuyen a Ralph Kimball y Bill Inmon. Aquí hay un par de descripciones generales de alto nivel ([1], [2]) sobre la diferencia entre estos dos enfoques comunes si tiene unos minutos para quemar.
Lo que creo que puede ser aplicable a su situación es que el enfoque de Bill Inmon exige la creación formal de Data marts de las que la (s) herramienta (s) de generación de informes extraen datos. Estas Data marts están diseñadas para que departamentos o unidades de negocio específicas accedan exclusivamente, y creo que esto puede ser hacia lo que su colega está tratando de avanzar. La naturaleza idéntica de las copias es extraña, pero ¿puede ser más fácil crear una copia del almacén de datos en su forma actual y luego cargar solo los datos de un departamento específico en dicha copia en el futuro?
Por lo que ha proporcionado, parece que su almacén de datos actual está utilizando el enfoque de Kimball donde el Data marts son un subconjunto lógico de datos dentro del almacén de datos dimensional al que accede directamente su herramienta de informes. Estos dos enfoques de diseño tienen sus pros y sus contras, y es de esperar que el meollo del problema de su colega sea que él o ella se sienta más cómodo con el enfoque de Inmon.
Es de esperar que esto sea solo un malentendido de términos y una discusión en profundidad de estos dos enfoques diferentes con su colega conducirá a algunas aclaraciones sobre los obstáculos que él o ella está tratando de superar.
Si conservas alguna desconfianza y forma de innovar nuestro artículo puedes realizar una glosa y con gusto lo ojearemos.