非关系型的数据库

教程大全 2026-02-09 16:13:40 浏览次

随着互联网的快速发展,数据已经成为企业的重要资产，传统的数据库在处理海量数据、实时性需求以及高并发访问等方面逐渐暴露出不足，非关系型数据库应运而生，以其独特的优势成为新趋势下的数据存储解决方案，本文将介绍非关系型数据库的概念、特点、应用场景以及未来发展趋势。

非关系型数据库

概念

非关系型数据库（NoSQL）是一种非传统的关系型数据库，它不遵循传统的表格结构，而是采用键值对、文档、列族、图等数据模型，非关系型数据库具有灵活的数据模型、高扩展性、分布式存储等特点。

特点

（1）灵活的数据模型：非关系型数据库支持多种数据模型，如键值对、文档、列族、图等，可以满足不同场景下的数据存储需求。

（2）高扩展性：非关系型数据库采用分布式存储架构，能够实现横向扩展，满足海量数据的存储需求。

（3）分布式存储：非关系型数据库支持分布式存储，提高数据可用性和容错性。

（4）高性能：非关系型数据库针对海量数据和高并发访问进行了优化，能够提供高性能的数据读写能力。

非关系型数据库应用场景

大数据场景

随着大数据时代的到来,非关系型数据库在处理海量数据方面具有明显优势，Hadoop、Spark等大数据处理框架都采用了非关系型数据库作为数据存储解决方案。

实时性需求

非关系型数据库具有高性能的数据读写能力,能够满足实时性需求，在电子商务、在线游戏等领域，非关系型数据库可以提供快速的数据读写，提高用户体验。

高并发访问

非关系型数据库采用分布式存储架构,能够实现高并发访问，社交网络、在线视频等领域，非关系型数据库可以满足大量用户同时访问的需求。

非关系型数据库未来发展趋势

融合关系型数据库

随着非关系型数据库的不断发展,未来可能会出现更多融合关系型数据库与非关系型数据库的技术，这种混合型数据库将结合两种数据库的优势，提高数据存储和处理能力。

自动化运维

随着非关系型数据库的广泛应用,自动化运维将成为未来发展趋势，通过自动化运维，可以提高数据库的稳定性和可靠性，降低运维成本。

安全性提升

非关系型数据库在安全性方面将不断优化,以满足企业和用户对数据安全的需求，加密存储、访问控制等技术将在非关系型数据库中得到广泛应用。

非关系型数据库作为一种新型的数据存储解决方案,具有灵活的数据模型、高扩展性、分布式存储等特点，能够满足海量数据、实时性需求以及高并发访问等场景，随着技术的不断发展，非关系型数据库将在未来发挥更加重要的作用。

什么是DQL，DML，DDL，DCL-victorymoshui-ITPUB博客

DQLDQL:Data Query Language SELECT 数据查询语言select具体用法SELECT select_list[ INTO new_table ]FROM table_source[ WHERE search_condition ][ GROUP BY group_by_expression ][ HAVING search_condition ][ ORDER BY order_expression [ ASC | DESC ] ]例子：找出emp表中员工号为007的员工的工资SELECT emp tWHERE =007DML　DML = Data Manipulation Language，数据操纵语言，命令使用户能够查询数据库以及操作已有数据库中的数据的计算机语言。具体是指是SELECT查询、UPDATE更新、INSERT插入、DELETE删除。 DML（Data Manipulation Language）数据操纵语言，SQL的分类之一，此外还有DDL（Data DEFinition Language）数据定义语言和DCL（Data Control Language）数据控制语言。 DML包括：INSERT、UPDATE、DELETE。注意，select语句属于DQL(Data Query Language)。 DML分成交互型DML和嵌入型DML两类。依据语言的级别，DML又可分成过程性DML和非过程性DML两种。如insert,delete,update,select(插入、删除、修改、检索)等都是DML.交互型DML:这类DML自成系统，可在终端上直接对数据库进行操作。嵌入型DML:这类DML是嵌入在主语言中使用。此时主语言是经过扩充能处理DML语句的语言。过程性DML:用户编程时，不仅需要指出“做什么”(需要什么样的数据)，还需要指出“怎么做”(怎么获得数据)。层状、网状的DML属于过程性语言。非过程性DML:用户编程时，只需要指出“做什么”，不需要指出“怎么做”。关系型DML属于非过程性语言。 DDL数据库模式定义语言DDL(Data Definition Language)，是用于描述数据库中要存储的现实世界实体的语言。一个数据库模式包含该数据库中所有实体的描述定义。这些定义包括结构定义、操作方法定义等。数据库模式定义语言并非程序设计语言，DDL数据库模式定义语言是SQL语言（结构化程序设计语言）的组成部分。 SQL语言包括三种主要程序设计语言类别的语句：数据定义语言(DDL)，数据操作语言(DML)及数据控制语言(DCL)。 DDL描述的模式，必须由计算机软件进行编译，转换为便于计算机存储、查询和操纵的格式，完成这个转换工作的程序称为模式编译器。模式编译器处理模式定义主要产生两种类型的数据：数据字典以及数据类型和结构定义。数据字典和数据库内部结构信息是创建该模式所对应的数据库的依据，根据这些信息创建每个数据库对应的逻辑结构；对数据库数据的访问、查询也根据模式信息决定数据存取的方式和类型，以及数据之间的关系和对数据的完整性约束。数据字典是模式的内部信息表示，数据字典的存储方式对不同的DBMS各不相同。数据类型和结构的定义，是指当应用程序与数据库连接操作时，应用程序需要了解产生和提取的数据类型和结构。是为各种宿主语言提供的用户工作区的数据类型和结构定义，使用户工作区和数据库的逻辑结构相一致，减少数据的转换过程，这种数据类型和结构的定义通常用一个头文件来实现。数据库模式的定义通常有两种方式: 交互方式定义模式和通过数据描述语言 DDL 描述文本定义模式。 CREATE DATABASE 创建数据库CREATE {DATABASE | SCHEMA} db_name[create_specification [, create_specification] ...]create_specification:[DEFAULT] CHARACTER SET charset_name| [DEFAULT] COLLATE collation_nameCREATE TABLE创建数据库表格CREATE [TEMPORARY] TABLE tbl_name[(create_definition,...)][table_options] [select_statement]ALTER TABLE修改数据库表格ALTER TABLE tbl_namealter_specification [, alter_specification] _specification:ADD [COLUMN] column_definition [FIRST | AFTER col_name ]| ADD [COLUMN] (column_definition,...)| ADD INDEX (index_col_name,...)| ADD [CONSTRAINT [symbol]]PRIMARY KEY (index_col_name,...)| ADD [CONSTRAINT [symbol]]UNIQUE (index_col_name,...)| ADD (index_col_name,...)| ADD [CONSTRAINT [symbol]]FOREIGN KEY (index_col_name,...)[reference_definition]| ALTER [COLUMN] col_name {SET DEFAULT literal | DROP DEFAULT}| CHANGE [COLUMN] old_col_name column_definition[FIRST|AFTER col_name]| MODIFY [COLUMN] column_definition [FIRST | AFTER col_name]| DROP [COLUMN] col_name| DROP PRIMARY KEY| DROP INDEX index_name| DROP FOREIGN KEY fk_symbol| DISABLE KEYS| ENABLE KEYS| RENAME [TO] new_tbl_name| ORDER BY col_name| CONVERT TO CHARACTER SET charset_name [COLLATE collation_name]| [DEFAULT] CHARACTER SET charset_name [COLLATE collation_name]| DISCARD TABLESPACE| IMPORT TABLESPACE| table_optionsDROP TABLE删除数据库表格DROP [TEMPORARY] TABLEtbl_name [, tbl_name] ...[RESTRICT | CASCADE]CREATE VIEW创建查询命令CREATE [OR REPLACE] [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]VIEW view_name [(column_list)]AS select_statement[WITH [CASCADED | LOCAL] CHECK OPTION]ALTER VIEW修改查询命令ALTER [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]VIEW view_name [(column_list)]AS select_statement[WITH [CASCADED | LOCAL] CHECK OPTION]DROP VIEW删除查询命令DROP VIEWview_name [, view_name] ...[RESTRICT | CASCADE]DCLDCL（Data Control Language）是数据库控制语言。是用来设置或更改数据库用户或角色权限的语句，包括（grant,deny,revoke等）语句。在默认状态下，只有sysadmin,dbcreator,db_owner或db_securityadmin等人员才有权力执行DCLDCL数据库控制语言不同于程序设计语言，SQL语言（结构化程序设计语言）的组成部分包括了DCL数据库控制语言。 SQL语言包括三种主要程序设计语言类别的语句：数据定义语言(DDL)，数据操作语言(DML)及数据控制语言(DCL)。

如何正确的使用MongoDB并优化其性能

e799bee5baa6e79fa5ee4b893e5b19e136数据库性能对软件整体性能的影响是不言而喻的，那么，当我们使用MongoDB时改如何提高数据库性能呢？1.范式化与反范式化在项目设计阶段，明确集合的用途是对性能调优非常重要的一步。从性能优化的角度来看，集合的设计我们需要考虑的是集合中数据的常用操作，例如我们需要设计一个日志（log）集合，日志的查看频率不高，但写入频率却很高，那么我们就可以得到这个集合中常用的操作是更新（增删改）。如果我们要保存的是城市列表呢？显而易见，这个集合是一个查看频率很高，但写入频率很低的集合，那么常用的操作就是查询。对于频繁更新和频繁查询的集合，我们最需要关注的重点是他们的范式化程度，在上篇范式化与反范式化的介绍中我们了解到，范式化与反范式化的合理运用对于性能的提高至关重要。然而这种设计的使用非常灵活，假设现在我们需要存储一篇图书及其作者，在MongoDB中的关联就可以体现为以下几种形式：1.完全分离（范式化设计）示例1：View Code{ _id : ObjectId(5124b5dc7dca), title : 如何使用MongoDB, author : [ ObjectId(144b5dc7dca),ObjectId(144b5dc7dca),ObjectId(144b5dc7dca), ] }我们将作者(comment) 的id数组作为一个字段添加到了图书中去。这样的设计方式是在非关系型数据库中常用的，也就是我们所说的范式化设计。在MongoDB中我们将与主键没有直接关系的图书单独提取到另一个集合，用存储主键的方式进行关联查询。当我们要查询文章和评论时需要先查询到所需的文章，再从文章中获取评论id，最后用获得的完整的文章及其评论。在这种情况下查询性能显然是不理想的。但当某位作者的信息需要修改时，范式化的维护优势就凸显出来了，我们无需考虑此作者关联的图书，直接进行修改此作者的字段即可。 2.完全内嵌（反范式化设计）示例2：View Code{ _id : ObjectId(5124b5dc7dca), title : 如何使用MongoDB, author : [{ name : 丁磊 age : 40,　nationality : china,},{ name : 马云 age : 49, nationality : china,},{ name : 张召忠 age : 59, nationality : china,},]} 在这个示例中我们将作者的字段完全嵌入到了图书中去，在查询的时候直接查询图书即可获得所对应作者的全部信息，但因一个作者可能有多本著作，当修改某位作者的信息时时，我们需要遍历所有图书以找到该作者，将其修改。 3.部分内嵌（折中方案）示例3：View Code{ _id : ObjectId(5124b5dc7dca), title : 如何使用MongoDB, author : [ {　_id : ObjectId(144b5dc7dca), name : 丁磊},{ _id : ObjectId(144b5dc7dca), name : 马云},{ _id : ObjectId(144b5dc7dca), name : 张召忠},]}这次我们将作者字段中的最常用的一部分提取出来。当我们只需要获得图书和作者名时，无需再次进入作者集合进行查询，仅在图书集合查询即可获得。这种方式是一种相对折中的方式，既保证了查询效率，也保证的更新效率。但这样的方式显然要比前两种较难以掌握，难点在于需要与实际业务进行结合来寻找合适的提取字段。如同示例3所述，名字显然不是一个经常修改的字段，这样的字段如果提取出来是没问题的，但如果提取出来的字段是一个经常修改的字段（比如age）的话，我们依旧在更新这个字段时需要大范围的寻找并依此进行更新。在上面三个示例中，第一个示例的更新效率是最高的，但查询效率是最低的，而第二个示例的查询效率最高，但更新效率最低。所以在实际的工作中我们需要根据自己实际的需要来设计表中的字段，以获得最高的效率。