[l-desarrollo] Intersystems' Caché vs. PostgreSQL

[Alejandro Imass]

Tenemos uns proyecto con PgSQL y el cliente nos ha pedido que
evaluemos cambiar a Caché a su costo por supuesto.

Quisiera saber si alguien aquí conoce la BD Caché de Intersystems y
cómo se compara contra PostgreSQL.

http://www.intersystems.com/cache/technology/techguide/cache_tech-guide_intro.html

Creo que los mismo se puede lograr combinando PgSQL con algo como
CouchDB (u otros noSQL) y _ciudado_ si no es exactamente lo que está
detrás de este producto.

Lo que quisiera saber es que si alguien aquí ha usado este producto y
lo puede des-mistificar a ver si estoy en lo correcto y al final son
un poco de cosas pegadas para dar la impresión que es un producto
end-eo-end objetos Y relacional a la vez como ellos lo pintan.

Saludos,

--
Alejandro Imass
_______________________________________________
l-desarrollo mailing list
l-desa...@velug.org.ve
http://listas.velug.org.ve/mailman/listinfo/l-desarrollo

[José Manuel Peña P.]

Alejandro,

Realmente no he trabajado con esa base de datos, pero me da la impresión de que es una base de datos de objetos mas, como otras que hay en el mercado: http://www.db4o.com/about/productinformation/db4o/ y http://www.objectdb.com/.

Dudo mucho que tenga que ver con CouchDB, ya que esta es una BD orientada a documentos y no "objetos".

Ahora bien, el problema es que no se conoce a casi nadie que haya trabajado con BD orientadas a objetos, sin embargo, teóricamente puede tener ventajas para aplicaciones de negocio tales como eliminar la llamada "impedencia objeto-relacional", en la cual un dato tiene que pasar por varias etapas antes de llegar al GUI. 

En este link hay evidencia de este tipo de ahorro: http://www.jpab.org/All/All/All.html. Claro que, este ahorro se da entre varias razones por que el manejador se ejecuta embebido, en el mismo proceso de la aplicación y por la inexistencia de la impedancia. Creo que la regla en general es que tu "manejador de BD orientada a objetos se ejecute en la misma VM" que tu aplicación, sea la plataforma que fuere (Java, Python, .NET, Perl, etc)

Por cierto, las BD no-sql como MongoDB, CouchDB, Riak, Cassandra, etc, se aprovechan también de un mapeo mas directo al ser BD orientadas a documentos o pares clave-valor, pero siguen teniendo la necesidad de utilizar comunicación entre procesos.

Ahora bien, debido a que lasBD no-sql orientadas a documentos han abandonado el inmenso poder existente en el álgebra relacional, se las han arreglado para mejorar el tema de la complejidad y performance de las consultas en noSQL (map-reduce y vistas indexadas), al costo de que hay que "programar" las consultas, pero por lo menos hay documentación y ejemplos de como hacerlas. Sin embargo, con todo y eso, no me atrevería a usar una noSQL en una aplicación transaccional.

En el caso de las BD orientadas a objetos no tengo la menor idea de como se pueden manejar consultas complejas y estadísticas, y parece que no hay demasiada documentación al respecto.

-- 

José Manuel Peña P.

[José Manuel Peña]

Se me pasó por alto mencionar que estas Bases de Datos orientadas a objeto tienen mucho más tiempo en el mercado que las del boom de noSQL, y hay que revisar las razones por las cuales no se han adoptado masivamente. Ahora parecieran estar dando cola con el boom, pero realmente es una tecnología mucho más vieja.

Con lo cual se crean mucho más dudas aún sobre el tema de el manejo de la escalabilidad y la concurrencia, que es a donde apuntan las recientes BD NoSQL.

Hay que hacerse la pregunta. Maneja clustering? Sharding? Etc...

Por cierto, el concepto correcto es "diferencia" de impedancia objeto-relacional, no como lo expresé en mi mensaje anterior.

Saludos,

José Manuel Peña

[Alejandro Imass]

2012/11/17 José Manuel Peña P. <josema...@gmail.com>:

> Alejandro,
>
> Realmente no he trabajado con esa base de datos, pero me da la impresión de
> que es una base de datos de objetos mas, como otras que hay en el mercado:
> http://www.db4o.com/about/productinformation/db4o/ y
> http://www.objectdb.com/.
>

Si en efecto. Lo que me llama la atención es que dice que es
relacional y objetos a la vez. habla de herencia múltiple y que la
interfaz en general es SQL. Por eso me parece que dijera PgSQL entre
líneas.

> Dudo mucho que tenga que ver con CouchDB, ya que esta es una BD orientada a
> documentos y no "objetos".
>

CouchDB almacena JSON que es realmente serialización de objetos, al
menos de los atributos de un objeto.

> Ahora bien, el problema es que no se conoce a casi nadie que haya trabajado
> con BD orientadas a objetos, sin embargo, teóricamente puede tener ventajas
> para aplicaciones de negocio tales como eliminar la llamada "impedencia
> objeto-relacional", en la cual un dato tiene que pasar por varias etapas
> antes de llegar al GUI.
>

Lo que hacemos nosotros es trabajar state-less/REST y combinar PgSQL y
CouchDB de la siguiente forma: el path de escritura (POST, PUT,
DELETE) llega al RDBMS y de allí triggers automáticamente serializan
JSON que se distribuye en Couch. Nosotros separamos MVC de Catalyst un
nivel más donde V realmente sigue siendo una capa de recursos JSON y
luego el View como tal corre netamente en el cliente que puede ser un
Browser (usando algo como JQuery + Jemplate) u otro tipo de clientes.

> En este link hay evidencia de este tipo de ahorro:
> http://www.jpab.org/All/All/All.html. Claro que, este ahorro se da entre
> varias razones por que el manejador se ejecuta embebido, en el mismo proceso
> de la aplicación y por la inexistencia de la impedancia. Creo que la regla
> en general es que tu "manejador de BD orientada a objetos se ejecute en la
> misma VM" que tu aplicación, sea la plataforma que fuere (Java, Python,
> .NET, Perl, etc)
>

Si. Igual era Oracle con Forrms y todos sabemos como terminó eso. Yo
creo que toda esa vaina es pura paja y uno tiene que tener control
pleno de todas las capas para poder adaptar tu arquitectura y no
casarte con el último FAD.

> Por cierto, las BD no-sql como MongoDB, CouchDB, Riak, Cassandra, etc, se
> aprovechan también de un mapeo mas directo al ser BD orientadas a documentos
> o pares clave-valor, pero siguen teniendo la necesidad de utilizar
> comunicación entre procesos.
>

Para mí todo lo noSQL y "big data" no es más que un caché sofisticado.
Yo las veo y las uso para distribuir objetos serializados y no
"documentos". Nosotros, de hecho, usamos CouchDB como almacenaje y
distribución de objetos serializados en JSON. Ejemplo: cuando si
almacenamos una factura en PgSQL automáticamente creamos un objeto
JSON que es la versión des-normalizada y se distribuye para la ruta
GET. Si te pones a ver la mutabilidad de los registros de negocios es
mínima y por ende casi todos los documentos y registros
transaccionales de negocio no mutan y pueden vivir perfectamente fuera
del RDBMS, pero como complemento a éste último, no como substituto.
Más aún, típicamente hay entre 3 y 10 queries por cada insert/update.
El truco es analizar la vigencia del dato (vigencia del caché) según
el negocio en particular. Digamos, hay negocio que pueden tolerar que
el nivel de inventario en consulta esté desfasado unos minutos e
incluso horas, hay otros negocios en que no. Hay otros casos que es
igual, por ejemplo una factura una vez impresa es inmutable por
definición, por ende puede vivir por siempre en los caché.

> Ahora bien, debido a que lasBD no-sql orientadas a documentos han abandonado
> el inmenso poder existente en el álgebra relacional, se las han arreglado
> para mejorar el tema de la complejidad y performance de las consultas en
> noSQL (map-reduce y vistas indexadas), al costo de que hay que "programar"
> las consultas, pero por lo menos hay documentación y ejemplos de como
> hacerlas. Sin embargo, con todo y eso, no me atrevería a usar una noSQL en
> una aplicación transaccional.
>

Exactamente!!! Ni de vaina se pueden ver como substitutos a los RDBMS
sino como complementos para poder escapar del teorema CAP. Pero para
poder combinar ambas tecnologías debes modelar adecuadamente (pensar
en entidades que representen su propio estado, a.k.a. REST). Lo otro
que dices y que es muy cierto es que al final del día en noSQL la
complejidad se esconde en el map-reduce y estás trasladando el
problema a otro sitio. Cualquier cosa mas allá estarías solapando con
mundo BI (business intelligence) y no tiene sentido. Las BD noSQL son
cachés sofisticados.

> En el caso de las BD orientadas a objetos no tengo la menor idea de como se
> pueden manejar consultas complejas y estadísticas, y parece que no hay
> demasiada documentación al respecto.
>

Como tu dices, primero no son nada nuevas. Segundo, zapatero a su
zapato. Yo creo que a nivel le los lenguajes los ORM son lo mejor para
aislar al código. Yo creo (y coincido contigo plenamente) que el
almacenaje permanente va __mucho__ mas allá que solo darle
persistencia a los objetos de aplicación. Si fueran solo para eso ni
siquiera necesitaríamos bases de datos!!


En fin, mi pregunta sobre Intersystems es que si no te huele que eso
es algo como Pg + X behind the scenes??

Saludos,

--
Alejandro

[Alejandro Imass]

2012/11/17 José Manuel Peña <josema...@gmail.com>:

> Se me pasó por alto mencionar que estas Bases de Datos orientadas a objeto
> tienen mucho más tiempo en el mercado que las del boom de noSQL, y hay que
> revisar las razones por las cuales no se han adoptado masivamente. Ahora
> parecieran estar dando cola con el boom, pero realmente es una tecnología
> mucho más vieja.
>

Si correcto. Nosotros estuvimos probando una a principios de los '90
pero no recuerdo el nombre en este momento. Como tu dices nunca se han
escuchado en aplicaciones grandes y complejas.

> Con lo cual se crean mucho más dudas aún sobre el tema de el manejo de la
> escalabilidad y la concurrencia, que es a donde apuntan las recientes BD
> NoSQL.
>
> Hay que hacerse la pregunta. Maneja clustering? Sharding? Etc...
>

Exacto!!

> Por cierto, el concepto correcto es "diferencia" de impedancia
> objeto-relacional, no como lo expresé en mi mensaje anterior.
>

Si, correcto. Pero de nuevo, todas esas vainas "one-size-fits-all"
siempre son FADs y malas noticias EMHO.

> Saludos,
>
> José Manuel Peña

[José Manuel Peña]

El 18/11/2012, a las 00:50, Alejandro Imass <a...@p2ee.org> escribió:

> 2012/11/17 José Manuel Peña P. <josema...@gmail.com>:
>> Alejandro,
>>
>> Realmente no he trabajado con esa base de datos, pero me da la impresión de
>> que es una base de datos de objetos mas, como otras que hay en el mercado:
>> http://www.db4o.com/about/productinformation/db4o/ y
>> http://www.objectdb.com/.
>
> Si en efecto. Lo que me llama la atención es que dice que es
> relacional y objetos a la vez. habla de herencia múltiple y que la
> interfaz en general es SQL. Por eso me parece que dijera PgSQL entre
> líneas.

Jeje... Empiezo a entender tu punto.

>
>> Dudo mucho que tenga que ver con CouchDB, ya que esta es una BD orientada a
>> documentos y no "objetos".
>
> CouchDB almacena JSON que es realmente serialización de objetos, al
> menos de los atributos de un objeto.

Así es.

>
>> Ahora bien, el problema es que no se conoce a casi nadie que haya trabajado
>> con BD orientadas a objetos, sin embargo, teóricamente puede tener ventajas
>> para aplicaciones de negocio tales como eliminar la llamada "impedencia
>> objeto-relacional", en la cual un dato tiene que pasar por varias etapas
>> antes de llegar al GUI.
>
> Lo que hacemos nosotros es trabajar state-less/REST y combinar PgSQL y
> CouchDB de la siguiente forma: el path de escritura (POST, PUT,
> DELETE) llega al RDBMS y de allí triggers automáticamente serializan
> JSON que se distribuye en Couch. Nosotros separamos MVC de Catalyst un
> nivel más donde V realmente sigue siendo una capa de recursos JSON y
> luego el View como tal corre netamente en el cliente que puede ser un
> Browser (usando algo como JQuery + Jemplate) u otro tipo de clientes.
>

Admirable arquitectura.

>> En este link hay evidencia de este tipo de ahorro:
>> http://www.jpab.org/All/All/All.html. Claro que, este ahorro se da entre
>> varias razones por que el manejador se ejecuta embebido, en el mismo proceso
>> de la aplicación y por la inexistencia de la impedancia. Creo que la regla
>> en general es que tu "manejador de BD orientada a objetos se ejecute en la
>> misma VM" que tu aplicación, sea la plataforma que fuere (Java, Python,
>> .NET, Perl, etc)
>
> Si. Igual era Oracle con Forrms y todos sabemos como terminó eso. Yo
> creo que toda esa vaina es pura paja y uno tiene que tener control
> pleno de todas las capas para poder adaptar tu arquitectura y no
> casarte con el último FAD.
>

Correcto. Pero yo no desestimaría el hecho de que al menos
teóricamente almacenar el objeto sin pasar por un pipe o un socket
puede considerarse un "ahorro". Claro que sería algo muy parecido a
serializar directo a disco.

>> Por cierto, las BD no-sql como MongoDB, CouchDB, Riak, Cassandra, etc, se
>> aprovechan también de un mapeo mas directo al ser BD orientadas a documentos
>> o pares clave-valor, pero siguen teniendo la necesidad de utilizar
>> comunicación entre procesos.
>
> Para mí todo lo noSQL y "big data" no es más que un caché sofisticado.
> Yo las veo y las uso para distribuir objetos serializados y no
> "documentos". Nosotros, de hecho, usamos CouchDB como almacenaje y
> distribución de objetos serializados en JSON. Ejemplo: cuando si
> almacenamos una factura en PgSQL automáticamente creamos un objeto
> JSON que es la versión des-normalizada y se distribuye para la ruta
> GET. Si te pones a ver la mutabilidad de los registros de negocios es
> mínima y por ende casi todos los documentos y registros
> transaccionales de negocio no mutan y pueden vivir perfectamente fuera
> del RDBMS, pero como complemento a éste último, no como substituto.
> Más aún, típicamente hay entre 3 y 10 queries por cada insert/update.
> El truco es analizar la vigencia del dato (vigencia del caché) según
> el negocio en particular. Digamos, hay negocio que pueden tolerar que
> el nivel de inventario en consulta esté desfasado unos minutos e
> incluso horas, hay otros negocios en que no. Hay otros casos que es
> igual, por ejemplo una factura una vez impresa es inmutable por
> definición, por ende puede vivir por siempre en los caché.
>

Así es. Totalmente de acuerdo, y muy interesante por demás tu enfoque.

Tal como mencioné con el caso de serializar directo a disco. ;-)

>
> En fin, mi pregunta sobre Intersystems es que si no te huele que eso
> es algo como Pg + X behind the scenes??
>

Dado todo lo que me dices empiezo a ver lo que tu ves. Y lo que puedo
intuir es que la técnica empleada por el susodicho manejador
probablemente sea muy similar a la tuya. Sólo que lo vería al revés.
Es decir, el modelo le pegaría directo a la capa de persistencia de
objetos (con lo cual se eliminaría cualquier tipo de fricción y
"diferencial de impedancia". Luego un proceso independiente se
encargaría de hacer un ORM clásico a una RDBMS (probablemente libre
con licencia LGPL o BSD.... Postgres???) para todo el tema de poder
usar los venerables SQL.

Entonces, si pudieras poner por delante a CouchDB o MongoDB, réplicas,
y luego un demonio en perl que haga un ORM clásico, pudieras tumbar
cualquier amenaza de migrar a una BD privativa y desconocida.

Aun así, teniendo la arquitectura que mencionas no le veo ventaja a
cambiar a otro modelo.

> Saludos,
>
> --
> Alejandro
> _______________________________________________
> l-desarrollo mailing list
> l-desa...@velug.org.ve
> http://listas.velug.org.ve/mailman/listinfo/l-desarrollo

Saludos,

José Manuel Peña

[Alejandro Imass]

2012/11/18 José Manuel Peña <josema...@gmail.com>:

> El 18/11/2012, a las 00:50, Alejandro Imass <a...@p2ee.org> escribió:
>
>> 2012/11/17 José Manuel Peña P. <josema...@gmail.com>:
>>> Alejandro,
>>>

[...]

> Dado todo lo que me dices empiezo a ver lo que tu ves. Y lo que puedo
> intuir es que la técnica empleada por el susodicho manejador
> probablemente sea muy similar a la tuya. Sólo que lo vería al revés.
> Es decir, el modelo le pegaría directo a la capa de persistencia de
> objetos (con lo cual se eliminaría cualquier tipo de fricción y
> "diferencial de impedancia". Luego un proceso independiente se
> encargaría de hacer un ORM clásico a una RDBMS (probablemente libre
> con licencia LGPL o BSD.... Postgres???) para todo el tema de poder
> usar los venerables SQL.
>
> Entonces, si pudieras poner por delante a CouchDB o MongoDB, réplicas,
> y luego un demonio en perl que haga un ORM clásico, pudieras tumbar
> cualquier amenaza de migrar a una BD privativa y desconocida.
>

Puedo ver que ambos estamos plenamente de acuerdo a nivel conceptual.
Sería bueno comenzar un hilo comparando normalización vs. vertical
partitioning, vs. sharding vs. noSQL vs. OODB. Pero...

EMHO el volumen de datos moderno es tán grande y poco estructurado que
creo que el problema está a un nivel más alto que éste y por ende
pienso que todo eso ya estaba pensado en los diseños originales de la
Web y luego con la disertación REST de Roy Fielding. Es decir, yo creo
que la discusión hay que llevarla a diferentes niveles.

Por ejemplo, ve la respuesta de Francisco Obispo en L-Linux y verás
que hay aplicaciones que son como perfectas para MongoDB aunque yo no
termino de comprender exactamente las diferencias entre sharding vs.
horizontal partitioning vs. buen diseño de modelos de datos. Y de
paso, cómo se compara todo esto a data-marts y Business Intelligence.
De nuevo, todo depende del objetivo final: almacenamiento,
procesamiento, transacciones, consultas?

El tema es largo y complejo. Déjame ver sin en los próximos días creo
un(os) thread de discusión un poco más específicos... o si se te
ocurre algo, postealo tu.

Saludos,

--
Alejandro Imass

[Francisco Obispo]

Hola Alejandro,

On Nov 20, 2012, at 11:00 AM, Alejandro Imass <a...@p2ee.org> wrote:

Por ejemplo, ve la respuesta de Francisco Obispo en L-Linux y verás
que hay aplicaciones que son como perfectas para MongoDB aunque yo no
termino de comprender exactamente las diferencias entre sharding vs.
horizontal partitioning vs. buen diseño de modelos de datos.

La idea detrás de partintioning, es mantener los datos a un nivel manejable en la base de datos.

PgSQL al igual que muchos maneadores sufren de IndexBloat, cuando tienes escrituras/lecturas frecuentes. Si el indice es mas grande de lo que puedes almacenar en memoria, entonces las consultas terminan siendo no muy óptimas. Lo ideal es "picar" la tabla en tablas mas pequeñas, que sean manejables para que no imparte el desempeño de las consultas.

Imaginate una tabla con millones/billones de registros, si es muy grande, los indices van a ser enormes, no los vas a poder cargar en memoria, y como consecuencia vas a terminar usando mmap (contra el disco) para poder buscar el contenido deseado.

Ahora bien, si tienes ese problema, la idea es buscar segmentar la información usando los campos que formarían parte de la consulta, por ejemplo, si fuera un registro de visitas de un webserver, pudieras usar la combinación de año/semana o mes, para así tener tablas mas pequeñas manejables.

Usando la habilidad de PgSQL de herencia de tablas, puedes crear una tabla maestra y muchas tablas hijas asociadas a la padre. Cuando haces un query, el query-planner es capaz de ver el query y las restricciones y solo revisar los indices de la(s) tablas afectadas. Es _muy_ interesante.. te recomiendo que lo pruebes [1]

Esto todo funciona bien, sin embargo, tienes una sola instancia de PgSQL corriendo y manejando todos los datos, lo que está bien hasta cierto punto.

Sharding: por el otro lado es hacer algo muy similar a lo explicado arriba, pero las tablas residen en maneadores de bases de datos distintos, toda la magia ocurre con un 'ruteador' de datos que es capaz de ver el query, y enviarlo al o a los servidores que tienen la data. Hay soluciones /hacks para PgSQL, pero en este campo es donde bigTable, MongoDB, y otros son reyes.[2]

La idea detrás de sharding no es solo particionar los datos, si no tener mas unidades en paralelo atendiendo un problema. Imaginate que quisieras calcular el promedio de bytes por segundo entregados a clientes (promedios de 5 minutos, por hora, y por día), usando la data del webserver descrita arriba… Lógicamente para un conjunto de datos pequeños, puedes tranquilamente correrlo en SQL y el resultado es rápido, pero si tienes millones/billones de registros, ya el problema se hace menos trivial, además no querrás procesar la misma información todo el tiempo, pero tienes que ser capaz de tomar casos como: que pasa si un servidor se retrasa uno o  dos días en subir los datos a SQL? vas a tener que recalcular todo otra vez? ahí es donde herramientas como map/reduce son útiles, y mas aún, la habilidad de que esos promedios sean calculados todos en paralelo para cada clave del shard, y que todo sea agregado automáticamente al hacer una consulta al cluster. (parece magia).

Ahora imaginare que esos datos crecen de a millones por día, sería ideal tener la capacidad de agregar mas hardware para atender el problema y crecer horizontalmente.

Por otra parte, toma un tiempo sacarse el casette de SQL de la cabeza, hay que pensar en documentos, colecciones, etc. hay que pensar muy bien en las consultas y los índices, y el manejo de los datos de manera eficiente. Nosotros pasamos por varias iteraciones hasta conseguir un modelo que nos sirviera.

Los documentos en mongo son almacenados en BSON, que es un formato de JSON binario, las librerías de Mongo son muy completas, aunque no todo es color de rosa, es importante aprender a procesar las cosas como es debido para que funcione bien.

El modelo de Map/Reduce se basa en NodeJS, asi que será necesario aprender un poco de Javascript, toma un tiempo acostumbrarse al modelo, pero una vez funciona es bastante poderoso.

Si leyeron hasta este punto, significa que no se aburrieron, así que si quieren mas detalles, puedo con mucho gusto ofrecerlo.

[1] http://www.postgresql.org/docs/current/static/ddl-partitioning.html

[2] http://docs.mongodb.org/manual/core/sharding/

Y de
paso, cómo se compara todo esto a data-marts y Business Intelligence.
De nuevo, todo depende del objetivo final: almacenamiento,
procesamiento, transacciones, consultas?

Todo radica en:

1) Que información necesitas obtener?

2) Que datos necesitas para generarla ?

3) Cuales son los tiempos aceptables para retornar esa información?

4) Esta dispuesto el cliente a pagar lo que cuesta ?