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. -~----------~----~----~----~------~----~------~--~---
