Postgres的全文搜索已经足够好了

关于MySQL和RDS（远程数据服务）

这在Postgres RDS上能运行吗？

上面所有的示例在RDS上都是可以运行的。 据我所知，RDS搜索特性中唯一的限制是搜索某些数据时需要访问文件系统，如自定义字典，拼写检查程序，同义词，主题词表。 相关信息见亚马逊aws论坛。

我使用的是MYSQL数据库，我可以使用内置的全文本搜索功能吗？

如果是我，我不会去用这个功能。 无需争论，MySQL的全文本搜索功能非常局限。 默认情况，它不支持任何语言的词干提取功能。 我偶然发现一个可以安装的词干提取的函数，但是MYSQL不支持基于索引的函数。

那么你可以做些什么？ 鉴于我们上面的讨论，如果 Postgres能够胜任你使用的各个场景，那么考虑下把数据库换为 Postgres。 数据库迁移工作可以通过工具如 py-mysql2pgsql方便地完成。 或者你可以研究一下更高级的解决方案如 SOLR（基于 Lucene的全文搜索服务器）和 Elasticsearch（基于 Lucene的开源、分布式、 RESTful搜索引擎）。

总结

我们已经了解了基于一个特殊的文档如何构建一个性能良好且支持多语言的文本搜索引擎。 这篇文章只是一个概述，但是它已经给你提供了足够的背景知识和示例，这样你可以开始构建自己的搜索引擎。 在这篇文章中，我也许犯了一些错误，如果你能把错误信息发送到blog@lostpropertyhq.com，我将感激不尽。

Postgres的全文本搜索特性非常好，而且搜索速度足够快。 这可以使你的应用中的数据不断增长，而无需依赖其它工具进行处理。 Postgres的搜索功能是银弹吗？ 如果你的核心业务围绕搜索进行，它可能不是的。

它移除了一些特性，但是在大部分场景中你不会用到这些特性。 毫无疑问，你需要认真分析和理解你的需求来决定使用哪种搜索方式。

就我个人而言，我希望Postgres全文本搜索功能继续改善，并新增下面的一些特性：

• 额外的内置语言支持： 汉语，日语...

• 围绕Lucene的外国数据包装程序。 在全文本搜索功能上，Lucene仍然是最优秀的工具，把它集成到Postgres中会有很多好处。

• 更多排名结果的提高或评分特性会是一流的。 Elasticsearch 和 SOLR已经提供了先进的解决方案。

• 进行模糊查询（tsquery）时不使用trigram的方式会非常棒。 Elasticsearch 提供了一种非常简单的方式来实现模糊搜索查询。

• 能够通过SQL动态创建和编辑如字典内容、同义词、主题词表的特性，而不再使用把文件添加到文件系统的方式。

Postgres 没有ElasticSearch 和 SOLR 那么先进，毕竟ElasticSearch 和 SOLR是专门进行全文本搜索的工具，而全文本搜索只是PostgresSQL一个比较优秀的特性。