¿Su enmascaramiento de datos estáticos tarda días cuando debería tardar minutos? En el mundo ágil con plazos de entrega rápidos, este es un problema que paraliza el desarrollo y es más común de lo que la mayoría de las organizaciones admiten. Muchas empresas terminan con software de almacenamiento: soluciones de enmascaramiento costosas que no se utilizan porque tardan demasiado en ejecutarse.

Una solución de enmascaramiento disfuncional no solo significa un desperdicio de dinero. También significa que no puede enmascarar sus datos. Esto puede tener dos consecuencias indeseables: o los equipos de pruebas y desarrollo continúan utilizando datos confidenciales (un grave problema de seguridad), o no se les permite realizar pruebas con datos reales, lo que se traduce en software de menor calidad y una entrega más lenta.

Pero, ¿Qué es exactamente lo que hace que el enmascaramiento sea lento y cómo puede superar el límite de velocidad?

El Desafío Principal: Actualizaciones

En esencia, el desafío subyacente reside en el funcionamiento de las bases de datos. El enmascaramiento estático requiere una sentencia SQL individual para actualizar cada valor. Al enmascarar millones de filas, se le pide a la base de datos que realice millones de pequeñas actualizaciones.

El enmascaramiento de alta velocidad depende de dos factores: su entorno y la implementación de la solución. Analicemos los detalles y analicemos los detalles: ¿Cómo puede el enmascaramiento de datos funcionar rápidamente?

Implementación del Software

La implementación del software que utiliza puede tener un efecto drástico en la velocidad del enmascaramiento. Aunque estos detalles rara vez se presentan a los clientes, revisaremos algunos trucos que hacen que algunas soluciones funcionen mucho más rápido que otras.

Eliminando la fase de «Planificación»

Las bases de datos analizan cada SQL para crear un plan de ejecución. El análisis toma fracciones de segundo que se acumulan rápidamente al ejecutar millones de ellos.

Al usar variables de enlace en lugar de incrustar valores sin procesar directamente en la cadena SQL, la base de datos puede reutilizar el mismo plan de ejecución para todos los SQL. Volver a ejecutar el mismo plan con diferentes valores puede reducir drásticamente el tiempo de ejecución.

Direccionamiento Directo de Datos

Cuando se ejecuta el SQL, necesita localizar la fila que desea actualizar. Si bien los índices son la forma estándar de encontrar datos, también implican un proceso de búsqueda. Muchas bases de datos ofrecen accesos directos para acceder a los datos directamente. Por ejemplo, en un entorno Oracle, el uso de ROWID permite a la base de datos acceder directamente al bloque de datos específico que almacena la fila. Omitir por completo los índices con direccionamiento directo ayuda a ahorrar tiempo valioso.

Superando la Latencia

El mayor límite de velocidad no suele estar en la base de datos en sí, sino en las conexiones de red. Si envía una sentencia SQL a la base de datos, espera la respuesta «Éxito» y luego envía la siguiente, está sujeto a la latencia de la red. Multiplicadas por millones de filas, esas pequeñas fracciones de segundo de espera para que los paquetes viajen de ida y vuelta se convierten en días.

La solución es la vinculación de matrices. En lugar de una sola solicitud a la vez, una solución de enmascaramiento puede enviar miles de variables de vinculación en una sola solicitud de red. El servidor las ejecuta en un flujo continuo sin el parloteo de ida y vuelta que reduce el rendimiento.

Prueba de la Caja Negra

Hasta ahora, hemos analizado algunos detalles de implementación de soluciones de enmascaramiento. Si bien existen trucos adicionales, dependientes de la plataforma, que permiten que los trabajos de enmascaramiento finalicen rápidamente, no se puede revisar ni controlar la implementación de la solución.

Sin embargo, se puede probar fácilmente el funcionamiento del producto final. Cuando una solución está bien construida, enviando miles de actualizaciones en una sola solicitud con direccionamiento directo y otras optimizaciones, se pueden enmascarar millones de filas en menos de un minuto.

Sin embargo, para validar correctamente una solución, se debe probar en condiciones reales. Esto implica enmascarar grandes conjuntos de datos a través de una conexión de red remota.

Idealmente, también se deben realizar pruebas con los datos que se planea enmascarar. No se trata de cómo se construye la solución, sino del problema desencadenante que abordaremos a continuación.

Los Frenos Ocultos: Triggers

Incluso con una implementación perfecta y sin latencia de red, aún existe un obstáculo importante: los triggers.

Los triggers son pequeños fragmentos de código que se activan automáticamente al modificar los datos. Suelen ser vitales para la integridad de los datos o para mantener las tablas sincronizadas, lo que significa que no se pueden desactivar sin más. Sin embargo, ejecutar estos scripts millones de veces puede convertir un trabajo de enmascaramiento rápido en un proceso lento.

Un administrador de bases de datos (DBA) puede indicarle si tiene desencadenadores en las tablas que desea enmascarar. Esa es la parte fácil. Sin embargo, resolver el problema de los desencadenadores es un desafío mucho mayor.

Resolviendo el Problema de los Triggers

No existe una solución mágica para los triggers, pero hay un camino que puede seguir:

1. Descubrimiento: Identifica los desencadenadores que se activan en las tablas que enmascaras. No es muy complicado, pero puede ser complicado, ya que un desencadenador puede provocar que otro también se active.
2. Análisis: Entiende esos desencadenadores. ¿Se relacionan con las columnas que estás enmascarando? Si es así, ¿qué hacen?
3. Solución: Crea una «actualización vertical» que ejecute la lógica del desencadenador en toda la columna en una sola operación, en lugar de millones de veces fila por fila. Por ejemplo, un desencadenador podría combinar el nombre y los apellidos en un campo full_name. Al ejecutarse en un desencadenador, cada fila ejecutaría código y una sentencia SQL independiente. Una actualización vertical puede actualizar toda la tabla en una sola sentencia SQL:
   update employees set full_name = first_name || ‘ ‘ || last_name;

Rastrear manualmente los desencadenadores puede parecer complicado. Ahí es donde las funciones de monitorización en vivo de Core Audit marcan la diferencia. En lugar de seguir el proceso, puede ver la actividad interna de la base de datos en tiempo real. Simplemente ejecute una actualización de prueba y observe exactamente qué SQL se activan. De esta forma, podrá identificar fácilmente la función de los desencadenadores y, en la mayoría de los casos, omitir los pasos 1 y 2.

Más Allá del Límite: Optimizaciones Adicionales

Todo lo mencionado hasta ahora ayudará a que el enmascaramiento de datos funcione excepcionalmente rápido. Sin embargo, si está enmascarando volúmenes masivos de datos, puede considerar ir un paso más allá optimizando su base de datos.

Las bases de datos normalmente se configuran para leer datos, no para escribirlos. El enmascaramiento es una operación de escritura de alta intensidad. Por lo tanto, optimizar la configuración de su base de datos para el rendimiento de escritura ayudará a que su base de datos supere aún más las barreras de velocidad. Sin embargo, esto solo es efectivo si todo lo demás ya está optimizado para la máxima velocidad.

Algunos ejemplos comunes de optimización de escritura:

• Elimine los índices de las columnas que enmascara antes de enmascarar y vuelva a crearlos después. Este es un truco común y sencillo para mejorar el rendimiento de escritura.
• Desactive temporalmente los registros de rehacer o el registro de transacciones para toda la base de datos o para la tabla que está enmascarando. Las operaciones de escritura generan mucha actividad de registro de rehacer, lo que consume muchos recursos.

Reflexión Final: Contrata un Socio, No Solo Una Licencia

Lograr que un trabajo de enmascaramiento se ejecute rápidamente puede requerir algo de esfuerzo, pero es totalmente posible. Sin embargo, es algo en lo que debe esperar que su proveedor le ayude.

En Blue Core Research, no solo le brindamos las soluciones que necesita. También le ayudamos a resolver los problemas que enfrentará. Al invertir en Core Masking, utilizaremos toda nuestra experiencia y recursos para garantizar que nuestras soluciones le brinden todo lo que necesita. Esto incluye aprovechar el poder de Core Audit para ayudarle a resolver las ralentizaciones relacionadas con los desencadenantes.

Como con cualquier producto, Data Masking se centra en la solución que compra y la empresa que la respalda para garantizar su éxito.