Purga

Descripción general

El propósito de ODS La purga consiste en eliminar todos los datos persistidos (UnitOfWork,Summary,MdsObjects,PdsObjects,ProcessObjects,CustomObjects) asociado con un identificador de unidad de trabajo que es más antiguo que un período configurado. ODS no está destinado a ser una solución de persistencia a largo plazo, por lo que los datos deberán ser eliminados después de un cierto punto para evitar implicaciones de almacenamiento masivo.

Existen dos modos de purga, ESTÁNDAR que debe utilizarse cuando la base de datos subyacente es mongo y TTL cuando la base de datos subyacente es cosmos. La elección de uno de ellos se realiza configurando el siguiente valor de configuración.ods.purging.mode desde el configuración.

PURGA ESTÁNDAR

Conceptos Clave

El ODS la implementación de purga utiliza un Akka Cluster Singleton y un Akka Programador el rendimiento del sistema. Se recomienda eliminar datos con frecuencia en pequeños lotes. Estas eliminaciones frecuentes ocurrirán periódicamente a lo largo del día, generándose y actualizándose un Informe de Purga a medida que se elimine la información. El objetivo es eliminar todos los datos necesarios sin afectar ODS-Ingesta.

Período de Retención

El período de retención es un intervalo de tiempo basado en una fecha configurable que se utiliza para determinar si los datos persistidos cumplen con uno de los criterios para la purga. Por defecto, esto se establece en 2 años; por ejemplo, si la purga se está ejecutando el 17/05/23, el período de retención sería: 17/05/21.- 17/05/23.

El límite inferior del período de retención es la fecha de ejecución de la purga, por ejemplo, 2023-05-17, menos el período de retención, por ejemplo, 2 años, y al inicio del día en UTC, resultando en 2021-05-17T00:00:00. 000Z.

Una unidadDeTrabajo se considera fuera del período de retención cuando su finishedAt el campo está antes del límite inferior del período de retención.

Campos de UnitOfWork: startedAt, finishedAt, archivedAt

Los campos unitOfWork startedAt y finishedAt están poblados con marcas de tiempo de ciertos ProcessFlowEvents que son ingeridos por ODS.startedAt se mapea desde el primero ProcessFlowEvent ingestado para un unitOfWorkId.finishedAt se mapea desde el ProcessFlowEvent ingresado que indica que la unidadDeTrabajo ha alcanzado un estado global terminal. Si la aplicación ipf-archiver-application está desplegada, el unitOfWork archivedAt el campo se completará cuando una unidadDeTrabajo y todos sus relacionados ODS Los objetos han sido archivados.

Criterios de depuración

Una unitOfWork será purgada si ocurre fuera del período de retención; la fecha y hora utilizadas para determinar esto dependen de la terminal-unit-of-works-only configuración.

El terminal-unit-of-works-only la configuración es true
- La unidadDeTrabajo finishedAt es antes del límite inferior del período de retención
El terminal-unit-of-works-only la configuración es false
- La unidadDeTrabajo finishedAt es antes del límite inferior del período de retención
- SI La unidadDeTrabajo finishedAt no existe, entonces el unitOfWork startedAt es antes del límite inferior del período de retención

Si el configurado terminal-unit-of-works-only es falso, la funcionalidad de purga incluye unitOfWorks no terminales.

Tipos de viaje dependientes archivados

El archived-dependent-journey-types config se utiliza para definir el unit of work Tipos de viaje que deben haber sido archivados antes de que puedan ser elegibles para su eliminación. Por ejemplo, si se establece en ["PAYMENT"], unit of work Los s con journeyType == PAYMENT deben haber sido archivados antes de que puedan ser eliminados.

Los tipos de viaje que no están definidos en esta lista pueden ser eliminados sin ser archivados, siguiendo los otros criterios de eliminación definidos anteriormente.

Si no archived-dependent-journey-types se definen, todos los tipos de viaje cumplirán con este criterio para la purga.

Los siguientes ejemplos suponen una fecha de ejecución de 2023-05-17 y un período de retención de dos años, con un límite inferior de 2021-05-17.

Tabla 1. Ejemplos
UnidadDeTrabajo	Terminales configuradosUnitOfWorksOnly	TiposDeViajeDependientesArchivadosConfigurados	¿Purificado?	Notas
started at:`2021-05-16` terminado en:`2021-05-16`	`false`	[]	SÍ	La unidadDeTrabajo finalizó antes del límite inferior del período de retención.
comenzó en:`2021-05-17` terminado en:`2021-05-17`	`false`	[]	NO	La unidadDeTrabajo finalizó dentro del límite inferior del período de retención.
comenzó en:`2021-05-16` terminado en:`null`	`false`	[]	SÍ	La unidadDeTrabajo no ha finalizado y ha comenzado antes del límite inferior del período de retención.
comenzó en:`2021-05-16` terminado en:`2021-05-16`	`true`	[]	SÍ	La unidadDeTrabajo finalizó antes del límite inferior del período de retención.
comenzó en:`2021-05-17` terminado en:`2021-05-17`	`true`	[]	NO	La unidadDeTrabajo finalizó dentro del límite inferior del período de retención.
comenzó en:`2021-05-16` terminado en:`null`	`true`	[]	NO	La unidadDeTrabajo no ha finalizado y ha comenzado antes del límite inferior del período de retención.
comenzó en:`2021-05-16` finalizado en:`2021-05-16` archivedAt:`2021-05-16` tipoDeViaje:`PAYMENT`	`true`	["PAGO"]	SÍ	La unidad de trabajo finalizó antes del límite inferior del período de retención y ha sido archivada.
comenzó en:`2021-05-16` terminado en:`2021-05-16` archivedAt:`null` tipoDeViaje:`PAYMENT`	`true`	["PAGO"]	NO	La unidadDeTrabajo finalizó antes del período de retención, pero no ha sido archivada.
comenzó en:`2021-05-16` terminado en:`2021-05-16` archivedAt:`null` tipoDeViaje:`RECALL`	`true`	["PAGO"]	SÍ	La unidadDeTrabajo finalizó antes del límite inferior del período de retención. El tipo de viaje RECALL no está especificado en la configuración, por lo tanto, no importa si este pago ha sido archivado o no.

Ejecución Recurrente

Para gestionar mejor la carga de la base de datos y el manejo de excepciones, la ejecución de la purga se divide en muchas purgas más pequeñas que ocurren periódicamente a lo largo del día. Al inicio del día, una InformeDePurga se persistirá en la base de datos. Luego, utilizando una frecuencia configurada, se llevarán a cabo purgas recurrentes más pequeñas de un tamaño configurado. Estas purgas más pequeñas continuarán ejecutándose hasta que se haya eliminado toda la información necesaria.

Informe de Purga

Los detalles de la ejecución de una purga se persisten como un PurgeReport. Cada día, se creará un nuevo PurgeReport, y luego se actualizará a lo largo de la ejecución de la purga.

public final class PurgeReport {
    private LocalDate executionDate;
    private Period retentionPeriod;
    private Instant retentionPeriodLowerBound;
    private boolean terminalUnitOfWorksOnly;
    private List<String> archivedDependentJourneyTypes;
    private long summariesToDelete;
    private long summariesDeleted;
    private Instant startedAt;
    private Instant finishedAt;
    private Duration duration;
}

Tabla 2. Resumen del Informe de Purga
Field	Description	Example
executionDate	The date which this purge was executed. This will be unique for each PurgeReport	2021-05-17T00:00:00.000Z
retentionPeriod	The configured `retentionPeriod` for this purge execution	P2Y
retentionPeriodLowerBound	The date-time lower bound for the retention period. A unit-of-work-id passes one of the criteria to be purged if its `Summary.lastUpdated` date-time is less than the `retentionPeriodLowerBound`	2021-05-17T00:00:00.000Z
terminalUnitOfWorksOnly	The configured `terminal-unit-of-works-only` flag for this purge execution. If configured to `true` only unit-of-work-ids that have reached a terminal global status will be eligible for purging	false
archivedDependentJourneyTypes	The configured `archived-dependent-journey-types` for this purge execution. Unit of works with journey types defined in this config must be archived before being eligible for purging	[PAYMENT, RECALL]
unitOfWorksToDelete	The number of Summary documents that have been identified as outside the retention period and should be deleted during this purge execution	1234567
unitOfWorksDeleted	The number of Summary documents that have actually been deleted. This value is incremented as the purge is ongoing	1234567
startedAt	The date-time at which purging began for this execution date (will nearly always be the start of the day)	2023-05-17T00:00:02.170Z
finishedAt	The date-time at which all the data that should be deleted for a given execution date has been deleted	2023-05-17T00:32:03.180Z
duration	The duration of time taken to complete a purge. Calculated by comparing the `startedAt` and `finishedAt` fields	PT32M1.01S

Uso ODS la purga solo se realiza dentro del `ods-ingestion` aplicación, y está deshabilitada por defecto

Para habilitar la purga, establezca el siguiente valor de configuración:`ods.purging.enabled = true`.

Con esto habilitado, el Akka Cluster Singleton se configurará y la funcionalidad de purga comenzará a ejecutarse periódicamente de acuerdo con la configuración establecida.

Más información sobre otros ODS La configuración de purga se puede encontrar a continuación.

Implementación

Ods Puerto de Purga de Persistencia

Cualquier implementación de purga debe proporcionar un Spring Bean para el PurgingOperations interfaz definida en ods-persistence-purging-port. Estos son métodos de base de datos que deben consultar, actualizar y eliminar datos del tipo de base de datos que se utilice.

OperacionesDePurgaMongo

Actualmente, IPF-ODS apoya MongoDB y Azure CosmosDB. Por lo tanto, la implementación predeterminada de la PurgingOperations la interfaz es la clase MongoPurgingOperations. Esto utiliza mongodb-reactivestreams-client biblioteca para interactuar con el ODS colecciones.

Purgador

Cualquier implementación de purga debe proporcionar un Spring Bean para el Purger interfaz. Por defecto, una instancia de la DefaultPurger se utiliza la clase. DefaultPurger`utiliza el `MongoPurgingOperations Bean y cuando el purge() método es triggered, hace lo siguiente:

Depuración de un único id-de-unidad-de-trabajo

Un único IPF-Flow generará muchos ODS objetos que se persisten en múltiples colecciones. Estos objetos serán: un único UnitOfWork, un solo Summary, y múltiples MdsObjects,PdsObjects,ProcessObjects, y CustomObjects, que están todos vinculados por un identificador de unidad de trabajo único generado por IPF. Para que un identificador de unidad de trabajo se considere purgado con éxito, todos los datos relacionados con ese identificador de unidad de trabajo deben ser eliminados.

Para asegurar que esto ocurra correctamente en ODS purga, el Summary, todo el MdsObjects,PdsObjects,ProcessObjects, y CustomObjects para un identificador de unidad de trabajo dado se eliminan antes de eliminar su UnitOfWork.

Manejo de Errores

Debido a la naturaleza de la implementación de purga, los errores con la eliminación se reintentan de forma natural en la siguiente ejecución recurrente. Sin embargo, el PurgeReport persistido debe mantenerse lo más actualizado posible. Por lo tanto, se han implementado escrituras reintentables para cualquier operación de base de datos que escriba en la colección purgeReports.

Cualquier error generado durante la ejecución de la purga se registra como una advertencia sin que se tome ninguna acción. La purga se ejecutará nuevamente en breve y los datos que failed para purgar previamente se recogerá en ejecuciones posteriores.

Akka Cluster Singleton

A Cluster Singleton se utiliza para ejecutar la purga recurrente. El PurgingSchedulerSingleton la clase está registrada como un Spring Bean al iniciar. Esto configura un Singleton Actor con un Akka Scheduler.

Este Akka Scheduler toma una instancia de la Purger interfaz y activa una purga, al llamar a la Purger.purge() método, a una tasa definida por el configurado frequency. Por defecto, esta frecuencia está configurada para activarse cada 1 segundo.

Rendimiento de Eliminación

El rendimiento de eliminación se define configurando la frecuencia y el tamaño de recuperación. Si la frecuencia es de 1 segundo y el tamaño de recuperación es de 500, entonces ODS intentará eliminar 500 unitOfWorks cada segundo.

Eliminar 500 unitOfWorks por segundo puede no ser alcanzable, dependiendo de los recursos de la base de datos disponibles y de la carga de ingestión en el momento de la eliminación. La eliminación también tendrá un impacto (a veces significativo) en la ingestión.

Cada ejecución (cada segundo) encuentra 500 unidades de trabajo candidatas, las agrupa en lotes de aproximadamente 62 (asumiendo un paralelismo de 8) y realiza 4 operaciones de eliminación, pasando a cada una la lista de 62.unit of work ids. Eliminando el resumen, el proceso,MDS, PDS, y custom Los objetos se procesan de manera concurrente, y cuando estos han finalizado, se eliminan las unidades de trabajo.

La latencia total de eliminación es la suma de la mayor latencia de eliminación entre resumen, proceso,MDS, PDS, y custom, además de la latencia de eliminación para unitOfWorks.

Enfoques Posibles

Existen algunos enfoques diferentes, con distintas implicaciones.

Elimine la mayor cantidad posible de unidades de trabajo candidatas al inicio del día

El objetivo es eliminar todas las unidades de trabajo de candidatos antes de que ocurra cualquier carga de ingestión.

Dado un tamaño de recuperación de 500 y una frecuencia de 1, ODS podría teóricamente eliminar 5. 4 millones de unidades de trabajo candidatas entre las horas de 12 a.m.- 3 a.m., cuando la carga de ingestión sería baja o nula.

Si hay una carga de ingestión significativa durante este período, el impacto en el rendimiento de la ingestión también será significativo, al igual que el impacto en el rendimiento de la eliminación.

Este enfoque se basa en que las operaciones de eliminación tengan una latencia lo suficientemente baja, de modo que todos los datos de las 500 unidades de trabajo puedan ser eliminados en un segundo.

Si la latencia de eliminación general (la mayor latencia de eliminación entre el resumen, el proceso,MDS, PDS, y custom más la latencia para eliminar las unitOfWorks) excede 1 segundo, las ejecuciones subsiguientes se encolarán.

Tabla 3. Ejemplos
Rendimiento de Eliminación/s	Tiempo para eliminar 1 millón de unidades de trabajo (h:m:s)
100	2:46:40
200	1:23:20
500	0:33:20

Elimine un pequeño número de unidades de trabajo candidatas a lo largo del día

El objetivo es eliminar lentamente a lo largo de todo el día, evitando el impacto en el rendimiento de la ingesta.

Dado un tamaño de recuperación de 40 y una frecuencia de 1, ODS podría teóricamente eliminar 3. 4 millones de unidades de trabajo candidatas a lo largo del día.

ODS siempre está eliminando (suponiendo que quedan candidatos), incluso cuando la carga de ingestión es alta.

Estas eliminaciones frecuentes pero pequeñas pueden seguir afectando la ingesta de alto rendimiento.

Tabla 4. Ejemplos
Rendimiento de Eliminación/s	Eliminado en 24 horas
15	1, 296, 000
20	1, 728, 000
40	3, 456, 000

Enfoque Preferido

El enfoque preferido, y actualmente por defecto, es eliminar pequeños lotes de candidate unitOfWorks con frecuencia, a lo largo de todo el día.

En las pruebas contra CosmosDB, no se pudo lograr un alto rendimiento de eliminación con la implementación actual, debido a la alta latencia de las operaciones de eliminación. Eliminar a 40tps introdujo un retraso en la ingesta con solo 300tps de rendimiento de ingesta, y a 500tps, el retraso en la ingesta aumentó y continuó en ascenso. Para las implementaciones de CosmosDB, se recomienda un tamaño de recuperación mucho más bajo, algo como 16.

En las pruebas contra MongoDB, se podía lograr un rendimiento de eliminación de aproximadamente 1000tps, pero para evitar un impacto significativo en la ingestión, se recomienda un rendimiento de eliminación de 500tps. Optar por un número menor, por ejemplo, 40tps, es probablemente preferible, para distribuir la carga de eliminación a lo largo del día.

En última instancia, dependerá de los recursos de la base de datos disponibles y de los requisitos del cliente. Algo intermedio entre los enfoques anteriores podría ser más adecuado.

Purga de TTL

La funcionalidad de tiempo de vida (TTL) permite que la base de datos expire automáticamente los datos. El modo de purga TTL debe ser utilizado cuando se despliega la base de datos cosmos.

Establezca el valor de tiempo de vida para una colección

Para habilitar el TTL de manera universal en una colección, se debe crear un "índice TTL" (índice de tiempo de vida). El índice TTL es un índice en el campo _ts con un expireAfterSeconds valor. Una vez que se crea el índice, la base de datos eliminará automáticamente cualquier documento en esa colección que no haya sido modificado en los últimos expireAfterSeconds segundos.

Establezca el valor de tiempo de vida para un documento

Los valores TTL por documento también son compatibles. El/los documento(s) deben contener una propiedad de nivel raíz "ttl" (en minúsculas), y debe haberse creado un índice TTL como se describió anteriormente para esa colección. Los valores TTL establecidos en un documento anularán el valor TTL de la colección.

Se han implementado algunas características de mantenimiento en el modo de purga TTL y puede encontrar más información aquí.Trabajo de mantenimiento de purga TTL.

Configuración Predeterminada

ods {
  purging {
    enabled = false
    mode = STANDARD
    retention-period = 2Y
    terminal-unit-of-works-only = false
    archived-dependent-journey-types = []

    frequency = 1s
    fetch-size = 16
    parallelism = 8
  }
}

Tabla 5. Descripción general de la configuración de purga
Clave de Configuración	Descripción
`ods.purging.enabled`	A flag para habilitar o deshabilitar ODS purga. Ya sea `true` or `false`
`ods.purging.mode`	Modo de purga. Ya sea `STANDARD` or `TTL`
`ods.purging.retention-period`	El período de retención para la ejecución de purgas. Un período de tiempo basado en fechas, por ejemplo, 1A = 1 año, 1M = 1 mes, 1S = 1 semana.
`ods.purging.terminal-unit-of-works-only`	A flag para permitir que el purgador solo purgue unitOfWorks que han alcanzado un Estado Global Terminal. O bien `true` or `false`.
`ods.purging.archived-dependent-journey-types`	Una lista utilizada para definir los tipos de viaje de unitOfWork que deben ser archivados antes de ser elegibles para la purga. Las opciones de tipo de viaje son `PAYMENT`,`RECALL`,`BULK` y `BATCH` Por defecto, todos los tipos de viaje, archivados o no, cumplirán con este criterio para la purga.
`ods.purging.frequency`	La frecuencia con la que ocurren las ejecuciones recurrentes. Una cantidad de tiempo basada en el tiempo, por ejemplo, 2S = 2 segundos, 1M = 1 minuto.
`ods.purging.fetch-size`	El número de unitOfWorks que se eliminarán en una ejecución.
`ods.purging.parallelism`	El número de lotes de unitOfWorks que se deben eliminar de manera concurrente. Si el `fetch-size` is `40`, y el `parallelism` is `8`, habrá 8 lotes de 5 unitOfWorks que se deben eliminar en una ejecución,

ods.purging.fetch-size`y `ods.purging.frequency se utilizan juntos para determinar el número de unitOfWorks que deben ser eliminados y con qué frecuencia. Si ods.purging.fetch-size = 1000, y ods.purging.frequency = 1s, ODS intentará eliminar 1000 unitOfWorks (y todos los relacionados ODS objetos) por segundo.