Database 处理大型结构化数据集

我要问的是一种方法论，而不是具体的解决方案。我将首先描述我发现具有挑战性的情况，然后继续提问。希望这样做更有意义

我正在处理从自然语言中提取的数据。这些数据以后必须根据某种“知识库”进行分析（引用它是因为它不是一个真正的知识库，我稍后再讨论）。到目前为止，理论上，知识库很大，其容量很大，但很快就会超过存储在内存中的容量。我关注的两个问题是：

• 将数据移动到数据库服务器将意味着速度降低一个因素。。。嗯，我不知道是什么因素，但它可能很容易达到几个数量级。也就是说，在内存中运行时本机的对象中查找数据块的任务比查询数据库快得多

• 在任何时候都不需要整个庞大的数据量。事实上，只使用了很小的一部分，因此，也许一些缓存可以帮助解决这个问题。我真的希望有人已经遇到了这个问题，缓存是正确的答案

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

我只是想给你一个更具体的例子来说明我在做什么。与

langutils

不同，我试图提出一种解析器，我称之为“预测解析器”，如果这个术语已经被使用，那么很抱歉，它的意思是其他的：）其主要思想是，不给单词分配词性标签，然后通过对推断信息应用一组规则来迭代修正原始假设，我试着用一种方式来做，给定一个特定的前缀，引擎将根据其“学到的知识”生成一个延续。也就是说，假设知识库了解到前缀“我可以”后面几乎肯定跟着一个动词短语。因此，解析器将假定动词短语并将其作为动词短语进行解析，除非它遇到错误。困难的部分是找到正确的前缀。不好的是，像“I will”和“you shall”这样的前缀将获得同等的优先级，即它们将按照相同的顺序检查匹配，可以是随机的，也可以是字母顺序等。不过，在知识获取过程中，知识库将学会以这种方式存储和查找信息，最可能的前缀将首先被查找，而最不可能的前缀甚至不会在最初加载

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

---

对不起，我收集了很多标签。我觉得这并不是在描述我的问题。如果你知道问题所在，欢迎你调整它。

< P>如果我们只考虑这一部分：

其思想是，在知识获取过程中 基地将学会以这种方式存储和查找信息， 最有可能的前缀将首先被查找，而最不可能被查找 可能的前缀最初甚至不会加载

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

关于n-gram的坏消息是，除了它们的大小之外，它们都是由分布的，这基本上意味着缓存不会非常有用

---

所以，我只是把数据放在本地机器上的一些快速数据库中（也许，是的一些变体）。如果您可以将所有内容都放在内存中，Memcached或Redis可能会更快。

这是一个很难解决的设计问题。如果性能不重要，而（数据的）可维护性很重要，我会说数据库。如果您的关键流程是标记，则每个令牌往返数据库将是典型的成本（仅用于查询，更新更困难）。对于实时Markov thingies，数据需要在核心中。两级结构-前缀和规则使用-其中前缀与规则的比例为1:M，并且两者都被索引可能会有所帮助。前缀索引是正常的，但规则使用索引是动态和加权的，并按前缀中的权重排序。学习过程将填充a）规则使用情况表b）规则使用情况索引c）索引中的权重和d）前缀表和前缀索引。这个结构可以被缓存——两个索引和适合于一小部分前缀的规则集。我不知道是否存在这样的加权指数结构。听起来Datomic会很适合你的账单。它有一个与您描述的非常相似的缓存模型，并且它有一个基于数据日志的查询系统。如果您有能力构建一个网络集群，您仍然可以使用全内存实现，并划分出知识块，以便它们可以分布在集群中的不同节点上。以Erlang实现为例来检查这项工作：当然，对于“缓存”的情况，缓存是可以工作的，但一般的问题是，您将获得对n-gram的最大请求量，而n-gram具有中等频率。所以如果你