Versionar blacklists con muchos registros

babri

Os pongo en situación:

Cliente nos manda un CSV/Excel con su blacklist (1 millón de registros de media).
Nosotros pillamos dichos registros los metemos una tabla temporal, si ya hay una temporada antigua, truncamos los datos anteriores y metemos los nuevos.
Hacemos el envío de datos nuevo con la blacklist que nos han dado.

Pero ahora queremos versionar dichas blacklist, osea poder mirar que blacklist usamos en que envío para compararlas.
Lo hemos montado de momento, para poder funcionar rápido. de la misma manera que ahora, pero claro se están generando muchísimas tablas y no se si esto es excesivamente bueno.

Tenemos 12 clientes semanales lo cual nos generan 12 tablas de 1 millón de registros semanales.

Todo es sobre mysql.

Alguna idea de poder mejorar el método? Creéis que no es mal método? Usarías una mongo solo para este tipo de casos?

Grachie mile y un saludo!

PiPePiTo

En mi empresa (envio de campañas de sms, email y llamadas) lo que hacemos es importar el fichero, eso va a un microservicio que va distribuyendo a los diferentes blacklist (sms/llamadas y email).

Ese servicio escribe en mongo y además mete un registro en un log que dice que fichero se ha importado y el id del blacklist.

Si me vuelves a mandar el mismo numero no lo meto otra vez en el bl, si no que meto una línea más en el audit vinculando el número al fichero nuevo y actualizando la fecha para quitarlo en base al periodo que nos dice el cliente.
De esta manera se cuándo llegó un numero a mi blacklist y cuántas veces me lo han vuelto a mandar.

Nuestros numeros a parte luego estan vinculados a un userid, claro, con lo cual la duplicidad de datos es inevitable y nosotros lo metimos a mongo porque cada vez que se manda una campaña o un sms a un numero introducido manualmente tengo que comprobar y quitarlo de la lista a enviar, en sql esto resultaba en blocks, y más cuando creaban la campaña y te importaban los numeros a bloquear al mismo tiempo

1 respuesta
JuAn4k4

Guarda el csv comprimido en algún sitio, y ten una tabla con: Donde esta el fichero (o fileId), el cliente, la fecha del fichero y la versión.

No necesitas los registros del csv realmente en la db para poder usarlo, puedes leer del csv a la vez que mandas...

Así tu source of truth es el csv, y le puedes devolver el csv original si hay cualquier error en el envío o cualquier problema, de lo contrario... estas en ascuas

1 1 respuesta
babri

#2 algo así tengo en mente. Es que el problema que comentas de blocks es el que tengo. Muchas gracias!

#3 por tema de GDPR no puedo almacenar archivos en servidor y menos de clientes. >.<

2 respuestas
JuAn4k4

#4 ¿ pero si te estas guardado los datos igualmente no ?

1 respuesta
Runig006

Hombre, lo que está claro es que ir almacenando tablas a piñón en MySql mucha gracia no le va a hacer.

Mongo no se, pero Elastic es el rey en series temporales, a parte de que siempre podrás guardar todo en índices de solo lectura para que vaya más rápido.

Tampoco te voy a negar que fijo que algo me estoy saltando de todo esto, pero no es más fácil simplemente subir una copia de los datos a un sistema más...eh...acostumbrado a este nivel de datos, al mismo tiempo que MySql guarda solo los necesarios? En plan, guarda estos 5000 números, y sube una copia de estos 5000 a Elastic

Vamos, yo digo Elastic porque cada uno ya se sabe, tiramos a nuestra casa. Yo ahora mismo necesito almacenar unos 300 millones de registros, viva las eléctricas, y bien montado, va como un misil, es cierto que si le dices de escribir 5000 registros mientras lees ese índice...gracia no le hace, pero si lo entiendo bien, sería más como un índice por carga masiva. Así que no creo que tengas este problema.

Luego Elastic tiene sus follones de mantenimiento, pero vamos, en tu caso se reducen a que cuando termines una carga, calcular el tamaño del índice, reducirlo a eso, y hacerlo solo lectura. Pero vamos, todo eso es más cuestión de verlo con calma y hacer los cálculos que por limitación de Elastic

2 respuestas
wdaoajw

#4 y hacer control de versiones en un S3 con encriptacion?

#6 elastic no es una solución para este caso

2 respuestas
Runig006

#7 Por qué? Son 12 millones de registros semanales, cada registro es único, pues vienen de ficheros distintos.

No se, ahora mismo, no veo el porqué no

babri

#5 va encriptado en el caso de datos. Minimizas problemas que guardando el fichero que si entran al server adiós muy buenas. (El DPO es quien pone las reglas xD).

#6 Elastic Search supongo que te refieres no? Puede ser una solución de cara a cuando nencesito usar dicha bl o wl el hecho de que esté indexado pero el proceso de mantemiento quizás es más elavorado, que ventaja le ves frente a una no relacional y una relacional?

#7 dices del fichero?

1 respuesta
Runig006

#9 Velocidad pura y dura. A parte de ser bastante "Elástico" en cuanto a la estructura que puedes tener para los datos.

Digamos que hoy haces un índice por semana, si mañana pasa un año y te quedas sin memoria no tienes problemas en reducirlo todo a índices por meses, o año. Mientras los nuevos siguen llendo por semana. Seguirán siendo buscables. Y no hay que liar un cristo, ni cambiar consultas ni nada, con dos comandos lo tienes hecho.

El nombre le viene que ni pintado jajajaja

Elastic en gran volumen de datos siempre será el rey porque básicamente es idiota, el no cuestiona si el registro es o no es válido, el lo machaca y a otra cosa.

Lo único es que si son objetos con relaciones y demás tendrás que "aplanarlos".

Estoy desde el móvil asi que escribir más tocho me es difícil. Pero registros, métricas, series temporales etc, Elastic es una solución perfecta, vamos, es para lo que está diseñado

wdaoajw

Elasticsearch es una herramienta para monitorizar logs, usarla para esto no es su caso de uso.

Una opción es usar MongoDB o Cassandra. Otra opción es almacenar los CSV con un control de versiones encriptados, pero usar elastic search, que es una BBDD basada en timeseries no me parece apropiado (por lo mismo tampoco InfluxDB)

Lo más simple es almacenar el fichero en el versión control y si es necesario cargar un fichero antiguo tirar de el

1 respuesta
HeXaN

#11 Elastic es mucho más que una herramienta para monitorizar logs.

1 respuesta
wdaoajw

#12 elástic per se, es una BBDD.

Pero usar elastic search cuando puedes usar mongodb es con el mismo resultado es complicarse la vida al extremo absurdamente

1 respuesta
Runig006

#13 Usar MongoDb cuando puedes usar Elastic es tirar velocidad por gusto.

Eso y tirar la opción de ya que montas un Elastic, aprovechar y montar los clientes de Monitorizacion y guardado de Logs.

Cargar un CSV de un millón de registros es MUY divertido. A parte de que pierdes cualquier estadística que quieras sacar luego.

eXtreM3

Móntalo en AWS y le cobráis por tamaño a los clientes, que algunos piensan que pueden mandar datos infinitos por el mismo coste y que estén ahí siempre disponibles para comparativas.

Usuarios habituales

  • eXtreM3
  • Runig006
  • wdaoajw
  • HeXaN
  • babri
  • JuAn4k4
  • PiPePiTo