MySQL binario de almacenamiento BLOB utilizando VS Sistema OS del archivo: archivos de gran tamaño, grandes cantidades, grandes problemas

Question

Versiones estoy corriendo (básicamente última de todo):
PHP: 5.3.1
MySQL: 5.1.41
Apache : 2.2.14
OS: CentOS (más reciente)

Aquí está la situación.

que tienen miles de documentos muy importantes, que van desde los contratos de clientes a expresar firmas (grabaciones de la autorización del cliente para los contratos), con tipos de archivo, incluyendo, pero no limitado a JPG, GIF, PNG, TIFF, DOC, DOCX, XLS , wav, mp3, pdf, etc.

Todos estos documentos están actualmente almacenados en varios servidores, incluidos Windows 32 bit, CentOS y Mac, entre otros. Algunos archivos también se almacenan en las computadoras de escritorio y portátiles de los empleados, y algunos siguen siendo copias impresas almacenadas en cientos de cajas y archivadores.

Ahora, debido a que los clientes o abogados pueden exigir pruebas de contratos en cualquier momento, mi empresa debe poder buscar y ubicar los documentos correctos de manera efectiva, por este motivo TODOS estos archivos deben digitalizarse (si no ya) y correlacionado en algún tipo de orden para buscar y acceder.

Como programador, he creado una herramienta completa de gestión de relaciones con el cliente que utiliza toda la empresa. Esto incluye gestión de perfiles de cliente, herramientas de seguimiento de pedidos y trabajos, módulos de creación y gestión de trabajos/ventas, etc., y en este momento cualquier archivo que se necesite a nivel de perfil de cliente (licencia de conductor, autoridad de crédito, etc.) o en un trabajo/el nivel de venta (contratos, firmas de voz, etc.) se puede cargar en el servidor y se ubica en una estructura jerárquica padre/hijo, al igual que Windows Explorer o cualquier otro modelo típico de administración de archivos.

La estructura aparece como tal:

drivers_license
| - DL_123.jpg
voice_signatures
| - VS_123.wav
| - VS_4567.wav
contratos

Así que los archivos se uplaoded utilizando PHP y Apache, y se almacenan en el sistema de archivos del sistema operativo. En el momento de la carga, cierta información sobre el archivo (s) se almacena en una base de datos MySQL. Parte de la información almacenada es:

tabla: FileUploads
fileid
CustomerID
JobID/SaleID (el ID de la oferta de empleo/(el ID de cliente que pertenece el archivo, todos ellos tienen esto). la venta, si lo hay.)
FileSize
FileType
UploadedDateTime
UploadedBy
FilePath (la ruta del directorio del archivo se almacena en.)
nombre de archivo (nombre de archivo actual del archivo subido, combinación de CustomerID y JobID/SaleID si procede.)
DescripcionArchivo
OriginalFileName (nombre original del archivo fuente cuando subido, incluyendo la extensión.)

Como puede ver, el archivo está vinculado a la base de datos por el Nombre del archivo. Cuando quiero proporcionarle a un usuario los archivos de un cliente, todo lo que tengo que hacer es "SELECCIONAR * FROM FileUploads WHERE CustomerID = 123 O ID de trabajo = 2345;" y esto dará como resultado todos los detalles del archivo que requiero, y con FilePath y FileName puedo proporcionar el enlace para descargar.

http ... servidor/FilePath/Nombre de archivo

Hay una serie de problemas con este método:

1. Almacenamiento de archivos en este entorno "base de datos inconsciente" significa integridad de los datos es no guardado Si se elimina un registro, es posible que el archivo no se elimine también, o viceversa.
2. Los archivos están esparcidos por todos lados, diferentes servidores, computadoras, etc.
3. El nombre del archivo es lo ÚNICO que coincide con el binario de la base de datos y el perfil del cliente y los registros del cliente.

etc., etc. Hay muchos motivos, algunos de los cuales se describen aquí: http://www.dreamwerx.net/site/article01. También hay un artículo interesante aquí: sietch.net/ViewNewsItem.aspx?NewsItemID=124.

SO, después de mucha investigación, he decidido que voy a almacenar TODOS estos archivos en la base de datos, como BLOB o LONGBLOB, pero todavía hay muchas consideraciones antes de hacerlo.

Sé que almacenarlos en la base de datos es una opción viable, sin embargo, hay una serie de métodos para almacenarlos. También sé que almacenarlos es una cosa; correlacionarlos y acceder a ellos de una manera manejable es otra cosa completamente distinta.

El artículo proporcionado en este enlace: dreamwerx.net/site/article01 describe una forma de dividir los archivos binarios cargados en trozos de 64kb y almacenar cada fragmento con el ID de archivo, y luego transmitir el archivo binario real al cliente utilizando encabezados . Esta es una idea genial, ya que alivia la presión en la memoria de los servidores; en lugar de cargar un archivo completo de 100mb en la RAM y luego enviarlo al cliente, lo está haciendo a 64 kb a la vez. Intenté esto (y actualicé sus scripts) y esto es totalmente exitoso, en un marco de prueba muy pequeño.

Si está de acuerdo con que este método es una opción viable, estable y robusta a largo plazo para almacenar archivos moderadamente grandes (1kb a un par de cientos de megas) y grandes cantidades de estos archivos, hágame saber qué otras consideraciones o ideas que tienes.

Además, estoy considerando obtener una secuencia de comandos PHP de "Administración de archivos" que brinde una interfaz para administrar archivos almacenados en el Sistema de archivos y convertirlos para administrar archivos almacenados en la base de datos. Si ya hay algún software que lo haga, por favor avíseme.

Supongo que hay muchas preguntas que podría hacer, y toda la información está allí ^^ así que, por favor, discuta todos los aspectos de esto y podemos pasar ideas de ida y vuelta y enseñarnos unos a otros.

Saludos,

Quantico773

Answer 1

trabajo en un sistema de software de gran tamaño que ha hecho dos mecanismos para almacenar los archivos adjuntos y otros contenidos. La primera iteración del sistema almacenó todos los datos en BLOB en el DB. Lo maldije en ese momento.Como programador, podía escribir scripts laterales para operar inmediatamente los datos y cambiarlos cuando quisiera.

Avanzo unos 10 años y sigo administrando el mismo software pero la arquitectura ha cambiado y fue escrita con punteros del sistema de archivos. Lo maldigo ahora y ojalá estuviera de regreso en la base de datos. Tengo el beneficio adicional de varios años y habiendo trabajado esta aplicación en una capacidad mucho mayor en muchas más situaciones y muchas más, siento que mi opinión ahora está mejor educada. La promoción o la migración del sistema de la aplicación requiere una gran cantidad de scripts y copias de millones de archivos. En una ocasión cambiamos el sistema operativo y todos los punteros de archivo tenían el separador de directorio incorrecto, o el nombre del servidor cambia donde estaba el archivo y tuvimos que escribir y programar las declaraciones de actualización de SQL simple con el DBA en el fin de semana para solucionarlo. Otra es que el sistema de archivos y los registros DB no se sincronizan, por qué es incierto, pero luego de miles de días de operación, a veces los sistemas no transaccionales (el sistema de archivos y DB no comparten contextos transaccionales) simplemente no están sincronizados. A veces los archivos desaparecen misteriosamente.

Cuando todo esto estaba en la base de datos, la migración o la promoción del entorno era una cuestión de volcado e importar la base de datos. Los cambios en las filas se pueden auditar adecuadamente, todo en sincronización y los registros se pueden reproducir para apuntar en el tiempo si es necesario. Seguro que la base de datos se pone grande, pero es 2011 y esto simplemente no es un desafío para las bases de datos.

Por lo que vale, tuvimos algunos problemas similares con los búferes de datos grandes cuando transmitimos algunos datos, pero A) podríamos bombear los datos en búferes de bytes con Input | OutputStreams en JDBC y B) cuando usamos otras herramientas, escribió un procedimiento almacenado que dividiría el BLOB en una tabla temporal y serviría iterativamente los fragmentos de la tabla temporal. Funciona genial.

No me importa cuál sea la razón técnica para no poner estas cosas en el PP, pero es mucho más fácil de manejar en un lugar consolidado que podía doblar y triplicar el hardware o rejilla de la base de datos de el tiempo perdido por los consultores y los clientes solo en un corto período de tiempo al administrar los archivos dispares.

---

Actualización: vaya fácil con los comentaristas, ellos solo están dando su opinión sobre el asunto.