jptx
2 天前
您好，我们团队深入使用 Manticore Search ，从 Sphinx 一直追到 Manticore Search 。我们觉得 Manticore Search 的搜索功能还是值得称赞的，速度快，而且搜索时占用的 CPU 和内存相比同类产品更小（这一点是 Manticore Search 相比其他产品最重要的特点）。
但我们从几个月前开始使用数据统计分析功能，发现分布式部署的场景下很多统计函数存在较为严重的 bug ，例如：select a, count(*) as c from my_table group by a order by c desc limit 10; 在很多场景下查出来的数据是错的，结果中 a 列的排名是错的，c 的数据也错。
此类问题我们发现了很多，尝试了最新版本，也存在这些问题。我们通过研究 Manticore Search 的源码，很多问题都有初步的定位，我们也想修改源码改进 Manticore Search ，但是很多问题涉及到的修改点太多了，我们很难评估某处改动是否会影响到其他功能。我们有很多可以复现问题的环境，但由于这些用例涉及到公司内部功能设计，不能公开到互联网上，而且由于涉及到的问题太多，难以设计出最小可复现的独立用例。请问是否有较为私密的反馈通道而不是 Github Issue ，或者是否有某位开发人员和我们在线上交流下，我们反馈一下我们发现的问题。
这里回答一下您要收集的问题：
1. 您使用哪款 Manticore 产品？
Manticore Search ；
尝试过 Manticore Columnar Library 但我们很多查询语句都是 select * ，性能不太行，于是放弃。
2. 你觉得 Manticore 产品好用的地方是啥 哪些方面/功能满意？
全文索引检索起来对 CPU 和内存压力比同类产品小很多，很适合低配置的硬件环境。
3. 您觉得缺少了啥功能？
对我们而言，最重要的问题是和 MySQL 相比缺少了很多聚合函数；
4. 您最希望改进哪些功能？
存储空间占用较大，我们在去年也测试过列式存储，压缩效果也比不上 ClickHouse 。
写入数据创建索引时占用的 CPU 太高，建议改进。我们每秒有大约 15 万条数据写入到单机的 Manticore Search ，indexer 进程的 CPU 占用甚至比 ClickHouse 的都高。
5. 您的整体使用体验怎么样？ 打个分 最好写出依据？
7 分（满分 10 分），Manticore Search 的全文索引做的很不错，而且部署时占用的 CPU 和内存相比同类产品很低（尤其是相比 ElasticSearch ），但统计功能真的很一般，功能丰富程度甚至不如 MySQL 5.5
6. 您咋找到的 Manticore ？
我们从 Sphinx 一路追随过来的，在我加入团队的时候已经在使用 Manticore Search 了，已经不知道当初是谁找到 Sphinx 的了。