非关系型数据库技术和应用方案.pptx

《非关系型数据库技术和应用方案.pptx》由会员分享，可在线阅读，更多相关《非关系型数据库技术和应用方案.pptx（86页珍藏版）》请在悟道方案网上搜索。

1、,CONTENTS,CONTENTS,基础理论与架构分类,部署方案与性能分析,发展现状与未来趋势,NoSQL数据库是非关系型数据存储的广义定义，它不同于符合ACID理论的关系型数据库，数据存储不需要固定的表结构，通常也不存在连接操作。NoSQL数据库不使用传统的关系数据库模型，而是使用如键值存储数据库、列存储数据库、文档型数据库、图形数据库等方式存储数据模型。,基础理论与架构分类,1,NoSQL共同特征： 1）不需要预定义模式：不需要事先定义数据模式，预定义表结构。数据中的每条记录都可能有不同的属性和格式，当插入数据时，并不需要预先定义它们的模式； 2）无共享架构：相对于将所有数据存储的存储区

2、域网络中的全共享架构，NoSQL往往将数据划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能，从而提高了系统的性能；,基础理论与架构分类,1,3）弹性可扩展：可以在系统运行的时候，动态增加或者删除结点。不需要停机维护，数据可以自动迁移； 4）分区：相对于将数据存放于同一个节点，NoSQL数据库需要将数据进行分区，将记录分散在多个节点上面。并且通常分区的同时还要做复制。这样既提高了并行性能，又能保证没有单点失效的问题；,基础理论与架构分类,1,5）异步复制：和RAID存储系统不同的是，NoSQL中的复制，往往是基于日志的异步复制。这样，数据就可以尽快地写

3、入一个节点，而不会被网络传输引起迟延。缺点是并不总是能保证一致性，这样的方式在出现故障的时候，可能会丢失少量的数据； 6）BASE：相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。,基础理论与架构分类,1,NoSQL适用情况： 1）数据模型比较简单； 2）需要灵活性更强的IT系统； 3）对数据库性能要求较高； 4）不需要高度的数据一致性。,基础理论与架构分类,1,CAP理论： CAP解释为一致性（consistency）、可用性（availability）和分区容忍性（partition tolerance）。 一致性：一个数据系统如何处理读写操作的一致性问题。分布式系统对

4、于一致性的要求为当更新写入操作完成时，其余读取操作需要及时看到数据的更新；,基础理论与架构分类,1,可用性：一个系统能够持续不间断使用的问题。严格定义上的高性能可用性意味着一个系统从设计到实施都应该能够提供可持续的操作； 分区容忍性：一个系统在提供持续性操作时分区处理的能力。一旦开始将数据和逻辑分布在不同的节点上，就有形成分区的风险。假定网线被切断，就形成分区，在不同分区的节点A和节点B无法通信。由于Web提供的这种分布式能力，临时的分区是一个常见的情况，处理这种情况就属于分区容忍性。,基础理论与架构分类,1,基础理论与架构分类,1,表1 CAP理论应用及实例,基础理论与架构分类,1,表2 C

5、AP理论数据库应用实例及功能分类,BASE理论： 传统ACID模式对于数据的属性要求非常高，在分布式系统中比较难以达到。所以在CAP理论的基础上，提出了BASE思想，对一致性进行概化处理。要解释BASE思想，首先要对ACID有一个了解，因为BASE是相对于DBMS中的ACID所提出来的新思想。,基础理论与架构分类,1,ACID指的是传统数据库对于数据特性的要求。 原子性：即事务执行作为原子，不可再分离，整个语句要么执行，要么不执行，不可能停在中间某个环节； 一致性：在事务开始之前和事务结束之后，数据库的完整性约束没有被破坏； 隔离性：两个事务的执行互不干扰，也不会发生交互，一个事务不可能看到其

6、他事务运行时中某一时刻的数据； 持久性：在事务完成以后，该事务对数据库所做的更改便持久地保存在数据库之中，并不会被回滚。,基础理论与架构分类,1,在数据库系统中，事务的ACID属性保证了数据库的一致性，如银行系统中，付款就是一个事务，从原账户扣除金额以及向目标账户添加金额，这两个数据库操作的总和构成一个完整的逻辑过程，为原子操作不可拆分，从而保证了整个系统中的总金额没有变化。 但是ACID特性对于大型的分布式系统来说，与高性能是不兼容的。如在线购买商品的时候，任何一个人购物的过程都为一个原子操作，不允许存在两个人同时进行购物的情况。很明显对于绝大多数在线商城，这个方法并不适用。,基础理论与架构

7、分类,1,BASE思想实际上是CAP理论中AP的衍伸。它通过牺牲高一致性，保证高可用性和分区容忍性。 BASE思想的组成有以下3个部分：基本可用、软状态、最终一致性。BASE模式指的是一个应用在任意时间首先应该能完成最基本化的工作（即基本可用），并不需要总是一致（即软状态），但最终应该是一致（即最终一致性）的。ACID和BASE应该被看作同一范畴内的互相补充品，而不是替代品。,基础理论与架构分类,1,基础理论与架构分类,1,表3 BASE与ACID的优缺点对比,NoSQL大致可以分为四类，分别为键值存储数据库、列存储数据库、文档型数据库和图形数据库。 键值存储数据库 键值存储典型实现的数据结构

8、一般为数组链表：先通过通过hash算法得出hashcode，找到数组的某一个位置，然后插入链表的第一个位置。,基础理论与架构分类,1,Bigtable Bigtable是一个稀疏、分布式、持久化存储的多维有序映射表，表的索引是行关键字、列关键字和时间戳。Bigtable中存储的表项都是未经解析的字节数组，其数据模型如下： (row:string, column:string,time:int64)-string,基础理论与架构分类,1,示例：一个存储了大量网页及其相关信息的表Webtable，Webtable使用URL作为行关键字，使用网页的某些属性作为列名，网页的内容存入contents列中

9、，并使用获取该网页的时间戳标识同一个网页的不同版本。,基础理论与架构分类,1,1）行关键字 行关键字可以是任意字符串，目前最大支持64KB。Bigtable按照行关键字的字典序组织数据，利用这个特性可以通过选择合适的行关键字，使数据访问具有良好的局部性。表的行区间可以动态划分，每个行区间称为一个子表。子表是数据分布和负载均衡的基本单位，不同的子表可以有不同的大小。,基础理论与架构分类,1,2）列族 列关键字一般都表示一种数据类型，列关键字的集合称作列族，列族是访问控制的基本单位。存储在同一列族下的数据属于同一种类型，列族下的数据被压缩在一起保存。数据在被存储之前必须先创建列族，并且表中的列族不

10、宜过多，通常几百个，但表中可以有无限多个列。,基础理论与架构分类,1,3）时间戳 Bigtable中的表项可以包含同一数据的不同版本，采用时间戳进行索引。时间戳是64位整型，既可以由系统赋值也可由用户指定。为了简化多版本数据的管理，每个列族都有两个设置参数用于版本的自动回收，用户可以指定保存最近 N 个版本，或保留足够新的版本（如最近7天的内容）。,基础理论与架构分类,1,列存储数据库 列数据库是对应并区别于行数据库的概念。 行数据库就是我们所熟知的传统关系型数据库，即数据按记录存储，每一条记录的所有属性都存储在一起，如果要查询一条记录的一个属性值，需要先读取整条记录的数据。 而列数据库是按数

11、据库记录的列来组织和存储数据的，数据库中每个表由一组页链的集合组成，每条页链对应表中的一个存储列，而该页链中每一页存储的是该列的一个或多个值。,基础理论与架构分类,1,HBase Hbase是运行在由多个节点构成的服务集群基础之上，为TB级甚至PB级别的数据存储提供支持，并为用户提供基于Row Key的高效查询机制，它是由一个一个Row Key作为唯一标识，并包含任意多例的一张表来根据存储的数据量以大小被分割成一个或多个称为 region 的子表,基础理论与架构分类,1,基础理论与架构分类,1,一个HBase集群通常由一个master和多个region组成，且每个region Server管理

12、一个或多个由master分配的region，而master则负责维护每个region的元信息，以及region和region Server之间的映射关系。,基础理论与架构分类,1,region中的数据最终将被存放在Hadoop的多副本分布式文件系统HDFS中，且每个值出现一个region，使得同一时间t内每个region只被分配给一台region服务器，就让所有行内的mutation操作都是原子操作，所有的put操作要么完全成功、要么完全失败，以及通过任何API返回行的内容总是一个完整的行，最后就使得跨行的mutation操作不是原子操作。,基础理论与架构分类,1,进一步地，对于HBase的表

13、与region表现为：表被动态地分割成region，且放在一个或多个region服务上，当region随着增大时，它们会被切分并平均分布在region服务器上，使得切分操作接近实时，则表现为从高负载节点迁移走，并且使错误的region节点会重新部署到正常节点上。同时，HBase采用 Zookeeper协调服务，保存Hadoop的集群状态、故障或变更通知，并集成MapReduce，Jruby的命令外壳，使得HBase避开了HDFS只能append的限制，将最近更新的数据保存在内存中，逐步重写数据至新的文件中，并进行智能拆分与合并。,基础理论与架构分类,1,文档型数据库 文档型数据库的灵感是来自于

14、Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档、半结构化的文档以特定的格式存储，例如JSON。 文档型数据库可以看作是键值数据库的升级版，允许之间嵌套键值。而文档型数据库比键值数据库的查询效率更高，如：CouchDB，MongoDb。国内也有文档型数据库SequoiaDB，已经开源。,基础理论与架构分类,1,MongoDB MongoDB是10gen公司研发的面向文档的开源的NoSQL数据库系统，用C+语言编写。它提供一种强大、灵活、可扩展的数据存储方式。它扩展了关系型数据库的众多功能，如辅助索引、范围查询和排序。MongoDB的功能非常丰富，比

15、如内置的对MapReduce聚合的支持，以及对地理空间索引的支持。,基础理论与架构分类,1,MongoDB的主要特性 1）数据类型丰富。MongoDB是面向文档的数据库，放弃关系模型的一个主要原因是为了获得更加灵活的扩展性。它是无模式的，文档的键不会事先定义也不会固定不变，应用层可以方便地处理新增的键或丢失的键，为开发者变更数据模型提供极大的便利； 2）功能丰富。支持辅助索引、存储JavaScript和MapReduce等其他聚合工具的独特功能；,基础理论与架构分类,1,3）容易扩展。MongoDB在设计时考虑了系统扩展的问题，面向文档的数据模型可以自动在多台服务器之间进行分割。通过其Auto

16、-Sharding机制，可以自动实现集群的数据和负载均衡； 4）性能卓越。MongoDB对文档进行自动动态填充，预分配数据文件，用空间换取性能的稳定。默认的存储引擎中使用了内存映射文件，将内存的管理工作交给操作系统去处理。,基础理论与架构分类,1,5）管理简便。尽可能的让服务器自动配置，通过复制机制来提升系统的可靠性。 MongoDB的核心概念是文档，多个键及其相应的值有序地存放在一起组成文档，文档类似于关系型数据库中的元组。多个文档组成集合，集合如同关系型数据库中的表。多个集合组成数据库，一个MongoDB的实例可以承载多个数据库，每个数据库之间是完全独立的。,基础理论与架构分类,1,基础理

17、论与架构分类,1,MongoDB的文档采用BSON格式存储，BSON是Binary JSON的简写，是一种类似于JSON文档的二进制序列化方案。用BSON格式來存储数据具有如下三个优势：轻量级、容易遍历和高效。,基础理论与架构分类,1,基础理论与架构分类,1,图形数据库 图形数据库就是将数据存储在图（Graph）结构中。图示是一个简单的有向无环图。,其中，节点表示一个实体。例如人或商品。边表示点与点之间的连接关系，可以是有方向和无向的。如用户买了商品表示；如果用户与用户相互都认识，这种关系就是双向的，表示为 。属性表示点和边所附带的属性。例如用户姓名、年龄等。需要注意的是每个点或边的属性是动态

18、可变的。,基础理论与架构分类,1,图形数据库可以看作是结点与关系的集合，图形数据库就是将数据存储在拥有属性的结点中，并用关系将这些结点组织起来。,基础理论与架构分类,1,数据存储的重要目的是为了检索。图的查找与搜索可以通过遍历算法完成，根据算法，从开始结点到与之相连的结点查询诸如“我好友的好友是哪些人”等问题。所以通过遍历算法可以对图进行导航与操作，从而确定结点之间的路径。,基础理论与架构分类,1,键值存储数据库 适用的场景 储存用户信息，比如会话、配置文件、参数、购物车等等。这些信息一般都和ID（键）挂钩，这种情景下键值数据库是个很好的选择。,基础理论与架构分类,1,不适用场景 1）取代通过

19、键查询，而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径。 2）需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据。 3）事务的支持。在Key-Value数据库中故障产生时不可以进行回滚。,基础理论与架构分类,1,列存储数据库 适用的场景 1）日志。因为我们可以将数据储存在不同的列中，每个应用程序可以将信息写入自己的列族中。 2）博客平台。我们储存每个信息到不同的列族中。举个例子，标签可以储存在一个，类别可以在一个，而文章则在另一个。,基础理论与架构分类,1,不适用场景 1）如果需要ACID事务。Vassandra就不支持事务； 2）原型设

20、计。如果我们分析Cassandra的数据结构，我们就会发现结构是基于我们期望的数据查询方式而定。在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列族。,基础理论与架构分类,1,面向文档型数据库 适用的场景 1）日志。企业环境下，每个应用程序都有不同的日志信息。Document-Oriented数据库并没有固定的模式，所以我们可以使用它储存不同的信息。 2）分析。鉴于它的弱模式结构，不改变模式下就可以储存不同的度量方法及添加新的度量。,基础理论与架构分类,1,不适用场景 在不同的文档上添加事务。文档型数据库并不支持文档间的事务，如果对这方面有需求则不应该选

21、用这个解决方案。,基础理论与架构分类,1,图形数据库 适用的场景 1）在一些关系性强的数据中； 2）推荐引擎。如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定。 不适用场景 不适合的数据模型。图数据库的适用范围很小，因为很少有操作涉及到整个图。,基础理论与架构分类,1,基础理论与架构分类,部署方案与性能分析,发展现状与未来趋势,CONTENTS,部署方案与性能分析,2,数据存储案例： 1）使用文档型数据库MongoDB深度挖掘天气现象数据内在价值：探究如何通过MongoDB实现对数据的存储； 2）基于Hbase的地震大数据存储研究：探究通过Hbase对数据存储的效率。,部署方案与性能

22、分析,2,使用文档型数据库MongoDB深度挖掘天气现象数据内在价值 地面气象观测基本资料中的天气现象数据与气温、雨量、气压等其他结构化数据不同，天气现象数据更像是一种非结构化数据，它模式不固定，由现象符号编码与表示方位、起始终止时间等内容的字符串组合而成。,部署方案与性能分析,2,天气现象数据的存储 1）建立数据库以及集合 在MongoDB的Shell界面中，使用命令Use dbname，该命令建立数据库dbname，也同时将当前工作切换到名为dbname的数据库中。集合类似于RDBMS中的“表”（table）。集合是不需要显式建立的，当存入数据时，使用某个新的集合名，数据库会自动建立这个新

23、的集合。例如db.test.save(数据文档)，就会自动建立一个名为test的集合。,部署方案与性能分析,2,2）将原始数据编码成BSON格式文档 一个文档就是一条记录，比如有以下表1是A文件（全国地面气象资料基本格式文件）中两天的天气现象原始数据，为了保存入MongoDB数据库，我们通过Java语言编程从 A 文件中读取出原始数据，然后分别编码成两个BSON格式文档如表2所示。,部署方案与性能分析,2,部署方案与性能分析,2,部署方案与性能分析,2,3）存储操作 （1）首先把键值日期“rq”建立成唯一索引，保证在一个集合中不会出现重复日期的文档。使用Shell命令db.test.ensur

24、eIndex(“rq”:1,“unique”:true,“dropDups”:true)； 建立该唯一索引以后，当插入或存入文档键值“rq”有重复时，将会返回错误，若需跟新数据，只有删除存在的文档再插入，或者通过 update 命令更新已存在的文档。这与RDBMS中的使用主键类似；,部署方案与性能分析,2,（2）使用db.test.save（文档）命令或者db.test.insert（文档）命令，将编码后的天气现象数据存储到MongoDB系统dbname数据库中的test集合中； （3）使用update命令更新已经存入的文档。例如需要修改日期为“20120719”的文档的天气现象数据,使用命令

25、db.test.update (“rq”:”20120719”,$set:“ww”:天气现象文档数组)；,部署方案与性能分析,2,（4）使用remove命令删除已经存入的文档。例如需要删除日期为“20120719”的文档，使用命令db.test.remove(“rq”:”20120719”)。,部署方案与性能分析,2,2. 基于Hbase的地震大数据存储研究 1） 存储原理 Hbase表是一个分布式多维表，表中的数据通过一个行关键字（Row Key）、一个列族和一个列名（Colunmfamily:column name）以及一个时间戳进行索引和查询定位。其关键在于设计好Row Key，以方便数

26、据查询和数据分析。,部署方案与性能分析,2,地震信息的业务逻辑是通过台网（Netid）、台站（Stationid）、测点（Pointid）、仪器（Intrid）、测项（Itenid）、采样率（Samplerate）、产品类别（Protype）和时间戳（Timestamp）进行查询的。,部署方案与性能分析,2,假设地震业务数据库中有一个Obs观测数据表，按照传统的RDBMS，Obs表中的列是不能随意改变的，比如Schema定义了Netid、Stationid、Pointid、Intrid、Itenid、Samplerate、Protype、Timestamp等属性，Obs表的属性是不能动态增加的

27、。而对于Hbase列存储数据库，在创建Obs表时，再为它定义一个info列族，Obs的数据便可以表示为info:value=23.4。如果要增加新的字段属性，只需要通过添加一个info:newProperty就可以了。,部署方案与性能分析,2,因此，如果采用传统关系数据库存储将非常复杂，且会造成一些为空值的存储浪费。而Hbase就不会出现该问题，列存储的每一个列单元如果是空值，则不占用存储空间。,部署方案与性能分析,2,因此Hbase的基于列存储数据模型非常适合地震数据频繁扩展的场景。另外Hbase数据库还能自动切分数据，当Obs表中的数据超过某一个阀值时，Hbase就会自动切分数据，使查询具

28、有伸缩性。再加上Hbase的弱事务性，使得Hbase的数据写入效率非常高。 Row Key是类似关系数据库中的主键，在Hbase中的存储也是根据Row Key来排序的。另外Hbase不支持条件查询和Order by等查询方式，故Row Key的设计要根据应用系统的查询需求而定。,部署方案与性能分析,2,根据上述地震业务需求，观测数据表Obs的Row Key可以由以下几个部分构成：、。当要查询某个台网某个时间段数据时，就可以指定起始Row Key为，终止Row Key为。其他各种组合需求，比如要查询某个自然测点数据、某台仪器的数据、某个学科数据、某个测项分量数据等，都可以非常高效地检索出来。,部

29、署方案与性能分析,2,2）存储方法实现 从数据结构角度，地震数据可划分为两类：观测产生的结构化数据和文件、图像等非结构化数据。,部署方案与性能分析,2,（1）结构化数据存储 地震典型的普通结构化数据就是前兆，存放在Oracle数据库和测震存放在MySQL数据库的关系型观测数据，主要包括前兆各学科（形变、重力、GNSS、地下流体、地电、地磁等）和测震学（地震目录、观测报告、事件波形、连续波形等）数据。这些观测数据，分别从前兆Oracle库、测震MySQL库读取出来，通过上述存储方法存储至Hbase设计的Obs表中进行统一存储管理。,部署方案与性能分析,2,（2）非结构化数据存储 地震非结构化数据

30、存储时，Hbase有着不可取代的优势： 更有效地存储小文件（小于16MB）；提供更高层和更可靠的接口，可以方便实现数据的增删查改功能；提供失败自动重试机制，有效地保证数据的一致性。,部署方案与性能分析,2,Hadoop开发了Hbase大对象LOB（large objectstorage）存储功能，方便用户在Hbase中存储各种类型的大对象。存储时，LOB Store是列族级别的存储单元，每个LOB Store可以存储几百万个文件，而LOB Store的底层存储在LOB File中。读写方面，其插入性能提高到100%，插入延时减少90%，读取的随机性能可达到200%。,部署方案与性能分析,2,3

31、）对比测试 （1）测试平台环境 为对比Hbase-0.94.6和MySQL-5.1.48的存储、查询等性能指标，由3台配置相同服务器的Hadoop集群组成分布式文件系统，构成一个逻辑Hbase集群，同时由其中一台机器单机测试MySQL。,部署方案与性能分析,2,部署方案与性能分析,2,（2）结构化数据存储性能对比 将两者针对结构化观测数据的存储进行效能测试，在关键代码处添加秒表，记录执行命令的时间。数据量（条）分别为50、100、1 000、10 000、100 000，每次插入保存完毕把所耗时长写入日志文件。连续多次测试，取平均值。,部署方案与性能分析,2,通过反复测试与效率对比发现，观测数

32、据读取性能较高情况为：测震连续波形数据，每条记录保存10min长度数据；前兆分钟以上采样率观测数据，每条记录保存1h长度数据。,部署方案与性能分析,2,（3）非结构化数据存储性能对比 分别对Hbase-0.94.6和MySQL-5.1.48做10、50、100、200、500、1 000次文件写入试验，文件大小约30KB/个，两者的二进制文件存储耗时性能对比结果如图所示。,部署方案与性能分析,2,（4）查询性能对比 分别对Hbase-0.94.6和MySQL-5.1.48做数据量为1 000、2 000、10 000、100 000、500 000的查询性能测试。,基础理论与架构分类,部署方案

33、与性能分析,发展现状与未来趋势,CONTENTS,发展现状与未来趋势,3,发展现状与未来趋势,3,DB-Engines Ranking,发展现状与未来趋势,3,NoSQL得到如此广泛的普及主要有3个驱动力。 首先是需求。在过去的几年间，互联网与移动的流量呈现出了爆发性的增长，现在很多大公司所处理的数据规模是几年前我们几乎不曾想到的。传统的关系型数据库在设计时从未考虑过能够比较容易地实现跨节点可伸缩这一特性，因此NoSQL在那些需要能够实现快速、轻松且低成本可伸缩的公司中开始流行起来；,发展现状与未来趋势,3,其次是可用性。在过去几年间，开源软件真的开始成熟起来了，现在已经出现了很多成熟的开源N

34、oSQL存储，这样公司就可以轻松找到满足其需求的数据存储方案了； 最后是新兴性。现在一定存在使用NoSQL构建，但关系型数据库却更加适合的应用。然而，随着NoSQL逐渐从新生事物变成主流，技术人员在选择适合其应用场景的解决方案时会变得更理性一些。,发展现状与未来趋势,3,目前，NoSQL对大型企业来说还不是主流，尽管大多数NoSQL数据存储系统都已被部署于实际应用中，但归纳其研究现状，还有许多挑战性问题。 1）已有 key-value 数据库产品大多是面向特定应用自治构建的，缺乏通用性； 2）已有产品支持的功能有限（不支持事务特性），导致其应用具有一定的局限性；,发展现状与未来趋势,3,3）已

35、有一些研究成果和改进的NoSQL数据存储系统，但它们都是针对不同应用需求而提出的相应解决方案，如支持组内事务特性、弹性事务等，很少从全局考虑系统的通用性，也没有形成系列化的研究成果； 4）缺乏类似关系数据库所具有的强有力的理论(如armstrong公理系统)、技术（如成熟的基于启发式的优化策略、两段封锁协议等）、标准规范（如SQL语言）的支持；,发展现状与未来趋势,3,5）目前，HBase数据库是安全特性最完善的NoSQL数据库产品之一，而其他的NoSQL数据库多数没有提供内建的安全机制或安全机制不完善。,发展现状与未来趋势,3,NoSQL数据库可提供良好的扩展性和灵活性，但他们也有自己的不足

36、。由于不使用SQL，NoSQL数据库系统不具备高度结构化查询等特性，此外不同的NoSQL数据库都有自己的查询语言，这使得很难规范应用程序接口。 NewSQL指的是像NuoDB这样的现代数据库，他们将跨节点的可伸缩性与对SQL查询的支持结合起来了，这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。,发展现状与未来趋势,3,不同的NewSQL系统虽然内部结构变化很大，但是它们有两个显着的共同特点：支持关系数据模型；使用SQL作为其主要的接口。 我们现在尚处在NewSQL革命的黎明阶段，但显然，对于有的场景来说，NoSQL存储提供了比关系型代数更好的

37、抽象能力；而对另一些场景来说，拥有开发者所熟知的编程模型的可伸缩数据库则是更好的解决方案。,发展现状与未来趋势,3,NoSQL及NewSQL之后的大趋势是不变的数据存储。在过去几年中，围绕着使用函数式编程跨多台服务器进行高效的可伸缩性处理，人们讨论了很多。通过最小化共享的可变状态，函数式编程模型避免了OO编程在大量计算机之间进行可伸缩性处理时所带来的死锁问题。,发展现状与未来趋势,3,不过如果我们认为共享的可变状态是进行可伸缩性处理时的问题，那么我们为何不将数据库设计为可变的呢？如果考虑到了这一点，那么你会发现数据库只不过是个大型的共享的可变存储（有点像所有服务器共享的一个全局变量集合）。很多公司现在都在探寻不变数据存储的属性数据库可以接收新的数据，不过现有数据通常不会被修改或删除。,Thank You!,