Hey Ramiro gracias por la sintesis, estuve leyendo el código de Gjallar y el pool de conecciones no es nada del otro mundo. De hecho es una sola clase y la puse en un paquete monticello aparte en 5 min. La estoy empezando a probar. Vamos a ver todavía no la cargué con muchos usuarios pero no me dio ningún problema despues de portarla dándole un uso básico con sesiones seaside.
Por lo de hacer algunas de lectura y otras de lectura/escritura no llegué a ver que la pool haga nada en especial. Al menos en Gjallar 0.3 no vi nada tipo #getReadonlySession, tiene el método #getSession normal (que la agarra activa y/o revive y/o crea en forma protegida por un semaforo). Lo de la performance.. si se trata de una aplicación seaside está la web de por medio y eso enmascara un poco para el usuario por lo que creo que manejándose con cuidados debería poderse lograr una experiencia buena. Lo que si hay que evitar al máximo es la agrupación de muchos objetos en una coleccion. Hay veces que no se puede evitar pero creo que se debe tratar de evitar. Para ilustrar lo que digo se me ocurre este ejemplo: si uno tiene que modelar las personas en un país, en ves de hacer Pais>>ciudadanos ^ ciudadanos y que en esa instVar esten todos los individuos, (supongamos un orden de magnidud inferior a la centena de millón) sería preferible hacer que Ciudad>>ciudadanos ^ ciudadanos cada ciudad los (sos)tengan y para consultarlos hacer que las queries tengan el rol de encuestas. Si unaCiudad supera un número de individuos que sea fácilmente o razonablemente manejable y ocurre que por ejemplo supera los 100mil individuos, entonces instanciarla como CiudadGrande y particionar los ciudadanos a que los tengan algunosBarrios. Todo esto de la tecnología de objetos virtuales que se comunican es para crear un ambiente que propicie hacer fácilmente (para nosotros los humanos) modelos virtuales, y limintados, de objetos reales que son órdenes de magnitud más complejos. Las odb no hacen otra cosa que persistirlos tal cual son en algún medio tecnológico y en forma confiable, fault tolerant, ACID, etc. Esto significa que la virtud de la odb es que no te exige que revirtualizes (alejando aún más de la realidad el modelo) lo ya virtualizado en algún otro molde, como por ejemplo tablas, porque el estado de la tecnología al dia de hoy es una kk en cuanto a usabilidad para desarrollar. Con esto quiero decir: las odb te ayudan a no deformar más el modelo y facilitarte la vida para materializar la virtualización del modelo vigente. O sea respetando lo mejor posible el concepto que un cerebro humano concibió y eligió aceptar como válido (realísticamente solo por un período) para un objeto real. Por qué digo todo esto? para contextualizar esto: minimizar la importancia o no valorar la citada virtud es dejar de lado la heurística no en uno sino en varios de sus principios. También reflexiono y me pregunto por los números que Norberto citaba. 12mil objetos deberían ser "like a walk in the park" para una odb de modo que voy a hacer un par de pruebas de carga a ver como se desempeña. saludos, Sebastian PD: si después le venden sistemas de encuestas de opinión a las consultoras de los candidatos por favor hacerlos mejores que los del INDEC </chistin> On Oct 18, 10:08 pm, "Ramiro Diaz Trepat" <[EMAIL PROTECTED]> wrote: > Un par de aclaraciones más, aunque vuelvo a aclarar: no por > experiencia real en sistemas en producción: > > 1. Chris dice que cuando separás el cliente y el servidor Magma, la > parte gruesa del trabajo se la lleva el cliente, no el servidor, como > quizás sea más intuitivo pensar. Por lo que la distribución de carga > entre n servidores está buena seguro, pero también hay que pensar en > el cuello de botella de los clientes. > > 2. Usar connection pools en las sesiones de Seaside es crítico. > Göran dijo alguna vez que los connection pools de Gjallar estaban muy > buenos por que diferenciaban sessiones de lectura y de escritura, pero > la verdad nunca las vi. También dice que no tiene tiempo de > *refactorizarlas* en un paquete externo. > > 3. Chris tiene siempre la mejor y te ayuda todo lo que puede, en la > lista y fuera de lista. Yo en una época le quemé la cabeza, realmente > pensé que me iba mandar al carajo, pero simpre me dio bola con mis > problemas. Yo vengo *jugando* con Magma desde 2003 y siempre fue así. > Comparado con el soporte de GOODS y OmniBase, me quedo seguro con > Magma. GLORP tiene una buena lista y soporte... pero hay que venderle > el alma al diablo de las bases relacionales :) Hay una forma de hacer > el uso de GLORP más amigable, más parecido al ActiveRecord de Ruby, > con el paquete MagretteGlorp de Ramón Leon, pero en muchas > circunstancias no funciona y hay que terminar uando GLORP puro. > > 4. Magma tiene un sistema de queries que, a mi criterio, es un valor > agregado enorme, y sé que esto es un asunto discutible, que hay mucha > gente que te dice que es "solo una cuestión de diseño". En los > sistemas grandes uno piensa un modelo lo más puro posible y no desea > pensarlo en función de consultas posteriores, después los usuarios > piden reportes complejos y cosas como un "order by" te pueden venir > mucho mejor que estar filtrando y ordenando colecciones a mano. > > 5. Otro punto a favor es que creo que Magma es estable, y Chris le > pone tests muy rigurosos. > > 6. De a poco, le van dando más lugar a Magma en la comuniad Squeak. > Creo que están explorando hacer la persistencia de Pier y de > squeaksource sobre Magma. Pero realmente nos sé como va esto. > > La verdad, creo que el único punto fuerte en contra de Magma es la > performance, y por cuestiones de diseño, esto siempre hay que probarlo > en el caso particular de cada uno. > Otro punto en contra podría ser que no está disponible en otros > dialectos fuera de Squeak. > > Saludos > > r. > > On 10/18/07, Sebastian <[EMAIL PROTECTED]> wrote: > > > > > Hola Norberto, > > > esta respuesta está mejor que algunos post de blogs que vi por ahi > > (bueno que para ser justos hay que aclarar que en realidad eran > > bastante básicos). Pero realmente conocer los detalles que comentás de > > la experiencia que pasaron al usarlo me resulta de lo más interesante. > > > Con lo que vi de Magma, muy superficialmente, hasta ahora, también me > > resulta muy atractivo el nivel de transparencia que promete. Parece > > ser ideal para cuando uno necesita poner todo en un objeto modelo y > > usarla acediendo a cada cosa según su reacheability con ese root > > object (que debería ir somewhere en el diccionario root de magma) y > > usar las MagmaCollections solo cuando se trata de muchas instancias. > > > Las pautas que pasaste me traen algunas preguntas que me gustaría > > pasarte: > > -Quisiera saber si te interpreto correctamente cuando decís: "También > > es bueno mantener el diccionario (root) de las colecciones magma." te > > referís a que las MagmaCollection son más ineficientes si están en > > algún lado diferente (más profundo del modelo persistido) que a > > tenerlas instaladas directamente en un valor del diccionrio root? o se > > trata de otra cosa? > > -Cuando decís que no deja de pensar en bases de datos te referís a qué > > aspecto/s exactamente? a los problemas de transacciones, concurrencia, > > al relacional o a algún otro/s? > > > Con certeza que hay que colaborar tanto para su usabilidad como buenas > > prácticas, etc porque esto lo banca la comunidad pero más que nada > > Chris M. y es la única forma de salir del problema del "one man show" > > que bien menciona Ramiro y que no me preocupa a priori porque todos > > hablan bien del soporte que viene dando hace rato Chris. Por otra > > parte la comunidad va mostrando tímido interés a medida que Magma > > mejora. Una clara señal de esto es el proyecto Gjallar el cual estoy > > leyendo código para ver como van usando la odb. Ya vi por ejemplo que > > usan un pool de conexiones me pareció bien interesante. Y bueno > > también porque lo cierto es que no tenemos a la mano alternativas open > > que sean más atractivas. > > > Imagino que lo de la posibilidad de hacer un farm de magmas debe ser > > el camino de esto pero te hago la pregunta igual la van a usar > > multiusuario? aparentemente Gjallar la usa multiusuario y tengo > > entendido que es el uso más osado en el sentido de que las actuales en > > realidad son todas experiencias pioneras porque no ha nadie que haya > > cargado mucho a Magma (no solo en cantidad de instancias) en el > > pasado. Algo con respecto a la carga de usuarios? > > > Lo que después le respondiste a Ramiro acerca de la memoria que va > > creciendo tiene alguna consecuencia extra además de no liberarla? > > concretamente ese problema llega a ser grave como generar caídas de la > > imagen o algún otro tipo de inestabilidad? o simplemente hace que se > > infle digamos hasta 200 megas y despues nunca adelgace? es 200 megas > > un numero cercano al que experimentaron o sería mayor? > > > gracias de nuevo por la info y saludos, > > > Sebastian > > > On 18 out, 10:15, "Norberto Manzanos" <[EMAIL PROTECTED]> wrote: > > > Hola Sebastián. > > > Nosotros (Juan Burella, Hernán Morales y yo) estamos usando Magma y en > > > estos > > > días estamos poniendo en producción lo que venimos haciendo. > > > Optamos por Magma porque era la solución más transparente a nuestra > > > disposición. En eso me parece que le gana a todos (dentro de lo que es > > > gratarola), aunque no es lo suficientemente transparente, porque uno no > > > deja > > > de pensar en términos de "base de datos". > > > El gran problema de Magma es la performance, esto es gravísimo. > > > Por ejemplo, nosotros teníamos que hacer una migración de 12.000 registros > > > de una base de datos que se convertirían en otros tantos objetos, con > > > bastante profundidad, lo cual terminaba en unas 15 colecciones Magma con > > > algunos miles de objetos cada una. Como la base original no estaba > > > normalizada, había que buscar en magma cada cosa que se agregaba para no > > > duplicarla. La migración, a pesar de varios intentos de optimizar estos > > > tiempos, tardó 10 dias!!!! > > > En la aplicación que estamos poniendo en producción, los tiempos de > > > recuperación de objetos son apenas aceptables. > > > Te paso algunas pautas > > > - Es muy importante controlar cuantos objetos se materializan cuando uno > > > muestra subconjuntos de una colección. > > > -Mantener los MagmaCollectionReader en memoria mejora muchos los tiempos. > > > - También es bueno mantener el diccionario (root) de las colecciones > > > magma. > > > - La generación de índices es bastante costosa. Hay que buscar el > > > equilibrio > > > entre la cantidad y tamaño de los índices y la performance. En el caso > > > de > > > subidas masivas de datos, es preferible tener un sólo índice impresindible > > > durante el proceso, y después agregar los demás al final. Tener un índice > > > es > > > imprescindible, no se gana nada al crear una colección sin índices y > > > buscar > > > por oids. > > > > Espero que te sirva para algo. Cualquier duda, preguntame a ver si se como > > > resolverlo. Lo mismo si descubrís algo importante, pasalo, porque la > > > documentación es muy escasa, así que son más las dudas que las certezas. > > > > Saludos > > > Norberto > > > > On 10/17/07, Sebastian <[EMAIL PROTECTED]> wrote: > > > > > Hola todos, > > > > > quería preguntarles si alguno ha usado con éxito Magma en > > > > producción, que le parece el sistema, en fin cualquier feedback y en > > > > general que les parece Magma. Escucho todas las opiniones más aún las > > > > que sean basadas en experiencias de produción reales (workload, etc). > > > > > gracias, > > > > > Sebastian --~--~---------~--~----~------------~-------~--~----~ Has recibido este mensaje porque estás suscrito a Grupo "clubSmalltalk" de Grupos de Google. Si quieres publicar en este grupo, envía un mensaje de correo electrónico a [email protected] Para anular la suscripción a este grupo, envía un mensaje a [EMAIL PROTECTED] Para obtener más opciones, visita este grupo en http://groups.google.com/group/clubSmalltalk?hl=es. -~----------~----~----~----~------~----~------~--~---
