1、爱奇艺Key-Value数据库HiKV应用实践HiKV 是什么？爱奇艺基于Scylla开发的Key-Value数据库 Scylla:C+重写的Cassandra，高吞吐，低延时 HiKV:High Performance Key-Value Database 特点 大容量：单集群百TB数据量 高负载：单节点10w+QPS 低延时：读写延迟 P99HiKV同步工具，实现快速数据同步迁移100%运维自动化，监控全覆盖（延迟监控，拨测监控），50%告警实现自愈CB6.0调研阶段Ephemeral buckets多数据结构权限管理二级索引未来可期Couchbase易扩展，“数据量可用内存”时性能极高。

2、但是，存储成本过高！大容量开源NoSQL系统选择Scylla、mongoDB、Couchbase进行性能对比大容量开源NoSQL-测试场景服务器服务端：3台物理机CPU:2 x Intel Xeon Gold 5118 2.30GHz,24 Cores 48 Threads in totalMemory:192GBSSD:8 x INTEL SSDSC2KB96(960GB)客户端：3台物理机CPU:2 x Intel Xeon Gold 6148 2.40GHz,40 Cores 80 Threads in totalMemory:512GB数据集小数据集（Small）1亿条 X 1KB长度

3、 X 3副本数据量内存负 载只读（RO）加载数据集后，10w Read+0 Write随机读写（RW）加载数据集后，5w Read+5w Write版 本MongoDB 4.2.0Couchbase 6.0.0Scylla 2.0.4/3.0.10大容量开源NoSQL-测试结果10.150.97.54.10.410.35.158.80.85.610551055SMALL_ROSMALL_RSMALL_WLARGE_ROLARGE_RLARGE_WQPS(万行万行/秒秒)mongoDBCouchbaseScylla3802280090.240.651.1528.76194.

4、471.3214.191.767.916.125.66SMALL_ROSMALL_RSMALL_WLARGE_ROLARGE_RLARGE_WP99读写延时读写延时(MS)mongoDBCouchbaseScylla 仅有 Scylla 满足所有场景QPS要求 mongoDB 在cache dirty比例达到20%后，写请求开始排队（qw），写QPS急剧下降 Couchbase 在大数据量读写场景下，数据异步持久化造成读QPS急剧下降 均不满足读写延时需求（P9910ms）Couchbase 在小数据量，数据均缓存在内存，延时最优。大数据量读写时，读延时较大 Scylla大数据量读写时，读延时

5、最优。压测2小时后，开始出现10s+超时Scylla最接近我们的需求，但高负载下长尾延时明显。是什么原因？Scylla 工作原理CREATE TABLE loads(machine,cpu,mtime,load,PRIMARY KEY(machine,cpu),mtime)WITH CLUSTERING ORDER BY(mtime DESC);Murmurhash3(PartitionKey)Token(64bit)Token RangeVNodePhysical NodeMem TableCommit LogSSTableCompactionCoordinator基于LSM(Log Str

6、uctured Merge)Tree的存储方式，会造成“写/读/空间的放大”Scylla 延时抖动的原因Size-Tiered Compaction 每层存储固定数量的文件（default:4）在该层文件数达到阈值时，将文件合并为1个，并放在下一层适用场景：新增写入和读 均衡不适用：对已有数据的大量Update/Delete是否采用其他存储引擎，以减小“写/读/空间放大”带来的性能抖动和空间浪费？T2T2T2T2T3T2T2T2T2T3T2T2T2T2T3T2T2T2T2T3T4提纲 为什么要开发 HiKV？HiKV 设计思路与关键技术 HiKV 在爱奇艺的应用HiKV 设计思路 继承Scyl

7、la的优势，发挥硬件的性能 Seastar Shared-nothing架构 用户态 I/O 队列 CPU和I/O调度 DPDK 查询缓存 无单点+多副本+多数据中心+多活 参考WiscKey的设计，减小写/读放大，降低长尾延时Core 0Socket 0Core 1Socket 0Core 0Socket MCore 1Socket MIO QueueMemorySeastar Task SchedulerIO QueueMemorySeastar Task SchedulerIO QueueMemorySeastar Task SchedulerIO QueueMemorySeastar

8、Task SchedulerthreadthreadthreadthreadHiKV=Scylla+WiscKey存储引擎shardshardshardshardApplicationHiKV 数据存储方式LSM-treeWiscKeyvaluevaluevalueValueLog(SSD)LSM-tree(SSD)HiKVvaluevaluevalueDataLog(SSD)RBTree(Memory)SSTable(SSD)优化写：批量顺序写盘优化读：Compaction（排序+GC）缺点Key与Value混存，检索效率低读/写放大浪费存储减小“读写放大”：索引（Key）与数据（Value

9、）分开管理优化写：Value批量顺序写盘优化读：Key排序+缓存，支持Range空间优化：ValueLog 轻量级GC缺点索引（Key）读放大消除索引（Key）的读放大LSM-tree RBTree/Hashtable读：1次盘IO提高索引检索速度：SSD Memory索引持久化：索引日志 Checkpoint空间优化：DataLog轻量级GC+手动全量清理缺点不支持range查询HiKV 整体架构Key-Value API读 Cache数据文件（DataLog/SSD Raid0）全链路监控索引（内存）数据复制GC写 BufferMetrics配置中心WRGossip元数据管理Checkpo

10、int存储代理 Storage Proxy运维工具故障处理ClientServer数据模型Value 为单/多列，支持类型、TTL支持的操作Get/MGetSet/MSetScan（token range）分布式复制Coordinator负责读写任何一个节点都可以是CoordinatorCoordinator通过Gossip共享元数据可配的一致性级别高可用多副本（Hinted Handoff/Read Repair）多数据中心HiKV 写数据流程ServerHiKV 读数据流程Server索引数据全部进memory，单机数据存储量是否受限？HiKV 索引内存结构 每条数据 1条索引信息 SET

11、 索引指向最新的Value Delete/TTL 删除索引 索引在内存中组成 RBTree 支持 Token Range遍历 索引记录长度 112 Byte(v1.0)64 Byte(v2.0)数据文件编号 16B8BTTL 8B4B数据记录大小 8B4BKey 16B24B(RipeMD160摘要）Token 20B8B颜色CLR 8B1bit父指针 8B0(保存在LRU缓存)2*孩子节点 2*8B2*4B(地址下标)4B对齐0HiKV 2.0 索引内存结构，每条索引长度 64 Byte内存如何管理？使用Seastar的内存分配器LSA（Log-Structured Memory Alloc

12、ator）？物理机内存：512GB索引数据内存占比：90%单条数据记录长度：1KBHiKV 1.0：4.1 TBHiKV 2.0:7.2 TB单台物理机单台物理机存储容量存储容量HiKV 内存管理 Seastar LSA 延迟释放+自动碎片整理 HiKV 定长内存分配器 延时释放+自动碎片整理+其他功能紧耦合(checkpoint)索引记录长度需要96Byte，单机存储量下降33%Server内存索引数据内存分配器索引数据如何进行 持久化 及 快速加载？HiKV 索引数据Checkpoint将某时刻内存索引数据持久化，并删除之前的IndexLog，加快节点启动速度RBTree内存分配器内存分配

13、器_OLD内存分配器内存分配器_NEWIndexFileW/RR记录索引记录索引日志日志遍历所有遍历所有Segment并持久化并持久化将将segment及空闲块信息及空闲块信息转交给新分配器转交给新分配器1234IndexFileIndexFileIndexFile5 删除旧索引日志删除旧索引日志HiKV 数据文件GC Datalog中的垃圾数据删除的数据被覆盖的旧数据过期的数据 Datalog GC将垃圾率超出阈值的Datalog重写，释放存储空间控制GC Thread并发度和优先级，避免影响正常操作更新/删除/过期操作，更新datalog垃圾率文件垃圾率超出阈值申请GC许可遍历datalo

14、g中每一条数据检查索引项为空？索引项过期?将数据写入新DataLog更新内存索引归还GC许可DatalogDatalogDatalogDatalogGCHiKV 设计思路总结HiKV=Scylla+WiscKey存储引擎 索引 索引以RBTree全部保存在内存，1次盘IO读到数据，消除读放大 优化索引结构，并定制定长内存分配器，减小索引内存占用，提高单机数据存储量 数据 数据以Log方式追加写入到Datalog文件，减小写放大 轻量级的GC（并发控制+IO带宽控制）清除垃圾数据，释放存储空间 框架Scylla分布式架构Seastar thread-per-core 框架提纲 为什么要开发 Hi

15、KV？HiKV 设计思路与关键技术 HiKV 在爱奇艺的应用性能比较 HiKV vs.Scylla1.023.191.044.815.662.3914.191.767.916.125.66SMALL_ROSMALL_RSMALL_WLARGE_ROLARGE_RLARGE_WP99读写延时读写延时(MS)HiKVScylla小数据量下，延时相当；大数据量下，HiKV 读写延时稳定，且明显优于Scylla随机读写各5w QPS 下 HiKV P99延时性能比较 HiKV vs.Scylla3049%5200%5299%5687%3236%5423%7085%7341%SMALL_ROSMALL_

16、RWLARGE_ROLARGE_RWCPU利用率利用率HiKVScylla2.07%41.13%45.60%47.90%3.49%28.02%87.60%83.77%1.7 0.7 1.9 1.7 0.00%50.00%100.00%150.00%200.00%250.00%Small_ROSmall_RWLarge_ROLarge_RWSSD IO利用率利用率HiKV7 478 375 304 535 379 21 341 447 1416 1141 2792 2.8 0.7 1.2 4.7 2.1 7.4 0.02.04.06.08.00500025003000Sma

17、ll_ROSmall_RSmall_WLarge_ROLarge_RLarge_W平均平均SSD带宽带宽(MB/s)HiKVScyllaHiKV 默认缓存策略对小数据量不友好，但CPU利用率较Scylla低，且极大降低了读写IO放大97.99%42.62%17.00%17.60%96.79%94.25%16.40%16.17%SMALL_ROSMALL_RWLARGE_ROLARGE_RW读缓存命中率读缓存命中率HiKVScyllaHiKV在爱奇艺的应用实践立项，封装Scylla团队1.5人2017Q4开发WiscKey引擎团队2人2018Q1发布v1.0，支持扩容、多列、视图等在内部IM工具

18、灰度上线2018Q2v1.2，支持缓存、GC、定长内存分配器等推荐系统用户兴趣与行为/内存偏好数据2018Q3v1.5，内存索引结构优化至72Byte推荐历史、播放记录、码流数据等2018Q4v2.0，内存索引结构优化至64Byte，RipeMD160 摘要、索引checkpoint、写保护等2019Q2应用推荐、BI、搜索、广告、视频播放、安全等数据视频特征、用户特征、视频元数据、推荐历史、设备指纹、KV持久化等成本约等于 Couchbase 1/6，Redis 1/9Small Size KV:性能接近内存KVLarge Size KV:长尾延时不超过10ms6节点/9TB数据KV平均长度 1KB读写比 50:1，QPS峰值20w缓存命中率：73%延时 P991ms12节点/50TB数据KV平均长度 5KB写QPS峰值35w，读QPS峰值10w缓存命中率：51%延时 P999ms未来计划 用Optane扩容内存 优化内存碎片整理 启用DPDK 数据压缩