2009-08-05 21 views
14

He leído algunas publicaciones al respecto, pero sigo sin entender cuál es la mejor solución en mi caso.

Empiezo a escribir una nueva aplicación web y el backend proporcionará alrededor de 1-10 millones de imágenes. (Tamaño medio de 200-500kb para una sola imagen)
Almacenamiento de imágenes: Sistema de base de datos o archivos -

Mi sitio proporcionará contenido y las imágenes de los usuarios 100-1000 al mismo tiempo.

Me gustaría también mantener los costos del proveedor lo más bajo posible (pero este es un requisito secundario). Estoy pensando que el espacio del sistema de archivos es menos costoso si se compara con el costo del tamaño de la base de datos.

Personalmente me gusta la idea de tener todas mis imágenes en el PP pero cualquier sugerencia será muy apreciada :)

¿Cree que en mi caso el enfoque DB es la elección correcta?

+0

duplicados de http://stackoverflow.com/questions/1212832/most-efficient-way-to-store-a-20-meg-file-in-a-sql-server- 2005-image-column – andrewWinn

+2

¿Duplicado? Estoy usando java, mysql y archivos de imagen que son 1/20 - 1/50 de 10MB. Mi pregunta no está relacionada con una tecnología específica, sino con el tamaño/cantidad de imágenes que deben almacenarse – mickthompson

Respuesta

22

Poner todas esas imágenes en su base de datos hará que sea muy, muy grande. Esto significa que su motor de DB estará ocupado guardando en caché todas esas imágenes (una tarea para la que no está realmente diseñado) cuando podría almacenar en caché datos de aplicaciones en caliente.

Deje el almacenamiento en caché de archivos en el sistema operativo y/o su proxy inverso; lo harán mejor.

+0

Se supone que los servidores perimetrales deben hacer esto por usted, si puede permitirse escalar. Un servidor de borde estaría operando fuera del tráfico de HTTP, por lo que no le importa de dónde vino la imagen, a excepción de la solicitud inicial, y el subconjunto de solicitudes que se producen solo "después" del tiempo de espera. Teniendo eso en cuenta, sería mejor estructurar su capa de base de datos de tal manera que pueda responder con la información correcta para las solicitudes HEAD sin tener que acceder al registro que contiene la imagen "completa". Por lo general, los discos son más rápidos, pero elegir la base de datos no significa que deba renunciar a todo el rendimiento. –

5

Al tratar con objetos binarios, siga un enfoque centrado en documentos para la arquitectura y no almacene documentos como PDF e imágenes en la base de datos, eventualmente tendrá que volver a configurarlo cuando comience a ver todo tipo de problemas de rendimiento con su base de datos . Simplemente almacene el archivo en el sistema de archivos y tenga la ruta dentro de una tabla de su databse. También hay una limitación física en el tamaño del tipo de datos que usará para serializar y guardarlo en la base de datos. Simplemente almacénelo en el sistema de archivos y acceda a él.

+1

Esta pregunta se sigue preguntando diariamente sobre SO. –

4

Su primera frase dice que ha leído algunas publicaciones sobre el tema, así que no me molestaré en poner enlaces a artículos que cubran esto. Según mi experiencia, y en función de lo que haya publicado en cuanto a la cantidad de imágenes y tamaños de las imágenes, va a pagar caro en rendimiento de BD si las almacena en la base de datos. Los almacenaría en el sistema de archivos.

0

Usamos FileNet, un servidor optimizado para imágenes. Es muy costoso. Una solución más barata es usar un servidor de archivos.

No considere almacenar archivos grandes en un servidor de base de datos.

Como han mencionado otros, almacene las referencias a los archivos de gran tamaño en la base de datos.

14

Algunas otras razones para almacenar imágenes en el sistema de archivos:

  • servidores de imágenes se ejecutan incluso cuando la base de datos está ocupado o hacia abajo.
  • Los sistemas de archivos están hechos a archivos de la tienda y son bastante eficientes en eso.
  • Volcar datos en su base de datos significa copias de seguridad más lentas y otras operaciones.
  • No se necesita un código del lado del servidor para mostrar una imagen, simplemente antiguo IIS/Apache.
  • Puede escalar más rápido con servidores web sucios, o potencialmente a un CDN.
  • Puede realizar trabajos relacionados (generar miniaturas, etc.) sin involucrar a la base de datos.
  • Su servidor de base de datos puede mantener más de los datos de tablas "reales" en la memoria, que es donde obtiene la velocidad de su base de datos para las consultas. Si utiliza su preciosa memoria para mantener los archivos de imagen en la memoria caché, eso no le convencerá casi nada en relación con la velocidad en lugar de tener más índices de fotos en la memoria.
3

¿Qué base de datos está usted utilizando? MS SQL Server 2008 proporciona el almacenamiento FILESTREAM

permite el almacenamiento y el acceso eficiente a los datos BLOB mediante una combinación de SQL Server 2008 y el sistema de archivos NTFS. Cubre las opciones de almacenamiento BLOB, la configuración de Windows y SQL Server para usar datos de FILESTREAM, las consideraciones para combinar FILESTREAM con otras características y los detalles de implementación, como la creación de particiones y el rendimiento.

details

Cuestiones relacionadas