Python中的文件索引（使用二叉树？） 背景

我有许多（数千！）基于字段的标准格式的数据文件（想想制表符分隔的，每行、每一个文件中都有相同的字段）。我正在讨论各种使这些数据可用/可搜索的方法。（一些选项包括RDBMS、NoSQL、使用grep/awk和friends等）

提议 特别是，一个吸引我的想法是以某种方式“索引”文件。因为这些文件是只读的（并且是静态的），所以我设想了一些包含二叉树的持久文件（每个索引字段对应一个，就像其他数据存储中一样）。我愿意接受关于如何解决这个问题的想法，或者听人说这简直是疯了。大多数情况下，我最喜欢的搜索引擎并没有为我提供任何预先推出的解决方案

我意识到这是一个有点不正确的形式，解决办法是受欢迎的

其他细节

• 文件长，不宽
  • 每小时数百万行，每小时传播100多个文件
  • 制表符分开，列不多（~10列）
  • 字段较短（例如每个字段<50个字符）
• 查询基于字段、字段组合，可以是历史查询

各种解决方案的缺点： （所有这些都是基于我的观察和测试，但我愿意改正）

BDB

• 在扩展到大文件大小方面存在问题（根据我的经验，一旦文件大小达到2GB左右，性能可能会非常糟糕）
• 单个编写器（如果有可能绕过这个问题，我想看看代码！）
• 很难进行多个索引，也就是说，一次在不同的字段上进行索引（当然可以通过反复复制数据来实现这一点）
• 因为它只存储字符串，所以有一个序列化/反序列化步骤

RDBMSes

胜利：

• 平面表模型非常适合于查询、索引

损失：

• 根据我的经验，问题在于索引。从我所看到的（如果我错了，请纠正我），我所知道的RDBMSE（sqlite、postgres）的问题是支持批处理加载（然后索引在最后很慢）或逐行加载（这很低）。也许我需要更多的性能调整

  ---

物理存储访问时间将主导您所做的任何事情。当您分析时，您会发现

read（）

是您花费大部分时间的地方

为了减少等待I/O的时间，最好的选择是压缩

---

为所有文件创建一个巨大的ZIP存档。一个

打开

，读取次数更少。您将花费更多的CPU时间。然而，I/O时间将主导您的处理，因此通过压缩所有内容来减少I/O时间。

为什么要重新发明轮子？无论如何，索引文件，但使用、或等

---

编辑：在我发布此答案时，您尚未说明您的性能要求。您将无法使用现成的软件为“每小时数百万行”编制索引。

如果数据已按字段组织，则听起来不像是文本搜索/索引问题。这听起来像是数据库可以很好地提供的表格数据

将文件数据脚本化到数据库中，根据需要编制索引，并以数据库支持的任何复杂方式查询数据

---

除非你正在寻找一个很酷的学习项目。然后，想尽一切办法，提出一个有趣的文件索引方案。

有许多基于文件的DBMS是为您描述的数据类型而设计的。其中最广泛使用的是。它是开源的，现在归Oracle所有，有C和Java两种版本（C版本有Python和其他语言包装）

但是，由于您的数据是只读的，因此还有其他选项。我想到的是。它同样具有Python接口，以及纯Python的重新实现

---

或者，如果你真的喜欢自己实现东西，你可以从谷歌的Bigtable文件中实现

sqlite3速度快，体积小，是python的一部分（因此无需安装），并提供列索引。它会写入文件，因此您无需安装数据库系统。

这太开放了。我认为关于如何查询数据、数据大小等更多细节将有助于确定哪些方法在这里有意义。我不同意。我们不知道数据集大小如何，不知道内存大小，不知道访问模式，等等@Bandi-t:去过那里，做到了。压缩为所有用例带来了显著的改进，除了“我们所做的就是插入文件，不再读取文件”场景。对于历史存档（一次写入-从不读取）用例，没有必要进行性能优化。@s.Lott：我仍然不同意。压缩可能会将数据大小（I/O负载）减少1:10-适当的索引可能会将其减少1:1000。@Bandi-T:这取决于索引的选择性。不是很有选择性的索引（“男性”与“女性”）可能只会减少大约1/2的行数。索引的聪明可以通过查询的沉默来弥补。压缩通常会为文本文件做更多的工作，并且无法通过哑查询撤消。@S.Lott:没错。你知道OP是否有文本文件吗？你知道他的列值有多高的选择性吗？这让我们回到了第一个问题（到OP）“你有什么，你想做什么？”我没有看到任何迹象表明OP在寻找全文搜索。我的回答是OP提到了两个索引框架，它们非常适合面向字段和分面搜索，对非结构化文本没有特别的偏见。我根本不寻求全文搜索（我倾向于选择Sphinx:），这就是为什么我的答案指向两个非常适合您的框架。Whoosh并没有宣传自己是表格数据索引器，但它似乎是这样工作的。我想知道它比MongoDB有什么优势。我要做一些测试！国开行对我来说是新闻！经过调查，它看起来也很整洁