En los últimos 10 años, VTB ha experimentado un aumento masivo en la carga informática. Cada año, aumentó una vez y media, y el volumen de credenciales: dos. Los servicios de soporte se esforzaron mucho, pero mantener este ritmo no fue fácil: los planes de consulta se estaban alejando, el espacio en disco se estaba agotando, las actualizaciones del código de la aplicación estaban consumiendo todos los recursos. En esta publicación, le mostraremos cómo resolver el problema sin gastar mucho en otro Sistema IBM pág.
En 2013, el procesamiento de tarjetas, que todavía era el banco VTB24, se encontraba en uno de los servidores más potentes de la época: IBM System p. Esto se complementó con réplicas para diferentes informes. Las réplicas para informes vivían en equipos adicionales: una base de datos actualizada todas las noches para informes diarios, herramientas para la réplica activa de Oracle Active Data Guard para informes operativos y una base de datos para informes del Banco Central, que actualizamos mensualmente.
Personalizamos activamente la funcionalidad de los sistemas: la mayor parte del código de la aplicación estaba ocupado por mejoras internas. Al mismo tiempo, los datos crecieron muy rápidamente. Como resultado, el plan de consulta para cuatro bases se deterioraba regularmente. Los sistemas frontales eran lentos. Desde una perspectiva técnica, había una dificultad más: la carga OLTP de transacciones con tarjeta se mezcló con la carga DWH / DSS de funcionalidad e informes personalizados.
La forma estándar de salir de esta situación es volcar recursos y cambiar a un subsistema de almacenamiento de datos más empinado. Se nos ocurrió una opción más interesante: tomamos para informar réplicas de dos complejos de hardware y software de Oracle Exadata optimizados para la operación de la base de datos.
El complejo de procesamiento se dividió en zonas "cálidas" y "calientes". La zona activa no se ha movido a ninguna parte con IBM System p, y solo su base de datos se ha conservado en ella. La zona "cálida" era una copia de la base de datos principal en Exadata. Aquí estaban todos los informes y la funcionalidad personalizada. Datos replicados usando Oracle GoldenGate.
Realizamos pruebas de réplica en Exadata: en promedio, los informes se volvieron cinco veces más rápidos gracias a la arquitectura y las características del software Oracle Exadata Storage: escaneos inteligentes, índices de almacenamiento, filtros de floración, etc. El tiempo necesario para preparar informes para el Banco Central se redujo en un factor de diez, y ahora algunos informes se preparan en menos de 1 hora. Lo principal que había que hacer para optimizar las consultas durante la transferencia a Exadata era eliminar las sugerencias que anteriormente ayudaban a trabajar en la plataforma anterior.
Llevamos a cabo un estudio de viabilidad, comparando opciones para varios parámetros con la extensión habitual de los sistemas actuales y con la participación de dos complejos Exadata.
- Rendimiento 40 mil IOPS versus 400 mil IOPS en Exadata. La solución de Oracle está orientada a grandes cantidades de datos, el escaneo completo de la tabla es mucho más rápido.
- Opciones de personalización. En la solución estándar, no podemos cambiar la estructura de los objetos sin cambiar la base de datos productiva, esto está prohibido por el proveedor. En Exadata, podemos eliminar índices innecesarios, agregar los necesarios y mejorar la respuesta del sistema.
- Escalado Exadata proporciona un aumento lineal de la productividad a un costo relativamente menor.
- Informes La velocidad de los informes con el complejo Exadata aumenta en 5 veces, y con la escala de los sistemas existentes, en 1.5.
- Servicio. La infraestructura de Oracle tiene soporte técnico unificado, un sistema de actualización único para servidores, subsistemas de disco e infraestructura de red. Con el escalado normal, debe trabajar con diferentes proveedores: hay más tiempo de inactividad y cualquier otro inconveniente.
- Costo Exadata gana aquí.
Al principio, la replicación de GoldenGate resultó ser un punto débil: en el caso de transacciones largas en la fuente, se retrasó. Resolvimos esto actualizando y refinando algunos procesos de aplicación. Después de eso, trabajar con Exadata solo nos reveló ventajas.
Introdujimos índices y particiones personalizados, lo que nos permitió aumentar el rendimiento de las funciones personalizadas. IBM no permite esta optimización.
La transferencia de informes analíticos a la zona "cálida" permitió reducir la profundidad de almacenamiento de datos históricos de la zona "cálida". Esto ha reducido el costo del almacenamiento costoso. Gestionado para acelerar la inserción en índices. La eliminación de datos a través del módulo de limpieza se filtró a nivel GoldenGate, como resultado, la réplica tenía datos nuevos y toda la historia;
Exadata utiliza compresión de columna híbrida (HCC), y esto ahorra espacio en disco de manera significativa. Los datos de más de un año se comprimen por el método de archivo bajo, más de un mes por el método de compresión avanzado, los datos más nuevos no se comprimen para aumentar la velocidad.
En cuanto a la actualización, es más eficiente reemplazar celdas de almacenamiento completas en Exadata con celdas con discos más potentes y procesadores potentes. Pero puede usar celdas de almacenamiento de diferentes versiones dentro del mismo sistema; Oracle lo permite.
Los informes de procesamiento de tarjetas, implementados en las tecnologías Oracle Exadata y Database, han funcionado bien hasta ahora, y se están construyendo nuevos sistemas bancarios con el mismo principio.