Estoy implementando un pequeño gestor documental. Un api para almacenar documentos y poco más. La cosa es que me surgen dudas a la hora de almacenar esos archivos. ¿Como soléis hacerlo?
Había pensado en almacenar la ruta física del fichero en la base de datos, y al recuperarlo leerlo de ahí (para no guardar directamente el archivo dentro de la BD).
El problema es... ¿si alguna vez lo despliego de forma distribuida?. Con clusters y tal. ¿Cómo se replican ahí los documentos?. Cada nodo debería tener el archivo, ¿no?.
Voy a suponer que estas hablando de una BD relacional.
En principio los ficheros son ficheros y los datos son datos (enteros, reales, cadenas, fechas) y como tal de forma general hay sistemas de ficheros que manejan eficientemente ficheros y sistemas gestores de bases de datos que manejan de manera eficiente "DATOS". (Si bien es cierto hay otros sistemas gestores de bases de datos que gestionan bien el almacenamiento de ficheros pero en ese tema no estoy muy metido. Creo que era con Mongo DB (GridFS)
)
Siento preocupación por saber en que estarían pensando algunos programadores al ver como en algunas aplicaciones legadas como consultas de pocas filas tardan 1 minuto en ejecutarse porque una de las columnas es un "señor fichero" de unos cuantos megas. (No es del todo cierto pero es por no entrar en detalles). O que te quedas sin espacio para la bd, copias de seguridad de una bd que podrían ser de 5 megas pasan a ser de 500mb 2gb,...
Vamos, que son todo ventajas
Si te sirve de ejemplo puedes fijarte como otros proyectos de gestión de contenidos u otros gestores documentales lo abordan.
Drupal por ejemplo crea una serie de metadatos sobre el fichero (url del fichero, nombre, mime type, fecha de subida, ...) y almacena el fichero aparte, además este fichero puede ser alojado de distintas formas:
Puedes tenerlo tu de forma local a el propio servidor web
Puedes externalizarlo a un servicio de almacenamiento externo como Amazon s3 (esto te permite manejar el escalado de tu aplicación de forma independiente entre ficheros y aplicación simplemente otorgando mas recursos).
Si almacenas los ficheros de forma pública (te da igual que cualquier persona pueda acceder a los ficheros) puedes hacer uso de redes de distribución de contenido (CDN's) sin problemas para que sirvan esos ficheros por ti de forma más eficiente, escalable., bla , bla.
Si lo haces de manera privada puede que tengas problemas para usar CDN's .
Este problema de la visibilidad de los ficheros no lo tienes cuando están en bd ya que controlas el acceso a ellos.
Si los ficheros son imágenes o vídeos quizás quisieras tener algún sistemas de transcodificación (servicios que convierten imágenes y vídeos a distintos formatos para ser representados correctamente en distintos dispositivos) y cache de estas imágenes adaptadas...
Si los ficheros son grandes ni me planteo guardarlos en bd.
...
Sólo se me ocurren ventajas.
Un saludo y espero que te sirva.
En realidad no estaba pensando en una relacional. Estaba decidiendo entre Cassandra o MongoDB. Y almacenarlo en la base de datos lo descartaba. La idea era tener mi repo, con mis ficheros en mi servidor, y un API que me devolviera los ficheros, sin más historia. Podría almacenarlo en Amazon, pero era un poco un ejercicio de DIY. Quiero almacenar los ficheros con ciertos metadatos, poder crear "tipos de documentos" (cada cual tendrá un juego de metadatos distinto, configurable). Como lo que comentas de Drupal, vaya (le echaré un ojo). Pero claro, en algún sitio debo almacenar el fichero.
Tal vez físicamente pueda almacenarlo en un servicio externo, pero me gustaría que fuera un microservicio "autocontenido" que pudiese desplegarse con Docker en cualquier lugar sin más configuración de servicios externos (como digo, en un ejercicio puro de DIY).
Hola.
Un apunte con lo de Drupal me refería a digamos imitar la forma de trabajar de estos gestores de contenidos en tu propia implementación no de usarlo como repositorio de ficheros (aun así podrías perfectamente...)
Los sistemas de los denominados Backend As A Service que te pueden solucionar esto si no quieres implementarlo tu.
Aquí va uno que entre otras cosas gestiona ficheros y que te puedes instalar en tu propio server.
http://www.baasbox.com/documentation/#available-functions
Aquí tienes un contenedor preparado por si quieres probarlo de forma rápida. (Yo no lo he probado, el contenedor digo,aunque baasbox sí.)
https://registry.hub.docker.com/u/joaobiriba/baasbox/
Estoy implementando un pequeño gestor documental. Un api para almacenar documentos y poco más. La cosa es que me surgen dudas a la hora de almacenar esos archivos. ¿Como soléis hacerlo?
Había pensado en almacenar la ruta física del fichero en la base de datos, y al recuperarlo leerlo de ahí (para no guardar directamente el archivo dentro de la BD).
El problema es... ¿si alguna vez lo despliego de forma distribuida?. Con clusters y tal. ¿Cómo se replican ahí los documentos?. Cada nodo debería tener el archivo, ¿no?.
¿Os habéis encontrado esta situación alguna vez?.
Un saludo.
13/06/2015 16:57
En principio los ficheros son ficheros y los datos son datos (enteros, reales, cadenas, fechas) y como tal de forma general hay sistemas de ficheros que manejan eficientemente ficheros y sistemas gestores de bases de datos que manejan de manera eficiente "DATOS". (Si bien es cierto hay otros sistemas gestores de bases de datos que gestionan bien el almacenamiento de ficheros pero en ese tema no estoy muy metido. Creo que era con Mongo DB (GridFS)
)
Siento preocupación por saber en que estarían pensando algunos programadores al ver como en algunas aplicaciones legadas como consultas de pocas filas tardan 1 minuto en ejecutarse porque una de las columnas es un "señor fichero" de unos cuantos megas. (No es del todo cierto pero es por no entrar en detalles). O que te quedas sin espacio para la bd, copias de seguridad de una bd que podrían ser de 5 megas pasan a ser de 500mb 2gb,...
Vamos, que son todo ventajas
Si te sirve de ejemplo puedes fijarte como otros proyectos de gestión de contenidos u otros gestores documentales lo abordan.
Drupal por ejemplo crea una serie de metadatos sobre el fichero (url del fichero, nombre, mime type, fecha de subida, ...) y almacena el fichero aparte, además este fichero puede ser alojado de distintas formas:
Puedes tenerlo tu de forma local a el propio servidor web
Puedes externalizarlo a un servicio de almacenamiento externo como Amazon s3 (esto te permite manejar el escalado de tu aplicación de forma independiente entre ficheros y aplicación simplemente otorgando mas recursos).
Si almacenas los ficheros de forma pública (te da igual que cualquier persona pueda acceder a los ficheros) puedes hacer uso de redes de distribución de contenido (CDN's) sin problemas para que sirvan esos ficheros por ti de forma más eficiente, escalable., bla , bla.
Si lo haces de manera privada puede que tengas problemas para usar CDN's .
Este problema de la visibilidad de los ficheros no lo tienes cuando están en bd ya que controlas el acceso a ellos.
Si los ficheros son imágenes o vídeos quizás quisieras tener algún sistemas de transcodificación (servicios que convierten imágenes y vídeos a distintos formatos para ser representados correctamente en distintos dispositivos) y cache de estas imágenes adaptadas...
Si los ficheros son grandes ni me planteo guardarlos en bd.
...
Sólo se me ocurren ventajas.
Un saludo y espero que te sirva.
15/06/2015 12:17
Gracias por la respuesta.
En realidad no estaba pensando en una relacional. Estaba decidiendo entre Cassandra o MongoDB. Y almacenarlo en la base de datos lo descartaba. La idea era tener mi repo, con mis ficheros en mi servidor, y un API que me devolviera los ficheros, sin más historia. Podría almacenarlo en Amazon, pero era un poco un ejercicio de DIY. Quiero almacenar los ficheros con ciertos metadatos, poder crear "tipos de documentos" (cada cual tendrá un juego de metadatos distinto, configurable). Como lo que comentas de Drupal, vaya (le echaré un ojo). Pero claro, en algún sitio debo almacenar el fichero.
Tal vez físicamente pueda almacenarlo en un servicio externo, pero me gustaría que fuera un microservicio "autocontenido" que pudiese desplegarse con Docker en cualquier lugar sin más configuración de servicios externos (como digo, en un ejercicio puro de DIY).
¡Muchas gracias por tu respuesta!.
Un saludo.
16/06/2015 08:13
Un apunte con lo de Drupal me refería a digamos imitar la forma de trabajar de estos gestores de contenidos en tu propia implementación no de usarlo como repositorio de ficheros (aun así podrías perfectamente...)
Los sistemas de los denominados Backend As A Service que te pueden solucionar esto si no quieres implementarlo tu.
Aquí va uno que entre otras cosas gestiona ficheros y que te puedes instalar en tu propio server.
http://www.baasbox.com/documentation/#available-functions
Aquí tienes un contenedor preparado por si quieres probarlo de forma rápida. (Yo no lo he probado, el contenedor digo,aunque baasbox sí.)
https://registry.hub.docker.com/u/joaobiriba/baasbox/
Saludos.