自动完成字段的性能不佳会降低其实用性。如果客户端实现必须调用执行大量数据库查找的端点，则响应时间很容易令人沮丧。
一种巧妙的方法来自 AWS Case Study: IMDb 。它曾经附带一个图表(不再可用)，但简而言之，将为每个可以以有意义的方式解析的组合生成并存储预测树。例如。 sta 的解析将包括将被存储的Star Wars、Star Trek、Sylvester Stallone，但 stb 不会解析为任何有意义的内容，也不会被存储。
To get the lowest possible latency, all possible results are pre-calculated with a document for every combination of letters in search. Each document is pushed to Amazon Simple Storage Service (Amazon S3) and thereby to Amazon CloudFront, putting the documents physically close to the users. The theoretical number of possible searches to calculate is mind-boggling—a 20-character search has 23 x 1030 combinations—but in practice, using IMDb's authority on movie and celebrity data can reduce the search space to about 150,000 documents, which Amazon S3 and Amazon CloudFront can distribute in just a few hours. IMDb creates indexes in several languages with daily updates for datasets of over 100,000 movie and TV titles and celebrity names.
如何使用私有(private)数据获得类似的性能体验？例如。自动完成客户名称、作业 ID、发票编号...为单独的用户存储不同的文档/决策树听起来很昂贵，特别是如果某些数据(客户名称？)可供多个用户使用。
最佳答案
您说得对，这样的工作负载需要一些特殊的优化。
您可以使用现成的搜索引擎，例如 Apache lucene或Solr (这是 lucene 的 REST API 包装器)
该引擎针对全文搜索进行了优化，并且可以使用私有(private)数据。
工作步骤:
- 安装 solr(或 lucene)
- 用于存储信息的设计架构(您需要哪些字段和哪些类型的搜索)
- 将数据加载到其中(通过 bach 操作或更新)
- 基于 solrs 查询语言的查询搜索(类似于 google 搜索)。 在这里，除了原始用户查询之外，您还可以添加基于 user_id 或任何 over 参数的特殊限制。因此私有(private)数据不会在用户之间造成困惑。
关于javascript - 自动完成性能和私有(private) "magic search"，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/25414620/