Manticore团队很高兴地宣布 Manticore Search版本4.2.0 。此次发布的新内容:
主要新特性
- 实时索引和全文查询的伪分片支持。在之前的版本中,我们添加了有限的伪分片支持。从这个版本开始,您可以通过启用
searchd.pseudo_sharding
来获得伪分片和多核处理器的所有好处。最酷的是,您不需要对索引或查询做任何事情,只需启用它,如果您有空闲的CPU,它将被用来降低响应时间。它支持用于全文、过滤和分析查询的普通和实时索引。例如,启用伪分片可以使大多数查询的平均响应时间降低约10倍,在
Hacker news策划的评论数据集
中乘以100倍(116百万文档在普通索引中)。

- ** Debian Bullseye **现在得到支持。
- PQ事务现在是原子和隔离的。之前PQ事务的支持是有限的。它使得更快的REPLACE到PQ成为可能,特别是当您需要一次替换大量规则时。性能细节:
之前的版本4.0.2
插入1M PQ规则需要48秒,并且在10K批次中仅替换40K需要406秒。
root@perf3 ~ # mysql -P9306 -h0 -e "drop table if exists pq; create table pq (f text, f2 text, j json, s string) type='percolate';"; date; for m in `seq 1 1000`; do (echo -n "insert into pq (id,query,filters,tags) values "; for n in `seq 1 1000`; do echo -n "(0,'@f (cat | ( angry dog ) | (cute mouse)) @f2 def', 'j.json.language=\"en\"', '{\"tag1\":\"tag1\",\"tag2\":\"tag2\"}')"; [ $n != 1000 ] && echo -n ","; done; echo ";")|mysql -P9306 -h0; done; date; mysql -P9306 -h0 -e "select count(*) from pq"
Wed Dec 22 10:24:30 AM CET 2021
Wed Dec 22 10:25:18 AM CET 2021
+----------+
| count(*) |
+----------+
| 1000000 |
+----------+
root@perf3 ~ # date; (echo "begin;"; for offset in `seq 0 10000 30000`; do n=0; echo "replace into pq (id,query,filters,tags) values "; for id in `mysql -P9306 -h0 -NB -e "select id from pq limit $offset, 10000 option max_matches=1000000"`; do echo "($id,'@f (tiger | ( angry bear ) | (cute panda)) @f2 def', 'j.json.language=\"de\"', '{\"tag1\":\"tag1\",\"tag2\":\"tag2\"}')"; n=$((n+1)); [ $n != 10000 ] && echo -n ","; done; echo ";"; done; echo "commit;") > /tmp/replace.sql; date
Wed Dec 22 10:26:23 AM CET 2021
Wed Dec 22 10:26:27 AM CET 2021
root@perf3 ~ # time mysql -P9306 -h0 < /tmp/replace.sql
real 6m46.195s
user 0m0.035s
sys 0m0.008s
新版本4.2.0
插入1M PQ规则需要34秒,并且在10K批次中替换它们需要23秒。
root@perf3 ~ # mysql -P9306 -h0 -e "drop table if exists pq; create table pq (f text, f2 text, j json, s string) type='percolate';"; date; for m in `seq 1 1000`; do (echo -n "insert into pq (id,query,filters,tags) values "; for n in `seq 1 1000`; do echo -n "(0,'@f (cat | ( angry dog ) | (cute mouse)) @f2 def', 'j.json.language=\"en\"', '{\"tag1\":\"tag1\",\"tag2\":\"tag2\"}')"; [ $n != 1000 ] && echo -n ","; done; echo ";")|mysql -P9306 -h0; done; date; mysql -P9306 -h0 -e "select count(*) from pq"
Wed Dec 22 10:06:38 AM CET 2021
Wed Dec 22 10:07:12 AM CET 2021
+----------+
| count(*) |
+----------+
| 1000000 |
+----------+
root@perf3 ~ # date; (echo "begin;"; for offset in `seq 0 10000 990000`; do n=0; echo "replace into pq (id,query,filters,tags) values "; for id in `mysql -P9306 -h0 -NB -e "select id from pq limit $offset, 10000 option max_matches=1000000"`; do echo "($id,'@f (tiger | ( angry bear ) | (cute panda)) @f2 def', 'j.json.language=\"de\"', '{\"tag1\":\"tag1\",\"tag2\":\"tag2\"}')"; n=$((n+1)); [ $n != 10000 ] && echo -n ","; done; echo ";"; done; echo "commit;") > /tmp/replace.sql; date
Wed Dec 22 10:12:31 AM CET 2021
Wed Dec 22 10:14:00 AM CET 2021
root@perf3 ~ # time mysql -P9306 -h0 < /tmp/replace.sql
real 0m23.248s
user 0m0.891s
sys 0m0.047s
次要更改
- optimize_cutoff
现在作为配置选项在
searchd部分中可用。当您想要在所有索引中将RT块的数量限制为特定数字时,它非常有用。 - Commit 00874743 准确的 count(distinct ...) 和 FACET ... distinct 在几个具有相同字段设置/顺序的本地物理索引(实时/普通)上。
- PR #598
bigint支持
YEAR()和其他时间戳函数。 - Commit 8e85d4bc
自适应
rt_mem_limit
。之前,Manticore Search在将新磁盘块保存到磁盘之前会收集恰好达到
rt_mem_limit的数据,而在保存时仍会收集多达10%(即双缓冲)以最小化可能的插入暂停。如果该限制也被耗尽,则添加新文档会被阻止,直到磁盘块完全保存到磁盘。新的自适应限制是基于我们现在有 auto-optimize 的事实,因此如果磁盘块没有完全遵守rt_mem_limit并开始提前刷新磁盘块,这并不是大问题。因此,现在我们收集最多50%的rt_mem_limit并将其保存为磁盘块。在保存时,我们查看统计信息(我们保存了多少,新文档在保存时到达了多少)并重新计算下次将使用的初始速率。例如,如果我们保存了9000万文档,而在保存时又有1000万文档到达,速率为90%,因此我们知道下次可以在开始刷新另一个磁盘块之前收集最多90%的rt_mem_limit。速率值自动计算,从33.3%到95%不等。 - Issue #628 unpack_zlib 用于PostgreSQL源。感谢, Dmitry Voronin 的 贡献 。
- Commit 6d54cf2b
indexer -v和--version。之前您仍然可以看到索引器的版本,但不支持-v/--version。 - Issue #662 默认情况下,当Manticore通过systemd启动时,mlock限制为无限。
- Commit 63c8cd05 spinlock -> op队列用于coro rwlock。
- Commit 41130ce3
环境变量
MANTICORE_TRACK_RT_ERRORS用于调试RT段损坏。
破坏性更改
- Binlog版本已增加,之前版本的binlog将无法重放,因此请确保在升级期间干净地停止Manticore Search:停止之前的实例后,
/var/lib/manticore/binlog/中不应有binlog文件,除了binlog.meta。 - Commit 3f659f36
show threads option format=all中的新列“chain”。它显示某些任务信息票据的堆栈,对于分析需求非常有用,因此如果您正在解析show threads输出,请注意新列。 searchd.workers自3.5.0以来已被废弃,现在已被弃用,如果您仍在配置文件中有它,启动时将触发警告。Manticore Search将启动,但会有警告。
Bugfixes
- ❗ Issue #650 Manticore 4.0.2 比 Manticore 3.6.3 慢。4.0.2 在批量插入方面比之前的版本快,但在单个文档插入方面明显较慢。这个问题在 4.2.0 中已修复。
- ❗ Commit 22f4141b RT 索引在高强度 REPLACE 负载下可能会损坏,或者可能会崩溃
- Commit 03be91e4 修复了合并分组器和组 N 排序器时的平均值;修复了聚合的合并
- Commit 2ea575d3
indextool --check可能会崩溃 - Commit 7ec76d4a 由于 UPDATE 导致的 RAM 耗尽问题
- Commit 658a727e 守护进程在 INSERT 时可能会挂起
- Commit 46e42b9b 守护进程在关闭时可能会挂起
- Commit f8d7d517 守护进程在关闭时可能会崩溃
- Commit 733accf1 守护进程在崩溃时可能会挂起
- Commit f7f8bd8c 守护进程在启动时尝试重新加入集群时可能会崩溃,原因是节点列表无效
- Commit 14015561 在 RT 模式下,如果无法在启动时解析其代理之一,分布式索引可能会被完全遗忘
- Issue #683 attr bit(N) engine='columnar' 失败
- Issue #682 创建表失败,但留下目录
- Issue #663 配置失败,错误信息:未知键名 'attr_update_reserve'
- Issue #632 Manticore 在批量查询时崩溃
- Issue #679 批量查询在 v4.0.3 中再次导致崩溃
- Commit f7f8bd8c 修复了守护进程在启动时尝试重新加入集群时因节点列表无效而崩溃的问题
- Issue #643 Manticore 4.0.2 在批量插入后不接受连接
- Issue #635 带有 ORDER BY JSON.field 或字符串属性的 FACET 查询可能会崩溃
- Issue #634 查询时出现 SIGSEGV 崩溃,原因是 packedfactors
