你应该了解的一些数据库概念！RDBMS vs NoSQL，分布式 vs 集群 ，分区 分表 分片 分库

早就想写一篇数据库概念类的文章，奈何本人能力实在有限，难以着笔。但实在又想多多了解数据库方面知识，开拓了解更多相关理念，还是尽力收集一些资料弥合起来。我没有发现知识，我只是收集一些我想了解的知识。本文前部分主要根据五月的仓颉的《Sql Or NoSql，看完这一篇你就懂了》此文展开，加上自己知识盲区的部分补充！仅仅作为备忘记录。

1️⃣数据存储结构

数据库，顾名思义是用来存取数据的。然而数据类型众多，比如：文本、图片、HTML、各类报表、视音频等等，不同的数据存储结构，会很大程度影响了数据库引擎的选型。没有一种事物是完美的，数据库也一样，有些数据库擅长存取结构化的数据，有些则擅长存取非结构化的数据。为什么擅长？因为需要，所以也会摈弃，做出权衡！下面了解一下数据存储结构分类：

• 结构化数据
  结构化数据指的是由二维表结构来逻辑表达和实现的数据，严格遵循数据格式与长度规范，也称作为行数据，特点为：数据以行为单位，一行数据表示一个实体的信息，每一行数据的属性是相同的。
  因为关系型数据库完美契合结构化数据的特点，关系型数据库也是关系型数据最主要的存储与管理引擎。
• 半结构化数据
  不符合二维逻辑这种数据模型结构，但是包含相关标记，用来分割语义元素以及对记录和字段进行分层。常见的半结构化数据有XML和JSON。

<person>
    <name>张三</name>
    <age>18</age>
    <phone>12345</phone>
</person>

• 非结构化数据
  数据结构不规则或不完整，没有任何预定义的数据模型，不方便用二维逻辑表来表现的数据。例如办公文档（Word）、文本、图片、HTML、视频音频等。

2️⃣NoSQL 体系介绍

关系数据库自不必多说了，相信各位入门第一种数据库课程就是关系型的数据库。

NoSql的全称为Not Only SQL，泛指非关系型数据库，是对关系型数据库的一种补充，特别注意补充这两个字，这意味着NoSql与关系型数据库并不是对立关系，二者各有优劣，取长补短，在合适的场景下选择合适的存储引擎才是正确的做法。

2.1❀ NoSQL 数据库分类

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

2.2❀ 几种常用NoSql讲解

Redis
Redis又是KV型NoSql中应用最广泛的NoSql。
优点：高性能（TPS 10万级别）

• 数据基于内存，读写效率高
• KV型数据，时间复杂度为O(1)，查询速度快

缺点：

• 只能根据K查V，无法根据V查K
• 查询方式单一，只有KV的方式，不支持条件查询，多条件查询唯一的做法就是数据冗余，但这会极大的浪费存储空间
• 内存是有限的，无法支持海量数据存储
• 由于KV型NoSql的存储是基于内存的，会有丢失数据的风险

适用场景：缓存

• 读远多于写
• 没有持久化的需求，可以容忍数据丢失，反正丢了再查询一把写入就是了
  例如根据用户id查询用户信息，每次根据用户id去缓存中查询一把，查到数据直接返回，查不到去关系型数据库里面根据id查询一把数据写到缓存中去。

MongoDB
文档型NoSql是没有Schema的，由于没有Schema的特性，我们可以随意地存储与读取数据，因此文档型NoSql的出现是解决关系型数据库表结构扩展不方便的问题的。

优点：

• 没有预定义的字段，扩展字段容易
• 相较于关系型数据库，读写性能优越，命中二级索引的查询不会比关系型数据库慢，对于非索引字段的查询则是全面胜出

缺点：

• 空间占用较大，这个是MongDB的设计问题，空间预分配机制 + 删除数据后空间不释放，只有用db.repairDatabase()去修复才能释放
• 多表之间的关联查询不支持（虽然有嵌入文档的方式），join查询还是需要多次操作

适用场景：

MongDB的使用场景很大程度上可以对标关系型数据库，但是比较适合处理那些没有join、没有强一致性要求且表Schema会常变化的数据。

ElasticSearch

传统关系型数据库主要通过索引来达到快速查询的目的，但是在全文搜索的场景下，索引是无能为力的，like查询一来无法满足所有模糊匹配需求，二来使用限制太大且使用不当容易造成慢查询，搜索型NoSql的诞生正是为了解决关系型数据库全文搜索能力较弱的问题

全文搜索的原理是倒排索引，我们看一下什么是倒排索引。要说倒排索引我们先看下什么是正排索引，传统的正排索引是文档–>关键字的映射，例如"Tom is my friend"这句话，会将其切分为"Tom"、“is”、“my”、"friend"四个单词，在搜索的时候对文档进行扫描，符合条件的查出来。这种方式原理非常简单，但是由于其检索效率太低，基本没什么实用价值。

倒排索引则完全相反，它是关键字–>文档的映射，我用张表格展示一下就比较清楚了：

意思是我现在这里有四个短句：

• “Tom is Tom”
• “Tom is my friend”
• “Thank you, Betty”