【Redis】认识NoSQL

一、引入

NoSQL比较陌生，但是与此相对的SQL我们就比较熟悉了，SQL我们将它称之为关系型数据库。

SQL全称：Structured Query Language。

NoSql可以翻译做Not Only Sql（不仅仅是SQL），或者是No Sql（非Sql的）数据库。不管是哪种翻译它所表达的意思都是：NoSQL相对于传统关系型数据库而言，有很大差异的一种特殊的数据库，因此也称之为非关系型数据库。当然也有联系，它们毕竟都属于数据库，数据库最终的目的一定是数据的增删改查，无非是在数据存储的方式上有一些差异，接下来就来对比一下两者在这方面的差异。

---

二、结构差异

1）SQL

两者的第一个差异体现在 字母S 上，S 是 structured 的缩写，代表的是结构化，存入关系型数据库的数据，都是结构化的数据，即：这些数据都有固定的一些格式要求，这些要求就是我们以前所学的表以及表的约束。

并且表的结构一般是不建议去修改的，最好在项目设计之初就将它定义好，因为以后一旦数据插入的较多，此时修改表中的某个字段，可能带来的影响是非常巨大的，可能会导致这张表被锁很长一段时间不可用，而且因为表跟业务有关联，因此将来表变了，业务有可能也要跟着变，这样带来的影响太大了，所以这是结构化数据带来的一个问题。

---

2）NoSQL

与此相对的NoSQL就是一种非结构化数据，它对于数据的结构并没有非常严格的约束，也不是完全没有约束，这个取决于NoSQL的类型，常见NoSQL类型有四种。

第一种：常见的redis这种键值型的

Key是可以自定义的，叫 id、name、age 都可以，这样就相当于将 SQL型数据库中一行数据全部都存下来了。

但是这么存一般不太建议这样做，我们也可以将 key 定义为用户的id，值定义为JSON字符串，这种键值型对Key的约束没那么强。

对Value类型同样也可以自定义，它有五种常见的类型，约束相对来讲就会小很多。

---

第二种：文档型

所谓文档型：SQL中的一条数据就对应一个文档，文档存储是JSON风格的。

它与SQL数据库的差异：首先字段是可以任意的，第一条插入 id name，第二条完全可以插入别的 id username 也是没问题，这样它的字段约束就非常的松散。

---

第三种：图类型的数据库

图类型的数据库：即存储这个数据库的每一个数据都可以看成一个节点。

例如我存进去了一个人的信息，那它就是一个节点。

为什么是节点呢？因为人与人之间会有练习，例如张三是李四的老师，他们两个就是师生关系等。

每个数据都是一个节点，节点与节点间有联系，这种就叫做图。

当然这种用的比较少，因为我们一般不做一些社交的app。

---

3）总结

以上是三种常见的数据库，不管是哪种，它们的数据结构其实都没有严格的要求，相对来讲比较松散，并且将来去修改数据结构也是可以的，例如一条数据增加字段和减少，影响都是比较小的。

---

三、关联和非关联

当然除了数据有结构上的要求以外，关系型数据库之所以叫关系，那就是数据与数据之间往往是有关联的。

1）SQL

例如下图，有 user表、item商品表，它们两个本身是没有关系的，但如果来了张订单表，订单表就需要记录是谁下了单（用户id），还要记录下单买了什么商品（商品id），这个时候关系就建立起来了。

order表 里面记录了用户的id，此时用户id就可以理解成是一个外键，它关联到了用户表里面的id。

商品id 对应到的就是商品表中的 id，也是一个外键，关联了 商品表 中的数据。

这样就知道了：张三 买了 荣耀6 商品。

此时表和表之间的关系就通过外键建立起来了，这种外键关系一旦建立，假设将来要删除一个用户，或者删除一个商品，它就不允许你这么做，因为它会觉得这个商品在其他表中有关联，所以数据库就会去维护这些关系。

并且这种关联有一个好处：节省数据存储空间，订单中关联了用户，此时并不是将用户信息完整的保存在这里，而是只关联一个id就行了。

---

2）NoSQL

而非关系型数据库不存在关联关系，要维护关系要么靠代码中的业务逻辑，要么靠数据之间的耦合：

{
    id: 1,
    name: "张三",
    orders: [
        {
            id: 1,
            item: {
                id: 10, title: "荣耀6", price: 4999
            }
        },
        {
            id: 2,
            item: {
                id: 20, title: "小米11", price: 3999
            }
        }
    ]
}

此处要维护“张三”的订单与商品“荣耀6”和“小米11”的关系，通过JSON嵌套的方式将这两个商品保存在张三的订单文档中。

并且这样存储数据有一个缺点：重复。张三买了荣耀6，李四也可以买，这样文档就需要存储多份了。

有人问：为什么你不像刚刚那样，记录的商品信息也只记录一个 id，然后单独再来存一个文档用来存储商品，这样它俩不就有关系了。

这样做也行，但是这个关系就需要靠程序员通过业务逻辑来维护了，因为数据库本身不会帮你维护表和表之间的关联。

---

四、查询差异

传统关系型数据库会基于Sql语句做查询，语法有统一标准。

语法固定的好处：只要是关系型数据库，都能使用相同的语句进行查询，不管你是MySQL数据库、Oracle数据库、还是其他的数据库，都可以使用相同的语句进行查询。

---

相对应的NoSQL库它的查询是非SQL，也就是说没有这样的固定的语法，格式不统一。而不同的非关系数据库查询语法差异极大，五花八门各种各样，例如下图三种NoSQL库：

• redis：根据键值对查询
• MongoDB：看起来调用了一个函数，db 代表数据库，users 代表表，find() 代表找，即找id为1的用户
• elasticsearch：变成了一种Restful的请求，users 代表库，1 代表 id 为1

这种方式调用的优点：redis调用直接用一个命令就行了，非常的简单。

MongoDB 是基于一种函数形式的调用，这种对程序员来讲相对比较熟悉。

因此它们这些风格使用起来相对简单，没有复杂的语法需要去学习。但是缺点就是不统一，每一个不同的库要学不同的语法。

---

五、事务差别

传统关系型数据库能满足事务ACID的原则。

而非关系型数据库往往不支持事务，或者不能严格保证ACID的特性，因此我们将它称之为BASE，即基本的一种满足。

对于BASE理论大家有兴趣也可以自己研究一下。

---

总结

除了上述四点以外，在存储方式.扩展性.查询性能上关系型与非关系型也都有着显著差异，总结如下：

• 存储方式
  • 关系型数据库基于磁盘进行存储，会有大量的磁盘IO，对性能有一定影响
  • 非关系型数据库，他们的操作更多的是依赖于内存来操作，内存的读写速度会非常快，性能自然会好一些

• 扩展性
  • 关系型数据库集群模式一般是主从，主从数据一致，起到数据备份的作用，称为垂直扩展。
  • 非关系型数据库可以将数据拆分，存储在不同机器上，可以保存海量数据，解决内存大小有限的问题。称为水平扩展。
  • 关系型数据库因为表之间存在关联关系，如果做水平扩展会给数据查询带来很多麻烦

垂直方式：关系型数据库在设计数据库之初，可能就没有考虑到这种分布式的需求，所以当我们去存储数据到关系型数据库的时候，它都是存储在本机，影响它性能就是本机这台机器的服务器的性能，你只能提升这个机器的性能，从而来提升它的能力。虽然MySQL是支持主从的，但是主从仅仅是提升了机器的数量、读写的性能，但是并不能提升数据存储的量，因为主和从存储数据是一样的，数据存储的总量没有变，只不过是做了备份而已。

水平方式：与此对应的NoSQL数据库，无论是redis也好，还是elasticsearch，它在设计之初就已经考虑到了数据拆分的一个需求，因为它们在插入数据的时候，往往会基于数据的id，或者是一个唯一的标识去做哈希运算，根据哈希运算的结果去判断这个数据到底应该存储在哪个不同的节点上，从而实现数据的拆分，天然的就支持这种水平的扩展。因此NoSQL库在扩展的时候是非常轻松的就能实现了。

虽然MySQL不支持扩展，但是也可以基于第三方的组件去实现数据库的分库，但是一旦引入了第三方的组件，肯定会对性能造成一定影响，并且在开发的时候需要考虑都的问题需要更多，复杂度就增加了。不想redis等NoSQL，它们天然的支持，对开发难度、性能都不会有特别大的影响，所以会更好一点。

两种库一般结合使用，各有各的优点，因此在实际开发中需要根据自己的需求去选择。