python 现实生活中的 ZODB
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/2388870/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
ZODB In Real Life
提问by Aiden Bell
Writing an app in Python, and been playing with various ORM setups and straight SQL. All of which are ugly as sin.
用 Python 编写一个应用程序，并一直在玩各种 ORM 设置和直接的 SQL。所有这些都像罪一样丑陋。
I have been looking at ZODB as an object store, and it looks a promising alternative... would you recommend it? What are your experiences, problems, and criticism, particularly regarding developer's perspectives, scalability, integrity, long-term maintenance and alternatives? Anyone start a project with it and ditch it? Why?
我一直将 ZODB 视为对象存储，它看起来是一个很有前途的替代方案……您会推荐它吗？您有哪些经验、问题和批评，特别是关于开发人员的观点、可扩展性、完整性、长期维护和替代方案？有人用它开始一个项目并放弃它吗？为什么？
Whilst the ideas behind ZODB, Pypersyst and others are interesting, there seems to be a lack of enthusiasm around for them :(
虽然 ZODB、Pypersyst 和其他人背后的想法很有趣，但似乎对他们缺乏热情:(
采纳答案by Chris McDonough
I've used ZODB for more than ten years now, in Zope and outside. It's great if your data is hierarchical. The largest data store a customer operates has maybe.. I dunno... 100GB in it? Something on that order of magnitude anyway.
我已经在 Zope 内外使用 ZODB 十多年了。如果您的数据是分层的，那就太好了。客户运营的最大数据存储可能有……我不知道……里面有 100GB？无论如何，这个数量级的东西。
Here is a performance comparison against Postgres.
If you're writing a WSGI web app, these packages may be useful:
如果您正在编写 WSGI Web 应用程序，这些包可能很有用：
回答by Tres Seaver
Compared to "any key-value store", the key features for ZODB would be automatic integration of attribute changes with real ACID transactions, and clean, "arbitrary" references to other persistent objects.
与“任何键值存储”相比，ZODB 的关键特性是将属性更改与真实 ACID 事务自动集成，以及对其他持久对象的干净、“任意”引用。
The ZODB is bigger than just the FileStorage used by default in Zope:
ZODB 比 Zope 中默认使用的 FileStorage 更大：
- The RelStorage backend lets you put your data in an RDBMS which can be backed up, replicated, etc. using standard tools.
- ZEO allows easy scaling of appservers and off-line jobs.
- The two-phase commit support allows coordinating transactions among multiple databases, including RDBMSes (assuming that they provide a TPC-aware layer).
- Easy hierarchy based on object attributes or containment: you don't need to write recursive self-joins to emulate it.
- Filesystem-based BLOB support makes serving large files trivial to implement.
- RelStorage 后端允许您将数据放入 RDBMS 中，该 RDBMS 可以使用标准工具进行备份、复制等。
- ZEO 允许轻松扩展应用程序服务器和离线作业。
- 两阶段提交支持允许在多个数据库之间协调事务，包括 RDBMS（假设它们提供 TPC 感知层）。
- 基于对象属性或包含的简单层次结构：您不需要编写递归自联接来模拟它。
- 基于文件系统的 BLOB 支持使得服务大文件变得很容易实现。
Overall, I'm very happy using ZODB for nearly any problem where the shape of the data is not obviously "square".
总的来说，我很高兴使用 ZODB 解决几乎所有数据形状不是明显“方形”的问题。
回答by Tres Seaver
I would recommend it.
我会推荐它。
I really don't have any criticisms. If it's an object store your looking for, this is the one to use. I've stored 2.5 million objects in it before and didn't feel a pinch.
我真的没有任何批评。如果它是您要查找的对象存储，则可以使用它。我之前已经在其中存储了 250 万个对象，并没有感到紧张。
回答by John La Rooy
ZODB has been used for plenty of large databases
ZODB 已用于大量大型数据库
Most ZODB usage is/was probably Zope users who migrated away if they migrate away from Zope
大多数 ZODB 使用情况可能是/曾经是 Zope 用户，如果他们从 Zope 迁移出去，他们可能会迁移出去
Performance is not so good as relatonal database+ORM especially if you have lots of writes.
性能不如关系数据库+ORM，特别是如果您有大量写入。
Long term maintenance is not so bad, you want to pack the database from time to time, but that can be done live.
长期维护也不是那么糟糕，你想不时地打包数据库，但这可以实时完成。
You have to use ZEO if you are going to use more than one process with your ZODB which is quite a lot slower than using ZODB directly
如果您要在 ZODB 中使用多个进程，则必须使用 ZEO，这比直接使用 ZODB 慢得多
I have no idea how ZODB performs on flash disks.
我不知道 ZODB 在闪存盘上的表现如何。
