首页 > 代码库 > 数据存储方案评估标准RDBMS or KV
数据存储方案评估标准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
数据存储方案评估标准RDBMS or KV
声明:以上内容来自用户投稿及互联网公开渠道收集整理发布,本网站不拥有所有权,未作人工编辑处理,也不承担相关法律责任,若内容有误或涉及侵权可进行投诉: 投诉/举报 工作人员会在5个工作日内联系你,一经查实,本站将立刻删除涉嫌侵权内容。