Question

我有以下情况，其中搜索返回用户标识值列表（1,2,3,4,5,6 ...等）如果要再次运行搜索，结果将保证更改给了一些时间。但是我需要存储将来要使用的搜索结果的实例。

我们有一个当前的实现（遗留），它使用条件为search_id创建一条记录，并将返回的每一行插入到具有相关search_id的不同表中。

table search_results
   search_id unsigned int FK, PK (clustered index)
   user_id unsigned int FK

这是一种不可接受的方法，因为该表已经发展到数百万条记录。我考虑过分区表，但要么我会有很多分区（1000s）。

我优化了搜索结果已过期的现有表格，除非它们在其他地方使用过，因此所有搜索结果都会在别处引用。

在当前架构中，我无法将结果存储为序列化数组或XML。我希望有效地存储搜索结果信息，以便以后可以有效地访问它而不会受到记录数量的影响。

编辑：感谢您的回答，我自己运行搜索没有任何问题，但搜索的结果集在这种情况下用于收件人列表，这将被反复使用，目的存储就是在给定时间拥有数据的快照。

Answer 1

答案是不存储查询结果。这是一个糟糕的主意！

它引入了statefulness，这非常糟糕，除非你真的（真的非常）需要它
不是scalable（正如你所知）
数据一存储就会过时

正确的方法是修复您的查询/数据库，使其快速运行。

如果使用更好的SQL和/或索引等无法更快地进行查询，我建议使用lucene（或任何基于文本的搜索引擎）并将数据库反规范化。 Lucene的查询非常快。

我最近在一个正在做你正在做的事情的大型网站上做到了这一点：它正在缓存来自会话对象中的生产关系数据库的查询结果，试图加速查询，但这是一团糟，并且不是'无论如何要快得多 - 在我的时间之前，一位“高级”java开发人员（其名字以Jam开头，以.illiams结尾）实际上是一个白痴，他认为这是一个好主意。

我放入了Solr（一个java定制的lucene实现），并使Solr与关系数据库（使用工作队列）保持同步，现在只需几毫秒的时间就可以进行Web查询。

Answer 2

您是否需要存储每次搜索？当然，您会想要为用户提供最新的信息吗？

我首先承认，这不是一个很好的解决方案。

在当前的[SYS_Searches]
保存脚本可以使用SELECT INTO [SYS_Searches] .Results_ {Search_ID}
检索的脚本可以从匹配表中执行简单的SELECT。

<强>优点：

每个搜索都整齐地打包到自己的表中，[最好在另一个数据库中]
检索查询非常简单
检索时间应该非常快，不需要大量的表扫描。

<强>缺点：

您将拥有一个用户可以存储的每个x用户* y搜索表。

除非涉及管理层使结果到期或用户只能拥有1个缓存的搜索结果集，否则这可能会非常愚蠢。

不漂亮，但我想不出另一种方式。

存储搜索结果以供将来使用

2 个答案: