一种数据逻辑分区的方法和系统的利记博彩app
【专利摘要】本发明公开了一种数据逻辑分区的方法和系统，适用于电信CRM系统RAC数据库，该方法包括对于业务数据设置客户编号为唯一标识；以所述客户编号为键值，采用不少于1个阶段的消除取余哈希算法对业务数据进行数据分片。本发明的技术方案适应性强，能够适合各种大型RAC数据中心，而且由于采取了多阶段哈希取模逻辑分片和分区路由访问，从而可以实现无阻塞高性能和分布式高扩张性，克服数据分区表的局限性。
【专利说明】一种数据逻辑分区的方法和系统
【技术领域】
[0001]本发明涉及数据库【技术领域】，尤其涉及一种数据逻辑分区的方法和系统。
【背景技术】
[0002]实时应用集群(Real Application Clusters,RAC)多节点分布式的云计算方案成了电信行业数据中心的必需技术手段。RAC通过增加数据库实例节点，增加数据库的整体处理能力，同时克服主机(实例)单点故障。但RAC的整体能力并非随数据库实例节点个数增加而线形增加，因为节点之间一致性通信，内存合并会消耗一定资源，限制整体能力提升，使用不好造成节点之间形成集群锁问题，甚至降低能力。目前省级电信公司客户关系管理系统(Customer Relationship Management,CRM)按照地市的维度进行数据的纵向切分，或使用数据库提供的范围分区表技术对客户数据进行分区建立分区表，以满足RAC数据物理分区提高性能的原则。
[0003]RAC的最佳实践应该根据应用的数据结构、业务处理结构特点进行数据的分片和离散设计。减少交叉访问，降低RAC内部通讯的管理消耗。从而平衡节点之间的负荷，提高整体集群的能力。目前普遍使用的方法是按自然地理的行政区域划分客户数据进行数据分片。或使用数据库提供的分区表技术对客户数据进行分片。
[0004]但这些方法存在以下问题:
[0005]1、数据库分区表技术对索引，查询使用，维护要求复杂，在灵活的应用场景下，表现很大局限性。
[0006]2、直辖市模式或单一行政区域数据模式下按照以上方法进行数据切分，造成RAC系统的性能、稳定性、可扩展性问题难以得到保证，应用部署到各个节点造成RAC的GC、GE
等故障。
[0007]在目前正在进行的全国集中、基地建设等大统一系统建设中无法实现有效数据分片设计，没有普遍适用的数据分片方法用于对数据分区。
【发明内容】
[0008]为了解决现有技术中存在的不能实现有效数据分片的技术问题，本发明提出一种数据逻辑分区的方法和系统，适合各种大型RAC数据中心，能够实现快速分布计算，数据分片灵活。
[0009]本发明一方面提供了 一种数据逻辑分区的方法，适用于电信CRM系统RAC数据库，
[0010]对于业务数据设置客户编号为唯一标识；
[0011]以所述客户编号为键值，采用不少于I个阶段的消除取余哈希算法对业务数据进行数据分片。
[0012]本发明另一方面提供了一种数据逻辑分区的系统，适用于电信CRM系统RAC数据库，包括应用节点和数据库节点，应用节点与数据库节点连接，其中，
[0013]应用节点用于对于业务数据设置客户编号为唯一标识，以所述客户编号为键值，采用不少于I个阶段的消除取余哈希算法对业务数据进行数据分片；
[0014]数据库节点用于存储业务数据。
[0015]本发明的技术方案适应性强，能够适合各种大型RAC数据中心，而且由于采取了多阶段哈希取模逻辑分片和分区路由访问，从而可以实现无阻塞高性能和分布式高扩张性，克服数据分区表的局限性。
【专利附图】
【附图说明】
[0016]图1是本发明实施例一中数据逻辑分区系统的结构示意图。
[0017]图2是本发明实施例二中数据逻辑分区的流程图。
[0018]图3是本发明实施例二中数据访问流程图。
[0019]图4是本发明实施例中CRM系统的部署示意图。
【具体实施方式】
[0020]下面结合附图对本发明的【具体实施方式】进行详细描述。
[0021]图1是本发明实施例一中数据逻辑分区系统的结构示意图。如图1所示，该数据逻辑分区系统适用于电信CRM系统RAC数据库，包括客户端101、应用节点102和数据库节点 103。
[0022]客户端与应用节点连接，应用节点与数据库节点连接。
[0023]其中，客户端用于在应用接入层通过前端传入的关键字段获取需要访问的应用节点。
[0024]应用节点用于对于业务数据设置客户编号为唯一标识，以所述客户编号为键值，采用不少于I个阶段的消除取余哈希算法对业务数据进行数据分片，还根据指定的数据源配置访问对应的数据库节点，并通过所述不少于I个阶段的哈希路由访问所述数据库节点中存储的分片业务数据。
[0025]数据库节点进一步包括不少于I个的数据分片，用于存储业务数据。
[0026]基于上述系统，本发明的【具体实施方式】提出了一种数据逻辑分区的方法，图2是本发明实施例二中数据逻辑分区的流程图。如图2所示，该流程包括以下步骤:
[0027]步骤201、通过对客户业务数据内部逻辑改造，对于所有客户业务数据设置客户编号为唯一标识；
[0028]步骤202、以客户编号为键值，采用I阶段或者η阶段的消除取余哈希算法对业务数据进行数据分片。
[0029]数据分片原则是考虑到数据准确性、数据均匀分布、应用处理复杂度几个层面的考虑，保障系统的性能、稳定性、可扩展性。
[0030]数据分区设计采用消除取余哈希(Hash)算法，对于三户资料相关的业务数据表，包括三户资料表、订单表、业务记录表等，根据业务数据中唯一标识作为关键字段取模。
[0031]按照业务数据所属的上级客户，即业务属性数据按其主体数据的唯一标识(如客户编号)进行分片，分片采用对上级客户取模的方式，以保证同一客户的业务数据在相同数据分片的分表中，保证不同业务数据表分表数据的均匀分布，并减少应用处理的复杂度；[0032]对业务数据的分片数量总共规划10 (η)个，每一个数据分片的分表存储对10 (η)取模后后一个分片数据；即Hash (key) = key mod 10 [n],其中key为键值。
[0033]在应用层级数增加或海量数据的情形下，可以采取二阶段取模Hash的算法，在理论上可以确保数据分区的快速扩展性。
[0034]在CRM业务数据内部逻辑分片实现多节点分布存储的基础上，应用通过客户资料的Hash路由算法实现多数据库节点分布式访问。由于hash算法是非阻塞分布式算法，可以支持分布数据快速定位。图3是本发明实施例二中数据访问流程图。如图3所示，该流程包括以下步骤:
[0035]步骤301、在应用接入层通过前端传入的关键字段获取需要访问的应用节点。
[0036]步骤302、该应用节点根据部署时指定的数据源配置访问对应的数据库节点。
[0037]步骤303、通过I阶段或者多阶段的哈希路由访问该数据库节点中存储的分片数据。一般设计中随业务应用层次的增加或海量数据环境下用到多阶段Hash，即多层应用使用多阶段Hash。
[0038]不同类型应用，设置路由的方式有所区别:
[0039]接口适配应用，在接口代码中进行路由设置。
[0040]后台进程应用，在后台进程主程序中进行路由设置。
[0041]WEB应用，在JSP (Java Server Pages, 一种java动态页面标准)页面或者Action (Java组件)层进行路由设置。
[0042]数据路由关键信息根据目前CRM系统中数据的关键信息可以是手机号码(包括宽带帐号)、用户标识、帐户标识、客户标识、订单编码和/或订单流水。
[0043]下面描述具体的业务数据分片插入算法I1、12和路由查询算法S1、S2。
[0044]算法Il:客户端把数据“Client”以key “c”存储。首先参考应用节点列表(1，2，η),计算key “c”的哈希值,假设应用节点I被选中。接着二阶段Hash过程。
[0045]算法12:客户端直接连接到应用节点1，再次参考数据分片列表(a，b，c)，计算key “c”的哈希值，假设应用节点a被选中。则通过key “c”把数据“Client”存储到数据分片a。
[0046]不同客户端使用相同的客户端库(意味着一阶段、二阶段的哈希算法相同)，也拥有同样的应用节点列表(1，2，η)和数据分片列表(a，b，c)。
[0047]客户端可以把数据存储在多台数据库RAC节点上。当查询数据时。
[0048]算法S1:客户端首先参考应用节点列表计算出key “c”的哈希值(一阶段哈希)，选中应用节点I。
[0049]算法S2:客户端将请求发送给选中应用节点1，然后应用节点通过针对数据分片列表(a，b，c)的哈希算法(二阶段哈希)，根据key “c”查找真正的数据“Client”。
[0050]实现过程看，各节点之间不需要通讯具有很好的可扩展性，且整个过程是非阻塞的同时具有很好性能。
[0051]图4是本发明实施例中CRM系统的数据部署和数据访问的示意图。如图4所示，CRM系统总体设计时，对于三户标识、订单编码等关键路由信息，采用指定的编码规则。系统应用在开户、过户等业务处理时，依据三户资料的编码规则生成三户标识及订单编码，并把三户资料及相关业务数据存储到相应的分区表中，同时，把手机号码与数据分片的映射数据通过缓存应用接口在缓存服务端进行缓存，便于后续业务办理时能够通过手机号码进行路由。
[0052]在应用层的部署上，依据不同接入渠道和外围接口的业务量及安全等级划分为多个应用集群组，每个应用集群组包括9个物理集群，其中4个集群对应数据库节点一，4个集群对应数据库节点二，不同应用集群组配置跨集群访问不同数据库的节点，使得数据库两个节点能够负荷分担。
[0053]WEB应用、接口适配应用、后台进程应用在业务处理时首先获取到关键的路由信息，通过关键路由信息进行地市的获取，获取方式如下。
[0054]手机号码:由缓存应用中缓存的手机号码和数据分片映射关系应用，通过手机号码进行数据hash分片的获取。
[0055]客户/帐户/用户标识:使用编码规则，通过三户标识的编码规则进行数据hash分片的获取。
[0056]订单编码:新系统中生成的订单数据，订单编码和订单标识采用一定的编码规则，可通过订单编码进行数据hash分片的获取。
[0057]应用根据关键路由信息获取到数据分片信息后，再通过相关配置数据查询到数据分片对应的大区(数据库节点)，依据配置的路由策略进行指定集群的访问，最终由应用集群访问对应的数据库节点进行数据访问和操作。
[0058]应说明的是:以上实施例仅用以说明本发明而非限制，本发明也并不仅限于上述举例，一切不脱离本发明的精神和范围的技术方案及其改进，其均应涵盖在本发明的权利要求范围中。
【权利要求】
1.一种数据逻辑分区的方法，适用于电信客户关系管理系统实时应用集群数据库，其特征在于， 对于业务数据设置客户编号为唯一标识； 以所述客户编号为键值，采用不少于I个阶段的消除取余哈希算法对业务数据进行数据分片。
2.根据权利要求1所述的一种数据逻辑分区的方法，其特征在于， 按照业务数据所属的主体数据的唯一标识进行分片，分片采用对所述上级客户取模的方式，使得一个客户的业务数据在相同数据分片的分表中； 设置预设数量的分片，每个数据分片的分表中存储对预设数量取模后的一个分片数据，即Hash (key) = key mod(预设数量)，其中key为键值。
3.根据权利要求1或者2所述的一种数据逻辑分区的方法，其特征在于，所述业务数据包括三户资料表、订单表和业务记录表。
4.根据权利要求1或者2所述的一种数据逻辑分区的方法，其特征在于，还包括以下步骤: 在应用接入层通过前端传入的关键字段获取需要访问的应用节点； 所述应用节点根据指定的数据源配置访问对应的数据库节点； 通过所述不少于I个阶段的哈希路由访问所述数据库节点中存储的分片数据。
5.根据权利要求4所述的一种数据逻辑分区的方法，其特征在于，对于接口适配应用，在接口代码中设置路由。
6.根据权利要求4所述的一种数据逻辑分区的方法，其特征在于，对于后台进程应用，在后台进程主程序中设置路由。
7.根据权利要求4所述的一种数据逻辑分区的方法，其特征在于，对于WEB应用，在JSP页面或者Action层设置路由。
8.根据权利要求4所述的一种数据逻辑分区的方法，其特征在于，所述关键字段包括手机号码、宽带账号、用户标识、账户标识、客户标识、订单编码和/或订单流水。
9.根据权利要求4所述的一种数据逻辑分区的方法，其特征在于， 依据三户资料的编码规则生成三户标识和订单编码； 将业务数据存储到对应的数据分片的分表中； 将手机号码与数据分片的映射数据通过缓存应用接口在缓存服务端进行缓存，用于通过手机号码进行路由。
10.一种数据逻辑分区的系统，适用于电信CRM系统RAC数据库，其特征在于，包括应用节点和数据库节点，应用节点与数据库节点连接，其中， 应用节点用于对于业务数据设置客户编号为唯一标识，以所述客户编号为键值，采用不少于I个阶段的消除取余哈希算法对业务数据进行数据分片； 数据库节点用于存储业务数据。
11.根据权利要求10所述的一种数据逻辑分区的系统，其特征在于，所述数据库节点进一步包括不少于I个的数据分片。
12.根据权利要求10或者11户的一种数据逻辑分区的系统，其特征在于，还包括客户端，客户端与应用节点连接，客户端用于在应用接入层通过前端传入的关键字段获取需要访问的应用节点； 应用节点还根据指定的数据源配置访问对应的数据库节点，并通过所述不少于I个阶段的哈希路由访问所述数据库节点中存储的分片业务数据。
【文档编号】G06F17/30GK103838770SQ201210487025
【公开日】2014年6月4日 申请日期:2012年11月26日 优先权日:2012年11月26日
【发明者】崔希宁, 杨海威, 张雨晴, 姚勇 申请人:中国移动通信集团北京有限公司