处理大型结构化数据集答案

【问题标题】：Dealing with large structured data sets处理大型结构化数据集
【发布时间】：2012-11-27 01:11:39
【问题描述】：

我要问的是一种方法，而不是一个具体的解决方案。我将从描述我认为具有挑战性的情况开始，然后继续这个问题。希望这样做更有意义。

我正在处理从自然语言中提取的数据。稍后必须根据某种“知识库”分析这些数据（引用它是因为它不是真正的知识库，我稍后会谈到）。到目前为止，知识库很大，其数量在理论上，但很快实际上将超过内存中可能存储的容量。我的两个担忧是：

将数据移动到数据库服务器将意味着速度降低一个因素...嗯，我不知道是什么因素，但它可能很容易降低几个数量级。 IE。在内存中的运行时本地对象中查找一条数据的任务要快得多，然后查询数据库。
任何时候都不需要整个海量数据。事实上，只使用了很小的一部分，所以，也许一些缓存可以帮助解决这个问题。我实际上希望有人已经遇到过这个问题，而缓存是正确的答案。

到目前为止，“知识库”只是一个复杂的数据结构，可以通过类似于使用某种查询语言查询数据库的方式来查询它。 IE。它不是一个简单的按键操作查找值，它需要多个子查询来识别一个对象是否匹配给定的条件。

只是为了给你一个更具体的例子来说明我正在尝试做的事情。与langutils 不同，我正在尝试提出一个解析器，我称之为“预测解析器”，对不起，如果该术语已经被采用并且意味着其他东西:) 主要思想是，而不是分配 POS 标签单词，然后通过将一组规则应用于推断信息来迭代地纠正原始假设，我试图以某种方式做到这一点，即给定特定前缀，引擎将根据其“学习知识”生成延续”。 IE。假设知识库了解到前缀“我可以”几乎肯定后面跟着一个动词短语。所以解析器会假设动词短语并按原样解析它，除非它遇到错误。困难的部分是找到合适的前缀。不好的是，像“我会”和“你应该”这样的前缀将获得同等的优先级，即它们将按照相同的顺序进行匹配检查，随机的、字母顺序等。这个想法是，虽然在知识获取过程中，知识库将学习以这样的方式存储和查找信息，即首先查找最可能的词首，而最不可能的词首最初甚至不会被加载。

这个概念有点类似于 CPU 缓存的工作原理。因此，如果我写的内容太长：我正在寻找一种数据结构，它的功能类似于 CPU 缓存，当前缓存的内容驻留在内存中，未缓存的内容存储在数据库中或作为文件等。

附言。对不起我收集的标签。我觉得这并没有真正描述我的问题。如果您知道问题属于哪里，欢迎您调整它。

【问题讨论】：

这是一个很难设计的问题。如果性能不重要并且（数据的）可维护性很重要，我会说去数据库。如果您的关键过程是标记，则每个令牌往返数据库将是典型成本（仅用于查询，更新更难）。对于实时马尔可夫事物，数据需要在核心中。
两级结构 - 前缀和规则用法 - 前缀是规则的 1:M，并且两者都被索引可能会有所帮助。前缀索引是正常的，但是规则使用索引是动态的、加权的，并且按照前缀内的权重排序。学习过程将填充 a) 规则使用表 b) 规则使用索引 c) 索引中的权重和 d) 前缀表和前缀索引。这个结构可以被缓存——两个索引和规则集适合一小组前缀。不知道有没有这样的加权索引结构。
听起来像 Datomic 非常适合您。它有一个和你描述的非常相似的缓存模型，它有一个基于datalog的查询系统。
如果你有能力构建一个网络集群，你仍然可以使用全内存实现，并划分出知识块，以便它们可以分布在集群中的不同节点上。看看这项工作作为 Erlang 实现的一个例子：act-r.psy.cmu.edu/papers/926/Douglass(2).pdf

标签： database dataset lisp common-lisp

【解决方案1】：

如果我们只考虑这部分：

这个想法是虽然在知识获取过程中 base 会学习以这种方式存储和查找信息，最可能的词首会被首先查找，并且最少最初可能甚至不会加载前缀。

那么，如果我对您的理解正确，您正在处理处理 n-gram 的任务。在您的情况下，您没有对前缀施加任何明确的限制，可以假设通常合理的限制适用，并且这些限制是 4-5 个单词的 n-gram。有很多这样的 n-gram：从真实世界的语料库中，您可以轻松获得千兆字节的数据。但是，即使您将自己限制为仅 3 克，您仍将获得至少几千兆字节，除非您执行一些巧妙的预处理，以某种方式将“好”的 n 克分开。（加上适当的平滑，这可能是一个可行的解决方案）。

除了大小之外，n-gram 的坏消息是它们是由Zipf's law 分发的，这基本上意味着缓存不会很有用。

所以，我只是将数据放入本地机器上的某个快速数据库中（也许是dbm 的一些变体）。如果你能把它全部放在内存中，也许 Memcached 或 Redis 会更快。

【讨论】：

当然，对于“the”缓存的情况是可行的，但普遍的问题是您将获得对 n-gram 的最大请求量，这些请求具有中等频率。因此，如果您缓存 20% 的最常见 n-gram，您将获得 20%，也许是 30% 的请求。虽然一个好的缓存用例是它能够为 80% 的请求和 20% 的最常用项目提供服务。（然而我对这个主题的理解可能并不精确和不完整——尽管我有一些实践经验，这在一定程度上证实了这一点）。