NoSQL非关系型数据库技术和应用

NoSQL非关系型数据库技术和应用CONTENTS目录

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