有什么理由不在Heroku上使用PostgreSQL的内置全文搜索？

Question

我准备在Heroku上部署一个需要全文搜索的Rails应用程序.到目前为止,我一直在使用MySQL与Sphinx的VPS上运行它.

但是,如果我想在Heroku上使用Sphinx或Solr,我需要支付附加费用.

我注意到PostgreSQL(Heroku上使用的数据库)具有内置的全文搜索功能.

有没有理由我不能使用Postgres的全文搜索？它比Sphinx慢还是有其他一些主要限制？

Answer 1

编辑,2016年 - 为什么不两个？

如果你对Postgres和Lucene感兴趣,为什么不两个？查看Postgres 的ZomboDB扩展,它将Elasticsearch集成为一流的索引类型.仍然是一个相当早的项目,但它看起来真的很有希望.

• https://github.com/zombodb/zombodb

(技术上没有在Heroku上提供,但仍然值得一看.)

披露:我是Websolr和Bonsai Heroku附加组件的联合创始人,所以我的观点有点偏向于Lucene.

我对Postgres全文搜索的看法是,它对于简单的用例非常可靠,但是Lucene(以及Solr和ElasticSearch)在性能和功能方面都有优势的原因有很多.

对于初学者来说,jpountz提供了一个真正优秀的技术答案,为什么Solr比Postgres快得多？值得一些读取来真正消化.

我还评论了最近的RailsCast情节,比较了Postgres全文搜索与Solr的相对优缺点.让我回顾一下:

Postgres的实用优势

• 重新使用您已经运行的现有服务,而不是设置和维护(或支付)其他内容.
• 远远超过了速度极慢的SQL LIKE运算符.
• 减少数据同步的麻烦,因为它们都在同一个数据库中 - 没有与某些外部数据服务API的应用程序级集成.

Solr(或ElasticSearch)的优点

在我的头顶,没有特别的顺序......

• 与常规数据库负载分开扩展索引和搜索负载.
• 更灵活的术语分析,​​如口音正常化,语言词干化,N-gram,标记删除......其他很酷的功能,如拼写检查,"丰富内容"(例如,PDF和Word)提取......
• Solr/Lucene可以在Postgres全文搜索TODO列表上完成所有工作.
• 更好更快的术语相关性排名,可在搜索时有效定制.
• 常见术语或复杂查询的搜索性能可能更快.
• 可能比Postgres更有效的索引性能.
• 通过将索引与主数据存储区分离,可以更好地容忍数据模型的更改

显然,我认为基于Lucene的专用搜索引擎是更好的选择.基本上,您可以将Lucene视为搜索专业知识的事实上的开源存储库.

但如果您唯一的其他选择是LIKE运营商,那么Postgres全文搜索就是一个明确的胜利.

Answer 2

由于我刚刚完成了将弹性搜索(1.9)与postgres FTS进行比较的努力,我认为我应该分享我的结果,因为它们比@gustavodiazjaimes引用的更新.

我对postgres的主要关注是它没有内置的faceing,但是自己构建起来很简单,这是我的例子(在django中):

results = YourModel.objects.filter(vector_search=query)
facets = (results
    .values('book')
    .annotate(total=Count('book'))
    .order_by('book'))

我正在使用postgres 9.6和elastic-search 1.9(通过django上的haystack).这是在16种不同类型的查询中弹性搜索和postgres之间的比较.

    es_times  pg_times  es_times_faceted  pg_times_faceted
0   0.065972  0.000543          0.015538          0.037876
1   0.000292  0.000233          0.005865          0.007130
2   0.000257  0.000229          0.005203          0.002168
3   0.000247  0.000161          0.003052          0.001299
4   0.000276  0.000150          0.002647          0.001167
5   0.000245  0.000151          0.005098          0.001512
6   0.000251  0.000155          0.005317          0.002550
7   0.000331  0.000163          0.005635          0.002202
8   0.000268  0.000168          0.006469          0.002408
9   0.000290  0.000236          0.006167          0.002398
10  0.000364  0.000224          0.005755          0.001846
11  0.000264  0.000182          0.005153          0.001667
12  0.000287  0.000153          0.010218          0.001769
13  0.000264  0.000231          0.005309          0.001586
14  0.000257  0.000195          0.004813          0.001562
15  0.000248  0.000174          0.032146          0.002246
                  count      mean       std       min       25%       50%       75%       max
es_times           16.0  0.004382  0.016424  0.000245  0.000255  0.000266  0.000291  0.065972
pg_times           16.0  0.000209  0.000095  0.000150  0.000160  0.000178  0.000229  0.000543
es_times_faceted   16.0  0.007774  0.007150  0.002647  0.005139  0.005476  0.006242  0.032146
pg_times_faceted   16.0  0.004462  0.009015  0.001167  0.001580  0.002007  0.002400  0.037876

为了让postgres达到分面搜索的速度,我不得不在字段上使用带有SearchVectorField的GIN索引,这是django特定的,但我确信其他框架具有类似的矢量类型.

另一个考虑因素是pg 9.6现在支持短语匹配,这是巨大的.

我带走的是,postgres对于大多数情况来说是优先的,因为它提供:

1. 更简单的堆栈
2. 没有搜索后端api包装器依赖性(思考 - sphinx,django-sphinx,haystack等).这些可能会拖累,因为它们可能不支持您的搜索后端所执行的功能(例如,haystack faceting/aggregates).
3. 具有相似的性能和功能(根据我的需要)

Answer 3

我找到了这个惊人的比较,并希望分享它:

PostgreSQL中的全文搜索

构建索引的时间LIKE谓词 - 无
PostgreSQL/GIN - 40分钟
Sphinx搜索 - 6分钟
Apache Lucene - 9分钟
倒置索引 - 高

索引存储LIKE谓词 - 无
PostgreSQL/GIN - 532 MB
Sphinx搜索 - 533 MB
Apache Lucene - 1071 MB
倒置索引 - 101 MB

查询速度LIKE谓词 - 90+秒
PostgreSQL/GIN - 20 ms
Sphinx搜索 - 8 ms
Apache Lucene - 80 ms
倒置索引 - 40 ms