我正在研究存储大量数据的语义搜索系统。数据实际上是文档及其索引。主要问题是如何使用本体索引文档以及如何存储它们。
我的问题是关于第二个问题。起初，我在RDBMS中实现了存储。它运作缓慢。我考虑为此目的使用一些NoSQL数据库，但有一些疑问。
请注意，使用Lucene的简单文本搜索不是我在当前字段中所需要的。
让我简化商店结构。注意，仅存储反向索引。在RDBMS中我们有表：
1）单词 - 来自某些词典的单词
2）文档 - 包含元数据的文档及其内容
3）命中 - 单词在文档中的命中（所有命中用'|'分隔）
获取结果系统分析请求中的单词并根据单词的命中信息计算文档相关性。我省略了一些关于语义分析的时刻，现在并不重要。
您如何看待存储这个词的结构？
{
“字”：“some_word”，
...
“字典中的其他一些元数据”
...
“命中”：[
“doc1”：[“hit_info1”，“hit_info2”...]
“doc2”：[“hit_info1”，“hit_info2”...]
]
}
提前致谢！
答案 0 :(得分：1)
首先，RDBMS是高度结构化数据的不错选择。 RDBMS的主要性能问题是事务处理。您尝试管理单词和文档之间的n：m关系。这不能在文件系统中完成。使用SQL服务器并按照以下提示进行操作，然后它应该足够快。
首先，您应该考虑支持“广义批处理”的ORM（对象关系映射）框架。对于C＃和.NET，我可以推荐“DataObjects.NET”。它为您节省了大量优化客户/服务器往返的工作。
让您的交易尽可能大。如果您有一个包含1000个单词的文档，请在一个事务中处理它。也许您可以在一个事务中处理多个文档。
分两批形成您的插页： （批处理是SQL命令的早午餐，一个和平地发送到服务器）
批量执行此操作绝对重要。如果你执行单个陈述，你将在客户/服务器往返中陷入困境。
我有类似的数据要处理，对于大批量（100000字），这是在大约0.2-0.5秒内完成的。
P.S。 并考虑禁用SQL服务器上事务端的刷新到磁盘。