Skip to content

NoSQL

NoSQL概述

基本概念

  • RDBMS：关系型数据库管理系统，是创建在关系模型基础上的数据库，借助于集合代数等数学概念和方法来处理数据库中的数据。

  • SQL：结构化查询语言，用于管理关系数据库管理系统（RDBMS），同过 SQL 与 RDBMS 进行交互

  • 数据库事务的ACID属性

  • A原子性：事务是原子工作单元，对于其数据的修改要么全部执行，要么全都不执行
  • C一致性：事务在完成时，必须使所有的数据都保持一致状态
  • I隔离性：由并发事务所做的修改必须与其它任何并发事务所做的修改格利

  • D 持久性：事务完成之后，它对于系统的影响是永久性的

  • 关系型数据库

  • 标准的EDBMS是模式固定、面向行的数据库且具有ACID性质和复杂的SQL查询处理引擎。
  • RDBMS强调事务的“强一致性”、参照完整性、数据抽象与物理存储相对独立，以及基于SQL语言的复杂查询支持。
  • RDBMS可以非常容易建立二级索引，执行复杂的内连接和外连接，执行计数、 求和、排序、分组等操作，或对表、行和列中的数据进行分页存放。

  • 局限性：

    • 大表 —— 在一张表中存储500GB的数据？=> 效率低
    • 灵活动态可变的表结构 —— 为大表修改表结构？=> 非常复杂
    • 无停机时间的在线大表分区和动态扩容 => 不支持

  • 纵向扩展（Vertical Scaling）：

  • 纵向扩展是通过增加单个计算资源的能力来提高系统性能和容量的方式。这通常包括升级硬件组件，如CPU、内存、存储等，以提供更多的计算能力。

  • 纵向扩展的优点是相对简单，不需要更改应用程序的架构，但它存在物理限制，一旦达到硬件的最大性能，无法进一步扩展。

  • 横向扩展（Horizontal Scaling）：

  • 横向扩展是通过增加计算资源的数量来提高系统性能和容量的方式。这通常涉及在系统中添加更多的计算节点或服务器，以平行地处理负载。
  • 横向扩展的优点是可以在需要时轻松添加新的计算节点，以适应不断增长的负载，从而提高系统的可扩展性和性能。

NoSQL与RDBMS

  • NoSQL = Not Only SQL：不仅仅是SQL， 泛指非关系型数据库
  • 放松了对传统数据库ACID事务处理特征和数据高度结构化的要求，以简化设计、提高数据存储管理的灵活性、提高处理性能、支持良好的水平扩展。

NoSQL兴起原因

  • 关系型数据库已经无法满足Web2.0的需求
  • 无法满足海量数据的管理需求
  • 无法满足数据高并发的需求

  • 无法满足高可扩展性和高可用性的需求

  • MySQL集群的问题：

  • 复杂性
  • 数据库复制(备份恢复较为苦难你)
  • 扩容问题（扩展性差）

  • 动态数据迁移问题

  • 关系型数据库的关键特性包括完善的事务机制和高效的查询机制对Web2.0并不重要

  • 不要求严格的数据库事务；
  • 不要求严格的读写实时性；
  • 通常不包含大量复杂的SQL查询

区别

  • 关系型数据库
  • 优势：以完善的关系代数理论作为基础，有严格的标准，支持事务ACID四性，借助索引机制可以实现高效的查询

  • 劣势：可扩展性较差，无法较好支持海量数据存储，数据模型过于死板、无法较好支持 Web2.0应用，事务机制影响了系统的整体性能等

  • NoSQL数据库

  • 优势：可以支持超大规模数据存储，灵活的数据模型可以很好地支持Web2.0应用，具有强大的横向扩展能力等
  • 劣势：缺乏数学理论基础，复杂查询性能不高，大都不能实现事务强一致性，很难实现数据完整性
项 RDBMS NoSQL 补充
数据库原理 完全支持 部分支持 RDBMS有关系代数理论作为基础
NoSQL没有统一的理论基础
数据规模 大 超大 RDBMS很难实现横向扩展，纵向扩展的空间也比较有限，性能会随着数据规模的增大而降低
NoSQL可以很容易通过添加更多设备来支持更大规模的数据
数据库模式 固定 灵活 RDBMS需要定义数据库模式，严格遵守数据定义和相关约束条件
NoSQL不存在数据库模式，可以自由灵活定义并存储各种不同类型的数据
查询效率 快 可以实现高效的简单查询，不具备高度结构化查询等特性，复杂查询的性能不尽人意 RDBMS借助于索引机制可以实现快速查询
很多NoSQL数据库没有面向复杂查询的索引，虽然NoSQL可以使用MapReduce来加速查询，但是在复杂查询方面的性能仍然不如RDBMS
一致性 强一致性 弱一致性 RDBMS严格遵守事务ACID模型，可以保证事务强一致性
NoSQL数据库放松了对事务ACID四性的要求，而是遵守BASE模型，只能保证最终一致性
数据完整性 容易实现 很难实现 RDBMS都可以很容易实现数据完整性
NoSQL数据库无法实现
扩展性 一般 好 RDBMS很难实现横向扩展，纵向扩展的空间也比较有限
NoSQL在设计之初就充分考虑了横向扩展的需求，可以很容易通过添加廉价设备实现扩展
可用性 好 很好 RDBMS在任何时候都以保证数据一致性为优先目标，随着数据规模的增大，RDBMS为了保证严格的一致性，只能提供相对较弱的可用性
大多数NoSQL都能提供较高的可用性
标准化 是 否 RDBMS已经标准化（SQL）
NoSQL还没有行业标准，不同的NoSQL数据库都有自己的查询语言，很难规范应用程序接口
技术支持 高 否 RDBMS经过几十年的发展，已经非常成熟，Oracle等大型厂商都可以提供很好的技术支持
NoSQL在技术支持方面仍然处于起步阶段，还不成熟，缺乏有力的技术支持
可维护性 复杂 复杂 RDBMS需要专门的数据库管理员(DBA)维护
NoSQL数据库虽然没有DBMS复杂，也难以维护
  • 应用场景：
  • 关系型数据库应用场景：电信、银行等领域的关键业务系统，需要保证强事务一致
  • NoSQL数据库应用场景：互联网企业、传统企业的非关键业务（比如数据分析）

NoSQL分类

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

键值数据库

  • image-20231114155337699
产品 Redis、Memcached
数据模型 键是一个字符串对象
值可以是任意类型的数据
典型应用 涉及频繁读写、拥有简单数据模型的应用内容缓存
优点 扩展性好，灵活性好，大量写操作时性能高
缺点 无法存储结构化信息，条件查询效率较低
不适用情形 不是通过键而是通过值来查：键值数据库根本没有通过值查询的途径
需要存储数据之间的关系：在键值数据库中，不能通过两个或两个以上的键来关联数据
需要事务的支持：在一些键值数据库中，产生故障时，不可以回滚
  • 作为缓冲层
  • image-20231114155739499

列族数据库

  • image-20231114155358518
产品 BigTable、HBase
数据模型 列族
典型应用 分布式数据存储与管理
可以容忍副本中存在短期不一致情况的应用程序
拥有动态字段的应用程序
拥有潜在大量数据的应用程序，大到几百TB的数据
优点 查找速度快，可扩展性强，容易进行分布式扩展，复杂性低
缺点 功能较少，大都不支持强事务一致性
不适用情形 需要ACID事务支持的情形，Cassandra等产品就不适用

文档数据库

  • image-20231114155410963
  • 如XML、HTML、JSON
产品 MongoDB
数据模型 键/值，值是版本化的文档
典型应用 存储、索引并管理面向文档的数据或者类似的半结构化数据
比如，用于后台具有大量读写操作的网站、使用JSON数据结构的应用、使用嵌套结构等非规范化数据的应用程序
优点 性能好（高并发），灵活性高，复杂性低，数据结构灵活
提供嵌入式文档功能，将经常查询的数据存储在同一个文档中
既可以根据键来构建索引，也可以根据内容构建索引
缺点 缺乏统一的查询语法
不适用情形 在不同的文档上添加事务，文档数据库并不支持文档间的事务。

图形数据库

  • image-20231114155418609
产品 Neo4J
数据模型 图结构
典型应用 专门用于处理具有高度相互关联关系的数据，比较适合于社交网络、模式识别、依赖分析、推荐系统以及路径寻找等问题
优点 灵活性高，支持复杂的图形算法，可用于构建复杂的关系图谱
缺点 复杂性高，只能支持一定的数据规模

NoSQL基石

CAP定理

  • 一个分布式计算系统来说，不可能同时满足以下三点:
  • 一致性(Consistency)：是指任何一个读操作总是能够读到之前完成的写操作的结果，也就 是在分布式环境中，多点的数据是一致的，或者说，所有节点在同一时间具有相同的数据；
  • 可用性(Availability)：是指快速获取数据，可以在确定的时间内返回操作结果，保证每个请 求不管成功或者失败都有响应；

  • 分区容忍性(Partition tolerance) ：是指当出现网络分区的情况时（即系统中的一部分节点无法和其他节点进行通信），分离的系统也能够正常运行，也就是说，系统中任意信息的丢失或失败不会影响系统的继续运作。

  • 核心：一个分布式系统不可能同时很好的满足一致性，可用性和 分区容错性这三个需求，最多只能同时较好的满足两个。

  • image-20231114160753341
  • CA：也就是强调一致性（C）和可用性（A），放弃分区容忍性（P），最简单 的做法是把所有与事务相关的内容都放到同一台机器上。很显然，这种做法会严 重影响系统的可扩展性。传统的关系数据库（MySQL、SQL Server和 PostgreSQL），都采用了这种设计原则，因此扩展性都比较差。
  • CP：也就是强调一致性（C）和分区容忍性（P），放弃可用性（A），当出现 网络分区的情况时，受影响的服务需要等待数据一致，因此在等待期间就无法对 外提供服务。
  • AP：也就是强调可用性（A）和分区容忍性（P），放弃一致性（C），允许系 统返回不一致的数据。

BASE

  • BASE是NoSQL数据库通常对可用性及一致性的弱要求原则:
  • BA基本可用性：基本可用性是指分布式系统在面临故障或分区情况下，仍然能够提供基本（部分）的功能和服务。一个分布式系统的一部分发生问题变得不可用时，其他部分仍然可以正常 使用，也就是允许分区失败的情形出现。
  • S软状态：软状态指的是在分布式系统中的数据状态不是严格的一致性状态，而是可以在一段时间内存在某种程度的不一致，具有一定的滞后性。
  • E最终一致性：经过一段时间后，所有副本的数据状态最终会达到一致。高并发的数据访问操作下，弱一致性不能保证后续访问读到的都是更新后的最新数据。（如DNS）

最终一致性

分类 - 因果一致性：如果进程 A通知进程 B 它已更新了一个数据项，那么进程 B 的后续访问将获得 A 写入的最新值。而与进程 A 无因果关系的进程 C 的访问，仍然遵守一般的最终一致性规则。 - “读己之所写”一致性：可以视为因果一致性的一个特例。当进程 A自己执行一个更新操作之后，它自己总是可以访问到更新过的值，绝不会看到旧值。 - 单调读一致性：如果进程已经看到过数据对象的某个值，那么任何后续访问都不会返回在那个值之前的值。 - 会话一致性：它把访问存储系统的进程放到会话的上下文中，只要会话还存在，系统就保证“读己之所写”一致性。如果由于某些失败情形令会话终止，就要建立新的会话，而且系统保证不会延续到新的会话。 - 单调写一致性：系统保证来自同一个进程的写操作顺序执行。

实现最终一致性
  • N — 数据复制的份数
  • W — 更新数据时需要保证写完成的节点数

  • R — 读取数据的时候需要读取的节点数

  • 如果W+R>N，写的节点和读的节点重叠，则是强一致性。例如对于 典型的一主一备同步复制的关系型数据库，N=2,W=2,R=1，则不管读 的是主库还是备库的数据，都是一致的。一般设定是R＋W = N+1， 这是保证强一致性的最小设定。

  • 如果W+R<=N，则是弱一致性。例如对于一主一备异步复制的关系型数据库，N=2,W=1,R=1，则如果读的是备库，就可能无法读取主库已 经更新过的数据，所以是弱一致性。
  • 如N=W,R=1，任何一个写节点失效，都会导致写失败，因此可用性会降低，但是由于数据分布的N个节点是同步写入的，因此可以保证强一致性。
  • 对于分布式系统，为了保证高可用性，一般设置N>=3。

NewSQL

  • 属于关系型数据库
  • NewSQL：对各种新的可扩展、高性能数据库的简称。
  • 具有NoSQL对海量数据的存储管理能力；并保持传统数据库支持ACID和SQL等特性，都支持关系数据模型，都使用SQL作为其主要的接口。
  • image-20231114164901539