PyTables处理的数据比内存大很多倍

Question

我试图理解PyTables如何管理大于内存大小的数据。 以下是PyTables（link to GitHub）代码中的注释：

# Nodes referenced by a variable are kept in `_aliveNodes`.
# When they are no longer referenced, they move themselves
# to `_deadNodes`, where they are kept until they are referenced again
# or they are preempted from it by other unreferenced nodes.

也可以在_getNode方法中找到有用的注释。
PyTables似乎有非常智能的IO缓冲系统，据我所知，它将用户引用的数据存储在快速RAM中作为“aliveNodes”，将之前和当前未引用的数据保存为“deadNodes”，以便在需要时快速“恢复”它，并且如果请求的密钥不存在于dead或alive类别中，则从磁盘读取数据。在

我需要一些专业知识来了解PyTables在处理比可用内存更大的数据时是如何处理这种情况的。我的具体问题：

1. 死点/验证节点系统如何工作（普通图片）？在
2. 如果正确的话，aliveNodes/deadNodes都代表存储在RAM中的数据，那么它们之间的关键区别是什么？在
3. 缓冲RAM的限制可以手动调整吗？在注释下面，是从params['NODE_CACHE_SLOTS']读取值的代码。它能被用户指定吗？例如，如果我想为其他需要内存的应用程序保留一些RAM？在
4. 在什么情况下，PyTables在处理大量数据时会崩溃或显著减速 数据的数量？在我的情况下，记忆可以超过100倍，在这种情况下，常见的陷阱是什么？在
5. PyTables在大小、数据结构以及对被认为是“正确”的数据进行操作以获得最佳性能方面的用途是什么？在
6. append" rel="nofollow">Docs suggests在每个基本.append()循环后使用.flush()。这个周期到底能持续多久？我执行了一个小的基准测试，比较了SQLite和PyTables如何处理从大的CSV文件创建一个大表的键值对。当我在主循环中使用.flush()时，PyTables获得了巨大的加速。那么-正确吗，先.append()相对较大的数据块，然后使用.flush()？在

Answer 1

我不是PyTable¹的专家，但它的工作方式很可能与swap memory类似。在

aliveNodes位于RAM中，而{}可能存储在磁盘上的hdf5文件中（PyTables使用的二进制文件格式）。 每次你需要访问一段数据时，它必须在RAM中。因此PyTable检查它是否已经存在（aliveNodes），如果已经存在，则返回给您。否则，它需要恢复数据所在的deadNode。由于RAM是有限的，它可能会杀死一个未使用的aliveNode来预先腾出一些空间。在

这个过程的原因当然是内存的大小有限。 其结果是，每次需要交换节点时性能都会受到影响（kill一个节点，revaive另一个节点）。在

为了优化性能，您应该尽量减少交换。例如，如果您的数据可以并行处理，那么您可能只能加载每个节点一次。另一个例子：假设你需要循环一个巨大矩阵的每个元素，这个矩阵被分割成一个节点网格。那么最好避免按行或按列访问其元素，而不是逐节点访问。在

当然，PyTable在幕后处理这个问题，所以您不必控制每个节点中的内容（但我鼓励您深入研究这个NODE_CACHE_SLOTS变量，至少要了解它是如何工作的）。但一般来说，访问连续的数据比分散在各地的数据更快。与往常一样，如果时间性能是应用程序的一个重要问题，请评测您的代码。在

---

^{1翻译：我对PyTables几乎一无所知}