2009-07-31 14 views
7

Recientemente, yo y mis colegas, estamos discutiendo cómo construir un gran sistema de almacenamiento que podría almacenar miles de millones de imágenes que podrían buscarse y descargarse rápidamente.¿Crees que es una buena idea guardar miles de millones de imágenes en la base de datos?

Algo como un fickr, pero no para una galería en línea. Lo que significa que la mayoría de estas imágenes nunca se descargarán.

Mis colegas sugieren que debemos guardar todos estos archivos en la base de datos directamente. Realmente siento que no es una buena idea y creo que la base de datos no está diseñada para restaurar una gran cantidad de archivos binarios. Pero tengo una razón muy fuerte para explicar por qué no son buenas ideas.

¿Qué opinas sobre él.

+11

Esto ya se ha discutido hasta la muerte: http://stackoverflow.com/questions/3748/storing-images-in-db-yea-or-nay http://stackoverflow.com/questions/815626/to- do-or-not-to-do-store-images-in-a-database http://stackoverflow.com/questions/805519/save-image-in-database –

Respuesta

17

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.

+8

Curiosamente SQL Server 2008 hace esto por usted con FILESTREAM opción de almacenamiento- http://msdn.microsoft.com/en-us/library/cc949109.aspx – RichardOD

+0

Aunque estoy de acuerdo con esto, ¿SharePoint no almacena casi todo en la base de datos? Si es así, creo que la gente de SharePoint podría no pensar que es una mala idea almacenar archivos en la base de datos. Creo que es beneficioso de alguna manera (como consultar), pero esas formas probablemente no contrarresten por completo las cosas que has mencionado aquí. – Dusty

+0

@RichardOD, leí el documento y habla principalmente sobre los mismos desafíos de almacenar contenido estructurado frente a contenido no estructurado y recomienda NTFS. "FILESTREAM es una nueva característica en la versión de SQL Server 2008. Permite almacenar datos estructurados en la base de datos y los datos asociados no estructurados (es decir, BLOB) que se almacenarán directamente en el sistema de archivos NTFS. A continuación, puede acceder al BLOB datos a través de las API de transmisión de Win32® de alto rendimiento, en lugar de tener que pagar la penalización de rendimiento de acceder a los datos de BLOB a través de SQL Server ". –

0

No es una buena idea. El objetivo de una base de datos es que pueda resolver rápidamente consultas complejas para recuperar datos textuales. Si bien los datos binarios se pueden almacenar en una base de datos, pueden ralentizar las transacciones. Esto es especialmente cierto cuando la base de datos está en un servidor separado de la aplicación en ejecución. En la base de datos, almacene los metadatos y la ubicación/nombre de archivo de las imágenes. Las imágenes en sí deberían estar en servidores estáticos.

2

Si realmente está hablando incalculable de imágenes, me almacenarlos en el sistema de archivos debido a la recuperación será más rápida que la serialización y des-seralizing las imágenes

+1

Sí, realmente estoy hablando de miles de millones de imágenes. Los milagros ocurren todos los días. – ablmf

1

Las respuestas anteriores parecen suponer la base de datos es un RDBMS. Si su base de datos es una base de datos orientada a documentos con soporte para documentos binarios del tamaño que espera, entonces puede ser perfectamente conveniente almacenarlos en la base de datos.

+0

¿Podría nombrar algunas de esas bases de datos? – Moonwalker

+2

MarkLogic (http://developer.marklogic.com/) admite el almacenamiento de documentos XML, JSON, de texto y binarios. Existe una API REST para que pueda acceder rápidamente a http://github.com/marklogic/Corona, así como a un lenguaje de consulta nativo (XQuery). –

Cuestiones relacionadas