[MongoDB] Migrar datos a nuevo esquema + corrección de AID

[dirodriguezm]

### Tasks
- [x] Simulate "production" mongo instance with old schema
- [x] Get production instance statistics (number of items to update)
- [x] Write script to migrate schema
- [x] Evaluate performance of the script
- [x] If the script is too slow, rewrite using distributed processing
- [X] Migración de detecciones + cálculo aid
- [ ] insertar objetos vacíos con aid al momento de migrar detecciones
- [ ] hacer update de objetos vacíos con los objetos de la BD source
- [ ] migración de non_detections + obtención de aid

[dirodriguezm]

Opciones:

• pipeline interna de mongo
• spark conector
• script externo que hace update

Estrategia:

• Leer en batches desde la BD origen
• Modificar cada documento del batch
• Bulk Write en la BD destino

UPDATE:

• Quedó listo el script para objects y detections
• Son 300M de objetos aprox

[dirodriguezm]

Avances Lunes 2/octubre:

• Está listo el script que copia datos Funciona para todas las colecciones y tiene un performance decente

  Average time for 10k object: 0.48235273361206055
  Average time for 10k non_detection: 0.25535082349590227
  Average time for 10k detection: 0.4288179266686533
  
  Estimated time: 10-15 hrs

• El problema es hacerlo incremental
  • Una alternativa es usar change streams
    • Change Streams requieren tener configurado el servidor con replica set
    • Lo probé y me da error al crear el replica set con autenticación habilitada BadValue: security.keyFile is required when authorization is enabled with replica sets
  • Otra alternativa es usar Tailable Cursors
    • Consiste en dejar un cursor abierto permanentemente como si fuera un consumidor de Kafka
    • Esto funcionaría bien, pero si se cae el proceso se pierde la posición del cursor
    • Dado lo anterior, es más seguro usar change streams

[dirodriguezm]

Avances Martes 3/octubre:

• Usar una estrategia incremental implica hacer muchos cambios que aumentan la complejidad de la tarea (ej: configurar replica sets) Decidimos no usar estrategia incremental por ahora, y usar Kafka como respaldo para reprocesar los eventuales "deltas"
• Se levantó infraestructura para la BD y una instancia que ejecuta la migración

[dirodriguezm]

Avances Miércoles 4/octubre:

• Se está haciendo una prueba de la migración con infraestructura "real" para probar performance
• El resultado fue: 16.5 horas en copiar detection

[dirodriguezm]

Jueves 4/octubre:

• @amoya87 se puso a probar performance usando spark

[dirodriguezm]

Nuevo plan para la migración:

• Migrar datos previos de mongoDB al nuevo esquema
• Arreglar bug de AID corrigiendo el problema en Sorting Hat

[dirodriguezm]

Viernes 3 / noviembre:

En proceso de hacer la parte del sorting hat.

Hice refactorización del script para usar Actor Model con la librería Pykka.

La estrategia va a ser leer desde detection y hacer una pipeline interna usando el actor model, insertando tanto object como detection "a la vez" (realmente son threads).