database-关系数据库与noSql数据库选型分析_nosql 与关系型数据库的技术选型

近期因为一些私有化部署的需求需要切换一下方案底层数据库，评估一下数据库选型并需要整理一份文档，这里借此机会也整理一下这部分内容。

本文档是个人一些浅见和基于极客时间的两门课程整理（Mysql实战45讲和从零开始学架构）

1 关系数据库

常见的以Mysql和Postgresql为代表

优点：

强大的 SQL 功能和 ACID 的属性

• 一个用户请求要么成功、要么失败，不能处于中间状态（Atomic）
• 一旦一个事务完成，将来的所有事务都必须基于这个完成后的状态（Consistent）
• 未完成的事务不会互相影响（Isolated）
• 一旦一个事务完成，就是持久的（Durable）

缺点：

• 关系数据库存储的是行记录，无法存储数据结构
• 关系数据库的 schema 扩展很不方便
• 关系数据库在大数据场景下 I/O 较高
• 关系数据库的全文搜索功能比较弱

基于以上的描述，如果我们对事务和原子性有很高的要求，且数据变动不大的情况下，关系型数据库应该是我们首选的方案

2 非关系数据库

非关系数据库并不是no sql 而是Not Only Sql

常见的 NoSQL 方案分为 4 类。

• K-V 存储：解决关系数据库无法存储数据结构的问题，以 Redis 为代表。
• 文档数据库：解决关系数据库强 schema 约束的问题，以 MongoDB 为代表。
• 列式数据库：解决关系数据库大数据场景下的 I/O 问题，以 HBase 为代表。
• 全文搜索引擎：解决关系数据库的全文搜索性能问题，以 Elasticsearch 为代表。

2.1 K-V 存储：Redis 为代表

优点：

1. 解决关系数据库无法存储数据结构的问题

缺点：

1. 主要体现在并不支持完整的 ACID 事务，Redis 虽然提供事务功能，但 Redis 的事务和关系数据库的事务不可同日而语，Redis 的事务只能保证隔离性和一致性（I 和 C），无法保证原子性和持久性（A 和 D）

这里常规redis的用法都是用一个key-value的方式存储数据，通常用作缓存。

在我的实际场景中，需要存一些消息数据并需要持久化，且要支持数据生命周期自动删除功能。还要支持按照一些其他字段进行查询，这种场景下看起来就不是很适合。

2.2 文档数据库: MongoDB为代表

优点

为了解决关系数据库 schema 带来的问题，文档数据库应运而生。文档数据库最大的特点就是 no-schema，可以存储和读取任意的数据。

1. 新增字段简单。
2. 历史数据不会出错。
3. 可以很容易存储复杂数据

缺点：

1. 最主要的代价就是不支持事务。（后续版本已支持）
2. 无法实现关系数据库的 join 操作

2.3 列式数据库: 以HBase 为代表

列式数据库就是按照列来存储数据的数据库，与之对应的传统关系数据库被称为“行式数据库”，因为关系数据库是按照行来存储数据的。

优点：

典型的场景就是海量数据进行统计。例如，计算某个城市体重超重的人员数据，实际上只需要读取每个人的体重这一列并进行统计即可，而行式存储即使最终只使用一列，也会将所有行数据都读取出来。如果单行用户信息有 1KB，其中体重只有 4 个字节，行式存储还是会将整行 1KB 数据全部读取到内存中，这是明显的浪费。而如果采用列式存储，每个用户只需要读取 4 字节的体重数据即可，I/O 将大大减少

1. 节省 I/O
2. 更高的存储压缩比

缺点：

典型的场景是需要频繁地更新多个列。因为列式存储将不同列存储在磁盘上不连续的空间，导致更新多个列时磁盘是随机写操作；而行式存储时同一行多个列都存储在连续的空间，一次磁盘写操作就可以完成，

2.4 全文搜索引擎

全文搜索引擎的技术原理被称为“倒排索引”（Inverted index），也常被称为反向索引、置入档案或反向档案，是一种索引方法，其基本原理是建立单词到文档的索引。

这种应用场景可以参考电商的场景下的筛选功能。比如某一类商品有非常多的可选项。当时就想如果这么多选项都要建立索引，会让表性能变差。

3 分析

对于数据库选型需要针对具体的场景。比如在我目前接触到的场景就并没有用到列式数据库和全文搜索引擎的场景。

下面举例说明下个人在这次选型思路：

在目前的项目中，有很多关系存在，需要一些事务操作和一定的join操作来提高开发效率。而且从数据量也不会太大。比如用户和设备。应该都不会触及分库分表的阶段。

而对于设备文件的和设备消息的存储，设备消息应该是设备数据量*50倍的关系，且需要支持生命周期自动过期删除消息。如果仅使用SQL来存储，很容易这张表的数据量就会变得很大，且还有需要删除数据场景，如果采用软删除，表数据量就会更大了。所以这种情况下sql 个人认为就不是最优解了。