Manticore团队很高兴地宣布 Manticore Search版本4.2.0 。此次发布的新功能：
重大新功能
- 对实时索引和全文查询的伪分片支持。在之前的版本中，我们添加了有限的伪分片支持。从这一版本开始，您可以通过启用
searchd.pseudo_sharding
来获得伪分片和多核处理器的所有好处。最酷的是，您不需要对索引或查询做任何处理，只需启用它，如果您的CPU有空余，则会被用来降低响应时间。它支持实时和普通索引的全文、过滤和分析查询。例如，这里是启用伪分片可以使大多数查询的平均响应时间减少约10倍的示例，使用的是
Hacker news精选评论数据集
乘以100（在一个普通索引中的1亿16百万文档）。
- Debian Bullseye 现在得到了支持。
- PQ事务现在是原子性和隔离性的。之前PQ事务的支持是有限的。它使得REPLACE into PQ更快，特别是当您需要同时替换很多规则时。性能详情：
上一个版本 4.0.2
插入100万PQ规则需要48秒，在10K批次中REPLACE仅需要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
插入100万PQ规则需要34秒，在10K批次中REPLACE仅需要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 queue 用于 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 将启动，但会有警告。
错误修复
- ❗ 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 FACET 查询带有 ORDER BY JSON.field 或字符串属性可能会崩溃
- Issue #634 在查询带有 packedfactors 时发生崩溃 SIGSEGV