什么是NoSQL数据库

2 什么是NoSQL？

21 NoSQL 概述

NoSQL(NoSQL = Not Only SQL )，意即“不仅仅是SQL”，

泛指非关系型的数据库。随着互联网web20网站的兴起，传统的关系数据库在应付web20网站，特别是超大规模和高并发的SNS类型的web20纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。NoSQL数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题，包括超大规模数据的存储。

（例如谷歌或Facebook每天为他们的用户收集万亿比特的数据）。这些类型的数据存储不需要固定的模式，无需多余 *** 作就可以横向扩展。

22 NoSQL代表

MongDB、 Redis、Memcache

3 关系型数据库与NoSQL的区别？

31 RDBMS

高度组织化结构化数据

结构化查询语言（SQL）

数据和关系都存储在单独的表中。

数据 *** 纵语言，数据定义语言

严格的一致性

基础事务

ACID

关系型数据库遵循ACID规则

事务在英文中是transaction，和现实世界中的交易很类似，它有如下四个特性：

A (Atomicity) 原子性

原子性很容易理解，也就是说事务里的所有 *** 作要么全部做完，要么都不做，事务成功的条件是事务里的所有 *** 作都成功，只要有一个 *** 作失败，整个事务就失败，需要回滚。比如银行转账，从A账户转100元至B账户，分为两个步骤：1）从A账户取100元；2）存入100元至B账户。这两步要么一起完成，要么一起不完成，如果只完成第一步，第二步失败，钱会莫名其妙少了100元。

C (Consistency) 一致性

一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。

I (Isolation) 独立性

所谓的独立性是指并发的事务之间不会互相影响，如果一个事务要访问的数据正在被另外一个事务修改，只要另外一个事务未提交，它所访问的数据就不受未提交事务的影响。比如现有有个交易是从A账户转100元至B账户，在这个交易还未完成的情况下，如果此时B查询自己的账户，是看不到新增加的100元的

D (Durability) 持久性

持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。

32 NoSQL

代表着不仅仅是SQL

没有声明性查询语言

没有预定义的模式

键 - 值对存储，列存储，文档存储，图形数据库

最终一致性，而非ACID属性

非结构化和不可预知的数据

CAP定理

高性能，高可用性和可伸缩性

分布式数据库中的CAP原理(了解)

CAP定理：

Consistency(一致性), 数据一致更新，所有数据变动都是同步的

Availability(可用性), 好的响应性能

Partition tolerance(分区容错性) 可靠性

P: 系统中任意信息的丢失或失败不会影响系统的继续运作。

定理：任何分布式系统只可同时满足二点，没法三者兼顾。

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，

因此，根据 CAP 原理将 NoSQL 数据库分成了满足 CA 原则、满足 CP 原则和满足 AP 原则三 大类：

CA - 单点集群，满足一致性，可用性的系统，通常在可扩展性上不太强大。

CP - 满足一致性，分区容忍性的系统，通常性能不是特别高。

AP - 满足可用性，分区容忍性的系统，通常可能对一致性要求低一些。

CAP理论就是说在分布式存储系统中，最多只能实现上面的两点。

而由于当前的网络硬件肯定会出现延迟丢包等问题，所以分区容忍性是我们必须需要实现的。

所以我们只能在一致性和可用性之间进行权衡，没有NoSQL系统能同时保证这三点。

说明：C：强一致性 A：高可用性 P：分布式容忍性

举例：

CA：传统Oracle数据库

AP：大多数网站架构的选择

CP：Redis、Mongodb

注意：分布式架构的时候必须做出取舍。

一致性和可用性之间取一个平衡。多余大多数web应用，其实并不需要强一致性。

因此牺牲C换取P，这是目前分布式数据库产品的方向。

4 当下NoSQL的经典应用

当下的应用是 SQL 与 NoSQL 一起使用的。

代表项目：阿里巴巴商品信息的存放。

去 IOE 化。

ps：I 是指 IBM 的小型机，很贵的，好像好几万一台；O 是指 Oracle 数据库，也很贵的，好几万呢；M 是指 EMC 的存储设备，也很贵的。

难点：

数据类型多样性。

数据源多样性和变化重构。

数据源改造而服务平台不需要大面积重构。

目录

ⅠopenGauss安全机制概览

ⅡopenGauss安全认证

ⅢopenGauss角色管理机制

ⅣopenGauss审计与追踪

1审计记录机制

2审计追踪机制

3统一审计

ⅤopenGauss数据安全技术

ⅥopenGauss云安全技术

ⅦopenGauss智能安全机制

四openGauss审计与追踪

openGauss在部署完成后，实际上会有多个用户参与数据管理。除了管理员用户外，更多的是创建的普通用户直接进行数据管理。用户的多样性会导致数据库存在一些不可预期的风险。如何快速发现和追溯到这些异常的行为，则需要依赖审计机制和审计追踪机制。

审计记录机制 01

审计记录的关键在于：

§ 定义何种数据库 *** 作行为需要进行日志记录。

§ 记录的事件以何种形式展现和存储。

只有有效的记录了所关心的行为信息，才能依据这些行为进行问题审计和追溯，实现对系统的一个有效监督。

正如我们在“三权分立模型”章节描述的，进行权限分离后，就出现了审计管理员（当然也可以使用普通角色管理模型中的系统管理员来担当）。审计管理员最重要的作用在于对管理员以及普通用户所有关心的行为进行记录和审计追溯。审计首先要定义审计哪些数据库行为，其次需要定义审计内容记录在什么文件中以及何种目录下，最后需要定义清楚应提供何种接口供审计管理员进行审计查询。

openGauss针对用户所关心的行为提供了基础审计能力，包括事件的发起者、发生的时间和发生的内容。openGauss的审计功能受总体开关audit_enabled控制，默认开启。该开关不支持动态加载，需要重启数据库后才可以使功能的性质发生改变。在总体开关的基础上，openGauss增加了每一个对应审计项的开关。只有相应的开关开启，对应的审计功能项才能生效。

不同于总体开关，每一个对应的子审计项都支持动态加载，在数据库运行期间修改审计开关的值，不需要重启数据库即可支持。审计的子项目包括如下的部分：

§ audit_login_logout：用户登录、注销审计

§ audit_database_process：数据库启动、停止、恢复和切换审计

§ audit_user_locked：用户锁定和解锁审计

§ audit_user_violation：用户访问越权审计

§ audit_grant_revoke：授权和回收权限审计

§ audit_system_object：数据库对象的Create、Alter和Drop *** 作审计

§ audit_dml_state：具体表的INSERT、UDPDATE和DELETE *** 作审计

§ audit_dml_state_select：select查询 *** 作审计

§ audit_copy_exec：copy行为审计

§ audit_function_exec：审计执行function的 *** 作

§ audit_set_parameter：审计设置参数的行为

定义完审计记录行为后，当数据库执行相关的 *** 作，内核独立的审计线程就会记录审计日志。

传统的审计日志保存方法有两种，记录到数据库的表中以及记录到OS文件中。前种方法由于表是数据库的对象，在符合权限的情况下就可以访问到该审计表，当发生非法 *** 作时，审计记录的准确性难以得到保证。而后种方法虽然需要用户维护审计日志，但是比较安全，即使一个账户可以访问数据库，但不一定有访问OS这个文件的权限。

与审计日志存储相关的配置参数及其含义定义如下：

§ audit_directory：字符串类型，定义审计日志在系统中的存储目录，一个相对于“/data”数据目录的路径，默认值为：/var/log/openGauss/perfadm/pg_audit，也可以由用户指定。

§ audit_resource_policy：布尔类型，控制审计日志的保存策略，即以空间还是时间限制为优先策略决定审计文件更新，默认值为on。

§ audit_space_limit：整型类型，定义允许审计日志占用的磁盘空间总量，默认值为1GB，在实际配置中需要结合环境进行总体考虑。

§ audit_file_remain_time：整型类型，定义保留审计日志的最短时间要求，默认值为90，单位为天。特别的，如果取值为0，则表示无时间限制。

§ audit_file_remian_threshold：整型类型，定义审计目录audit_directory下可以存储的审计文件个数。默认值为1048576。

§ audit_rotation_size：整型类型，定义单个审计日志文件的最大大小，当审计日志文件大小超过此参数值时，新创建一个审计文件。

§ audit_rotation_interval：整型类型，定义新创建一个审计日志文件的时间间隔。默认值为1天，单位为分钟。

通过上述的这些配置参数，系统管理员用户可以在查询任务发生后找到对应的审计日志，并进行有效归档。审计日志文件也会按照参数指定的规则来进行更新、轮换等。

审计追踪机制 02

openGauss将审计所产生的文件独立存放在审计文件中，并按照产生的先后顺序进行标记管理，并以特定的格式进行存储（默认为二进制格式文件）。当审计管理员需要进行审计查询时，通过执行函数pg_query_audit即可，其具体的语法如下所示：

其中，valid_start_time和valid_end_time定义了审计管理员将要审计的有效开始时间和有效结束时间；audit_log表示审计日志信息所在的归档路径，当不指定该参数时，默认查看链接当前实例的审计日志文件(不区分具体的审计文件)。

值得注意的是，valid_start_time和valid_end_time的有效值为从valid_start_time日期中的00:00:00开始到valid_end_time日期中23:59:59之间。由于审计日志中包含了众多的信息，如时间、地点、行为分类等等，审计管理在获得完整的信息后可以增加各种过滤条件来获得相对应的更明确的信息。

统一审计 03

传统审计依据开关定义了不同的审计组合行为。事实上，这种无区分对待的审计行为虽然记录了所有想要审计的行为，但是对于通过审计日志发现问题则显得不那么容易，且管理员无法为特定的用户定义特定的行为，反而造成了系统处理的负担。因此需要为审计添加更精细化管理的能力。

统一审计的目的在于通过一系列有效的规则在数据库内部有选择性执行有效的审计，从而简化管理，提高数据库生成的审计数据的安全性。本节所述的技术目前处于研发阶段，对应产品尚未向客户发布。

openGauss提供了一套完整的统一审计策略机制，依据不同任务的诉求对用户的行为进行定制化审计管理。更进一步，openGauss的统一审计不仅可以依据用户、依据表进行审计行为定义，同时还可以扩展至通过IP地址、APP的名称来过滤和限制需要审计的内容。实际的语法如下所示：

其中，privilege_audit_clause定义语法如下：

该语法定义了针对DDL类语句的审计策略，其中LABEL表示一组资产集合，即数据库对象的集合。access_audit_clause定义语法如下：

该语法定义了针对DML类语句的审计策略。filter_clause标记需要过滤的信息，常见的Filter types类型包括IP、APPS应用（访问的应用名）、ROLES（数据库系统用户）以及LABEL对象。

一个有效的统一审计策略可参见如下：

表示创建针对CREATE/ALTER/DROP *** 作的审计策略，审计策略只对dev用户在本地（local）执行CREATE/ALTER/DROP行为时生效。

未完待续

以上就是关于什么是NoSQL数据库全部的内容，包括:什么是NoSQL数据库、如何掌握openGauss数据库核心技术秘诀五：拿捏数据库安全（4）、等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！