Universidad del Valle de Guatemala Facultad de Ingeniera Departamento de Ingeniera en Ciencias de la Computacin CC3012 Modelado de Base de Datos Catedrtica:

: Lynette Garca

Tarea No.4

Zope Object Data Base (ZODB)

Trabajo presentado por: Luis Carlos Aldana Molina, 08261 Martn Luis H. Guzmn Colmenares, 08041 Byron Orlando Morales Sequn, 08414 Guatemala, 27 de agosto de 2011

Zope Object Data Base (ZODB) is licensed under Creative commons AttributionNoncommercial-Share Alike 3.0 Guatemala License

1/15

RESUMEN
El presente trabajo describe las principales caractersticas de Zope Object Database (ZODB), el cual pertenece al framwork para Python Zope. ZODB fue desarrollado como adicin al framework, pero se puede utilizar como aplicacin independiente. ZODB proporciona una base de datos orientada a objetos de alto grado de transaparencia para Python. Las aplicaciones pueden aprovechar las caractersticas de la base de datos orientada a o objetos con pocos cambios en la lgica de aplicacin. No es necesario consultar o actualizar objetos a travs de interacciones con la base de datos. Los objetos se obtienen y actualizan por medio de interaccin normal con objetos. Las transacciones se pueden deshacer de una manera que mantiene la integridad. El cach de un objeto provee alto rendimiento, uso eficiente de memoria y proteccin contra prdidas de memoria (memory leaks) debido a las referencias circulares.

2/15

NDICE DE CONTENIDOS
Pgina 1. Resumen ............................................................................................... ........................................................ 2 4 4 4 5 5 6 7 9 10 10 11 11 11 12 13 13 13 14 14 14 15 15

2. Introduccin ............................................................................................... 3. Zope Object Database (ZODB) a. Qu es ZODB? ..................................................................... ........................................................

b. Requerimientos del sistema ........................................................ c. Cmo funciona ZODB? e. Ventajas f. d. Interfaces de ZODB ..................................................................... .................................................................................. ........................................................ ........................................................ Desventajas ..................................................................................

4. Zope Enterprise Objects (ZEO) a. Cmo funciona ZEO? b. Requerimientos d. Probando ZEO a. Subtransacciones b. Deshacer cambios c. Versiones

..................................................................... ..................................................................... ..................................................................... .....................................................................

c. Para correr el servidor ZEO ........................................................ 5. Transacciones ...............................................................................................

..................................................................................

d. Bloqueos y resolucin de conflictos........................................... 6. Escalabilidad ............................................................................................... 7. Futuras caractersticas 9. Bibliografa ..................................................................... 8. Conclusiones ............................................................................................... ...............................................................................................

3/15

INTRODUCCIN
El mtodo ms comn para almacenar datos es el uso de sistemas de base de datos relacionales. Estos proporcionan un modelo sencillo para organizar los datos en tablas, y la mayora puede manejar grandes cantidades de datos de manera efectiva. Desafortunadamente, no todos los problemas se ajustan a una organizacin tabular simple. Por esto, una parte importante de la lgica de la aplicacin se dedica a leer los datos de las tablas y luego escribir los datos modificados de vuelta a las tablas. Los beneficios de la orientacin a objetos, tales como la encapsulacin y asociacin de la lgica con los datos, se pierden. Las bases de datos orientadas a objetos proveen una integracin ms estrecha entre el modelo de objetos de la aplicacin y el almacenamiento de datos. El propsito de este trabajo es presentar una base de datos orientada a objetos para Python, Zope Object Database (ZODB). Los objetivos del trabajo son describir el uso y beneficios de ZODB, proveer una visin arquitectnica de alto nivel, resaltar aspectos tcnicos interesantes y describir la evolucin reciente y futura.

Zope Object Database (ZODB) Qu es ZODB?

Zope Object Database (ZODB) es un sistema de persistencia para objetos de Python. Los lenguajes de programacin persistentes proveen facilidades para escribir automticamente los objetos en el disco y leerlos de nuevo cuando son requeridos por un programa en ejecucin. Al instalar ZODB, stas facilidades se agregan a Python, haciendo del mismo un lenguaje de programacin persistente. En el caso de Python, como en muchos otros lenguajes de programacin, ciertamente es posible construir un propio sistema de objetos persistentes. El modo usual de inicio es convertir los objetos en cadenas de bytes para poderlos almacenar en un medio de almacenamiento fsico. Algunos ejemplos de sto, en Python, podran ser los mdulos de gdbm o bsddb, que proveen formas para escribir y leer los objetos hacia disco. Es importante mencionar que stos mdulos son sencillos de utilizar y combinar con el mdulo de pickle1 para almacenar los objetos. Incluso estos mdulos vienen incluidos en las bibliotecas de Python.

1 No todos los objetos pueden ser persistidos. El mdulo de pickle provee una lista de los objetos que pueden ser persistidos.

4/15

Sin embargo, la desventaja es que el programador tiene que gestionar de forma explcita los objetos, desde la escritura de los objetos en disco cuando el objeto ya no es necesario, hasta la lectura del objeto en cuanto se necesita. El trabajo que hace ZODB es administrar los objetos, para facilitar este trabajo al programador, manteniendo los objetos en memoria RAM, escribindolos en disco cuando se modifican, y eliminndolos de la memoria cuando no se hayan utilizado en suficiente tiempo.

Requerimientos del sistema

El nico requerimiento de ZODB es tener instalado Python 2.3 o superior. La forma de instalar ZODB es tan fcil como descomprimir el archivo ejecutable2 y luego ejecutar: >> python setup.py install Sin embargo tambin es necesario, en el caso de instalarlo en Windows, tener instalado un compilador para lenguaje C, ya que ZODB utiliza varios mdulos de dicha lenguaje para funcionar. En el caso de usuarios UNIX no es necesario, pues estos mdulos vienen incluidos en el sistema operativo.

Cmo funciona ZODB?

ZODB es conceptualmente simple. Para que un objeto de Python pueda ser persistido utilizando ZODB debe cumplir con cualquiera de las siguientes opciones: 1. Ser un dato primitivo, como int, char, boolean, string, etc. 2. Ser un objeto que pertenece a una clase que hereda la subclase de Python persistent.Persistent. Una clase que herede de sta puede ser persistido sin ningn problema por ZODB. Las instancias de los objetos persistentes son tradas de un medio de almacenamiento permanente, como un archivo de disco, cuando el programa lo necesita, y se mantiene en memoria RAM. ZODB se encarga de reconocer las modificaciones a los objetos, de modo que cuando se modifica un objeto (por ejemplo con una instruccin como: obj.size = 1) se marca como sucio. Cuando el usuario lo requiere, un objeto sucio puede ser persistido (almacenado permanentemente en disco), a lo se que le conoce como committing a transaction. Las transacciones tambin pueden ser abortadas, con lo que los objetos sucios vuelven a su estado inicial, es decir, cuando comenz la transaccin u operacin.

Los ejecutables pueden ser encontrados en: http://old.zope.org/Products/ZODB3.3

5/15

El trmino transaccin tiene un sentido tcnico especfico en Ciencias de la Computacin. ste es uno de los trminos ms importantes en el rea. Usualmente es muy importante que el contenido de una base de datos no se dae por accidentes de software o hardware, por lo que la mayora del software de base de datos ofrece proteccin contra este tipo de corrupcin mediante el apoyo de cuatro propiedades: Atomicidad, Consistencia, Aislamiento y Durabilidad. Colectivamente se les conoce a stos como ACID, por sus siglas en ingls. Cuando un software posee estas cuatro propiedades se dice que el software realiza transacciones. Todas stas son provedas por ZODB, por lo que se puede decir que realiza transacciones. A continuacin se muestra qu significa cada propiedad: Atomicidad: significa que cualquier cambio a los datos hechos durante una transaccin, se realizan todo o nada. En otras palabras, o bien todos los cambios se aplica, o ninguno de ellos. La idea es que si se realizan varios cambios no se vaya a corromper o dejar incoherente el dato por realizar cambios parcialmente. Consistencia: significa que cada transaccin se ejecuta en un estado vlido de la base de datos, con el objetivo de no corromper los datos que ya se encuentren dentro de la misma. Aislamiento: significa que dos programas o subprocesos o hilos de ejecucin que se ejecuten en 2 transacciones distintos no puedan ver los cambios del otro hasta que la transaccin sea finalizada. sto para no dejar la base de datos en un estado modificado parcialmente por transacciones distintas. Durabilidad: significa que cada vez que una transaccin se haya completado, un error posterior no dae o cause la prdida de los datos cambiados en la transaccin.

Interfaces de ZODB
ZODB proporciona tres principales interfaces: Storage, DB y Connection. Las interfaces de DB y de Connection tienen implementaciones individuales, sin embargo la interfaz de Storage (almacenamiento) posee varias implementaciones diferentes. A continuacin se describe un poco cada interfaz: DB: La implementacin en una clase de esta interfaz permite la interaccin entre el medio de almacenamiento y la conexin. Se puede decir que se encuentra en la parte superior. Por proceso es necesario crear una nica instancia.

6/15

Connection: Una implementacin de esta interfaz permite la correcta escritura y lectura de los objetos dentro del medio de almacenamiento. Un programa con varios hilos de ejecucin debe abrir una conexin independiente para cada subproceso. Storage: La implementacin en una clase de esta interfaz permite manejar el almacenamiento y recuperacin de objetos de algn tipo de almacenamiento permanente. Como se mencion anteriormente, existen varias implementaciones de esta interfaz. Algunos ejemplos son: FileStorage: utiliza los arhivos de disco nomales. Es el predeterminado. Todo se guarda en un gran archivo Data.fs, el cual es seesncialmente un log de transacciones. DBDFullStorage: que utiliza datos del software Sleepycat Software's BerkeleyDB. DirectoryStorage: utiliza archivos y carpetas ordinarias para guardar revisiones. Guarda un archivo por revisin de un objeto. RelStorage: guarda pickles (coleccin de objetos convertidos en tablas utilizando una funcin llamada pickler fetch) en una base de datos relacional. Provee soporte para PostreSQL, MySQL y Oracle.

Ventajas
1. Eficiencia contra otros tipo de gestores

Se sabe que es complicado crear programas que creen objetos a partir de datos guardados en tablas (mediante mapeo objeto-relacional) y que tomen poco tiempo para realizar esta tarea. En cambio ZODB utiliza la serializacin de punteros, por lo que restablecer los objetos toma poco tiemo (lo cual es especialmente til para aplicacciones que realizan lecturas intensamente). 2. Podemos realizar un Undo

En la mayora de Sistemas Manejadores de Bases de Datos podemos cancelar una transaccin antes de que finalice, pero una vez realizada ya no se puede deshacer. Mientras que en ZODB se puede eliminar la ltima transaccin que se ha realizado sobre un grupo de datos determinado. Una opcin muy til, cuando tenemos los parmetros suficientes para determinar que la ltima transaccin no debi realizarse.

7/15

3.

Lo que hace una transaccin es explicito

En ZODB se escribe donde inicia y donde finaliza una transaccin dentro de nuestro propio cdigo. Por ello sabemos exactamente lo que cada transaccin hace. 4. Indexacin de textos

Existen diveros indices de textos en ZODB, claro estos indexadores trabajan nicamente en la capa de aplicacin. Esto implica que nuestra aplicacin sea la encargada de actualizar los ndices. 5. Realizar herencia es trivial

Aprovechando las ventajas de trabajar para un lenguaje orientado a objetos como Python, realizar modelado de herencia en varios niveles es sencillo. Se sigue la misma lnea que para el resto de objetos. Realizar esta tarea en gestores de bases de datos tradicionales es muy complicado, adems que repercute en el desempeo del mismo. 6. Escalable

Para cambios sensillos e incrementales, para nuestra aplicacin trabajar en red no implica muchos cambios a trabajar localmente. Unas simples configuraciones de clases y ZODB hace el resto. Con un sistema de puntos de montaje, hace simple y transparente este sistema. 7. Soporta Blobs (Binary Large Objects) para menejar archivos grandes (multimedia) En la actualidad se requiere del manejo de informacin multimedia, especialmente en entornos que giran a la Red. En ZODB el manejo de archivos binarios grandes es bastante simple ya que se ayuda de lo que Python ofrece. 8. Packing: quita revisiones viejas de los objetos

El desempeo de nuestras aplicaciones es importante para ZODB, por ello nos permite llevar un historial de las modificaciones de nuestros objetos. Lo cual podra llegar a ser un problema si se realizan demasiados, por ello tambin cuenta con un sistema de limpieza del historial.

8/15

Desventajas
1. La persistencia slo aparece en nuestra aplicacin.

Para que una aplicacin externa pueda acceder a la informacin de una aplicacin, se debe tener la estructura de la base de datos completa la cual est dentro de la aplicacin que la maneja. Lo que esto implica para el desempeo de las aplicaciones externas, es que para realizar la ms mnima tarea (como hacer una pequea consulta a un dato especifico de un objeto) es necesario tener cargada la aplicacin completa. 2. Manejo centralizado de la informacin

Dada la forma como ZODB maneja la informacin, se vuelve un cuello de botella. Dependemos completamente de ZODB para acceder a la informacin que hemos guardado en una base de datos. Lo cual no nos permite tener replicas de la informacin que manejamos. 3. Manejo pobre de la informacin que se recupera

Para acceder a un dato especifico de un objeto es necesario cargar el objeto completo en memoria. Adems no tenemos una forma certera de saber que otros objetos ha cargado ZODB. Por esto la organizacin de una base de datos puede tener muchas complicaciones. 4. Migrar toma demasiado tiempo

Organizar una base de datos creada en ZODB toma tiempo y es poco transparente. Mientras que migrar datos tiene muchos inconvenientes de tiempo y es casi imposible migrar la informacin de las transacciones realizadas sobre un objeto. 5. Problemas con deshacer (undo)

Si las transacciones realizan cambios sobre un mismo objeto, no es aconsejable intentar hacer un Undo sobre una transaccin que ha sucedido hace varias transacciones porque puede dejar inconsistente a la base de datos (una transaccin slo guarda informacin sobre los cambios que han ocurrido en un objeto y no se refleja en el resto de objetos relacionados a ellos). Esto conlleva que se puede llevar totalmente a una base de datos a un estado del pasado con la informacin de una transaccin.

9/15

6. Indexar no es transpartente Debido a que los indices se manejan dentro de la aplicacin, es necesario escribir como se actualizan los ndices; esto repercute en la transparencia del cdigo de las aplicaciones. En mucho casos este manejo manual puede ocacionar problemas con Undo.

Zope Enterprise Objects (ZEO) Cmo funciona ZEO?

ZODB, como se ha descrito hasta ahora, slo puede ser utilizado dentro de un nico proceso de Python (aunque podra ser en varios hilos de ejecucin). ZEO, Zope Enterprise Objects, se utiliza para extender la funcionalidad de ZODB y facilitar el acceso a los objetos por una red. Cabe destacar que el nombre Zope Enterprise Objects es un poco engaoso. ZEO se puede utilizar para almacenar objetos Python y acceder a ellos de forma distribuida, sin necesidad de utilizar Zope. La combinacin de ZEO y ZODB es esencialmente una base de datos que puede ser utilizada en red para el lenguaje de Python. ZEO se compone de cerca de 12,000 lneas de cdigo Python. El cdigo es relativamente pequeo, ya que contiene slo el cdigo de un servidor TCP/IP, e implementa un nuevo tipo de almacenamiento: ClientStorage. ste simplemente hace llamadas de procedimiento remoto al servidor, que luego pasa a una clase de almacenamiento regular, como por ejemplo FileStorage. Cualquier nmero de procesos puede crear una instancia de ClienStorage, as como cualquier nmero de hilos en cada proceso. En caso de corrupcin, ZEO enva un mensaje de invalidacin a todas las instancias relacionadas con ClientStorage en cada operacin de escritura o lectura. Funciona por medio de mensajes, en general. El mensaje de invalidacin contiene el identificador de objeto para cada objeto que haya sido modificado, dejando que las diferentes instancias de ClientStorage borren los datos antiguos de su respectiva memoria RAM. Cabe destacar que este diseo tiene algunas consecuencias a tener en cuenta. En primer lugar, mientras que ZEO no est ligado a Zope, de haber sido escrita para su uso con Zope, por lo que almacena cdigo del programa de la base de datos. Como resultado, la lectura a la base de datos se hace mucho ms frecuente de lo que se escribe, y por lo tanto, ZEO es ms adecuado para aplicaciones de lectura intensa. Si cada ClientStorage est escribiendo en la base de datos todo el tiempo, esto se traducir en una tormenta de mensajes que se envan e invalidan, por lo que puede tomar ms tiempo el procesamiento de las operaciones que las operaciones de los datos en s. 10/15

Por otro lado, para aplicaciones que tienen pocas instrucciones de escritura en comparacin con el nmero de lecturas, este mtodo puede ser de gran ayuda. La idea es lograr que el servidor ZEO haga relativamente poco trabajo. Si es posible lograr hacer que el servidor ZEO no vaya a ser contactado para cada peticin, por lo que su carga de trabajo podra continuar siendo manejable.

Requerimientos
El software: ZEO server software se encuentra includo en ZODB3. Por lo tanto es necesario nicamente contar con Python 2.3 o superior, al igual que ZODB.

Para correr el servidor ZEO

Para correr un servidor ZEO es necesario corrar el cdigo runzeo.py, que se encuentra dentro de la carpeta de ZEO en el directorio del instalador de ZODB. Se puede correr con el comando: python runzeo.py -h, para ver las diferentes opciones que posee. Un buen ejemplo de prueba puede ser: >> python ZEO/runzeo.py -a/tmp/zeosocket -f /tmp/test.fs Con lo que se consigue correr ZEO en un sistema UNIX utilizando la implementacin de Storage predeterminada: FileStorage

Probando ZEO
Una vez el servidor de ZEO se encuentre corriendo, puede ser utilizado por ZODB como si fuera un modo de almacenamiento ms, por lo que no es necesario codificar cdigo extra para hacer el uso remoto del servidor. La nica diferencia radica en que se debe crear una instancia de ClientStorage en lugar de FileStorage.

A continuacin se muestra un pequeo ejemplo para probar el funcionamiento adecuado de ZEO:

11/15

Imagen No.1 Ejemplo para funcionamiento de ZEO

Transacciones
ZODB provee soporte de transacciones en su ncleo. Las transacciones proveen control de concurrencia y atomicidad. Las transacciones se ejecutan como si tuvieran acceso exclusivo a los datos. No existe algo que prevenga el conflicto de dos peticiones simultneas. Una transaccin tendr xito o no, los datos no se dejan en un estado inconsistente si se produce un error. Los cambios realizados durante una transaccin no aparecen en la base de datos hasta que se invoca commit(), mtodo del objeto actual de Transaction. Si se utiliza el hilo predeterminado del administrador de transacciones, es suficiente ejecutar: >> transaction.commit() De manera similar, las transacciones se pueden abortar explcitamente invocando abort(). transaction.abort() Si se produce un error y falla el commit, todos los commit posteriores producirn un error. Se debe iniciar explcitamente una nueva transaccin, ya sea abortando la anterior o utilizando begin().

12/15

Subtransacciones
Subtransacciones pueden ser creadas dentro de una transaccin. Cada una puede hacer commit y abort individualmente. Los cambios dentro de una subtransaccin hacen un verdadero commit hasta que la transaccin que la contiene hace commit. Una subtransaccin nueva inicia automticamente al terminar la anterior. >> transaction.commit(True) >> transaction.abort(True)

Deshacer cambios
Algunos tipos de almacenamiento soportan deshacer cambios aun despus de un commit. Invocando undoLog(start, end [, func]), retorna el log de las transacciones pasadas entre los tiempos start y end, medidos en segundos. Si est presente, func trabaja como un filtro de las transacciones a retornar. Para deshacer los cambios de una transaccin se invoca DB.undo(id), siendo el parmetro el identificador de la transaccin a deshacer. La transaccin no se puede deshacer si transacciones posteriores modificaron los objetos que afect la transaccin a deshacer. Para guardar los cambios se tiene que hacer commit a la transaccin que deshizo los cambios.

Versiones
Al igual que muchas subtransacciones se contienen en una transaccin, muchas transacciones se contienen dentro de una transaccin larga, llamada versin. Dentro de una versin, muchas transacciones pueden ser creadas, hacer commit y abort; pero los cambios no son visibles para otras conexiones a la base de datos. Una versin se puede seleccionar al crear la conexin, enviando como parmetro el nombre de la versin: >> DB.open([*version*]) Para hacer visibles los cambios realizados en una versin se utiliza: >> DB.commitVersion() >> DB.abortVersion() ZODB no hace ningn intento para conciliar los cambios entre diferentes versiones. La primera versin que modifique un objeto va a obtener un bloqueo sobre ese objeto. Cualquier otra versin no podr modificar ese objeto. 13/15

Bloqueos y resolucin de conflictos

ZODB utiliza un protocolo optimista basado en timestamps. Cambios a copias individuales de objetos se realizan de forma independiente, por lo que objetos individuales no necesitan ser bloqueados. Los cambios se sincronizan cuando las transacciones son confirmadas. Slo una transaccin tiene permitido hacer commit a un almacenamiento a la vez. Si dos hilos modifican el mismo objeto en mltiples conexiones, un hilo est garantizado para hacer commit primero. Cuando el segundo hilo hace commit, se lanza una excepcin ConflictError. La aplicacin debe detectar el conflicto y volver a ejecutar las operaciones. Cuando la transaccin se vuelve a ejecutar, los estados de los objetos afectados reflejan los cambios hechos por la transaccin anterior.

Escalabilidad
Scalability Python est limitado a un solo CPU por el Global Interpreter Lock. ZEO permite ejecutar mltiples aplicaciones de servidor Zope compartiendo una sola base de datos. Se recomienda ejecutar un cliente Zope por cada procesador en el servidor.

Futuras caractersticas
Opciones de Almacenamiento: se desea aumentar los almacenamientos existentes, guardando data comprimida o que reducen espacio cuando registros actualizados son idnticos a registros existentes. Una herramienta para copiar datos entre almacenamientos sin recurrir a exportar e importar objetos. Optimizacin: partes de la base de datos sern re implementadas en C para proporcionar un mayor rendimiento o reducir uso de memoria. Bloqueos: protocolos de gestin de contenidos, como WebDAV, requieren la capacidad de bloquear objetos para su actualizacin. Probablemente se crearn versiones asociadas a los bloqueos y estas se crearn para los objetos afectados. Lenguaje de consulta: Python provee el lenguaje de consulta para ZODB. Es deseable que provea un lenguaje de consulta estndar como el Object Query Language (OQL).

14/15

CONCLUSIONES
ZODB es una simple y transparente base de datos orientada a objetos para Python. ZODB es un componente de libre disponibilidad del servidor de aplicaciones Zope. ZODB ofrece caractersticas avanzadas que permiten desarrollar simples pero poderosos programas de Python. Las consultas se hacen por interaccin con objetos, no con la base de datos. Las transacciones cumplen las cuatro propiedades ACID.

BIBLIOGRAFA
McDonoug, C. ZODB Tips and Tricks. 2005, Plone Symposium. http://www.plope.com/static/presentations/zodb.pdf ZODB programming guide. http://www.zodb.org/documentation/guide/index.html Rowe, Laurence. An Overview of the ZODB. http://www.zodb.org/documentation/articles/ZODB-overview.html Rowe, Laurence. Transactions in ZODB. http://www.zodb.org/documentation/guide/transactions.html Rowe, Laurence. Comparison to other database types. http://www.zodb.org/documentation/articles/ZODB-overview.html#comparison-toother-database-types Fulton, Jim. Introduction to the Zion Object Database. http://www.python.org/workshops/2000-01/proceedings/papers/fulton/zodb3.html Winkler, P. To ZODB Or Not to ZODB. 2009. http://www.coactivate.org/projects/toppengineering/blog/2009/03/20/to-zodb-or-not-to-zodb

15/15