Look, ma! No database!

Gracias al ALT.NET Café del sábado pasado (anunciado como La inmortalidad de la medusa) se pudieron discutir varios temas, desde arquitectura de software, capas, niveles, patrones, etc. Seguramente, en estos días la gente de la comunidad publicará la grabación de ese evento.

Un tema que mencioné fue resumido en una frase mía: “En mundo perfecto no tendríamos base de datos”.

Hoy, recibo por Twitter, este comentarion de @chamix:

Bien, esto me da la excusa para comentar esa frase mía acá en mi blog… ;-)

La frase, claro, es utópica. Hoy vivimos con bases de datos relacionales (les recuerdo que hubo un tiempo donde también habían bases de datos jerárquicas y en red), y no podemos ignorarlase. Desde hace como veinte años, se vienen asomando las bases de objetos, pero parece que aún no despegaron.

Pero ¿a qué viene esa frase mía? Es una elaboración otra que mencioné en algunas charlas y alguna VAN: la base de datos está por si se corta la luz o se acaba la memoria. En un mundo ideal, podríamos manejar todo el estado nuestra aplicación en otro medio, notablemente la memoria.

No es una idea nueva: basta recordar que desde los 70 del siglo pasado, ésa ha sido la aproximación que adoptaron las implementaciones de Smalltalk: objetos con estado y conducta en memoria, y su copia en vivo a una imagen en disco. Yo quisiera recordar algo diferente que mencioné en la VAN NoSQL sobre el sistema Pick: todo, los registros de un proceso, la memoria de trabajo, los archivos, los datos, todo estaba en sectores, que ya podían estar en la memoria activa como en disco.

Entonces, volviendo al tema: si no hubiera cortes de luz ni faltara memoria, cualquier sistema de los que estamos trabajando, conocemos, chico, mediano o grande, podría tener todo el estado en memoria: si vamos a algo más concreto, como un modelo de dominio, las instancias de las distintas entidades, tranquilamente residirían en memoria. Mi frase, lo que trata de hacer, es llamar la atención sobre esa situación. A veces, usamos una herramienta (la base de datos), pero no recordamos que:

- tiene su historia (de dónde provino, a qué problemas le dió solución en su tiempo, y ahora)

- está entre nosotros, pero bien podríamos plantear no usarla (el movimiento NoSql en parte está impulsado por esto).

Para los que están en .NET: vean que tener todo en memoria, implicaría que podríamos usar el mejor provider de LINQ: el inicial, el nativo, el que opera sobre los objetos mismos, más que el que tiene un QueryProvider que traduce la recuperación (predicados para el where, proyecciones para el select) a comandos SQL. Al eliminar base de datos, y trabajar directamente con objetos, el LINQ que usaríamos, simplemente, sobre objetos.

(Incidentalmente, vean que esto de LINQ, ya estaba presente, de alguna manera, en Smalltalk, con el mensaje select: sobre colecciones; mencioné el tema en el ALT.NET Café).

De nuevo: la frase intenta llamar la atención, a cómo sería nuestro trabajo si cambiara un presupuesto tan pervasivo: tenemos que usar una base de datos. El ejercicio mental de cambiar uno de los pilares de nuestro trabajo diario, nos muestra más claro, para qué sirve ese pilar, y en qué vericuetos tecnológicos y de diseño se introduce, sin que tal vez estamos advertidos. (Si se me permite, sacar un pilar e introducir otro, es como jugar con la geometría euclidiana, sacar el quinto postulado (el de las paralelas) y poner otro en su lugar, para ver qué cambia; o en física, tratar de pensar cómo cambiaría todo si el espacio tuviera dos dimensiones o cuatro).

¿En qué brillan las bases de datos relacionales? Una: en el manejo de conjuntos de datos. Nada procedural o de objetos mejora un simple

update articulos set precio = precio* 1.10

(lo único que lo mejoraría sería usar algo como LINQ sobre objetos en memoria; usar ese mismo LINQ sobre objetos que se tiene que reificar de la base y volver a ella, sería bailar la conga comparado con lo de arriba). Como siempre, todo tema de optimización hay que medirlo. Pero creo que todos tenemos ejemplos de sistemas de la vida real, donde llega el tiempo de ajustar el acceso a datos para algunas operaciones (no se me dió que hubiera que actuar TODAS las operaciones: de ahí la importancia de mejorar lo que se midió y comprobó que, dadas las necesidades de nuestra aplicación, debe ser mejorado).

El otro punto donde brillan las bases de datos (relacionales o no) es en el manejo de la concurrencia: noten que la solución de este problema no se dió directamente con lockeos, sino con transacciones (que internamente se resuelven con lockeos y otros algoritmos). Para no obligar al programador a usar lockeos para resolver concurrencia (tema difícil y delicado de implementar), los manejadores de base de datos nos dan transacciones.

Mientras que el manejo de conjuntos podría ser posible con todo en memoria, el manejo de la concurrencia con todo en memoria, es más difícil de resolver. Dos grandes opciones:

- Las operaciones sobre el dominio son serializadas (entran de a una, lo vi alguna vez implementado en prevlayer y otros)

- Usar Software Transactional Memory (http://delicious.com/ajlopez/stm).

El primer punto no resuelve un tema: si durante un proceso de negocios, modificamos un objeto, y al tratar de seguir con la operación, algo nos lo impide (no hay stock para el pedido que nos hacen, etc…), no podemos dejar los objetos así como así: tenemos que volver a su estado antes del inicio de ese proceso. Notemos que los ORM en general, no se han decantado por manejar esto, se lo delegan a la base de datos: rollback en la base, y los objetos cargados para esa sesión, proceso de negocios, se descartan. Ante un nuevo pedido/sesión, se reifican los objetos desde la base de datos.

Otro punto: vean cómo la gente de Smalltalk, cuando se enfrentó a la concurrencia y varios usuarios, adoptó el camino de objetos en base de objetos como GemStone (ahora en proceso de desmantelamiento, creo, por lo menos la parte Smalltalk pura, al ser comprada por Oracle por sus productos Java y distribuidos).

Otro punto: noten cómo la gente de Sun lo embarró todo, tratando de tener un dominio como si fuera en memoria, con las especificacones EJB 1.x, 2.x (de hecho, esas especificaciones no requerían tener una base de datos relacional, aunque la mayoría de los proveedores de servidores EJB tomó ese camino; la gente de Gemstone adaptó su producto Smalltalk para que sirva en el mundo Java/EJB).

En fin, espero que las frases del comienzo del posts, exageradas, hayan podido dar alguna luz sobre temas, problemas y soluciones que tenemos en el día a día, en el armado de sistemas.

Nos leemos!

Angel “Java” Lopez
http://www.ajlopez.com
http://twitter.com/ajlopez

This entry was posted in 10790, 1389, 1390, 3463. Bookmark the permalink.

One Response to Look, ma! No database!

  1. Osorio says:

    ¡Claro como el agua! Adhiero sin reparos.
    Mi primera experiencia de programación fue con Erlang, un lenguaje de programación orientado a la concurrencia (Concurrency Oriented Programming) y cuyo énfasis es la confiabilidad. Se trata de un lenguaje funcional.
    El modelo de memoria está basado en “tail-call optimization” de unidades con estado llamadas “procesos”. Estos procesos no guardan información de estado compartida, comunicándose únicamente mediante mensajes. (Tal como describes, es como “LINQ entre objetos en memoria”.)
    Con esto en mente, si un proceso es modificado y algo falla, se restituye a su estado previo (parecido a la destrucción y vuelta a crear del objeto, pero en memoria.)
    Estas características permiten actualizaciones en caliente de la aplicación, cosa que no se ve en los ambientes OOP.
    Usando metáforas con ligereza: todo esto convertiría a la DB en un almacen de comprobantes de transacción (una especie de contabilidad de la aplicación).

    Gracias por manifestar esa utopía.

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>