El Lunes, 15 de Marzo de 2010 13:58:13 Camaleón escribió:
El Mon, 15 Mar 2010 13:21:06 +0100, Angel Alvarez escribió:
El Lunes, 15 de Marzo de 2010 11:07:11 Camaleón escribió:
Haz las pruebas en remoto, así mola más.
en realidad no, la latencia de red no me indica nada (al menos de momento)
Porque no querrás implementarlo en un sistema de correo real >:-)
Lo que quiero ver es que tal se comprta ls BBD con mucho correos, busquedas etc...
Ah, vale, eso es otra cosa.
Pero de un servidor de correo interesa ver cómo gestiona el ancho de banda y la carga de trabajo (búsqueda e indexación de correos) sobre enlaces ADSL y también conexiones 3G con imap que tan de moda están ahora (todo el mundo tiene un "smartphone" de esos y quieren tener acceso al correo).
Si, pero muchos cleinte sde correo hacen un pobre uso de IMAp y de sus extensiones... por tanto es dificil ver algunas cosas
¿Has probado Cyrus? Dicen que es muy bueno para estas cosas. Si pero no aporta nada nuevo
Ni falta que le hace si realiza su trabajo mejor que cualquier sistema "novedoso".
Si es cierto pero Cyrus en Filesystem no DB que es lo que quiero ver
Vale, pero entonces no le veo sentido a probar un servidor de correo con una bd como backend. ¿Qué quieres probar realmente, el rendimiento del servidor de correo o el rendimiento de una bd?
Ambos
Me gustaría ver una comparativa de rendimiento de servidores de correo con backend de mensajes en una bdd o sobre sistema de archivos. Tener una bd por detrás tiene que penalizar de alguna forma u otra.
¿Porqué? es peor tener un sistema de ficheros y tener que indexar por tu cuenta, gestionar los bloqueos etc... un FS no es ni un SGBD relacional y ni documental... Al fin y al cabo cuando sabes la estructura de tu problema y las relacionas entre las partes el modelo relacional surge en su máximo esplendor... Es tantop sinsentido acceder via imap a unos ficheros como accder via SGBD a unos mensajes... pero mira como google demuestra que ni uno ni otro están mal, todo depende de como "veas" la información. Ellos no veén correos, solo conversaciones... y además usan una BBDD ( mas bien un key store) para soportarlo...
¿Gestión de filtros en el servidor? ¿Sieve? Si, tiene sieve, busquedas completas de texto etc...
Eso está bien.
Lo siento pero no me creo que empresas como Google, Amazon, Facebook, Twitter o la propia Digg:
a) No tengan ingenieros que sean capaces de saber cómo escalar bases de datos relacionales
b) No sepan SQL Ya, pero tiene restricciones de time to market, etc.. que no sirmpe les permiten hacer un diseño y puesta en ejecución a la manera clasica.
No sé... yo creo que tienen libertad total para hacer lo que quieran. Ellos tienen la pasta, ellos deciden y marcan su ritmo, además de marcar tendencias.
Algunos ni siquiera tiene claro que están haciendo (twitter) o empezxaron con un modelo no adecuado )Digg)
Es normal, los proyectos evolucionan según el uso que le dan los usuarios y no es fácil predecir una única utilidad para los servicios de la nube.
El caso del cambio de Digg a una db nosql es muy reciente. Estuve leyendo los motivos que daba uno de los propios desarrolladores y me pareció interesante:
Looking to the future with Cassandra http://about.digg.com/blog/looking-future-cassandra
Y ojo, que Cassandra está escrita en Java...
Saludos,
-- Camaleón
-- No imprima este correo si no es necesario. El medio ambiente está en nuestras manos. __________________________________________ Clist UAH a.k.a Angel __________________________________________ Evitar la programación defensiva. Manual de Erlang -- Para dar de baja la suscripción, mande un mensaje a: opensuse-es+unsubscribe@opensuse.org Para obtener el resto de direcciones-comando, mande un mensaje a: opensuse-es+help@opensuse.org