En aws dynamo db no podemos almacenar más de 400 KB de datos en un solo registro [ Referencia ]. Según las sugerencias en línea, puedo comprimir los datos antes de almacenarlos o cargar parte de ellos en el depósito de aws s3, lo cual me parece bien
Pero mi aplicación (javascript/servidor express más muchos js lambdas/microservicios) es demasiado grande y agrega la lógica anterior que requiere una reescritura pesada y pruebas exhaustivas. Actualmente, hay un requisito inmediato de un gran cliente que exige más de 400 KB de almacenamiento en la base de datos, por lo tanto, ¿hay alguna forma alternativa de resolver el problema que no me obligue a cambiar mi código existente para obtener el registro de la base de datos?
Estaba pensando más en estas líneas:
Mi backend hace una llamada de db de dynamo para obtener el registro como lo está haciendo ahora (usamos una combinación de vogels y aws-sdk para hacer llamadas de db) -> La llamada es interceptada por una lambda (o algo más) que maneja la compresión necesaria /descompresión/s3 con dynamodb y devuelve los datos al backend.
¿Es posible hacer el enfoque anterior y, en caso afirmativo, cómo puedo implementarlo? O si tiene una mejor manera, por favor díganos.
PD. En el futuro, definitivamente volveré a escribir mi código base para encargarme de esto, lo que pido es una solución provisional inmediata.
Divida los datos en varios elementos. Tendrá que cambiar un poco el código del cliente, pero es de esperar que tenga una capa de acceso a datos, por lo que es solo un pequeño cambio en un solo lugar. Si no tienes DAL, de ahora en adelante ten siempre DAL. :)
Para la carga útil de un artículo grande, use el artículo regular como el manifiesto que puede apuntar a los artículos segmentados. Luego, obtenga artículos por lotes de esos artículos segmentados.
Esto supone que la compresión por sí sola no siempre es suficiente. Si es así, haz eso.