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