Estrategias de reindexado [v3.08]

Alcance

Este documento describe los aspectos a tener en cuenta para el reindexado del sistema, considerando los cambios en la versión 3.08.

Tratamiento de índices

Debido a los cambios aplicados en el código, se requiere considerar los siguientes acomodos en un entorno cuyos datos sean previos a la v3.08:

StepIndex (Traslados)

Debido a que se añadió un nuevo atributo opcional, cancelled, se recomienda reindexar todos los Steps que sean coincidentes con este atributo (cancelled = true).

Se asume que son una ínfima minoría del universo de Traslados.

ShippingIndex (Envios)

En la v3.08 se añadió el segundo factor de ordenamiento de StepStates, el cual surgió como solución ante StepStates duplicados, basados en su atributo date (DateTime).

Por lo tanto se recomienda, hallar1 solamente envios afectados por StepStates duplicados y reindexar ese subconjunto, en la ventana de tiempo que se considere más conveniente.

ClientStaticsDay (Estadisticas de Cliente)

En la última versión se realizaron múltiples modificaciones a los criterios de cálculos y/o correcciones sobre los mismos. Debido a ello, se deberá reindexar todas las estadísticas de cliente en la ventana de tiempo que se considere necesario.

Estrategias

En este apartado se proponen algunas “recetas low-cost” para reindexar información masiva, según sea el escenario.

Vale recalcar existe una fuerte dependencia entre ClientStaticsDay y ShippingIndex, dado que las Estadisticas se calculan a partir de las Entradas de ShippingIndex, además algunas terceras, como es el caso de los ZipCodes (MySQL).

Entorno sin impacto de eventos

Contando con un Entorno sin que sea receptor de avisos de estados y/o cambios en las principales configuraciones, que ejecuten lógica de negocio (Reglas de Estados, Configuración de Cliente,..), se busca acomodar masivamente las estructuras persistidas en MongoDb (índices). Tras ese acomodo, se puede reactivar ese entorno, o bien se puede usar sus estructuras para actualizar un tercer entorno crítico y/o productivo (lease como producción).

Para llevar a cabo esto, requiere tener definido una ventana de tiempo (periodo) deseable de indexación, y en base a ello seguir los siguientes pasos:

1. Apagar los servicios (Supervisors, Crons, Services de SystemD) del S.O. que sean productores de:

   1. ShippingIndex:
      app1:api:shippings:index
   2. ClientStaticsDays:
      app1:api:client:statics
      app1:api:shipping:statics
      app1:api:client:statics:refresh (añadido en v3.08)

2. Borrar las entradas de ClientStaticsDays comprendidas por el rango a actualizar.

3. [OPCIONAL] Considerar añadir más Instancias de consumidores de ShippingIndex
   (*swarrot:consume:shipping _index_add) si la cantidad de entradas de Envios afectados, supera con creces los tiempos disponibles para actualizar el ShippingIndex. *

4. Reindexar ShippingIndex basado en Ids, invocando por cada uno de los Shippings afectados:
   app1:api:shippings:index execute —id=12345 -vv

5. Una vez consumidos todos mensajes de ShippingIndex, se propone incrementar el número de instancias de consumidores de ClientStaticsDays.

6. Prender el productor *app1:api:shipping:statics *o bien encolar manualmente todos los envíos listados por el.

7. Tras finalizar el consumo de los mismos, se recomienda reducir estrictamente a solo una las instancias de Consumers de ShippingIndex y ClientStaticsDays.

Tras haber finalizado los pasos anteriores, se espera que el sistema haya quedado reindexado sin costos de desarrollo y explotando los recursos ante la concurrencia de consumidores.

Entorno con impacto de eventos

Se propone que un entorno “activo”, osea que es receptor de múltiples avisos de Estados y/o sufre alteraciones en sus configuraciones, pueda hacer uso de la concurrencia en sus consumidores de indices.

Se propone una solución de desarrollo “low-cost” para el muy corto plazo, en la cual se defina un cantidad preestablecida de nuevas colas (pre-fijadas), tanto para ShippingIndex como ClientStaticsDays.

La propuesta se basa que teniendo N colas prefijadas, los productores implementen una función de dispersión2, la cual posibilitará que ante un mensaje igual o “semejante”, sea asignado unívocamente a la misma cola. De esta forma el consumidor asociado a la misma tratará siempre los mismos casos, evitandose así muchos de los problemas de concurrencia, como por ejemplo los que producen inconsistencias y/o duplicidad de datos.

Gráficamente se podría visualizar de la siguiente manera

1 Se propusieron queries que hallan los casos. Se recomienda usar una de ellas con el periodo que se crea conveniente.

2 Son las funciones involucradas con la generación de Hashes (MD5, SHA-1,…) o bien en Estructuras de tipo Hash, usadas por SGBD y/o casos de persistencia con acceso “rápido” (1 lectura en disco). Para el caso de ShippingIndex, la función de dispersión estará basada en el Envio mientras que para el ClientStaticsDays, en la “dupla” cliente + dia, dado que para ambos casos, se identifica e involucra al “causal” de la principal problemática: el chequeo de existencia en collections de MongoDB, dado el contexto particular del mismo.