图数据库：从传统关系型数据库说起_什么是传统关系型数据库?请例举一个具体关系型数据库软件

1.数据库

按照早期的数据库理论，比较流行的数据库模型有三种，分别为层次式数据库、网状数据库和关系型数据库。而在当今的互联网中，最常见的数据库模型主要是两种，即SQL关系型数据库和NoSQL非关系型数据库。

2.什么是关系型数据库

关系型数据库，是指采用了关系模型来组织数据的数据库，其以行和列的形式存储数据，以便于用户理解，关系型数据库这一系列的行和列被称为表，一组表组成了数据库。用户通过查询来检索数据库中的数据，而查询是一个用于限定数据库中某些区域的执行代码。关系模型可以简单理解为二维表格模型，而一个关系型数据库就是由二维表及其之间的关系组成的一个数据组。

3.常用名词介绍

3.1. 数据库（Database，简称DB）是按照数据结构来组织、存储和管理数据的仓库；

3.2. 数据库管理系统（Database Managerment System，简称DBMS）:管理数据库的软件；

3.3. SQL可分为：

• 3.3.1 数据定义语言（DDL）：Data Defintion Language;

    数据定义语言（DDL）：Data Defintion Language
    · 用于建立、修改、删除数据对象；

    · 包括：
    - CREATE：创建表或其他对象结构；
    - ALTER：修改表或其他对象的结构；
    - DROP：删除表或其他对象结构；
    - TRUNCATE：删除表数据，保留表结构；
1
2
3
4
5
6
7
8

• 3.3.3 事务控制语言（TCL）: Transaction Control Language;

    数据操作语言（DML）：Data Manipulation Language
    · 用于改变数据表中的数据；
    · 和事务相关，执行完成后需要经过事务控制语句提交后才真正的将改变应  用到数据库中；

    · 包括：    
     - INSERT：将数据插入到数据库中；
     - UPDATE：更新数据表中已存在的数据；
     - DELETE：删除数据表中的数据；
1
2
3
4
5
6
7
8

• 3.3.4 数据查询语句（DQL）: Data Query Language；

    数据查询语句（DQL）: Data Query Language
    · 用来查询所需要的数据；
    · SELECT语句；
1
2
3

• 3.3.5 数据控制语言（DCL）：Data Control Language；

    数据控制语言（DCL）：Data Control Language
    · 用于执行权限的授予和回收操作；

    · 包括：
      - GRANT：授予，用于给用户或角色授予权限；
      - REVOKE：用于回收用户或角色已有的权限；
      - CREATE USER：创建用户；
1
2
3
4
5
6
7

• 3.3.6 数据操作语言（DML）：Data Manipulation Language;

• 3.3.7 事务控制语言（TCL）: Transaction Control Language;

    事务控制语言（TCL）: Transaction Control Language
    · 用来维护数据一致性的语句

    · 包括：
      - COMMIT：提交，确认已经进行的数据改变；
      - ROLLBACK：回滚，取消已经进行的数据改变；
      - SAVEPOINT：保存点，使当前事务可以回退到指定的保存点，便于取消   部分改变；
1
2
3
4
5
6
7

3.4 ACID事务

• 3.4.1 原子性（Atomicity）
  事务必须是一个自动工作的单元，要么全部执行，要么全部不执行。
• 3.4.2 一致性（Consistent）
  事务结束的时候，所有的内部数据都是正确的。
• 3.4.3 隔离性（Isolation）
  并发多个事务时，各个事务不干涉内部数据，处理的都是另外一个事务处理之前或之后的数据。
• 3.4.4 持久性(Durability)
  事务提交之后，数据是永久性的，不可再回滚。

4.主流关系型数据库

先来一下排名，此排名截至到2020年10月

如果需要关注实时排名可以关注：https://db-engines.com/en/ranking

4.1 Oracle 数据库

4.1.1 介绍

1. Oracle是著名的Oracle（甲骨文）公司的数据库产品；
2. Oracle是世界上第一个商品化的关系型数据库管理系统；
3. Oracle采用标准SQL（结构化查询语句），支持多种数据类型，提供面向对象的数据支持，具有第四代语言开发工具；支持UNIX、WINDOWS、OS/2等多种平台；

4.Oracle19c和20c的新特性：https://www.modb.pro/doc/1291?leiZH

4.1.2 优点

1. Oracle 能在所有主流平台上运行（包括 windows）完全支持所有工业标准采用完全开放策略使客户选择适合解决方案对开发商全力支持。
2. Oracle 并行服务器通过使组结点共享同簇工作来扩展windownt能力提供高用性和高伸缩性簇解决方案windowsNT能满足需要用户把数据库移UNIXOracle并行服务器对各种UNIX平台集群机制都有着相当高集成度。
3. 获得最高认证级别的ISO标准认证。
4. Oracle 性能高 保持开放平台下TPC-D和TPC-C世界记录。
5. Oracle 多层次网络计算支持多种工业标准用ODBC、JDBC、OCI等网络客户连接。
6. Oracle 长时间开发经验完全向下兼容得广泛应用地风险低。

4.1.3 缺点

1. 对硬件的要求很高。
2. 价格比较昂贵。
3. 管理维护麻烦一些。
4. 操作比较复杂，需要技术含量较高。

---

---

4.2 MySQL数据库概述

4.2.1 介绍

1. MySQL是开放源码的小型关系型数据库管理系统，广泛应用在中小型网站中；
2. 总体拥有成本低，规模较Oracle和DB2小
3. 2008年1月16日，Sun收购了MySQL;2009年4月20日，SUN被Oracle公司收购了，所以现在MySQL是属于Oracle的；

4.2.2 优点

1. 体积小、速度快、总体拥有成本低，开源，提供的接口支持多种语言连接操作。
2. 支持多种操作系统。
3. MySQL 的核心程序采用完全的多线程编程。线程是轻量级的进程，它可以灵活地为用户提供服务，而不过多的系统资源。用多线程和C语言实现的MySQL 能很容易充分利用CPU。
4. MySQL 有一个非常灵活而且安全的权限和口令系统。当客户与MySQL 服务器连接时，他们之间所有的口令传送被加密，而且MySQL 支持主机认证。
5. MySQL 能够提供很多不同的使用者界面，包括命令行客户端操作，网页浏览器，以及各式各样的程序语言界面，例如 C++，Perl，Java，PHP，以及Python。你可以使用事先包装好的客户端，或者干脆自己写一个合适的应用程序。MySQL可用于 Unix，Windows，以及OS/2等平台，因此它可以用在个人电脑或者是服务器上。

4.2.3 缺点

1. 不支持热备份。
2. MySQL不支持自定义数据类型
3. MySQL最大的缺点是其安全系统，主要是复杂而非标准，另外只有到调用mysqladmin来重读用户权限时才发生改变。
4. MySQL对存储过程和触发器支持不够良好。
5. 尽管 MySQL 理论上仍是开源产品，也有人抱怨它诞生之后更新缓慢。然而，应该注意到有一些基于 MySQL 并完整集成的数据库（如 MariaDB），在标准的 MySQL 基础上带来了额外价值。
6. MySQL对XML支持不够良好

4.2.3 何时使用 ？

1. 分布式操作:
   当你需要的比SQLite可以提供的更多时，把MySQL包括进你的部署栈，就像任何一个独立的数据库服务器，会带来大量的操作自由和一些先进的功能。
2. 高安全性:
   MySQL的安全功能，用一种简单的方式为数据访问（和使用）提供了可靠的保护。
3. Web网站 和 Web应用:
   绝大多数的网站（和Web应用程序）可以忽视约束性地简单工作在MySQL上。这种灵活的和可扩展的工具是易于使用和易于管理的——这被证明非常有助于长期运行。
4. 定制解决方案:

如果你工作在一个高度量身定制的解决方案上，MySQL能够很容易地尾随和执行你的规则，这要感谢其丰富的配置设置和操作模式。

---

---

4.3 SQL Server数据库概述

4.3.1 介绍

1. MicrosoftSQL Server是微软的产品，运行在Windows NT服务器上；
   优点

4.3.2 优点

1. 易用性、适合分布式组织的可伸缩性、用于决策支持的数据仓库功能、与许多其他服务器软件紧密关联的集成性、良好的性价比等；
2. 为数据管理与分析带来了灵活性，允许单位在快速变化的环境中从容响应，从而获得竞争优势。从数据管理和分析角度看，将原始数据转化为商业智能和充分利用Web带来的机会非常重要。作为一个完备的数据库和数据分析包，SQLServer为快速开发新一代企业级商业应用程序、为企业赢得核心竞争优势打开了胜利之门。 作为重要的基准测试可伸缩性和速度奖的记录保持者，SQLServer是一个具备完全Web支持的数据库产品，提供了对可扩展标记语言 (XML)的核心支持以及在Internet上和防火墙外进行查询的能力；

4.3.3 缺点

1. SQL Server 只能windows上运行，没有丝毫开放性操作系统，系统稳定对数据库十分重要，WindowsX系列产品偏重于桌面应用，NT server只适合小型企业，而且windows平台可靠性、安全性和伸缩性非常有限。
2. SQL server 并行实施和共存模型并成熟难处理日益增多用户数和数据卷伸缩性有限；
3. 没有获得任何安全证书。
4. SQL Server 多用户时性能佳。

---

---

4.4 PostgreSql数据库

4.3.1 介绍

PostgreSQL是一个自由的对象-关系数据库服务器(数据库管理系统),支持大部分 SQL标准并且提供了许多其他现代特性：复杂查询、外键、触发器、视图、事务完整性、MVCC。同样，PostgreSQL 可以用许多方法扩展，比如， 通过增加新的数据类型、函数、操作符、聚集函数、索引。免费使用、修改、和分发 PostgreSQL。

4.4.2 优点

1. PostgreSQL 是一个开源的，免费的，同时非常强大的关系型数据管理系统。
2. PostgreSQL 背后有热忱而经验丰富的社区，可以通过知识库和问答网站获取支持，全天候免费。
3. 即使其本身功能十分强大，PostgreSQL 仍附带有许多强大的开源第三方工具来辅助系统的设计、管理和使用。
4. 可以用预先存储的流程来程序性扩展 PostgreSQL ，一个高级的关系型数据库理应如此。
5. PostgreSQL 不只是一个关系型数据库，还是一个面向对象数据库——支持嵌套，及一些其他功能。

4.4.3 缺点

1. 对于简单而繁重的读取操作, 超过了 PostgreSQL 的杀伤力，可能会出现比同行（如MySQL）更低的性能。
2. 按给出的该工具的性质，从普及度来说它还缺乏足够后台支撑，尽管有大量的部署——这可能会影响能够获得支持的容易程度。

---

---

4.5 Access DB

4.5.1 介绍

1. Microsoft Access只是Microsoft整体数据管理产品战略的一部分。它基于Access Jet数据库引擎以自己的格式存储数据。像关系数据库一样，Microsoft Access也允许链接相关信息。

4.4.2 优点

1. Access数据库是Windows平台上最为兼容的文件型数据库

4.4.3 缺点

1. Access数据库存在文件上限2G大小的问题，单文件无法超过2G大小，如果一个表的内容超过2G便是灾难
2. 独占数据库，无法多连接操作
3. 没有事务的概念

---

---

4.6 Sqlite数据库

4.6.1 介绍

SQLite，是一款轻型的数据库，是遵守ACID的关系型数据库管理系统，它包含在一个相对小的C库中。它是D.RichardHipp建立的公有领域项目。它的设计目标是嵌入式的，而且已经在很多嵌入式产品中使用了它，它占用资源非常的低，在嵌入式设备中，可能只需要几百K的内存就够了。它能够支持Windows/Linux/Unix等等主流的操作系统，同时能够跟很多程序语言相结合，比如 Tcl、C#、PHP、Java等，还有ODBC接口，同样比起Mysql、PostgreSQL这两款开源的世界著名数据库管理系统来讲，它的处理速度比他们都快。SQLite第一个Alpha版本诞生于2000年5月。 至2019年已经有19个年头，SQLite也迎来了一个版本 SQLite 3已经发布。

4.6.2 优点

1. 轻量级：SQLite是轻量级的，没有客户端和服务器端之分，并且是跨平台的关系型数据库。SQLite是一个单文件的，可以copy出来在其他地方用。
2. 绿色版：SQLite的另外一个特点是绿色：它的核心引擎本身不依赖第三方的软件，使用它也不需要“安装”。所以在部署的时候能够省去不少麻烦。
3. 单一文件：所谓的“单一文件”，就是数据库中所有的信息（比如表、视图、触发器、等）都包含在一个文件内。这个文件可以copy到其它目录或其它机器上，也照用不误。
4. 跨平台/可移植性：如果光支持主流操作系统，那就没啥好吹嘘的了。除了主流操作系统，SQLite还支持了很多冷门的操作系统。我个人比较感兴趣的是它对很多嵌入式系统（比如Android、WindowsMobile、Symbin、Palm、VxWorks等）的支持。
5. 内存数据库（in-memory database）：这年头，内存越来越便宜，很多普通PC都开始以GB为单位来衡量内存（服务器就更甭提了）。这时候，SQLite的内存数据库特性就越发显得好用。

4.6.2 缺点

1. 并发访问的锁机制：SQLite在并发（包括多进程和多线程）读写方面的性能一直不太理想。数据库可能会被写操作独占，从而导致其它读写操作阻塞或出错。
2. SQL标准支持不全：在它的官方网站上，具体列举了不支持哪些SQL92标准。我个人感觉比较不爽的是不支持外键约束。
3. 网络文件系统（以下简称NFS）：有时候需要访问其它机器上的SQLite数据库文件，就会把数据库文件放置到网络共享目录上。这时候你就要小心了。当SQLite文件放置于NFS时，在并发读写的情况下可能会出问题（比如数据损坏）。原因据说是由于某些NFS的文件锁实现上有Bug。
4. 授权协议（License）：SQLite使用的是PublicDomain协议，这是最爽一种，可以放心大胆地用。
5. 用户的普及程度：最近这几年，使用SQLite的人越来越多（从Google Trends可以反应出来）。包括一些大公司也开始把它整合到产品中（比如Google的Gears、Apple的Safari、Adobe的AIR）。这说明它的健壮性、稳定性等方面不会有太大问题。
   6.开发的活跃程度：如果到SQLite的Change Log上大致了解一下，可以看出最近5年基本上每1-2个月都会有更新。说明开发的活跃度还是非常高的。

5.关系型数据库能干什么

从数据结构上来看关系型数据库就是列表、集合。
如：所有人的基本信息[UserInfo]

通过以上的简单的结构固化的存储在关系型数据库中，当需要使用时使用，如需要查询年龄在17岁以上人的信息时.

select * from UserInfo where age>17

查询结果为：

基于以上的基本功能逐步演变有：

• 联表查询
• 视图
• 事务
• 日志
• 备份与恢复
• 迁移
  等等

6 关系数据库在某些方向上存在的乏力与瓶颈

1. 传统的关系数据库具有不错的性能，高稳定型，久经历史考验，而且使用简单，功能强大，同时也积累了大量的成功案例。在互联网领域，MySQL成为了绝对靠前的王者，毫不夸张的说，MySQL为互联网的发展做出了卓越的贡献。
2. 在90年代，一个网站的访问量一般都不大，用单个数据库完全可以轻松应付。在那个时候，更多的都是静态网页，动态交互类型的网站不多。
3. 到了最近10年，网站开始快速发展。火爆的论坛、博客、sns、微博逐渐引领web领域的潮流。在初期，论坛的流量其实也不大，如果你接触网络比较早，你可能还记得那个时候还有文本型存储的论坛程序，可以想象一般的论坛的流量有多大。

这个时候就出现如下几个方面的数据库开始在各自的业务场景下搔首弄姿

6.1 HBase

HBase是一个分布式的、面向列的开源数据库，该技术来源于 Fay Chang 所撰写的Google论文“Bigtable：一个结构化数据的分布式存储系统”。就像Bigtable利用了Google文件系统（File System）所提供的分布式数据存储一样，HBase在Hadoop之上提供了类似于Bigtable的能力。HBase是Apache的Hadoop项目的子项目。HBase不同于一般的关系数据库，它是一个适合于非结构化数据存储的数据库。另一个不同的是HBase基于列的而不是基于行的模式。
Hbase是一种NoSQL数据库，这意味着它不像传统的RDBMS数据库那样支持SQL作为查询语言。Hbase是一种分布式存储的数据库，技术上来讲，它更像是分布式存储而不是分布式数据库，它缺少很多RDBMS系统的特性，比如列类型，辅助索引，触发器，和高级查询语言等待。那Hbase有什么特性呢？如下：

6.1.1 特性

1. 强读写一致，但是不是“最终一致性”的数据存储，这使得它非常适合高速的计算聚合
2. 自动分片，通过Region分散在集群中，当行数增长的时候，Region也会自动的切分和再分配
   自动的故障转移
   Hadoop/HDFS集成，和HDFS开箱即用，不用太麻烦的衔接
   丰富的“简洁，高效”API，Thrift/REST API，Java API
   块缓存，布隆过滤器，可以高效的列查询优化
   操作管理，Hbase提供了内置的web界面来操作，还可以监控JMX指标
   什么时候用Hbase？

6.1.2 Hbase不适合解决所有的问题：

首先数据库量要足够多，如果有十亿及百亿行数据，那么Hbase是一个很好的选项，如果只有几百万行甚至不到的数据量，RDBMS是一个很好的选择。因为数据量小的话，真正能工作的机器量少，剩余的机器都处于空闲的状态
其次，如果你不需要辅助索引，静态类型的列，事务等特性，一个已经用RDBMS的系统想要切换到Hbase，则需要重新设计系统。
最后，保证硬件资源足够，每个HDFS集群在少于5个节点的时候，都不能表现的很好。因为HDFS默认的复制数量是3，再加上一个NameNode。
Hbase在单机环境也能运行，但是请在开发环境的时候使用。

6.1.3 优势

1. 存储容量大，一个表可以容纳上亿行，上百万列；
2. 可通过版本进行检索，能搜到所需的历史版本数据；
3. 负载高时，可通过简单的添加机器来实现水平切分扩展，跟Hadoop的无缝集成保障了其数据可靠性（HDFS）和海量数据分析的高性能（MapReduce）；
4. 在第3点的基础上可有效避免单点故障的发生。

6.1.4 缺点

1. 基于Java语言实现及Hadoop架构意味着其API更适用于Java项目；
2. node开发环境下所需依赖项较多、配置麻烦（或不知如何配置，如持久化配置），缺乏文档；
3. 占用内存很大，且鉴于建立在为批量分析而优化的HDFS上，导致读取性能不高；
4. API相比其它 NoSql 的相对笨拙。

6.1.5 适用场景

1. bigtable类型的数据存储；
2. 对数据有版本查询需求；
3. 应对超大数据量要求扩展简单的需求。

6.2 Redis

Redis 是一个开源的使用ANSI C语言编写、支持网络、可基于内存亦可持久化的日志型、Key-Value数据库，并提供多种语言的API。目前由VMware主持开发工作。

6.2.1. 特点

1. 数据格式

Redis 通常被称为数据结构服务器，因为值（value）可以是 字符串(String), 哈希(Hash/Map), 列表(list), 集合(sets) 和 有序集合(sorted sets)五种类型，操作非常方便。比如，如果你在做好友系统，查看自己的好友关系，如果采用其他的key-value系统，则必须把对应的好友拼接成字符串，然后在提取好友时，再把value进行解析，而redis则相对简单，直接支持list的存储(采用双向链表或者压缩链表的存储方式)。

⑴ String
string 是 Redis 最基本的类型，你可以理解成与 Memcached 一模一样的类型，一个key对应一个value。
string 类型是二进制安全的。意思是 Redis 的 string 可以包含任何数据。比如 jpg 图片或者序列化的对象 。
string 类型是 Redis 最基本的数据类型，一个键最大能存储512MB。
⑵ Hash
Redis hash 是一个键值对集合。
Redis hash 是一个 string 类型的 field 和 value 的映射表，hash 特别适合用于存储对象。
⑶ List
Redis 列表是简单的字符串列表，按照插入顺序排序。你可以添加一个元素导列表的头部（左边）或者尾部（右边）。
⑷ Sets
Redis的Set是string类型的无序集合。 集合是通过哈希表实现的，所以添加，删除，查找的复杂度都是O(1)。
⑸ sorted sets/zset
Redis zset 和 set 一样也是string类型元素的集合,且不允许重复的成员。 不同的是每个元素都会关联一个double类型的分数。redis正是通过分数来为集合中的成员进行从小到大的排序。

2. 性能
   Redis数据库完全在内存中，因此处理速度非常快，每秒能执行约11万集合，每秒约81000+条记录（测试数据的可参考这篇《Redis千万级的数据量的性能测试》）。
   Redis的数据能确保一致性——所有Redis操作是原子性（Atomicity，意味着操作的不可再分，要么执行要么不执行）的，这保证了如果两个客户端同时访问的Redis服务器将获得更新后的值。

3. 持久化
   通过定时快照（snapshot）和基于语句的追加（AppendOnlyFile，aof）两种方式，redis可以支持数据持久化——将内存中的数据存储到磁盘上，方便在宕机等突发情况下快速恢复。

4. CAP类别
   属于CP类型（了解更多）。

5. Node下的使用
   node 下可使用 node_redis 来实现 redis 客户端操作：

6.2.3. 优势

1. 非常丰富的数据结构；
2. Redis提供了事务的功能，可以保证一串 命令的原子性，中间不会被任何操作打断；
3. 数据存在内存中，读写非常的高速，可以达到10w/s的频率。

6.2.3. 缺点

1. Redis3.0后才出来官方的集群方案，但仍存在一些架构上的问题（出处）；
2. 持久化功能体验不佳——通过快照方法实现的话，需要每隔一段时间将整个数据库的数据写到磁盘上，代价非常高；而aof方法只追踪变化的数据，类似于mysql的binlog方法，但追加log可能过大，同时所有操作均要重新执行一遍，恢复速度慢；
3. 由于是内存数据库，所以，单台机器，存储的数据量，跟机器本身的内存大小。虽然redis本身有key过期策略，但是还是需要提前预估和节约内存。如果内存增长过快，需要定期删除数据。

6.2.4. 适用场景

适用于数据变化快且数据库大小可遇见（适合内存容量）的应用程序。更具体的可参照这篇《Redis 的 5 个常见使用场景》译文。

在这篇文章中，我们将阐述 Redis 最常用的使用场景，以及那些影响我们选择的不同特性。

1、会话缓存（Session Cache）
最常用的一种使用Redis的情景是会话缓存（session cache）。用Redis缓存会话比其他存储（如Memcached）的优势在于：Redis提供持久化。当维护一个不是严格要求一致性的缓存时，如果用户的购物车信息全部丢失，大部分人都会不高兴的，现在，他们还会这样吗？
幸运的是，随着 Redis 这些年的改进，很容易找到怎么恰当的使用Redis来缓存会话的文档。甚至广为人知的商业平台Magento也提供Redis的插件。

2、全页缓存（FPC）
除基本的会话token之外，Redis还提供很简便的FPC平台。回到一致性问题，即使重启了Redis实例，因为有磁盘的持久化，用户也不会看到页面加载速度的下降，这是一个极大改进，类似PHP本地FPC。
再次以Magento为例，Magento提供一个插件来使用Redis作为 全页缓存后端。
此外，对WordPress的用户来说，Pantheon有一个非常好的插件   wp-redis，这个插件能帮助你以最快速度加载你曾浏览过的页面。

3、队列
Reids在内存存储引擎领域的一大优点是提供 list 和 set 操作，这使得Redis能作为一个很好的消息队列平台来使用。Redis作为队列使用的操作，就类似于本地程序语言（如Python）对 list 的 push/pop 操作。
如果你快速的在Google中搜索“Redis queues”，你马上就能找到大量的开源项目，这些项目的目的就是利用Redis创建非常好的后端工具，以满足各种队列需求。例如，Celery有一个后台就是使用Redis作为broker，你可以从 这里去查看。

4、排行榜/计数器
Redis在内存中对数字进行递增或递减的操作实现的非常好。集合（Set）和有序集合（Sorted Set）也使得我们在执行这些操作的时候变的非常简单，Redis只是正好提供了这两种数据结构。所以，我们要从排序集合中获取到排名最靠前的10个用户–我们称之为“user_scores”，我们只需要像下面一样执行即可：
当然，这是假定你是根据你用户的分数做递增的排序。如果你想返回用户及用户的分数，你需要这样执行：
ZRANGE user_scores 0 10 WITHSCORES
Agora Games就是一个很好的例子，用Ruby实现的，它的排行榜就是使用Redis来存储数据的，你可以在 这里看到。

5、发布/订阅
最后（但肯定不是最不重要的）是Redis的发布/订阅功能。发布/订阅的使用场景确实非常多。我已看见人们在社交网络连接中使用，还可作为基于发布/订阅的脚本触发器，甚至用Redis的发布/订阅功能来建立聊天系统！（不，这是真的，你可以去核实）。

Redis提供的所有特性中，我感觉这个是喜欢的人最少的一个，虽然它为用户提供如果此多功能。
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

6.3 MongoDB

MongoDB 是一个高性能，开源，无模式的文档型数据库，开发语言是C++。它在许多场景下可用于替代传统的关系型数据库或键/值存储方式。

6.3.1. 特点

1. 数据格式
   在 MongoDB 中，文档是对数据的抽象，它的表现形式就是我们常说的 BSON（Binary JSON ）。
   BSON 是一个轻量级的二进制数据格式。MongoDB 能够使用 BSON，并将 BSON 作为数据的存储存放在磁盘中。
   BSON 是为效率而设计的，它只需要使用很少的空间，同时其编码和解码都是非常快速的。即使在最坏的情况下，BSON格式也比JSON格式再最好的情况下存储效率高。

6.3.2. 优势

1. 强大的自动化 shading 功能（更多戳这里）；
2. 全索引支持，查询非常高效；
3. 面向文档（BSON）存储，数据模式简单而强大。
4. 支持动态查询，查询指令也使用JSON形式的标记，可轻易查询文档中内嵌的对象及数组。
5. 支持 javascript 表达式查询，可在服务器端执行任意的 javascript函数。

6.3.3. 缺点

1. 单个文档大小限制为16M，32位系统上，不支持大于2.5G的数据；
2. 对内存要求比较大，至少要保证热数据（索引，数据及系统其它开销）都能装进内存；
3. 非事务机制，无法保证事件的原子性。

6.3.4. 适用场景

1. 适用于实时的插入、更新与查询的需求，并具备应用程序实时数据存储所需的复制及高度伸缩性；
2. 非常适合文档化格式的存储及查询；
3. 高伸缩性的场景：MongoDB 非常适合由数十或者数百台服务器组成的数据库。
4. 对性能的关注超过对功能的要求。

6.4 Neo4j

1. 在高速发展的互联网应用中，业务需求的频繁变更和数据的快速增长都要求数据库必须具有很强的适应能力。Neo4j图数据库正是一个能够适应这种业务需求不断变化和大规模数据增长而产生的数据库，它不但具有很强的适应能力，而且能够自始至终保持高效的查询性能。
2. 现实世界中的一切事物都处在联系之中，如人际关系、电脑网络、地理数据、分子结构模型等，无一不处在纷繁复杂的联系之中。这种联系形成了一种互相关联的数据，联系才是数据的本质所在。传统的关系型数据库并不能很好地表现数据的联系，而一些NoSQL（Not Only SQL，非关系型数据库）数据库又不能表现数据之间的联系。同样是NoSQL的Neo4j图数据库是以图的结构形式来存储数据的，它所存储的就是联系的数据，是关联数据本身。
3. 关联数据中的联系本来就很复杂，若要在关系型数据库中使用结构化形式来表现这种联系，则一般不能直接表示，处理起来既烦琐又费事，并且随着数据的不断增长，其访问性能将日趋下降。无数的开发人员和数据库管理人员都或多或少地使用过关系型数据库，在其应用的规模化进展过程中，对于数据库的性能优化往往捉襟见肘、陷入窘境。Neo4j没有模式结构的定义，也不需要这些定义，它使用非结构化的方式来存储关联数据，所以能够直接表现数据的关联特性。
4. Neo4j不管是与关系型数据库相比，还是与其他NoSQL数据库相比，都具有很多前所未有的优势，这可以从以下几个方面来分析，主要表现为查询的高性能、设计的灵活性和开发的敏捷性等。

6.3.2. 优点：

数据的插入，查询操作很直观，不用再像之前要考虑各个表之间的关系。
提供的图搜索和图遍历方法很方便，速度也是比较快的。

6.3.2. 缺点：

最不能让人忍受的就是极慢的插入速度。可能是因为创建节点和边的时候需要保存一些额外信息（为了查询服务）。不知道是不是我代码的问题，插入10000个节点，10000条边花了将近10分钟…
超大节点。当有一个节点的边非常多时（常见于大V），有关这个节点的操作的速度将大大下降。这个问题很早就有了，官方也说过会处理，然而现在仍然不能让人满意。
提高数据库速度的常用方法就是多分配内存，然而看了官方操作手册，貌似无法直接设置数据库内存占用量，而是需要计算后为其”预留“内存…

4. 适用场景
   鉴于其明显的优缺点，Neo4j适合存储”修改较少，查询较多，没有超大节点“的图数据。

另外，针对Neo4j的缺点，有一款使用混合索引的数据库Arangodb也许是一个不错的考虑对象。根据其官网的说明，Arangodb不仅具有一般图形数据库的优点，而且在各种操作的速度上领先于Neo4j。

https://www.arangodb.com/2016/04/index-free-adjacency-hybrid-indexes-graph-databases/

，10000条边花了将近10分钟…
超大节点。当有一个节点的边非常多时（常见于大V），有关这个节点的操作的速度将大大下降。这个问题很早就有了，官方也说过会处理，然而现在仍然不能让人满意。
提高数据库速度的常用方法就是多分配内存，然而看了官方操作手册，貌似无法直接设置数据库内存占用量，而是需要计算后为其”预留“内存…

4. 适用场景
   鉴于其明显的优缺点，Neo4j适合存储”修改较少，查询较多，没有超大节点“的图数据。

另外，针对Neo4j的缺点，有一款使用混合索引的数据库Arangodb也许是一个不错的考虑对象。根据其官网的说明，Arangodb不仅具有一般图形数据库的优点，而且在各种操作的速度上领先于Neo4j。

https://www.arangodb.com/2016/04/index-free-adjacency-hybrid-indexes-graph-databases/

https://www.arangodb.com/2015/10/benchmark-postgresql-mongodb-arangodb/