Uso de archivos planos vs base de datos / API como transporte entre una interfaz y un servidor

Tengo una aplicación que ha generado una discusión bastante acalorada entre un par de desarrolladores.

Básicamente, se divide en una capa web y una capa de fondo. La capa web recopila información mediante un formulario web simple, almacena estos datos como un documento JSON (literalmente un archivo .json) en una carpeta de observación utilizada por el back-end. El back-end sondea esta carpeta cada pocos segundos, recoge el archivo y lleva a cabo sus funciones.

Los archivos en sí son muy simples (es decir, todos los datos de cadena, sin anidamiento), y alrededor de 1-2k como máximo, con el sistema pasando la mayor parte de su tiempo inactivo (pero reventando hasta 100 mensajes en un momento dado). El paso de procesamiento de backend tarda unos 10 minutos por mensaje.

El argumento surge cuando un desarrollador sugiere que usar el sistema de archivos como una capa de mensajería es una mala solución, cuando algo como una base de datos relacional (MySQL), una base de datos noSQL (Redis) o incluso una simple llamada REST API debería usarse en su lugar.

Cabe señalar que Redis se utiliza en otras partes de la organización para el manejo de mensajes en cola.

Los argumentos que he escuchado se desglosan de la siguiente manera

A favor de los archivos planos:

• Los archivos planos son más confiables que cualquier otra solución, ya que el archivo solo se mueve de una carpeta de "observación", a una carpeta de "procesamiento" después de ser recogido, y finalmente a una carpeta "listo" cuando finaliza. No hay riesgo de que los mensajes desaparezcan, salvo errores de muy bajo nivel que de todos modos romperían otras cosas.

• Los archivos planos requieren menos sofisticación técnica para comprender, solo cateso. Sin consultas para escribir, sin riesgo de que accidentalmente aparezca un mensaje de la cola y que desaparezca para siempre.

• El código de administración de archivos es más simple que las API de bases de datos desde el punto de vista de la programación, ya que es parte de la biblioteca estándar de cada idioma. Esto reduce la complejidad general de la base del código y la cantidad de código de terceros que debe introducirse.

• El principio de YAGNI establece que los archivos planos funcionan bien en este momento, no hay necesidad demostrada de cambiar a una solución más complicada, así que déjelo.

A favor de una base de datos:

• Es más fácil escalar una base de datos que un directorio lleno de archivos

• Los archivos planos tienen el riesgo de que alguien copie un archivo "hecho" de nuevo al directorio "watch". Debido a la naturaleza de esta aplicación (administración de máquinas virtuales), esto podría resultar en una pérdida de datos catastrófica.

• Al exigir más sofisticación técnica a T / S, la aplicación significa que es menos probable que el personal sin educación arruine algo simplemente hurgando en las cosas.

• El código de conexión de la base de datos, especialmente para algo como Redis, es al menos tan robusto como las funciones estándar de administración de archivos de la biblioteca.

• El código de conexión de base de datos es visiblemente (si no funcionalmente) más simple desde el punto de vista del desarrollador, ya que es más alto que la manipulación de archivos.

Por lo que puedo ver, ambos desarrolladores tienen muchos puntos válidos.

Entonces, de estas dos personas, el desarrollador de pro-archivos o el desarrollador de pro-bases de datos, ¿cuál está más en línea con las mejores prácticas de ingeniería de software y por qué?

Cambiar a una solución que involucre bases de datos o los sistemas de colas mencionados por Ewan

• crear dependencia en un sistema nuevo y complejo tanto en backend como en frontend
• Introducir una complejidad innecesaria y un montón de nuevos puntos de falla.
• aumentar el costo (incluido el costo de propiedad)

Se garantiza que mover / renombrar archivos dentro de un solo volumen será atómico en todos los sistemas operativos actuales, cualesquiera que sean sus dificultades con respecto al bloqueo de archivos / registros. La gestión de derechos a nivel del sistema operativo debería ser suficiente para bloquear lo no lavado y evitar una manipulación incorrecta irreflexiva / accidental por parte de operadores autorizados (administradores / desarrolladores). Por lo tanto, las bases de datos no tienen nada que ofrecer, siempre y cuando el rendimiento de la solución actual esté a la altura.

En nuestra empresa, hemos utilizado interfaces similares basadas en archivos durante décadas con gran éxito. Muchas otras cosas han ido y venido, pero estas interfaces se han mantenido debido a su total simplicidad, confiabilidad y mínimas conexiones / dependencias.

No creo que ninguna de las soluciones sea una mala práctica, por lo que responder cuál es la mejor práctica puede ser difícil.

No creo que el director de YAGNI se aplique aquí si se trata de escala. "Trabajar" es relativo, si tiene un gran potencial de pérdida de datos catastrófica y poca capacidad para escalar, realmente no consideraría que funcione. No estoy exactamente seguro de la escala con la que está tratando, pero si tiene una cantidad masiva de estas entradas, solo se volverá más difícil con cada una cambiar a un nuevo sistema. Entonces, si este es el caso, diría que una base de datos es la mejor práctica.

MongoDB o redis (no tengo experiencia con redis, lea solo cosas buenas) debería funcionar bien, ya que sus datos ya deberían encajar perfectamente en él (los documentos json a menudo se cambian trivialmente a documentos BSON para MongoDB). También tiene la ventaja adicional de mantener una gran cantidad de datos en la memoria en lugar de posibles lecturas / escrituras frecuentes en el disco todo el tiempo. También se asegura de que las lecturas / escrituras concurrentes no conduzcan a la corrupción o el bloqueo.

Si el director de YAGNI se aplica aquí y los archivos no son un cuello de botella, se escalan dentro del alcance y no tienen problemas catastróficos, diría que quedarse con los archivos es "la mejor práctica". No hay razón para cambiar nada si no hay problemas, tal vez escribir algunas pruebas, enfatizarlo y ver dónde están sus límites y cuellos de botella.

No estoy seguro si una base de datos es la solución en este contexto de todos modos. Si se está comunicando con cosas en el mismo servidor, se podría hacer algún tipo de IPC, ¿no?

Mientras que lo bueno es guardar un archivo y copiarlo en un directorio hecho es un elemento básico de muchas capas de comunicación, especialmente. con sistemas de marcos principales más antiguos y similares. Los chicos 'anti' tienen un punto; en eso tiene muchos problemas y casos extremos. Son difíciles de manejar si necesita un 100% de confiabilidad y ocurren con mayor frecuencia a medida que aumenta la frecuencia y el volumen de los archivos.

Si controla ambos lados de la transacción, le sugiero que mire algunos de los muchos sistemas de colas simples disponibles. ZeroMQ, RabbitMQ, MSMQ, etc., en lugar de una base de datos. Pero como insinúas, si no está roto ...

La solución de la base de datos es la correcta. Resuelve mucha dependencia de un host particular o condiciones de contorno.

Ambas son soluciones similares, excepto que la base de datos no está alojada en un host particular. Esto elimina los problemas de firewall / acceso con el sistema unix. Hemos tenido casos de eliminación "accidental" en los sistemas de archivos y nadie a quien culpar.

Con la base de datos, también puede tener el mismo problema, pero puede activar la auditoría o insertar solo la lógica para eliminar las eliminaciones.

También en el sistema de archivos si necesita poner la aplicación en el nombre del archivo, por ejemplo, OASIS, deberá crear los archivos OASIS.john_doe.system1.20160202. Esto se vuelve tedioso y se puede representar más fácilmente en la base de datos. Incluso puede tener campos nulos en la base de datos y lógica basada en eso

También es fácil actualizar las bases de datos en lugar de un directorio de archivos completo en caso de cualquier parche o corrección que desee hacer en las tablas. Por supuesto, puede hacerlo en el sistema de archivos, pero la actualización de la base de datos es más intuitiva.

Por ejemplo, si desea una repetición pero con un sistema diferente al OASIS, diga DESERT y john_doe a doe_smith y fecha de 20160101 a 20151231

Fácil de generar filas para DESERT / doe_smith / 20151231 desde el conjunto original en lugar de crear esos archivos con script de shell.

Entonces, desde la legibilidad, la solución de base de datos de punto de vista de extensión es mejor.