私有搜索引擎服务的必要性及其价值

其中有一个很大的价值就是：

把模糊查询变为精确查询，即可以在用户界面层面，就将用户的模糊输入，变为面向核心数据系统的精确查询。

实际上，首先是由于核心数据系统对模糊查询的支持不是很友好而造成大量模糊查询的体验非常糟糕。也同时由于搜索引擎的实现和接入成本较高，也更加加剧了这种不好体验的蔓延。

如果在用户界面即给予用户以及时反馈，用户既能作出合理决策，也能合理设计数据系统，分担核心数据系统的压力，让擅长的系统执行擅长的任务。

一，输入即反馈，默认选择第一个，回车即可查询。

二，光标持续保持，保证连续多次查询的连贯性体验。

三，如果是鼠标选择其它提示条目，则以所选择的条目进行查询，并予以保持。 但当输入改变，则继续以第一条逻辑执行，回到默认状态。

（但是 focus 不一定可以，需要确认。）

以及：

将原来需要等到未知结果列表的查询，改为两阶段查询，第一阶段定位到精确查询需要的 ID，第二阶段使用精确查询的单条数据进行返回，这两个阶段可以分别由用户触发，或者自动触发。

由于第一阶段如果数据量很小可以极其地快，第二阶段由于可以利用缓存也可以很快（冷数据可能稍微慢一些些～）

如果是自动触发，第二阶段可以使用 debounce 机制延迟对核心数据库的请求，以及同时支持他进行主动请求的提交。

如果，需求不是返回单条数据，而是需要一个列表，那么，提交 IDs 即可，这也还是由模糊查询得到的列表而进行中转，行为机制也是一样的。

以此，或许可以成为一个组件，通过两个接口进行支持以实现这两个阶段的动作。

哪怕是列表需求，也是可以走缓存，100 次缓存可以同比一次核心数据库查询，以及用得越多，后续响应越快。

还有，如果是需要状态筛选，也可以把枚举状态值改为对应的文本存入搜索引擎，从而支持简单的筛选目的，但是缺陷在于它可能不是很会满足需求。

如果是精确筛选需求，可以考虑纳入高级查询去，走缓存过滤或者走数据库查询，这都是可以的。当然，这些处理逻辑目的都是为了获取 Top n 的少量数据，极致化地提升用户体验，大列表查询不在本方案内。

以上是一直以来有过设想的一个对私有化搜索引擎的使用方案，今日在路上得以快速记录下来，稍作整理并发布，作为备忘参考。

此设想认为可以实现的前提是：当前私有化搜索引擎的实现与接入成本正在极速地降低。