摘要
架构师在工作中经常会遇到数据库存储选型的问题，而市面上数据库产品众多，往往会无从下手，甚至有时候从业务开发到上线运维过程中会多次更换底层数据库，给整个研发中心带来不必要的额外工作。结合业务场景做数据库存储选型的时候，可以综合以下几个维度去考虑：
一、技术选型维度
1.1 业务是否需要保证ACID事务？
事务具有4个特征,分别是原子性、一致性、隔离性和持久性
| 需要ACID | MySQL、pg（PostgreSQL）等 |
| 不需要ACID | MongoDB、hbase、cassandra等 |
1.2 要求低延迟
| 对性能要求极致，不担心数据丢失的选择 | memcache |
| 数据生命周期短，数据量相对小，性能要求高，需要存储灵活的数据结构： | Redis |
| 一般scylladb>canssdra>hbase | |
1.3 是否高并发写入，随机读多于范围读？
| 需要支持高并发写入，随机读多于范围读？ | hbase、cassandra，hbase范围读更优。 |
1.4 海量数据存储，支持水平扩展，分布式容错？
| 需要支持海量数据存储，支持水平扩展，分布式容错 | NOSQL 如：resis、hbase、Cassandra、mongodb |
1.5 需要全文搜索？
| 支持全文搜索 | 海量数据用Elasticsearch |
| 支持全文搜索 | 数据量可控用pg GIST索引。 |
1.6 存储复杂数据模型？
1.7 OLTP OR OLAP OR离线分析?
| OLTP（联机事务处理） | 行存数据库 mysql 、pg |
| OLAP（联机分析处理） | 列存数据库高压缩 gp 、clickhouse |
| 离线分析 | :hbase |
1.8 金融级要求高可用、数据不丢
| 支持数据不丢 | oceanbase、阿里云mysql金融版、mysql group replication |
1.9 需要事务而且海量数据存储
| 分库分表 | drds、sharding-jdbc+关系型数据库 |
| newsql | TiDB |
1.10 CAP权衡
CAP： 一致性（Consistency）、可用性（Availability）、分区容错性（Partition tolerance）。
| 保证CA | 关系型数据库 |
| 保证CP | hbase、redis、mongodb |
| 保证AP | cassandra、riak 、couchdb |
1.11 特殊业务场景
| 地理信息系统GIS | PG>ES>Mongodb |
| 时序 | TaosDB>influxdb>opentsdb |
1.12 开发角度，业务迭代快，需要schema free
对开发友好：关系型数据库都行。另外就是MongoDB，不过也有两面性，不如关系型数据库有严格的约束，将任意类型的任意值插入任意集合，有时候会带来负面作用。
1.13 运维角度
