一种分布式版本控制系统的数据处理方法、设备及系统的制作方法
【专利摘要】本发明公开了一种分布式版本控制系统的数据处理方法，该方法应用于该系统的Git服务设备，该方法包括：分别与分布式数据库服务设备建立第一链接，与分布式文件存储服务设备建立第二链接；通过第一链接与分布式数据库服务设备进行交互，处理打包文件的存储位置，通过第二链接与分布式文件存储服务设备进行交互，处理打包文件的存储内容；所述打包文件从客户端接收。本发明还公开了一种Git服务设备，及一种分布式版本控制系统。采用本发明能够降低处理成本，提高处理效率。
【专利说明】一种分布式版本控制系统的数据处理方法、设备及系统
【技术领域】
[0001]本发明涉及通信领域中核心网，特别涉及一种分布式版本控制系统的数据处理方法、设备及系统。
【背景技术】
[0002]当我们在使用分布式版本控制系统的时候，底层数据的存储都是直接基于文件系统的目录结构的，一个仓库，对应一个按照自己规定的，私有的固定存放格式来存储管理的内容。对于Git这种分布式版本控制系统，针对大量的数据读写操作，可以通过在Git服务器上使用挂载高转速的磁盘阵列在一定程度上解决数据容量，数据备份，数据完整性及数据高并发访问的问题。这种方式，在单节点服务器的场景中，当Git服务器提供服务的时候，存储单元，即磁盘阵列附属在该服务器上提供存储功能；在多节点服务器的场景中，存储单元作为中心存储服务，通过共享总线或者类似nfs的网络文件系统。
[0003]也就是说，现有技术中通过硬件方式，将多个磁盘组合到一起，挂载在Git服务器上，将Git服务器通过Git客户端接收的打包文件进行存储。但是使用磁盘阵列会导致造价过高，而且针对未来的发展不利于扩展，在服务器节点增加的时候，导致输入和输出(10)争用，数据串行处理，效率低下。
【发明内容】
[0004]本发明的目的在于提供一种分布式版本控制系统的数据处理方法、设备及系统，能够降低处理成本，提高处理效率。
[0005]为实现上述发明目的，本发明提供了一种分布式版本控制系统的数据处理方法，该方法应用于该系统的Git服务设备，该方法包括:
[0006]分别与分布式数据库服务设备建立第一链接，与分布式文件存储服务设备建立第二链接；
[0007]通过第一链接与分布式数据库服务设备进行交互，处理打包文件的存储位置，通过第二链接与分布式文件存储服务设备进行交互，处理打包文件的存储内容；所述打包文件从客户端接收。
[0008]为实现上述发明目的，本发明还提供了一种Git服务设备，所述Git服务设备包括:
[0009]链接建立单元，用于分别与分布式数据库服务设备建立第一链接，与分布式文件存储服务设备建立第二链接；
[0010]处理单元，用于通过第一链接与分布式数据库服务设备进行交互，处理打包文件的存储位置，通过第二链接与分布式文件存储服务设备进行交互，处理打包文件的存储内容；所述打包文件从客户端接收。
[0011]为实现上述发明目的，本发明还提供了一种分布式版本控制系统，该系统包括:
[0012]Git服务设备，用于分别与分布式数据库服务设备建立第一链接，与分布式文件存储服务设备建立第二链接；
[0013]通过第一链接与分布式数据库服务设备进行交互，处理打包文件的存储位置，通过第二链接与分布式文件存储服务设备进行交互，处理打包文件的存储内容；所述打包文件从客户端接收；
[0014]分布式数据库服务设备，用于存储打包文件的存储位置；
[0015]分布式文件存储服务设备，用于存储打包文件的存储内容。
[0016]综上所述，本发明实施例将Git服务设备分别与用于存储小文件的分布式数据库服务设备建立第一链接，与用于存储大文件的分布式文件存储服务设备建立第二链接，通过第一链接读写打包文件的存储位置，通过第二链接读写打包文件的存储内容，将打包文件的存储位置和存储内容分别在两个存储服务设备中处理。与现有技术中读写磁盘，或者磁盘阵列的方式相比，本发明读写的是廉价的存储服务设备，可以在数据量很大时，在做统计，搜索等全局操作时方便地利用多台廉价的商业存储服务器进行大规模的并行运算。
【专利附图】
【附图说明】
[0017]图1为本发明实施例分布式版本控制系统的数据处理方法的流程示意图。
[0018]图2为本发明具体实施例中应用于上述方法的Git服务设备的结构示意图。
【具体实施方式】
[0019]为使本发明的目的、技术方案及优点更加清楚明白，以下参照附图并举实施例，对本发明所述方案作进一步地详细说明。
[0020]本发明的核心思想是:通过在Git服务设备中设置接口，完成与分布式数据库服务设备和分布式文件存储服务设备的交互处理，将打包文件的存储位置和存储内容分别在两个存储服务设备中处理。进一步地，根据实际存储内容特性提供优化处理方案，在打包文件的存储内容大小不超过阈值时，将内容较小的打包文件只在一个存储服务设备中处理，即Git服务设备只需要与分布式数据库服务设备进行交互，处理打包文件的存储位置和存储内容。从而有效提高了资源访问速度和利用率。
[0021]本发明实施例提供了一种分布式版本控制系统的数据处理方法，该方法应用于该系统的Git服务设备，其流程示意图如图1所示，该方法包括:
[0022]步骤11、分别与分布式数据库服务设备建立第一链接，与分布式文件存储服务设备建立第二链接；
[0023]步骤12、通过第一链接与分布式数据库服务设备进行交互，处理打包文件的存储位置，通过第二链接与分布式文件存储服务设备进行交互，处理打包文件的存储内容；所述打包文件从客户端接收。
[0024]这里，当通过第一链接和第二链接的交互为写操作时，通过设置写接口完成交互；当通过第一链接和第二链接的交互为读操作时，通过设置读接口完成交互。
[0025]需要说明的是，分布式数据库服务设备一般用于存储小文件，由多个服务器组成，即分布式数据库服务设备是一个服务器集群；分布式文件存储服务设备一般用于存储大文件，也由多个服务器组成，即分布式文件存储服务设备也是一个服务器集群。分布式数据库服务设备和分布式文件存储服务设备都是一种存储服务设备，常用的分布式数据库服务设备有Hbase，Cassandra等；分布式文件存储服务设备有Jss，HDFS等。为清楚说明本发明，下面分布式数据库服务设备以ffiase为例进行说明，分布式文件存储服务设备以Jss为例进行说明。
[0026]上述方案在实现时，对于从客户端接收的打包文件，不分内容大小，都是将打包文件的存储位置和存储内容分别在两个存储服务设备中处理。也就是说，写入打包文件时，将打包文件在Jss的存储位置写入Hbase，将打包文件的存储内容写入Jss ;读取打包文件时，从Hbase中读取打包文件在Jss的存储位置，从Jss的相应存储位置上读取打包文件的存储内容。
[0027]但是，对于较小的打包文件，可以直接将打包文件的存储内容写入Hbase的相应存储位置中，这样，读取时，可以直接从ffiase的相应存储位置中读取打包文件的存储内容。Git服务器在读写时都不需要与Jss进行交互。所以，优选地，本发明在写操作时，进一步加入对于打包文件存储内容的特性判断，具体方法为:
[0028]对打包文件的存储内容大小进行判断，当存储内容大小不超过阈值时，确定将存储内容存入分布式数据库服务设备，通过第一链接与分布式数据库服务设备进行交互，将打包文件的存储内容写入分布式数据库服务设备的对应存储位置中；
[0029]当存储内容大小超过阈值时，确定将存储内容存入分布式文件存储服务设备，通过第一链接与分布式数据库服务设备进行交互，将打包文件在分布式文件存储服务设备的存储位置写入分布式数据库服务设备中，通过第二链接与分布式文件存储服务设备进行交互，将打包文件的存储内容写入分布式文件存储服务设备的对应存储位置中。
[0030]其中，根据该打包文件所属仓库的仓库名、打包文件对应的类型标识以及打包文件名，生成打包文件在分布式数据库服务设备中的存储位置标识，作为打包文件的存储内容在分布式数据库服务设备中的存储位置；
[0031]根据该打包文件所属仓库的仓库名、打包文件对应的类型标识以及打包文件名，生成打包文件在分布式文件存储服务设备中的存储位置标识，作为打包文件的存储内容在分布式文件存储服务设备中的存储位置。
[0032]进而，在读操作下，读取方法包括:
[0033]根据该打包文件所属仓库的仓库名、打包文件对应的类型标识以及打包文件名，确定该打包文件在分布式数据库服务设备中的存储位置；
[0034]根据分布式数据库服务设备中存储位置上的信息判断该打包文件的存储内容存在分布式数据库服务设备中还是分布式文件存储服务设备中，当存储位置上存储的是该打包文件的内容时，则读取该打包文件的内容；
[0035]当存储位置上存储的是该打包文件写入分布式文件存储服务设备的存储位置时，则根据该打包文件写入分布式文件存储服务设备的存储位置，从分布式文件存储服务设备中读取该打包文件的内容。
[0036]需要说明的是，在进行写操作时，不但可以对打包文件的存储内容大小进行判断，还可以设置一个动态灵活的判断策略，评价该打包文件需要写入哪种存储服务设备，例如对分布式数据库服务设备和分布式文件存储服务设备的状态进行判断，根据各存储服务设备的负载及健康状况，结合打包文件的存储内容大小，来灵活判断打包文件需要写入的存储服务设备。[0037]为清楚说明本发明，下面列举具体场景对本发明的方法进行详细说明，这里仍然以Hbase和Jss为例进行介绍。
[0038]整个写入流程和读取流程如下:
[0039]写入流程:以写接口(write file)为例，首先根据该打包文件所属仓库的仓库名(abc),打包文件对应的类型标识(pack),打包文件名(packl),三者拼在一起得到打包文件packl在Hbase中的存储位置标识:abc:pack:packl ；
[0040]如果经过判断将该打包文件的存储内容存储在Hbase中，则将该打包文件的存储内容写入abc:pack:packl所标识的Hbase存储位置中；
[0041]如果经过判断将该打包文件的存储内容存储在Jss中，则根据abc:pack:packl生成打包文件存储内容在Jss中的存储位置标识:JSS_GIT_ABC_PACK_PACK1_20131217，将JSS_GIT_ABC_PACK_PACK 1_20131217 写入 abc:pack:packl 所标识的 Hbase 存储位置中，将该打包文件的存储内容写入JSS_GIT_ABC_PACK_PACK1_20131217所标识的Jss存储位置中。
[0042]同理，
[0043]读取流程:以读接口(open file)为例，首先根据该打包文件所属仓库的仓库名(abc),打包文件对应的类型标识(pack),打包文件名(packl),三者拼在一起得到打包文件packl在Hbase中的存储位置标识:abc:pack:packl,从而可以找到该打包文件在HBase中的存储位置；
[0044]然后，根据存储位置上的信息得到打包文件的存储内容到底是直接存储在Hbase中，还是存储在Jss中，如果存储在Hbase中，直接读取该打包文件的存储内容；
[0045]如果存储位置上的信息是存储内容在Jss里的对应位置标识:JSS_GIT_ABC_PACK_PACK1_20131217,则，根据 JSS_GIT_ABC_PACK_PACK1_20131217 从 Jss 的相应位置上读取该打包文件的存储内容。
[0046]基于同样的发明构思，本发明还提出一种Git服务设备，参见图2，图2为本发明具体实施例中应用于上述方法的Git服务设备的结构示意图。该Git服务设备包括:
[0047]链接建立单元201，用于分别与分布式数据库服务设备建立第一链接，与分布式文件存储服务设备建立第二链接；
[0048]处理单元202，用于通过第一链接与分布式数据库服务设备进行交互，处理打包文件的存储位置，通过第二链接与分布式文件存储服务设备进行交互，处理打包文件的存储内容；所述打包文件从客户端接收。
[0049]优选地，该Git服务设备进一步包括:
[0050]判断单元203，用于对打包文件的存储内容大小进行判断，根据判断结果对打包文件进行相应的处理。
[0051]本发明还提出一种分布式版本控制系统，该系统包括:
[0052]Git服务设备，用于分别与分布式数据库服务设备建立第一链接，与分布式文件存储服务设备建立第二链接；
[0053]通过第一链接与分布式数据库服务设备进行交互，处理打包文件的存储位置，通过第二链接与分布式文件存储服务设备进行交互，处理打包文件的存储内容；所述打包文件从客户端接收；[0054]分布式数据库服务设备，用于存储打包文件的存储位置；
[0055]分布式文件存储服务设备，用于存储打包文件的存储内容。
[0056]本发明分布式版本控制系统的数据处理方法、设备及系统，会带来如下好处:
[0057]—、整个系统具有良好的可伸缩性，扩展时只需要独立地对各存储服务设备进行扩展，而无需对现有系统进行修改；也就是说，如果需要提升系统的性能，可以通过灵活增加分布式数据库服务设备或分布式文件存储服务设备的服务器集群中服务器的个数，而不需要像现有技术那样增加Git服务设备的磁盘。
[0058]二、由于各存储服务设备由服务器集群构成，所以写入时可以写入服务器集群中不同的服务器，读取时可以从集群中某一服务器进行读取，从而对IO访问进行有效地分流，提高响应速度及负载能力。
[0059]三、进行写操作时，根据实际存储内容等特性进行判断，提高资源访问速度和利用率。
[0060]四、当数据量很大时，在做统计，搜索等全局操作时可以很方便地利用多台廉价的商业存储服务器进行大规模的并行运算。
[0061]以上所述，仅为本发明的较佳实施例而已，并非用于限定本发明的保护范围。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。
【权利要求】
1.一种分布式版本控制系统的数据处理方法，该方法应用于该系统的Git服务设备，该方法包括： 分别与分布式数据库服务设备建立第一链接，与分布式文件存储服务设备建立第二链接; 通过第一链接与分布式数据库服务设备进行交互，处理打包文件的存储位置，通过第二链接与分布式文件存储服务设备进行交互，处理打包文件的存储内容；所述打包文件从客户端接收。
2.如权利要求1所述的方法，其特征在于，当通过第一链接和第二链接的交互为写操作时，通过设置写接口完成交互； 当通过第一链接和第二链接的交互为读操作时，通过设置读接口完成交互。
3.如权利要求2所述的方法，其特征在于，在写操作下，该方法进一步包括： 对打包文件的存储内容大小进行判断，当存储内容大小不超过阈值时，确定将存储内容存入分布式数据库服务设备，通过第一链接与分布式数据库服务设备进行交互，将打包文件的存储内容写入分布式数据库服务设备的对应存储位置中； 当存储内容大小超过阈值时，确定将存储内容存入分布式文件存储服务设备，通过第一链接与分布式数据库服务设备进行交互，将打包文件在分布式文件存储服务设备的存储位置写入分布式数据库服务设备中，通过第二链接与分布式文件存储服务设备进行交互，将打包文件的存储内容写入分布式文件存储服务设备的对应存储位置中。
4.如权利要求3所述的方法，其特征在于， 根据该打包文件所属仓库的仓库名、打包文件对应的类型标识以及打包文件名，生成打包文件在分布式数据库服务设备中的存储位置标识，作为打包文件的存储内容在分布式数据库服务设备中的存储位置； 根据该打包文件所属仓库的仓库名、打包文件对应的类型标识以及打包文件名，生成打包文件在分布式文件存储服务设备中的存储位置标识，作为打包文件的存储内容在分布式文件存储服务设备中的存储位置。
5.如权利要求2所述的方法，其特征在于，该方法还包括：预先将打包文件的存储内容存储在分布式数据库服务设备的对应存储位置中，在读操作下，具体交互方法为： 根据该打包文件所属仓库的仓库名、打包文件对应的类型标识以及打包文件名，确定该打包文件在分布式数据库服务设备中的存储位置； 根据分布式数据库服务设备中存储位置上的信息判断该打包文件的存储内容存在分布式数据库服务设备中还是分布式文件存储服务设备中，当存储位置上存储的是该打包文件的内容时，则读取该打包文件的内容； 当存储位置上存储的是该打包文件写入分布式文件存储服务设备的存储位置时，则根据该打包文件写入分布式文件存储服务设备的存储位置，从分布式文件存储服务设备中读取该打包文件的内容。
6.一种Git服务设备，所述Git服务设备包括： 链接建立单元，用于分别与分布式数据库服务设备建立第一链接，与分布式文件存储服务设备建立第二链接； 处理单元，用于通过第一链接与分布式数据库服务设备进行交互，处理打包文件的存储位置，通过第二链接与分布式文件存储服务设备进行交互，处理打包文件的存储内容；所述打包文件从客户端接收。
7.如权利要求6所述的Git服务设备，其特征在于，该Git服务设备进一步包括：判断单元，用于对打包文件的存储内容大小进行判断，根据判断结果对打包文件进行相应的处理。
8.如权利要求7所述的Git服务设备，其特征在于，所述判断单元，还用于对分布式数据库服务设备和分布式文件存储服务设备的状态进行判断，根据判断结果对打包文件进行相应的处理。
9.一种分布式版本控制系统,该系统包括： Git服务设备，用于分别与分布式数据库服务设备建立第一链接，与分布式文件存储服务设备建立第二链接； 通过第一链接与分布式数据库服务设备进行交互，处理打包文件的存储位置，通过第二链接与分布式文件存储服务设备进行交互，处理打包文件的存储内容；所述打包文件从客户端接收； 分布式数据库服务设备，用于存储打包文件的存储位置； 分布式文件存储服务设备，用于存储打包文件的存储内容。
10.如权利要求9所述的系统，其特征在于， 所述分布式数据库服务设备包括Hbase, Cassandra ； 所述分布式文件存储服务设备包括Jss，HDFS。
【文档编号】G06F17/30GK103647850SQ201310726376
【公开日】2014年3月19日 申请日期:2013年12月25日 优先权日:2013年12月25日
【发明者】甘露 申请人:北京京东尚科信息技术有限公司