1、CONTENTS目 录 ONTENTS123目 录ONTENTSCONTENTS123NoSQL数据库是非关系型数据存储的广义定义，它不同于符合ACID理论的关系型数据库，数据存储不需要固定的表结构，通常也不存在连接操作。NoSQL数据库不使用传统的关系数据库模型，而是使用如键值存储数据库、列存储数据库、文档型数据库、图形数据库等方式存储数据模型。基础理论与架构分类1NoSQL共同特征：1）不需要预定义模式：不需要事先定义数据模式，预定义表结构。数据中的每条记录都可能有不同的属性和格式，当插入数据时，并不需要预先定义它们的模式；2）无共享架构：相对于将所有数据存储的存储区域网络中的全共享架构，
2、NoSQL往往将数据划分后存储在各个本地服务器上。因为从本地磁盘读取数据的性能往往好于通过网络传输读取数据的性能，从而提高了系统的性能；基础理论与架构分类13）弹性可扩展：可以在系统运行的时候，动态增加或者删除结点。不需要停机维护，数据可以自动迁移；4）分区：相对于将数据存放于同一个节点，NoSQL数据库需要将数据进行分区，将记录分散在多个节点上面。并且通常分区的同时还要做复制。这样既提高了并行性能，又能保证没有单点失效的问题；基础理论与架构分类15）异步复制：和RAID存储系统不同的是，NoSQL中的复制，往往是基于日志的异步复制。这样，数据就可以尽快地写入一个节点，而不会被网络传输引起迟延
3、。缺点是并不总是能保证一致性，这样的方式在出现故障的时候，可能会丢失少量的数据；6）BASE：相对于事务严格的ACID特性，NoSQL数据库保证的是BASE特性。基础理论与架构分类1NoSQL适用情况：1）数据模型比较简单；2）需要灵活性更强的IT系统；3）对数据库性能要求较高；4）不需要高度的数据一致性。基础理论与架构分类1CAP理论：CAP解释为一致性（consistency）、可用性（availability）和分区容忍性（partition tolerance）。一致性：一个数据系统如何处理读写操作的一致性问题。分布式系统对于一致性的要求为当更新写入操作完成时，其余读取操作需要及时看到
4、数据的更新；基础理论与架构分类1可用性：一个系统能够持续不间断使用的问题。严格定义上的高性能可用性意味着一个系统从设计到实施都应该能够提供可持续的操作；分区容忍性：一个系统在提供持续性操作时分区处理的能力。一旦开始将数据和逻辑分布在不同的节点上，就有形成分区的风险。假定网线被切断，就形成分区，在不同分区的节点A和节点B无法通信。由于Web提供的这种分布式能力，临时的分区是一个常见的情况，处理这种情况就属于分区容忍性。基础理论与架构分类1基础理论与架构分类1选择特征实例一致性+可用性2PC缓存验证单机数据库、集群数据库、LDAP、xFS一致性+分区容忍性乐观锁分布式系统、分布式锁、大部分的协议可
5、用性+分区容忍性冲突解决，乐观化Coda（分布式档案系统）、网络缓存、DNS表1 CAP理论应用及实例基础理论与架构分类1表2 CAP理论数据库应用实例及功能分类选择例子对应功能分类一致性+可用性MySQL关系型数据库Vertica列存储数据库一致性+分区容忍性BigTable列存储数据库HBase列存储数据库MongoDB文档型数据库可用性+分区容忍性Dynamo键值存储数据库Cassandra列存储数据库BASE理论：传统ACID模式对于数据的属性要求非常高，在分布式系统中比较难以达到。所以在CAP理论的基础上，提出了BASE思想，对一致性进行概化处理。要解释BASE思想，首先要对ACID
6、有一个了解，因为BASE是相对于DBMS中的ACID所提出来的新思想。基础理论与架构分类1ACID指的是传统数据库对于数据特性的要求。原子性：即事务执行作为原子，不可再分离，整个语句要么执行，要么不执行，不可能停在中间某个环节；一致性：在事务开始之前和事务结束之后，数据库的完整性约束没有被破坏；隔离性：两个事务的执行互不干扰，也不会发生交互，一个事务不可能看到其他事务运行时中某一时刻的数据；持久性：在事务完成以后，该事务对数据库所做的更改便持久地保存在数据库之中，并不会被回滚。基础理论与架构分类1在数据库系统中，事务的ACID属性保证了数据库的一致性，如银行系统中，付款就是一个事务，从原账户扣
7、除金额以及向目标账户添加金额，这两个数据库操作的总和构成一个完整的逻辑过程，为原子操作不可拆分，从而保证了整个系统中的总金额没有变化。但是ACID特性对于大型的分布式系统来说，与高性能是不兼容的。如在线购买商品的时候，任何一个人购物的过程都为一个原子操作，不允许存在两个人同时进行购物的情况。很明显对于绝大多数在线商城，这个方法并不适用。基础理论与架构分类1BASE思想实际上是CAP理论中AP的衍伸。它通过牺牲高一致性，保证高可用性和分区容忍性。BASE思想的组成有以下3个部分：基本可用、软状态、最终一致性。BASE模式指的是一个应用在任意时间首先应该能完成最基本化的工作（即基本可用），并不需要
8、总是一致（即软状态），但最终应该是一致（即最终一致性）的。ACID和BASE应该被看作同一范畴内的互相补充品，而不是替代品。基础理论与架构分类1基础理论与架构分类1表3 BASE与ACID的优缺点对比ACIDBASE高度一致弱一致，仅需要针对性数据高度分割化可用性第一位着重于“提交”一般注重网状事务较为激进弱可用性注重可用性较保守更简单扩展性不强更快，更具有扩展性NoSQL大致可以分为四类，分别为键值存储数据库、列存储数据库、文档型数据库和图形数据库。键值存储数据库键值存储典型实现的数据结构一般为数组链表：先通过通过hash算法得出hashcode，找到数组的某一个位置，然后插入链表的第一个位
9、置。基础理论与架构分类1BigtableBigtable是一个稀疏、分布式、持久化存储的多维有序映射表，表的索引是行关键字、列关键字和时间戳。Bigtable中存储的表项都是未经解析的字节数组，其数据模型如下：(row:string,column:string,time:int64)-string 基础理论与架构分类1示例：一个存储了大量网页及其相关信息的表Webtable，Webtable使用URL作为行关键字，使用网页的某些属性作为列名，网页的内容存入contents列中，并使用获取该网页的时间戳标识同一个网页的不同版本。基础理论与架构分类11）行关键字 行关键字可以是任意字符串，目前最大
10、支持64KB。Bigtable按照行关键字的字典序组织数据，利用这个特性可以通过选择合适的行关键字，使数据访问具有良好的局部性。表的行区间可以动态划分，每个行区间称为一个子表。子表是数据分布和负载均衡的基本单位，不同的子表可以有不同的大小。基础理论与架构分类12）列族 列关键字一般都表示一种数据类型，列关键字的集合称作列族，列族是访问控制的基本单位。存储在同一列族下的数据属于同一种类型，列族下的数据被压缩在一起保存。数据在被存储之前必须先创建列族，并且表中的列族不宜过多，通常几百个，但表中可以有无限多个列。基础理论与架构分类13）时间戳 Bigtable中的表项可以包含同一数据的不同版本，采用
11、时间戳进行索引。时间戳是64位整型，既可以由系统赋值也可由用户指定。为了简化多版本数据的管理，每个列族都有两个设置参数用于版本的自动回收，用户可以指定保存最近 N 个版本，或保留足够新的版本（如最近7天的内容）。基础理论与架构分类1列存储数据库列数据库是对应并区别于行数据库的概念。行数据库就是我们所熟知的传统关系型数据库，即数据按记录存储，每一条记录的所有属性都存储在一起，如果要查询一条记录的一个属性值，需要先读取整条记录的数据。而列数据库是按数据库记录的列来组织和存储数据的，数据库中每个表由一组页链的集合组成，每条页链对应表中的一个存储列，而该页链中每一页存储的是该列的一个或多个值。基础理论
12、与架构分类1HBaseHbase是运行在由多个节点构成的服务集群基础之上，为TB级甚至PB级别的数据存储提供支持，并为用户提供基于Row Key的高效查询机制，它是由一个一个Row Key作为唯一标识，并包含任意多例的一张表来根据存储的数据量以大小被分割成一个或多个称为 region 的子表基础理论与架构分类1基础理论与架构分类1一个HBase集群通常由一个master和多个region组成，且每个region Server管理一个或多个由master分配的region，而master则负责维护每个region的元信息，以及region和region Server之间的映射关系。基础理论与架构
13、分类1region中的数据最终将被存放在Hadoop的多副本分布式文件系统HDFS中，且每个值出现一个region，使得同一时间t内每个region只被分配给一台region服务器，就让所有行内的mutation操作都是原子操作，所有的put操作要么完全成功、要么完全失败，以及通过任何API返回行的内容总是一个完整的行，最后就使得跨行的mutation操作不是原子操作。基础理论与架构分类1进一步地，对于HBase的表与region表现为：表被动态地分割成region，且放在一个或多个region服务上，当region随着增大时，它们会被切分并平均分布在region服务器上，使得切分操作接近实时
14、，则表现为从高负载节点迁移走，并且使错误的region节点会重新部署到正常节点上。同时，HBase采用 Zookeeper协调服务，保存Hadoop的集群状态、故障或变更通知，并集成MapReduce，Jruby的命令外壳，使得HBase避开了HDFS只能append的限制，将最近更新的数据保存在内存中，逐步重写数据至新的文件中，并进行智能拆分与合并。基础理论与架构分类1文档型数据库文档型数据库的灵感是来自于Lotus Notes办公软件的，而且它同第一种键值存储相类似。该类型的数据模型是版本化的文档、半结构化的文档以特定的格式存储，例如JSON。文档型数据库可以看作是键值数据库的升级版，允许
15、之间嵌套键值。而文档型数据库比键值数据库的查询效率更高，如：CouchDB，MongoDb。国内也有文档型数据库SequoiaDB，已经开源。基础理论与架构分类1MongoDBMongoDB是10gen公司研发的面向文档的开源的NoSQL数据库系统，用C+语言编写。它提供一种强大、灵活、可扩展的数据存储方式。它扩展了关系型数据库的众多功能，如辅助索引、范围查询和排序。MongoDB的功能非常丰富，比如内置的对MapReduce聚合的支持，以及对地理空间索引的支持。基础理论与架构分类1MongoDB的主要特性1）数据类型丰富。MongoDB是面向文档的数据库，放弃关系模型的一个主要原因是为了获得
16、更加灵活的扩展性。它是无模式的，文档的键不会事先定义也不会固定不变，应用层可以方便地处理新增的键或丢失的键，为开发者变更数据模型提供极大的便利；2）功能丰富。支持辅助索引、存储JavaScript和MapReduce等其他聚合工具的独特功能；基础理论与架构分类13）容易扩展。MongoDB在设计时考虑了系统扩展的问题，面向文档的数据模型可以自动在多台服务器之间进行分割。通过其Auto-Sharding机制，可以自动实现集群的数据和负载均衡；4）性能卓越。MongoDB对文档进行自动动态填充，预分配数据文件，用空间换取性能的稳定。默认的存储引擎中使用了内存映射文件，将内存的管理工作交给操作系统去
17、处理。基础理论与架构分类15）管理简便。尽可能的让服务器自动配置，通过复制机制来提升系统的可靠性。MongoDB的核心概念是文档，多个键及其相应的值有序地存放在一起组成文档，文档类似于关系型数据库中的元组。多个文档组成集合，集合如同关系型数据库中的表。多个集合组成数据库，一个MongoDB的实例可以承载多个数据库，每个数据库之间是完全独立的。基础理论与架构分类1基础理论与架构分类1MongoDB的文档采用BSON格式存储，BSON是Binary JSON的简写，是一种类似于JSON文档的二进制序列化方案。用BSON格式來存储数据具有如下三个优势：轻量级、容易遍历和高效。基础理论与架构分类1基础
18、理论与架构分类1图形数据库图形数据库就是将数据存储在图（Graph）结构中。图示是一个简单的有向无环图。其中，节点表示一个实体。例如人或商品。边表示点与点之间的连接关系，可以是有方向和无向的。如用户买了商品表示；如果用户与用户相互都认识，这种关系就是双向的，表示为。属性表示点和边所附带的属性。例如用户姓名、年龄等。需要注意的是每个点或边的属性是动态可变的。基础理论与架构分类1图形数据库可以看作是结点与关系的集合，图形数据库就是将数据存储在拥有属性的结点中，并用关系将这些结点组织起来。基础理论与架构分类1数据存储的重要目的是为了检索。图的查找与搜索可以通过遍历算法完成，根据算法，从开始结点到与之
19、相连的结点查询诸如“我好友的好友是哪些人”等问题。所以通过遍历算法可以对图进行导航与操作，从而确定结点之间的路径。基础理论与架构分类1键值存储数据库适用的场景 储存用户信息，比如会话、配置文件、参数、购物车等等。这些信息一般都和ID（键）挂钩，这种情景下键值数据库是个很好的选择。基础理论与架构分类1不适用场景 1）取代通过键查询，而是通过值来查询。Key-Value数据库中根本没有通过值查询的途径。2）需要储存数据之间的关系。在Key-Value数据库中不能通过两个或以上的键来关联数据。3）事务的支持。在Key-Value数据库中故障产生时不可以进行回滚。基础理论与架构分类1列存储数据库 适用
20、的场景 1）日志。因为我们可以将数据储存在不同的列中，每个应用程序可以将信息写入自己的列族中。2）博客平台。我们储存每个信息到不同的列族中。举个例子，标签可以储存在一个，类别可以在一个，而文章则在另一个。基础理论与架构分类1不适用场景 1）如果需要ACID事务。Vassandra就不支持事务；2）原型设计。如果我们分析Cassandra的数据结构，我们就会发现结构是基于我们期望的数据查询方式而定。在模型设计之初，我们根本不可能去预测它的查询方式，而一旦查询方式改变，我们就必须重新设计列族。基础理论与架构分类1面向文档型数据库 适用的场景 1）日志。企业环境下，每个应用程序都有不同的日志信息。D
21、ocument-Oriented数据库并没有固定的模式，所以我们可以使用它储存不同的信息。2）分析。鉴于它的弱模式结构，不改变模式下就可以储存不同的度量方法及添加新的度量。基础理论与架构分类1不适用场景 在不同的文档上添加事务。文档型数据库并不支持文档间的事务，如果对这方面有需求则不应该选用这个解决方案。基础理论与架构分类1图形数据库 适用的场景 1）在一些关系性强的数据中；2）推荐引擎。如果我们将数据以图的形式表现，那么将会非常有益于推荐的制定。不适用场景 不适合的数据模型。图数据库的适用范围很小，因为很少有操作涉及到整个图。基础理论与架构分类1目 录ONTENTS213CONTENTS部署
22、方案与性能分析2数据存储案例：1）使用文档型数据库MongoDB深度挖掘天气现象数据内在价值：探究如何通过MongoDB实现对数据的存储；2）基于Hbase的地震大数据存储研究：探究通过Hbase对数据存储的效率。部署方案与性能分析2使用文档型数据库MongoDB深度挖掘天气现象数据内在价值地面气象观测基本资料中的天气现象数据与气温、雨量、气压等其他结构化数据不同，天气现象数据更像是一种非结构化数据，它模式不固定，由现象符号编码与表示方位、起始终止时间等内容的字符串组合而成。部署方案与性能分析2天气现象数据的存储1）建立数据库以及集合在MongoDB的Shell界面中，使用命令Use dbna
23、me，该命令建立数据库dbname，也同时将当前工作切换到名为dbname的数据库中。集合类似于RDBMS中的“表”（table）。集合是不需要显式建立的，当存入数据时，使用某个新的集合名，数据库会自动建立这个新的集合。例如db.test.save(数据文档)，就会自动建立一个名为test的集合。部署方案与性能分析22）将原始数据编码成BSON格式文档一个文档就是一条记录，比如有以下表1是A文件（全国地面气象资料基本格式文件）中两天的天气现象原始数据，为了保存入MongoDB数据库，我们通过Java语言编程从 A 文件中读取出原始数据，然后分别编码成两个BSON格式文档如表2所示。部署方案与性
24、能分析2部署方案与性能分析2部署方案与性能分析23）存储操作（1）首先把键值日期“rq”建立成唯一索引，保证在一个集合中不会出现重复日期的文档。使用Shell命令db.test.ensureIndex(“rq”:1,“unique”:true,“dropDups”:true)；建立该唯一索引以后，当插入或存入文档键值“rq”有重复时，将会返回错误，若需跟新数据，只有删除存在的文档再插入，或者通过 update 命令更新已存在的文档。这与RDBMS中的使用主键类似；部署方案与性能分析2（2）使用db.test.save（文档）命令或者db.test.insert（文档）命令，将编码后的天气现象数
25、据存储到MongoDB系统dbname数据库中的test集合中；（3）使用update命令更新已经存入的文档。例如需要修改日期为“20120719”的文档的天气现象数据,使用命令db.test.update(“rq”:”20120719”,$set:“ww”:天气现象文档数组)；部署方案与性能分析2（4）使用remove命令删除已经存入的文档。例如需要删除 日 期 为“2 0 1 2 0 7 1 9”的 文 档，使 用 命 令db.test.remove(“rq”:”20120719”)。部署方案与性能分析22.基于Hbase的地震大数据存储研究1）存储原理Hbase表是一个分布式多维表，表中
26、的数据通过一个行关键 字（R o w K e y）、一 个 列 族 和 一 个 列 名（Colunmfamily:column name）以及一个时间戳进行索引和查询定位。其关键在于设计好Row Key，以方便数据查询和数据分析。部署方案与性能分析2地震信息的业务逻辑是通过台网（Netid）、台站（Stationid）、测点（Pointid）、仪器（Intrid）、测项（Itenid）、采样率（Samplerate）、产品类别（Protype）和时间戳（Timestamp）进行查询的。部署方案与性能分析2假设地震业务数据库中有一个Obs观测数据表，按照传统的RDBMS，Obs表中的列是不能随意
27、改变的，比如Schema定义了Netid、Stationid、Pointid、Intrid、Itenid、Samplerate、Protype、Timestamp等属性，Obs表的属性是不能动态增加的。而对于Hbase列存储数据库，在创建Obs表时，再为它定义一个info列族，Obs的数据便可以表示为info:value=23.4。如果要增加新的字段属性，只需要通过添加一个info:newProperty就可以了。部署方案与性能分析2因此，如果采用传统关系数据库存储将非常复杂，且会造成一些为空值的存储浪费。而Hbase就不会出现该问题，列存储的每一个列单元如果是空值，则不占用存储空间。部署方案
28、与性能分析2因此Hbase的基于列存储数据模型非常适合地震数据频繁扩展的场景。另外Hbase数据库还能自动切分数据，当Obs表中的数据超过某一个阀值时，Hbase就会自动切分数据，使查询具有伸缩性。再加上Hbase的弱事务性，使得Hbase的数据写入效率非常高。Row Key是类似关系数据库中的主键，在Hbase中的存储也是根据Row Key来排序的。另外Hbase不支持条件查询和Order by等查询方式，故Row Key的设计要根据应用系统的查询需求而定。部署方案与性能分析2根据上述地震业务需求，观测数据表Obs的Row Key可以由以下几个部分构成：、。当要查询某个台网某个时间段数据时，
29、就可以指定起始Row Key为，终止Row Key为。其他各种组合需求，比如要查询某个自然测点数据、某台仪器的数据、某个学科数据、某个测项分量数据等，都可以非常高效地检索出来。部署方案与性能分析22）存储方法实现从数据结构角度，地震数据可划分为两类：观测产生的结构化数据和文件、图像等非结构化数据。部署方案与性能分析2（1）结构化数据存储地震典型的普通结构化数据就是前兆，存放在Oracle数据库和测震存放在MySQL数据库的关系型观测数据，主要包括前兆各学科（形变、重力、GNSS、地下流体、地电、地磁等）和测震学（地震目录、观测报告、事件波形、连续波形等）数据。这些观测数据，分别从前兆Oracl
30、e库、测震MySQL库读取出来，通过上述存储方法存储至Hbase设计的Obs表中进行统一存储管理。部署方案与性能分析2（2）非结构化数据存储地震非结构化数据存储时，Hbase有着不可取代的优势：更有效地存储小文件（小于16MB）；提供更高层和更可靠的接口，可以方便实现数据的增删查改功能；提供失败自动重试机制，有效地保证数据的一致性。部署方案与性能分析2Hadoop开发了Hbase大对象LOB（large objectstorage）存储功能，方便用户在Hbase中存储各种类型的大对象。存储时，LOB Store是列族级别的存储单元，每个LOB Store可以存储几百万个文件，而LOB Stor
31、e的底层存储在LOB File中。读写方面，其插入性能提高到100%，插入延时减少90%，读取的随机性能可达到200%。部署方案与性能分析23）对比测试（1）测试平台环境为对比Hbase-0.94.6和MySQL-5.1.48的存储、查询等性能指标，由3台配置相同服务器的Hadoop集群组成分布式文件系统，构成一个逻辑Hbase集群，同时由其中一台机器单机测试MySQL。部署方案与性能分析2硬件环境软件环境3台服务器，CPU均为4核i5处理器，8G内存，1T硬盘，千兆网络CenteOS6.4、Hadoop-2.0.0、Hbase-0.94.6、MySQL-5.1.48 部署方案与性能分析2（2
32、）结构化数据存储性能对比将两者针对结构化观测数据的存储进行效能测试，在关键代码处添加秒表，记录执行命令的时间。数据量（条）分别为50、100、1 000、10 000、100 000，每次插入保存完毕把所耗时长写入日志文件。连续多次测试，取平均值。部署方案与性能分析2通过反复测试与效率对比发现，观测数据读取性能较高情况为：测震连续波形数据，每条记录保存10min长度数据；前兆分钟以上采样率观测数据，每条记录保存1h长度数据。部署方案与性能分析2（3）非结构化数据存储性能对比分别对Hbase-0.94.6和MySQL-5.1.48做10、50、100、200、500、1 000次文件写入试验，文
33、件大小约30KB/个，两者的二进制文件存储耗时性能对比结果如图所示。部署方案与性能分析2（4）查询性能对比分别对Hbase-0.94.6和MySQL-5.1.48做数据量为1 000、2 000、10 000、100 000、500 000的查询性能测试。目 录ONTENTS321CONTENTS发展现状与未来趋势3发展现状与未来趋势3DB-Engines Ranking发展现状与未来趋势3NoSQL得到如此广泛的普及主要有3个驱动力。首先是需求。在过去的几年间，互联网与移动的流量呈现出了爆发性的增长，现在很多大公司所处理的数据规模是几年前我们几乎不曾想到的。传统的关系型数据库在设计时从未考虑
34、过能够比较容易地实现跨节点可伸缩这一特性，因此NoSQL在那些需要能够实现快速、轻松且低成本可伸缩的公司中开始流行起来；发展现状与未来趋势3其次是可用性。在过去几年间，开源软件真的开始成熟起来了，现在已经出现了很多成熟的开源NoSQL存储，这样公司就可以轻松找到满足其需求的数据存储方案了；最后是新兴性。现在一定存在使用NoSQL构建，但关系型数据库却更加适合的应用。然而，随着NoSQL逐渐从新生事物变成主流，技术人员在选择适合其应用场景的解决方案时会变得更理性一些。发展现状与未来趋势3目前，NoSQL对大型企业来说还不是主流，尽管大多数NoSQL数据存储系统都已被部署于实际应用中，但归纳其研究
35、现状，还有许多挑战性问题。1）已有 key-value 数据库产品大多是面向特定应用自治构建的，缺乏通用性；2）已有产品支持的功能有限（不支持事务特性），导致其应用具有一定的局限性；发展现状与未来趋势33）已有一些研究成果和改进的NoSQL数据存储系统，但它们都是针对不同应用需求而提出的相应解决方案，如支持组内事务特性、弹性事务等，很少从全局考虑系统的通用性，也没有形成系列化的研究成果；4）缺乏类似关系数据库所具有的强有力的理论(如armstrong公理系统)、技术（如成熟的基于启发式的优化策略、两段封锁协议等）、标准规范（如SQL语言）的支持；发展现状与未来趋势35）目前，HBase数据库是
36、安全特性最完善的NoSQL数据库产品之一，而其他的NoSQL数据库多数没有提供内建的安全机制或安全机制不完善。发展现状与未来趋势3NoSQL数据库可提供良好的扩展性和灵活性，但他们也有自己的不足。由于不使用SQL，NoSQL数据库系统不具备高度结构化查询等特性，此外不同的NoSQL数据库都有自己的查询语言，这使得很难规范应用程序接口。NewSQL指的是像NuoDB这样的现代数据库，他们将跨节点的可伸缩性与对SQL查询的支持结合起来了，这类数据库不仅具有NoSQL对海量数据的存储管理能力，还保持了传统数据库支持ACID和SQL等特性。发展现状与未来趋势3不同的NewSQL系统虽然内部结构变化很大
37、，但是它们有两个显着的共同特点：支持关系数据模型；使用SQL作为其主要的接口。我们现在尚处在NewSQL革命的黎明阶段，但显然，对于有的场景来说，NoSQL存储提供了比关系型代数更好的抽象能力；而对另一些场景来说，拥有开发者所熟知的编程模型的可伸缩数据库则是更好的解决方案。发展现状与未来趋势3NoSQL及NewSQL之后的大趋势是不变的数据存储。在过去几年中，围绕着使用函数式编程跨多台服务器进行高效的可伸缩性处理，人们讨论了很多。通过最小化共享的可变状态，函数式编程模型避免了OO编程在大量计算机之间进行可伸缩性处理时所带来的死锁问题。发展现状与未来趋势3不过如果我们认为共享的可变状态是进行可伸缩性处理时的问题，那么我们为何不将数据库设计为可变的呢？如果考虑到了这一点，那么你会发现数据库只不过是个大型的共享的可变存储（有点像所有服务器共享的一个全局变量集合）。很多公司现在都在探寻不变数据存储的属性数据库可以接收新的数据，不过现有数据通常不会被修改或删除。Thank You!
