Almacenar imagenes, cual es el limite?

Saludos
Estoy haciendo una aplicacion donde cada usuario podra almacenar unas
5 o 6 imagenes.
Mi idea es que para cada usuario es crear un directorio con su avatar,
las imagenes, los thumbnails…

La unica duda que tengo es como va a escalar la cosa (dudo mucho que
llega a tener centenares de miles de usuarios
pero nunca se sabe).
Cual es la forma optima de almacenarlo? cual es el limite de
directorios que puedo crear (sobre ext3) sin que se vea penalizado el
rendimiento?
Os habeis encontrado con este problema o solo son paranoias mias?

Gracias

On Jan 2, 2008 6:47 PM, trancos asd [email protected] wrote:

directorios que puedo crear (sobre ext3) sin que se vea penalizado el
rendimiento?

En ext3 el límite es 32000, aunque el rendimiento se empieza a ver
afectado bastante antes. Así que lo suyo es usar alguna forma para
dividir en subdirectorios (casos típicos: usar la inicial, p.e.
t/trancos, s/sergio, etc., algún tipo de checksum…). Si ves el
plugin attachment_fu usa una jerarquía de directorios con números
(aunque no recuerdo con qué lógica los calcula).

En Reiser no hay límite, pero el descenso de rendimiento
también está ahí.
De todas maneras busca comparativas y tal que seguro que las hay (no
es un tema para nada específico de Rails).

Os habeis encontrado con este problema o solo son paranoias mias?

Creo que sí que hay algo de paranoia. Quiero decir, se pierde
rendimiento, y cuesta tan poco hacerlo bien que se debe hacer, pero
creo que si creces te encontrarás muchos otros problemas antes, a no
ser que tu aplicación sea intensiva en eso.


Sergio Gil Pérez de la Manga
e-mail > [email protected]
blog > http://www.lacoctelera.com/porras

Yo creo que un buen límite es 1000 directorios por directorio, de esta
manera ext3 no se degradará y tendrás siempre las imágenes
clasificadas para encontrarlas sin problemas.

En cuanto a lo que comentas de la escalabilidad, está bien tenerlo
presente, pero aparte de gestionar los uploads de manera eficiente
tienes que centrarte en optimizar las consultas SQL y las relaciones
entre modelos para no realizar demasiadas peticiones a la base de
datos y ralentizar así la
aplicación.
Por ejemplo: si en lugar de guardar un campo con la url de la imágen,
puedes crearte un helper que te averigue la url en función del id te
ahorrarás una consulta para saber dónde está la imágen. Hay cientos de
ejemplos como este, pero solo debes tenerlos en cuenta y aplicarlos si
realmente el tráfico de tu sitio va a ser muy elevado.

Hay muchas cosas a tener en cuenta a la hora de escalar una aplicación
y está bien tener en cuenta estos aspectos, pero no escales antes de
tiempo.

El 02/01/2008, a las 18:47, trancos asd
escribió:

Saludos

Buenas,
yo más que por el rendimiento(que también, claro), me
preocuparía máspor la parte de la escalabilidad por si en algún momento dado te
quedases sin espacio en el disco duro y es que si lo organizas por
subdirectorios como comenta Sergio(otra opción es usar fechas en plan
yyyy/mm/dd/id, aunque esto pega más si tienes que hacer noticias o algo
parecido), siempre podrás montar los directorios de datos en distintos
discos duros o incluso usar NFS y tenerlos en otra máquina distinta y
sería totalmente transparente para tu
aplicación.
Ya aprovecho l

Sergio Gil Pérez de la Manga
escribió:> On Jan 2, 2008 6:47 PM, trancos asd [email protected] wrote:

Cual es la forma optima de almacenarlo? cual es el limite de

rendimiento, y cuesta tan poco hacerlo bien que se debe hacer, pero
creo que si creces te encontrarás muchos otros problemas antes, a no
ser que tu aplicación sea intensiva en eso.


/**

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs