我正在为一个尚未设置约束和规范的新项目做一些研究。需要的一件事是直接在根域下的大量路径。这可能会增加数百万条路径。这些路径没有共同的结构或独特的部分，所以我必须寻找完全匹配的东西。
现在我知道分解这些路径更有效，这也有助于路径查找。但是我正在研究这里的可能性，所以请耐心等待。
我正在评估实现这一目标的方法，同时保持出色的性能。我想到了以下方法：
- 将路径存储在 SQL 数据库中并对每个请求进行查找。这似乎是最糟糕的选择，绝对不会被使用。
- 将路径存储在 Redis 等键值存储中。这会好很多，而且我认为表现得很好（尽管必须对其进行基准测试）。
- 进行字符串/正则表达式匹配 - 就像许多框架一样，开箱即用 - 因为这么多可能的匹配是疯狂的，因此不是一个真正的选择。但是我可以看到，在结合一些智能优化的情况下，逐字母比较的某种算法是如何起作用的。
但也许有一些我不知道的工具/方法更适合这类问题。不过，我可以使用任何提示来完成此操作。
哦，如果有人想知道，不，这不是家庭作业。
更新
我已经测试了 Redis 方法。基于两组关键词，我得到了 1.5 亿条路径。我已经使用set命令添加了它们中的每一个，其值是一个序列化的 id 字符串，我可以使用它来识别请求中的实际关键字。( SET 'keyword1-keyword2' '<serialized_string>')
在具有一百万条记录的数据集的本地 VM 中进行快速测试返回了有希望的结果：对 1000 个请求进行基准测试平均需要 2 毫秒。这是在我的笔记本电脑上，它运行着很多其他的东西。
接下来我在一个 4 核 8GB 内存的 VPS 上做了一个完整的测试，完整的 1.5 亿条记录。这产生了一个文件大小为 3.1G 的数据库和大约 9GB 的内存。由于数据库无法完全加载到内存中，Redis 开始交换，这导致了可怕的结果：平均大约 100 毫秒。
显然这不会起作用并且可以很好地扩展。要么每个 Web 服务器都需要有大量的 RAM，要么我们必须使用专用的 Redis 路由服务器。我读过Instagram 工程师的一篇文章，他们想出了一个技巧来显着减小数据库大小，但我还没有尝试过。无论哪种方式，这似乎都不是正确的方法。回到绘图板。