分布式海量空间数据存储结构研究*

刘小春

(信息工程大学，河南 郑州 450052)

0 引言

从1970 年美国IBM 公司的E．F．Codd 提出关系模型以来，关系数据库以其具有概念单一、存取路径对用户透明、数据独立性好等优势，在各个应用领域都为数据库用户提供了对结构化数据的简单、健壮、灵活、高效的组织和管理方法，对于空间数据的存储和管理，又催生出许多对象关系数据库，如Oracle11g 提供了管理多维矢量数据和栅格数据的对象机制，使用户对复杂空间数据的管理像对关系数据的管理一样简单易用，基于数据库也易于满足网络应用的共享性、保密性和并发性。

目前，情形有些变化，在分布式环境下，对于数量不断增长的应用程序而言，应用和数据的可伸缩性日益重要，对非结构和半结构数据的管理要求越来越高，在Internet 网络空间应用环境中，应用服务器、数据服务器承受大规模工作负荷的应用的情况下，数据服务器负载不断提升的情况下，采用诸如Oracle 数据库服务器会遇到越来越多的困难，需要解决越来越多的难题，如海量空间数据中心有1 台负载均衡数据库服务器和20 台数据库服务器，负载每日剧增，如何快速升级硬件及重新部署数据以满足快速增长数据需求的需要。

关系数据库的可伸缩性在单台服务器上能较好地得到体现，但一旦单服务器的负载达到极点，必须通过多台数据库服务器来提供服务，这时多节点服务器会遇到管理复杂性、数据一致性复杂性、数据共享复杂性、数据存储复杂性等问题，这些问题严重影响了数据库应用规模。在分布式网络环境中，对关系数据库的要求更高，要能支持分布式事务管理、分布式并行操作和分布式存储等。对于海量空间数据的组织管理，需要高效强大的存储和管理机制，有效实现空间数据的组织、存储、管理和检索，以满足分布式网络环境中大量用户的并发频繁访问。

Google Earth 在应用中没有使用传统的对象关系数据库部署数据，而是开发了一个用于满足大规模的分布式数据存储系统BigTable，用于存储海量数据和高校检索数据，BigTable 是基于键/值的一种新的数据模型，有效解决了Google 应用环境下的海量数据存储和高效服务，对各种海量多源空间数据进行了科学的组织［1］。为此，本文研究了数据在Oracle 和BigTable 中的存储结构，并对两种结构各自的优缺点进行了分析。

1 关系数据库中空间数据的存储结构

Oracle 系统是分布式对象关系数据库管理系统，对于空间位置数据和属性数据可以以面向对象的方式一体化存储、组织管理，支持在Windows、Linux、Unix 多种操作系统环境下使用，支持Oracle SQL* NET TCP/IP 的通信模式［2］。Oracle RDBMS可以部署在分布式网络环境中，通过结点事务一致性和全局事务一致性，可以实现结点自治和全局同步［3］。

Oracle 的逻辑结构由表空间、数据段、数据区间和数据块组成。一个Oracle 数据库从逻辑上说是由一个或多个表空间所组成，每个表空间包含多个数据文件，每一个数据文件仅能属于一个表空间，Oracle 的逻辑对象保存在表空间中，表空间是数据库中的数据仓库，数据库的表、索引、视图等逻辑对象均保存在表空间中，表空间的大小取决于所属的数据文件大小，每一个表空间由若干段(segment)组成，一个段由一组区(extent)组成，一个区又由一组连续的数据块组成，数据块的大小一般是操作系统数据块大小的整数倍。

图1 是Oracle 逻辑结构与物理结构的对应关系，物理结构是逻辑结构在物理上的体现，主要包括数据库、物理文件和物理块。

图1 Oracle 数据库的逻辑结构和物理结构Fig．1 The logical and physical structure of Oracle database

表1 和表2 描述了以道路表为例的数据库的存储模型，道路表中按行存储有道路的道路类型、宽度、小巷数量、道路名等属性数据，几何数据字段中存储有道路的矢量数据，而道路表中的道路类型ID 列是外键字段。道路表和道路类型表构成主外键关系，在道路表中既存储有道路的几何位置数据，又存储有道路的属性数据，实现了空间位置数据和属性数据的一体化存储。

表1 道路表Tab．1 Road table

表2 道路类型表Tab．2 Road type table

基于数据库的分布式应用中，可以采用负载均衡服务器、多数据服务器、分区表及分区表索引、数据库链路、分区内空间聚簇［4］等方法解决海量空间数据的海量存储和高效检索问题。

2 BigTable 中空间数据的存储结构

BigTable 数据模型是一个有序的分布式多维表结构，能满足结构化或半结构化的海量数据存储，提供了从关键字到数据值的映射关系，用行关键字、列关键字、时间戳三元组和内容来表示，可利用行关键字、列关键字和时间戳对数据进行索引［5］。

BigTable 按照行关键字对表的行进行排序，并且动态将数据行分割成若干个行空间，一个行区间称作一个Tablet，由专门的服务器对多个Tablet 进行管理。

图2 是BigTable 的体系结构。BigTable 主要包括3 部分［6］:一个ClientLib 组件部署在客户端;一个主服务器(Master);多个Tablet 服务器(TabletServer)。BigTable 不支持完整的关系模型，但是建立在GFS 文件系统上容易实现分布式存储海量数据，存储数据文件和日志文件，使用Chubby 提供锁服务，Chubby 是一个序列化的分布式锁组件，使用Paxos 算法保证数据副本的一致性，系统根据负载变化，动态添加或者删除Tablet 服务器。

图2 BigTable 体系结构图Fig．2 BigTable architecture chart

ClientLib 部署在客户端，通过API 向客户端程序提供统一操作的调用接口，并且在客户端缓存读到的数据，以加快处理速度。每个Tablet 服务器对一组Tablet 进行管理，Tablet 服务器主要是处理客户端对Tablet 的读写请求，并对Tablet 进行分割。Master 服务器中存储Tablet 服务器的状态，通过状态可判断哪些Tablet 服务器活跃，进而获得哪些Tablet 分配给哪些Tablet服务器，哪些Tablet 没有分配。Master 实现了均衡Tablet 服务器的负载，对Tablet 进行有效的管理，并对垃圾GFS 文件进行回收管理。

在BigTable 系统中，每个表由多个数据块(Tablet)和结构信息(Schema)组成，如图3 所示。主服务器Master 负责管理表结构信息，Chubby 组件对其进行存储，保证数据一致性，Tablet服务器负责管理数据块，GFS 文件系统用于管理数据块的内容。

图3 BigTable 表的结构图Fig．3 The structure chart of BigTable table

表数据以Tablet 数据块的形式分布在不同的服务器上，Tablet 的位置信息保存在元数据表中，这既实现了数据的分布存储，也提高了数据并发访问性能。在读写数据操作之前需要查找元数据表，确定数据块的位置，然后再进行读写，如果查询涉及多个位置的Tablet 服务器，需要将结果整合后提供给用户使用，当然这个过程对用户是完全透明的。BigTable 使用类似B+树的3 层结构［5］来存储Tablet 的位置信息，如图4 所示。

图4 Tablet 位置层次结构图Fig．4 Tablet location hierarchy chart

图4 中元数据表以分层的形式存储Tablet 的位置信息，图中方框部分是BigTable 集群中的分层元数据表。每个元数据块保存着一组下层数据块的位置信息。

3 对比分析

BigTable 键/值数据库应用越来越广泛，但是关系数据库还在大量使用，两种存储模型各有优劣，主要表现在这些方面:

1)BigTable 键/值存储模型简单，从可伸缩性上比关系模型要好很多，但是值数据不区分，全部作为字符串来存储，为用户程序解析带来了较大的麻烦。

2)从面向对象角度看，关系数据库逐渐支持面向对象数据存储，而键/值的存储模型面向对象性较差，在存储有面向对象特点的海量空间上支持较弱，不利于空间分析和空间索引的创建。

3)键/值数据库目前主要用于更新操作少、查询操作多的应用，并且在连接查询上支持较弱，相比较而言，基于数据库存储结构在连接查询和数据更新方面都比较方便。

4)BigTable 数据模型具有较强大的扩充能力，提供了基于相对廉价的存储设备实现高效存储的方案，基于BigTable 容易实现根据用户需求分配存储和计算资源，实现了按需分配，随着用户需求增长，配额能随之而增，整个存储空间的大小基本不受限制。而对于Oracle 等对象关系数据库，虽然可以分布式部署，但是当单个的数据库服务器不能满足剧增的用户需求时，配备硬件和软件环境都需要付出高额费用，并且随之而来的还有管理复杂性等问题的出现。

5)关系数据库通过设立主键、外键等完整性约束机制基本能保证数据在最低层次拥有完整性一致性。违反完整性约束的数据不能存入数据库中，更新的数据违反完整性约束也不能更新，删除数据违反完整性约束也不能删除，这些机制较好地保障了数据库中数据的完整性一致性。但在键/值数据库中不存在这些机制，需要通过应用程序进行控制，但是程序往往是不健全的，或者部分用户提交的代码是不健全的，没有考虑完备的数据完整性机制，难以确保入库数据的完整性，并且从应用程序的角度来考虑，提高了软件开发的难度和代码量。

6)关系数据库的建立往往基于数据建模，而数据建模在很大程度上对应用程序开发是独立的，这意味着多个应用程序可以使用同一数据集，应用逻辑的改变也不影响底层的数据模型，但是键/值数据库要想实现这种独立性，显然比较困难。

7)BigTable 不是行存储，而是列存储，以道路表的数据存储为例，对于传统的DBMS，它在磁盘上是按照记录存储数据，格式如下:

Table 中的每一行(即每一条记录)在磁盘上是紧密排列的，也就是按行进行存储的。一般最常用的Database，如MySQL，Oracle 等，都属于此类。

而在列存储方式中则不同，对于道路表，它的列存储逻辑结构，如表3 所示。它将表中的每一列的数据项放在了一起。实际中列存储会更复杂一些，还要存储行关键字、列关键字、时间戳及列的内容，早期的数据库主要为满足OLTP 的需求，大部分的操作都是插入删除，行存储自然成为最适合的方案，因为采用行存储可以很容易的找到一个记录所包含的所有数据。但是，在当前海量数据的情况下，OLAP 的需求越来越大，相当多复杂的查询，列存储在这种情况下就很有优势。

表3 BigTable 中的道路表Tab．3 Road table in BigTable

表3 在磁盘上按列存储的结构如下:

1 水泥

2 柏油

3 土路

1 60

2 40

3 30

…

8)BigTable 数据库不像关系数据库，并没有多少办法去共享标准。BigTable、Hyptertable、HBase 这些键/值数据库都相似，但是API 却不同，均具有特定的访问接口。这种情况下，你选用哪种数据库，主要依赖于你对于哪类数据库的信任程度，另外，从成熟度来说，成熟的关系数据库比键/值数据库可靠性更强些。

4 结束语

通过研究空间数据在关系数据库和BigTable 数据库中的存储模型，以及两种存储模型的优缺点，可以看出:目前BigTable数据存储机制并不能完全替代关系数据库，对象关系数据库以其使用简单，容易共享、并发等特性，在许多应用中还有其独特的优势，但BigTable 作为一种键/值数据库代表，在大规模分布式应用环境下将会大放光彩。

［1］ 蔡磊，龚健雅．分布式海量空间数据的组织与网络可视化［J］． 测绘信息工程，2009，34(6):28 -30．

［2］ 刘勇，寿春法，印洁，等．城市GIS 社会化应用中的分布式数据组织方法研究［J］．测绘科学，2007(11):96 -98．

［3］ 罗艳秋，张书艳． 基于Oracle 的GIS 数据库的分布式设计与实现［J］．中国科技信息，2005(9):18 -20．

［4］ 冯杭建，刘南，刘仁义．Linux 环境下基于Oracle Spatial 的分布式海量空间数据处理平台的设计与实现［J］． 计算机应用研究，2004(7):111 -113．

［5］ 费江涛，张晓清，潘清．基于表结构的海量数据管理系统技术综述［J］．计算机与现代化，2010(1):166 -168．

［6］ 张晓清，费江涛，潘清．分布式海量数据管理系统BigTable 数据服务器设计［J］．网络安全技术与应用，2009(3):56 -57．