存储矩阵
几亿用户下先死的是错误的数据形状：把粉丝列表放 MySQL、把视频文件放 KV、把 Feed 结果当事务来写。下面四套是公开资料里抖音系真正依赖的在线存储。
这条数据长什么样？
微秒点查、可丢
Redis
很大、要多活
Abase
要事务或索引
ByteSQL
多跳关系、大 V
ByteGraph
大文件视频
对象存储 + CDN
关键词
倒排
相似向量
ANN
Abase / Abase2
公司级高可用 KV（公开称覆盖约 90% KV 场景）
- 数据模型：兼容 Redis 协议：String/Hash/ZSet/List。可当大容量缓存，也可持久化。
- 分布式形态：2.0 无主多写：任意副本可写，没有切主窗口。冲突用 Anti-Entropy / CRDT 合并后下刷。
- 引擎：Log engine 存多版本；达成一致后单版本进 KV engine（RocksDB / TerarkDB / 点查向的哈希引擎可插拔）。
- 规模：Client 直连或 Proxy（RESP2 / Thrift）。SDK 带重试、Backup Request、热 Key 处理。支持跨地区多活和边缘近地读写。
ByteKV + ByteSQL
需要事务和二级索引的在线表
- 数据模型：ByteKV：Range 分区强一致 KV。ByteSQL：在 KV 上的 SQL 与表格模型。
- 分布式形态：Range 可分裂合并。二级索引和主键可以不在同一 shard，避免全局扫。
- 引擎：先 RocksDB，后自研 BlockDB（分片、compaction、按 block 管理）。
- 规模：WriteBatch + 多版本实现 Snapshot Isolation。用户/视频元数据、订单走这里，而不是 Abase。
ByteGraph
关注、好友、屏蔽、二度关系
- 数据模型：有向属性图，Gremlin。点 (id, type) + 边 (type, ts, 属性)。
- 分布式形态：三层：BGE/bgdb 查询规划与 2PC；BGS/bgkv 内存缓存与日志；底层 RocksDB 一类 KV。跨机房复制。
- 引擎：邻接表按边类型和方向切开。普通点一个 KV；超级顶点升到 edge-tree（类 B-Tree，节点本身也是 KV，可跨实例）。
- 规模：VLDB'22：百亿点、万亿边；读吞吐千万 QPS 级、毫秒延迟。热顶点查询层缓存可单 Key 20 万+ QPS。
对象存储 + 融合 CDN
视频源文件、转码产物、封面
- 数据模型：对象语义，生命周期分层。播放不走数据库。
- 分布式形态：源站 TOS；边缘多厂商 CDN。平台做统一配置、联动刷新、拨测与切流。
- 引擎：热内容驻留边缘。冷内容回源。活动期可限制首屏码率。
- 规模：带宽是短视频的第一成本。必须把 meta API 和媒体字节拆成两条网络。
怎么选型
点查、可丢失、要微秒：Redis。点查、容量超内存、要跨城多活：Abase。要事务、二级索引、账户资金：ByteSQL。要多跳遍历、超大邻接表：ByteGraph。要顺序大文件：对象存储。要关键词：倒排。要近邻：向量索引。计数如果写放大，不要直接 INCR 一个全局 Key，而是分片计数加异步聚合。