没有其他⼆二级 索引 • 所以只有按rowkey查询⽐比较快, 其他全表扫 • 除了了列列族要求是可打印字符, 别的都可以是任 意⼆二进制数据 数据模型 RowKey • ColumnFamily的设计是要求把相关的列列放在 同族 • 所有的各项配置, 都是指定到列列族上, 不不是列列, 同列列族数据, 物理理上存在同⽂文件 • ColumnFamily在建表时确定, 具体有哪些列列 是数据随意添加的 寻迹数据 场景 千亿级PV, 万亿个KV对 寻迹数据 对⽐比 这⾥里里先对⽐比 前两⾏行行. ⼀一个10列列⼀一个1列列. • ⼀一开始想吐槽这种模型设计, 后来看google论⽂文说⼈人家参考了了很多模型最终才决 定这样设计的…. • 简单⾼高效, 可以作为其他应⽤用的基础 • OpenTSDB: 时序数据库, 主要是监控数据这类的 • JanusGraph: 图数据库 Schema Design 如何设计表结构 • 合理理设计RowKey 和 Column • 根据查询需求决定schema • 单⼀一⼤大宽表, 避免跨表查询 • 必要的时候进⾏行行冗余, 反范式 • 相关的数据要存放在⼀一起 • 不不要有热点 • 将列列限定符视为数据通常是⼀一个合理理选择 Schema设计 在关于数据库⾥里里我们有各种范式来帮助设计, 在hbase⾥里里也要合理理设计⼀一下

Split/Compaction等操作对集群性能影响极大 • 多租户隔离能力差 • 大内存(>100GB)管理差 12 Postgres Conference China 2016 中国用户大会 Kudu的设计目标 • 扫描大数据量时吞吐率高(列式存 储和多副本机制) – 目标: 相对Parquet的扫描性能差距 在2x之内 • 访问少量数据时延时低(主键索引 和多数占优复制机制) – 目标: SSD上读写延时不超过1毫秒 China 2016 中国用户大会 行记录设计 • 采用多行存储还是单行多列存储？ • 将数据另存储为一行还是”覆盖”存储为列(Column)的不同版 本 • 将数据另存储为一行还是增加一个列 • 建议 • 通常情况下的回答: 分行存储 » 能获得更好的Get以及scan的性能 » 太长的行记录不利于做Region的split • 行设计必须符合数据原子性操作要求 » HBase只保证行级别数据的原子性操作 2016 中国用户大会 RowKey设计 • RowKey的组成元素 • 尽量将所有常用查询所使用的域放入RK » 优先使用RK filter，其次使用value filter • 保持RK值得唯一性 (添加序列号) • RK长度越短越好 (通用数据定义规则，适用于其他) » 考虑KeyValue的物理存储规则 • 一般建议RK长度 < 50B • RK的设计首要考虑便于能将最常用的查询转