Zope Object Database - ZODB

La Zope Object Database (ZODB) es una base de datos orientada a objetos para almacenar de forma transparente y persistente objetos en el lenguaje de programación Python. Se incluye como parte de Zope, un Servidor de aplicaciones Web, pero también puede ser utilizado independientemente de Zope.

Características

Las características de la ZODB se incluyen:

  • Transacciones.
  • Historial / deshacer.
  • Almacenamiento conectable de forma transparente.
  • Almacenamiento en caché.
  • Control de concurrencia multiversión (multiversion concurrency control - MVCC).
  • Escalabilidad a través de una red (usando ZEO).

Historia

  • Creado por Jim Fulton de Zope Corporation a finales de los años 90.
  • Inicio como un simple sistema de persistencia de Objetos (Persistent Object System - POS) durante el desarrollo de Principia (el cual posteriormente sería Zope).
  • ZODB 3 fue renombrada cuando un cambio significante de la arquitectura fue publicado.
  • ZODB 4 fue un proyecto de corta duración para volver a poner re-implementar todo el paquete de ZODB 3 usando 100% Python.

ZEO

ZEO (Zope Enterprise Objects), es una implementación de almacenamiento de ZODB que permite varios procesos de clientes a la persistencia de objetos en un único servidor ZEO. Esto permite la escalabilidad transparente, pero el servidor ZEO es todavía un punto único de fallo.

Almacenes de datos basado en conectores

  • FileStorage - Permite que un único proceso de Python para hablar con un archivo en el disco.
  • BlobStorage - Permite a los grandes datos binarios ser gestionado por la ZODB, pero separado de su habitual base de datos FileStorage, es decir Data.fs. Esto tiene varias ventajas, la más importante un archivo Data.fs mucho más pequeños y un mejor rendimiento tanto en CPU, así como de la memoria.
  • RelStorage - Permite el almacenamiento de respaldo persistencia para ser un RDBMS.
  • NetworkStorage (también conocido como ZEO) - Permite cargar varios procesos de Python y almacenar instancias persistentes al mismo tiempo.
  • DirectoryStorage - Cada dato persistente se almacena como un archivo separado en el sistema de archivos. Al igual que en FSFS en Subversion.
  • DemoStorage - Un fondo en memoria para el almacenamiento persistente. Proporcione un ejemplo de implementación de un almacenamiento completo sin distraer información acerca del almacenamiento, este tipo de almacenamiento es volátil lo cual es útil para dar demostraciones.
  • BDBStorage - que utiliza Berkeley DB back-end. Ahora abandonada.

Tecnologías de conmutación por error

  • Servicios de replicación de Zope (ZRS) Es un producto que elimina el punto único de fallo, proporcionando copia de seguridad en caliente de las escrituras y lecturas de balanceo de carga.
  • ZEORaid, es una solución de código abierto que proporciona un servidor proxy de red que distribuye el almacenamiento de objetos y la recuperación a través de una serie de servidores de red.
  • RelStorage, usa las tecnologías de RDBMS así de esta forma se evitas la necesidad de servidor ZEO.
  • NEO - Distribuido (tolerancia a fallos, equilibrio de carga) la aplicación de almacenamiento. No está listo para su uso en producción todavía (a partir de 01/2011).

Directorios de ZODB

En el directorio var/filestorage/ se encuentran los siguiente archivos:

  • Data.fs es la base de datos como tal.
  • Data.fs.lock es para señalar que Data.fs esta en uso.
  • Data.fs.index guarda una copia del indice.
  • Data.fs.tmp se usa para operaciones como pack.
los comentarios son proporcionados por Disqus

Editar este documento

El código fuente de este archivo esta hospedado en GitHub. Todos pueden actualizar y corregir errores en este documento con unos clic - sin necesidad de descargar.

  1. Vaya hacia el articulo Zope Object Database - ZODB en GitHub.
  2. Presione el botón Fork. Este creara su propia copia personal de la documentación.
  3. Edite los archivos usando el editor de texto de GitHub desde su navegador Web
  4. Rellene en la caja de texto Commit message al final de la pagina indicando por que usted realizo estos cambios. Presione el botón Propose file change próximo a ese cuando haya finalizado.
  5. Luego diríjase a la página Send a pull request (no será necesario rellenar ningún texto adicional). Sólo tiene que pulsar el botón Send pull request.
  6. Sus cambios serán consultados por un revisor dentro de la pestaña Pull requests del proyecto en Github.

Para mas información básica acerca de como actualizar este manual y referencia a sintaxis Sphinx, por favor consulte la guía Escribiendo y actualizando el manual.