OTS调研

背景

部分业务上MySQL的使用去到了极限, 单表数据量逼近1TB, 需要评估其他的解决办法.

为什么说MySQL是单机KV服务

KV服务的定义:

(大数据量下) MySQL的局限性

因此, 数据量大之后, MySQL表只能当作一个支持SQL语法访问的单机KV来用, 慎用二级索引, 当然要完全避免扫表筛选逻辑. 对于高TPS的MySQL表, 查询必须限制在SELECT ... WHERE primary_key = ...模式下. 拍脑袋的经验: 单表(单分区)数据量超过100GB, 或超过1kw行后, 需要特别注意读写语句是否足够简单.

其他可以认为是单机KV的服务/存储:

分布式MySQL

本质上基于主键表分实例, 对于中间件及变更运维质量依赖要求高. 最重要的是, 资源需要提前预留好, 不能按需扩容.

基于MySQL的改进云服务数据库

通过改写IO相关实现, 以及后面挂分布式存储, 来优化读写性能的问题:

产品思路是面向客户的MySQL通讯协议不变, 从而最简化上车成本, 后面具体内部实现逻辑再慢慢换掉.

分布式KV服务

或者说NoSQL数据存储服务, 以显得时髦/特别.

OTS vs MySQL

OTS使用限制

成本相关

按需计费的服务有好处, 也有坑点, 使用上一不小心容易产生天价账单. 所以要格外注意成本测算相关, 并有相关成本告警.

成本对比

MySQL:

OTS: 按需计费 (按量容量型算)

总的来说, 存储成本比自建MySQL要低 (自然低过RDS), 更适合存文本类型的属性字段; 需要排序筛选的字段, 一般数值型, 或者枚举的, 相对而言表大小可控, 可以MySQL里面做相关排序筛选逻辑.

参考

成本优化策略

写入成本优化思路: 降频写入, 离线脚本定期写入数据, 同现在kafka2mysql离线化的逻辑. 在数据同步实时性和写入量之间找折衷.

查询成本优化: 评估直接查询性能是否满足要求, 查询成本, 以及根据查询单独建索引表的成本

其他优化手段: 买预留

二级索引

不同于MySQL的二级索引指向原表数据行, OTS的二级索引本质上是自动另外维护另外一个表, 单独计费.

区别

DLA映射表

支持DLA上创建OTS的映射表, 可以和其他数据源做JOIN查询, 写SQL直接读写OTS上的数据

一些使用备忘:

OTS vs DDB 主观使用感受区别

附: MySQL里面做”万金油”表

由于业务上各种字段需求比较多, 大表又加不动字段, 因此MySQL表设计的一种”万金油”做法:

create table xx_kv (
    id int primary key comment '主键',
    k tinyint comment '列名',
    v varchar(1024) comment '值',
    key (k, v(16))
);

可以达到类似的节约宽表结构设计导致的空间浪费, 以及不方便动态加字段的弊端, 甚至还可以对任意字段查询走索引. 也可以针对数值字段/字符字段分两张表处理, 从而支持数值范围查询.

弊端在于不方便做多字段筛选, 以及需要基于筛选条件拿到对象全部属性值时需要分两步走.

HOME