From de1f24ca0eb6ae250d16d91d5d6a13c60238a6f3 Mon Sep 17 00:00:00 2001 From: Jim Fulton Date: Tue, 14 Nov 2017 13:51:30 -0700 Subject: [PATCH] Update the front page to be a little less negative. (#186) Especially with regard to write capacity and search. This hasn't been updated in a while and I feel that it is out of date. I feel that this could use more work, but I'm anxious to do an incremental improvement given the screencast I just released. :) --- doc/index.rst | 63 +++++++++++++++++++++++++++------------------------ 1 file changed, 34 insertions(+), 29 deletions(-) diff --git a/doc/index.rst b/doc/index.rst index ef59789f1..8bb6f7539 100644 --- a/doc/index.rst +++ b/doc/index.rst @@ -14,6 +14,9 @@ Because ZODB is an object database: - almost no seam between code and database. +- Relationships between objects are handled very naturally, supporting + complex object graphs without joins. + Check out the :doc:`tutorial`! ZODB runs on Python 2.7 or Python 3.4 and above. It also runs on PyPy. @@ -21,7 +24,7 @@ ZODB runs on Python 2.7 or Python 3.4 and above. It also runs on PyPy. Transactions ============ -Make programs easier to reason about. +Transactions make programs easier to reason about. Transactions are atomic Changes made in a transaction are either saved in their entirety or @@ -66,12 +69,6 @@ ZODB transaction support: Other notable ZODB features =========================== -Pluggable layered storage - ZODB has a pluggable storage architecture. This allows a variety of - storage schemes including memory-based, file-based and distributed - (client-server) storage. Through storage layering, storage - components provide compression, encryption, replication and more. - Database caching with invalidation Every database connection has a cache that is a consistent partial database replica. When accessing database objects, data already in the cache @@ -80,36 +77,43 @@ Database caching with invalidation to be invalidated. The next time invalidated objects are accessed they'll be loaded from the database. - This makes caching extremely efficient, but provides some limit to - the number of clients. The server has to send an invalidation - message to each client for each write. + Applications don't have to invalidate cache entries. The database + invalidates cache entries automatically. + +Pluggable layered storage + ZODB has a pluggable storage architecture. This allows a variety of + storage schemes including memory-based, file-based and distributed + (client-server) storage. Through storage layering, storage + components provide compression, encryption, replication and more. Easy testing + Because application code rarely has database logic, it can + usually be unit tested without a database. + ZODB provides in-memory storage implementations as well as copy-on-write layered "demo storage" implementations that make testing database-related code very easy. +Garbage collection + Removal of unused objects is automatic, so application developers + don't have to worry about referential integrity. + +Binary large objects, Blobs + ZODB blobs are database-managed files. This can be especially + useful when serving media. If you use AWS, there's a Blob + implementation that stores blobs in S3 and caches them on disk. + Time travel ZODB storages typically add new records on write and remove old records on "pack" operations. This allows limited time travel, back to the last pack time. This can be very useful for forensic analysis. -Binary large objects, Blobs - Many databases have these, but so does ZODB. - - In applications, Blobs are files, so they can be treated as files in - many ways. This can be especially useful when serving media. If you - use AWS, there's a Blob implementation that stores blobs in S3 and - caches them on disk. - When should you use ZODB? ========================= You want to focus on your application without writing a lot of database code. - Even if find you need to incorporate or switch to another database - later, you can use ZODB in the early part of your project to make - initial discovery and learning much quicker. + ZODB provides highly transparent persistence. Your application has complex relationships and data structures. In relational databases you have to join tables to model complex @@ -155,21 +159,22 @@ Need to test logic that uses your database. When should you *not* use ZODB? =============================== -- Search is a dominant data access path +- You have very high write volume. -- You have high write volume + ZODB can commit thousands of transactions per second with suitable + storage configuration and without conflicting changes. -- Caching is unlikely to benefit you - - This can be the case when write volume is high, or when you tend to - access small amounts of data from a working set way too large to fit in - memory and when there's no good mechanism for dividing the working - set across application servers. + Internal search indexes can lead to lots of conflicts, and can + therefore limit write capacity. If you need high write volume and + search beyond mapping access, consider using external indexes. - You need to use non-Python tools to access your database. especially tools designed to work with relational databases +Newt DB addresses these issues to a significant degree. See +http://newtdb.org. + How does ZODB scale? ====================