Nada se pierde, todo se complica: Algunas simples reflexiones sobre base de datos y aplicaciones

Desde hace un tiempo, vengo leyendo con interés los artículos que se escriben sobre NoSQL, que en general son sobre bases de datos que almacenan los datos en esquemas no relacionales. Hay varias bases de datos de este tipo (SimpleDB,Project Voldemort, Cassandra, Neo4j y muchas mas). Algunas de éstas bases de datos son ideales para almacenar campos blobs, cosa que muchísimas aplicaciones que desarrollamos con Genexus tienen que hacer hoy.


También hay otra tendencia interesante en las bases de datos que es la de almacenar los datos por columnas, en vez de por filas. La que mas he mirado de esas bases de datos es Vertica y parece estar buena.


Que ventaja tiene guardar los datos por columnas en vez de por filas?. Estas DBMS son muy rápidas para consultas de sumarización de datos, del tipo de consultas que se realizan en la data warehouses.


Otra cosa que me ha tenido meditando son que las aplicaciones que necesitan guardar historia (o versiones de los datos) y también las aplicaciones que son orientadas a tiempo [1]. Estos dos temas están bastante relacionados y por suerte están apareciendo herramientas que ya las soportan.


Las bases de datos que guardan la historia de tus datos, permiten hacer aplicaciones que nunca actualizan datos, sino que cualquier actualización se transforma en un insert en la base de datos, posibilitando tener muy buenas performance (para aplicaciones especificas). Un ejemplo de esta base de datos es RethinkDB.


Otro tema que cada vez mas tienen que tener las aplicaciones modernas es la posibilidad de search "tipo google" y aun las bases de datos no lo resuelven correctamente. Un ejemplo de herramienta que hace esto es Lucene


En la situación actual se plantean como antagonistas estas opciones y a mi me parecen complementarias. Mi opinión importa poco, pero son los clientes los que cada vez piden mas que las cosas como :
  • Quiero buscar en todos los datos de la aplicacion una palabra determinada
  • Quiero que mi consulta de resumen de los ultimos 23 años se resuelva en menos de 10 segundos
  • La aplicacion debe poder imprimir el documento emitido hace 5 años exactamente igual que el original.
  • Se necesita adjuntar cualquier documento a la entidad X y luego recuperarlo, verlo, etc.
Seria muy bueno poder tener en mi base de datos, un conjunto de tablas que se guarden orientados a filas, y otros que se guarden orientados a columnas (los acumulados).


También seria bueno poder indicar (declarar!) si quiero poder mantener la historia de determinada entidad de mi base de datos y que automáticamente se guarde dicha historia y ademas pueda consultar su estado en diferentes momentos del tiempo.


Lo que a mi me gustaría seria que los repositorios de datos (base de datos + lo que se necesite) resolvieran todos estos problemas y que tuviéramos un mensaje unificado para consultarlos (SQL + lo que se necesite). Por un tiempo creo que las aplicaciones van a tener que lidiar con todas estas complejidades y vamos a tener que continuar programando en varios frentes.

UPDATE: Un articulo interesante que habla sobre el tema de bases NoSQL y tiene links interesantes: The end of SQL and relational databases?.

[1] Con respecto al manejo de tiempo en las base de datos con SQL, hay un libro PDF interesante gratis aqui.

Comentarios

  1. Enrique, coincido con tus reflexiones sobre este tema. De hecho estamos trabajando en algo que llamamos Permatron (http://wiki.gxtechnical.com/commwiki/servlet/hwiki?Category:Permatron,) para experimentar como podriamos tener algunas de las facilidadesque tu planteas en las aplicaciones GX de la forma mas indolora posible.

    Nicolas Jodal

    ResponderBorrar
  2. Te recomiendo investigar GemStone/S que una base de datos orientada a objetos (gemstone.com). No para comprarlo o usarlo, sino como una fuente de información. Podes hacer todo lo que decís aquí, dependiendo de la configuración que uses. Es decir, para búsquedas rápidas si lo necesitas podes aumentar el cache de GemStone/S que tiene un limite de 32.768 GB. O sea, podes tener toda tu aplicación en memoria, esto para la versión 64 bits. El limite físico es 8.192 TeraBytes, de estos 8.192 TeraBytes, podes tener 32.768 GB en cache. Cuando cambias la definicion de una clase podes migrar y hacer transformaciones para actualizar los datos, pero los objetos "viejos" siguen en la base por si queres volver atras.
    Saludos cordiales, Bruno
    PD: perdón por siempre inclinar la balanza hacia Smalltalk, se que estas hablando de SQL.

    ResponderBorrar
  3. Nicolas:
    Conozco el Permatron y lo he mirado con cariño. Parte de la solución de las inquietudes vienen por ese lado. Es un buen banco de pruebas.

    Creo que cuando se pueda almacenar la estructura del permatron en un banco de datos especializado, puede tener mejor performance.

    ResponderBorrar
  4. Bruno:

    Lo idea de hacer publico lo que estoy pensando, es justamente para poder compartir y recibir diferenes puntos de vista, que ayudan mucho a encontrar mejores ideas.

    No conozco GemStone/S. La posibilidad de base de datos (o parte de ella) en memoria, es otro de los puntos que me gustaria contar, pero no lo puse para no hacer demasiado pesado el post.

    Voy a tratar de mirar GemStone, para tratar de sacar algunas buenas ideas.

    Gracias

    ResponderBorrar
  5. Enrique:
    Te paso un link de GemStone/S que esta en español:
    http://smalltalkuy.wordpress.com/2009/10/19/gemstones-el-oracle-de-las-oodbms/

    De la arquitectura se pueden sacar muy buenas ideas.

    Este otro link tiene mucha info pero esta en ingles:
    http://gemstonesoup.wordpress.com/gemstone-101/

    Saludos,
    Bruno

    ResponderBorrar

Publicar un comentario

1) Lee el post
2) Poné tu opinión sobre el mismo.
Todos los comentarios serán leidos y la mayoría son publicados.

Entradas más populares de este blog

Aplicación monolítica o distribuida?

La nefasta influencia del golero de Cacho Bochinche en el fútbol uruguayo

Funcionalidades de GeneXus que vale la pena conocer: DATE Constants.