数据存储方案评估标准RDBMS or KV
浏览数：47 /
时间：2015年06月12日
作者：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
郑重声明：本站内容如果来自互联网及其他传播媒体，其版权均属原媒体及文章作者所有。转载目的在于传递更多信息及用于网络分享，并不代表本站赞同其观点和对其真实性负责，也不构成任何其他建议。
