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

时间:2009-08-05 20:37:19

标签: python orm persistence

我正在开始一个新的科学项目,它有大量的数据(数百万条目),我想以一种简单快捷的格式存储。我遇到了许多不同的潜在选择,但我不确定如何从中挑选。我的数据可能只是存储为字典,或者可能是字典字典。一些潜在的考虑因素:

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

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

我开始关注的一些潜在选项(请参阅this发布):

有关哪些可能更适合我的目的的任何建议?有更好的想法吗?其中一些有后端;关于哪个文件系统后端最好的建议?

9 个答案:

答案 0 :(得分:13)

可能希望给mongodb一个镜头 - PyMongo库可以使用字典并支持大多数Python类型。易于安装,性能卓越+可扩展。 MongoDB(和PyMongo)也在一些大牌上使用in production

答案 1 :(得分:8)

RDBMS。

没有什么比在众所周知的RDBMS上使用表格更可行了。想到Postgresql

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

真的很快。

在“感觉像python”这一点上,我可能会补充说你可以使用ORM。强名称是sqlalchemy。也许使用elixir扩展程序”。

使用sqlalchemy,您可以让您的user / sysadmin选择他想要使用的数据库后端。也许他们已经安装了MySql - 没问题。

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

答案 2 :(得分:5)

我正在研究这样一个项目,我正在使用SQLite

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

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

我发现使用SQL过滤/排序/操作/ ...数据非常方便。虽然,我不是SQL专家。 (的易于使用)

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

无论如何,SQLite对我有用。

答案 3 :(得分:4)

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

答案 4 :(得分:3)

Sqlite - 它带有python,快速,广泛可用且易于维护

答案 5 :(得分:2)

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

答案 6 :(得分:1)

使用RDBMS可靠且可扩展且速度快。

如果你需要更多的scalabre解决方案并且不需要RDBMS的功能,你可以使用像couchdb那样具有良好python api的键值存储。

答案 7 :(得分:1)

NEMO合作(在水下建造一个宇宙中微子探测器)有很多相同的问题,他们使用mysql和postgresql没有重大问题。

答案 8 :(得分:1)

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

为什么需要集群?每个值的大小是否非常大?如果没有,您不应该需要一个集群来处理一百万个条目的存储。但是,如果你要存储大量数据,这很重要,而且你可能需要一些容易支持读取从属和/或透明分区的东西。一些键值存储是面向文档的和/或优化用于存储更大的值。由于快速GET所需的索引开销,Redis在技术上对于更大的值更具存储效率,但这并不一定意味着它更慢。事实上,额外的索引使查找更快。

你是唯一能够真正回答这个问题的人,我强烈建议整合一个自定义基准测试套件来测试实际使用场景下的可用选项。您从中获得的数据将为您提供更多的洞察力。