如何有效地存储文档索引答案

【问题标题】：How to efficiently store document indexes如何有效地存储文档索引
【发布时间】：2012-01-08 11:31:55
【问题描述】：

我正在研究存储大量数据的语义搜索系统。数据实际上是文档及其索引。主要问题是如何使用本体索引文档以及如何存储它们。

我的问题是关于第二个问题。起初，我在 RDBMS 中实现了存储。它的工作非常缓慢。我考虑为此目的使用一些 NoSQL 数据库，但有一些疑问。

请注意，使用 Lucene 进行简单的文本搜索并不是我在当前领域所需要的。

让我简化商店结构。请注意，仅存储倒排索引。在 RDBMS 中，我们有表：
1) Word - 某些字典中的单词
2) 文档 - 包含元数据及其内容的文档
3) Hit - 单词在文档中的命中（所有命中由 '|' 分隔）

为了获得结果，系统会分析请求中的单词并根据单词的命中信息计算文档相关性。我省略了一些关于语义分析的部分，暂时不重要。

您如何看待单词存储的这种结构？

{
"word": "some_word",
...
“字典中的一些其他元数据”
...
“命中”：[
“doc1”：[“hit_info1”、“hit_info2”...]
“doc2”：[“hit_info1”、“hit_info2”...]
]
}

提前致谢！

【问题讨论】：

您是否考虑将它们存储在您的文件系统中？文件系统实际上是一个非常优化的 NoSQL 系统。
有很多插入、更新和选择存储正在做，我认为文件系统不是最好的解决方案。
请提供有关您的数据以及如何查询此数据的其他信息。您是如何在 RDBMS 中实现这一点的？
我将简化结构以便更好地理解。在 RDBMS 中有表格：Word（来自某个 dict 的单词）、Hit（wordid、docid 以及此文档中所有单词的命中）、Document（文档本身）。
为什么不呢？文件系统是为插入、更新、按键选择而设计的。事实上，任何 DB、NoSQL 或 RDBMS，在某些时候都会归结为文件系统......

【解决方案1】：

首先，RDBMS 是高度结构化数据的不错选择。 RDBMS 的主要性能问题是事务处理。您尝试管理单词和文档之间的 n:m 关系。这不能在文件系统中完成。使用 SQL 服务器并遵循以下提示，那么它应该足够快。

首先，您应该考虑一个支持“广义批处理”的 ORM（对象关系映射）框架。对于 C# 和 .NET，我可以推荐“DataObjects.NET”。它为您节省了大量优化客户端/服务器往返的工作。

使您的交易尽可能大。如果您有一份 1000 字的文档，请在一个事务中处理它。也许您可以在一次事务中处理多个文档。

分两批形成您的插入物：（批处理是一次性发送到服务器的一系列 SQL 命令）

批量执行此操作非常重要。如果您执行单个语句，您将在客户端/服务器往返行程中搞砸。

我有类似的数据要处理，对于大批量（100000 字）来说，这大约需要 0.2-0.5 秒。

附：并考虑在 SQL 服务器的事务结束时禁用刷新到磁盘。

【讨论】：

感谢您的解释！我已经实现了批量插入和大型事务。是的，它在大约 1 秒内完成了 10 万次插入，但是为文档中的每个单词插入新行似乎效率不高。
这很简单：如果你需要它，你必须拥有它。如果您不需要所有单词，请考虑惰性索引。仅索引您查询的单词。很明显，这对大量文档有缺点。
另一个想法：你有没有想过用散列函数将你的单词折叠成一些更小的索引？计算一个简单的哈希并将其折叠到 16 位或更少。因此，您的索引室可以随心所欲。您的查询结果集太大，但这很容易检查。也许您可以在索引和查询数据之间取得更好的折衷。
你对 NoSQL 存储的 JSON 结构有什么看法（我已经更新了我的问题）？
事实上，您将信息放入单词中。这对插入没有多大帮助，因为对于每个新文档，您都必须更新附加信息。这实际上与具有两个键的 n:m 表具有相同的复杂性。我认为情况更糟，因为您必须为文档中的每个单词阅读、更新和编写此信息。在 n:m 表中，它只是每个单词的插入。