Información y consejos para proyecto web

[Neftali [Germán.Estévez]]

Empezado por Casimiro Notevi

Y bien, aquí van las preguntas:

• Fotos en una base de datos o fuera
• Si van fuera, cómo organizarlas mejor (esto creo que es lo primordial)
• Hacerlo todo desde cero o aprovechar algo existente tipo joomla, drupal, etc.
• Los servidores estarán alojados físicamente en la central de la empresa, qué medidas de seguridad se recomiendan (Por supuesto, en Linux)
• Lenguaje a usar y base de datos, mi experiencia web no es muy amplia
• Otras cosas a tener en cuenta
• Consejos
  

Hola Casimiro.
Pues no tengo mucha experiencia en Web, pero me interesa que me vayas comentando cómo va el proyecto, Las decisiones que tomas y qué resultado dan.

En cuanto a las preguntas, la primera es la eterna discusión. Creo que nunca se pondrán de acuerdo los defensores de una y otra postura.

Mi experiencia en este campo (no es con una apliación web, pero la problemática es la misma desde una aplicación no-web) ha sido la de escoger guardar los ficheros fuera de la Base de datos. Hay razones para lo uno y para lo otro, pero se trata de ver el peso de cada una y las ventajas que te puede aportar. En mi caso:

* Al incluirlas en la Base de datos el tamaño de esta hace más complejas las tareas "varias" a realizar con la BD. Backups, Restauraciones, copias,...
Una simple multiplicación da muestra de ello. Por ejemplo, fotos de 5 MG; Cuando tengamos 300.000 fotos y hagamos el Backup. ¿Cuanto va a tardar? ¿Dónde lo vamos a meter?
* Al incluir las imágenes fuera de la Base de datos tenemos mucho más control sobre ellas y más facilidad para realizar todo tipo de operaciones. Copias de seguridad, cambios de tamaño, miniaturas,...
* Podemos tenerlas divididas en diferentes ubicaciones físicas de forma mucho más fácil.

································································································
En nuestro caso partimos de un directorio inicial, a partir de ahí tenemos diferentes Volúmenes (VOL) y dentro de los volúmenes, diferentes directorios (DIR).
Se tiene en cuenta que cada Directorio no supere un tamaño especificado u un número de ficheros fijado (5000, por defecto), de esta forma se controla que cada directorio no tenga ni demasiado tamaño ni demasiados fucheros.
Esta ubicación de:
UBICACIÓN -> VOL -> DIR
facilita, por ejemplo, que con pocos cambios se puedan mover los Volúmenes del 1 al 1000 a otra ubicación (otro disco) modificando sólo la Ubicación inicial.
Lo mismo pasa cuando un disco cae, basta con cambiar la ubicación para que las imágenes se vayan a buscar a otro disco (replicación).
································································································

* Otras aplicaciones no tienen porqué tener acceso a la base de Datos. Basta con que se les pase la ubicación del fichero que necesitan (esto hay que evaluar en cada caso si es bueno o malo).

* Un inconveniente de este, es que los directorios de imágenes/documentos deben estar accesibles para más gente/programas de lo necesario. Es decir, cualquier aplicación que deba acceder a una imagen/documento, debe tener acceso al directorio de imágenes. Esto no me acaba de gustar y las posibles soluciones las estamos pensando/evaluando.

[[movorack]]

Lo del tema del acceso a directorios en las aplicaciones web se maneja mas facil pues con los permisos de linux solo permites que el usuario del webserver (apache por lo general) sea quien tenga permiso de entrar a ese directorio y se le restringe el acceso y escritura al publico y/o al grupo.

[roman]

Empezado por movorack

Lo del tema del acceso a directorios en las aplicaciones web se maneja mas facil pues con los permisos de linux solo permites que el usuario del webserver (apache por lo general) sea quien tenga permiso de entrar a ese directorio y se le restringe el acceso y escritura al publico y/o al grupo.

Pero es este mismo usuario el que accede para servir el contenido, así que las fotos estarían al alcance de cualquiera desde la web. Si se usa Apache, hay que usar además un .htaccess para impedir el acceso desde el exterior.

// Saludos

[Casimiro Noteví]

Voy tomando notas de todos vuestros comentarios, por ejemplo:

Empezado por roman

[..] hay que usar además un .htaccess para impedir el acceso desde el exterior. [..]

¿Eso de qué va?

[roman]

Siguiendo el ejemplo de movorack, si tienes el directorio

/photos/2010/04/33025/img1.jpg

el usuario puede poner

http://tuservidor.com/photos/2010/04/33025/img1.jpg

y descargarse la foto sin necesidad de iniciar sesión en tu sistema. Si las fotos no son para el acceso público, debes proteger los directorios donde las guardas. En Apache, esto lo puedes hacer colocando un archivo.htaccess con este contenido:

deny from all

De hecho, acabo de percatarme, que el w2box lo maneja abierto. Por ejemplo, si vas al FTP público y navegas a Delphi|Tools, podrás ver que los enlaces de cada archivo son las rutas directas al archivo. Por ejemplo

http://www.terawiki.clubdelphi.com/archivos/Delphi/Tools/CloneDelphiWizard.zip

Si pones eso directamente en el navegador, podrás descargar el archivo. Sin emabrgo, a manera experimental y temporal, he puesto un .htaccess en

http://www.terawiki.clubdelphi.com/archivos/Delphi/Ejemplos

Intenta descargar ahora uno de los archivos de esa sección...

De todas formas, hay que tener en cuenta, que el Apache debe estar configurado para procesar archivos .htaccess.

// Saludos

[Casimiro Noteví]

Ya entiendo, me dice que no tengo permisos.
Ya puedes dejarlo como estaba


Por cierto, aunque no lo he hecho yo directamente, sí he colaborado en bastantes cosas de un proyecto parecido que hicimos en mi trabajo hace varios años.
Era, y es, como un sistema de ventas con carrito de la compra, navegas por los artículos, ves las fotos, las amplias, etc. y haces el pedido de las unidades que quieras.
Está hecho en php con firebird y los datos de los artículos y los pedidos los almacena directamente en el otro servidor, donde está la gestión comercial de la empresa.
Pero yo no "piqué" el código. En este caso me tocará a mí, seguro.
La principal diferencia es que este nuevo proyecto es prácticamente todo fotos, es lo principal, y es también el motivo de pensar no almacenarlas en la base de datos, porque un millón de fotos a sólo 1 mega por cada una son... un millón de megas. Pues no sé cómo hice las cálculos, pero había sacado mucho más, si es así entonces sería sólo 1 giga de base de datos.
Creo que me equivoco en algo.

[mamcx]

Algo de lo que no hablas es cuantos accesos concurrentes hay, cuales son los parametros de confiabilidad y tiempo en linea y como rayos se manejaran los backups!

Puedes leer algo general sobre hacer aplicaciones escalables y robustas aqui:

http://www.slideshare.net/mmalone/sc...django-1393282

(Es en django, que es lo que recomendaria pa usar: PHP es como usar C++, con la legibilidad del PERL... pero bueno son lecciones que se pueden aplicar a lo que sea, esta desactualizado en cuanto no hay nada maduro en Nosql, ahora SI).

Con respecto a lo de las imagenes, la mejor explicacion sobre este tema y todos los demas la vi aqui:

http://www.slideshare.net/fbrunel/ja...rlin-sept-2007

(Es una presentacion larga pero ponle mucho cuidado a donde arranca en "Pay attention in how you store the files" y muestra las diferentes estrategias.)

Yo hosteo en www.joyent.com y me ha ido bien, y esta gentes es muy experta en estos temas. Valdria la pena que tal como recomiendan en la presentacion, evaluaras opensolaris/zfs/zones como infraestructura....

El manejo de los archivos, si terminan siendo masivos, depende mucho de que tan bueno sea el array de almacenamiento en red. Otra alternativa, es no usar un BD relacional sino una NOSQL (ya te mencionaron algunas) pero estoy usando MongoDB con GridFS (http://api.mongodb.org/python/1.4%2B...dfs/index.html) que es su API para almacenamiento MASIVO y GRANDE de archivos. Mongo hace backuos en caliente, o mejor dicho, prendes otro servidor, lo metes en la lista, se sincroniza y apagas. Tambien hay un metodo de hacer backup de forma tradicional.

Es muy bueno! Pero el chiste en este caso es que tengas al MENOS 2 servidores que se repliquen entre si (Mongo es muy != a BD relacionales, replicacion es algo natural y sin lios).

AL usar Mongo, no hay problemas de como rayos almacenes los archivos. Y NO TIENES QUE ABANDONAR LA BD. Puedes acceder a la BD de mongo usando cualquier driver (hay para python, php, .net, etc) para el manejo de archivos y la BD pa lo demas.

Mongo es lo que usa SourceForge. Una unica advertencias: Mongo en un solo servidor no es "confiable" en el sentido que se pueden perder datos si hay un crash (=MySql sin transacciones). Los desarrolladores de Mongo apuntan a que la unica forma confiable es federar los datos, y en cierta forma tienen razon.

Lo que me lleva a que me parece MUY mala idea hostiar "en casa". Como muestra la presentacion de joyent, hay tantas cosas que hay que hacer bien que me parece mejor usar un proveedor externo (amazon, joyent, mediatemple, etc...). De lo contrario, buenas UPS, servidores redundantes, buen sistema de almacenamiento en RAID (o mejor aun: Solaris+ZFS).

La BD? Pa lo que mencionas cualquiera daria la talla, excepto por lo de los archivos. Hay o Mongo o ZFS u otro sistema de archivos robusto + estrategia de almacenamiento.

Prueba ademas, usar Cherokee (mas rapido que apache) y/o nginx (mas veloz para servir archivos estaticos. Si no tienes una carga alta por segundo, con cherokee creo que matas todo de un solo tiro.

http://www.cherokee-project.com/doc/ Muestra que tienes proxy reversos, balanceos, modulo para generar links a archivos temporales (lo que impide el lio que menciona roman) y mas cosas con lo que 1 solo servidor te cubre como a 5.

Una BUENA aplicacion web, usa URLS que no estan ligadas al sistema de archivos (o url limpias o bonitas como le llaman). Con django/rails es lo normal que las URLs representen el mapeo a las vistas asi que no hay nada de eso de usar .htacces y cosas asi raras (y es comun usar un servidor web independiente, no apache, para servir archivos).

[roman]

Las razones que expone Neftali son bastante convincentes para almacenar las fotos fuera de la base. Aunque si generas miniaturas, quizá éstas sí podrías guardarlas en la base. Sería más cómodo para generar listados.

Recuerda que con PHP también puedes usar Firebird, así que no tendrías que desprenderte de tu motor favorito.

Al guardar las imágenes en archivos en disco, hay que tener en cuenta que no puedes guardarlas en rutas accesibles desde la web (a menos que cualquiera pueda verlas). Tendrás que impedir su acceso y usar el mismo PHP para recoger las fotos y servirlas.

Desde luego, no creo que ningún CMS como joomla, drupal, wordpress, etc. sirva para esto. En todo caso, sería más adecuado algo como el w2box, que es el que usamos aquí en los foros para gestionar los archivos del FTP público. Aunque más que nada para darte una idea, porque también pienso que los mejor es hacerlo desde cero, que no parece un proyecto complejo.

// Saludos