historia de fondoMantener la base de datos en sincronía con las imágenes en el sistema de archivos [PHP/PostgreSQL/Linux]
que mantienen y estoy en el proceso de re-ingeniería de un par de PHP webapplications basada, y no es un tema i refugio Encontré una solución elegante por el momento, así que estoy buscando algún aporte que pueda llevarme a una mejor manera de hacerlo.
ESTADO ACTUAL
Varios de mis aplicaciones permiten a los usuarios almacenar imágenes, además de una gran cantidad de datos. Todos los datos terminan en un clúster de PostgreSQL, sin embargo, decido no almacenar las imágenes en la base de datos para el rendimiento y el mantenimiento. Las imágenes obtienen sus metadatos almacenados en la base de datos (como nombre de archivo original, ancho/alto, etc.) y una vez que la transacción de la base de datos tuvo éxito, muevo la imagen en el sistema de archivos a un directorio de imágenes (almacenado como .jpg).
EL PROBLEMA
Todo esto funciona muy bien, pero a medida que las aplicaciones se utilizan mucho, y por varias personas simultaneamente, ya través de Internet, y el control de errores/excepción de PHP no es precisamente el más confiable en todos los escenarios, a veces me preocupa no poder envolver el almacenamiento de la imagen (en el Sistema de archivos) dentro de la transacción de la Base de datos (ya que está sucediendo en el sistema de archivos). También me preocupa porque si un archivo de imagen se corrompe/altera/elimina en el sistema de archivos, los registros de la base de datos no se actualizarán correctamente (sin integridad referencial).
SOLUCIONES
Lo que he encontrado hasta el momento es:
Opción a) almacenar la imagen real (no sólo los metadatos, pero todo el binario) en la base de datos. - No soy fan de esto, ya que actualmente la base de datos, aunque es bastante compleja, es muy pequeña (no más de 60 MB orso). Las imágenes relacionadas suman muchos muchos GB, por lo que aumentaría la huella de mi instalación de PostgreSQL de forma masiva. Además, complicará mi copia de seguridad de la base de datos y escenarios de replicación.
Opción B) Mantenga el diseño actual (imágenes en el sistema de archivos, datos en postgres) y simplemente intente dar cuenta de los datos corruptos en el nivel de aplicación en cada punto donde se usa. - Hace que la aplicación sea mucho más compleja y errónea.
Opción C) Encontré una estructura PHP ORM llamada Flourishlib que contiene una clase del sistema de archivos que simula las transacciones del sistema de archivos (básicamente si llama $ file-> rename() comprueba si eso sería posible, pero no cambia el nombre hasta usted compromete la transacción) - Esta es la mejor solución que he encontrado hasta ahora, sin embargo, ya estoy usando otro marco ORM (Propel) que me gusta mucho más para un proyecto de este tamaño, por lo que necesitaría 2 marcos con mayor funcionalidad superpuesta
Sooo
Por lo tanto, estoy pensando en muchas otras personas aquí se han topado con el mismo "problema" antes, y estoy seguro que algunos llegaron a algunas soluciones que no he pensado todavía . Aprecie cualquier consejo, consejo o crítica.
Optimización prematura? – symcbean
@symcbean No es realmente, el plan es reconstruir algunas de estas aplicaciones desde cero, solucionando muchos otros problemas que existen (las aplicaciones comenzaron mucho más pequeñas y han crecido constantemente con el tiempo, pero agregarle nuevas características ha degradado la calidad general) Entonces, como voy a hacer eso de todos modos, tiene sentido (para mí de todos modos) considerar qué otras partes no son buenas y ver si hay una mejor manera de construirlas. – Stackhouse