A Resource-centric Analysis and Optimization of NoSQL Workloads using Distressed Resource Volume Metric
Gunika Verma, Aashutosh A, Pooja Srinivas, Yogesh Simmhan, Ayush Choure, Harshit Shah, Mayukh Das, Prashant Sasatte, Chetan Bansal, Abhijit Pai, Suraj Dixit, Achint Agrawal
cs.DC, cs.DB, eess.SY
2026-08-10
微软用 Luna 分位数预测驱动 Orbit 重排 Cosmos DB 副本,相对现网 SA,6 天 10 mERU 档多送 18B RU,迁移从 3.4 万降到 47,节点可砍 35%。
Azure Cosmos DB 跑在 60 多个数据中心、数十万节点上,托管数千万个分片副本。每个分片通常 4 个副本:1 个主副本只吃第一跳写、不接读;3 个从副本扛全部读和转发写。副本是放到 VM 上的最小调度单位,资源按 Requested Unit(RU,计费和配额用的无量纲复合指标)计量,1 RU 大约撑住每秒一次键值查找。
现网负载均衡走 Azure Service Fabric 的 Simulated Annealing:节点越界,或者 max/min「能量比」跨过阈值,就在时限内搜邻域,一次并行迁几百个副本。CPU 卡 80% 这类全局约束挡不住尾部错误。论文在 213 节点上把负载打到每节点 6.3M RU,5 分钟采样:RU 不超过 3.46M 时错误率远低于 0.001%,对应五九可用性;再往上第四档有 1.2% 的样本越过 0.001%,最高档 39.6% 越线。三个真实集群里都有节点顶着超过 3M RU,平均密度却并不高。不均才会把错误堆到长尾。
轨迹来自北美数据中心,覆盖 LLM 基础设施、电商、金融和企业办公,已脱敏。三簇节点都是同构 VM,内存上限 380GB、存储 5.2TB:
| 集群 | 天数 | 节点 | 副本 | 峰值 RU |
| C1a | 60 | 196 | 约 3.2 万 | 3.7M |
| C1b | 13 | 196 | 35408 | 3.7M |
| C2 | 54 | 196 | 31207 | 4.3M |
| C3 | 54 | 190 | 42876 | 8.5M |
C1a 和 C1b 是同一簇不同时段,C1b 短,拿来做消融和训练测试切分。
Distressed Resource Volume(DRV)不数总错误。系统这么大,稳态也会冒错误码。DRV 先算 ERU(Errors per RU,单位负载上的错误),再按 ERU 分箱,记录每一箱里真正送到用户手里的 RU。剖面曲线下面积等于总交付量;好策略把面积堆到低错误一侧。
LoadStar 是开源策略模拟器。它把历史日志洗成「时刻-副本-节点-资源-错误」,跑候选 Packing and Migration(PAM)策略,再用非参数模型从节点 RU 估 ERU。RU 按分位数切成 2000 箱,箱内变异够就 Kernel Density Estimation,稀疏就按频率 bootstrap。C1a 均值 0.0069 对预测 0.0068,C1b 是 0.0086 对 0.0087;l2 RMS 分别是 0.1138 和 0.1254,高 ERU 边界会偏。论文把溢出箱做成无上界,SLA 失败档内部差多少不再细分。
调度分成预测和放置两段。
Luna(Load Utilization prediction for NoSQL workload Analytics)用 LightGBM 分位数回归,预测副本在 30 分钟块上的峰值负载。Whittaker-Eilers 平滑去噪,特征是星期、小时、分钟、多窗口滚动统计,再加偏度和峰度。C1b 上 6 天训练、6 天测试,Pinball Loss 全面低于 ARIMA 和指数平滑:中位数分位 Luna 1420,ARIMA 2531,ETS 2968;0.001 分位从 3069/3751 降到 58。覆盖偏差显示模型系统性高估负载,宁可空一点容量,也不把节点打满。
Orbit 三步:
主对比在 C1b 的 6 天,对照现网 SA,以及用 Google OR-Tools 做的多维 worst-fit 在线装箱(WFO)。Orbit 超参:α=4、2 小时、P50。
节点均匀性用 P80/P20,即第 80 百分位节点利用率除以第 20 百分位。完美均匀是 1.0。Orbit 在四类资源上的中位 P80/P20 落在 1.34-1.73,小提琴比 WFO 更窄,SA 最散。C2、C3 上 Orbit 中位比是 1.33-1.69 和 1.34-1.64;WFO 在这两簇算到以天计,没跑完。
| 策略 | 10 mERU 档交付 RU | 6 天迁移次数 | 单次峰值迁移 |
| Orbit | 163B | 47 | 7 |
| SA | 145B | 3.4 万 | 1.87 万 |
| WFO | 137B | 1.93 万 | 1.93 万(一次全重装) |
总负载相同,低错误档多出来的 RU 就是从高错误档挪过来的。WFO 在 5 分钟窗口进来不到 500 个副本要 30-60 秒,3000+ 要 5-8 分钟,全重装接近 1 小时,线上来不及。Orbit 单次决策 30 秒以内,而且靠预测提前数十分钟到数小时。
把 C1b 节点从 100% 按 5% 往下砍到 65%,再低就放不下副本。65% 时 RU 的 P80/P20 从 1.73 降到 1.60;10 mERU 档 151.2B 对 147.5B,100 mERU 档 1.47B 对 1.65B。论文据此写最多少 35% 资源。策略已进生产,声称每年能省上亿美元量级。
消融:α 在 1.0-4.0 的 DRV 接近,0.1 和 10 变差。预测窗口设成 0 小时(不预测),前几天均匀性差几个数量级;0.5-24 小时差别不大,默认 2 小时。分位 P10、P90 会引出上千次迁移,P25 和 P50 最少,默认 P50。
给云数据库调度的人,这是一套能复用的评测管线:真实 NoSQL 轨迹、面向错误的 DRV、能从 RU 映射到用户侧错误的模拟器。过去公开的是 VM、Hadoop、GPU 轨迹,NoSQL 库轨迹停在十年前,而且几乎不带错误码。
对已经定好分片和副本因子、只在簇内搬副本的托管库,收益很具体:同样 SLA 下少 35% 机器,迁移从万级掉到几十。Luna 不是端到端深度模型,LightGBM 加分位数就够驱动放置。没有预测的 Orbit 会垮,有 30 分钟前瞻就已经够用。
放置启发式是 worst-fit 加 skew,预测是 GBDT,工程价值大于方法新颖性。开源轨迹和 LoadStar 对外部研究者更值钱,因为生产数字外人无法复核。
论文没有独立的局限节。作者自己写了几条:LoadStar 的 l1 和 l2 差得大,高 ERU 边界估不准;Luna 系统性高估;超参只在 C1b 上扫,再拿到 C2、C3;WFO 在大簇上跑不完,对照不完整。未来工作提到要在别的 NoSQL 和云轨迹上验证,并处理迁移本身的冲击、动态修正预测高估。
实验是模拟器回放,不是在线 A/B。DRV 的错误率来自按历史 RU-ERU 关系采样,换了放置之后错误生成机制是否仍成立,没有独立验证。节点同构、调度不出簇、分区方案给定,跟多规格机型或跨可用区搬迁不是同一道题。年省上亿美元写在摘要里是 potential,引言写成已经部署的节省,口径并不一致,外部无法核对。负载只来自北美三个簇。