数据存储方案评估标准RDBMS or KV

作者：zhanhailiang 日期：2014-12-11

本文主要介绍常见的数据存储方案及相应选型的评估标准的介绍。

Guideline：针对不同应用场景，针对性选择存储方式。

1. 数据存储方案

SQL：

MySQL 5.5/5.6/MariaDB(对于Dev绝大多数场景下透明)；
Oracle|MS SQL暂不考虑；

NoSQL：

Memcached 1.4.21；
Redis 2.8；
MongoDB 2.6.6；
Hbase 0.96/0.98；

2. 评估标准

RDBMS：(MySQL):

• 要求数据持久化存储；用户提交数据就不能丢失；
• 要求事务保证；
• 应用复杂，数据结构复杂，数据一致性要求高；
• 分布式实现时复杂度高，分库分表代价较大。
• 适合需要严格事务保证的OLTP类系统和MIS类系统;

典型场景：

以电商网站为例，
所有后端子系统(比如ERP，物流，财务，仓储，人事，VIS等）；
网站核心数据存储（比如用户，商品，库存，购物车，订单）；

KV(Memcache/Redis)：

• 数据结构简单；只是按照简单的Key来查询和update记录；
• 数据不需要持久化存储(persistent on disk)， 是secondary data；一般不是用户直接写入；（比如由后端job生成，可以由应用实现双写）
• 不需要transaction事务支持；
• 可能有很高的QPS/TPS(for example, 10k+ query/transaction per second);
• 有非常高的响应速度要求（<1ms typically)，以redis为例，同机房操作一般都是几十微秒级别；

典型场景：

各类计数器；
各类cache层（商品列表页，各类配置信息，商品描述信息等）；

Analytics Platform:

Hadoop：ETL；科学分析；
GP：BI分析；各类报表；
Hbase：在线系统；OLAP分析；
DocDB：应用相对简单，数据结构相对复杂，支持快速开发，非事务类处理的信息处理系统。如知识问答、社区等；

3. 性能优化

已有系统碰到性能瓶颈时，优化次序依次为：

• 容量评估
• 性能优化（系统优化，代码逻辑优化，SQL优化）
• 硬件升级（从低端硬件到高端硬件，从低端存储到高端存储）
• 垂直拆分（按照不同的模块拆分数据库）
• 水平拆分（对某个模块，在系统里面再也跑不动，就需要对该模块按照主键或者其他逻辑拆分）

附录

开始尝试使用github.com issues工具写博客，挺爽的！
对应github.com链接：#4