Re: [Tabularium-devel] Algo más usable

[Muammar El K. <mu...@pr...>]

Hola,

2009/12/1 CaStarCo <cas...@gm...>:
> He mejorado el sistema de login y he añadido información referente a la base
> de datos (aunque aun no la uso al 100%), también he añadido documentación
> referente al almacenamiento de libros digitales, estaría bien discutir la
> forma, pues si queremos que escale debemos poder distribuír la carga de
> almacenamiento y accesos.
>

Esto sería bueno discutirlo en otro hilo.

> He propuesto un sistema en el que el almacen está subdividido en arbol de
> directorios con un grado de ramificación 16 , todas los directorios y
> subdirectorios nombrados con las letras 0, 1, 2, ..., 9, a, b, .., f. Cada
> fichero iría a una carpeta u otra dependiendo de su valor md5 (que quedaría
> guardado dentro de la DB), dado que la distribución de las imagenes para la
> función md5 es homogenea, se puede esperar que los libros estén repartidos
> de forma más o menos homogénea.
>

¿Entonces lo que sugieres es ingresar al archivo los libros según la
primera letra o dígito de su valor md5?

> Separar los libros en diferentes directorios, por un lado aporta cierto
> orden, (aunque no sea inteligible para un ser humano que lo examine a ojo de
> buen cubero), y por otro abre las puertas a montar diferentes sistemas de
> archivos existentes en máquinas remotas, lo que serviría para distribuír la
> carga tal y como indicaba en un principio.
>

Eso sí. Es posible montar cada letra/dígito en una partición distinta.

> Lo que no sé es como lo haríamos para (en un futuro lejano) hacer que el
> frontend (nginx, cherokee, o apache) no se transforme en un cuello de
> botella. Ahora mismo el sistema está ideado para correr entre unas 2 y 8
> instancias de tabularium (una por procesador o núcleo) que actuan como
> backend de nginx, que se encarga de distribuír la carga y de servir los
> ficheros estáticos (para lo que está mucho mejor diseñado que tornado, que
> tiene un mejor desempeño para las aplicaciones dinámicas como tabularium).
>

Esto lo veremos a lo que se implemente el software. El cuello de
botella que se podría generar no solo depende de la aplicación si no
también de la configuración del servidor (ya sea nginx, cherokee, o
apache2).

> El problema que veo a la larga (y supongo que me parece un problema por
> falta de conocimientos.. seguro que hay alguna solución, si no los de
> google, wikipedia u otros servicios de uso masivo no podrían con nada) es...
> vale, toda la carga de tratamiento de la información está bien repartida...
> pero ¿y qué pasa con la carga que tiene que soportar el intermediario
> (nginx)? ¿como se distribuye la carga ligada a la transferencia de datos?
> Aquí estoy yendo muy lejos ya, pero creo que es interesante plantearse la
> cuestión.
>

Estas son buenas preguntas, pero cada servicio trae consigo la
necesidad de distintas soluciones. La mayoría de esas empresas y
organizaciones que nombraste tienen que hacer modificaciones desde
cambiar algo en el kernel para mejorar el manejo de los recursos del
hardware hasta cambiar la aplicación misma.

> Por cierto, cosas que faltan y son sencillas, si queréis hacer algun apaño:
> · Mejorar la seguridad en los formularios para hacerlos resistentes a  SQL
> injection (ya son resistentes, en teoría, a ataques xsrf)

Se puede investigar, sería bueno reportar ese error en el BTS de
tabularium porque si no todo se quedará en un correo.

> · crear scripts que permitan una puesta a punto rápida del sistema para
> reducir el tiempo de preparación y permitir que más gente pueda colaborar
>

IDEM.

Saludos,
-- 
Muammar El Khatib.
Linux user: 403107.
GPG Key = 127029F1
http://muammar.me | http://proyectociencia.org
  ,''`.
 : :' :
 `. `'
   `-