比较python中的持久存储解决方案答案

【问题标题】：Comparing persistent storage solutions in python比较python中的持久存储解决方案
【发布时间】：2009-08-05 20:37:18
【问题描述】：

我正在开始一个新的科学项目，其中包含大量数据（数百万个条目），我想以一种易于访问的格式存储。我遇到了许多不同的潜在选择，但我不确定如何从中挑选。我的数据可能只是存储为字典，或者可能是字典字典。一些潜在的考虑因素：

速度。每次启动新脚本时，我都无法从磁盘上加载所有数据，我希望尽可能快速地访问随机条目。
易于使用。这是蟒蛇。存储应该感觉像 python。
稳定性/成熟度。我想要目前支持的东西，虽然效果很好但仍在开发中的东西会很好。
易于安装。我的系统管理员应该能够在我们的集群上运行它。

我不太关心存储的大小，但如果一个选项在这方面真的很糟糕，这可能是一个考虑因素。另外，如果重要的话，我很可能会创建一次数据库，然后只读取它。

我已经开始研究的一些潜在选项（请参阅this 帖子）：

有什么建议可以更好地满足我的目的吗？有更好的想法吗？其中一些有后端；关于哪种文件系统后端最好的建议？

【问题讨论】：

感谢您的回答。在查看了已经提到的各种选项后，我正在更彻底地研究 sqlalchemy 选项。
对于将来看到这个的任何人，我决定使用东京内阁键值存储的 pytc 绑定，因为这提供了对原始数据的最快访问。对于处理过的数据，我可能会使用 SQLAlchemy，但它在速度上无法触及 pytc 和 pymongo 之类的键值存储。
shove 规则它们，它有几乎所有的后端，在我的快速测试中，我用 leveldb 得到了更好的结果

标签： python orm persistence

【解决方案1】：

可能想试一试mongodb - PyMongo 库可与字典配合使用并支持大多数 Python 类型。易于安装，非常高效 + 可扩展。 MongoDB（和 PyMongo）也被 in production 用于一些大牌。

【讨论】：

【解决方案2】：

一个关系型数据库。

没有什么比在众所周知的 RDBMS 上使用表更可靠的了。 Postgresql 浮现在脑海中。

这会自动为您提供一些未来的选择，例如集群。此外，您自动拥有许多工具来管理您的数据库，并且您可以在几乎任何语言编写的其他软件中使用它。

真的很快。

在“感觉像 python”这一点上，我可能会补充一点，您可以使用 ORM。一个强名称是sqlalchemy。也许使用elixir "extension"。

使用 sqlalchemy，您可以让您的用户/系统管理员选择他想要使用的数据库后端。也许他们已经安装了MySql - 没问题。

RDBMS 仍然是数据存储的最佳选择。

【讨论】：

好的，如果我往这个方向走应该使用哪个界面？
界面，和GUI一样？还是在 API - 应用程序程序员接口中？
一个很好的数据库 API 是 sqlalchemy - 我已经更新了答案以说一些关于它的内容并添加了指向该网站的链接。如果您需要更多信息，请告诉我。
酷，我会调查的。 Elixir 看起来很有趣。
另外，使用 RDBMS 可以让您处理诸如 JOINS 和聚合函数之类的事情。

【解决方案3】：

我正在从事这样一个项目，我正在使用SQLite。

SQLite 将所有内容存储在一个文件中，并且是Python's standard library 的一部分。因此，安装和配置几乎是免费的（易于安装）。

您可以使用小型 Python 脚本或通过各种工具轻松管理数据库文件。还有一个Firefox plugin（易于安装/易于使用）。

我发现使用 SQL 过滤/排序/操作/...数据非常方便。虽然，我不是 SQL 专家。（易用性）

我不确定 SQLite 是否是这项工作的最快数据库系统，它缺少一些您可能需要的功能，例如存储过程。

无论如何，SQLite 对我有用。

【讨论】：

【解决方案4】：

如果您真的只需要类似字典的存储，一些新的键/值或列存储（如 Cassandra 或 MongoDB）可能会提供比使用关系数据库更快的速度。当然，如果您决定使用 RDBMS，SQLAlchemy 就是您要走的路（免责声明：我是它的创建者），但是您想要的功能列表似乎倾向于“我只想要一个感觉像 Python 的字典”——如果你对关系查询或强 ACIDity 不感兴趣，RDBMS 的这些方面可能会感觉很麻烦。

【讨论】：

感谢您的回复——我想我会以此作为学习经验，看看 RDBMS 是否真的适合未来的项目。

【解决方案5】：

Sqlite -- 自带 python，速度快，应用广泛，易于维护

【讨论】：

【解决方案6】：

如果您只需要简单（类似dict）的访问机制并且需要高效地处理大量数据，那么HDF5 可能是一个不错的选择。如果你打算使用 numpy，那么它真的值得考虑。

【讨论】：

【解决方案7】：

使用 RDBMS 具有可靠的可扩展性和快速性。

如果您需要更可扩展的解决方案并且不需要 RDBMS 的功能，则可以使用具有良好 python api 的 couchdb 之类的键值存储。

【讨论】：

【解决方案8】：

NEMO 合作（在水下建造宇宙中微子探测器）有很多相同的问题，他们使用 mysql 和 postgresql 没有大问题。

【讨论】：

【解决方案9】：

这真的取决于你想要做什么。 RDBMS 专为关系数据而设计，因此如果您的数据是关系数据，则使用各种 SQL 选项之一。但听起来您的数据更倾向于具有非常快速的随机 GET 操作的键值存储。如果是这种情况，请比较各种密钥库的基准，重点关注 GET 速度。理想的键值存储将请求保存或缓存在内存中，并能够同时处理许多 GET 请求。您实际上可能想要创建自己的基准测试套件，以便有效地比较随机并发 GET 操作。

为什么需要集群？每个值的大小是否很大？如果没有，您不应该需要一个集群来处理一百万个条目的存储。但是，如果您要存储大量数据，这很重要，您可能需要一些轻松支持 read slaves 和/或透明分区的东西。一些键值存储是面向文档的和/或针对存储更大值进行了优化。由于快速 GET 所需的索引开销，Redis 在技术上对于较大的值更存储效率，但这并不一定意味着它更慢。事实上，额外的索引使查找速度更快。

您是唯一能真正回答这个问题的人，我强烈建议您组合一个自定义基准测试套件，以根据实际使用场景测试可用选项。您从中获得的数据将为您提供比其他任何东西更深入的洞察力。

【讨论】：