Los sistemas de contabilidad corporativa se caracterizan por un aumento gradual en el volumen de bases de datos debido a la acumulación de información histórica. Con el tiempo, el tamaño de la base de datos puede alcanzar dimensiones que provocan una serie de problemas con el rendimiento, el mantenimiento, el espacio disponible en el disco y más. Hoy consideramos dos enfoques para resolver este problema: aumentar los recursos de hardware y plegar datos históricos.
Introduccion
Este artículo aborda el problema de plegar bases de datos especialmente grandes en la plataforma MS SQL Server. La solución a este problema se describe utilizando la tecnología de replicación DBREPLICATION de Softpoint.
Problema
Cada tipo de sistema contable puede comenzar a manifestar sus propias características específicas. Por ejemplo, en sistemas basados en la plataforma 1C, surgen problemas con operaciones rutinarias como actualizar la configuración, actualizar la plataforma 1C. A medida que la base de datos crece, la situación empeora gradualmente; tarde o temprano, se deben tomar medidas.
Enfoque n. ° 1: hardware
La solución más obvia y técnicamente transparente es aumentar los recursos de hardware. Esto puede ser la compra de servidores más productivos, almacenamiento en disco, etc., o el alquiler de equipos más potentes en un centro de datos de terceros o en la nube.
Si sigue este camino, entonces una buena opción es colocar la base de datos en la nube de Microsoft Azure. Azure proporciona varias opciones de arquitectura para alojar la base de datos: MS SQL en la máquina virtual de Azure y tres opciones para la Base de datos SQL de Azure en la nube. Por lo tanto, es posible elegir la opción de ubicación más óptima según las características de una base de datos particular y sus condiciones de funcionamiento.
Azure tiene una serie de ventajas en comparación con la compra de su propio equipo. Una de las principales son las enormes capacidades de hardware que Azure puede proporcionar. Además de un enfoque flexible para el uso de estas capacidades dependiendo de la carga real. Por ejemplo, puede comprar capacidades adicionales para el período de la "temporada alta" de su negocio, o al cierre del período de informe, para que los picos puedan pasar sin problemas. Y el resto del tiempo, use una configuración de recursos más presupuestaria. Por lo tanto, por un lado, en el momento adecuado tiene acceso al enorme potencial de recursos de Azure (que, por cierto, está creciendo todo el tiempo), y por otro lado, no puede pagar de más por el exceso de capacidad cuando no los necesita.
Sin embargo, a pesar de su relativa simplicidad, aumentar los recursos de hardware no es una solución universal. En primer lugar, el efecto positivo a menudo está lejos de ser proporcional a las inversiones financieras (hay muchas inversiones, hay poco efecto). En segundo lugar, el efecto es temporal, ya que la base continúa creciendo y requiere más recursos, más inversiones financieras.
En cualquier caso, este enfoque tiene derecho a la vida y es ampliamente utilizado. Pero ya no nos detendremos más en él, ya que el objetivo principal del artículo no es un enfoque de "hardware", sino uno de "software", que se describe a continuación.
Enfoque n. ° 2: convolución de la base
Una solución más radical es la convolución de la base de datos, es decir, la eliminación de datos históricos no relevantes de la misma. En la base de datos colapsada solo hay datos para un período operativo relativamente pequeño, generalmente no es más de 1-2 años. Obviamente, el grado de reducción en cada caso es diferente, y es difícil nombrar números específicos. Y, sin embargo, para una guía, tomaremos un indicador de una disminución en la base en un 50-70%, es decir, aproximadamente 2-3 veces, aproximadamente la misma cantidad con mayor frecuencia y resulta en la práctica, menos o viceversa más, es raro.
No nos detendremos en las ganancias resultantes. Obviamente, si la base se reduce en 2-3 o más veces, el efecto de rendimiento será muy poderoso y a largo plazo, y se pueden evitar inversiones adicionales en el componente de hardware. Y el mecanismo de convolución, una vez desarrollado y ejecutado, puede reutilizarse en el futuro. En general, esta es una gran solución efectiva con resultados garantizados.
La complejidad de la implementación de convolución
Pero a pesar de toda su efectividad, la convolución tiene un gran problema. Y ni siquiera se trata de desarrollar el mecanismo de convolución en sí. Sí, este desarrollo también es una tarea difícil, pero de alguna manera está resuelto. La cosa es diferente. Cuando la base de datos tiene un tamaño de varios cientos de gigabytes o ha cruzado la línea de terabytes, resulta que es físicamente muy difícil realizar la operación de plegado. Inevitablemente, surge todo un complejo de dificultades interconectadas, considerámoslas.
- Intensidad de recursos de las operaciones de plegado: el equipo está muy cargado.
- Durante la convolución, no solo se elimina físicamente una gran variedad de datos, sino que también se realizan muchas operaciones intensivas relacionadas con los recursos: varias selecciones, comprobaciones, agrupaciones, indexación, registro, movimiento de datos entre tablas, etc. Este hecho es especialmente importante porque la base de datos plegable, como regla, ya está muy cargada y no tiene un exceso de capacidad.
- Interferencia a los usuarios.
- Es extremadamente difícil o imposible realizar la convolución directamente en la base de datos de trabajo en paralelo con el trabajo del usuario debido a la alta carga adicional y los bloqueos creados por el proceso de convolución.
- No hay ventana tecnológica.
- Una ventana tecnológica de duración suficiente, cuando los usuarios no trabajan, simplemente no está disponible para la convolución. Después de todo, el proceso de plegado para bases de datos de este tamaño suele ser de decenas de horas o varios días.
- Altos riesgos al plegar directamente a la base de trabajo.
- El enfoque, cuando el algoritmo de convolución se aplica directamente a la base de trabajo, es en sí mismo altamente riesgoso por varias razones. Uno de ellos: las posibilidades para la verificación final de los resultados de la convolución son muy limitadas (sin tiempo).
- Duración inaceptable de un enfoque iterativo.
- Puede intentar evitar un cuello de botella, una ventana tecnológica, y realizar iteraciones en porciones iterativamente pequeñas directamente en la base productiva, seleccionando el tamaño de cada porción para que se ajuste a las ventanas tecnológicas existentes. Pero este camino tampoco suele aplicarse, porque, en primer lugar, el proceso de recorte se prolonga durante un período inaceptablemente largo (muchas semanas o meses), y en segundo lugar, la complejidad del mecanismo de plegado aumenta drásticamente, el costo total de garantizar un proceso de recorte ininterrumpido durante tanto tiempo , los riesgos del proyecto en su conjunto están aumentando radicalmente.
- ¿Cómo comprimir vacíos en un archivo de datos?
- Durante la eliminación de información histórica de la base de datos, su archivo de datos en realidad no disminuye (y a menudo incluso aumenta ligeramente), simplemente crea enormes vacíos dentro de él. Y necesita deshacerse de ellos de alguna manera para reducir el archivo de datos. De lo contrario, la ganancia se pierde en términos de espacio en disco. Una opción es ejecutar un SHRINK típico. Y en tales volúmenes es un procedimiento muy largo (muchas horas, o incluso decenas de horas).
Por lo tanto, la convolución es una tarea muy no trivial. No es suficiente desarrollar un mecanismo de convolución, también debe aplicarse. Además, la aplicación a menudo se convierte en un cuello de botella.
Nota: A continuación, dejamos entre paréntesis el desarrollo del mecanismo de convolución en sí (en otras palabras, el algoritmo para eliminar datos históricos), sin importar el medio que se cree. Y nos enfocamos solo en la aplicación del mecanismo ya implementado en la batalla.
Solución usando DBREPLICATION
Parecería un callejón sin salida. Pero todavía hay soluciones. Existe una técnica efectiva que le permite desentrañar toda la maraña de dificultades, eliminar riesgos y garantiza el objetivo. Implica el uso de la tecnología de intercambio de datos DBREPLICATION. La solución es adecuada tanto para la opción de infraestructura tradicional como para Microsoft Azure basado en la nube. Brevemente, la esencia es la siguiente.
- Se crea un clon de la base de datos, el intercambio de datos unidireccional entre el clon y la base de datos principal se configura mediante DBREPLICATION. Está permitido que la base de datos principal y / o su clon estén ubicados (ambos o uno de ellos) en la nube de Microsoft Azure.
- En el clon, los usuarios no trabajan, allí comienza el proceso de convolución. Dado que el proceso de plegado no molesta a nadie, puede durar todo el día sin interrupciones durante el tiempo que sea necesario. ¡Por lo tanto, el enlace a la duración de la ventana tecnológica desaparece!
- Los usuarios sin interferencia trabajan en la base de datos principal. Y la tecnología DBREPLICATION transfiere automáticamente todos los cambios de la base de datos principal a la plegable a gran velocidad. Por lo tanto, el clon está actualizado en términos de datos operativos.
- Después de la finalización de la convolución, por regla general, se lleva a cabo una verificación detallada del resultado con la participación de especialistas técnicos y usuarios comerciales del Cliente. Y este proceso puede durar bastante tiempo (varias horas o días). En la metodología considerada, prácticamente no hay límite de tiempo, por lo tanto, la verificación se puede asignar tanto tiempo como sea necesario.
- Después de completar la convolución y la verificación, todos los usuarios cambian al clon recortado, y desde ese momento se convierte en la base principal. Y la base original no circuncidada sirve como un archivo de datos históricos.
- Una ventaja adicional es la capacidad de cambiar la replicación en la dirección opuesta cuando los usuarios cambian a una base de datos minimizada. Esto proporciona seguridad adicional, porque si "algo sale mal", puede cambiar rápidamente a los usuarios a la base de datos no circuncidada sin perder los datos ingresados.
- Si es necesario mantener actualizada la base de datos de archivo, puede cambiar la replicación en la dirección opuesta y transferir los cambios de la base de datos minimizada a la de archivo.
Fig.1. Diagrama esquemático del recorte de la base de datos utilizando la tecnología DBREPLICATION.
Fig.2. Opción para alojar bases de datos plegables en la nube de MS Azure.
Por lo tanto, la técnica de convolución descrita en la base de datos de clones expande todos los cuellos de botella. Elimina la dependencia de la ventana tecnológica. En el clon, el paquete no molesta a nadie, y nadie la molesta. Puede utilizar de forma segura los recursos máximos del clon y también prestar suficiente atención a la verificación final.
¿Queda por entender qué tecnología de intercambio se puede utilizar en este esquema? ¿Por qué DBReplication?
¿Por qué DBReplication?
En la metodología descrita, el elemento clave es la tecnología de intercambio, que garantiza la sincronización de la base de datos recortada con la principal. En principio, la tecnología de intercambio puede ser cualquiera si cumple tres condiciones clave esenciales:
- Compatibilidad con la plataforma de aplicaciones empresariales, cuya base se está derrumbando.
Ejemplo: si colapsamos la base de datos 1C, entonces no todas las tecnologías de intercambio son compatibles con la estructura base 1C, en particular, la clásica réplica de transacciones de MS no es compatible, ya que realiza cambios en la estructura de la tabla.
- Rendimiento Se debe garantizar que la tecnología de intercambio haga frente al flujo de cambios que ocurre en la base de trabajo durante la convolución.
Explicación: en este artículo, nos referimos principalmente a bases de datos altamente cargadas con una alta tasa de cambio de datos. La convolución durará docenas de horas, tal vez varios días, tal vez incluso habrá más de una iteración de la convolución. Durante este tiempo, los usuarios harán grandes cambios. Muchas tecnologías para compartir simplemente no pueden manejarlo. Y no solo necesita hacer frente, es recomendable hacer frente al suministro.
- La aplicabilidad principal a las condiciones del problema.
Explicación: tal vez este punto parece evidente, pero sin embargo podemos destacarlo. A saber: ¡no olvide que los datos en la base de datos de origen y en el clon no son iguales entre sí! Este hecho elimina automáticamente toda una clase de tecnologías potentes y productivas basadas en la sincronización de registros de transacciones, siempre activadas, envío de registros, duplicación, etc.
Además, la tecnología de intercambio debería ser efectiva en términos de otros indicadores:
- Fiabilidad y autonomía de funcionamiento. Dado que estamos hablando de la transferencia de grandes cantidades de datos, y durante un tiempo bastante largo, el equipo del proyecto simplemente no tendrá la capacidad física para lidiar manualmente con problemas de intercambio, colisiones y fallas, verificar la calidad de los datos, etc. Por lo tanto, la tecnología de intercambio debe ser lo más confiable posible en términos de calidad de los datos transmitidos, lo más autónoma y automatizada posible.
- Interfaces de usuario de calidad para control y gestión.
- Fácil de implementar y configurar. La tecnología de intercambio no debe imponer requisitos excesivamente altos en las calificaciones de especialistas para su ajuste.
Sin estas cualidades, la tecnología de intercambio amenaza con pasar de un elemento clave de ahorro de la metodología a su "eslabón débil", presenta serios riesgos y amenaza todo el proyecto. Y luego la idea original pierde su significado.
Sin embargo, la tecnología DBReplication ciertamente satisface todos los requisitos y garantiza el éxito del proyecto de resumen.
Tenga en cuenta los principales factores debido a los cuales DBReplication tiene éxito en esta tarea:
- Muy alto tipo de cambio. Tenga en cuenta algunas características que proporcionan velocidad:
- DBReplication es una replicación transaccional, cada cambio comienza a transmitirse inmediatamente después de que se confirma la transacción;
- La arquitectura interna del subsistema de transporte utiliza soluciones tales como el procesamiento paralelo de colas de subprocesos múltiples, un enfoque canalizado, compresión de flujo, procesamiento de transacciones por lotes, el uso de Bulk Insert y otros.
- Transporte implementado sobre la base de los servicios de Windows, equipado con muchas características para garantizar un funcionamiento sin problemas. Estos incluyen: recuperación automática de intercambio después de interrupciones de comunicación, trabajo en canales de comunicación débiles e inestables, procesamiento automático de conflictos de versiones (para intercambio bidireccional), adaptación automática en caso de cambios en la estructura de tablas de una aplicación comercial, y otros.
- Mecanismo de entrega de datos garantizado. Adhesión estricta a la integridad transaccional y consistencia en la transferencia de cambios.
- No modifica la estructura de la tabla de la aplicación empresarial. Por lo tanto, en particular, se puede usar con éxito al plegar bases de datos 1C.
- Interfaz de usuario desarrollada que le permite administrar centralmente el sistema de intercambio "desde una ventana", toda la información del servicio se recopila y se muestra en línea.
- Fácil de implementar y configurar.
- Adaptado para plataforma 1C. El usuario no trabaja con tablas, sino con objetos familiares de metadatos 1C.
- Cualquier versión de MS SQL, a partir de 2005, desde Standard hasta Enterprise, implementada localmente y ubicada en la nube de MS Azure; desde el punto de vista de Azure, se permiten tanto el alojamiento de máquinas virtuales como las opciones de alojamiento de Azure SQL DB, incluida una instancia administrada de Azure SQL Database ( instancia administrada ).
- DBReplication es una solución confiable lista para usar que ha sido probada por muchos proyectos en una variedad de condiciones y tareas.
- Si se utiliza DBREPLICACIÓN en el modo de intercambio unidireccional, se puede cambiar la dirección del intercambio.
Además, observamos una característica más importante:
- DBREPLICATION puede funcionar en un modo de intercambio bidireccional, cuando es posible ingresar / cambiar datos simultáneamente en todas las bases de datos que participan en el intercambio. El número de bases que se pueden incluir en el circuito de intercambio no está limitado.
Ejemplo de aplicación práctica
Una gran empresa rusa tiene un sistema de contabilidad de aplicaciones basado en la plataforma 1C 8 + MS SQL Server. La base operativa principal ha superado por mucho más de 2 terabytes y continúa creciendo. Al mismo tiempo, la carga aumenta cada vez más: tanto transaccional como analítica. Al final, se formaron varias razones para la convolución de la base. Se decidió recortar los datos históricos para principios de 2017. Se seleccionó la técnica descrita aquí usando DBReplication.
En sí mismo, el algoritmo de convolución se decidió implementar principalmente por TSQL con pequeñas inclusiones de herramientas típicas de 1C. La tarea se complicó por el hecho de que no todos los objetos aplicados (tablas) podían colapsarse en la fecha programada, ya que las características comerciales requerían que en varios de los subsistemas más grandes los datos históricos estuvieran presentes por completo en una profundidad de 5-7 años. Por lo tanto, desde el punto de vista del volumen de la base de datos, el efecto de la convolución no fue tan grande como nos gustaría. Se realizó un análisis preliminar, que mostró que, teniendo en cuenta las restricciones objetivas, se cortará aproximadamente el 33% del volumen inicial. Pero esto fue evaluado por el Cliente como un buen resultado, porque la ganancia no solo está en el volumen de la base de datos como tal, sino también en la velocidad de las tablas individuales, y las tablas de los subsistemas colapsados disminuyeron en volumen en más del 33%, del 46% al 77% (en 2- 3 veces)
Echemos un vistazo más de cerca a algunos indicadores y hechos del uso real de la convolución. La duración de la convolución directa de datos fue de aproximadamente 12 horas. La sincronización de los cambios acumulados usando DBREPLICATION tomó aproximadamente 1 hora. Uno de los puntos clave del proyecto fue la verificación final de la base minimizada, realizada por los especialistas del Cliente. Especialmente vale la pena señalar su duración: este proceso tomó aproximadamente 1 semana. Esta duración se debió al hecho de que la verificación fue muy profunda e integral, con la participación de especialistas de varios perfiles, incluida la construcción de un modelo de datos en un sistema externo. Todo este tiempo, la base minimizada se sincronizó automáticamente con la base de datos de combate actual a través de DBREPLICATION. La verificación fue exitosa. Y los usuarios fueron cambiados a una base de datos colapsada. La base de datos anterior se transfirió al estado de archivo, con acceso de solo lectura. No hubo necesidad de su posterior sincronización, por lo que se deshabilitó la replicación.
Resumen del proyecto:
- La técnica aplicada valió la pena por completo, gracias a ella hubo tiempo suficiente para completar la propia circunvolución, así como para verificar exhaustivamente los datos, lo que minimizó radicalmente los riesgos de omitir ciertos errores y cambiar a una base de datos colapsada.
- Convolución completada con éxito:
- El volumen total de la base de datos operativa disminuyó en un 33%. No fue posible lograr un mayor efecto en el volumen de la base de datos por razones objetivas, debido a restricciones en el plegamiento de algunos subsistemas grandes.
- El volumen de las tablas de subsistemas colapsados utilizados activamente disminuyó en un 46-77% (2-3 veces).
Conclusión
DBReplication es una solución confiable lista para usar que ha estado presente en el mercado durante muchos años, probada por muchos proyectos en una variedad de condiciones. En la técnica de convolución en consideración, DBReplication asume completamente una de las subtareas clave: la sincronización de la base de datos. En el caso de bases de datos particularmente grandes, se imponen requisitos muy estrictos al sistema de intercambio, y DBReplication los satisface por completo. Resuelve su tarea de manera confiable y eficiente, asegurando así el éxito del proyecto en su conjunto.
¿Para qué otras tareas puedes usar DBREPLICATION?
Un conjunto de características y ventajas competitivas permite utilizar DBReplication para resolver una serie de problemas. Como referencia, los enumeramos.
- Redundancia de bases de datos y tolerancia a fallos.
- Equilibrio de carga: redistribuirlo entre 2 o más instancias de base de datos síncronas.
- Transición controlada a nuevas versiones de software (MS SQL, 1C), la técnica es similar a la técnica de convolución.
- Creación de un sistema de información distribuido con intercambio de alta velocidad basado en DBReplication. En particular, reemplazando la tecnología de intercambio de la compañía existente por una más productiva y eficiente: DBREPLICACIÓN.