Hola,
Hace un buen tiempo que trabajo con Gemstone/S, con lo cual
puedo contar algunas experiencias. Nunca he usado un esquema tipo
Omnibase ni otro esquema de persistencia pasivo en forma comercial y por
bastante tiempo, con lo cual me limito a opinar sobre Gemstone/S.
El trabajo es muy diferente a usar una base SQL. El trabajar con
objetos no es fácil de entender y a mucha gente le deja más tranquila
hacer un SQL y ver sus datos ahi tranquilitos, sin que ninguna magia de
GC se los vuele :-)
Una cosa es que en un esquema de objeto JAMAS tenés un join
largo, si pasa esto es porque se está violando la encapsulación de los
objetos del modelo en algún lugar o falta que otros objetos se conozcan
entre si, etc.
No me imagino otra manera de poder escribir una consulta en
Smalltalk larga.
Los problemas que podés encontrar en un esquema de persistencia
con objetos son:
a) Congestión de la red. Traerse los objetos al cliente y el
problema que ocasiona que los objetos viajen por la red. Entonces tenés
mecanismos de proxies que ayudan a que solo viaje lo estrictamente
necesario.
b) Espacio en disco. Generalmente crecen mucho con la actividad
de las transacciones, se crea mucha basura que luego es actividad del
GC, los extents se agrandan y la única manera de bajar el espacio
ocupado en disco por los extents de una base es un Backup/Restore. Esto
es por la arquitectura multigeneracional que usan. El único motor SQL
que sabía que era multigeneracional era Interbase, y también se
resolvían muchos problemas de la misma manera que en Gemstone (Sweep +
B/R).
c) Actividad del GC. Cuando hay mucha actividad en la base se
genera mucha basura, esta cantidad de basura genera mucha actividad del
GC. Como sabemos un GC es un proceso de mucho stress en el ambiente con
lo cual puede tirar abajo la performance. Para evitar esto hay muchas
técnicas, por ejemplo, Gemstone/S tiene 5 tipos diferentes de GC, que
ayudanm a aliviar esta actividad. También hay otra técnica en la se
puede desactivar el GC, a costo de consumir disco, y en una base espejo
paralela ir corriendo en GC, marcar los OOP de los objetos que van a
morir y luego correrla (en horarios con menos actividad) sobre la base
productiva.
Como se ve, hay muchas cosas por las que preocuparse en una BO,
y ninguna tiene que ver con los problemas que se sucitan en un motor
SQL.
Con respecto a lo que decía Ramiro, seguramente se refiere al
punto a), traerte todo la colección de objetos persistentes al cliente
para luego consultarlo y quedarte con uno, es una locura. Si la red es
local, quizás ni se note, pero si es Wan puede ser que tarde siglos en
moverse, y es lógico. Lo que el menciona sería un remotePerform: en la
base. Esto lo provee Gemstone/S, o la otra solución es traer proxies, y
que estos a medida que vas consultando vaya trayendo de manera onDemand
lo que requiere. Hay varias técnicas de resolución.
Saludos,
Hernán.-
Pd. Es un tema muy interesante :-)
-----Mensaje original-----
De: [email protected]
[mailto:[EMAIL PROTECTED] En nombre de Ramiro Diaz Trepat
Enviado el: Lunes, 07 de Agosto de 2006 09:27 a.m.
Para: [email protected]
Asunto: [clubSmalltalk] Re: OmniBase
On 8/7/06, GallegO <[EMAIL PROTECTED]> wrote:
>
> Bruno BB (st) escribió:
> > Lo que tenes que tener cuidado es que un ODBMS no es una RDBMS, y se
> > trabaja de forma diferente.
Si, pero el lenguaje de query sigue siendo necesario, al menos algo como
el que está proponiendo Magma. En vez de navegar todo desde un root
Dictionary.
Por más que sea un modelo de objetos, siempre que necesites hacer
consultas complejas que involucren varios joins de mucho volumen, vas a
tener que hacerlas con un lenguaje de consulta (aunque no sea SQL) para
que las resuelva el motor de base de datos y no las resuelvas vos a
nivel de lenguaje con #collect, #select, etc. Lo que sería -creo- muy
ineficiente.
Me alegro de escuchar que OmniBase le anduvo muy bien a mucha gente. La
última vez que lo probé sobre Squeak/Linux tenía un problema de locks
que aún no habían resuelto. Pero escuchando todos estos comentarios
favorables, voy a volver a probarla.
Pero por ahora, me inclino por Magma por que le están dando bola a la
forma de hacer consultas.
--~--~---------~--~----~------------~-------~--~----~
Ha recibido este mensaje porque está 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íe un mensaje a [EMAIL PROTECTED]
Para obtener más opciones, visita este grupo en
http://groups.google.com/group/clubSmalltalk.
-~----------~----~----~----~------~----~------~--~---
