ZODB 膨胀一定是坏事吗？答案

【问题标题】：Is ZODB Bloat necessarily a bad thing?ZODB 膨胀一定是坏事吗？
【发布时间】：2013-09-14 13:06:50
【问题描述】：

我正在编写一个检索网页的软件，将有关它们的一些关键信息提取到一个对象中，然后将其写入 ZODB 数据库。我最终将大约 350,000 个这些对象写入我的数据库。

在我的代码运行一段时间后，每当我向数据库添加新对象时，它就会开始发布此消息...

UserWarning: The <class 'persistent.mapping.PersistentMapping'>
object you're saving is large. (26362014 bytes.)
Perhaps you're storing media which should be stored in blobs.

Perhaps you're using a non-scalable data structure, such as a
PersistentMapping or PersistentList.

Perhaps you're storing data in objects that aren't persistent at
all. In cases like that, the data is stored in the record of the
containing persistent object.

In any case, storing records this big is probably a bad idea.

所以我的问题首先是，错误消息所指的 26MB 是用于添加的单个对象还是整个数据库。这些对象中的每一个都应该很小，但消息会显示在每个添加的新对象上。

【问题讨论】：

标签： python database zodb

【解决方案1】：

26MB 是为整个 PersistentMapping 对象生成的“pickle”的大小。正如消息所说，PersistentMapping 不可扩展：如果您向其中添加一个键值对并提交事务，它将写出 26MB（加上您添加的单个新对的大小）再次。每次更改 PersistentMapping 实例并提交时，整个对象都会存储到磁盘（包括您之前添加的所有对象）。在一系列的添加和提交中，这会在您添加的项目数量中产生总数据库大小二次，并且还会遭受二次时间行为（您添加的每个新项目都比上一个花费更长的时间添加，因为每次提交也会写出所有以前添加的项目，而不仅仅是最后添加的项目。

查看文档以了解 BTree ZODB 支持的各种风格。这些是可扩展的、持久的键值映射，几乎可以肯定，您应该在此任务中使用这些映射。

请注意，ZODB 实现了多种BTree 以提高效率。最通用的是OOBTree，它允许键和值的通用对象。最具体的是IIBTree，它只允许 32 位整数作为键和值。这是一个教程：

http://pythonhosted.org/BTrees

【讨论】：

谢谢，但我仍然不清楚 Persistent 如何与 ZODB 一起工作。因此，对于我放入 ZODB 数据库的对象，如果它们继承自“持久”类，是否会阻止所有先前添加的对象再次存储？我将研究 BTree，但我仍在尝试理解 Persistence 的重要性。
你的问题与Persistent无关，它与PersistentMapping有关。您无法阻止PersistentMapping 始终被完整地读取和写入 - 这就是PersistentMapping 的工作原理。它仅适用于小型映射。您只是使用了不适当的数据结构。请改用 BTree。
我现在还有一些时间 ;-)，所以：如果您查看代码，您会发现 PersistentMapping 只是 Python 字典的包装器，继承自 Persistent 所以它也获得了所有持久性机制，最重要的是，它覆盖了所有 dict 的变异方法（__delitem__、__setitem__、clear、update、setdefault 和 popitem）来设置神奇的self._p_changed为真。这就是持久性机器如何知道你何时改变了PersistentMapping。哎呀！字数不足。但_p_changed 适用于整个 PersistentMapping。
这就是为什么每次都写出来，以及为什么你不能改变它。 BTree 是许多持久对象的（可能非常大）图。只有实际变化的部分需要存储。而这一切都是通过魔法为您完成的。