1应用背景
数字图书馆的建设，自上而下可以分为网络、存储等硬件设置，数据资源层，应用支撑层，应用层，用户层，如图1所示。直接面临大数据挑战的是数据资源层。目前数字图书馆的数据资源层设计除一些共同特点之外，大都是针对不同的需求设计不同的方案，例如存储和内容的分发，元数据的管理和数据的采集，检索查询，服务应用，系统持久性的各方面都有很多不同，缺乏统一标准。这一事实客观反映了数字图书馆领域中的各方面的差异复杂性。在这些差异性中，最为基本的就是需要处理的数据形式上的差异。加州大学伯克利分校PeterLyman和HalVarian的研究报告[5]指出，2003年前世界产生的信息在1PB以上，但是在2011年IDC的研究报告指出，2011年全球数据总量1.8ZB，比2010年增加了1ZB。这些信息数量巨大，类型各异，包括文本，图像，图形，视频，音频等非结构化的数据。面对这些分布广泛，数量庞大，载体类型众多的数字资源，出现了大量的数据密集型应用需求，这些需求普遍存在的特点是：数据形式多样，数据量大，元数据复杂数据异构，数据分布广泛，数字资源之间的共享交换以及调度要求高，数据需要长期归档保存。于是，如何有效存储和管理数据成为了一个数字图书馆系统的关键。通常，如何存储和管理内容数据和元数据都取决于存储数据的类型和所使用的检索方式。一些通用的数字仓储系统例如DSpace[3]和CONTENTdm[6]在许多机构的一般规模的电子图书馆中使用十分广泛。但是对于更大规模的数字图书馆来说，他们往往选择自己开发自己的内容管理平台，例如NSDL[7]开发了NCore平台来管理他们的内容，NCore使用Fedora仓储管理软件并设计了自己的数据模型来支持NSDL系统，还开发了MPTCore作为管理RDF三元组的工具。目前，大部分仓储管理还是用关系型数据库作为系统的数据资源层管理系统来存储和管理大量的数字资源。
1.1数字图书馆系统业务流程
数字图书馆从建立到正常运行从数据资源层的层面来说如图2所示分为四个阶段：仓储服务建立阶段，数据导入阶段，数据优化加工阶段，上线运营维护阶段。仓储建立阶段包括仓储系统的设计与实现，需要针对系统的应用需求综合考虑系统的分布式架构，数据的存储方式，使得系统的效率达到最优。目前的数字图书馆不管从规模上还是服务提供上都比诞生初期有了飞速的发展，面对海量、异构的大数据和复杂的需求，过去普遍采用关系型数据库作为仓储的存储方式缺乏足够灵活性和扩展性，显得力不从心，设计高效可靠的仓储服务变得越来越困难。因此我们需要研究一种新的高可用、高可扩展和高可靠的数据仓储方式。数字图书馆在上线之前需要批量导入初始数据。目前产生数据大部分属于非结构化数据，而且很多情况下需要处理很多异构的数据。传统的关系型数据库要求数据必须是结构化的。这种情况下在导入数据的过程中为了保持数据的结构就会导致丢失一部分数据，如果数据是海量的，这样的数据损失就会变得不可接受。即使系统针对初始数据做了充分优化，能够同时保持数据的完整性和结构性，但是系统无法预知未来需要导入的数据的结构信息。因此需要一种灵活的数据管理方式，才能在有效管理数据的同时避免数据信息的丢失。对于导入的初始数据，系统需要对其进行一些加工之后才能为服务所用，例如数据的清理，集成，变换等等。其中一个重要的步骤便是建立索引。对于结构化的数据，关系型数据库提供良好的索引机制，但是对于非结构化和半结构化的数据，提供类似的索引就变得比较困难。另外对于文本数据来说，还需提供全文检索服务，因此需要系统能够针对不同的数据采取不同的策略。运营维护阶段主要需要保证系统的可用性和可靠性。首先需要满足用户的数据访问需求，其次要能够处理新的数据导入，还要便于系统维护。这需要图书馆系统在前三个阶段充分考虑各种因素，采用合理正确的设计。
1.2相关技术方法
针对上述问题，一些项目开始探索新的方式[8-10]，例如Europeana(http://www.europeana.eu/portal/)。Europeana不同于集中式内容管理的数字图书馆系统。它的内容来自于各个内容提供商（Federated），Europeana只存储内容的元数据（MetaData）[11]，用户需要从不同的内容供应商处获取实际内容。正因为Europeana并不维护实际内容，所以系统只需要维护索引内容即可。Europeana使用Solr(http://lucene.apache.org/solr/)作为其管理元数据的数据库，数据模型采用EuropeanaSemanticElement[12]。这种方式为目前的数字图书馆提供了一个很好的思路。但是这种设计可以很好的解决非结构化数据的查询问题，但那是并不能够解决上述的所有问题。目前大规模数字图书馆有很多，包括人们熟知的GoogleBook[13]等，这些数字图书馆系统也发展出了众多不同的架构来试图满足各种需求。美国的HathiTrust[14]等系统也提供了许多管理数字内容的方法。总结起来数字图书馆的架构中与应用层紧密相关的存储层服务归纳起来主要有内容存储和分布，元数据管理和收割，内容检索，系统可靠性与性能几个方面，其对应关系如图3。数字图书馆系统都要求有可靠的性能高的存储系统。特别是大型的数字图书馆，因为可能会有大量的用户试图同时访问请求资源，用户希望可靠且快速的获取所需资源。因此大型图书馆系统必须合理选择存储硬件、数据库、服务器的分布位置和方式以及存储数据的格式等等。存储硬件选择取决于系统的内容管理是集中式（Centrally）的还是联邦式（Federated）的。联邦式的系统内容是由不同的内容服务商提供，内容存储可以有不同架构的服务器管理。而集中式的管理系统则需要统一集中提供所有内容，因此现在系统大都使用集群式的存储来满足可靠性和可用性的需求。使用集中式内容管理的系统的一个典型实例是HathiTrust。HatthiTrust采用两个同步的存储中心存储数据，两个存储节点位于不同的地理位置，并且每六个月用磁带对数据进行加密备份。元数据管理收割包括几个部分：元数据格式，管理方式，内容收割和提取。DublinCore（DC）[15]是目前被广泛被数字图书馆采用的一种元数据格式，但是多数系统会根据自身情况进行定制修改。Europeana使用一种叫做ESE的数据模型作为其元数据。ESE同样是DublinCore和一些和自身系统相关的元素组成的。ESE的模型支持Europeana使用Solr来存储和索引系统的元数据这一重要特性。元数据的管理方式有两种，一种是元数据和相应的内容紧密结合，一种是元数据和内容分离。元数据和内容紧密结合的方式更利于系统的整体扩展性和更高的检索浏览性能；元数据和内容分离的方式被认为是元数据隶属于数据，因此必须要随数据的移动而移动，与数据分离的话容易出现元数据丢失的风险。大型的数字图书馆目前对于两种方式都有实现。还有通过结合元数据收割和内容吸收来相互弥补完善元数据的方法，并且每次通过元数据读取内容之后又可以利用内容完善元数据，这种方案被Europeana所采用。检索在过去几十年中一直是热门的研究课题。大型数字仓储使用最多的文本检索工具便是Lucene。Solar是一个使用Lucene库，被许多数字仓储系统所采用的全文检索系统，动态聚类，数据库集成和处理富文本等多种功能。Europeana使用Solar作为其元数据管理系统。同时一些非集中管理式的大型系统还使用抓取数据的方式进行检索。面向服务的架构（SOA）在大型数字图书馆领域十分流行，好的SOA设计可以使的系统有很好的扩展性，支持功能的动态增删改。HathiTrust和NSDL是两个典型的采用了SOA[16]思想的系统，这使得他们的开发十分的灵活，一项服务被开发出来之后可以十分灵活的被重用或者修改。同时，很多针对教育和图书馆的服务被开发了出来。除了使用SOA的架构之外，数字图书馆系统自身也提供很多服务和应用，比如Blog，Wiki等。在数字图书馆考虑构建一个健壮的内容管理系统的同时，一个同样重要的问题也许给予充分考虑：系统是否能够一直可靠运行。只有能够保证系统的可靠性，用户才能有充分的信任将数据存储在系统中。特别是决定系统是采用集中式还是联邦式的管理形式时，对各个层次能否保证其可靠性是首先应该考虑的问题。用户在使用系统是需要能够确定内容是否随时可用，因此数字图书馆应该保证能够随时提供任何用户所需的系统内的内容。HathiTrust是一个十分关注长期可靠性的系统，它采用模块化的架构，这种架构使得系统能够快速定位系统出现的问题并且支持分布式应用的开发。同时系统采用开放的标准和开放的系统，便于第三方为系统开发新的服务和组件。目前的数字图书馆系统架构几乎没有采用非关系型数据库作为其数据存储处理方式，但是有许多应用场景利用现有的单纯利用关系型数据库存储方式并不足以应对，因此需要提出新的架构设计方案。根据OpenDOAR提供的统计结果，截止到2013年，参与统计的2254家数字图书馆中有1011家使用自己的数字图书馆系统，只有约一半的数字图书馆使用如Fedora，DSpace等通用数据仓储系统。这一方面说明数字图书馆发展迅速，另一方面也说明数字图书馆应用需求复杂，很难设计通用的仓储系统。以Fedora为例，Fedora是一个通用的仓储系统，并且被广泛部署和使用。在Fedora中，所有数据被作为数据块存储在内部仓储系统中。这种低层次的设计便于数据存储，但是不便于数据管理。当前出现了很多专用的或者针对某种数据类型进行优化的系统，但是类似Fedora的仓储架构很难应用这些系统，因为其底层存储系统是固定的，无法灵活配置，因此我们需要一种灵活可配的数据仓储系统。
2PuntTable设计
PuntTable是一种针对灵活对象存储的键-值存储数据库。PuntTable的整体结构如图1所示，它实现了一个分布式的结构，包括一个全局控制中枢和多个数据存储节点。PuntTable使用JSON存储模型，提供了Get和Set等对于键-值操作的接口。PuntTable中的数据被存储在由行和列组成的表结构中。表中的每一行都有一个唯一的ID作为主键，然后其后的其他属性则为数据属性。然而，PuntTable并没有全局上的Schema概念。表中的每一行都是灵活的，并不受表关系限制。这种灵活性虽然能使基于数据库的开发和应用变得简单，但是却增大了对数据查询的难度。为了解决查询问题，PuntTable提供了多索引策略。本文中我们将着重介绍PuntTable的存储类型选择策略。图4是PuntTable的整体架构。
2.1PuntTable存储结构
数据模型PuntTable所使用的数据模型是key-value存储模型。PuntTable存储的记录包含key和value两个部分。其中value部分可以包含多个属性。对用户来说，PuntTable把数据存储在表结构中，就和传统的关系数据库一样。用户也可以对表结构进行定义。然而，PuntTable中的表结构不是固定的。表的每一行都可以有其独立的表结构。PuntTable通过JSON来存储数据，表中每一行的键与值都被存放在一个JSON型的数组记录中，然后再由这些JSON记录组成表。因为JSON是一种轻量级的数据转换，建立在顺序排列的名字和值组成的数据对上，所以它很适合被用于实现PuntTable的数据存储模型。接口设计PuntTable提供了数据存储和查询的接口。PuntTable可以用结构化和非结构化两种不同的方式存对数据进行键-值存储。一个键可以对应多个值。查询数据时可以直接查询所需要数据的键或者在限定的范围内进行值的查询。本文中我们会着重介绍PuntTable如何实现Get，Set，Del，和Search功能。Get和Set函数通过获得键来存储或者返回其他属性域上的值。Del操作主要是通过获得键来找到记录并把它从PuntTable上删除。Search函数主要是对一系列的条件参数进行查找然后返回一个结果集。索引设计PuntTable定义了一个查询协议，所有的基于条件的查询都是通过这个协议完成的。协议支持四种不同类型的查询，包括相等，大于，小于和包含，可以根据不同的数据类型来进行条件查询。在原始的键-值数据关系上进行查询的代价非常大，因为搜索引擎必须遍历记录中的每一个值。如果数据库中的数据量非常庞大，进行这种搜索所耗费的时间是难以接受的。为了克服这个难点，PuntTable提供了PuntIndex模块来辅助查询过程。PuntIndex可以给多个属性增加索引。如此，搜索这些属性的时候就会消耗较少的资源，而且只需较少时间。存储层设计为了能根据应用需求灵活的选择存储方式，PuntTable的存储层针对不同的应用环境，提供了四种不同的存储模型。上文中已经提到，PuntTable是一个可扩展的分布式的键-值存储系统，而并不仅仅只限于本文所描述的部分。本文中我们只着重于单一节点的数据和索引存储方式的选择。图5展示了PuntTable的节点结构，节点中的存储层被分为两部分。其中一部分是PuntTable，用来控制读写并在缓存中存储数据。另外一部分是PuntIndex，用来处理和存储索引。
2.2多重索引和多重存储策略的设计
PuntTable提供了数据存储接口和索引存储接口来分别支持数据和索引的存储。接口根据对数据和索引操作进行初始化。我们将对二者的操作定义为数据存储接口和索引接口，接口通过所有的数据和索引来实现。我们称这种实现方式为存储适配器。我们通过表1列举了部分操作函数。存储层通过多种不同的方式来实现数据和索引的存储接口。本文中我们主要介绍关系型数据库和NoSQL两种方式，我们的目标是分别找出对应每种不同存储需求的最佳存储方法。
3实验测评
PuntTable目前已经成功部署在中国科技史图书馆(DLHSTC)上，因此我们选取DLHSTC中的数据作为测评数据，分别测试在PuntTable上使用PuntDB和MySQL做存储引擎的各项性能。PuntDB是一个针对数字图书馆应用优化的NoSQL文档数据库。为了描述简便，以下直接用PuntDB和MySQL代指使用PuntDB和MySQL作为存储引擎的PuntTable。经过对实际工作负载的分析，我们发现线上系统中很大比例的操作时对非结构化数据的简单操作。首先，我们测试和比较了PuntTable在PuntDB和MySQL上管理大量元数据时的效果。被测试的数据是约100万条左右从DLHSTC中得到的元数据。每一个记录有约10个属性。测试的内容包括倒入，建立索引和查询，所用的测试数据全部为非结构化的数据。不同的元数据可能会包含不同的属性。这种情况在实际数据中是非常常见的，因为在DLHSTC中所记录的数据往往是一些历史资料，DLHSTC的作用正是用来完整的保存这些数据资料。因此，这样从真实历史资料中所得到的元数据具有很高的多样性，使得实验更具有参考价值。图6显示了测试的结果。图6中显示了向MySQL和PuntDB中写入数据时，所用消耗的时间的差异。MySQL的倒入时间呈快速线性增长。PuntDB的倒入时间也呈线性增长，但是增长的幅度没有MySQL的大。造成这种现象的主要原因是PuntDB没有固定的表关系，所以系统资源的耗费要相对少些。MySQL则需要维护庞大的表关系，而这会浪费极多的系统资源和存储空间。很多事务型的操作对于PuntTable来说并不是必须的，所以PuntDB在倒入数据的时候并不需要做这些操作。图6元数据导入测试之后我们将在属性上建立B+树。图6分别显示了建立索引，利用索引进行查询，和不利用索引进行查询所需要的时间。使用PuntDB和MySQL数据库建立索引所需要的时间均随着数据量的增长呈线性增长。显然，在数据量相等的情况下，MySQL所花费的时间要比PuntDB多的多。在有索引辅助的前提下进行查询时，两种数据库所需要的时间都大幅度减少，并且从结果来看，PuntDB仍然要优于MySQL。下一步，我们进行了PuntTable来处理大规模文本数据集的测试，测试的数据集是一个从DLHSTC中获得的超过10Gb的文本数据。我们将MyISAM配置为MySQL的数据引擎，使得数据库能更好的支持文本数据。文本内容被存在Text类型的列中。图8显示了导入不同大小的文本数据所需要的时间。对于相同大小的数据，PuntDB使用PuntTable所花费的时间要比使用MySQL少。并且，当数据量增大时，PuntDB所用时间增长速度要比MySQL慢。由此我们可以得到结果，PuntDB比MySQL更适合用于对大规模文本数据进行处理。之前的测试主要针对测试工作负载中的不同数据类型对系统性能的影响，在接下来的实验中，我们将着重考虑工作负载中不同种类的数据操作会对系统性能带来的影响。我们用简单操作（ADD，GET，DEL）对从DLHSTC中选出的五种不同类型的非结构化数据集进行简单操作测试。五类数据的统计信息见表2。我们通过计算系统在不同数据集上执行每条操作所花费的平均时间来对系统性能进行评估。数据的存储和读取在DLHSTC的数据负载中是十分常见的。我们在PuntTable上进行Add，Get，Del等常用操作，分别记录PuntTable在MySQL和PuntDB上执行这些操作所花费的时间。如图9所示，试验的结果用执行每条操作花费的时间来表示。从图上我们可以看出，所有的结果都显示存储层为MySQL的时候所花费的时间要比存储层为PuntDB的情况下长。也就是说，PuntDB在非结构化数据集上进行简单操作时要比MySQL更为高效。综上所述，PuntDB存储方式和MySQL相比，可以更高效的对数据进行操作。这个结果也揭示了，在数据仓库的应用中，PuntDB存储方式要优于MySQL这种传统关系数据库的存储方式。只要对数据仓库的操作大多是非事务管理性质的，这种优势就会一直存在，因为一般情况下数据仓库应用中大多数操作都是读操作，写操作只占很少一部分。对于数据仓库，数据通常都是大批量加载进数据库，并且一般不会去修改它们。在这种前提下，键-值存储方式就变得十分有利且有效。然而，如果对于一个需要频繁进行更新和写入的数据库来说，MySQL类型的存储模式就变得更适用。索引和查询的性能在很大程度上取决于建立索引时候使用的算法。MySQL一般会建立B+树和完整的文本查找索引。在PuntTable的索引中我们也使用了这种机制。但是对于PuntDB存储，我们同时也需要实现另一种不同的索引适配器。实验结果已经表明，两种存储方式对于生成B+树索引的时间基本是相同的。然而，MySQL在生成倒排索引的时候比PuntDB存储效率要高，这很可能与PuntDB生成倒排索引所时使用的算法有关。在选择索引的存储方式时，应当同时考虑索引的算法和数据存储本身的一些性质，比如数据类型，吞吐量，延迟等等。对于索引的存储，目前暂时没有一种通用的标准来断定哪种存储方式更加有效。
4总结
研究NoSQL数据库能为数据仓库的发展带来很大益处。和传统关系数据库相比，非关系型数据库采用的数据模型更接近真实的数据并且数据的表现形式也更加灵活。现在，新生的数据往往是非结构化的。关系数据库在近几十年里一直扮演着重要角色，对于ACID模式操作的RDBMS存储方式对很多人来说无疑是最好的选择。然而，随着新技术新需求的产生，新种类的数据库以其灵活的应用方式，已经在很多RDBMS表现不足或不佳的领域逐渐发挥作用。所以，将这两者结合应用也许是更好的选择。在PuntTable中，我们部署了很多种不同的配置环境用以将关系数据库和非关系数据库结合使用。目前来看，PuntTable的存储层还只能以手动进行配置。如果能将其改为自动配置并且自动选择不同存储结构以适应不同种类的任务，将会更有效的提高系统的效率。系统在未来可以通过实现分布式环境来进行扩展。每一种存储节点可以被配置成适用于不同数据集的存储方寝室管理论文式，且工作负载可以通过上层数据分析进行分类并分配给最适合它的数据节点。
作者：兰超 张勇 邢春晓 单位：清华大学信息技术研究院 信息科学与技术国家实验室
