Estamos haciendo una aplicación que ha de dar acceso a un montón de imágenes generadas por equipos médicos. El asunto es llevar un historial de los pacientes y en cada examen mostrar las imagenes que se adquirieron en el mismo.
El volumen es mas o menos importante, unas 20000 mensuales y bueno, me parece una chapuza informática meter semejante número de ficheros en un sistema de archivos (y no es güindon, no señor).
Meter las imagenes en la base de datos nos aporta otra serie de ventajas, por ejemplo, si se conecta un cliente remoto via inet, la misma aplicación recibirá las imagenes como si fuese local, entre otras cosas.
La base de datos usada es PostgreSQL, y sobre el asunto que comentan por ahí del tamaño de las copias, para copiar solo los datos, pg_dump, sin opcion -b, si quieres los blob, con -b, de todas maneras si hay que hacer un backup de las imágenes, también ocuparán lo suyo aunque sean archivos.
Meter las imagenes en la base de datos nos aporta otra serie de ventajas, por ejemplo, si se conecta un cliente remoto via inet, la misma aplicación recibirá las imagenes como si fuese local, entre otras cosas.
No se me habia ocurrido esa posibilidad, si se quiere acceder a la informacion desde otro host diferente al de la base de datos o desde una aplicacion (lo mas normal por cierto) entonces si que seria mas que logico meter los ficheros en la base de datos.
Aunque en este caso dice que lo quiere para una pagina web y podrian almacenarse tambien en el sistema de ficheros del servidor de la pagina..
pero creo que tienes razon, si es una base de datos importante que es susceptible de ser modificada / adaptada a nuevas necesidades en un futuro si es logico hacerlo asi.
... para que preguntas. Te han dado bastantes razones de por qué separar los ficheros y la BB.DD, con las que estoy de acuerdo(Oracle aparte, probablemente tenga su manera de hacerlo dentro de sí mismo, pero es que casi es un S.O. de por sí). Yo te voy a dar el punto de vista de sistemas, por si te valen de algo, ya que tenemos una aplicación bastante parecida.
Si vas a generar 170GB de datos al año, tienes que tener en cuenta el coste y función de los discos. Los requerimientos para una BB.DD. con cierta carga son distintos que para un FS donde vas a escribir casi secuencialmente y en el que no vas a borrar prácticamente nada (baja fragmentación). En el primer caso, raid 5 preferiblemente por hardware con discos SCSI no muy grandes(¿36GB?) sería una buena elección. Para el segundo caso, discos grandes SATA/IDE con RAID 1 por Soft sería suficiente (preferiblemente en una NAS que exporte por NFS, las hay bastante baratas y además descargas de CPU a la máquina de la BB.DD).
Meterlo todo en la BB.DD. ralentizará muchísimo las inserciones y lecturas, y hará que tengas discos "caros" desaprovechados y fragmentados. Insisto que una NAS barata puede ser una buena inversión, por 4.000eur tienes asegurada la escalabilidad, además siempre puedes usarla para otros proyectos.Aparte es más difícil corromper un FS que una BB.DD.
Evidentemente, una jerarquía de directorios lógica es necesaria.
Dicho lo dicho, tu verás. Es tu proyecto y lo gestionas como quieres.
--
Programs should be written for people to read,
and only incidentally for machines to execute
No son radiografias, son retinografías y topografías corneales, las retinografías tomadas a 6 mpx, ocupan en jpg unos 700 kb cada una, las topografías son 30000 puntos y se guardan los valores medidos, luego el programa reconstruye el perfil que se requiera.
Me pongo un vestidito rosa y unas gafas redondas cual azafata del "un dos tres" para decir, calculadora en mano, que:
"700kb cada imagen por 20.000 imágenes al mes suponen una base de datos con un crecimiento de... ¡14 Terabytes mensuales! que multiplicados por 12 meses que tiene un año suponen... ¡1´7 Petabytes anuales! ¡Sólo en imágenes! ¡Sin contar las tablas auxiliares y los índices sobre las mismas!"
Me rasgo el vestidito rosa y me quedo en bolas para decirte que como metas eso en posgreSQL la hostia que te vas a dar va a ser escuchada desde la estrella Vega. Si me cuentas que el posgre lo usas para los campos índice y que las imágenes van a un IXOS [ixos.com] me lo creo. Pero si me cuentas que vas a meter una BBDD de ese tamaño en posgre, sólo me queda preguntarte por la fecha del pase a producción para ir encargando la corona de flores.
--
En España la mejor manera de guardar un secreto es escribir un libro.
Pues en lugar de EXT2/EXT3 (que usan una estructura lineal para almacenar el contenido de los directorios) utilizas ReiserFS (que usa una estructura en árbol equilibrado o balanceado, igual que las bases de datos), y listo. Máximo rendimiento a la hora de buscar archivos.
Y ya si me apuras y no quieres irte a eso, puedes crear tú mismo también un sistema jerárquico de directorios para agrupar las imágenes en directorios con menos archivos cada uno.
Vale un poco políticamente incorrecto pero creo que en esencia en este comentario se han desmontado algunas de las falsas creencias que se han dicho antes.
Yo soy de los de base de datos
(Puntos:3, Interesante)El volumen es mas o menos importante, unas 20000 mensuales y bueno, me parece una chapuza informática meter semejante número de ficheros en un sistema de archivos (y no es güindon, no señor).
Meter las imagenes en la base de datos nos aporta otra serie de ventajas, por ejemplo, si se conecta un cliente remoto via inet, la misma aplicación recibirá las imagenes como si fuese local, entre otras cosas.
La base de datos usada es PostgreSQL, y sobre el asunto que comentan por ahí del tamaño de las copias, para copiar solo los datos, pg_dump, sin opcion -b, si quieres los blob, con -b, de todas maneras si hay que hacer un backup de las imágenes, también ocuparán lo suyo aunque sean archivos.
Pero como siempre, para gustos, los colores
Re:Yo soy de los de base de datos
(Puntos:2)( Última bitácora: Domingo, 04 Septiembre de 2005, 12:57h )
No se me habia ocurrido esa posibilidad, si se quiere acceder a la informacion desde otro host diferente al de la base de datos o desde una aplicacion (lo mas normal por cierto) entonces si que seria mas que logico meter los ficheros en la base de datos. Aunque en este caso dice que lo quiere para una pagina web y podrian almacenarse tambien en el sistema de ficheros del servidor de la pagina.. pero creo que tienes razon, si es una base de datos importante que es susceptible de ser modificada / adaptada a nuevas necesidades en un futuro si es logico hacerlo asi.
PISO Pontevedra con Garaje. Rias Baixas. Sanxenxo. Centrico. Playa. [pisopontevedra.com.es]
Si ya lo sabías...
(Puntos:2)( Última bitácora: Lunes, 22 Febrero de 2016, 07:16h )
... para que preguntas. Te han dado bastantes razones de por qué separar los ficheros y la BB.DD, con las que estoy de acuerdo(Oracle aparte, probablemente tenga su manera de hacerlo dentro de sí mismo, pero es que casi es un S.O. de por sí). Yo te voy a dar el punto de vista de sistemas, por si te valen de algo, ya que tenemos una aplicación bastante parecida.
Si vas a generar 170GB de datos al año, tienes que tener en cuenta el coste y función de los discos. Los requerimientos para una BB.DD. con cierta carga son distintos que para un FS donde vas a escribir casi secuencialmente y en el que no vas a borrar prácticamente nada (baja fragmentación). En el primer caso, raid 5 preferiblemente por hardware con discos SCSI no muy grandes(¿36GB?) sería una buena elección. Para el segundo caso, discos grandes SATA/IDE con RAID 1 por Soft sería suficiente (preferiblemente en una NAS que exporte por NFS, las hay bastante baratas y además descargas de CPU a la máquina de la BB.DD).
Meterlo todo en la BB.DD. ralentizará muchísimo las inserciones y lecturas, y hará que tengas discos "caros" desaprovechados y fragmentados. Insisto que una NAS barata puede ser una buena inversión, por 4.000eur tienes asegurada la escalabilidad, además siempre puedes usarla para otros proyectos.Aparte es más difícil corromper un FS que una BB.DD.
Evidentemente, una jerarquía de directorios lógica es necesaria.
Dicho lo dicho, tu verás. Es tu proyecto y lo gestionas como quieres.
Programs should be written for people to read, and only incidentally for machines to execute
Re:va a ser gigante esa base!!!
(Puntos:2)Re:va a ser gigante esa base!!!
(Puntos:4, Inspirado)( http://mcpolu.blogspot.com/ | Última bitácora: Miércoles, 05 Marzo de 2014, 00:04h )
Me pongo un vestidito rosa y unas gafas redondas cual azafata del "un dos tres" para decir, calculadora en mano, que:
"700kb cada imagen por 20.000 imágenes al mes suponen una base de datos con un crecimiento de... ¡14 Terabytes mensuales! que multiplicados por 12 meses que tiene un año suponen... ¡1´7 Petabytes anuales! ¡Sólo en imágenes! ¡Sin contar las tablas auxiliares y los índices sobre las mismas!"
Me rasgo el vestidito rosa y me quedo en bolas para decirte que como metas eso en posgreSQL la hostia que te vas a dar va a ser escuchada desde la estrella Vega. Si me cuentas que el posgre lo usas para los campos índice y que las imágenes van a un IXOS [ixos.com] me lo creo. Pero si me cuentas que vas a meter una BBDD de ese tamaño en posgre, sólo me queda preguntarte por la fecha del pase a producción para ir encargando la corona de flores.
En España la mejor manera de guardar un secreto es escribir un libro.
Re:Yo soy de los de base de datos
(Puntos:2)Re:Yo soy de los de base de datos
(Puntos:2)( http://www.rastersoft.com/ )
Y ya si me apuras y no quieres irte a eso, puedes crear tú mismo también un sistema jerárquico de directorios para agrupar las imágenes en directorios con menos archivos cada uno.
Yo quiero un par de narices...
Re:Yo soy de los de base de datos
(Puntos:2)Como coño se pueden dar puntos?