2009-04-09 20 views
8

Usando Rails, ¿hay alguna razón por la que deba almacenar archivos adjuntos (podría ser un archivo de cualquier momento) en el sistema de archivos en lugar de en la base de datos? La base de datos me parece más simple, no hay necesidad de preocuparse por las rutas, la estructura, etc. del sistema de archivos, simplemente mire en su campo blob. Pero la mayoría de la gente parece usar el sistema de archivos que me hace adivinar que debe haber algunos beneficios que no estoy obteniendo, o algunas desventajas al usar la base de datos para dicho almacenamiento. (En este caso, estoy usando postgres).Rieles: almacenamiento de archivos binarios en la base de datos

Respuesta

26

Esta es una pregunta de diseño bastante estándar, y realmente no hay una "única respuesta verdadera".

La regla de oro que suelo seguir es "los datos van en las bases de datos, los archivos van en los archivos".

Algunas de las consideraciones a tener en cuenta:

  1. Si un archivo se almacena en la base de datos, ¿cómo se va a servir a cabo a través de http? Recuerde, debe configurar el tipo de contenido, nombre de archivo, etc. Si se trata de un archivo en el sistema de archivos, el servidor web se encargará de todo eso. Muy rápido y eficientemente (quizás incluso en el espacio del kernel), no se necesita código interpretado.

  2. Los archivos son típicamente grandes. Las bases de datos grandes son ciertamente viables, pero son lentas e inconvenientes para hacer copias de seguridad, etc. ¿Por qué hacer que su base de datos sea enorme cuando no es necesario?

  3. Como 2., es muy fácil copiar archivos a varias máquinas. Digamos que está ejecutando un clúster, puede simplemente sincronizar periódicamente el sistema de archivos desde su máquina maestra a sus esclavos y usar una porción http estándar estática. Obviamente, las bases de datos también se pueden agrupar, no es necesariamente tan intuitiva.

  4. En la otra cara de 3, si ya está agrupando su base de datos, entonces tener que tratar con los archivos en clúster además es la complejidad administrativa. Esta sería una razón para considerar el almacenamiento de archivos en el DB, diría yo.

  5. Los datos de blobs en las bases de datos suelen ser opacos. No puede filtrarlo, ordenarlo o agruparlo. Eso disminuye el valor de almacenarlo en la base de datos.

  6. Por otro lado, las bases de datos comprenden la concurrencia. Puede usar su modelo estándar de aislamiento de transacciones para asegurarse de que dos clientes no intenten editar el mismo archivo al mismo tiempo. Esto podría ser bueno. No quiere decir que no puedas usar archivos de bloqueo, pero ahora tienes dos cosas que entender en lugar de una.

  7. Accesibilidad. Los archivos en un sistema de archivos se pueden abrir con herramientas comunes. Vi, Photoshop, Word, lo que sea que necesites. Esto puede ser conveniente. ¿Cómo vas a abrir ese documento de Word de un campo blob?

  8. Permisos. Los sistemas de archivos tienen permisos, y pueden ser un dolor en la parte posterior. Por el contrario, podrían ser útiles para su aplicación. Los permisos realmente te morderán si estás aprovechando 7, porque está casi garantizado que tu servidor web se ejecuta con permisos diferentes a tus aplicaciones.

  9. Cacheing (de sarah mei a continuación). Esto se juega en la pregunta http de arriba en el lado del cliente (¿recordarás establecer los tiempos de vida de forma correcta?). En el lado del servidor, los archivos en un sistema de archivos son un patrón de acceso muy bien entendido y optimizado. La base de datos puede optimizar o no los grandes campos de blobs, y está casi garantizado que también tendrá un viaje de red adicional desde la base de datos al servidor web.

En resumen, las personas tienden a utilizar los sistemas de archivos para archivos porque admiten mejor las expresiones de archivo. Sin embargo, no hay ninguna razón para hacerlo, y los sistemas de archivos se están convirtiendo cada vez más en bases de datos, por lo que no me sorprendería en absoluto ver una convergencia completa con el tiempo.

+0

Gracias, Erik. Esa fue una respuesta muy útil e integral. –

+0

7. ¿Quiere decir trabajar en el servidor directamente? Como archivo, también lo descargué antes de abrirlo en photoshop. O mi sistema de control de versiones haría eso por mí. – Luc

+0

Almacenar elementos en un sistema de archivos local que no se replica a menudo rompe 12 aplicaciones de estilo facial, lo que hace problemático escalar una aplicación mediana o mejor. El almacenamiento de archivos adjuntos en un S3/CloudFront o back-end clonado similar es el camino a seguir para la mayoría de los casos de uso (pero no todos). CarrierWave, Paperclip, etc. pueden ayudar a abstraer esas diferencias. – Barry

2

La respuesta de Erik es genial. También agregaré que si desea hacer un almacenamiento en caché, es mucho más sencillo y directo almacenar en caché los archivos estáticos que almacenar en caché los contenidos de la base de datos.

0

Si utiliza un complemento como Paperclip, no tiene que preocuparse por nada tampoco. Hay algo llamado sistema de archivos, que es donde deberían ir los archivos. El hecho de que sea un poco más difícil no significa que deba poner sus archivos en el lugar equivocado. Y con clip (u otros complementos similares) no es difícil. Entonces, ¡sistema de archivos gogo!

+1

¿Qué hay de asegurarse de que solo los usuarios apropiados puedan ver/acceder a los archivos? ¿Se encarga de esto Paperclip? – Greg

+0

Es una carcasa de borde extremo. Facebook nunca protege sus imágenes (aparte de dar a las imágenes URLs muy maliciosas). –

+0

Una forma de hacer esto sería colocar los archivos detrás de un servidor Apache en la producción, un archivo .htaccess podría cerrar esto. ¿El problema? Obteniendo los archivos. No estoy seguro si esto es posible en rieles, pero en PHP, puede tomar el archivo de un directorio protegido .htaccess después de verificar si el usuario tiene permisos para verlo. El script PHP, por supuesto, está en un directorio público diferente. –

6

Hay algunos buenos consejos sobre el uso del sistema de archivos para los archivos, pero aquí hay algo más en qué pensar. Si está almacenando archivos/archivos adjuntos sensibles o seguros, usar el DB realmente es el único camino a seguir. He creado aplicaciones donde los datos no se pueden publicar en un archivo. Tiene que ser puesto en el DB por razones de seguridad. No puede dejarlo en un sistema de archivos para que un usuario en el servidor/máquina lo mire o se lo lleve sin la seguridad adecuada. Usando una base de datos de alta clase como Oracle, puede bloquear esos datos muy estrechamente y garantizar que solo los usuarios apropiados tengan acceso a esos datos.

Pero los otros puntos son muy válidos. Si simplemente está haciendo cosas como imágenes de avatar o información no confidencial, el sistema de archivos generalmente es más rápido y más conveniente para la mayoría de los sistemas de complementos.

La base de datos es bastante fácil de configurar para enviar archivos de vuelta; es un poco más trabajo, pero solo unos minutos si sabes lo que estás haciendo. Así que sí, el sistema de archivos es la mejor manera de ir en general, la OMI, pero la base de datos es la única opción viable cuando la seguridad o los datos confidenciales son una preocupación importante.

+0

Esto es cierto. Intentar sincronizar las reglas de seguridad en el sistema de archivos y la base de datos simultáneamente es, en el mejor de los casos, difícil. – easel

+0

Si bien puede ser imposible una idea sería algo así como Linux con.htaccess archivos en el sistema de archivos evitando que los visitantes web no autorizados vean el archivo, o puede almacenarlo fuera del directorio público del servidor web y tener un enlace de referencia al mismo. PHP, sé de hecho que puede extraer el archivo de un lugar no público en el sistema operativo si tiene los permisos adecuados. –

1

No veo cuál es el problema con las blobstores. Siempre puede reconstruir un almacén de sistema de archivos a partir de él, p. guardando en caché las cosas en el servidor web local mientras se usa el sistema. Pero la tienda autorizada siempre debe ser la base de datos. Lo que significa que puede implementar su aplicación lanzando en la base de datos y exportando el código del control de origen. Hecho. Y agregar un servidor web no es un problema en absoluto.

+0

Según la experiencia de producción, creo que esta es la respuesta correcta. – cfeduke

Cuestiones relacionadas