解决方法:
几年前我在大型数据集上运行基准测试,发现：
> MySQL FULLTEXT
很慢.另一个缺点是它强迫MyISAM对你造成很多问题.一旦索引达到一定大小,索引更新也会非常慢：当您插入新行时,会重新生成索引的大部分内容,有时会为了插入论坛帖子而重写几百兆的索引.换句话说,对于一个有几MB帖子的小型论坛来说没问题,但维基百科没有使用它的原因……
> Postgresql全文
比MysqL全文快10-100倍,功能强大得多,插入/更新的要点很快,锁没有问题,换句话说,它是一个完全不错的解决方案.
但是,由于MVCC,当数据集大于RAM时搜索速度变慢,postgres需要通过命中堆来检查行的可见性.请注意,这可能会在将来的版本中更改.如果您的查询返回10行,没问题.但是,如果要SELECT WHERE(全文查询)ORDER BY date LIMIT 10并且fulltext匹配10.000行,则可能会变得非常慢.仍然比MysqL快,但不是你想要的性能.
> Xapian：我测试了这个,还有Lucene和Sphinx,它们都有良好的声誉.
Xapian不必遵循与数据库相同的限制,因此它可以进行更多的优化.例如,它是单作者多读者并发模型,因此您需要某种更新队列来在后台更新索引.它也有自己的磁盘格式.结果是,即使数据集比RAM大得多,它也非常快,特别是在匹配大量行,排序和返回最相关的复杂查询时.
该索引也很庞大,它可能包含许多重复的东西.结果是它不需要寻找检索的东西.
基本上,一旦Postgres开始进入IO寻求墙,MysqL就已经死了,而且Xapian一直在快速发展.
但它并没有很好地集成在数据库中,因此使用起来更多.只有拥有庞大的数据集才值得.如果这是你的情况,试试吧,这太棒了.如果你的数据集适合RAM,那么postgres只会减少麻烦.此外,如果您想要结合全文和数据库查询,那么集成变得非常重要.
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 [email protected] 举报，一经查实，本站将立刻删除。
