1.本发明涉及数据处理领域，尤其涉及一种在非关系型数据库中能够关联管理文档间关联关系的方法及系统。
背景技术：
：：2.在使用nosql数据库之前，我们都使用关系型数据库来存储数据，对于父子文档数据之间通过建立主外键关系形成联系，但随着业务使用年限的增加，数据量增长到一定量时，业务使用体验就会下降，主要体现在查询速度耗时较长，伴随着nosql数据库的发布，其优秀的性能吸引了大量开发者的目光，由于nosql本身是一个非结构化的数据库，所以不像关系型数据库一样，文档数据之间是不能建立关系的，因此无法直接实现父子文档的功能，只能简单的将父子文档的主键信息记录到各自的文档，再通过各自的文档去关联，但是这种方式带来的弊端是查询时导致的总文档数不正确的问题。技术实现要素：3.因此，需要提供一种能够进行对数据的生成及后续的变化进行监控的方法，能够满足对于网络传输的数据进行溯源需求。4.为实现上述目的，发明人提供了一种非关系型数据库的父子文档关联方法，包括如下步骤，5.从关系型数据库收集、打包第一数据集，所述第一数据集包括其中的文档间的父子文档关系，将所述的第一数据集根据内容分解为，一个第一记录模块，若干第二记录模块，将所有第二记录模块的元数据信息保存至第一记录模块中，对第一记录模块增加一个父级标识，所述第一记录模块、第二记录模块存储到非关系型数据库中。6.具体地，还包括步骤，对第二记录模块增加一个子级标识。7.具体地，对非关系型数据库进行检索时，仅显示具备父文档标识的查询结果。8.具体地，对所述第一数据及根据内容分解为可分的最小单位，作为记录模块。9.具体地，所述元数据信息包括：索引信息或业务关键词信息。10.一种非关系型数据库的父子文档关联系统，包括：11.收集打包单元，用于从关系型数据库收集、打包第一数据集，所述第一数据集包括其中的文档间的父子文档关系，12.分解单元，用于将所述的第一数据集根据内容分解为，一个第一记录模块，若干第二记录模块，13.存储单元，用于将所有第二记录模块的元数据信息保存至第一记录模块中，对第一记录模块增加一个父级标识，所述第一记录模块、第二记录模块存储到非关系型数据库中。14.具体地，所述存储单元还用于对第二记录模块增加一个子级标识。15.具体地，对非关系型数据库进行检索时，仅显示具备父文档标识的查询结果。16.具体地，对所述第一数据及根据内容分解为可分的最小单位，作为记录模块。17.具体地，所述元数据信息包括：索引信息或业务关键词信息。18.通过上述方案，能够在整理关系型数据库的数据的时候，将关系型数据库的内容打包并迁移到非关系型数据库中，同时保留相关的关联关系，并通过元数据存储的方式方便在非关系型数据库中的查找操作。19.上述
发明内容相关记载仅是本技术技术方案的概述，为了让本领域普通技术人员能够更清楚地了解本技术的技术方案，进而可以依据说明书的文字及附图记载的内容予以实施，并且为了让本技术的上述目的及其它目的、特征和优点能够更易于理解，以下结合本技术的具体实施方式及附图进行说明。附图说明20.附图仅用于示出本技术具体实施方式以及其他相关内容的原理、实现方式、应用、特点以及效果等，并不能认为是对本技术的限制。21.图1为具体实施方式所述的非关系型数据库的父子文档关联方法流程图；22.图2为具体实施方式所述的关联关系展示流程图；23.图3为具体实施方式所述的父子文档关联方法流程图；24.图4为具体实施方式所述的非关系型数据库的父子文档关联系统图；25.图5为具体实施方式所述的存储单元示意图。具体实施方式26.为详细说明技术方案的技术内容、构造特征、所实现目的及效果，以下结合具体实施例并配合附图详予说明。27.在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本技术的至少一个实施例中。在说明书中各个位置出现的“实施例”一词并不一定指代相同的实施例，亦不特别限定其与其它实施例之间的独立性或关联性。原则上，在本技术中，只要不存在技术矛盾或冲突，各实施例中所提到的各项技术特征均可以以任意方式进行组合，以形成相应的可实施的技术方案。28.除非另有定义，本文所使用的技术术语的含义与本技术所属
技术领域：
：的技术人员通常理解的含义相同；本文中对相关术语的使用只是为了描述具体的实施例，而不是旨在限制本技术。29.在本技术的描述中，用语“和/或”是一种用于描述对象之间逻辑关系的表述，表示可以存在三种关系，例如a和/或b，表示：存在a，存在b，以及同时存在a和b这三种情况。另外，本文中字符“/”一般表示前后关联对象是一种“或”的逻辑关系。30.在本技术中，诸如“第一”和“第二”之类的用语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何实际的数量、主次或顺序等关系。31.在没有更多限制的情况下，在本技术中，语句中所使用的“包括”、“包含”、“具有”或者其他类似的表述，意在涵盖非排他性的包含，这些表述并不排除在包括所述要素的过程、方法或者产品中还可以存在另外的要素，从而使得包括一系列要素的过程、方法或者产品中不仅可以包括那些限定的要素，而且还可以包括没有明确列出的其他要素，或者还包括为这种过程、方法或者产品所固有的要素。32.与《审查指南》中的理解相同，在本技术中，“大于”、“小于”、“超过”等表述理解为不包括本数；“以上”、“以下”、“以内”等表述理解为包括本数。此外，在本技术实施例的描述中“多个”的含义是两个以上(包括两个)，与之类似的与“多”相关的表述亦做此类理解，例如“多组”、“多次”等，除非另有明确具体的限定。33.在本技术实施例的描述中，所使用的与空间相关的表述，诸如“中心”“纵向”“横向”“长度”“宽度”“厚度”“上”“下”“前”“后”“左”“右”“竖直”“水平”“垂直”“顶”“底”“内”“外”“顺时针”“逆时针”“轴向”“径向”“周向”等，所指示的方位或位置关系是基于具体实施例或附图所示的方位或位置关系，仅是为了便于描述本技术的具体实施例或便于读者理解，而不是指示或暗示所指的装置或部件必须具有特定的位置、特定的方位、或以特定的方位构造或操作，因此不能理解为对本技术实施例的限制。34.除非另有明确的规定或限定，在本技术实施例的描述中，所使用的“安装”“相连”“连接”“固定”“设置”等用语应做广义理解。例如，所述“连接”可以是固定连接，也可以是可拆卸连接，或成一体设置；其可以是机械连接，也可以是电连接，也可以是通信连接；其可以是直接相连，也可以通过中间媒介间接相连；其可以是两个元件内部的连通或两个元件的相互作用关系。对于本技术所属
技术领域：
：的技术人员而言，可以根据具体情况理解上述用语在本技术实施例中的具体含义。35.nosql，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的sns类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。nosql数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。难以克服的问题，例如：36.1、highperformance-对数据库高并发读写的需求37.web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次sql查询还勉强顶得住，但是应付上万次sql写数据请求，硬盘io就已经无法承受了。其实对于普通的bbs网站，往往也存在对高并发写请求的需求。38.2、hugestorage-对海量数据的高效率存储和访问的需求39.对于大型的sns网站，每天用户产生海量的用户动态，以国外的friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行sql查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，40.3、highscalability&&highavailability-对数据库的高可扩展性和高可用性的需求41.在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像webserver和appserver那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？42.在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：43.1、数据库事务一致性需求44.很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。45.2、数据库的写实时性和读实时性需求46.对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的。并不要求这么高的实时性。47.3、对复杂的sql查询，特别是多表关联查询的需求48.任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂sql报表查询，特别是sns类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，sql的功能被极大的弱化了。49.因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。50.nosql是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与acid理论大一统的局面。nosql数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。51.当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而nosql存储就是为了实现这个需求。google的bigtable与amazon的dynamo是非常成功的商业nosql实现。一些开源的nosql体系，如facebook的cassandra，apache的hbase，也得到了广泛认同。从这些nosql项目的名字上看不出什么相同之处：hadoop、voldemort、dynomite，还有其它很多。在一些实施例中，申请人开始在业务系统中增加使用nosql数据库并结合关系型数据库一起使用，使用的方式就是将关系型数据库的数据同步到nosql数据库中，并将查询的接口统一调整为从nosql数据库进行查询，一旦关系型数据库数据有变更，则即时将关系型数据库的最新数据同步到nosql数据库。52.在如图1所示的实施例中，为一种非关系型数据库的父子文档关联方法，包括如下步骤，53.s1从关系型数据库收集、打包第一数据集，所述第一数据集包括其中的文档间的父子文档关系，s2将所述的第一数据集根据内容分解为，一个第一记录模块，若干第二记录模块，s3将所有第二记录模块的元数据信息保存至第一记录模块中，s4对第一记录模块增加一个父级标识，所述第一记录模块、第二记录模块存储到非关系型数据库中。54.在具体的实施例中，关系型数据库能够存储文档，且存储第一文档与其子文档，第一文档与其父级文档之间的关系，形成关系树，在数据量大的时候，数据的检索和调用将会变得缓慢。在数据转移时，任意选取第二文档及其相关的所有子级文档并进行打包，得到第一数据集，并记录其中文档间的父子文档关系，则第一数据集能够被迁移至非关系型数据库，并能够被预设的数据分解器根据其内容进行重新分解成最小文档为单元的记录模块。在一些实施例中，第一记录模块对应所述第二文档，第二记录模块对应第二文档的子文档。将第二记录模块中的元数据信息保存至第一记录模块中，并为第一记录模块添加一个父级标识。父级标识能够记录第二文档在关系型数据库中的等级架构，然后存储在非关系型数据库中。通过上述方案，能够在整理关系型数据库的数据的时候，将关系型数据库的内容打包并迁移到非关系型数据库中，同时保留相关的关联关系，并通过元数据存储的方式方便在非关系型数据库中的查找操作。达到了在非关系型数据库中保存文档关联性的技术效果。55.在一些具体的实施例中，所述元数据信息包括：索引信息或业务关键词信息。例如根据特定业务流程产生的数据，已经在关系型数据库中存在，在需要转移的时候可以根据特定业务流程的特点，自定义业务关键词，关键值、关键字等等，定义为元数据信息，这样在进行数据迁移的之后，第二记录模块中的自定义业务关键词、关键值或关键字信息就能够同样记录到第一记录模块中，这样做的好处在于，仅在父级文档中就能够展示所有子级文档相关的信息，在用户进行数据检索的时候，就能够利用元数据信息在父级文档中就能够检索得到相关结果。另一些实施例中，所述元数据信息还可以包括子级文档的索引信息，在如图2所示的实施例中，方案还包括步骤s6,向客户展示第一记录模块，及所属的第二记录模块的层级关系。这样能够在基于父级文档进行检索的时候，就能够完整展示第一记录模块及其对应的第二记录模块的所有信息。克服了在非关系型数据库中无法展示记录模块的层级关系的问题。56.在其他一些具体的实施例中，如图3所示，还包括步骤，s5对第二记录模块增加一个子级标识。对第二记录模块增加子级标识，能够对第二记录模块的原关系属性进行个更好地标识。使得第二记录模块的关系和内容都更加直观。57.另一些具体的实施例中，对非关系型数据库进行检索时，仅显示具备父文档标识的查询结果。这样设置的好处在于，能够更快地提升查询结果的速度，可以在几毫秒内就返回需要的查询结果，更好的满足对业务数据的检索需求。58.其他一些具体的实施例中，还进行步骤，对所述第一数据及根据内容分解为可分的最小单位，作为记录模块。最小单位可以根据业务需求定义，如设定最小的单位包含的基本数据、格式或值，或定义文件格式。通过自定义最小单位，能够更好地进行数据的迁移步骤。59.在如图4所示的实施例中，还将介绍一种非关系型数据库的父子文档关联系统，包括：60.收集打包单元40，用于从关系型数据库收集、打包第一数据集，所述第一数据集包括其中的文档间的父子文档关系，61.分解单元42，用于将所述的第一数据集根据内容分解为，一个第一记录模块，若干第二记录模块，62.存储单元44，用于将所有第二记录模块的元数据信息保存至第一记录模块中，对第一记录模块增加一个父级标识，所述第一记录模块、第二记录模块存储到非关系型数据库中。63.通过上述系统，能够在整理关系型数据库的数据的时候，将关系型数据库的内容打包并迁移到非关系型数据库中，同时保留相关的关联关系，并通过元数据存储的方式方便在非关系型数据库中的查找操作。达到了在非关系型数据库中保存文档关联性的技术效果。64.具体地，请参阅图5，所述存储单元44还用于对第二记录模块增加一个子级标识。65.具体地，对非关系型数据库进行检索时，仅显示具备父文档标识的查询结果。66.具体地，对所述第一数据及根据内容分解为可分的最小单位，作为记录模块。67.具体地，所述元数据信息包括：索引信息或业务关键词信息。68.需要说明的是，尽管在本文中已经对上述各实施例进行了描述，但并非因此限制本发明的专利保护范围。因此，基于本发明的创新理念，对本文所述实施例进行的变更和修改，或利用本发明说明书及附图内容所作的等效结构或等效流程变换，直接或间接地将以上技术方案运用在其他相关的
技术领域：
：，均包括在本发明的专利保护范围之内。当前第1页12当前第1页12
背景技术：
：：2.在使用nosql数据库之前，我们都使用关系型数据库来存储数据，对于父子文档数据之间通过建立主外键关系形成联系，但随着业务使用年限的增加，数据量增长到一定量时，业务使用体验就会下降，主要体现在查询速度耗时较长，伴随着nosql数据库的发布，其优秀的性能吸引了大量开发者的目光，由于nosql本身是一个非结构化的数据库，所以不像关系型数据库一样，文档数据之间是不能建立关系的，因此无法直接实现父子文档的功能，只能简单的将父子文档的主键信息记录到各自的文档，再通过各自的文档去关联，但是这种方式带来的弊端是查询时导致的总文档数不正确的问题。技术实现要素：3.因此，需要提供一种能够进行对数据的生成及后续的变化进行监控的方法，能够满足对于网络传输的数据进行溯源需求。4.为实现上述目的，发明人提供了一种非关系型数据库的父子文档关联方法，包括如下步骤，5.从关系型数据库收集、打包第一数据集，所述第一数据集包括其中的文档间的父子文档关系，将所述的第一数据集根据内容分解为，一个第一记录模块，若干第二记录模块，将所有第二记录模块的元数据信息保存至第一记录模块中，对第一记录模块增加一个父级标识，所述第一记录模块、第二记录模块存储到非关系型数据库中。6.具体地，还包括步骤，对第二记录模块增加一个子级标识。7.具体地，对非关系型数据库进行检索时，仅显示具备父文档标识的查询结果。8.具体地，对所述第一数据及根据内容分解为可分的最小单位，作为记录模块。9.具体地，所述元数据信息包括：索引信息或业务关键词信息。10.一种非关系型数据库的父子文档关联系统，包括：11.收集打包单元，用于从关系型数据库收集、打包第一数据集，所述第一数据集包括其中的文档间的父子文档关系，12.分解单元，用于将所述的第一数据集根据内容分解为，一个第一记录模块，若干第二记录模块，13.存储单元，用于将所有第二记录模块的元数据信息保存至第一记录模块中，对第一记录模块增加一个父级标识，所述第一记录模块、第二记录模块存储到非关系型数据库中。14.具体地，所述存储单元还用于对第二记录模块增加一个子级标识。15.具体地，对非关系型数据库进行检索时，仅显示具备父文档标识的查询结果。16.具体地，对所述第一数据及根据内容分解为可分的最小单位，作为记录模块。17.具体地，所述元数据信息包括：索引信息或业务关键词信息。18.通过上述方案，能够在整理关系型数据库的数据的时候，将关系型数据库的内容打包并迁移到非关系型数据库中，同时保留相关的关联关系，并通过元数据存储的方式方便在非关系型数据库中的查找操作。19.上述
发明内容相关记载仅是本技术技术方案的概述，为了让本领域普通技术人员能够更清楚地了解本技术的技术方案，进而可以依据说明书的文字及附图记载的内容予以实施，并且为了让本技术的上述目的及其它目的、特征和优点能够更易于理解，以下结合本技术的具体实施方式及附图进行说明。附图说明20.附图仅用于示出本技术具体实施方式以及其他相关内容的原理、实现方式、应用、特点以及效果等，并不能认为是对本技术的限制。21.图1为具体实施方式所述的非关系型数据库的父子文档关联方法流程图；22.图2为具体实施方式所述的关联关系展示流程图；23.图3为具体实施方式所述的父子文档关联方法流程图；24.图4为具体实施方式所述的非关系型数据库的父子文档关联系统图；25.图5为具体实施方式所述的存储单元示意图。具体实施方式26.为详细说明技术方案的技术内容、构造特征、所实现目的及效果，以下结合具体实施例并配合附图详予说明。27.在本文中提及“实施例”意味着，结合实施例描述的特定特征、结构或特性可以包含在本技术的至少一个实施例中。在说明书中各个位置出现的“实施例”一词并不一定指代相同的实施例，亦不特别限定其与其它实施例之间的独立性或关联性。原则上，在本技术中，只要不存在技术矛盾或冲突，各实施例中所提到的各项技术特征均可以以任意方式进行组合，以形成相应的可实施的技术方案。28.除非另有定义，本文所使用的技术术语的含义与本技术所属
技术领域：
：的技术人员通常理解的含义相同；本文中对相关术语的使用只是为了描述具体的实施例，而不是旨在限制本技术。29.在本技术的描述中，用语“和/或”是一种用于描述对象之间逻辑关系的表述，表示可以存在三种关系，例如a和/或b，表示：存在a，存在b，以及同时存在a和b这三种情况。另外，本文中字符“/”一般表示前后关联对象是一种“或”的逻辑关系。30.在本技术中，诸如“第一”和“第二”之类的用语仅仅用来将一个实体或者操作与另一个实体或操作区分开来，而不一定要求或者暗示这些实体或操作之间存在任何实际的数量、主次或顺序等关系。31.在没有更多限制的情况下，在本技术中，语句中所使用的“包括”、“包含”、“具有”或者其他类似的表述，意在涵盖非排他性的包含，这些表述并不排除在包括所述要素的过程、方法或者产品中还可以存在另外的要素，从而使得包括一系列要素的过程、方法或者产品中不仅可以包括那些限定的要素，而且还可以包括没有明确列出的其他要素，或者还包括为这种过程、方法或者产品所固有的要素。32.与《审查指南》中的理解相同，在本技术中，“大于”、“小于”、“超过”等表述理解为不包括本数；“以上”、“以下”、“以内”等表述理解为包括本数。此外，在本技术实施例的描述中“多个”的含义是两个以上(包括两个)，与之类似的与“多”相关的表述亦做此类理解，例如“多组”、“多次”等，除非另有明确具体的限定。33.在本技术实施例的描述中，所使用的与空间相关的表述，诸如“中心”“纵向”“横向”“长度”“宽度”“厚度”“上”“下”“前”“后”“左”“右”“竖直”“水平”“垂直”“顶”“底”“内”“外”“顺时针”“逆时针”“轴向”“径向”“周向”等，所指示的方位或位置关系是基于具体实施例或附图所示的方位或位置关系，仅是为了便于描述本技术的具体实施例或便于读者理解，而不是指示或暗示所指的装置或部件必须具有特定的位置、特定的方位、或以特定的方位构造或操作，因此不能理解为对本技术实施例的限制。34.除非另有明确的规定或限定，在本技术实施例的描述中，所使用的“安装”“相连”“连接”“固定”“设置”等用语应做广义理解。例如，所述“连接”可以是固定连接，也可以是可拆卸连接，或成一体设置；其可以是机械连接，也可以是电连接，也可以是通信连接；其可以是直接相连，也可以通过中间媒介间接相连；其可以是两个元件内部的连通或两个元件的相互作用关系。对于本技术所属
技术领域：
：的技术人员而言，可以根据具体情况理解上述用语在本技术实施例中的具体含义。35.nosql，泛指非关系型的数据库。随着互联网web2.0网站的兴起，传统的关系数据库在应付web2.0网站，特别是超大规模和高并发的sns类型的web2.0纯动态网站已经显得力不从心，暴露了很多难以克服的问题，而非关系型的数据库则由于其本身的特点得到了非常迅速的发展。nosql数据库的产生就是为了解决大规模数据集合多重数据种类带来的挑战，尤其是大数据应用难题。难以克服的问题，例如：36.1、highperformance-对数据库高并发读写的需求37.web2.0网站要根据用户个性化信息来实时生成动态页面和提供动态信息，所以基本上无法使用动态页面静态化技术，因此数据库并发负载非常高，往往要达到每秒上万次读写请求。关系数据库应付上万次sql查询还勉强顶得住，但是应付上万次sql写数据请求，硬盘io就已经无法承受了。其实对于普通的bbs网站，往往也存在对高并发写请求的需求。38.2、hugestorage-对海量数据的高效率存储和访问的需求39.对于大型的sns网站，每天用户产生海量的用户动态，以国外的friendfeed为例，一个月就达到了2.5亿条用户动态，对于关系数据库来说，在一张2.5亿条记录的表里面进行sql查询，效率是极其低下乃至不可忍受的。再例如大型web网站的用户登录系统，40.3、highscalability&&highavailability-对数据库的高可扩展性和高可用性的需求41.在基于web的架构当中，数据库是最难进行横向扩展的，当一个应用系统的用户量和访问量与日俱增的时候，你的数据库却没有办法像webserver和appserver那样简单的通过添加更多的硬件和服务节点来扩展性能和负载能力。对于很多需要提供24小时不间断服务的网站来说，对数据库系统进行升级和扩展是非常痛苦的事情，往往需要停机维护和数据迁移，为什么数据库不能通过不断的添加服务器节点来实现扩展呢？42.在上面提到的“三高”需求面前，关系数据库遇到了难以克服的障碍，而对于web2.0网站来说，关系数据库的很多主要特性却往往无用武之地，例如：43.1、数据库事务一致性需求44.很多web实时系统并不要求严格的数据库事务，对读一致性的要求很低，有些场合对写一致性要求也不高。因此数据库事务管理成了数据库高负载下一个沉重的负担。45.2、数据库的写实时性和读实时性需求46.对关系数据库来说，插入一条数据之后立刻查询，是肯定可以读出来这条数据的。并不要求这么高的实时性。47.3、对复杂的sql查询，特别是多表关联查询的需求48.任何大数据量的web系统，都非常忌讳多个大表的关联查询，以及复杂的数据分析类型的复杂sql报表查询，特别是sns类型的网站，从需求以及产品设计角度，就避免了这种情况的产生。往往更多的只是单表的主键查询，以及单表的简单条件分页查询，sql的功能被极大的弱化了。49.因此，关系数据库在这些越来越多的应用场景下显得不那么合适了，为了解决这类问题的非关系数据库应运而生。50.nosql是非关系型数据存储的广义定义。它打破了长久以来关系型数据库与acid理论大一统的局面。nosql数据存储不需要固定的表结构，通常也不存在连接操作。在大数据存取上具备关系型数据库无法比拟的性能优势。51.当今的应用体系结构需要数据存储在横向伸缩性上能够满足需求。而nosql存储就是为了实现这个需求。google的bigtable与amazon的dynamo是非常成功的商业nosql实现。一些开源的nosql体系，如facebook的cassandra，apache的hbase，也得到了广泛认同。从这些nosql项目的名字上看不出什么相同之处：hadoop、voldemort、dynomite，还有其它很多。在一些实施例中，申请人开始在业务系统中增加使用nosql数据库并结合关系型数据库一起使用，使用的方式就是将关系型数据库的数据同步到nosql数据库中，并将查询的接口统一调整为从nosql数据库进行查询，一旦关系型数据库数据有变更，则即时将关系型数据库的最新数据同步到nosql数据库。52.在如图1所示的实施例中，为一种非关系型数据库的父子文档关联方法，包括如下步骤，53.s1从关系型数据库收集、打包第一数据集，所述第一数据集包括其中的文档间的父子文档关系，s2将所述的第一数据集根据内容分解为，一个第一记录模块，若干第二记录模块，s3将所有第二记录模块的元数据信息保存至第一记录模块中，s4对第一记录模块增加一个父级标识，所述第一记录模块、第二记录模块存储到非关系型数据库中。54.在具体的实施例中，关系型数据库能够存储文档，且存储第一文档与其子文档，第一文档与其父级文档之间的关系，形成关系树，在数据量大的时候，数据的检索和调用将会变得缓慢。在数据转移时，任意选取第二文档及其相关的所有子级文档并进行打包，得到第一数据集，并记录其中文档间的父子文档关系，则第一数据集能够被迁移至非关系型数据库，并能够被预设的数据分解器根据其内容进行重新分解成最小文档为单元的记录模块。在一些实施例中，第一记录模块对应所述第二文档，第二记录模块对应第二文档的子文档。将第二记录模块中的元数据信息保存至第一记录模块中，并为第一记录模块添加一个父级标识。父级标识能够记录第二文档在关系型数据库中的等级架构，然后存储在非关系型数据库中。通过上述方案，能够在整理关系型数据库的数据的时候，将关系型数据库的内容打包并迁移到非关系型数据库中，同时保留相关的关联关系，并通过元数据存储的方式方便在非关系型数据库中的查找操作。达到了在非关系型数据库中保存文档关联性的技术效果。55.在一些具体的实施例中，所述元数据信息包括：索引信息或业务关键词信息。例如根据特定业务流程产生的数据，已经在关系型数据库中存在，在需要转移的时候可以根据特定业务流程的特点，自定义业务关键词，关键值、关键字等等，定义为元数据信息，这样在进行数据迁移的之后，第二记录模块中的自定义业务关键词、关键值或关键字信息就能够同样记录到第一记录模块中，这样做的好处在于，仅在父级文档中就能够展示所有子级文档相关的信息，在用户进行数据检索的时候，就能够利用元数据信息在父级文档中就能够检索得到相关结果。另一些实施例中，所述元数据信息还可以包括子级文档的索引信息，在如图2所示的实施例中，方案还包括步骤s6,向客户展示第一记录模块，及所属的第二记录模块的层级关系。这样能够在基于父级文档进行检索的时候，就能够完整展示第一记录模块及其对应的第二记录模块的所有信息。克服了在非关系型数据库中无法展示记录模块的层级关系的问题。56.在其他一些具体的实施例中，如图3所示，还包括步骤，s5对第二记录模块增加一个子级标识。对第二记录模块增加子级标识，能够对第二记录模块的原关系属性进行个更好地标识。使得第二记录模块的关系和内容都更加直观。57.另一些具体的实施例中，对非关系型数据库进行检索时，仅显示具备父文档标识的查询结果。这样设置的好处在于，能够更快地提升查询结果的速度，可以在几毫秒内就返回需要的查询结果，更好的满足对业务数据的检索需求。58.其他一些具体的实施例中，还进行步骤，对所述第一数据及根据内容分解为可分的最小单位，作为记录模块。最小单位可以根据业务需求定义，如设定最小的单位包含的基本数据、格式或值，或定义文件格式。通过自定义最小单位，能够更好地进行数据的迁移步骤。59.在如图4所示的实施例中，还将介绍一种非关系型数据库的父子文档关联系统，包括：60.收集打包单元40，用于从关系型数据库收集、打包第一数据集，所述第一数据集包括其中的文档间的父子文档关系，61.分解单元42，用于将所述的第一数据集根据内容分解为，一个第一记录模块，若干第二记录模块，62.存储单元44，用于将所有第二记录模块的元数据信息保存至第一记录模块中，对第一记录模块增加一个父级标识，所述第一记录模块、第二记录模块存储到非关系型数据库中。63.通过上述系统，能够在整理关系型数据库的数据的时候，将关系型数据库的内容打包并迁移到非关系型数据库中，同时保留相关的关联关系，并通过元数据存储的方式方便在非关系型数据库中的查找操作。达到了在非关系型数据库中保存文档关联性的技术效果。64.具体地，请参阅图5，所述存储单元44还用于对第二记录模块增加一个子级标识。65.具体地，对非关系型数据库进行检索时，仅显示具备父文档标识的查询结果。66.具体地，对所述第一数据及根据内容分解为可分的最小单位，作为记录模块。67.具体地，所述元数据信息包括：索引信息或业务关键词信息。68.需要说明的是，尽管在本文中已经对上述各实施例进行了描述，但并非因此限制本发明的专利保护范围。因此，基于本发明的创新理念，对本文所述实施例进行的变更和修改，或利用本发明说明书及附图内容所作的等效结构或等效流程变换，直接或间接地将以上技术方案运用在其他相关的
技术领域：
：，均包括在本发明的专利保护范围之内。当前第1页12当前第1页12
再多了解一些
本文用于企业家、创业者技术爱好者查询，结果仅供参考。
