vlambda博客
学习文章列表

点击“Golang在发光”，选择“星标🔝”

 
   
   
 

  
    
    
  
点击文末“阅读原文”解锁资料！
  
    
    
  

  
    
    
  


  
    
    
  

  
    
    
  


 
   
   
 

由于项目需要存储一些无结构的数据, 这些数据主要以文本为主, 同时还需支持一些文本分析, 咋一听似乎ES是一个不错的选择, 但是这些无结构的数据同时也需要被管理, 也就是这些数据可能经常变更, 衡量再三, 最后还是选择了Mongo, 毕竟现阶段是以数据的存储和管理为主, 分析并没有那么强的需求。整篇文章以大数据存储问题为引, 一步步引出NoSQL领域文档数据的代表MongoDB。

 1   大数据存储问题

E.F.Codd在1970年首次提出了数据库系统的关系模型，从此开创了数据库关系方法和关系数据理论的研究，为数据库技术奠定了理论基础，数据库技术也开始蓬勃发展。而随着几大数据库厂商陆续发布的商业数据库管理系统几乎都支持关系数据模型，数据库技术逐渐统一到以关系型数据库为主导。关系模型有扎实的数学理论做基础, 并且经过长时间的实践, 使得其在数据存储与管理领域占据统治地位。

2001年后，互联网技术迅速发展，数据量迅速膨胀并并大，人类逐步进入大数据时代。大数据给传统的数据管理方式带来了严峻的挑战，关系型数据库在容量，性能，成本等多方面都难以满足大数据管理的需求。NoSQL数据库通过折中关系型数据库严格的数据一致性管理，在可扩展性、模型灵活性、经济性和访问性等方面获得了很大的优势，可以更好地适应大数据应用的需求，成为大数据时代最重要的数据管理技术。

围绕大数据的存储问题, 我们依次讨论下数据库的几大分类: RDBMS, NewSQL, NoSQL。

1.1 RDBMS

在现代的计算系统上每天网络上都会产生庞大的数据量。这些数据有很大一部分是由关系数据库管理系统(RDMBSs)来处理。1970年 E.F.Codd’s提出的关系模型的论文 “A relational model of data for large shared data banks”，这使得数据建模和应用程序编程更加简单。
通过应用实践证明，关系模型是非常适合于客户服务器编程，远远超出预期的利益，今天它是结构化数据存储在网络和商务应用的主导技术。

什么是RDBMS？

RDBMS全称是Relational Database Management System, 及关系型数据管理系统, 他采用关系模型来存储数据,关系模型是把复杂的数据结构归结为简单的二元关系(即二维表格形式), 在关系型数据库中，对数据的操作几乎全部建立在一个或多个关系表格上，通过对这些关联的表格分类、合并、连接或选取等运算来实现数据库的管理。

关系型数据的特点(ACID)

关系型数据库遵循ACID规则, 也就是我们常说的事物模型(transaction), 事物这个概念和现实世界中的交易很类似, 它有如下4个特性:

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

  
  

• C(Consistency)
  一致性也比较容易理解，也就是说数据库要一直处于一致的状态，事务的运行不会改变数据库原本的一致性约束。
  例如现有完整性约束a+b=10，如果一个事务改变了a，那么必须得改变b，使得事务结束后依然满足a+b=10，否则事务失败。

  
  

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

  
  

• D(Durability)
  持久性是指一旦事务提交后，它所做的修改将会永久的保存在数据库上，即使出现宕机也不会丢失。
  比如A账户收到了100元到账, 只要到账这个事物完成, 数据就已经到数据库里面了, 即使此时宕机对A用户的资产也没有影响。

典型的产品

关系型数据库诞生40多年了，从理论产生发展到现实产品, RDBMS很多产品应该都是耳熟能详的:

• Oracle

• MySQL

• PostgreSQL

• SQLServer

大数据存储时面临的问题

关系型数据库严格ACID原则, 因此在扩展性上表现不是特别好, 面对大规模的数据时, 在读和写上面会出现严重瓶颈。想要提升其性能, 往往需要从业务层进行处理, 进行数据的Sharding。
sharding有2个维度: 水平切分和垂直切分:

• 水平切分: 根据表中的数据的逻辑关系，将同一张表的数据，按照某种条件切分到不同的数据库主机上

• 垂直切分: 按照不同的表或者schema，来切分到不同的数据库主机上

切片(sharding)会增加整个系统的复杂性，而且切片本身也是一个很复杂的过程，与应用本身有这密切的关系，所以对于不但增大的数据而言，切片并不能从根本上解决大数据存储问题。

1.2 NewSQL

传统的关系型数据想要做到高扩展, 高性能, 高可靠性是很复杂的, 但是当你的确想要一种这种样的数据库时, NewSQL可能是你一种不错的选择。

什么是NewSQL？

这是一个中间产物, 是一种完全不同的数据库架构, NewSQL术语最早在2011年由Matthew Aslett创造, NewSQL的设计立足于传统的关系型数据库，但是同时也引进一些新技术，从而达到可扩展和高性能的目的, 而缺点是没有提供强一致性, 它们不可以被使用在强一致性环境下。
NewSQL具有NoSQL的海量数据存储管理能力,同时还支持传统数据库的ACID和SQL能力(单个节点上的ACID能力), 但是在现实使用中还没普及开来, 还没被大规模使用。

NewSQL的特点

NewSQL具体和RDBMS一样的单个节点上的ACID能力, 同时又具有NoSQL一样的很强的扩展能力(它在整个集群上遵循BASE规则, 关于BASE在后面NoSQL中再做介绍)。

典型的NewSQL产品

我迄今也没有使用过NewSQL产品, 以下是我所知的关于NewSQL的经典产品:

• Google spanner: Google的全球级的分布式数据库(Globally-Distributed Database)

• CockroachDB: 参考Goole spanner实现的开源版

如何解决大数据存储问题？

NewSQL基于NoSQL的BASE原则, 构建可以横向扩展的分布式系统来解决大数据的存储和管理问题。

1.3 NoSQL

今天我们可以通过第三方平台(如：Google,Facebook等), 可以很容易的访问和抓取数据。用户的个人信息，社交网络，地理位置，用户生成的数据和用户操作日志已经成倍的增加。我们如果要对这些用户数据进行挖掘，那SQL数据库已经不适合这些应用了, NoSQL数据库的发展也却能很好的处理这些大的数据。

什么是NoSQL？

NoSQL(NoSQL = Not Only SQL)，意即“不仅仅是SQL”，是一项全新的数据库革命性运动，早期就有人提出，发展至2009年趋势越发高涨。NoSQL的拥护者们提倡运用非关系型的数据存储，相对于铺天盖地的关系型数据库运用，这一概念无疑是一种全新的思维的注入

NoSQL的特点(BASE)

BASE的全称是Basically Available, Soft-state, Eventually Consistent。由Eric Brewer定义。ACID强调强一致性(CAP中的C), 而BASE则强调基本可用性(CAP中的A），在BASE思想的扩展下，就出现了NoSQL。
BASE是NoSQL数据库通常对可用性及一致性的弱要求原则:

• Basically Availble: 基本可用

• Soft-state: 软状态/柔性事务。“Soft state” 可以理解为”无连接”的, 而 “Hard state” 是”面向连接”的

• Eventual Consistency: 最终一致性 最终一致性， 也是是 ACID 的最终目的。

BASE是相对ACID而言的, 下面是对比表:

典型的NoSQL产品

NoSQL是实现方式各不相同，下面主要介绍 主流的NoSQL流派, 想要了解更具体的信息请点击关于所有NoSQL介绍的一个网站:

• 列式数据模型
  数据模型：看到也是表, 但是不支持链接查询, 因为数据存储以列为单位(column), 而关系数据库是以行为存储单位的
  应用场景：在分布式文件系统之上提供支持随机读写的分布式数据存储
  典型产品：Hbase、 Hypertable、 Bigtable、 Cassandra
  优点：快速查询、 高扩展性、易于实现分布式扩展

• 文档数据模型 ：
  数据模型：介于键值存储kv)和关系型存储(row),每一行数据组织为一个文档, 以文档为存储单位
  应用场景：非强事物需求的web应用
  典型产品：MongoDB、 ElasticSearch(弹性搜索，存储web日志)
  优点：　数据模型无需事先定义

• 键值数据模型 ：
  数据模型：模型简单, 易于实现, 操作简单(get set del)
  应用场景：内容缓存, 用于大量并行数据访问, 高负载场景
  应用产品：DynamoDB, Riak, Redis
  优点：hash的优点， 查询迅速

• 图式数据模型 ：
  数据模型：图式结构
  应用场景：社交网络、 推荐系统、 关系图谱
  典型产品：Neo4J
  优点：适用于图式技术场景

如何解决大数据存储问题？

通过分布式解决

1.4 RDBMS vs NoSQL

RDBMS的特点:

• 高度组织化结构化数据

• 结构化查询语言

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

• 数据操纵语言，数据定义语言

• 严格的一致性

• 基于事务

NoSQL的特点:

• 代表着不仅仅是SQL

• 没有声明性查询语言

• 没有预定义的模式, 架构的灵活性，支持半结构化数据

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

• 最终一致性，而非ACID属性

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

• 分布式计算, CAP定理

• 高性能，高可用性和可伸缩性, 高水平扩展能力和低成本的低端硬件集群

• 功能相对简单, 没有统一的查询语言, 有限的查询功能

• 最终一致是不直观的程序

 2   数据模型

对于数据本身而言, 我们往往将其分为结构化数据, 半结构化数据, 以及非结构化数据, 但是对于储存时数据的组织我们才称其为数据模型, 常见的数据模型有: 关系模型, 文档模型, 健值模型, 以及列式模式。

2.1 用户侧数据

随着网络技术的发展，特别是Internet和Intranet技术的飞快发展，使得非结构化数据的数量日趋增大。这时，主要用于管理结构化数据的关系数据库的局限性暴露地越来越明显。因而，数据库技术相应地进入了“后关系数据库时代”，发展进入基于网络应用的非结构化数据库时代。

结构化数据(structured data)

结构化数据, 即行数据,存储在数据库里,可以用二维表结构来逻辑表达实现的数据。
结构化数据, 先知结构, 再有数据。我们根据数据的结构预先建立好二维表, 等数据来的时候, 填入即可。因此结构化的数据往往是可建模, 标准化的数据,结构化的数据很方便程序使用, 因为结构已知。

结构化数据最大的问题, 就当数据的结构发生变化时, 我们需要调整数据的结构, 一般就意味着数据库表结构的需要变动。这使得数据在存储时有严格的要求(需要定义schema)。
结构化数据: 可以被提前建模的数据(定义schema)

半结构化数据(semi-structured data)

所谓半结构化数据，就是介于完全结构化数据(如关系型数据库、面向对象数据库中的数据)和完全无结构的数据(如声音、图像文件等)之间的数据，HTML文档就属于半结构化数据。它一般是自描述的，数据的结构和内容混在一起，没有明显的区分。
所以对于半结构化的数据, 数据的结构要等数据获得后才知道, 也就是先有数据, 后知结构。整个互联网上这类数据是很多的, 因为html就是半结构化的数据。

相对于结构化的数据, 半结构化数据无需定义数据的结构(schema free), 使得其在存储上表现出强大的灵活性。
半结构化数据: HTML, JSON, XML

非结构化数据(unstructured data)

相对于结构化数据而言，不方便用数据库二维逻辑表来表现的数据即称为非结构化数据。
非结构化数据库是指其字段长度可变，并且每个字段的记录又可以由可重复或不可重复的子字段构成的数据库，用它不仅可以处理结构化数据(如数字、符号等信息), 而且更适合处理非结构化数据（全文文本、图象、声音、影视、超媒体等信息)。

非结构化WEB数据库主要是针对非结构化数据而产生的，与以往流行的关系数据库相比，其最大区别在于它突破了关系数据库结构定义不易改变和数据定长的限制，支持重复字段、子字段以及变长字段并实现了对变长数据和重复字段进行处理和数据项的变长存储管理，在处理连续信息（包括全文信息）和非结构化信息（包括各种多媒体信息）中有着传统关系型数据库所无法比拟的优势。
非结构化数据: 所有格式的办公文档、文本、图片、XML、HTML、各类报表、图像和音频/视频信息等等。

2.2 存储时数据

数据存储模型值数据存储时如何组织

2.2.1 关系模型

关系模型: 新定义列, 然后通过行的方式对数据进行存储, 以二维表来表示实体与实体之间的联系，在数据建模时需要对数据对象进行拆分，再将各自的信息存到对应的表里，在需要时再将各个表连接起来。

在关系模型当中，多个表中的不同记录经常“交错连接”，一些数据会被多条记录共享。这样的好处就是减少了重复数据的出现，但是这样不好的地方就是一旦其中某一条链接的记录发生改变，那么与其相关的记录和表都会被锁住以防止非一致性的出现。ACID事务在关系型数据库中是很复杂的，因为数据会扩散。即便是单一条记录，这复杂的共享数据内部关系网的存在，也使得关系型数据在多个服务器之间的传递变得复杂而缓慢，同时让读和写操作的性能变差。

当存储空间昂贵又稀少时，折中的权衡方案是很必要的。然而，如今存储空间的价格跟40年前相比已经大大的下降了，很多时候计算折中方案已经完全没有必要。使用更多的存储空间来换取更好的操作性能，或者是将工作负载分配到多台机器上，这才是如今应用上更好的解决方案。

2.2.2 文档模型

文档数据: 将一个数据记录(record或者row)作为单位进行存储, 无需定义行。也可以认为一个文档就是关系数据库的一行。

使用“文档”这个词似乎让人觉得奇怪，但是其实”文档型数据模型”真的和传统意义的文字”文档”没有什么关系。他不是书、信或者文章，这里说的”文档”其实是一个数据记录, 这个记录能够对包含的数据类型和内容进行“自我描述”。XML文档、HTML文档和JSON 文档就属于这一类, 因此我们可以认为所有半结构化的数据都属于文档数据, 而现在主要的文档数据库还是以Json作为文档为主.

可以看到，数据是不规则的，每一条记录包含了所有的有关该记录的信息而没有任何外部的引用, 这条记录就是“自包含”的。这就使得记录很容易完全移动到其他服务器, 因为这条记录的所有信息都包含在里面了, 不需要考虑还有信息在别的表没有一起迁移走。同时，因为在移动过程中，只有被移动的那一条记录

需要操作而不像关系型中每个有联系的表都需要锁住来保证一致性，这样一来ACID的保证就会变得更快速, 读写的速度也会有很大的提升。

2.2.3 健值模型

健值模型: 它的数据按照键值对的形式进行组织,索引和存储。KV存储非常适合不涉及过多数据关系业务关系的业务数据，同时能有效减少读写磁盘的次数，比SQL数据库存储拥有更好的读写性能。

2.2.4 列式模型

列式存储: 以列相关存储架构进行数据存储。列式存储以流的方式在列中存储所有的数据，主要适合与批量数据处理和即席查询。

由于查询需要读取的blocks少, 所以查询快, 因为同一类型的列存储在一起, 所以数据压缩比高, Load快。它简化数据建模的复杂性。但是插入更新慢，不太适合数据老是变化，它是按列存储的。列式存储很适合做数据仓库，它不适合OLTP。

 3   CAP定理

在计算机科学中, CAP定理(CAP theorem), 又被称作布鲁尔定理(Brewer's theorem), 它指出对于一个分布式计算系统来说，不可能同时满足以下三点:

• 一致性(Consistency) (所有节点在同一时间具有相同的数据)

• 可用性(Availability) (保证每个请求不管成功或者失败都有响应)

• 分隔容忍(Partition tolerance) (系统中任意信息的丢失或失败不会影响系统的继续运作)

  
  

CAP理论的核心是：一个分布式系统不可能同时很好的满足一致性，可用性和分区容错性这三个需求，最多只能同时较好的满足两个。
因此，根据CAP原理将NoSQL数据库分成了满足CA原则、满足CP原则和满足AP原则三 大类：

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

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

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

  
  

定理: 任何分布式系统最多只能同时时满足3点(Consistency, Availability, Partition tolerance)中的2点, 同时满足3点的分布式系统是不存在的

忠告：架构师不要将精力浪费在如何设计能满足三者的完美分布式系统，而是应该进行取舍。

3.1 CAP与数据库

RDBMS满足的是ACID规则, 而ACID规则满足的就是CAP里面的CA, 因此扩展性不强.
NewSQL/NoSQL满足的是BASE规则, 而BASE规则就是降低一致性或者可用性来提升系统性能, 就是CAP里面的CP/AP

 4   参考

MongoDB Architecture官方中文介绍
elasticsearch(lucene)可以代替NoSQL(mongodb)吗？

往期原创文章推荐