.NET vs SQL Server - 重复搜索的最佳实践答案

【问题标题】：.NET vs SQL Server - best practise for repeated searching.NET vs SQL Server - 重复搜索的最佳实践
【发布时间】：2011-10-24 12:45:58
【问题描述】：

我的客户要求将基于“建议”的查找添加到特定表单字段。换句话说，当您开始在某个字段中输入内容时，应该会出现一个“Google 风格”弹出窗口，它会建议您从中选择可能的结果。将有大约“数万”个可能的建议 - 这是我目前对数量的最佳估计。

使用 AJAX 发送/检索结果，我的问题是将所有建议存储在 .NET 缓存中并在那里处理是否更好，或者在 SQL Server 上为每个请求运行基于存储过程的查询是否更好?

这将使用 .NET 2.0 和 SQL Server 2005

【问题讨论】：

【解决方案1】：

每次面对这样的任务时，我都会使用一个技巧。不要在每次击键时都这样做。将搜索的启动设置为滑动超时。

此处的目的是仅在用户暂停输入时才启动搜索。通常我将超时设置为 0.1 到 0.2 秒。从心理上讲，它仍然是瞬时的，但它大大减少了您将用于搜索的任何内容的负载

【讨论】：

我真的很喜欢这个想法，我一定会把它作为设计的一部分...谢谢
这是一个很好的观点......而且我越想它，作为谷歌搜索的用户，我最终在输入时本能地建立了一个暂停。我会快速输入我认为“足够”的内容，然后稍微停顿一下，看看是否“它明白了”。在没有建议的搜索框中输入时感觉像个傻瓜：-)

【解决方案2】：

您的瓶颈是将数据从服务器传输到浏览器。您几乎可以在短时间内轻松地从数据库中生成大量结果，但返回浏览器需要很长时间。

您必须找到一种方法来限制服务器返回的结果，以便您只获取用户现在必须看到的内容。

当您将数据流量降至合理水平时，您可以开始考虑优化服务器部分。考虑到当用户键入结果通常是先前结果的子集时，使用一些应该很容易的缓存和逻辑，例如"hat" 的匹配是 "ha" 的匹配的子集。

【讨论】：

我认为您在这里找到了一个重要的...特别是当人们在建议列表中搜索经常重复的单词时。尽管您建议的缓存想法会增加用户体验，但它需要为网站上的每个用户提供缓存，这可能会进一步增加服务器资源需求。
@freefaller：它不需要为每个用户缓存，它可以利用查询经常相互跟随的方式。例如，它可以使用“ha”的缓存结果来生成“hat”的结果，而无需查询数据库。
抱歉，我一定遗漏了一些东西，因为除了用户特定之外，我看不出它会如何。如果多个用户同时在网站上（我希望他们是这样），那么就不可能使用子集，因为查询很可能完全不同。
@freefaller：没有理由让它特定于用户。大多数情况下，缓存会使用来自同一用户的先前结果，但如果另一个用户正在寻找类似的东西，而结果仍在缓存中，则没有理由不使用它。例如，考虑“ca”的结果可以同时用于生成“car”和“cat”的结果。
我明白你在说什么，是的，我认为尝试存储（即使是很短的时间）该子集确实是有意义的。感谢您的意见

【解决方案3】：

当我在 SQL Server 环境中看到“键入时建议”类型的搜索时，我看到了使用某种缓存机制的最佳性能，通常是分布式方法 - 通常像 memcached。即使您的代码优化得很好，您的数据库也得到了很好的调整，并且您的查询在调用、处理和返回时只花费了

【讨论】：

谢谢迈克。有点不清楚您是说 10 毫秒响应是好事还是坏事。我个人不会看到（比如说）500 毫秒响应下的任何问题，因为瞬时并不完全重要
我是说低于 10 毫秒会很棒，但我用这个数字来感受即使是通过堆栈调用的 DBMS 的出色性能有时也会让执行搜索建议类型的用户感到迟缓搜索。在我的示例中，10 毫秒可能是滥用的错误持续时间，但我的观点是 - 我认为您会通过缓存方法获得更快的建议。不过，我不认为使用 SP 并为此目的优化数据库/调用会很糟糕，只是没有那么快。

【解决方案4】：

这取决于项目的数量。如果您可以在 .NET 进程中缓存项目而不会耗尽内存，这肯定会更快。

但是，如果无法做到这一点，您将不得不在每次请求时访问数据库。存储过程将是一个很好的方法。

但是有一些设计模式可以指导你。在开发类似于您正在做的事情时，我使用了以下两个。

【讨论】：

感谢 Wouter - 这几乎正是我一直在经历的思维模式。这两个选项当然值得考虑，但我会担心要下载和存储在浏览器上的数据量。
在我编写的“动态搜索”应用程序中，我们将显示的最大项目数限制为 10 个。因此，对于每次击键，我们将缓存 10 个项目，当用户输入更多字符时，我们可以过滤列表更多。