快速关键字查找

Question

我正在编写一个程序，将用户提交的查询与关键字列表进行匹配。该列表大约有2000个单词，性能最重要。

旧

  

将此列表存储在a中是否更快   它在SQL表或硬代码中   源代码？该列表不需要   经常更新。

     

如果SQL表的哪个数据更快   类型会是最好的？ （智力，   nvarchar的？）

     

如果硬编码列表的数据更快   类型会是最好的？   （列表？）

     

有什么建议吗？

快速查找的最佳内存数据结构是什么？

Answer 1

存储此数据的性能无关紧要。

如果您启动程序，则从您存储的数据存储区加载字符串数组 一次 。然后你可以一直使用这个数组，直到你退出程序。

Answer 2

IMO，如果列表没有经常更新，请将其存储在文件（text / xml）上，然后将其缓存在您的应用程序中，以便下次请求更快。

Answer 3

好的，回复你的编辑（并基本上将我的评论提到答案中）：

1. 事先指定您期望的表现。

2. 针对排序数组对应用程序进行编码，并使用二进制搜索在数组中搜索关键字。这很容易实现，并提供了不错的性能。然后进行配置以查看它是否与您要求的性能相匹配。如果此表现可以接受，请继续。这里最糟糕的表现是O(m log n)，其中n是关键字的数量，m是关键字的最大长度。

3. 如果第二步中的性能不可接受，请使用trie（也称为前缀树）。此处的预期效果为m，其中m是关键字的最大长度。查看是否符合您的预期效果的配置文件。如果没有，请重新审视您的绩效标准;他们可能是不合理的。

4. 如果您仍未达到性能规格，请考虑使用散列表（在.NET中，您将使用HashSet<string>。虽然散列表的最坏情况会更差，但它可能会有更好的平均值大小写性能（如果没有冲突，哈希表查找为O(1)，而哈希计算功能为O(m)，其中m是关键字的最大长度。。这可能更快（平均而言） ）但可能并不明显。

您甚至可以考虑直接跳到最后一步（因为它不如前者复杂）。这一切都取决于您的需求。尝试具有以下优点：您可以轻松地吐出最接近的匹配关键字，例如。

这里重要的是要对您的性能要求进行规范并进行分析！使用最简单的实现来满足您的性能要求（可维护性，可读性和可实现性（如果不是，现在就是一个词！）

Answer 4

  

该列表不需要经常更新

我说如果它需要更新它不属于源代码。

Answer 5

硬编码列表更快。检索列表的数据库命中无疑比从内存中对象中拉出列表要慢。

对于存储值的数据类型，数组可能比List更快，占用的内存更少，但是很简单。

Answer 6

如果列表基本上是静态的，并且你可以花费一些时间准备（即在应用程序启动时），你可能最好将关键字列表存储在文本文件中，然后使用例如B *树在内部存储关键字（假设您只关心完全匹配而不是部分匹配或Levenshtein距离）。