一种数据的存储方法和设备的制作方法【专利摘要】本申请公开了一种数据的存储方法和设备，该方法包括：业务管理设备获得待存储数据；所述业务管理设备确定所述待存储数据的类型；当所述待存储数据的类型为主体数据时，所述业务管理设备在主体数据区域内存储所述待存储数据；和/或当所述待存储数据的类型为非主体数据时，所述业务管理设备在非主体数据区域内存储所述待存储数据。本申请实施例中，可以在非关系型数据库中存储数据，并能够方便的对非关系型数据库中存储的数据进行维护和管理。【专利说明】一种数据的存储方法和设备【
技术领域：
】[0001]本申请涉及存储【
技术领域：
】，尤其是涉及一种数据的存储方法和设备。【
背景技术：
】[0002]现有技术中，通常采用关系型数据库(如MySQL数据库)实现对用户事件行为(分为长期一年和短期一月)的数据的操作，如进行记录、删除和查询等。关系型数据库建立在关系模型基础上，借助于集合代数等数学原理和方法来处理关系型数据库中的数据，且各种实体以及实体之间的各种联系均使用关系模型来表示。该关系模型由关系数据结构、关系操作集合、关系完整性约束三部分组成，且关系模型就是指二维表格模型；因此一个关系型数据库就是由二维表及其之间的联系所组成的一个数据组织。[0003]在实现本申请的过程中，发明人发现现有技术中至少存在以下问题:[0004]由于关系型数据库具有固定的表结构，因此其扩展性极差。例如，在SNS(S0CialNetworkSites,社交网站)中，当系统升级或功能增加时,数据结构的改动很大,从而对关系型数据库的改动也很大，对关系型数据库中内容的添加和删除比较困难，不利于关系型数据库的维护和管理。【
发明内容】[0005]本申请实施例提供一种数据的存储方法和设备，以在非关系型数据库中存储数据，并能够方便的对非关系型数据库中存储的数据进行维护和管理。[0006]为了达到上述目的，本申请实施例提供一种数据的存储方法，该方法用于在非关系型数据库中存储数据，且所述非关系型数据库中包含有用于存储主体数据的主体数据区域、用于存储非主体数据的非主体数据区域、以及用于提供索引功能的数据索引区域；该方法包括以下步骤:[0007]业务管理设备获得待存储数据；[0008]所述业务管理设备确定所述待存储数据的类型，当所述待存储数据的类型为主体数据时，所述业务管理设备在所述主体数据区域内存储所述待存储数据；和/或当所述待存储数据的类型为非主体数据时，所述业务管理设备在所述非主体数据区域内存储所述待存储数据。[0009]本申请实施例提供一种数据的存储设备，该设备用于在非关系型数据库中存储数据，且所述非关系型数据库中包含有用于存储主体数据的主体数据区域、用于存储非主体数据的非主体数据区域、以及用于提供索引功能的数据索引区域；该设备包括:[0010]获得模块，用于获得待存储数据；[0011]确定模块，用于确定所述待存储数据的类型，所述待存储数据的类型为主体数据或者非主体数据；[0012]存储模块，用于当所述待存储数据的类型为主体数据时，在所述主体数据区域内存储所述待存储数据；和/或当所述待存储数据的类型为非主体数据时，在所述非主体数据区域内存储所述待存储数据。[0013]与现有技术相比，本申请实施例至少具有以下优点:本申请实施例中，通过将非关系型数据库划分为主体数据区域和非主体数据区域，并分别通过主体数据区域存储主体数据或者通过非主体数据区域存储非主体数据，从而合理的利用非关系型数据库来存储数据，并能够方便的对非关系型数据库中存储的数据进行维护和管理。进一步的，通过在非关系型数据库内划分出数据索引区域，并在数据索引区域内记录数据的信息与该数据存储位置信息之间的对应关系，从而可以方便的通过数据的信息查询到该数据的存储位置信息，继而可以得到该数据的相关内容，并进一步可以利用这些内容对用户的行为和习惯进行分析，从而为用户提供更好更优质的服务，以提高服务质量。【专利附图】【附图说明】[0014]为了更清楚地说明本申请的技术方案，下面将对实施例描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。[0015]图1是本申请实施例一中非结构化数据存储模型的示意图；[0016]图2是本申请实施例一提供的一种数据的存储方法流程示意图；[0017]图3是本申请实施例一中UDC(卖家档案)在实际中运用本申请实施例提供的非结构化数据存储模型时的结构示意图；[0018]图4是本申请实施例二提供的一种数据的存储设备结构示意图。【具体实施方式】[0019]下面将结合本申请中的附图，对本申请中的技术方案进行清楚、完整地描述，显然，所描述的实施例仅仅是本申请的一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。[0020]实施例一[0021]本申请实施例一提供一种数据的存储方法，该方法用于在非关系型数据库中存储数据，该非关系型数据库包括但不限于:HBase、Cassandra、MongoDB等数据库；其中，HBase是一个高可靠性、高性能、面向列、可伸缩的分布式存储系统，利用HBase技术可在Server(服务器)上搭建起大规模结构化存储集群，且HBase具有存储列的高扩展性；Cassandra是一个混合型的非关系的数据库，其是由一堆数据库节点共同构成的分布式网络服务，对Cassandra的写操作会被复制到其他节点上,对Cassandra的读操作也会被路由到某个节点上去读取；MongoDB是一个基于分布式文件存储的数据库，由C++语言编写，旨在为WEB应用提供可扩展的高性能数据存储解决方案。[0022]针对待存储数据，需要一个能够方便对非关系型数据库中存储的数据进行维护和管理的数据存储模型，为此本申请实施例中选取了非结构化数据存储模型，如图1所示的非结构化数据存储模型的示意图。[0023]基于图1所示的非结构化数据存储模型，该非关系型数据库中包含有用于存储主体数据的主体数据区域、用于存储非主体数据的非主体数据区域、以及用于提供索引功能的数据索引区域。[0024](I)主体数据区域。[0025]本申请实施例中，该主体数据区域内包含有用于存储属性数据的第一数据区域、用于存储在预设第一时间内需要维护的数据的第二数据区域、以及用于存储在预设第二时间内需要维护的数据的第三数据区域；其中，该预设第一时间大于该预设第二时间；且该预设第一时间为一个长期的时间(如10年)，该预设第二时间为一个短期的时间(如I个月)。[0026]该属性数据为用户属性信息，其在时间上是无状态的，在逻辑上为用户的某个属性；对用户来说，属性数据通常一直都有效，且不需要关心属性数据的变化趋势；例如，属性数据可以为用户的生日、身份证等信息。[0027]所述在预设第一时间内需要维护的数据为需要长期存储的数据(为方便描述，将其称为长期历史数据)，长期历史数据是用户的属性信息和/或业务信息；从业务上考虑，如果丢失了一部分永久历史数据，则数据将不完整；例如，长期历史数据可以为处罚数据，即用户可能在某个时间被处罚过，这些处罚数据对用户的作用是长期的，其反映了用户被处罚的行为，因此其可以为长期历史数据；又例如，长期历史数据可以为用户的身份证信息，该身份证信息对用户的作用是长期的，一般不会发生变化，因此其可以为长期历史数据。[0028]所述在预设第二时间内需要维护的数据为需要短期存储的数据(为方便描述，将其称为短期历史数据)。短期历史数据是用户的属性信息和/或业务信息，且短期历史数据只需要保存预设第二时间，在存储时间到达预设第二时间后需要删除；对于用户来说，短期历史数据只在短期内有效，且在有效时间以外的数据允许丢失和忽略；例如，短期历史数据可以为支付宝成交额，即只考虑预设第二时间内的支付宝成交额所反应的支付宝成交趋势，不在考虑预设第二时间外的支付宝成交额所反应的支付宝成交趋势。[0029](2)非主体数据区域。[0030]本申请实施例中，对于主体数据区域内记录数据的业务扩展，在非主体数据区域内可以记录非主体数据(其为主体数据的附属数据)。例如，在实际应用中，该非主体数据可以为具有卖家备注功能的备注信息。[0031](3)数据索引区域。[0032]本申请实施例中，针对指定类型数据，需要记录该数据的信息与该数据的存储位置信息之间的对应关系；为此在非关系型数据库中划分了数据索引区域，以记录指定类型数据的信息与该数据的存储位置信息之间的对应关系。[0033]基于上述非结构化数据存储模型，如图2所示，该方法包括以下步骤:[0034]步骤201，业务管理设备获得待存储数据。[0035]步骤202，业务管理设备确定待存储数据的类型；其中，该待存储数据的类型为主体数据和/或非主体数据。[0036]本申请实施例中，在获得待存储数据之后，业务管理设备可以直接确定该待存储数据的类型；当待存储数据的类型为主体数据时，则执行步骤203;当待存储数据的类型为非主体数据时，则执行步骤204。[0037]步骤203，业务管理设备在主体数据区域内存储待存储数据。[0038]本申请实施例的一种优选实施方式中，由于主体数据区域进一步包含有用于存储属性数据的第一数据区域、用于存储在预设第一时间内需要维护的数据的第二数据区域、以及用于存储在预设第二时间内需要维护的数据的第三数据区域；且主体数据具体为:属性数据，或者在预设第一时间内需要维护的数据，或者在预设第二时间内需要维护的数据，或者同时为属性数据和在预设第一时间内需要维护的数据，或者同时为属性数据和在预设第二时间内需要维护的数据。[0039]因此，业务管理设备在主体数据区域内存储待存储数据的过程进一步包括:当主体数据为属性数据时，业务管理设备在第一数据区域内存储待存储数据；或者，当主体数据为在预设第一时间内需要维护的数据时，业务管理设备在第二数据区域内存储待存储数据；或者，当主体数据为在预设第二时间内需要维护的数据时，业务管理设备在第三数据区域内存储待存储数据；或者，当主体数据同时为属性数据和在预设第一时间内需要维护的数据时，业务管理设备在第一数据区域和第二数据区域内分别存储待存储数据；或者，当主体数据同时为属性数据和在预设第二时间内需要维护的数据时，业务管理设备在第一数据区域和第三数据区域内分别存储待存储数据。[0040]本申请实施例中，业务管理设备在第三数据区域内存储待存储数据之后，当该待存储数据在第三数据区域内存储的时间到达第二时间之后，该业务管理设备还需要在第三数据区域内删除该待存储数据。[0041]步骤204，业务管理设备在非主体数据区域内存储待存储数据。[0042]本申请实施例中，基于上述步骤203或者步骤204的存储结果，在获得待存储数据之后，该方法还可以包括以下步骤:[0043]步骤205，业务管理设备判断待存储数据是否为需要建立索引的数据；如果是，则执行步骤206;如果否，则结束流程。[0044]本申请实施例中，在非关系型数据库中划分了数据索引区域，且针对指定类型数据，需要记录该数据的信息与该数据的存储位置信息之间的对应关系；因此，当待存储数据为指定类型数据时，则确定待存储数据为需要建立索引的数据；否则，确定待存储数据不是需要建立索引的数据。[0045]例如，指定类型数据(可以根据实际需要进行指定，且可以指定多种类型的数据)为支付宝成交额时，当待存储数据为支付宝成交额3000时，则确定待存储数据为需要建立索引的数据；当待存储数据不是支付宝成交额时，则确定待存储数据不是需要建立索引的数据。[0046]步骤206，业务管理设备在数据索引区域内记录待存储数据的信息与存储该待存储数据的位置信息之间的对应关系。[0047]例如，当待存储数据为支付宝成交额3000，且步骤203中将待存储数据存储到主体数据区域内的第三数据区域时，则业务管理设备需要在数据索引区域内记录支付宝成交额3000与第三数据区域内的位置A(即存储支付宝成交额3000的位置)之间的对应关系。[0048]本申请实施例中，业务管理设备在第三数据区域内删除待存储数据之后，如果业务管理设备在数据索引区域内记录了该待存储数据的信息与存储该待存储数据的位置信息之间的对应关系，则该业务管理设备还需要在数据索引区域内删除该对应关系。[0049]本申请实施例中，业务管理设备在数据索引区域内记录待存储数据的信息与存储该待存储数据的位置信息之间的对应关系之后，当业务管理设备接收到携带该待存储数据的信息的查询请求消息时，该业务管理设备利用待存储数据的信息以及数据索引区域内记录的对应关系获得存储该待存储数据的位置信息，并获得该位置信息对应位置所记录的数据。[0050]例如，业务管理设备在数据索引区域内记录了支付宝成交额3000与第三数据区域内的位置A之间的对应关系之后，如果收到携带支付宝成交额3000的查询请求消息，则该业务管理设备利用支付宝成交额3000查询数据索引区域内记录的对应关系，获得第三数据区域内的位置A，继而可以获得第三数据区域内的位置A所记录的数据。[0051]需要注意的是，在收到携带支付宝成交额3000的查询请求消息，业务管理设备利用支付宝成交额3000查询数据索引区域内记录的对应关系时，不仅能够获得第三数据区域内的位置A，还能够获得其他支付宝成交额3000所对应的位置信息，继而获得所有支付宝成交额3000所对应的位置信息，并获得所有的位置信息对应位置所记录的数据，继而可以在非关系型数据库内查询到所有与支付宝成交额3000相关的内容，并进一步利用这些查找到的内容对用户的行为和习惯进行分析，从而为用户提供更好的服务，以提高处理效率和服务质量。[0052]为了更加清楚的阐述本申请的上述实施例，以下结合图3所示的具体应用场景进行详细说明，图3所示为非结构化数据存储模型。[0053]本应用场景下，在主体数据区域(selltable)内，主体数据区域的行key是数字类型唯一ID;且主体数据区域分为三个列簇(非关系型数据库在水平方向上的一组列的集合):S_baSe(即第一数据区域)、s_perm(即第二数据区域)dPS_year(即第三数据区域)；其中:[0054](I)s_base,用于记录属性数据,实现key-value的存储；如表1所示,rowKey为数字类型唯一ID，icn是身份证号码存储的列名。[0055]表1[0056]用户:test01rowKey:134201~s—base:1cn=>324442198401030015用户:test02rowKey:134202s—base:1cn=>428695198012251862[0057](2)s_perm，用于记录在预设第一时间内需要维护的数据，即长期历史数据，其列名的命名方式使用前缀+时间，且可以横向扩展；如表2所示，rowKey为数字类型唯一ID，punis是处罚历史数据的列名前缀。[0058]表2[0059]用户:testOIrowKey:134201s_perm:punis201106281136142=>ruleld:9....s_perm:punis201001082024012=>ruleld:11....用户:test02rowKey:134202s_perm:punis201006111259523=>ruleld:11....[0060](3)s_year，用于记录在预设第二时间内需要维护的数据，即短期历史数据，短期历史数据列名的设置与长期历史数据列名的设置相同，即短期历史数据列名的命名方式使用前缀+时间，并可以横向扩展；如表3所示，rowKey为数字类型唯一ID，sv是销售额数据的列名前缀。[0061]表3[0062]【权利要求】1.一种数据的存储方法，其特征在于，该方法用于在非关系型数据库中存储数据，且所述非关系型数据库中包含有用于存储主体数据的主体数据区域、用于存储非主体数据的非主体数据区域、以及用于提供索引功能的数据索引区域；该方法包括以下步骤:业务管理设备获得待存储数据；所述业务管理设备确定所述待存储数据的类型，当所述待存储数据的类型为主体数据时，所述业务管理设备在所述主体数据区域内存储所述待存储数据；和/或当所述待存储数据的类型为非主体数据时，所述业务管理设备在所述非主体数据区域内存储所述待存储数据。2.如权利要求1所述的方法，其特征在于，还包括:所述业务管理设备判断所述待存储数据是否为需要建立索引的数据；如果是，则所述业务管理设备在所述数据索引区域内记录所述待存储数据的信息与存储所述待存储数据的位置信息之间的对应关系。3.如权利要求1所述的方法，其特征在于，所述主体数据区域内包含有用于存储属性数据的第一数据区域、用于存储在预设第一时间内需要维护的数据的第二数据区域、以及用于存储在预设第二时间内需要维护的数据的第三数据区域，且所述第一时间大于所述第二时间。4.如权利要求3所述的方法，其特征在于，所述主体数据具体为:属性数据，或者在预设第一时间内需要维护的数据，或者在预设第二时间内需要维护的数据，或者同时为属性数据和在预设第一时间内需要维护的数据，或者同时为属性数据和在预设第二时间内需要维护的数据；所述业务管理设备在所述主体数据区域内存储所述待存储数据的过程，进一步包括:当所述主体数据为属性数据时，所述业务管理设备在所述第一数据区域内存储所述待存储数据；或者，当所述主体数据为在预设第一时间内需要维护的数据时，所述业务管理设备在所述第二数据区域内存储所述待存储数据；或者，当所述主体数据为在预设第二时间内需要维护的数据时，所述业务管理设备在所述第三数据区域内存储所述待存储数据；或者，当所述主体数据同时为属性数据和在预设第一时间内需要维护的数据时，所述业务管理设备在所述第一数据区域和第二数据区域内分别存储所述待存储数据；或者，当所述主体数据同时为属性数据和在预设第二时间内需要维护的数据时，所述业务管理设备在所述第一数据区域和第三数据区域内分别存储所述待存储数据。5.如权利要求4所述的方法，其特征在于，所述业务管理设备在所述第三数据区域内存储所述待存储数据，之后还包括:当所述待存储数据在所述第三数据区域内存储的时间到达所述第二时间之后，所述业务管理设备在所述第三数据区域内删除所述待存储数据。6.如权利要求5所述的方法，其特征在于，所述业务管理设备在所述第三数据区域内删除所述待存储数据，之后还包括:如果所述业务管理设备在所述数据索引区域内记录了所述待存储数据的信息与存储所述待存储数据的位置信息之间的对应关系，则所述业务管理设备在所述数据索引区域内删除该对应关系。7.如权利要求2所述的方法，其特征在于，所述业务管理设备在所述数据索引区域内记录所述待存储数据的信息与存储所述待存储数据的位置信息之间的对应关系，之后还包括:当所述业务管理设备接收到携带所述待存储数据的信息的查询请求消息时，所述业务管理设备利用所述待存储数据的信息以及所述数据索引区域内记录的对应关系获得存储所述待存储数据的位置信息，并获得该位置信息对应位置所记录的数据。8.一种数据的存储设备，其特征在于，该设备用于在非关系型数据库中存储数据，且所述非关系型数据库中包含有用于存储主体数据的主体数据区域、用于存储非主体数据的非主体数据区域、以及用于提供索引功能的数据索引区域；该设备包括:获得模块，用于获得待存储数据；确定模块，用于确定所述待存储数据的类型，所述待存储数据的类型为主体数据或者非主体数据；存储模块，用于当所述待存储数据的类型为主体数据时，在所述主体数据区域内存储所述待存储数据；和/或当所述待存储数据的类型为非主体数据时，在所述非主体数据区域内存储所述待存储数据。9.如权利要求8所述的设备，其特征在于，还包括:判断模块，用于判断所述待存储数据是否为需要建立索引的数据；记录模块，用于在判断结果为是时，在所述数据索引区域内记录所述待存储数据的信息与存储所述待存储数据的位置信息之间的对应关系。10.如权利要求9所述的设备，其特征在于，所述主体数据区域内包含有用于存储属性数据的第一数据区域、用于存储在预设第一时间内需要维护的数据的第二数据区域、以及用于存储在预设第二时间内需要维护的数据的第三数据区域，且所述第一时间大于所述第二时间。【文档编号】G06F17/30GK103544157SQ201210238442【公开日】2014年1月29日申请日期:2012年7月11日优先权日:2012年7月11日【发明者】张俊,毛世杰,李令龙申请人:阿里巴巴集团控股有限公司