全文本搜索是指将文本查询与存储在数据库中的文档进行部分或全部匹配。与传统的数据库查询相比，全文本搜索即使在部分匹配的情况下也能提供结果。它允许构建更灵活的用户搜索界面，从而使他们能够更快地找到准确的结果。

从简单的应用内搜索到浏览庞大的电子商务目录，全文本搜索用例非常多。它非常常见，以至于 Postgres 和其他关系型数据库都包含用于全文本搜索的专用 API。不幸的是，Postgres 在多个方面都逊于搜索专用数据库。

1. 复杂设置

为了提供相关结果，全文本搜索应容忍拼写错误，允许使用同义词，并允许部分匹配。此外，结果排名需要高度可定制，以适应企业的特定需求。在 Postgres 上配置全文本搜索需要全面的配置，并且通常需要在使用托管云服务时无法使用的扩展。

创建数据库索引、编写查询和排名算法很快就会超出领域知识，并且需要搜索、索引和语言学的专业知识。在处理旨在解决 Postgres 全文本搜索限制的混合扩展的约束时，优化性能变得更加困难。

相反，搜索专用数据库提供了最先进的功能，例如开箱即用的拼写错误容忍、前缀搜索、模糊匹配、同义词和可定制排名。

分面搜索允许用户通过广泛的类别细化搜索结果。它通常用于电子商务应用程序。例如，服装店可以通过品牌、尺码或评分范围等方面实施过滤。

Faceted search on an ecommerce website
电子商务网站上的分面搜索（查看演示)

对单个方面实施过滤已经足够棘手。但方面可以采取多种形式：类别标签、价格范围或最低评分。对所有类型实施过滤非常具有挑战性。最难实现的查询是聚合结果以构建方面计数。这对大型数据集来说非常资源密集。

使用 Postgres 实现分面搜索的复杂性随着方面数量的增加呈指数级增长。仅分面搜索就成为像Elasticsearch 或 Meilisearch这样的搜索引擎的强大卖点。它们提供了经过优化的、一流的 API 来处理方面过滤和计数。

3. 拼写错误容忍

默认情况下，Postgres 全文本搜索无法处理拼写错误。用户通常安装pg_trgm扩展来解决此限制。（同样，此解决方案并不总是可以在托管 Postgres 中使用。）此扩展主要引入了新的运算符来比较字符串之间的相似性，以及针对搜索优化的 GIN 和 GIST 索引。

新索引允许对全文本搜索进行更多配置，但选择 GIN 和 GIST 索引并不总是微不足道的。此外，新的运算符没有考虑词语的邻近性、空格分隔符或词语的大小。尤其是在此情况下，很难使用 Postgres 实现真正的模糊匹配。

理想情况下，搜索专用数据库应允许为单字查询和多字查询配置不同的规则。Meilisearch 就是这种情况，它允许完全禁用特定字段的拼写错误。这使用户能够通过唯一的标识符（如书籍的国际标准书号（ISBN））进行搜索。

Example of typo tolerance
ISBN 字段的拼写错误容忍已禁用（查看演示)

4. 语言支持

使用拉丁字母的语言与阿拉伯语或中文等其他语言之间的语言特殊性差异很大。截至 Postgres 15，全文本搜索词典在简体中文和繁体中文、韩语和日语等语言中不可用。这意味着要针对不同的语言采用特定的实现。

💡
要查看Postgres 全文本搜索支持的语言列表，可以在 Postgres 中运行\dFd命令。

语言支持约束在 Amazon RDS 等托管环境中被放大，用户无法访问文件系统。这种受限的访问权限阻止他们实现自定义词典、词干提取器、同义词等。

Meilisearch 提供了优化的语言支持，包括中文、日语、韩语、希伯来语等，以及所有使用空格分隔词语的语言。

🤩
由于其活跃的开源社区，Meilisearch 得益于母语人士对改进特定语言功能的贡献。

5. 支付后端费用

Postgres 是一个旨在与服务器端语言通信的数据库。在构建面向公众的客户端应用程序时，这意味着在数据库之上构建 API 来与客户端进行通信。除了额外的开发时间之外，创建这样的代理还带来了进一步的问题。

首先是延迟问题：向在返回结果之前查询数据库的 API 发出请求必然需要一些时间。这不会影响专用搜索引擎，因为它们提供了旨在向最终用户提供数据的公共 API。

现在第二个问题是安全问题。搜索引擎 API 从一开始就针对公开使用而设计。安全是为此用例而内置的。默认情况下，API 密钥会限制搜索请求，而高级功能（如租户令牌）可以实现多租户。

Example of tenant tokens usage
使用租户令牌限制对文档的访问（查看演示)

6. 扩展限制

将所有数据保存在单个数据库中有一个合理的动机。但将与搜索相关的数据保存在主数据库中会带来巨大的技术后果。对大型数据集进行全文本搜索查询在 Postgres 上会变得很昂贵，尤其是在对结果进行排名和计算方面计数时。

单体数据库通常会成为需要扩展的应用程序的瓶颈。当你可以避免时，不要为这个资源添加不必要的与搜索相关的成本。当使用高流量构建面向用户的应用程序时，这些成本只会成倍增加。

与关系型数据库不同，像Meilisearch 这样的全文本搜索引擎使用倒排索引。这种数据结构创建信息冗余，以允许更快的信息检索。它是为执行搜索操作而设计的，因此在大型数据集上会自然地优于关系型数据库。而且，当搜索使用量激增时，只需要扩展单个服务。

7. 相关性

如前所述，相关搜索需要拼写错误容忍、自定义排名和同义词。在现代应用程序中，用户希望结果在每次按键时更新，这需要前缀搜索。但 Postgres 全文本搜索ts_rank函数只允许属性加权。在使用pg_trgm扩展时，开发人员需要根据相似性自己实现排序。

在搜索专用数据库中，结果排名、属性优先级、匹配的词语数量和查询的准确性是一流的概念。它们匹配允许显式微调搜索行为的高级 API。这使得这些概念更容易被非技术人员、业务利益相关者使用。这是Bookshop 为其电子商务搜索选择 Meilisearch的主要原因之一。

8. 错过 InstantSearch 库

在搜索体验方面，网站和应用程序通常实现相同的用户界面模式：文本搜索栏、复选框方面列表、范围滑块、排序菜单、页面导航等。开源 InstantSearch 库提供了所有这些功能的实现形式，这些功能以小部件的形式通过 JavaScript、iOS 和 Android 中的 SDK 提供。

当上市时间至关重要时，很难错过这些便利。由 Algolia 支持的 InstantSearch 库享有广泛的采用率，并且许多搜索引擎数据库都提供了兼容 InstantSearch 的 API。阅读我们的 Nuxt 电子商务搜索指南，了解如何使用 Vue 实现 InstantSearch 小部件。

⚛️
更喜欢 React？阅读我们关于使用 InstantSearch 与 React的教程。

9. 云支持有限

在云时代，外包服务器的配置、维护和扩展是一种常见策略。团队可以将精力集中在为用户提供价值，而不是管理服务器。Postgres 与其他数据库一样，在广泛的云服务托管服务中都可用。不幸的是，托管服务通常会带来限制。

在 Postgres 的情况下，实现最先进的全文本搜索需要安装扩展。此外，微调语言词典和更多配置需要访问文件系统。不幸的是，这意味着许多功能在云环境中不可用。

为了支持基础设施的委托，搜索引擎通常提供了专用的云服务。这些定制平台不会妥协，并允许使用完整的搜索功能集。此外，客户还可以从针对其搜索用例量身定制的高级 SLA、支持和其他企业服务中受益。

Postgres 是一个很棒的、灵活的数据库，它允许实现许多自定义的、一体化的解决方案。其全文本搜索功能可能足以满足基本的搜索需求，但在涉及实时搜索和相关性问题时，它就力不从心了。这些限制在大型数据集上会变得更糟。这是很自然的，因为 Postgres 是一个数据库，而不是搜索引擎。

Meilisearch 是一个开源搜索引擎，用于构建快速且相关的搜索体验。它旨在为最终用户提供最先进的体验，同时提供简单直观的开发人员体验。你可以通过在本地运行 Meilisearch或创建Meilisearch Cloud 上的免费帐户来试用它。

详细了解 Meilisearch 如何为您的企业带来价值

与搜索专家交谈

有关 Meilisearch 的更多信息，你可以加入Discord上的社区或订阅时事通讯。你可以通过查看路线图和参与产品讨论来详细了解该产品。