BanyanDB 0.11.0 发布，本次更新聚焦于提高性能、简化运维流程还有 者体验。其中最关键的改动是 - 它改变了传统滚动升级顺序并可能导致短暂服务中断； - 所有均需迁移到 Property 模式，这对长期依赖 Etcd 的使用者来说是一次必经痛点。下面内容按功能模块拆解，并在每处主要提醒潜在风险与方法。以方便你评估与准备升级计划。

向量化查询已默认开启——升级顺序要注意！

BanyanDB 从 Measure 开始就已经采用列式批处理，但此版本将 Stream 与 Trace 同步加入向量化方法，并把三者相关命令行开关默认为 true. 成效显著：扫描密集型工作负载内存使用下降≈30%。但也带来了以下痛点:

• Liaison → Data 顺序反转: • 原先建议先升级 Data 再升 Liaison，现在必须相反。• 若未遵守，将导致所有跨节点请求返回“Frame 解码失败”，服务不可用。• 建议通过脚本手动控制升级顺序或临时禁用向量化选项：

  -stream-vectorized-enabled=false
  -trace-vectorized-enabled=false
  -measure-vectorized-enabled=false
  

• No 数据迁移: • 切换仅影响网络传输格式，无磁盘结构变化。• 可以随时回滚到旧方法，只需把上述三条开关设为 false 即可。• 若业务需要保持连续可视性，请提前准备好回滚脚本以减少停机时间。
• {单机部署无影响} vs {分布式部署需严格遵守}: • 单机模式下只有一个 Data 节点，不涉及 Frame/Protobuf 切换。• 分布式模式下务必确认所有 Liaison 已完成新版本启动后再启动新的 Data 节点，否则整个程序会出现死锁般的“无法解析响应”情况。其实，

  请在正式环境中先做一次灰度测试。以验证节点间通信是否正常，再逐步推广至生产环境。

  ---

  常见问答 – 向量化方法

  问题	回答
  是否必须调整自动升级顺序？	是为确保正常通信，需要先升 Liaison 再升 Data。 如果无法手动控制，请临时关闭向量化选项直至 Liaison 完成更新后再开启。
  向量化方法正确性如何保证？按理说，	Measure 方法经过数十小时持续跑测。一致性比较符合 Protobuf 原始输出；若遇差异，可立即切回非向量模式，无需重新导入数据。

  ---

  Trace 后采样流水线——插件环境完善且内存受控 *

  BanyanDB 在落盘后执行 Trace 合并时引入了可插拔的采样器链。每个 Group 都可以动态注册自己的 .so 插件，实现更加精准的数据保留决策。引入了 Drop‑Set 上限机制。有效抑制单次合并产生的大规模堆内存峰值，从而降低程序整体峰值压力。若你使用 SkyWalking 或 Zipkin。可直接使用官方提供的 sw‑trace‑sampler.so / zipkin‑trace‑sampler.so 两个插件，无需自行编译。**主要改动概览**：

  • 插件注册 – 可通过 REST 接口动态添加、更新或删除采样器链。
  • Drop Set 上限 – 内部采用 “limit/” 限制，每次合并最多保留固定数量链路；超出部分将被直接保留以免漏失关键日志。
  • 延迟解码调整 – 对字符串与 Tag 做零拷贝处理，使 SkyWalking / Zipkin 的决策成本减半。

  这些改动让你可以根据业务需要灵活决定哪些 Trace 保留，而不会因单次合并导致 OOM 或磁盘膨胀。

  ---

  集群级 Schema 一致性屏障 — 防止过期或缺失 Schema 的痛点消失 *