关系型数据库存在的弱点

不容易扩展（增加一列或者是提高性能都需要很大的成本）

列式数据库

是以列相关存储架构进行数据存储的数据库，主要适合于批量数据处理和即时查询。

相应代表(HBase, BigTable)

列式数据库特点

• 高效的储存空间利用率

列用字典表等结构

• 查询效率高

读取多条数据的同一列效率高，因为这些列都是存储在一起的，一次磁盘操作可以数据的指定列全部读取到内存中。

• 适合做聚合操作

因为按照的是列来存储

• 适合大量数据而不是小数据

由于字典也需要占用一定空间，数据量越大，空间利用越高

缺点:

1.不适合扫描 小量数据


2.不适合 随机的更新


3.不适合做含有删除和更新的 实时操作


4.单行数据 支持 ACID 的 事务操作，多行数据 的 事务操作，不支持事务的 正常回滚，支持 （Isolation）隔离性、(Durability）持久性，不能保证 (Atomicity）原子性、（Consistency）一致性。

应用场景

1.适合 大数据量 (100TB 级数据），有 快速随机访问 的需求。


2.适合 写密集型 应用，每天写入量巨大，而 读数量相对较小 的应用，比如 IM 的 历史消息，游戏日志 等等。


3.适合不需要 复杂查询 条件来查询数据的应用。HBase 只支持基于 rowkey 的查询，对于 HBase 来说，单条记录 或者 小范围的查询 是可以接受的。大范围 的查询由于 分布式 的原因，可能在 性能 上有点影响。HBase 不适用于有 join，多级索引，表关系复杂 的数据模型。


4.对 性能 和 可靠性 要求非常高的应用。
由于 HBase 本身没有 单点故障，可用性 非常高。


5.适合 数据量较大，而且 增长量 无法预估的应用，需要进行优雅的数据扩展的应用。HBase 支持 在线扩展，即使在一段时间内，数据量呈 井喷式增长，也可以通过 HBase 横向扩展 来满足功能。


6.存储 结构化 和 半结构化 的数据。

K-V数据库

指的是使用 键值（key-value）存储的数据库，其数据按照 键值对 的形式进行 组织、索引 和 存储。
KV 存储非常适合不涉及过多 数据关系 业务的数据。它能够有效减少 读写磁盘 的次数，比 SQL 数据库存储 拥有更好的 读写性能，能够解决 关系型数据库 无法存储 数据结构 的问题。

代表:redis，Cassandra，Memcached，LevelDB

特点(Redis为例)

优点

• 性能极高

Redis 单机最高能支持超过 10W 的 TPS

• 丰富的数据类型

Redis 支持包括 String，Hash，List，Set，Sorted Set，Bitmap 和 Hyperloglog 等数据结构。

• 丰富的特性

Redis 还支持 publish/subscribe，通知，key 过期 等特性。

具体应用场景

适合:  存储用户信息、配置文件、参数、购物车等

不适合: 通过值来查询， 需要存储数据之间的关系，没有事物要求

缺点

• Redis 事务 不能支持 原子性 和 持久性（A 和 D），只支持 隔离性 和 一致性（I 和 C）。

文档数据库

文档数据库 用于将 半结构化数据 存储为 文档 的一种数据库。文档数据库通常以 JSON 或 XML 格式存储数据。

由于文档数据库的 no-schema 特性，可以 存储 和 读取 任意数据。

由于使用的 数据格式 是 JSON 或者 BSON，因为 JSON 数据是 自描述的，无需在使用前定义字段，读取一个 JSON 中 不存在的字段 也不会导致 SQL 那样的语法错误，可以解决关系型数据库 表结构 schema 扩展不方便 的问题。

代表(MongoDB、CouchDB)

特点（MongoDB为例）

优点

• 新增字段简单不需要像关系型数据库一样，先执行 DDL 语句 修改表结构，程序代码 直接读写 即可。

• 容易兼容 历史数据。对于历史数据，即使没有新增的字段，也不会导致错误，只会返回 空值，此时 代码兼容处理 即可。

• 容易存储复杂数据。JSON 是一种强大的 描述语言，能够描述复杂的 数据结构。

缺点

多条数据记录 的 事务支持较弱，具体体现如下：

• Atomicity（原子性）：仅支持 单行/文档级原子性，不支持 多行、多文档、多语句原子性。

• Isolation（隔离性）：隔离级别仅支持 已提交读（Read committed）级别，可能导致 不可重复读，幻读 的问题。

• 不支持 复杂查询。例如 join 查询，如果需要 join 查询，需要 多次操作数据库。

应用场景

适用

• 数据量 很大或者未来会变得很大。

• 表结构不明确，且 字段 在 不断增加，例如内容管理系统，信息管理系统。

不适用

• 在不同的文档上需要添加 事务。Document-Oriented 数据库并不支持 文档间的事务。

• 多个文档之间需要 复杂的查询，例如 join 操作。

全文搜索数据库

传统关系型数据库，主要通过 索引 来达到 快速查询 的目的。在 全文搜索 的业务下，索引 也无能为力，主要体现在以下几方面：

全文搜索的条件，可以随意 排列组合，如果通过索引来满足，则索引的 数量非常多。

全文搜索的 模糊匹配方式，索引 无法满足，只能用 like 进行查询，而 like 查询是 整表扫描，效率非常低。

全文搜索引擎 的技术原理称为 倒排索引（inverted index），是一种 索引方法，其基本原理是建立 单词 到 文档 的索引。与之相对是，是 正排索引，其基本原理是建立 文档 到 单词 的索引

代表（ElasticSearch,Solr）

特点

优点

• 查询效率高，适用于对 海量数据 进行 近实时 的处理。

• 可扩展性

• 基于 集群 环境可以方便 横向扩展，可以承载 PB 级的数据。

• 支持 高可用，ElasticSearch 集群弹性灵活，可以发现新的或失败的节点，重组 和 重新平衡 数据，确保数据是 安全 和 可访问的。

缺点

• 事务的 ACID 支持不足，单一文档 的数据是支持 ACID 的。对于 多个文档 的 事务操作，不支持事务的 正常回滚。支持（Isolation）隔离性（基于 乐观锁机制）和（Durability）持久性，不支持（Atomicity）原子性，（Consistency）一致性。

• 对类似数据库中，通过 外键 进行 多表关联的复杂操作支持较弱。

• 读写 有一定 延时，写入的数据，最快 1s 中能被检索到。

• 更新 性能较低，底层实现是 先删数据，再 插入新数据。

• 内存占用大，因为 Lucene 将 索引部分 加载到 内存 中。

应用场景

适用

• 分布式的 搜索引擎 和 数据分析引擎。
• 全文检索，结构化检索 以及 数据分析。
• 对海量数据进行 近实时 的处理，可以将 海量数据 分散到 多台服务器 上去 存储 和 检索。

不适用

• 数据需要 频繁更新。

• 需要 复杂关联查询。

图形数据库

图形数据库 应用 图形理论 存储 实体 之间的 关系信息。最常见例子就是 社会网络中人与人之间的关系。关系型数据库 用于存储这种 关系型数据 的效果并不好，其查询 复杂、缓慢、超出预期。

图形数据库 的独特设计弥补了这个缺陷，解决 关系型 数据库 存储 和 处理复杂关系型数据 功能较弱的问题。

代表(Neo4j,ArangoDB,)

原理 (以Neo4j为例)

Neo4j 使用 数据结构 中图（graph）的概念来进行 建模。


Neo4j 中两个最基本的概念是 节点 和 边。节点 表示 实体，边 则表示 实体之间的关系。节点 和 边 都可以有自己的 属性。不同 实体 通过各种不同的 关系 关联起来，形成复杂的 对象图。

在 Neo4j 中，存储节点 时使用了 index-free adjacency，即 每个节点 都有指向其 邻居节点 的 指针。这样就可以在 O(1) 的 复杂度 内找到 邻居节点。另外，按照官方的说法，在 Neo4j 中 边 s是最重要的，是 first-class entities，需要 单独存储。这有利于在 图遍历 的时候 提高速度，也可以很方便地以 任何方向 进行遍历。

特点

优点

• 高性能表现

图的遍历 是 图数据结构 所具有的独特算法，即从 一个节点 开始，根据其连接的 关系，可以快速和方便地找出它的 邻近节点。这种查找数据的方法不受 数据量大小 的影响，因为 邻近查询 始终查找的是 有限的局部数据，不会对 整个数据库 进行搜索。

• 设计的灵活性

数据结构 的自然伸展特性，以及其 非结构化 的 数据格式，让图数据库设计可以具有很大的 伸缩性 和 灵活性。因为随着需求的变化而增加的 节点、关系 及其 属性，并不会影响到 原来数据 的正常使用。

• 开发的敏捷性

数据模型 直接明了，从需求的讨论开始，到程序开发和实现，基本上不会有大的变化。

• 完全支持ACID

不像别的 NoSQL 数据库，Neo4j 还完全具有 事务管理特性，完全支持 ACID 事务管理。

缺点

• 节点，关系 和它们的 属性 的数量被 限制。

• 不支持 拆分。

应用场景

适用场景

• 在一些 关系性强 的数据应用，例如 社交网络。

• 推荐引擎，将数据以 图的形式 表现，非常有益于推荐的制定。

不适用场景

• 记录大量 基于事件 的数据，如日志记录、传感器数据。

• 对大规模 分布式数据 进行处理，类似于 Hadoop。

• 不适用于应该保存在 关系型数据库 中的 结构化数据。

• 二进制数据存储。

关于 关系型数据库 和 NoSQL 数据库 的选型，往往需要考虑几个指标：

数据量
并发量
实时性
一致性要求
读写分布
数据类型
安全性
运维成本

企业内部管理系统
例如运营系统，数据量少，并发量小，首选考虑 关系型数据库


互联网大流量系统
例如电商单品页，后台考虑选 关系型数据库，前台考虑选 内存型数据库


日志型系统
原始数据 考虑选 列式数据库，日志搜索 考虑选 倒排索引


搜索型系统
例如站内搜索，非通用搜索，商品搜索，后台考虑选 关系型数据库，前台考虑选 倒排索引


事务型系统
例如库存管理，交易，记账，考虑选 关系型数据库 + 缓存数据库 + 一致性型协议


离线计算
例如大量数据分析，考虑选 列式数据库 或者 关系型数据库 都可以


实时计算
例如实时监控，可以考虑选 内存型数据库 或者 列式数据库

参考自

作者：零壹技术栈
链接：https://juejin.im/post/6844903666260901896