我目前正在从事一个童话般的大型项目（活跃成员约为数百 K），并且非常倾向于 Plone 解决方案。
从非常有经验的 Plonistas（以及活跃的 stackoverflowers）那里得到了一些回复。对此，我真的非常感激。人们一直说 Plone 不能很好地扩展到那么大，大部分原因是因为 ZODB。
然后我想到了 ZODB 的内存后端。RAM现在真的很便宜！您只需约 3000 美元即可获得 128GB，是普通 300 美元 128GB SSD 的十倍，与约 300MB 的 SSD 相比，实现约 30GB 的 IO 带宽。
内存中后端 + Blob 用于二进制 + 10 秒磁盘日志记录用于备份 + 除了最后 10 秒之外的所有撤消都将是实例终止！他们应该抽 RDBMs 并提供完整的 ACID + Transaction + Object Mapping 与这样的沙发 */redis 等相比。
技术可行吗？有什么实施吗？是否值得实施（在您看来）？
RelStorage 有一个 memcache 选项，当您需要使用慢速数据库时，它会有所帮助，但实际上您可能应该将这种缓存留给您的操作系统，并确保您的数据库服务器有足够的 RAM。（如果您的 RAM 足够大，那么您的文件系统缓存应该已经存储了大部分数据。）
SSD 将显着降低随机访问尚未在文件系统缓存中的数据的最坏情况读取延迟。现在不使用它们似乎很愚蠢，特别是因为 Intel 330 SSD 非常便宜，并且有一个电容器，相当于一个电池支持的 raid 控制器（也使写入速度超快。）
一个全在 RAM 的解决方案永远不能被认为是 ACID，因为它不会是持久的。
正如我在您的另一篇文章的评论中提到的，这里的问题不是 ZODB，而是 Plone 同步使用单个竞争的 portal_catalog。
您可以将 portal_catalog 挂载到单独的挂载点并将其保存在内存中，而不是将整个 ZODB 保存在内存中。我已经见过这样的配置，它可以为大约 8k 用户使用标准硬件（2 台服务器 + 1 台 zeo 服务器）顺利运行。它可能足以满足您的需求，也许使用性能更高的硬件。