浅谈常见的NoSQL技术⽅案和选型
版权声明：零壹技术栈 blog.csdn/baidu_22254181/article/details/82594116
前⾔
在互联⽹和⼤数据的背景下，越来越多的⽹站、应⽤系统需要⽀撑 海量数据存储、⾼并发请求、⾼可⽤、⾼可扩展性 等特性要求。传统的关系型数据库 已经难以应对类似的需求，各种各样的 NoSQL（Not Only SQL）数据库因此⽽产⽣。 本⽂将分析 传统数据库 的存在的问题，以及⼏类 NoSQL 如何解决这些问题。在不同的 业务场景 下，作出正确的 数据存储 技术选型。正⽂
1. 传统数据库缺点
缺点解释说明
⼤数据场景下 I/O 较⾼因为数据是按 ⾏存储，即使只针对其中 某⼀列 进⾏运算，关系型数据库也会对 整⾏数据 进⾏扫描，从存储设备中 读⼊内存，导致 I/O 较⾼
结构化存储 不够灵活存储的是 ⾏记录，⽆法存储 灵活的数据结构
表结构 schema 扩展不⽅便如要需要修改 表结构，需要执⾏执⾏ DDL（data definition language）语句修改，修改期间会导致 锁表，部分服务不可⽤
全⽂搜索 功能较弱关系型数据库只能够进⾏ ⼦字符串 的 匹配查询，当表的数据逐渐变⼤的时候，即使在有 索引 的情况下，like 扫表查询的匹配会 ⾮常慢 难以 存储 和 处理 复杂 关系
型数据
传统的关系数据库，并不擅长处理 数据点之间 的关系
2. NoSQL简介
NoSQL，泛指 ⾮关系型 的数据库，可以理解为 关系型 数据库的⼀个有⼒补充。
NoSQL 在许多⽅⾯性能⼤⼤优于 ⾮关系型 数据库的同时，往往也伴随⼀些特性的缺失。⽐较常见的是 事务功能 的缺失。 数据库事务正确执⾏的四个基本要素 ACID 如下：
名称描述
丁学强
A Atomicity(原⼦性)
C Consistency⼀致性
I Isolation隔离性
国术联盟D Durability持久性
针对传统 关系型数据库 的不⾜，下⾯介绍常见的 5 ⼤类 NoSQL 解决⽅案：
3. 列式数据库
列式数据库 是以 列相关存储架构 进⾏数据存储的数据库，主要适合于 批量数据处理 和 即时查询。相对应的是 ⾏式数据库，数据以 ⾏相关的存储架构 进⾏空间分配，主要适合于 ⼩批量 的 数据处理，常⽤于 联机事务型数据处理。 基于列式数据库的 列存储特性，可以解决某些特定场景下 关系型数据库 ⾼ I/O 的问题。
3.1. 基本原理
传统关系型数据库是 按照⾏ 来存储数据库，称为 ⾏式数据库，⽽ 列式数据库 是 按照列 来存储数据。
将表放⼊存储系统中有两种⽅法，⽽我们绝⼤部分是采⽤ ⾏存储 的。⾏存储法是将 各⾏ 放⼊ 连续的物理位置，这很像传统的记录和⽂件系统。
列存储法 是将数据 按照列 存储到数据库中，与 ⾏存储 类似，下图是两种存储⽅法的图形化解释：
3.2. 常见列式数据库
3.2.1. H Ba se
HBase 是⼀个开源的 ⾮关系型分布式数据库（NoSQL），它参考了 ⾕歌 的 BigTable 建模，实现的编程语⾔为 Java。它是 Apache 软件基⾦会的 Hadoop 项⽬的⼀部分，运⾏于 HDFS ⽂件系统之上，为 Hadoop 提供类似于 BigTable 规模的服务。因此，它可以 容错地 存储海量稀疏 的数据。
3.2.2. BigTa ble
BigTable 是⼀种 压缩的、⾼性能的、⾼可扩展性的，基于 Google ⽂件系统（Google File System，GFS）的数据存储系统，⽤于存储 ⼤规模结构化数据，适⽤于云计算。
3.3. 相关特性
3.3.1. 优点
⾼效的储存空间利⽤率
列式数据库 针对不同列的 数据特征 ⽽发明了 不同算法，使其⽐ ⾏式数据库 ⾼的多的 压缩率。普通的 ⾏式数据库 ⼀般压缩率在 3：1 到5：1 左右，⽽ 列式数据库 的压缩率⼀般在 8：1 到 30：1 左右。
⽐较常见的，通过 字典表 压缩数据：
下⾯才是那张表本来的样⼦。经过 字典表 进⾏ 数据压缩 后，表中的 字符串 才都变成 数字。正因为每个字符串在 字典表 ⾥只 出现了⼀次，所以达到了 压缩 的⽬的。
查询效率⾼
读取多条数据的 同⼀列效率⾼，因为这些列都是 存储在⼀起的，⼀次磁盘操作可以数据的 指定列 全部读取到 内存 中。 下图通过 ⼀条查询 的执⾏过程说明 列式存储 （以及 数据压缩）的优点。
意象艺术
执⾏步骤如下：
1. 去 字典表 ⾥到 字符串对应数字（只进⾏⼀次字符串⽐较）。
2. ⽤ 数字 去列表⾥匹配，匹配上的位置设为 1。
3. 把 不同列 的 匹配结果 进⾏ 位运算 得到符合所有条件的 记录下标。
4. 使⽤这个 下标组装 出最终的 结果集。
适合做聚合操作
适合⼤量的数据⽽不是⼩数据
3.3.2. 缺点
不适合扫描 ⼩量数据
不适合 随机的更新
不适合做含有删除和更新的 实时操作
单⾏数据 ⽀持 ACID 的 事务操作，多⾏数据 的 事务操作，不⽀持事务的 正常回滚，⽀持 （Isolation）隔离性、(Durability）持久性，不能保证 (Atomicity）原⼦性、（Consistency）⼀致性。
3.4. 应⽤场景
列数据库的适⽤场景，以 HBase 为例说明：
适合 ⼤数据量 (100TB 级数据），有 快速随机访问 的需求。
适合 写密集型 应⽤，每天写⼊量巨⼤，⽽ 读数量相对较⼩ 的应⽤，⽐如 IM 的 历史消息，游戏⽇志 等等。
适合不需要 复杂查询 条件来查询数据的应⽤。HBase 只⽀持基于 rowkey 的查询，对于 HBase 来说，单条记录 或者 ⼩范围的查询是可以接受的。⼤范围 的查询由于 分布式 的原因，可能在 性能 上有点影响。HBase 不适⽤于有 join，多级索引，表关系复杂 的数据模型。
对 性能 和 可靠性 要求⾮常⾼的应⽤。
由于 HBase 本⾝没有 单点故障，可⽤性 ⾮常⾼。
适合 数据量较⼤，⽽且 增长量 ⽆法预估的应⽤，需要进⾏优雅的数据扩展的应⽤。HBase ⽀持 在线扩展，即使在⼀段时间内，数据量呈 井喷式增长，也可以通过 HBase 横向扩展 来满⾜功能。
存储 结构化 和 半结构化 的数据。
4. K-V数据库
4.1. 基本概念
指的是使⽤ 键值（key-value）存储的数据库，其数据按照 键值对 的形式进⾏ 组织、索引 和 存储。
KV 存储⾮常适合不涉及过多 数据关系 业务的数据。它能够有效减少 读写磁盘 的次数，⽐ SQL 数据库存储 拥有更好的 读写性能，能够解决 关系型数据库 ⽆法存储 数据结构 的问题。
4.2. 常见K-V数据库
4.2.1. R edis
Redis 是⼀个使⽤ ANSI C 编写的 开源、⽀持⽹络、基于内存、可选持久性 的 键值对存储 数据库。Redis 是⽬前最流⾏的 键值对存储 数据库之⼀。
4.2.2. Ca ssa ndra
Apache Cassandra（社区内⼀般简称为 C*）是⼀套 开源的分布式 NoSQL 数据库系统。它最初由 Facebook 开发，⽤于储存 收件箱 等简单格式数据，集 Google BigTable 的 数据模型 与 Amazon Dynamo 的 完全分布式 架构于⼀⾝。Cassandra 是⼀种流⾏的 分布式结构化 数据存储⽅案。
4.2.3. Memc a c hed
Memcached 是⼀个 开放源代码、⾼性能、分配的 内存对象缓存系统。⽤于加速动态 web 应⽤程序，减轻关系型数据库负载。它可以应对任意多个连接，使⽤ ⾮阻塞的⽹络 IO。由于它的⼯作机制是在内存中开辟⼀块空间，然后建⽴⼀个 Hash 表，Memcached ⾃管理这些Hash 表。
Memcached 简单⽽强⼤。它简单的设计促进 迅速部署，易于发现所⾯临的问题，解决了很多 ⼤型数据缓存。
4.2.4. LevelDB
LevelDB 是⼀个由 Google 所研发的 键／值对（Key/Value Pair）嵌⼊式 数据库管理系统 编程库，以开源的 BSD 许可证发布。
4.3. 相关特性
永生的眼睛教学设计
K-V 数据库的相关特性，以 Redis 为例说明：
4.3.1. 优点
性能极⾼
Redis 单机最⾼能⽀持超过 10W 的 TPS。
丰富的数据类型
Redis ⽀持包括 String，Hash，List，Set，Sorted Set，Bitmap 和 Hyperloglog 等数据结构。
丰富的特性
Redis 还⽀持 publish/subscribe，通知，key 过期 等特性。
4.3.2. 缺点
Redis 事务 不能⽀持 原⼦性 和 持久性（A 和 D），只⽀持 隔离性 和 ⼀致性（I 和 C）。
这⾥所说的 ⽆法保证原⼦性，是针对 Redis 的 事务操作，因为事务是 不⽀持回滚（roll back），⽽因为 Redis 的 单线程模型，Redis 的普通操作是 原⼦性的。
4.4 应⽤场景
4.4.1. 适⽤场景
适合存储 ⽤户信息（⽐如 会话）、配置⽂件、参数、购物车 等等。这些信息⼀般都和 ID 挂钩。
4.4.2. 不适⽤场景
不适合需要通过 值 来查询，⽽不是 键 来查询。Key-Value 数据库中根本没有通过 值查询 的途径。
不适合需要储存 数据之间的关系。在 Key-Value 数据库中不能通过 两个或以上 的键来 关联数据。
不适合需要⽀持 事务 的场景。在 Key-Value 数据库中 故障产⽣ 时不可以进⾏ 回滚。
5. ⽂档型数据库
5.1. 基本概念
⽂档数据库 ⽤于将 半结构化数据 存储为 ⽂档 的⼀种数据库。⽂档数据库通常以 JSON 或 XML 格式存储数据。
由于⽂档数据库的 no-schema 特性，可以 存储 和 读取 任意数据。
由于使⽤的 数据格式 是 JSON 或者 BSON，因为 JSON 数据是 ⾃描述的，⽆需在使⽤前定义字段，读取⼀个 JSON 中 不存在的字段 也不会导致 SQL 那样的语法错误，可以解决关系型数据库 表结构 schema 扩展不⽅便 的问题。
5.2. 常见⽂档数据库
5.2.1. Mo ngo DB
果蔬气调库MongoDB 是⼀个基于 分布式⽂件存储 的数据库。由 C++ 语⾔编写。旨在为 WEB 应⽤提供可扩展的 ⾼性能 数据存储解决⽅案。MongoDB 是⼀个介于 关系数据库 和 ⾮关系数据库 之间的产品，是⾮关系数据库当中功能 最丰富，最像关系数据库的 NoSQL。时代经贸
5.2.2. Co uc hDB
CouchDB 是⽤ Erlang 开发的 ⾯向⽂档 的 分布式 数据库，⽤于存储 半结构化 的数据，⽐较类似 lucene 的 index 结构。
CouchDB ⽀持 RESTful API，它使⽤ JSON 作为 存储格式，JavaScript 作为 查询语⾔，MapReduce 和 HTTP 作为 API 的 NoSQL 数据库。其中⼀个显著的功能就是 多主复制 功能。除此之外，CouchDB 构建在强⼤的 B- 树储存引擎 之上。
5.3. 相关特性
⽂档型数据库 的相关特性，以 MongoDB 为例进⾏说明：
5.3.1. 优点
新增字段简单不需要像关系型数据库⼀样，先执⾏ DDL 语句 修改表结构，程序代码 直接读写 即可。
容易兼容 历史数据。对于历史数据，即使没有新增的字段，也不会导致错误，只会返回 空值，此时 代码兼容处理 即可。
容易存储复杂数据。JSON 是⼀种强⼤的 描述语⾔，能够描述复杂的 数据结构。
5.3.2. 缺点
相⽐ 传统关系型数据库，⽂档数据库的缺点，主要是对 多条数据记录 的 事务⽀持较弱，具体体现如下：
Atomicity（原⼦性）：仅⽀持 单⾏/⽂档级原⼦性，不⽀持 多⾏、多⽂档、多语句原⼦性。
Isolation（隔离性）：隔离级别仅⽀持 已提交读（Read committed）级别，可能导致 不可重复读，幻读 的问题。
不⽀持 复杂查询。例如 join 查询，如果需要 join 查询，需要 多次操作数据库。
5.4. 应⽤场景
5.4.1. 适⽤场景
数据量 很⼤或者未来会变得很⼤。
表结构不明确，且 字段 在 不断增加，例如内容管理系统，信息管理系统。
5.4.2. 不适⽤场景
在不同的⽂档上需要添加 事务。Document-Oriented 数据库并不⽀持 ⽂档间的事务。
多个⽂档之间需要 复杂的查询，例如 join 操作。
6. 全⽂搜索引擎
6.1. 基本概念
豫公网安备41160202000603
站长QQ:729038198
关于我们
投诉建议