# 关系数据库 VS NoSQL的比较
---

## 关系数据库的缺点

- 关系数据库存储的是行记录，无法存储数据结构
- 使用关系数据库存储只能将列表拆成多行，然后再查询出来组装，无法直接存储一个列表。
- 关系数据库的 schema 扩展很不方便
- 关系数据库的表结构 schema 是强约束，操作不存在的列会报错，业务变化时扩充列也比较麻烦，需要执行 DDL（data definition language，如 CREATE、ALTER、DROP 等）语句修改，而且修改时可能会长时间锁表（例如，MySQL 可能将表锁住 1 个小时）。
- 关系数据库在大数据场景下 I/O 较高
- 如果对一些大量数据的表进行统计之类的运算，关系数据库的 I/O 会很高，因为即使只针对其中某一列进行运算，关系数据库也会将整行数据从存储设备读入内存。
- 关系数据库的全文搜索功能比较弱
- 关系数据库的全文搜索只能使用 like 进行整表扫描匹配，性能非常低，在互联网这种搜索复杂的场景下无法满足业务要求。

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

| 类型 | 部分代表 | 特点 |
| -------- | -------- | -------- |
| 列存储 | Hbase Cassandra Hypertable | 顾名思义，是按列存储数据的。最大的特点是方便存储结构化和半结构化数据，方便做数据压缩，对针对某一列或者某几列的查询有非常大的IO优势。 |
| 文档存储 | MongoDB CouchDB | 文档存储一般用类似json的格式存储，存储的内容是文档型的。这样也就有有机会对某些字段建立索引，实现关系数据库的某些功能。 |
| key-value存储 | Tokyo Cabinet / Tyrant Berkeley DB MemcacheDB Redis | 可以通过key快速查询到其value。一般来说，存储不管value的格式，照单全收。（Redis包含了其他功能） |
| 图存储 | Neo4J FlockDB | 图形关系的最佳存储。使用传统关系数据库来解决的话性能低下，而且设计使用不方便。 |
| 对象存储 | db4o Versant | 通过类似面向对象语言的语法操作数据库，通过对象的方式存取数据。 |
| xml数据库 | Berkeley DB XML BaseX | 高效的存储XML数据，并支持XML的内部查询语法，比如XQuery,Xpath。 |

| 类型 | 部分代表 | 解释 |
| -------- | -------- | -------- |
| bigTable技术 | HBase | 不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库.另一个不同的是HBase基于列的而不是基于行的模式 |
| bigTable技术 | Cassandra | 一个混合型的非关系的数据库 |
| bigTable技术 | Hypertable | Bigtable的一个开源实现 |
| 内存数据库 | redis | key-value存储系统，但也支持持久化机制（快照，AOF等） |
| 内存数据库 | Memlink | 一个高性能、持久化、分布式的Key-list/queue数据引擎。与Memcached不同的是，它的value是一个list/queue。并且提供了诸如持久化，分布式的功能。听起来有点像Redis，但它号称比Redis更好。 |

注意：MemcacheDB与memcached不同，它是一个分布式、key-value形式的持久存储系统，不是一个缓存组件，而是一个基于对象存取的、可靠的、快速的持久存储引擎。 协议跟memcache一致（不完整），因此很多memcached客户端都可以跟它连接。MemcacheDB采用Berkeley DB作为持久存储组件，故很多Berkeley DB的特性的他都支持。MemcacheDB的前端：memcached的网络层，后端：BerkeleyDB存储。

## 数据库的选择问题

1. 需要确定业务需求，是否需要NoSQL产品。对于大多数百万量级、千万量级的应用，MySQL也能支持。

2. 在明确需要NoSQL产品后，应根据业务需求抽象出数据模型，比如：有些数据是需要采用key-value系统存储，有些数据是需要采用key-list系统存储，有些数据是采用文档数据库存储等等。

## 对于NoSQL产品候选列表的选项，可以从如下维度进行考虑：

1. 系统的容量、性能、软硬件环境是否符合需求？
2. 数据的安全机制如何？各种异常是否会丢失数据？
3. 具备主从复制功能？何种一致性策略？
4. 可扩展性？自动扩展 or 程序进行扩展？
5. 系统的可控性？系统的成熟度、对开发者的支持度、bug谁来修复等等

###### tags: `database`