mysql - 在全文搜索方面，Postgres 的性能比 MYSQL 高多少？

Question

我一直是 MYSQL 用户，从未尝试过 Postgres。

但是MYSQL在数据量很大的情况下，在全文检索上存在瓶颈。

Answer 1

几年前，我对大型数据集进行了基准测试，发现:

• MySQL 全文

速度很慢。另一个缺点是它会强制你使用 MyISAM，这会带来很多问题。一旦索引达到一定大小，索引更新也非常缓慢:当你插入一个新行时，索引的很大一部分会重新生成，有时几百兆字节的索引被重写只是为了插入一个论坛帖子。换句话说，对于一个只有几兆字节的帖子的小型论坛来说还可以，但维基百科不使用它是有原因的......

• PostgreSQL 全文

比 MySQL 全文快 10-100 倍，功能更强大，要点在插入/更新时速度很快，锁没有问题，换句话说，这是一个完全不错的解决方案。

但是，由于 MVCC，当数据集大于 RAM 时，搜索会变慢，postgres 需要通过访问堆来检查行的可见性。请注意，这可能会在未来的版本中发生变化。如果您的查询返回 10 行，没问题。但是，如果您想要 SELECT WHERE (fulltext query) ORDER BY date LIMIT 10 并且全文匹配 10.000 行，它会变得非常慢。仍然比 MySQL 快，但没有您想要的性能。

• Xapian:我测试过这个，还有Lucene和Sphinx，口碑都不错。

Xapian 不必遵守与数据库相同的限制，因此它可以进行更多的优化。例如，它是一个单写多读并发模型，因此您需要某种更新队列来在后台更新您的索引。它还具有自己的磁盘格式。结果是它非常快，即使数据集比 RAM 大得多，尤其是在匹配大量行、排序并仅返回最相关的行的复杂查询上。

索引也很大，可能包含很多重复的东西。结果是它不需要寻求检索内容。

基本上，一旦 Postgres 开始撞上 IO-seek 墙，MySQL 早就死了，而 Xapian 一直在快速发展。

但它并没有很好地集成到数据库中，因此使用起来比较麻烦。仅当您拥有庞大的数据集时才值得。如果这是您的情况，请尝试一下，这太棒了。如果您的数据集适合 RAM，那么 postgres 的工作就会少很多麻烦。此外，如果您想结合全文查询和数据库查询，那么集成就变得很重要。