A backend for ZODB that stores pickles in a relational database.

Navigation

Verified details

These details have been verified by PyPI
Maintainers
Avatar for hathawsh from gravatar.com hathawsh Avatar for J1m from gravatar.com J1m Avatar for jamadden from gravatar.com jamadden

Unverified details

These details have not been verified by PyPI
Project links
Meta
Classifiers
Report project as malware

Project description

RelStorage is a storage implementation for ZODB that stores pickles in a relational database (RDBMS). PostgreSQL 9.6 and above, MySQL 5.7.19 / 8.0, Oracle 10g and above, and SQLite 3.8.3 and above are currently supported. RelStorage replaced the PGStorage project.

Features

  • It is a drop-in replacement for FileStorage and ZEO, with several enhancements:

    • Supports undo, packing, and object history preservation just like FileStorage.

    • RelStorage can be configured not to keep object histories for reduced disk space usage and improved performance.

    • Multiple processes on a single machine can read and write a local ZODB database using SQLite without needing to start and manage another process (i.e., ZEO).

    • Blobs can be stored on a shared filesystem, or (recommended) in the relational database and only cached locally.

    • Multiple threads in the same process share a high-performance in-memory pickle cache to reduce the number of queries to the RDBMS. This is similar to ZEO, and the ZEO cache trace tools are supported.

    • The in-memory pickle cache can be saved to disk and read when a process starts up. This can dramatically speed up site warmup time by eliminating a flood of RDBMS queries. Unlike ZEO, this cache is automatically shared by all processes on the machine (no need to configure separate client identifiers.)

  • Ideal for large, high volume sites.

    • Multiple Python processes on multiple machines can read and write the same ZODB database concurrently. This is similar to ZEO, but RelStorage does not require ZEO.

    • Supports ZODB 5’s parallel commit feature: Database writers only block each other when they would conflict (except for a small window at the end of the twophase commit protocol when the transaction ID is allocated; that still requires a global database lock).

    • According to some tests, RelStorage handles concurrency better than the standard combination of ZEO and FileStorage.

    • Whereas FileStorage takes longer to start as the database grows due to an in-memory index of all objects, RelStorage starts quickly regardless of database size.

    • Capable of failover to replicated SQL databases.

  • Tested integration with gevent for PostgreSQL and MySQL.

  • There is a simple way (zodbconvert) to (incrementally) convert FileStorage to RelStorage and back again. You can also convert a RelStorage instance to a different relational database. This is a general tool that can be used to convert between any two ZODB storage implementations.

  • There is a simple way (zodbpack) to pack databases.

  • Supports zodburi .

  • Free, open source (ZPL 2.1)

Documentation

Documentation including installation instructions is hosted on readthedocs.

The complete changelog is also there.

https://readthedocs.org/projects/relstorage/badge/?version=latest

Development

RelStorage is hosted at GitHub:

https://github.com/zodb/relstorage

Continuous integration

A test suite is run for every push and pull request submitted. Travis CI is used to test on Linux, and AppVeyor runs the builds on Windows.

https://travis-ci.org/zodb/relstorage.svg?branch=master https://ci.appveyor.com/api/projects/status/pccddlgujdoqvl83?svg=true

Builds on Travis CI automatically submit updates to coveralls.io to monitor test coverage.

https://coveralls.io/repos/zodb/relstorage/badge.svg?branch=master&service=github

Supported by

AWS Cloud computing and Security Sponsor Datadog Monitoring Fastly CDN Google Download Analytics Pingdom Monitoring Sentry Error logging StatusPage Status page