在本文中，我记录了在 PostgreSQL（使用 Django ORM）和 ElasticSearch 中实现全文搜索 (FTS) 时的一些发现。
作为一名 Django 开发人员，我开始寻找可用的选项来在大约一百万行的标准大小上执行全文搜索。有两个值得尝试的选项：PostgreSQL 和 ElasticSearch。
在深入研究我的发现之前，让我们澄清一下全文搜索 (FTS)（或“搜索”）与数据库过滤器或查询之间的区别。“搜索”涉及从零开始，然后向其中添加结果。数据库过滤从一个集合开始，然后根据条件从中删除条目。过滤不适用于模糊输入，但可以使用模糊输入完成“搜索”。
PostgreSQL 全文搜索
我的大部分项目都使用 Django Web 框架和 PostgreSQL。PostgreSQL 从 2008 年开始支持全文搜索 (FTS)，Django 从 1.10 (2016) 开始通过 django.contrib.postgres 支持 FTS。因此，它是我集成的最快和最简单的选择。以下是我的一些发现：
这是一种更便宜、更快捷的选择，因为它不需要任何额外的设置和维护。
在我的本地（Razer Blade 2.4 GHz 6 Core i7）测试中，使用 GIN Index 的多达 500,000 条记录始终在大约 30 毫秒左右得到结果。在网上查看其他人所做的基准测试时，我发现它会在大约 30-50 毫秒内返回 150 万条记录的结果。
使用 Trigram 最多可以将其减慢 5 倍。
当前的 Django 集成不直接支持 Stemming 或 Fuzziness
ElasticSearch
ElasticSearch 是一个非常成熟的名称，有很多库可用于与 Django 和其他框架集成。以下是调查结果：
该技术仅针对搜索进行了优化，但设置和维护基础架构可能非常耗时。
自己设置需要专用的服务器或服务，这比 PostgreSQL 选项昂贵。
随着数据的增长进行扩展更易于管理，它支持所有搜索选项，例如 Trigram、EdgeGram、Stemming、Fuzziness
在我的本地（Razer Blade 2.4 GHz 6 Core i7）测试多达 500,000 条记录时，它始终在大约 25 毫秒内返回结果。在网上查看其他人所做的基准测试时，我发现它会在大约 5-30 毫秒内返回 150 万条记录的结果。
比较图
Postgresql vs ElasticSearch performance graph
结论
随着 PostgreSQL 的每个新版本，搜索响应时间都在改进，并且与 ElasticSearch 相比，它正在朝着苹果与苹果的比较前进。因此，如果项目不打算拥有数千万条记录或大规模数据，Postgresql 全文搜索将是最佳选择。
术语
- 词干提取：这是将单词简化为其根形式的过程，以确保该单词的变体在搜索过程中与结果匹配。例如，Referencing、Reference、References 可以归结为一个词 Refer 并且在搜索词时，refer 将返回具有该词的任何变体的结果。
- NGram：它就像一个在单词上移动的滑动窗口——一个连续的字符序列，直到指定长度。例如，术语 Refer 将变成 [R, RE, REF, E, EF, EFE, F, FE, FER]。NGram 可用于部分搜索单词，甚至从中间搜索单词。最常用的 NGram 类型是 Trigram 和 EdgeGram。
- 模糊性：模糊匹配允许您获得不完全匹配的结果。例如，搜索单词框也会返回包含 fox 的结果。常见应用包括拼写检查和垃圾邮件过滤。
