本发明涉及一种关系型到NoSQL的数据适配方法，属于软件技术领域。
背景技术：
海量数据场景下，传统关系数据库在数据存储和处理上的瓶颈越来越凸显。近年来，分布式NoSQL技术得到了迅速发展。作为关系数据库的补充，NoSQL指代了一大类构建于非关系数据模型之上的数据存储管理系统，如BigTable，HBase和MongoDB等。得益于其水平可扩展能力，灵活的数据模型以及与各种计算框架的紧密连接等优势，越来越多的应用开始采用NoSQL数据库作为其存储层。同时，许多原先构建于关系数据库之上的应用也逐渐向NoSQL数据库迁移(Harezlak K, Skowron R. Performance Aspects of Migrating a Web Application from a Relational to a NoSQL Database. In Proceedings of the International Conference: Beyond Databases, Architectures and Structures, 2015, 107-115)。然而，从关系数据库迁移到NoSQL也伴随着巨大的挑战，主要的难点体现在不同数据模型之间的转换(Schram A, Anderson K M. MySQL to NoSQL: Data Modeling Challenges in Supporting Scalability. In Proceedings of the 3rd Annual Conference on Systems, Programming, and Applications: Software for Humanity, 2012, 191-202)，即如何将关系表映射成NoSQL中基于key-value的存储形式。
具体来讲，数据模型转换的难点与挑战体现在以下几个方面：(1)相比理论与技术成熟的关系数据库，NoSQL缺乏统一的标准，其弱模式或者无模式的结构意味着转换方式的多种多样。(2)NoSQL数据库不支持关系数据库中的索引，高层语言和复杂的查询引擎等机制，在实际场景中，往往需要在应用层面实现。(3)最重要的是建模理念上的差别，关系数据库的应用遵循一种“数据驱动”的思想，能够在查询未知的情况下，通过关系模型和范式理论来刻画现实世界。而NoSQL数据库是一种应用驱动的平台，在基于NoSQL的应用中，数据访问类型是第一要素，数据模型根据查询进行对应性的设计。目前，能够支持数据模型自动化转换的是一种面向数据的方法，仅仅从数据本身进行考虑。适配器采用固定的映射机制将关系表转换为NoSQL的key-value存储方式。
面向数据的方法提供了关系表逻辑视图和类SQL查询语言，实际上是一种“从关系思维到关系思维”的思想，即仍然以关系模型来刻画业务。优势在于简单通用，适用于任何的应用类型，而且能够快速地完成自动化的转换过程。但该方法忽略了不同平台的特点，以下几个方面的不足导致了性能上的缺陷。(1)关系数据库解决方案中创建的索引丢失，导致查询时需要进行全表扫描。(2)NoSQL数据库之上的第三方SQL查询引擎目前的发展还达不到关系数据库中查询引擎的性能优化效果，例如细粒度的代价优化机制缺失等。(3)从通用性考虑，这些查询引擎只是将NoSQL作为文件系统之外的一种可选的数据表存储方式。相对分布式文件系统，NoSQL中许多独有的特点如天然索引、排序等，无法被查询引擎所感知。(4)查询被翻译成特定的计算范型，所以查询性能取决于单一的计算框架。因此，面向数据转换方法并不能满足需求。在实际应用中，往往需要开发人员根据应用的特点编写程序来完成特定的转换。而这个过程涉及到大量繁琐的工作，既要根据关系数据库中的设计分析出实际需求，又要考虑如何在NoSQL数据库中实现这些需求。此外，开发人员对于关系数据库和分布式NoSQL数据库的知识都必须熟知。
技术实现要素：
本发明的原理：提出了查询感知的数据模型转换方法，能够自动完成“从关系思维到NoSQL思维”的转换，相比现有方法更加高效；在企业数据分析应用中，能够实现数据模型自动化地转换；对NoSQL数据库数据建模行为过程的抽象，其概念和技术不局限于具体的应用类型，具有广泛的通用性。。
本发明技术解决方案：一种关系型到NoSQL的数据适配方法，其特点在于实现步骤如下：
第一步，转换前处理：数据在Hive中仍然是关系模型，因此从关系数据库迁移到Hive中是一对一的对应关系。Hive中的基本表对应关系数据库中的基本表，Hive中的中间表对应关系数据库中的物化视图。同时，关系数据库中的存储过程也由HiveQL完成，查询PT和PN与原SQL表达一一对应。这种方式的不足之处和采用适配器机制类似，导致了交互式查询在性能上的下降，需要引入NoSQL来支持交互式的性能需求。
第二步，查询感知转换：转换过程从逻辑上主要包含两个阶段，分别解决“存什么”和“怎么存”的问题。第一阶段通过查询的抽象语法树(AST)分析出数据模型，其本质是对于关系数据库解决方案的逆向工程，解析SQL语句来得到查询中所蕴含的实际需求。第二阶段则是对数据模型的NoSQL数据建模过程，其核心工作在于NoSQL的key-value数据模型中key部分的设计。发明的自动化设计以查询中的相关谓词和关系数据库中创建的索引作为驱动。因此，从技术层面，数据模型支持的是一种查询感知的数据模型转换过程；在思想层面，数据模型体现了“从关系思维到NoSQL思维”的本质。
第三步，转换后处理：从图中可以看出，在转换后的数据模型设计中，基本表存储在HDFS中用来支持新增数据的导入。原先的中间表OS_PRES设计成数据模型，并将数据模型按照特定的形式存储。NoSQL数据模型中，其value部分按照HBase(列存储类型的NoSQL)内部数据结构，设计为“pyc_name:drug_number”，最重要的row-key部分设计为“drug_name+f(pres_time)”，其中drug_name与f(pres_time)通过字符“+”进行字符串连接。根据查询的需求，函数f(pres_time)将pres_time字符串进行了字典升序改成字典降序，如2013-01-01转变为7986-98-98，用9减去每个数字。转换后的查询相应地改变为NoSQL的API形式，例如PT查询，仅仅需要以“penicillin+”作为起始键进行扫描，直到返回5个不同的pyc_name即可；PN查询以“penicillin+f(endTime)”为起始键和“penicillin+f(startTime)”作为结束键进行范围查询，在范围扫描间计算出drug_number最大的前10个pyc_name即可。
本发明与现有技术相比具有如下优点：
l 对数据表存储策略的内在机制进行了深入分析；
l 基于轻量级测试与查询感知的选取方法支持开发人员快速决策；
l 对不同的数据表存储策略进行接口抽象，满足可扩展性的需求。
附图说明
图1为数据适配方法。
具体实施方式
以下结合具体实施例和附图对本发明进行详细说明，如图1所示，本发明实施例方法流程：
迁移之前，各应用的规模等基本信息，表示数据维护时间随着数据量增长而不断增加，查询语句以二元组表示，分别代表交互式查询和报表查询的数目。此外，因为原始TPC-DS数据集中并没有设计生成物化视图，因此其存储空间与维护代价均可以看作是0。案例研究不直接比较关系数据库和NoSQL数据库方案，重点考察应用迁移质量。
(1)评价指标。得益于其天然的可扩展性架构，迁移到NoSQL之后的应用可以通过添加服务器来应对海量增长的数据。因此以应用中数据存储和查询性能来综合评价数据模型转换的质量。
(2)评价标准。参数化查询涉及到用户输入，难以定量地评价，因此除了参考相关的需求文档作为评价标准，在迁移过程中，还与系统维护人员和用户进行交互，来评价查询的性能是否可接受(satisfactory)，并根据应用中可接受的查询比例计算出“满意度”。
在实际项目迁移中，除了来自合作企业中的系统维护人员和开发人员，团队中参与的工程师与开发人员有27人，其中11人对数据库和大数据以及Hadoop生态系统方面具有专业的知识。本节对数据模型转换过程中各种技术的应用情况进行描述。
数据模型在实际迁移中的应用：数据模型在数据分析应用中对应于查询感知的物化视图，通过数据模型重用可以减少存储空间和数据维护的代价。实际迁移工作中，具体的使用情况。在技术层面，数据模型主要用于满足交互式查询的性能需求，因此一个应用中数据模型的数量往往取决于交互式查询的数目，而数据模型的重用情况则和不同查询之间彼此所蕴含的语义相关。
发明在迁移中的应用：一个查询中，可能应用到多个发明的模式。不同应用中发明的应用情况。可以看出，前三种轻量级的发明应用比例很大(80%以上)；Salted键比较特殊，主要用于增量更新时避免数据倾斜带来的写入性能；降维键和Tree键需要用户自定义的相关算法，主要用于数据模型自动化转换后更加深入的优化阶段，因此这几种模式应用不多(例如MICROBLOG中只有一个查询应用到了Tree键，这并不包含在数据模型的自动化转换过程中，而是在迁移到NoSQL之后的调整阶段，对于特定的某种类型的查询，开发人员自定义并实现的树型索引。例如在MICROBLOG中的例子就是用于范围聚合查询的线段树结构)。
数据访问模式：迁移之后，数据访问模式根据数据模型的不同，存在着三种情况：HiveQL(报表查询一对一的方式)，NoSQL自带API(数据模型转换之后的点查询和用户输入范围较小时的范围查询)，MapReduce(用户输入范围较大时的范围查询)。因此，范围查询的数据访问模式是一种混合的方式。不同应用的数据访问模式分布，HBase API与MapReduce的性能，其中大约1250k行数据量可以当作是一个经验的阈值。