假设我有一组一百万个标签和一个需要为这些标签和可能的新标签解析的文本。这里的标签数量只是说明我的思维问题的一个例子——太多而无法以线性方式循环，太多而无法保存在内存中等等。
不知何故，我想不出一个占用空间小的解决方案（并且保持快速）。我知道人们必须进行权衡，但我认为我忽略了一些概念。
这对于智能标记（“Michael Jackson”=“artist”等）特别有趣，因为应用的标记可能不是文本本身的一部分。
除了做单词黑名单、流行标签缓存和大量 sql 查询之外，解决这个问题的最有效方法是什么？
（很有趣，我必须自己标记这个问题:-)）
由于我的评论空间有限，让我在这里补充一些想法：
- 我同意使用整数哈希可以提高速度。好主意。
- 散列不会解决迭代问题（循环遍历每个散列/标签，同时根据标签列表检查单词或单词组合）
- 细化问题：假设像“hello world”这样的文本。此文本有 3 个潜在标签（“hello”、“world”和“hello world”）。标签列表可能只包含“hello”，但解析后可能会添加“world”或“hello world”，这意味着这些标签不会应用于文本。
问题：
- 假设一个书本大小的文本，遍历所有组合（如“九英寸钉子”，但我们假设组合限制为 4 个单词）以将它们与数据库中的标签进行比较需要很长时间，即使假设使用整数哈希也是如此。
- 标签列表可能很长，因此迭代存储的标签也可能很慢。
- 标签更新将意味着对文本进行额外的全文搜索 - 取决于文本的数量及其长度，这可能是数据库杀手并且根本没有效率？
- 如何自动找到“相关”的新标签？（在一篇关于音乐的文章中再次想到“九寸钉”——但“发行一首新歌”并不是一个好的标签）。不过，这可能是一个问题。