处理大型结构化数据集

时间:2012-12-09 11:50:33

标签: database dataset lisp common-lisp

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

我正在处理从自然语言中提取的数据。这些数据必须稍后根据某种“知识库”进行分析(引用它是因为它不是真正的知识库,我稍后会介绍它)。到目前为止,理论基础上知识库很大,其数量很大,但实际上很快就会超过存储在内存中的内容。我的两个问题是:

  • 将数据移到数据库服务器上意味着减速的因素......好吧,我不知道是什么因素,但它可能很容易几个数量级。即在位于内存中的运行时本机的对象中查找数据的任务明显更快,然后查询数据库。

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

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

只是为了给你更具体的例子,说明我正在尝试做什么。与langutils不同,我正在尝试提出一个解析器,我称之为“预测解析器”,如果该术语已被采用并且意味着其他内容,则很抱歉:)主要的想法是不是分配POS标记为单词,然后通过对推断信息应用一组规则迭代地纠正原始假设,我试图以某种方式进行,给定一个特定的前缀,引擎将生成一个延续,基于其“学到的知识“。即假设知识库知道前缀“我能”几乎肯定会跟着动词短语。所以解析器会假设动词短语并解析它,除非它遇到错误。困难的部分是找到合适的前缀。不好的是,像“我愿意”和“你应该”这样的前提将获得相同的优先权,即他们将以相同的顺序检查匹配,无论是随机的,字母的等等。这个想法是在知识获取期间知识库将学会以这种方式存储和查找信息,最先查找最可能的前提条件,并且最不可能的前提条件最初都不会被加载。

这个概念有点类似于CPU缓存的工作原理。所以,如果我写的内容太长:我正在寻找一种数据结构,其功能类似于CPU缓存,其中当前缓存的内容驻留在内存中,而不是存储在数据库中,或作为文件等。

PS。对不起我的标签集。我觉得它并没有真正描述我的问题。如果您知道问题所在的位置,欢迎您进行调整。

1 个答案:

答案 0 :(得分:1)

如果我们只考虑这部分:

  

这个想法虽然是在知识获取过程中获得的知识   base将学会以这种方式存储和查找信息,   最有可能的前提是先查找,最少   可能的初始版本甚至不会被加载。

然后,如果我理解正确的话,你就是在处理处理n-gram的任务。在你的情况下,你没有对前缀作出任何明确的限制,可以假设,通常合理的限制适用,那些是4-5字n-gram。有很多这样的n-gram:从现实世界的语料库中你可以轻松获得数十亿字节的数据。但即使你将自己限制在只有3克,你仍然会获得至少几千兆字节,除非你执行一些聪明的预处理,否则会以某种方式将“好”的n-gram分开。 (加上适当的平滑,这可能是一个可行的解决方案)。

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

所以,我只是把数据放到本地机器上的一些快速数据库中(可能是dbm的一些变体)。如果你可以将它全部放在内存中,也许,Memcached或Redis会更快。