精华内容
下载资源
问答
  • 新老系统迁移及整合方案

    千次阅读 2018-10-17 17:23:58
    本次系统是在原有系统的基础上...本章将针对新老系统迁移和整合提出解决方案。   1.1 新老系统迁移及整合需求分析   系统迁移又称为系统切换,即新系统开发完成后将老系统切换到新系统上来。 系统切换得主要...

    本次系统是在原有系统的基础上开发完成,因此,新旧系统间就存在着切换的问题。另外,新开发的系统还存在与其他一些应用系统,例如,企业信用联网应用系统、企业登记子网站、外资登记子网站等系统进行整合使之成为一个相互连通的系统。本章将针对新老系统迁移和整合提出解决方案。

     

    1.1 新老系统迁移及整合需求分析

     

    系统迁移又称为系统切换,即新系统开发完成后将老系统切换到新系统上来。

    系统切换得主要任务包括:数据资源整合、新旧系统迁移、新系统运行监控过程。数据资源整合包含两个步骤:数据整理与数据转换。数据整理就是将原系统数据整理为系统转换程序能够识别的数据;数据转换就是将整理完成后的数据按照一定的转换规则转换成新系统要求的数据格式,数据的整合是整合系统切换的关键;新旧系统迁移就是在数据正确转换的基础上,制定一个切实可行的计划,保证业务办理顺利、平稳过渡到新系统中进行;新系统运行监控就是在新系统正常运转后,还需要监控整个新系统运行的有效性和正确性,以便及时对数据转换过程中出现的问题进行纠正。

    系统整合是针对新开发的系统与保留的老系统之间的整合,以保证新开发的系统能与保留的老系统互动,保证业务的顺利开展。主要的任务是接口的开发。

    1.1.1 需要进行整合的系统

    需要与保留系统整合的系统包括:

    1、企业登记管理(含信用分类),全国企业信用联网统计分析,不冠行政区划企业名称核准,大屏幕触摸屏系统与企业信用联网应用,企业登记子网站,属地监管传输,网上业务受理之间的整合;

    2、外资企业登记管理(含信用分类),全国外资企业监测分析与属地监管传输,外资登记子网站,网上业务受理,大屏幕触摸屏系统之间的整合;

    3、广告监管系统与广告监管子网站之间的整合;

    4、12315数据统计分析与12315子网站之间的整合;

    5、通用信息查询、统计系统与数据采集转换之间的整合;

     

     

    1.1.1 需要进行迁移的系统

    1.1.2 需要进行整合的系统

     

    需要与保留系统整合的系统包括:

    1、企业登记管理(含信用分类),全国企业信用联网统计分析,不冠行政区划企业名称核准,大屏幕触摸屏系统与企业信用联网应用,企业登记子网站,属地监管传输,网上业务受理之间的整合;

    2、外资企业登记管理(含信用分类),全国外资企业监测分析与属地监管传输,外资登记子网站,网上业务受理,大屏幕触摸屏系统之间的整合;

    3、广告监管系统与广告监管子网站之间的整合;

    4、12315数据统计分析与12315子网站之间的整合;

    5、通用信息查询、统计系统与数据采集转换之间的整合;

    1.1.1 数据迁移和转换分析

    根据招标文件工商总局新建系统的数据库基于IBM DB2,而原有系统的数据库包括ORACLE,SQL Server,DB2。这种异构数据在总局主要存在于两个方面,即部门内部的异构数据和上下级部门之间的异构数据。同时,系统的技术构件有.NET和J2EE两大类。

    对于部门内部的异构数据的集成采用数据移植的方法,如:如果数据有基于DB2管理的,有ORACLE管理的,有SQL Server管理的,就根据新系统DB2的要求,把ORACLE的数据迁移到DB2数据库中,把SQL Server的数据迁移到DB2数据库中。

    上下级国工商局之间的异构数据的集成利用数据交换系统来完成,重点在于数据库存储标准、交换标准的制定和遵守,保证数据的共享,这部分工作由数据中心完成。

    1.1 系统迁移和整合目标

    一、系统切换的主要目标:

    l 保证系统正常运行

    在数据转换过程中,由于原有的系统数据的复杂性,给数据转换工作带来了很大的难度,为了在新系统启动后不影响原系统正常的业务,因此数据转换完成后,必须保证新系统的正常运行。

    l 保证原有系统在新系统中的独立性

    原有系统是独立运行的系统,数据在新系统中虽然是集中存放的,但是各个系统由于存在业务上的差别,数据在逻辑上应当保持一定的独立性。

    二、系统整合的目标:

    保证直接关联的系统互动,保证业务的正常办理。例如公众服务系统与基本业务系统之间互动,基本业务与协同业务之间互动等等。

    1.2 系统切换方案

    1.2.1 系统切换工作流程

    系统切换包括前期调研、数据整理、数据转换、系统切换、运行监控五个阶段。系统切换的整个工作流程如下所示

    1.1.1 系统切换工作步骤

    1.1.1.1 前期调研阶段

    前期调研是数据转换中很重要的一个步骤,也是至关重要的一部分。在进行数据转换工作前,我们需要先认真阅读系统的相关文档,如《数据字典》、《系统概要设计报告》等,来熟悉原有的系统。当然在阅读文档的过程中肯定还会有理解不清晰的地方,这时还需要熟悉原有系统的工程师的帮助。数据转换的前期工作就是对原系统做一次彻底的全面了解,主要需要的考虑的有下面一些情况:

    1、原系统的网络结构;

    2、原系统的业务范围、存在几套业务系统以及他们之间的关系;

    3、原系统的开发商、开发工具、开发平台以及采用的数据库;

    4、原系统的数据分布状况:包括数据范围、数据量大小等;

    5、原系统的业务流程;

    6、原系统的数据流程;

    7、原系统的数据结构;

     

    在了解这些要素的基础上,需要编写《前期调研分析报告》。调研报告主要包含如下一些方面:

    1、将所有数据表进行分类,如系统参数类、代码类、综合业务类、相关业务类等等。

    2、对所有数据表的数据组成、数据来源、用途等进行描述。

    3、并非所有的数据都是需要进行转换的,在《数据字典分析报告》中要指出那些数据表是需要进行转换的,那些是不需要进行转换的,对于不需要转换的表要说明不需要转换的原因。

    4、描述数据在各表中的流向,对于关键的或复杂的业务点要做详细说明。

    1.1.1.2 转换设计阶段

    转换设计阶段主要是完成新旧数据字典的对照,同时明确各个表中具体数据字段的转换方式。在转换设计阶段主要是编写《数据字典对照报告》

    《数据字典对照报告》主要描述新旧系统数据表间的对照关系以及代码对照关系。以新系统为准,原系统作参照,将原系统的数据字典对应到相应的系统数据字典中。在对照过程中,需要遵循数据照搬原则,数据尽量不要作处理。

    在数据字典对照表中需要进行转换的数据字段应该一一对应,对新旧数据表中字段的名称、类型、精度等都要有详细的描述,同时还要明确数据的转换方式。数据转换方式主要有以下几种:

    1. 直接转换。直接转换方式是最常用的方式,就是将原表中对应字段的数据原封不动的搬到新表中来。按照“数据照搬”原则,我们应该应该尽量采用这种方法。

    2. 程序转换。对那些需要进行计算才能进行转换的数据将采用程序转换方式进行。

    3. 代码对照。某些代码字段,往往新旧系统的编码不相同,这时就需要参照代码对照表进行代码对照转换。

    4. 类型转换。少数数据可能需要对类型进行转换,如就表以字符串‘YYYY-MM-DD’来存放日期,而新表中以DATE型来存放日期,这时就需要进行类型转换。

    5. 常量转换。新表中某些字段可能存在缺省值,这时将采用常量转换方式,当旧表没有对应字段或旧表对应字段数据为空时,将直接在新表中写入缺省数据。

    6. 不转换。对于旧表有但新表中没有的字段将不作任何转换。

     

    新旧系统代码对照列出了全部需要进行转换的新旧系统数据表中存在的二级代码间的对照关系,主要以二级代码对照表的形式来反映。

    1.1.1.1 数据迁移

    一、数据整理策略

    数据整理就是将原系统数据整理为系统转换程序能够识别的数据。数据整理大致分为两个阶段:第一阶段就是将不同类型来源数据采集备份到统一的数据库中;第二阶段就是将原始数据进行整理,按照不同的要求分类进入不同的中间数据库,为数据转换提供中间数据。数据整理过程采用了以下方法:

    l 确保原始数据的完整性

    在进行数据整理之间,我们先需要对原始采集数据进行备份。备份的目的有两个:一个是统一数据库,便于数据转换,另一个就是为以后数据追根溯源提供参考依据。在本系统中,我们将采用DB2作为备份统一数据库。

    l 数据分级过滤策略

    数据分级过滤就是把数据按照不同的数据级别进行分类整理进入不同的中间数据库中。本系统中我们把数据分为三个级别:废弃数据、待调整数据、可转换数据。废弃数据就是该部分数据的存在对系统资源造成浪费的数据,并且会影响以后系统的运行。待调整数据就是该部分数据严重影响新系统的运行,必须进行人工调整后,方可进行数据转换。可转换数据就是该部分数据不需做任何处理,基本满足数据转换的要求或者是该部分数据新系统建议调整,但是不影响系统的运行,可以等新系统运行后再调整,这样可以为数据转换工作节省很多时间。

    l 借助数据整理相关工具

    数据整理非常艰巨,涉及的数据量很大,通过人工检查是不可能完成的,因此必须编写相关的数据整理工具完成数据整理。包括数据整理工具和数据纠错工具。数据整理工具负责将原始备份数据库中的数据进行分类进入不同的中间数据库;数据纠错工具负责提供友好、方便的工具界面供用户方相关人员完善和纠正错误数据。

    l 利用中间库作为桥梁

    由于原系统和新系统的数据库结构可能不一样,所以采用中间库作为衔接新旧系统数据的重要桥梁,对于建立新旧系统的对照关系很重要。一旦业务人员对新系统中某项转换数据存在疑问的情况下,就可以通过中间库的关联,顺利找出原数据。

     

    二、数据转换

    数据转换就是将整理后的数据,依照对照表的要求进行转换,并写入到新系统。这个过程可以通过交换系统实现。

    三、数据整理与转换步骤

    l 设计数据移植方案

    设计数据移植方案主要包括以下几个方面工作:研究历史数据的结构、来源、数据项定义、取值等现状,研究新旧数据库结构的差异,评估和选择数据移植的软硬件平台、选择数据移植方法、选择数据备份和恢复策略、设计数据移植和测试方案等。

    l 源数据库数据清理

    对于一个运行已久的数据库,主要存在三种数据库垃圾:数据库对象垃圾、数据库权限垃圾、数据垃圾。数据库对象的清理不是一件容易的工作,需有认真负责的态度,要有耐力,任何错误的清理不仅会造成前端不能运行,而且将会造成数据的丢失。所以清理数据库对象也许需要一个安全、准确,可很快恢复的方法。

    首先要认识数据库资源,包括数据库对象,如表、数据库事件、过程、函数,数据库结构关系,在此基础上结合运行系统,确认数据库垃圾,制定合理的垃圾清理方案,达到清理垃圾的目的。

    主要方法是对数据库数据进行整合和分解,整合相关数据减少数据的重复,分解数据则可是数据团体更趋向合理,当然整合和分解要以适合新设计的数据库结构为基础,以便简化转化程序。

    l 进行数据模拟移植

    根据设计的数据移植方案,建立一个模拟的数据移植环境,它既能仿真实际环境又不影响实际数据,然后在数据模拟移植环境中测试数据移植的效果。

    数据模拟移植前也应按备份策略备份模拟数据,以便数据移植后能按恢复策略进行恢复测试。

    l 测试数据模拟移植

    根据设计的数据移植测试方案测试数据模拟移植,也就是检查数据模拟移植后数据和应用软件是否正常,主要包括:数据一致性测试、应用软件执行功能测试、性能测试、数据备份和恢复测试等。

    l 准备实施数据移植

    数据模拟移植测试成功后,在正式实施数据移植前还需要做好以下几个方面工作:进行完全数据备份、确定数据移植方案、安装和配置软硬件等。

    l 正式实施数据移植

    按照确定的数据移植方案,正式实施数据移植。

    1.1.1.1 数据整理和转换的关键技术

    对于多源异构数据库之间的数据转换,因为目标数据库的格式和约束的限制严格,直接编写转换程序实现困难,可在原有数据库系统中编写转换程序。

    对于源数据库、目标数据库结构有差异的数据,建立中间过渡库,中间库在原数据库平台中建立,但结构与目标数据库的结构相同。

    将源数据库转入中间库的过程是一个数据的重新组合和关联的过程,将是转换的中心和重点工作,需要对源数据库与新数据库的数据关系进行深入分析,对每一个数据库写出转换策略。

    非空处理:对于应该非空但实际为空的记录制定处理规则。

    取值约束处理:对于有取值范围约束的字段进行规范化处理,即将转换后的数据取值规范到该范围内。

    主键处理:重新对中间库进行编号。

    填写外键:每个数据库或多或少存在外键,外键越多,标明与其它库关联越多,这样的库应后处理;反之,外键越少的库应该先处理。

    唯一键处理:对要求唯一的数据项(主键、唯一键)进行唯一检测,并对检测出的不唯一的记录,制定处理规则。

    附加分散处理:对某些表中的某些字段进行数据规范化处理,即将不合规范的数据替换成规范的数据,几个表之间的关联处理,以及一些特殊处理等。数据一致性处理:对于有多个数据源的数据进行一致性检查, 制定处理规则。

    1.1.1.2 新旧系统切换 

    第一步:编写《系统切换方案》。

    系统切换方案包括系统切换方法、系统切换计划等内容。

    第二步:组织相关人员对《系统切换方案》进行评审,如果未通过,则需要调整系统切换方案。

    第三步:进行业务系统数据转换。

    在进行业务系统数据转换前,需要先选择一个时间点进行业务系统数据采集。该时间点的选择以完成一个完整的业务周期为准。

    l 转换时机

    根据以往的经验,我们建议将正式数据转换的时间放在月结刚刚完成后并且最好是节假日。

    l 准备工作

    正式数据转换前的准备工作是非常多的,现列举如下:

    编写详细的《数据转换指南》。《数据转换指南》应该是在前面的几次试转换过程中编写并完善的,要详细说明数据转换的全过程,包括:准备工作、执行步骤、注意事项等。

    编写执行脚本。在前面几次试转换的基础上编写并完善好数据转换执行脚本。执行脚本包括:转换执行脚本、验证执行脚本等。所有的脚本都必须安装执行的先后顺序编写,在正式转换时将按照顺序来执行。

    数据库环境准备。根据以往的经验,在正式转换阶段出现的异常往往都是有数据库方面的,大部分是因为数据库环境没有准备好。数据库方面需要做好如下几方面的准备:表空间划分、大数据文件准备、大回滚段准备、创建索引等。

    其他必要准备。在正式转换前,老系统要停止使用,同时在还需要把老系统的数据做一次完整的备份。   

    l 执行过程

    数据转换时将按照已经编写好的转换执行脚本来进行。对没一步的操作都要做好日志记录,日志分两种,一种是计算机自动产生的日志,如LOG文件;另一种是在转换执行过程中手工做的记录。在正式转换时,要求至少两人一起工作,其中一人负责操作,另外一人负责监督,两人都必须做好记录。

    每执行完一条转换命令后都需要去查看一些错误记录表,如果出现异常错误信息,需要暂停转换执行,对错误分析处理完毕后才能继续执行。

    l 验证过程

    转换执行结束后,需要对转换的结果进行验证,验证时按照已经编写好的验证脚本来进行,验证最好由两名以上的人员分开来进行,在验证过程中做好每一步的验证记录。

    如果在验证过程中没有发现异常,并且几名验证人员的验证记录都非常一致,则可以认为已经通过验证。

    l 收尾工作

    数据转换工作执行完毕后,需要对关闭原有系统全部的业务经办功能,只开发查询功能,以便业务人员在需要时可以继续查询旧系统中的数据。

    对新系统的数据进行一次物理备份,同时启动新系统数据库的重做日志功能。

    到此时为止新旧系统数据转换工作全部结束,整个应用系统将切换到新系统上来运行。

    第四阶段: 新系统运行监控及数据整理

    在所有新系统平稳运行后,还需要进行定期的运行监控以及对部分数据进行调整。对于那些对系统运行未造成影响的,在数据整理过程中,没有进行数据修正,所以在系统平稳运行后,需要对这些数据进行调整。

    1.1.1.3 系统切换保障措施

    系统在整个切换过程中,安全、平稳过渡是第一位的。我们将采用如下措施保证系统切换安全:

    1、数据备份

    在进行新旧系统数据转换时,对原系统数据进行备份以保证历史数据的可追溯性。一旦在新系统中业务办理出现问题,则可以通过追溯历史数据来判断是数据转换错误,还是新系统程序存在BUG。

    2、 数据测试

    数据测试分为两个层次测试,一个是数据监测性测试,就是在数据转换完成后,测试数据的转换正确性;二是验证性测试,验证性测试通过使用已经通过功能测试的新系统办理实际业务来验证数据转换的正确性。

    数据测试是一个关键环节,关系到系统切换的成功与否,所以必须加大测试力度来保证数据转换的正确性。而与数据测试相关的系统功能测试也必须重视,因为如果系统功能如果存在问题,则数据测试也就无法保证正确性。

    3、切换点的选择

    系统在什么时候进行切换,也是一个很关键的问题。一般情况下,我们都选择一个业务周期结束,下一个业务周期开始的时候进行切换。

    4、切换方式的选择

    系统切换有两种方式,一种是新旧系统并轨运行,一种是新系统单轨运行。对于第一种方式旧系统为主,新系统为辅,在时机成熟的时候在切换到新系统运行;第二种是以新系统为主,旧系统为辅,旧系统只是验证新系统业务办理的正确与否。第一种方式安全系数由于过渡期时间会很长,业务人员工作量很大,而第二种由于直接采用新系统,存在一定的风险,我们可以通过加大测试力度来降低风险。综上所述,我们建议采用第二种方式,就是新系统为主,原系统为辅的方式。

    5、应急预案

    在特殊情况下,由于某种原因导致系统没有能够正常切换或者切换以后系统运行不稳定,在这种情况下,必须启动应急预案来解决。具体应急预案如下:

    应急预案需要从业务系统、数据库、网络平台三个方面来考虑应急处理措施,只有三方面同时恢复到系统切换前的状态,才能保证原系统业务经办的正常进行。业务应用系统应急措施主要是在业务经办时保留原业务应用系统,并且保证原业务应用系统的客户端配置环境能够在最短时间内恢复到以前的配置;数据库应急措施就是利用原始数据与原系统保持一致来处理的,也就是在新系统数据库中保留备份,并且按照原系统数据集中情况下分不同用户存放备份数据,但是用户名仍需要采用原数据库系统用户名。一旦出现紧急情况,新系统数据库立即切入原备份数据库;网络平台应急预案就是保证在数据大集中情况下整个社会保障网络链路的畅通即可。

    1.1.1 系统切换过程中需注意的问题

    1、最大限度的保证原系统数据转换到新系统中,即使是对错误数据进行一些处理,然后在新系统中调整。

    2、新旧系统的对应关系一定要完整。

    3、原系统的数据在新系统中一定要有备份,不能数据转换完成以后就将原系统数据删除掉。原系统备份数据至少保留一年的时间。

    4、新系统开发过程中,数据转换负责人一定要与软件项目负责人保持经常沟通,以保证转换数据的正确性。同时软件项目负责人熟悉原系统的业务流程和用户的习惯操作方式也是有必要的。

    5、数据质量测试是非常重要的一个环节。

    展开全文
  • mysql 数据库拆分与整合方案

    千次阅读 2015-05-18 11:03:39
    文章整理自:http://www.linuxidc.com/Linux/2011-08/40601p2.htm1、数据切分方案当数据库比较庞大,读写操作特别是写入操作过于频繁,很难由一台服务器支撑的时候,我们就要考虑进行数据库的切分。所谓数据库的切分...

    文章整理自:http://www.linuxidc.com/Linux/2011-08/40601p2.htm

    1、数据切分方案

    当数据库比较庞大,读写操作特别是写入操作过于频繁,很难由一台服务器支撑的时候,我们就要考虑进行数据库的切分。所谓数据库的切分,就是我们按照某些特定的条件,将一台数据库上的数据分散到多台数据库服务器上。因为使用多台服务器,所以当一台服务器宕机后,整个系统只有部分数据不可用,而不是全部不可用。因此,数据库切分不仅能够用多台服务器分担数据库的负载压力,还可以提高系统的总体可用性。

    数据的切分有两种方式:垂直切分和水平切分。

    1.1 垂直切分

    垂直切分就是按照系统功能模块,将每个模块访问的数据表切分到不同的数据库中

    适用情况:垂直切分适用于架构设计较好,各个模块间的交互点比较统一而且比较少,耦合度较低的系统。

    优点:数据库的切分简单明了,规则明确;系统模块清晰明确,容易整合;数据维护方便,定位容易。

    缺点:无法在数据库内实现表关联,只能在程序中实现;对于访问量大且数据量超大的数据表仍然会存在性能问题;事物处理会变得更为复杂,跨服务器的分布式事务会增多;过度切分会导致系统过度复杂、无法扩展、维护困难。

    1.2 水平切分

    水平切分就是对数据量超大的数据表,按照其中数据的逻辑关系,根据某个字段的某种规则,将其中的数据切分到多个数据库上。

    适用情况:水平切分适用于有超大数据量的表且有合适的字段和规则进行水平切分的数据库。数据库进行水平切分后的多个数据库不应该存在交互的情况。

    优点:可以在数据库内实现表关联;不会存在超大数据量且超高负载的数据表;可以在数据库内实现事务处理,事务处理相对简单;在合理的切分规则下,扩展性较好。

    缺点:切分规则一般比较复杂,很难找出一个适合整个数据库的切分规则;数据的维护难度增加,人工定位数据难度增加;系统模块的耦合度较高,数据迁移拆分难度增加。

    在实际进行数据切分时,我们首先应该根据系统模块的设计,合理地进行垂直切分。当模块细分到一定程度后,如果继续进行细分,就会使系统架构过于复杂,整个系统面临失控的危险。这时,我们就要利用水平切分的优势,来避免继续进行垂直切分导致的系统复杂化、面临失控的问题。同时,因为数据已经进行了合理的垂直切分,所以水平切分规则相对简单,系统模块耦合度较高的问题也已得到解决。总之,数据切分应该遵循一个原则,那就是“先合理垂直切分,再适时水平切分;先模块化切分,后数据集切分”。


    2、数据整合方案

    数据在经过垂直和水平切分被存放在不同的数据库服务器上之后,系统面临的最大问题就是如何来让这些来自不同数据库服务器上的数据得到较好的整合。解决这个问题有两种方式:

    第一种:在系统的每个模块中配置管理该模块需要的一个或者几个数据库及其所在服务器的信息,数据在模块中进行整合;

    第二种:通过中间代理层来统一管理所有的数据源,数据库集群对系统应用透明。

    第一种方案在初期开发时所需成本较小,但是长期来看,系统的扩展性会受到较大的限制。第二种方案则刚好相反,短期内付出的成本相对较大,但有利于系统的扩展。第二种方案可以通过一些第三方软件实现。

    2.1 MySQLProxy

    MySQLProxy可用来监视、分析、传输应用与数据库之间的通信。它可以实现连接路由,Query分析,Query过滤和修改,负载均衡,以及基本的HA机制等。

    原理:MySQLProxy 实际上是在应用请求与数据库服务之间建立了一个连接池。所有应用请求都发向MySQLProxy,然后经由MySQLProxy 进行相应的分析,判断出是读操作还是写操作,分发至对应的MySQLServer 上。对于多节点Slave集群,也可以起到负载均衡的效果。

    优点:MySQLProxy具有很大的灵活性,我们可以最大限度的使用它。

    缺点:MySQLProxy实际上并不直接提供相关功能,这些功能都要依靠自行编写LUA脚本实现。

    2.2 Amoeba

    Amoeba是一个基于Java开发的Proxy程序开源框架,致力于解决分布式数据库的数据整合问题。它具有Query路由,Query过滤,读写分离,负载均衡功能以及HA机制等。Amoeba可以整合数据切分后的复杂数据源,降低数据切分给整个系统带来的影响,降低数据库与客户端的连接数,实现数据的读写分离。

    原理:Amoeba相当于一个SQL请求的路由器,它集中地响应应用的请求,依据用户事先设置的规则,将SQL请求发送到特定的数据库服务器上执行。据此实现负载均衡、读写分离、高可用性等需求。

    优点:基于XML的配置文件,用SQLJEP语法编写规则,配置比较简单

    缺点:目前还不支持事务;对返回大数量的查询并不合适;不支持分库分表,只能做到分数据库实例。

    2.3 HiveDB

    HiveDB也是一个基于Java开发,针对MySQL数据库提供数据切分及整合的开源框架。但是,目前的HiveDB仅支持数据的水平切分。HiveDB主要解决大数据量下数据库的扩展性及数据的高性能访问问题,同时支持数据的冗余及基本的HA机制。

    原理:HiveDB通过用户自定义的各种Partition keys将数据分散到多个数据库服务器上,访问时解析query请求,自动分析过滤条件,并行从多个数据库上读取数据后合并结果集返回给客户端应用程序。HiveDB的实现机制与Amoeba和MySQLProxy不同,它不用借助其他复制同步技术即可自行实现数据的冗余。其底层主要是基于Hibernate Shards 来实现的。Hibernate Shards是Google 技术团队在对 Google 财务系统数据 Sharding 过程中诞生的。Hibernate Shards是在框架层实现的,有其独特的特性:标准的 Hibernate 编程模型,会用 Hibernate 就能搞定,技术成本较低;相对弹性的 Sharding 策略以及支持虚拟 Shard 等。

    优点:有商业公司支持,可自行实现数据冗余。

    缺点:仅支持水平分区

    在数据的整合过程中,还存在一些问题,比如:分布式事务的问题,跨节点JOIN的问题,跨节点排序分页的问题等。对于分布式事务的问题,我们需要将其拆分成多个单数据库内的小事务,由应用程序进行总控;跨节点JOIN的问题,我们需要先从一个节点中取出数据,然后由应用程序去其他节点进行JOIN或者使用Federated引擎;跨节点排序分页时,我们可以并行地从多个节点中读取数据,然后由应用程序进行排序分页。

    3、数据冗余方案

    任何设备或服务,只要是单点,就存在着很大的安全隐患。因为一旦这台设备或服务宕机之后,在短时间内就很难有备用设备或服务来顶替其功能。数据库作为系统的核心,必须存在一个备份以在出现异常时能够快速顶替原有服务,实现高可用性。同时,要实现数据库的读写分离,也必须采用复制技术保持多数据库节点的数据同步。实现数据同步的方式有很多,下面简要介绍常用的几个。

    3.1 MySQL Replication

    MySQL Replication是MySQL自带的一个异步复制的功能。复制过程中一个服务器充当主服务器,而一个或多个其它服务器充当从服务器,也就是主从模式。

    原理:MySQL使用3个线程来执行复制功能。当开始复制时,从服务器会创建一个I/O线程连接主服务器并要求主服务器发送记录在其上的二进制日志中的语句。主服务器会创建一个线程将二进制日志中的内容发送到从服务器。从服务器I/O线程读取主服务器线程发送的内容并将该数据复制到从服务器数据目录中的本地文件中,这个文件称为中继日志。第三个线程是SQL线程,是由从服务器创建的,用来读取中继日志并执行日志中包含的更新。常用的架构方式为:主-从、主-主、主-从级联、主-主-从级联等。

    优点:部署简单、实施方便,是MySQL自动支持的功能,主备机切换方便,可以通过第三方软件或者自行编写简单的脚本即可自动完成主备切换。

    缺点:实际使用时,只能单主机进行写入,不一定能满足性能要求;服务器主机硬件故障时,可能会造成部分尚未传输至从机的数据丢失。

    3.2 MySQLCluster

    MySQL Cluster 是MySQL适用于分布式计算环境的高可用、高冗余版本,采用了NDB Cluster 存储引擎(“NDB”是一种“内存中”的存储引擎,它具有可用性高和数据一致性好的特点),允许在1个 Cluster 中运行多个MySQL服务器。

    原理:MySQL Cluster将标准的MySQL服务器与NDB Cluster存储引擎集成了起来。MySQL Cluster由一组计算机构成,每台计算机上均运行着多种进程,包括MySQL服务器,NDB Cluster的数据节点,管理服务器,以及(可能)专门的数据访问程序。所有这些程序一起构成了MySQL Cluster。将数据保存到NDB Cluster存储引擎时,表(结构)被保存到了数据节点中,应用程序能够从所有其他MySQL服务器上直接访问这些表。 参见下图:


    优点:可用性非常高,性能非常好;每一份数据至少在不同主机上面存在一份拷贝,且实时同步;通过无共享体系结构,系统能够使用廉价的硬件,而且对软硬件无特殊要求。

    缺点:维护比较复杂,很多情景下不适合使用。


    简单的说,Mysql Cluster 实际上就是在无共享存储设备的情况下实现的一种内存数据库Cluster 环境,其主要是通过NDB Cluster(简称NDB)存储引擎来实现的。一般来说,一个Mysql Cluster 的环境主要由以下三部分组成:
    a) 负责管理各个节点的Manage 节点主机:管理节点负责整个Cluster 集群中各个节点的管理工作,包括集群的配置,启动关闭各节点,以及实施数据的备份恢复等。管理节点会获取整个Cluster 环境中各节点的状态和错误信息,并且将各Cluster 集群中各个节点的信息反馈给整个集群中其他的所有节点。由于管理节点上保存在整个Cluster 环境的配置,同时担任了集群中各节点的基本沟通工作,所以他必须是最先被启动的节点。

    b) SQL 层的SQL 服务器节点(后面简称为SQL 节点),也就是我们常说的Mysql Server:主要负责实现一个数据库在存储层之上的所有事情,比如连接管理,query 优化和响
    应,cache 管理等等
    ,只有存储层的工作交给了NDB 数据节点去处理了。也就是说,在纯粹的Mysql Cluster 环境中的SQL 节点,可以被认为是一个不需要提供任何存储引擎的Mysql服务器,因为他的存储引擎有Cluster 环境中的NDB 节点来担任。所以,SQL 层各Mysql 服务器的启动与普通的Mysql 启动有一定的区别,必须要添加ndbcluster 项,可以添加在my.cnf 配置文件中,也可以通过启动命令行来指定。

    c) Storage 层的NDB 数据节点,也就是上面说的NDB Cluster:NDB 是一个内存式存储引擎,也就是说,他会将所有的数据和索引数据都load 到内存中,但也会将数据持久化到存储设备上。不过,最新版本,已经支持用户自己选择数据可以不全部Load 到内存中了,这对于有些数据量太大或者基于成本考虑而没有足够内存空间来存放所有数据的用户来说的确是一个大好消息。NDB 节点主要是实现底层数据存储的功能,保存Cluster 的数据。每一个NDB 节点保存完整数据的一部分(或者一份完整的数据,视节点数目和配置而定),在MySQL CLuster 里面叫做一个fragment。而每一个fragment,正常情况来讲都会在其他的主机上面有一份(或者多分)完全相同的镜像存在。这些都是通过配置来完成的,所以只要配置得当,MysqlCluster 在存储层不会出现单点的问题。一般来说,NDB 节点被组织成一个一个的NDB Group,一个NDB Group 实际上就是一组存有完全相同的物理数据的NDB 节点群。上面提到了NDB 各个节点对数据的组织,可能每个节点都存有全部的数据也可能只保存一部分数据,主要是受节点数目和参数来控制的。首先在Mysql Cluster 主配置文件(在管理节点上面,一般为config.ini)中,有一个非常重要的参数叫NoOfReplicas,这个参数指定了每一份数据被冗余存储在不同节点上面的份数,该参数一般至少应该被设置成2,也只需要设置成2 就可以了。因为正常来说,两个互为冗余的节点同时出现故障的概率还是非常小的,当然如果机器和内存足够多的话,也可以继续增大。一个节点上面是保存所有的数据还是一部分数据,还受到存储节点数目的限制。NDB 存储引擎首先保证NoOfReplicas 参数配置的要求对数据冗余,来使用存储节点,然后再根据节点数目将数据分段来继续使用多余的NDB 节点,分段的数目为节点总数除以NoOfReplicas 所得。


    3.3 DRBD磁盘网络镜像方案

    DRBD(Distributed Replicated Block Device),是由LINBIT 公司开发的,通过网络来实现块设备的数据镜像同步的一款开源Cluster软件,也被俗称为网络RAID1。

    原理:DRBD介于文件系统与磁盘介质之间,通过捕获上层文件系统的所有IO操作,调用内核中的IO模块来读写底层的磁盘介质。当DRBD捕获到文件系统的写操作之后,会在进行本地的磁盘写操作的同时,以TCP/IP协议,通过本地主机的网络设备(NIC)将IO传递至远程主机的网络设备。当远程主机的DRBD监听到传递过来的IO信息之后,会立即将该数据写入到该DRBD所维护的磁盘设备。DRBD在处理远程数据写入的时候有三种复制模式,适用于不同的可靠性和性能要求情景。

    优点:功能强大,数据在底层块设备级别跨物理主机镜像,可根据性能和可靠性要求配置不同级别的同步;IO操作保持顺序,可满足对数据一致性的苛刻要求。

    缺点:非分布式文件系统环境无法支持镜像数据同时可见,性能和可靠性两者相互矛盾,无法适用于性能和可靠性要求都比较苛刻的环境,维护成本比较高。

    3.4 RaiDB

    RaiDB,其全称为RedundantArrays of Inexpensive Databases,也就是通过Raid理念来管理数据库的数据:通过将多个廉价的数据库实例组合到一个数据库阵列,提供比单台数据库更好的性能和容错性,同时隐藏分布式数据库的复杂性,提供给应用程序一个独立的数据库。

    原理:在RaiDB中,控制器在数据库阵列的前面。应用程序发送请求到RaiDB控制器,控制器将请求分发给一组数据库。跟磁盘的Raid一样,RaiDB也有不同的级别或数据分发方案,如RaiDB-0、RaiDB-1、RaiDB-1-0、RaiDB-0-1等,用于提供不同的成本、性能、容错权衡。

    优点:和磁盘的Raid一样,RaiDB也可以大幅提高数据的读写速度,并提供容错功能

    缺点:只能支持将数据库中的表分割到不同的数据库实例上,数据表本身不能再进行分割了;不支持分布式的join;扩展性的提升取决于表的数目和各个表的负载情况。

    4、数据缓存方案

    4.1 Memcached

    缓存是任何海量 Web 应用程序不可或缺的部分。Memcached是一个高性能的分布式内存对象缓存系统,用以减轻动态Web应用的数据库负载。它通过在内存中缓存数据和对象来减少读取数据库的次数,从而提高动态数据库驱动网站的访问速度。

    原理:Memcached基于一个存储键/值对的hashmap,需要采用不同的方式来执行数据库的读取和写入操作。执行读取操作的顺序是从 Web 层获取(需要执行一次数据库查询的)请求并检查之前在缓存中存储的查询结果。如果找到所需的值,则返回它。如果未找到,则执行查询并将结果存储在缓存中,然后再将结果返回给 Web 层。在执行写入操作时,首先执行数据库写入操作,然后将之前缓存的任何受此写入操作影响的结果设定为无效,用以防止缓存和数据库之间出现数据不一致。

    优点:大幅度地降低了数据库负载,更好地分配了资源,提供了更快速地数据访问;其守护进程(daemon)是用C写的,但是客户端可以用任何语言来编写,并通过memcached协议与守护进程通信。

    缺点:不提供冗余,当某个服务器停止运行或崩溃时,所有存放在该服务器上的键/值对都将丢失;在需要Cache的数据对象较多的时候,应用程序所需要的代码量就会增加很多,同时系统复杂度以及维护成本也会直线上升。

    5、全文检索方案

    全文检索是指计算机索引程序通过扫描文章中的每一个词,对每一个词建立一个索引,指明该词在文章中出现的次数和位置,当用户查询时,检索程序就根据事先建立的索引进行查找,并将查找的结果反馈给用户的检索方式。这个过程类似于通过字典中的检索字表查字的过程。好的检索方案不仅能提高检索效率,还能降低系统负载、节约系统成本。

    5.1 Lucene

    Lucene是一个开放源代码的全文检索引擎工具包。它不是一个完整的全文检索引擎,而是一个全文检索引擎的架构,提供了完整的查询引擎和索引引擎,还有部分文本分析引擎。Lucene的目的是为软件开发人员提供一个简单易用的工具包,以方便的在目标系统中实现全文检索的功能,或者是以此为基础建立起完整的全文检索引擎。目前已有一些对Lucene进行封装的解决方案,如Hibernate Search、Compass等。

    原理:应用程序调用Lucene的相关API把数据库的数据写入并创建好索引,然后就可以调用Lucene所提供的数据检索API得到需要访问的数据,而且可以进行全模糊匹配。Lucene的数据也是存放在磁盘上而不是内存中,但是由于其高效的分词算法和索引结构,其效率非常的好。

    优点:索引文件格式独立于应用平台;实现了分块索引,能够针对新的文件建立小文件索引,提升索引速度;设计了独立于语言和文件格式的文本分析接口;已经默认实现了一套强大的查询引擎,用户无需自己编写代码即可使系统获得强大的查询能力,Lucene默认实现了布尔操作、模糊查询、分组查询等等。

    缺点:不是完整的全文搜索引擎,需要开发人员进行大量的编码实现;配置比较复杂,应用难度大。

    5.2 Hibernate Search

    Hibernate Search是Hibernate对Lucene的一个集成方案,使用Java开发,用于对数据库中的数据进行检索。

    原理:Hibernate Search通过对数据表中某些内容庞大的字段(如text字段)建立全文索引,然后对这些字段进行全文检索后获得相应的POJO,从而加快了对内容庞大字段进行模糊检索(sql语句中like匹配)的速度。

    优点:功能强大,配置简单,只需要修改两个XML文件就可进行配置;支持Hibernate,以及EJB3 JPA标准应用;可以简单透明索引查询过的数据;支持通配符、多关键字、近义词、同义词、模糊查询等复杂检索,以及相关性排序等;支持搜索集群。

    缺点:只支持Hibernate框架集成;应用示例很少,缺少参考资料。

    5.3 Compass

    Compass也是对Lucene的一个封装,是一个强大的,支持事务的开源搜索引擎框架。

    原理:服务器启动时把需要建立索引的表中的数据全部取出,建立索引;在运行过程中,如果容器检测到数据有变动,需要更新索引,则添加或者删除索引。

    优点:可以实时建立增量索引,不用定时重建索引;支持事务,可以直接对POJO进行保存;支持多种持久化框架(Hibernate、Struts、Spring等)。

    缺点:不支持分类统计;API能力有限。

    5.4 Solr

    Solr也是一个开源的基于Lucene的高性能全文搜索服务器,采用Java5开发。它对Lucene进行了扩展,提供了比其更为丰富的查询语言,同时实现了可配置、可扩展并对查询性能进行了优化,并且提供了一个完善的功能管理界面,是一款非常优秀的全文搜索引擎。

    原理:Solr对外提供类似于Web-service的API接口。用户可以通过http请求,向搜索引擎服务器提交一定格式的XML文件,生成索引;也可以通过HttpGet操作提出查找请求,并得到XML格式的返回结果。

    优点:具有高效、灵活的缓存功能和垂直搜索功能;可高亮显示搜索结果;通过索引复制提高了可用性;提供了一套强大的Data Schema来定义字段,类型和设置文本分析;提供了基于Web的管理界面。

    缺点:分布式搜索的Master节点不容错。

    5.5 Sphinx

    Sphinx是一个用C++开发的基于SQL的全文检索引擎,可以结合MySQL,PostgreSQL做全文搜索,它可以提供比数据库本身更专业的搜索功能,使得应用程序更容易实现专业化的全文检索。Sphinx特别为一些脚本语言设计了搜索API接口,如PHP,Python,Perl,Ruby等,同时也为MySQL设计了一个存储引擎插件。

    原理:Sphinx提供了indexer、searchd、search 3个应用程序,indexer用来创建索引,searchd用来启动全文检索服务,search作为客户端访问全文检索服务获取检索结果。Sphinx支持以增量的方式来建立索引:在第一次为需要检索的内容全部建立索引之后,以后每次重建索引时只为一段时间内新增或修改过的内容建立索引。创建的这些增量索引可以定时合并到主索引中。Sphinx在进行全文检索时默认会访问全部建立的索引,包括主索引和所有的增量索引。索引以何种方式创建对于应用来说是透明的,应用可以完全不必关心。

    优点:高速索引 (在新款CPU上,近10 MB/秒);高速搜索 (2-4G的文本量中平均查询速度不到0.1秒);高可用性 (单CPU上最大可支持100 GB的文本,100M文档);提供良好的相关性排名;支持分布式���索;提供文档摘要生成;提供从MySQL内部的插件式存储引擎上搜索;支持每个文档多个全文检索域(默认最大32个);支持每个文档多属性;支持断词;支持单字节编码与UTF-8编码;支持MySQ(MyISAM和InnoDB 表都支持);支持PostgreSQL;支持多个平台(Windows、Linux、Unix、Mac等)。

    缺点:必须要有主键,且必须为整型;不能进行灵活配置。


    6、分布式并行计算方案

    6.1 Google MapReduce

    MapReduce是由Google公司发明的近些年来新兴的分布式计算模型,同时也是Google用C++开发的处理海量数据的编程工具。作为Google公司的核心技术之一,MapReduce在处理T级别以上的海量数据时有着卓越的表现。

    原理:在我们输入数据的逻辑记录上应用map操作,来计算出一个中间key/value对集;在所有具有相同key的value上应用reduce操作,来适当地合并派生的数据。功能模型的使用,再结合用户指定的map和reduce操作,让我们可以非常容易的实现大规模并行化计算,同时使用重启作为初级机制可以很容易地实现容错。

    优点:简化了跨节点的编程,使用非常方便,它隐藏了并行计算的细节,错误容灾,本地优化以及负载均衡,开发人员可以使用自己熟悉的语言进行开发,如Java,C#,Python,C++等;可以非常轻松的完成大型的计算需求;支持上千节点的大型集群,而且提供经过优化的错误容灾;扩展性强,可通过增加节点增强处理能力。

    缺点:不适应实时计算应用的需求;在计算未全部完成前,无法查询到结果。

    6.2 Hadoop

    Hadoop 是一个开源的可运行于大规模集群上的分布式并行编程框架,是MapReduce思想的一个Java实现。由于分布式存储对于分布式编程来说是必不可少的,这个框架中还包含了一个分布式文件系统 HDFS( Hadoop Distributed File System )。

    原理:在Hadoop的系统中,会有一台Master,主要负责NameNode的工作以及JobTracker的工作。JobTracker的主要职责就是启动、跟踪和调度各个Slave的任务执行。还会有多台Slave,每一台Slave通常具有DataNode的功能并负责TaskTracker的工作。TaskTracker根据应用要求来结合本地数据执行Map任务以及Reduce任务。

    优点:良好的可扩展性,系统管理员可以随时增删计算节点;分布式文件系统的备份恢复机制以及MapReduce的任务监控保证了分布式处理的可靠性;分布式文件系统的高效数据交互实现以及MapReduce结合LocalData处理的模式,可实现高效处理海量数据;框架可以运行在任何普通的PC上节约成本。

    缺点:易用性不够;缺乏第三方产品支持;稳定性有待加强。

    7 典型案例

    7.1 Facebook

    根据网络搜集到的资料,Facebook可能的部分架构如下:

    Web前端是由PHP编写的,PHP程序由HipHop for PHP转换成 C++并用 g++编译,用于为模板和Web逻辑业务层提供高性能;业务逻辑以Service的形式存在,使用的是Thrift框架,根据需求的不同由PHPC++Java等实现;非用户相关的信息使用APCThe Alternative PHP Cache)缓存,用户相关的数据使用Memcached缓存;持久化由MySQL CassandraHBase完成;页面加速使用Facebook定制的BigPipe技术;HTTP代理用Varnish Cache。


    日志、点击、feeds等数据使用Scribe日志收集系统收集并存储于HDFS系统上,使用Hadoop和Hive进行分析处理。

    Facebook并未公开其架构,以上内容为个人根据网络搜集资料进行的猜想。

    7.2 人人网

    根据网络上搜集到的相关资料来看,人人网的架构是不断演变的,每年的架构都不相同。2006年,人人网(校内网)刚创办上线时的架构比较简单。Squid cache用作HTTP代理服务器和Web缓存服务器;Resin用作Web服务器;使用MySQL(InnoDB引擎和主从结构)做持久化。2007年,随着业务的迅速发展,Web服务器改为LVS进行负载均衡的Resin群集,MySQL也改为群集并进行了垂直切分,开始大量使用Memcached进行数据缓存处理,同时基于ICE通信框架开发了位于MySQL和Resin中间的中间层服务,用于提供高并发低成本的数据访问。另外,还引入了Lucene进行全文检索。2008年,人人网开始开发开放API,引入了SOA(Service-oriented architecture,面向服务架构),同时由于业务量的大幅增加,MySQL进行了水平分区。另外,开始使用DFS(分布式文件系统)并引入了集群存储系统(龙存)。2008年以后,人人网开始拆分各个子系统,架构从紧耦合逐渐变为松耦合,MySQL也逐渐地被NoSQL取代,同时更加关注Graceful degradation和TCO((Total cost of ownership))。

    从网络搜集到的资料来看,人人网目前采用的相关软件如下:

    Nginx用来做跨IDC的请求代理;Resin用作Web服务器;Squid cache用作图片文件的反向代理;LVS提供四层负载均衡;ICE网络通讯框架被用来开发一些cache服务和逻辑服务;Netty网络框架被用来开发一些小服务;Struts框架已被自行开发的基于Spring技术的Rose Web框架所代替;基于Lucene的搜索集群提供搜人的服务;Memcached继续负责大部分缓存服务;持久化除MySQL外还有Tokyo Cabinet和人人网自行开发的Nuclear。大致的架构图如下:





    展开全文
  • 数据切分及整合方案

    千次阅读 2015-11-09 15:19:33
    通过前面的章节,我们已经很清楚了通过数据库的数据切分可以极大的...这一节我们主要针对的内容就是分析可以使用的各种可以帮助我们实现数据切分以及数据整合的整体解决方案。 数据的整合很难依靠数据库本身来达到这

    通过前面的章节,我们已经很清楚了通过数据库的数据切分可以极大的提高系统的扩展性。但是,数据库中的数据在经过垂直和(或)水平切分被存放在不同的数据库主机之后,应用系统面临的最大问题就是如何来让这些数据源得到较好的整合,可能这也是很多读者朋友非常关心的一个问题。这一节我们主要针对的内容就是分析可以使用的各种可以帮助我们实现数据切分以及数据整合的整体解决方案。

    数据的整合很难依靠数据库本身来达到这个效果,虽然MySQL存在Federated存储引擎,可以解决部分类似的问题,但是在实际应用场景中却很难较好的运用。那我们该如何来整合这些分散在各个MySQL主机上面的数据源呢?

    总的来说,存在两种解决思路:

    1. 在每个应用程序模块中配置管理自己需要的一个(或者多个)数据源,直接访问各个数据库,在模块内完成数据的整合;

    2. 通过中间代理层来统一管理所有的数据源,后端数据库集群对前端应用程序透明;

    可能90%以上的人在面对上面这两种解决思路的时候都会倾向于选择第二种,尤其是系统不断变得庞大复杂的时候。确实,这是一个非常正确的选择,虽然短期内需要付出的成本可能会相对更大一些,但是对整个系统的扩展性来说,是非常有帮助的。

    所以,对于第一种解决思路我这里就不准备过多的分析,下面我重点分析一下在第二种解决思路中的一些解决方案。

    ★ 自行开发中间代理层

    在决定选择通过数据库的中间代理层来解决数据源整合的架构方向之后,有不少公司(或者企业)选择了通过自行开发符合自身应用特定场景的代理层应用程序。

    通过自行开发中间代理层可以最大程度的应对自身应用的特定,最大化的定制很多个性化需求,在面对变化的时候也可以灵活的应对。这应该说是自行开发代理层最大的优势了。

    当然,选择自行开发,享受让个性化定制最大化的乐趣的同时,自然也需要投入更多的成本来进行前期研发以及后期的持续升级改进工作,而且本身的技术门槛可能也比简单的Web应用要更高一些。所以,在决定选择自行开发之前,还是需要进行比较全面的评估为好。

    由于自行开发更多时候考虑的是如何更好的适应自身应用系统,应对自身的业务场景,所以这里也不好分析太多。后面我们主要分析一下当前比较流行的几种数据源整合解决方案。

    ★利用MySQLProxy实现数据切分及整合

    MySQLProxy是MySQL官方提供的一个数据库代理层产品,和MySQLServer一样,同样是一个基于GPL开源协议的开源产品。可用来监视、分析或者传输他们之间的通讯信息。他的灵活性允许你最大限度的使用它,目前具备的功能主要有连接路由,Query分析,Query过滤和修改,负载均衡,以及基本的HA机制等。

    实际上,MySQLProxy本身并不具有上述所有的这些功能,而是提供了实现上述功能的基础。要实现这些功能,还需要通过我们自行编写LUA脚本来实现。

    MySQLProxy实际上是在客户端请求与MySQLServer之间建立了一个连接池。所有客户端请求都是发向MySQLProxy,然后经由MySQLProxy进行相应的分析,判断出是读操作还是写操作,分发至对应的MySQLServer上。对于多节点Slave集群,也可以起做到负载均衡的效果。以下是MySQLProxy的基本架构图:

    通过上面的架构简图,我们可以很清晰的看出MySQLProxy在实际应用中所处的位置,以及能做的基本事情。关于MySQLProxy更为详细的实施细则在MySQL官方文档中有非常详细的介绍和示例,感兴趣的读者朋友可以直接从MySQL官方网站免费下载或者在线阅读,我这里就不累述浪费纸张了。

    ★利用Amoeba实现数据切分及整合

    Amoeba是一个基于Java开发的,专注于解决分布式数据库数据源整合Proxy程序的开源框架,基于GPL3开源协议。目前,Amoeba已经具有Query路由,Query过滤,读写分离,负载均衡以及HA机制等相关内容。

    Amoeba 主要解决的以下几个问题:

    1. 数据切分后复杂数据源整合;

    2. 提供数据切分规则并降低数据切分规则给数据库带来的影响;

    3. 降低数据库与客户端的连接数;

    4. 读写分离路由;

    我们可以看出,Amoeba所做的事情,正好就是我们通过数据切分来提升数据库的扩展性所需要的。

    Amoeba并不是一个代理层的Proxy程序,而是一个开发数据库代理层Proxy程序的开发框架,目前基于Amoeba所开发的Proxy程序有AmoebaForMySQL和AmoebaForAladin两个。

    AmoebaForMySQL主要是专门针对MySQL数据库的解决方案,前端应用程序请求的协议以及后端连接的数据源数据库都必须是MySQL。对于客户端的任何应用程序来说,AmoebaForMySQL和一个MySQL数据库没有什么区别,任何使用MySQL协议的客户端请求,都可以被AmoebaForMySQL解析并进行相应的处理。下如可以告诉我们AmoebaForMySQL的架构信息(出自Amoeba开发者博客):

    AmoebaForAladin则是一个适用更为广泛,功能更为强大的Proxy程序。他可以同时连接不同数据库的数据源为前端应用程序提供服务,但是仅仅接受符合MySQL协议的客户端应用程序请求。也就是说,只要前端应用程序通过MySQL协议连接上来之后,AmoebaForAladin会自动分析Query语句,根据Query语句中所请求的数据来自动识别出该所Query的数据源是在什么类型数据库的哪一个物理主机上面。下图展示了AmoebaForAladin的架构细节(出自Amoeba开发者博客):

    咋一看,两者好像完全一样嘛。细看之后,才会发现两者主要的区别仅在于通过MySQLProtocalAdapter处理之后,根据分析结果判断出数据源数据库,然后选择特定的JDBC驱动和相应协议连接后端数据库。

    其实通过上面两个架构图大家可能也已经发现了Amoeba的特点了,他仅仅只是一个开发框架,我们除了选择他已经提供的ForMySQL和ForAladin这两款产品之外,还可以基于自身的需求进行相应的二次开发,得到更适应我们自己应用特点的Proxy程序。

    当对于使用MySQL数据库来说,不论是AmoebaForMySQL还是AmoebaForAladin都可以很好的使用。当然,考虑到任何一个系统越是复杂,其性能肯定就会有一定的损失,维护成本自然也会相对更高一些。所以,对于仅仅需要使用MySQL数据库的时候,我还是建议使用AmoebaForMySQL。

    AmoebaForMySQL的使用非常简单,所有的配置文件都是标准的XML文件,总共有四个配置文件。分别为:

    ◆amoeba.xml:主配置文件,配置所有数据源以及Amoeba自身的参数设置;

    ◆rule.xml:配置所有Query路由规则的信息;

    ◆functionMap.xml:配置用于解析Query中的函数所对应的Java实现类;

    ◆ rullFunctionMap.xml:配置路由规则中需要使用到的特定函数的实现类;

    如果您的规则不是太复杂,基本上仅需要使用到上面四个配置文件中的前面两个就可完成所有工作。Proxy程序常用的功能如读写分离,负载均衡等配置都在amoeba.xml中进行。此外,Amoeba已经支持了实现数据的垂直切分和水平切分的自动路由,路由规则可以在rule.xml进行设置。

    目前Amoeba少有欠缺的主要就是其在线管理功能以及对事务的支持了,曾经在与相关开发者的沟通过程中提出过相关的建议,希望能够提供一个可以进行在线维护管理的命令行管理工具,方便在线维护使用,得到的反馈是管理专门的管理模块已经纳入开发日程了。另外在事务支持方面暂时还是Amoeba无法做到的,即使客户端应用在提交给Amoeba的请求是包含事务信息的,Amoeba也会忽略事务相关信息。当然,在经过不断完善之后,我相信事务支持肯定是Amoeba重点考虑增加的feature。

    关于Amoeba更为详细的使用方法读者朋友可以通过Amoeba开发者博客(http://amoeba.sf.net)上面提供的使用手册获取,这里就不再细述了。

    ★利用HiveDB实现数据切分及整合

    和前面的MySQLProxy以及Amoeba一样,HiveDB同样是一个基于Java针对MySQL数据库的提供数据切分及整合的开源框架,只是目前的HiveDB仅仅支持数据的水平切分。主要解决大数据量下数据库的扩展性及数据的高性能访问问题,同时支持数据的冗余及基本的HA机制。

    HiveDB的实现机制与MySQLProxy和Amoeba有一定的差异,他并不是借助MySQL的Replication功能来实现数据的冗余,而是自行实现了数据冗余机制,而其底层主要是基于HibernateShards来实现的数据切分工作。

    在HiveDB中,通过用户自定义的各种Partitionkeys(其实就是制定数据切分规则),将数据分散到多个MySQLServer中。在访问的时候,在运行Query请求的时候,会自动分析过滤条件,并行从多个MySQLServer中读取数据,并合并结果集返回给客户端应用程序。

    单纯从功能方面来讲,HiveDB可能并不如MySQLProxy和Amoeba那样强大,但是其数据切分的思路与前面二者并无本质差异。此外,HiveDB并不仅仅只是一个开源爱好者所共享的内容,而是存在商业公司支持的开源项目。

    下面是HiveDB官方网站上面一章图片,描述了HiveDB如何来组织数据的基本信息,虽然不能详细的表现出太多架构方面的信息,但是也基本可以展示出其在数据切分方面独特的一面了。

    ★ mycat 数据整合:具体http://www.songwie.com/articlelist/11

    ★ 其他实现数据切分及整合的解决方案

    除了上面介绍的几个数据切分及整合的整体解决方案之外,还存在很多其他同样提供了数据切分与整合的解决方案。如基于MySQLProxy的基础上做了进一步扩展的HSCALE,通过Rails构建的SpockProxy,以及基于Pathon的Pyshards等等。

    不管大家选择使用哪一种解决方案,总体设计思路基本上都不应该会有任何变化,那就是通过数据的垂直和水平切分,增强数据库的整体服务能力,让应用系统的整体扩展能力尽可能的提升,扩展方式尽可能的便捷。

    只要我们通过中间层Proxy应用程序较好的解决了数据切分和数据源整合问题,那么数据库的线性扩展能力将很容易做到像我们的应用程序一样方便,只需要通过添加廉价的PCServer服务器,即可线性增加数据库集群的整体服务能力,让数据库不再轻易成为应用系统的性能瓶颈。

     


    数据切分与整合可能存在的问题

    这里,大家应该对数据切分与整合的实施有了一定的认识了,或许很多读者朋友都已经根据各种解决方案各自特性的优劣基本选定了适合于自己应用场景的方案,后面的工作主要就是实施准备了。

    在实施数据切分方案之前,有些可能存在的问题我们还是需要做一些分析的。一般来说,我们可能遇到的问题主要会有以下几点:

    ◆ 引入分布式事务的问题;

    ◆跨节点Join的问题;

    ◆ 跨节点合并排序分页问题;

     

    1. 引入分布式事务的问题

    一旦数据进行切分被分别存放在多个MySQLServer中之后,不管我们的切分规则设计的多么的完美(实际上并不存在完美的切分规则),都可能造成之前的某些事务所涉及到的数据已经不在同一个MySQLServer中了。

    在这样的场景下,如果我们的应用程序仍然按照老的解决方案,那么势必需要引入分布式事务来解决。而在MySQL各个版本中,只有从MySQL5.0开始以后的各个版本才开始对分布式事务提供支持,而且目前仅有Innodb提供分布式事务支持。不仅如此,即使我们刚好使用了支持分布式事务的MySQL版本,同时也是使用的Innodb存储引擎,分布式事务本身对于系统资源的消耗就是很大的,性能本身也并不是太高。而且引入分布式事务本身在异常处理方面就会带来较多比较难控制的因素。

    怎么办?其实我们可以可以通过一个变通的方法来解决这种问题,首先需要考虑的一件事情就是:是否数据库是唯一一个能够解决事务的地方呢?其实并不是这样的,我们完全可以结合数据库以及应用程序两者来共同解决。各个数据库解决自己身上的事务,然后通过应用程序来控制多个数据库上面的事务。

    也就是说,只要我们愿意,完全可以将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务,并通过应用程序来总控各个小事务。当然,这样作的要求就是我们的俄应用程序必须要有足够的健壮性,当然也会给应用程序带来一些技术难度。

     

    2.跨节点Join的问题

    上面介绍了可能引入分布式事务的问题,现在我们再看看需要跨节点Join的问题。数据切分之后,可能会造成有些老的Join语句无法继续使用,因为Join使用的数据源可能被切分到多个MySQLServer中了。

    怎么办?这个问题从MySQL数据库角度来看,如果非得在数据库端来直接解决的话,恐怕只能通过MySQL一种特殊的存储引擎Federated来解决了。Federated存储引擎是MySQL解决类似于Oracle的DBLink之类问题的解决方案。和OracleDBLink的主要区别在于Federated会保存一份远端表结构的定义信息在本地。咋一看,Federated确实是解决跨节点Join非常好的解决方案。但是我们还应该清楚一点,那就似乎如果远端的表结构发生了变更,本地的表定义信息是不会跟着发生相应变化的。如果在更新远端表结构的时候并没有更新本地的Federated表定义信息,就很可能造成Query运行出错,无法得到正确的结果。

    对待这类问题,我还是推荐通过应用程序来进行处理,先在驱动表所在的MySQLServer中取出相应的驱动结果集,然后根据驱动结果集再到被驱动表所在的MySQLServer中取出相应的数据。可能很多读者朋友会认为这样做对性能会产生一定的影响,是的,确实是会对性能有一定的负面影响,但是除了此法,基本上没有太多其他更好的解决办法了。而且,由于数据库通过较好的扩展之后,每台MySQLServer的负载就可以得到较好的控制,单纯针对单条Query来说,其响应时间可能比不切分之前要提高一些,所以性能方面所带来的负面影响也并不是太大。更何况,类似于这种需要跨节点Join的需求也并不是太多,相对于总体性能而言,可能也只是很小一部分而已。所以为了整体性能的考虑,偶尔牺牲那么一点点,其实是值得的,毕竟系统优化本身就是存在很多取舍和平衡的过程。

     

    3. 跨节点合并排序分页问题

    一旦进行了数据的水平切分之后,可能就并不仅仅只有跨节点Join无法正常运行,有些排序分页的Query语句的数据源可能也会被切分到多个节点,这样造成的直接后果就是这些排序分页Query无法继续正常运行。其实这和跨节点Join是一个道理,数据源存在于多个节点上,要通过一个Query来解决,就和跨节点Join是一样的操作。同样Federated也可以部分解决,当然存在的风险也一样。

    还是同样的问题,怎么办?我同样仍然继续建议通过应用程序来解决。

    如何解决?解决的思路大体上和跨节点Join的解决类似,但是有一点和跨节点Join不太一样,Join很多时候都有一个驱动与被驱动的关系,所以Join本身涉及到的多个表之间的数据读取一般都会存在一个顺序关系。但是排序分页就不太一样了,排序分页的数据源基本上可以说是一个表(或者一个结果集),本身并不存在一个顺序关系,所以在从多个数据源取数据的过程是完全可以并行的。这样,排序分页数据的取数效率我们可以做的比跨库Join更高,所以带来的性能损失相对的要更小,在有些情况下可能比在原来未进行数据切分的数据库中效率更高了。当然,不论是跨节点Join还是跨节点排序分页,都会使我们的应用服务器消耗更多的资源,尤其是内存资源,因为我们在读取访问以及合并结果集的这个过程需要比原来处理更多的数据。

    分析到这里,可能很多读者朋友会发现,上面所有的这些问题,我给出的建议基本上都是通过应用程序来解决。大家可能心里开始犯嘀咕了,是不是因为我是DBA,所以就很多事情都扔给应用架构师和开发人员了?

    其实完全不是这样,首先应用程序由于其特殊性,可以非常容易做到很好的扩展性,但是数据库就不一样,必须借助很多其他的方式才能做到扩展,而且在这个扩展过程中,很难避免带来有些原来在集中式数据库中可以解决但被切分开成一个数据库集群之后就成为一个难题的情况。要想让系统整体得到最大限度的扩展,我们只能让应用程序做更多的事情,来解决数据库集群无法较好解决的问题。

     

    小结

    通过数据切分技术将一个大的MySQLServer切分成多个小的MySQLServer,既解决了写入性能瓶颈问题,同时也再一次提升了整个数据库集群的扩展性。不论是通过垂直切分,还是水平切分,都能够让系统遇到瓶颈的可能性更小。尤其是当我们使用垂直和水平相结合的切分方法之后,理论上将不会再遇到扩展瓶颈了。

    展开全文
  • Mysql数据库切分及整合方案

    千次阅读 2016-06-30 16:17:07
    我们已经很清楚通过数据库的数据切分可以极大的...这一节我们主要针对的内容就是分析可以使用的各种可以帮助我们实现数据切分以及数据整合的整体解决方案。 数据的整合很难依靠数据库本身来达到这个效果,虽然MyS

          我们已经很清楚通过数据库的数据切分可以极大的提高系统的扩展性。但是,数据库中的数据在经过垂直和(或)水平切分被存放在不同的数据库主机之后,应用系统面临的最大问题就是如何来让这些数据源得到较好的整合,可能这也是很多读者朋友非常关心的一个问题。这一节我们主要针对的内容就是分析可以使用的各种可以帮助我们实现数据切分以及数据整合的整体解决方案。

    数据的整合很难依靠数据库本身来达到这个效果,虽然MySQL存在Federated存储引擎,可以解决部分类似的问题,但是在实际应用场景中却很难较好的运用。那我们该如何来整合这些分散在各个MySQL主机上面的数据源呢?

    总的来说,存在两种解决思路:

    1. 在每个应用程序模块中配置管理自己需要的一个(或者多个)数据源,直接访问各个数据库,在模块内完成数据的整合;

    2. 通过中间代理层来统一管理所有的数据源,后端数据库集群对前端应用程序透明;

    可能90%以上的人在面对上面这两种解决思路的时候都会倾向于选择第二种,尤其是系统不断变得庞大复杂的时候。确实,这是一个非常正确的选择,虽然短期内需要付出的成本可能会相对更大一些,但是对整个系统的扩展性来说,是非常有帮助的。

    所以,对于第一种解决思路我这里就不准备过多的分析,下面我重点分析一下在第二种解决思路中的一些解决方案。

    ★ 自行开发中间代理层

    在决定选择通过数据库的中间代理层来解决数据源整合的架构方向之后,有不少公司(或者企业)选择了通过自行开发符合自身应用特定场景的代理层应用程序。

    通过自行开发中间代理层可以最大程度的应对自身应用的特定,最大化的定制很多个性化需求,在面对变化的时候也可以灵活的应对。这应该说是自行开发代理层最大的优势了。

    当然,选择自行开发,享受让个性化定制最大化的乐趣的同时,自然也需要投入更多的成本来进行前期研发以及后期的持续升级改进工作,而且本身的技术门槛可能也比简单的Web应用要更高一些。所以,在决定选择自行开发之前,还是需要进行比较全面的评估为好。

    由于自行开发更多时候考虑的是如何更好的适应自身应用系统,应对自身的业务场景,所以这里也不好分析太多。后面我们主要分析一下当前比较流行的几种数据源整合解决方案。

    ★利用MySQLProxy实现数据切分及整合

    MySQLProxy是MySQL官方提供的一个数据库代理层产品,和MySQLServer一样,同样是一个基于GPL开源协议的开源产品。可用来监视、分析或者传输他们之间的通讯信息。他的灵活性允许你最大限度的使用它,目前具备的功能主要有连接路由,Query分析,Query过滤和修改,负载均衡,以及基本的HA机制等。

    实际上,MySQLProxy本身并不具有上述所有的这些功能,而是提供了实现上述功能的基础。要实现这些功能,还需要通过我们自行编写LUA脚本来实现。

    MySQLProxy实际上是在客户端请求与MySQLServer之间建立了一个连接池。所有客户端请求都是发向MySQLProxy,然后经由MySQLProxy进行相应的分析,判断出是读操作还是写操作,分发至对应的MySQLServer上。对于多节点Slave集群,也可以起做到负载均衡的效果。以下是MySQLProxy的基本架构图:

    通过上面的架构简图,我们可以很清晰的看出MySQLProxy在实际应用中所处的位置,以及能做的基本事情。关于MySQLProxy更为详细的实施细则在MySQL官方文档中有非常详细的介绍和示例,感兴趣的读者朋友可以直接从MySQL官方网站免费下载或者在线阅读,我这里就不累述浪费纸张了。

    ★利用Amoeba实现数据切分及整合

    Amoeba是一个基于Java开发的,专注于解决分布式数据库数据源整合Proxy程序的开源框架,基于GPL3开源协议。目前,Amoeba已经具有Query路由,Query过滤,读写分离,负载均衡以及HA机制等相关内容。

    Amoeba 主要解决的以下几个问题:

    1. 数据切分后复杂数据源整合;

    2. 提供数据切分规则并降低数据切分规则给数据库带来的影响;

    3. 降低数据库与客户端的连接数;

    4. 读写分离路由;

    我们可以看出,Amoeba所做的事情,正好就是我们通过数据切分来提升数据库的扩展性所需要的。

    Amoeba并不是一个代理层的Proxy程序,而是一个开发数据库代理层Proxy程序的开发框架,目前基于Amoeba所开发的Proxy程序有AmoebaForMySQL和AmoebaForAladin两个。

    AmoebaForMySQL主要是专门针对MySQL数据库的解决方案,前端应用程序请求的协议以及后端连接的数据源数据库都必须是MySQL。对于客户端的任何应用程序来说,AmoebaForMySQL和一个MySQL数据库没有什么区别,任何使用MySQL协议的客户端请求,都可以被AmoebaForMySQL解析并进行相应的处理。下如可以告诉我们AmoebaForMySQL的架构信息(出自Amoeba开发者博客):

    AmoebaForAladin则是一个适用更为广泛,功能更为强大的Proxy程序。他可以同时连接不同数据库的数据源为前端应用程序提供服务,但是仅仅接受符合MySQL协议的客户端应用程序请求。也就是说,只要前端应用程序通过MySQL协议连接上来之后,AmoebaForAladin会自动分析Query语句,根据Query语句中所请求的数据来自动识别出该所Query的数据源是在什么类型数据库的哪一个物理主机上面。下图展示了AmoebaForAladin的架构细节(出自Amoeba开发者博客):

    咋一看,两者好像完全一样嘛。细看之后,才会发现两者主要的区别仅在于通过MySQLProtocalAdapter处理之后,根据分析结果判断出数据源数据库,然后选择特定的JDBC驱动和相应协议连接后端数据库。

    其实通过上面两个架构图大家可能也已经发现了Amoeba的特点了,他仅仅只是一个开发框架,我们除了选择他已经提供的ForMySQL和ForAladin这两款产品之外,还可以基于自身的需求进行相应的二次开发,得到更适应我们自己应用特点的Proxy程序。

    当对于使用MySQL数据库来说,不论是AmoebaForMySQL还是AmoebaForAladin都可以很好的使用。当然,考虑到任何一个系统越是复杂,其性能肯定就会有一定的损失,维护成本自然也会相对更高一些。所以,对于仅仅需要使用MySQL数据库的时候,我还是建议使用AmoebaForMySQL。

    AmoebaForMySQL的使用非常简单,所有的配置文件都是标准的XML文件,总共有四个配置文件。分别为:

    ◆amoeba.xml:主配置文件,配置所有数据源以及Amoeba自身的参数设置;

    ◆rule.xml:配置所有Query路由规则的信息;

    ◆functionMap.xml:配置用于解析Query中的函数所对应的Java实现类;

    ◆ rullFunctionMap.xml:配置路由规则中需要使用到的特定函数的实现类;

    如果您的规则不是太复杂,基本上仅需要使用到上面四个配置文件中的前面两个就可完成所有工作。Proxy程序常用的功能如读写分离,负载均衡等配置都在amoeba.xml中进行。此外,Amoeba已经支持了实现数据的垂直切分和水平切分的自动路由,路由规则可以在rule.xml进行设置。

    目前Amoeba少有欠缺的主要就是其在线管理功能以及对事务的支持了,曾经在与相关开发者的沟通过程中提出过相关的建议,希望能够提供一个可以进行在线维护管理的命令行管理工具,方便在线维护使用,得到的反馈是管理专门的管理模块已经纳入开发日程了。另外在事务支持方面暂时还是Amoeba无法做到的,即使客户端应用在提交给Amoeba的请求是包含事务信息的,Amoeba也会忽略事务相关信息。当然,在经过不断完善之后,我相信事务支持肯定是Amoeba重点考虑增加的feature。

    关于Amoeba更为详细的使用方法读者朋友可以通过Amoeba开发者博客(http://amoeba.sf.net)上面提供的使用手册获取,这里就不再细述了。

    ★利用HiveDB实现数据切分及整合

    和前面的MySQLProxy以及Amoeba一样,HiveDB同样是一个基于Java针对MySQL数据库的提供数据切分及整合的开源框架,只是目前的HiveDB仅仅支持数据的水平切分。主要解决大数据量下数据库的扩展性及数据的高性能访问问题,同时支持数据的冗余及基本的HA机制。

    HiveDB的实现机制与MySQLProxy和Amoeba有一定的差异,他并不是借助MySQL的Replication功能来实现数据的冗余,而是自行实现了数据冗余机制,而其底层主要是基于HibernateShards来实现的数据切分工作。

    在HiveDB中,通过用户自定义的各种Partitionkeys(其实就是制定数据切分规则),将数据分散到多个MySQLServer中。在访问的时候,在运行Query请求的时候,会自动分析过滤条件,并行从多个MySQLServer中读取数据,并合并结果集返回给客户端应用程序。

    单纯从功能方面来讲,HiveDB可能并不如MySQLProxy和Amoeba那样强大,但是其数据切分的思路与前面二者并无本质差异。此外,HiveDB并不仅仅只是一个开源爱好者所共享的内容,而是存在商业公司支持的开源项目。

    下面是HiveDB官方网站上面一章图片,描述了HiveDB如何来组织数据的基本信息,虽然不能详细的表现出太多架构方面的信息,但是也基本可以展示出其在数据切分方面独特的一面了。

    ★ mycat 数据整合:具体http://www.songwie.com/articlelist/11

    ★ 其他实现数据切分及整合的解决方案

    除了上面介绍的几个数据切分及整合的整体解决方案之外,还存在很多其他同样提供了数据切分与整合的解决方案。如基于MySQLProxy的基础上做了进一步扩展的HSCALE,通过Rails构建的SpockProxy,以及基于Pathon的Pyshards等等。

    不管大家选择使用哪一种解决方案,总体设计思路基本上都不应该会有任何变化,那就是通过数据的垂直和水平切分,增强数据库的整体服务能力,让应用系统的整体扩展能力尽可能的提升,扩展方式尽可能的便捷。

    只要我们通过中间层Proxy应用程序较好的解决了数据切分和数据源整合问题,那么数据库的线性扩展能力将很容易做到像我们的应用程序一样方便,只需要通过添加廉价的PCServer服务器,即可线性增加数据库集群的整体服务能力,让数据库不再轻易成为应用系统的性能瓶颈。

     


    数据切分与整合可能存在的问题

    这里,大家应该对数据切分与整合的实施有了一定的认识了,或许很多读者朋友都已经根据各种解决方案各自特性的优劣基本选定了适合于自己应用场景的方案,后面的工作主要就是实施准备了。

    在实施数据切分方案之前,有些可能存在的问题我们还是需要做一些分析的。一般来说,我们可能遇到的问题主要会有以下几点:

    ◆ 引入分布式事务的问题;

    ◆跨节点Join的问题;

    ◆ 跨节点合并排序分页问题;

     

    1. 引入分布式事务的问题

    一旦数据进行切分被分别存放在多个MySQLServer中之后,不管我们的切分规则设计的多么的完美(实际上并不存在完美的切分规则),都可能造成之前的某些事务所涉及到的数据已经不在同一个MySQLServer中了。

    在这样的场景下,如果我们的应用程序仍然按照老的解决方案,那么势必需要引入分布式事务来解决。而在MySQL各个版本中,只有从MySQL5.0开始以后的各个版本才开始对分布式事务提供支持,而且目前仅有Innodb提供分布式事务支持。不仅如此,即使我们刚好使用了支持分布式事务的MySQL版本,同时也是使用的Innodb存储引擎,分布式事务本身对于系统资源的消耗就是很大的,性能本身也并不是太高。而且引入分布式事务本身在异常处理方面就会带来较多比较难控制的因素。

    怎么办?其实我们可以可以通过一个变通的方法来解决这种问题,首先需要考虑的一件事情就是:是否数据库是唯一一个能够解决事务的地方呢?其实并不是这样的,我们完全可以结合数据库以及应用程序两者来共同解决。各个数据库解决自己身上的事务,然后通过应用程序来控制多个数据库上面的事务。

    也就是说,只要我们愿意,完全可以将一个跨多个数据库的分布式事务分拆成多个仅处于单个数据库上面的小事务,并通过应用程序来总控各个小事务。当然,这样作的要求就是我们的俄应用程序必须要有足够的健壮性,当然也会给应用程序带来一些技术难度。

     

    2.跨节点Join的问题

    上面介绍了可能引入分布式事务的问题,现在我们再看看需要跨节点Join的问题。数据切分之后,可能会造成有些老的Join语句无法继续使用,因为Join使用的数据源可能被切分到多个MySQLServer中了。

    怎么办?这个问题从MySQL数据库角度来看,如果非得在数据库端来直接解决的话,恐怕只能通过MySQL一种特殊的存储引擎Federated来解决了。Federated存储引擎是MySQL解决类似于Oracle的DBLink之类问题的解决方案。和OracleDBLink的主要区别在于Federated会保存一份远端表结构的定义信息在本地。咋一看,Federated确实是解决跨节点Join非常好的解决方案。但是我们还应该清楚一点,那就似乎如果远端的表结构发生了变更,本地的表定义信息是不会跟着发生相应变化的。如果在更新远端表结构的时候并没有更新本地的Federated表定义信息,就很可能造成Query运行出错,无法得到正确的结果。

    对待这类问题,我还是推荐通过应用程序来进行处理,先在驱动表所在的MySQLServer中取出相应的驱动结果集,然后根据驱动结果集再到被驱动表所在的MySQLServer中取出相应的数据。可能很多读者朋友会认为这样做对性能会产生一定的影响,是的,确实是会对性能有一定的负面影响,但是除了此法,基本上没有太多其他更好的解决办法了。而且,由于数据库通过较好的扩展之后,每台MySQLServer的负载就可以得到较好的控制,单纯针对单条Query来说,其响应时间可能比不切分之前要提高一些,所以性能方面所带来的负面影响也并不是太大。更何况,类似于这种需要跨节点Join的需求也并不是太多,相对于总体性能而言,可能也只是很小一部分而已。所以为了整体性能的考虑,偶尔牺牲那么一点点,其实是值得的,毕竟系统优化本身就是存在很多取舍和平衡的过程。

     

    3. 跨节点合并排序分页问题

    一旦进行了数据的水平切分之后,可能就并不仅仅只有跨节点Join无法正常运行,有些排序分页的Query语句的数据源可能也会被切分到多个节点,这样造成的直接后果就是这些排序分页Query无法继续正常运行。其实这和跨节点Join是一个道理,数据源存在于多个节点上,要通过一个Query来解决,就和跨节点Join是一样的操作。同样Federated也可以部分解决,当然存在的风险也一样。

    还是同样的问题,怎么办?我同样仍然继续建议通过应用程序来解决。

    如何解决?解决的思路大体上和跨节点Join的解决类似,但是有一点和跨节点Join不太一样,Join很多时候都有一个驱动与被驱动的关系,所以Join本身涉及到的多个表之间的数据读取一般都会存在一个顺序关系。但是排序分页就不太一样了,排序分页的数据源基本上可以说是一个表(或者一个结果集),本身并不存在一个顺序关系,所以在从多个数据源取数据的过程是完全可以并行的。这样,排序分页数据的取数效率我们可以做的比跨库Join更高,所以带来的性能损失相对的要更小,在有些情况下可能比在原来未进行数据切分的数据库中效率更高了。当然,不论是跨节点Join还是跨节点排序分页,都会使我们的应用服务器消耗更多的资源,尤其是内存资源,因为我们在读取访问以及合并结果集的这个过程需要比原来处理更多的数据。

    分析到这里,可能很多读者朋友会发现,上面所有的这些问题,我给出的建议基本上都是通过应用程序来解决。大家可能心里开始犯嘀咕了,是不是因为我是DBA,所以就很多事情都扔给应用架构师和开发人员了?

    其实完全不是这样,首先应用程序由于其特殊性,可以非常容易做到很好的扩展性,但是数据库就不一样,必须借助很多其他的方式才能做到扩展,而且在这个扩展过程中,很难避免带来有些原来在集中式数据库中可以解决但被切分开成一个数据库集群之后就成为一个难题的情况。要想让系统整体得到最大限度的扩展,我们只能让应用程序做更多的事情,来解决数据库集群无法较好解决的问题。

     

    小结

    通过数据切分技术将一个大的MySQLServer切分成多个小的MySQLServer,既解决了写入性能瓶颈问题,同时也再一次提升了整个数据库集群的扩展性。不论是通过垂直切分,还是水平切分,都能够让系统遇到瓶颈的可能性更小。尤其是当我们使用垂直和水平相结合的切分方法之后,理论上将不会再遇到扩展瓶颈了。

     

    展开全文
  • 水务信息化数据整合系统方案分析

    千次阅读 2009-01-05 15:42:00
    本文从水务信息化整合可能要设及到的整合内容入手,设计了整合方案,并指出系统整合中的难点及解决方法,给出了水务信息化数据整合系统实现模拟图。 文章来源:信息化建设 作者:张效刚 马中文 
  • 公安警务综合系统业务整合解决方案 随着“金盾工程”建设的进展,公安系统建立的业务信息应用系统数量很多,如何才能够让这些系统在公安工作中发挥出更大的效益,更进一步促进公安实际工作,已经逐渐引起大家更大的...
  • 另外元数据管理系统需要将服务作为一类元数据管理起来,以便运维人员查看基于服务的数据流向; 3) 服务生成模块 该模块提供服务生成管理界面,展示元数据系统获取的数据源表结构和字段信息,管理...
  • UCenter作为整合用户的这样一个开源插件,对于PHP开发的,甚至其它开发语言如.net,java.asp等开发人员解决多个项目整合到一起,用户进行同步登录,同步退出等,同步消息等都是非常有用的。下面分享下以前整合项目中...
  • BEA方案的实施架构有七层,其中应用的应用逻辑和功能的开发占两层,分别是应用功能服务层和应用数据存访层,它们对应于传统的多层Web应用构架中的功能逻辑层和数据存访层。而多层Web应用构架中的Web展现层则被展开成...
  • 如今信息化普及情况下,信息系统越来越庞大、复杂,早期的内容需要整合到统一平台上,采用“发烧级的”云技术架构,这时,人员跨部门、虚拟团队的解决方案就比较突出了,如何解决更合理呢? 使用多租户技术的解决...
  • springboot整合swagger

    千次阅读 2018-11-05 10:26:46
    但是目前公司的项目,后端接口需要通过postman来完成,而且手动维护api文档,徒增后端开发人员的时间成本,而且手动维护出错概率大,会造成前后端时间成本增加。借鉴上家公司的方案,希望改善这一部分的不足。关于...
  • 整合”兼具统一、合并、沟通和集成的性质选择资源分配方案、平衡相互竞争的目标和方案,以及管理项目管理知识领域之间的依赖关系。当过程之间发生相互作用时,项目整合管理就显得非常必要。在项目管理过程组的各...
  • 项目整合管理

    千次阅读 2008-12-08 23:02:00
    项目整合管理就是为满足各方需求而进行协调以达到预期目的的过程。它是一项综合性、全局性的工作,主要内容是在相互冲突的目标或可选择的目标中权衡得失。虽然所有的项目管理过程在某种程度上都可看成是一个整体,但...
  • 更重要的是资源的整合——把众多的、方方面面的资源,组合起来做成一件事! 作为一名普通的职业经理人,没有显赫的背景可以利用、没有大笔的资金可供调动,我们能做的,更多是依靠自己的智慧,完成
  •  ECMBoss项目的开发人员并不是在项目开始之初,就全部立即到位的,而是根据不同开发阶段,不同模块的业务需求,不同职能的开发人员在适合的时机进入项目,一方面节省项目资金,另一方面也便于项目的管理。...
  • Spring boot Mybatis 整合(注解版)

    万次阅读 多人点赞 2017-11-24 10:39:57
    之前写过一篇关于springboot 与 mybatis整合的博文,使用了一段时间spring-data-jpa,发现那种方式真的是太爽了,mybatis的xml的映射配置总觉得有点麻烦。接口定义和映射离散在不同的文件中,阅读起来不是很方便。...
  • 本群专注于海思方案的技术交流以及海思产品项目立项评估交流,旨在为大家提供一个清爽干净的技术交流环境,整合产业链优质的供需资源,及为行业发展方向提供最新的讨论话题。适合做IT研发,产品经理,及产业链供应商...
  • Spring整合velocity

    千次阅读 2013-09-06 10:16:16
    Spring整合velocity 使用Velocity模板 Velocity是一种针对Java应用的易用的模板语言。Velocity模板中没有任何 Java代码,这使得它能够同时被非开发人员和开发人员轻松地理解。Velocity的用户手册上是这么说...
  • 阿里Java面经大全(整合版)

    万次阅读 多人点赞 2018-08-03 16:10:12
    关于Java,1只回答了使用remove方法,第2题没明白在问什么,第4题说不会,第6题不会,第7题不会, 算法题,只大致说了思路,从最高位开始递归,但是我一开始讲的太乱了,对方听不下去了最后让我举个例子1024中2的...
  • Mentor面向智能家居的IoT方案

    万次阅读 多人点赞 2018-08-27 07:00:00
    目前有各种智能家居的自动化解决方案,但其中大多数缺乏将已存在的家庭环境和安全无缝整合的潜力。为了弥合消费者和技术之间的差距,同时允许在不对建筑进行改造的情况下融入任何现有的家庭环境,需要一个具有无缝...
  • 千万数据的分库分表方案

    万次阅读 2018-07-24 01:21:22
    这是项目中有一定量级的数据或用户,都会遇到的一个...常用的切分方案 数据的切分(Sharding)根据其切分规则的类型,可以分为两种切分模式。一种是按照不同的表(或者Schema)来切分到不同的数据库(主机)之上,...
  • 技术路线一定是与核心技术有关的...关于技术路线与实施方案问题,打一个不一定恰当的比方.项目要求是走陆路从马尔康到北京.打开互联网一查公路与铁路分布看.从马尔康到成都经西安-郑州北上可到北京;从马尔康到成都...
  • gulp+webpack工具整合简介

    万次阅读 2017-01-03 14:08:48
    由于webpack会把所有的js都打包到一个js文件中,这样就不方便开发人员debug,故需要进行sourcemap的配置: devtool: (isProduct ? false : 'source-map' ) 加载器loader js加载器: { test: ...
  • Shiro权限控制+整合shiro

    万次阅读 多人点赞 2019-03-02 13:17:56
    特点:为每个人单独的分配权限模块,能够实现权限控制,但是当公司人员庞大之后,非常难管理 上述权限控制如何设计表? 关系:员工和菜单权限的关系:多对多 员工id 菜单名称 1 取派管理 2 快递员管理 2...
  • Kylin, Mondrian, Saiku系统的整合

    千次阅读 2016-06-13 10:12:06
    ...本文主要介绍有赞数据团队为了...这个工具对Kylin,Mondrian以及Saiku做了一个整合,主要工作包括一些定制化的修改以及环境的配置。 目前这个系统还处于一个需要优化、完善的过程,这篇博文也会相应地更新。
  • 房地产行业商业智能解决方案分享

    千次阅读 多人点赞 2016-03-23 11:24:26
    房地产行业需要在有限的资源下对全国区域范围内的多个项目做出科学的决策,以及进行合理地资源平衡,这是一项非常复杂信息化...部署商业智能系统可以帮助企业将数据处理的工作重点从原本的数据整合转移到数据分析上来。
  • 为了满足市场需求,从人员成长、技术能力乃至开源软件的专业认证上,联想正在一步步不断的打造并加强自身的整合能力。目前,联想在软件开发方面已在全球部署了数千名开发人员,现已将联想平台产品基于混合云的部署...
  • 云计算的应用解决方案

    千次阅读 2016-01-05 16:21:14
    这个体系结构如图3所示,它概括了不同解决方案的主要特征,每一种方案或许只实现了其中部分功能,或许也还有部分相对次要功能尚未概括进来。   图1 云计算技术体系结构   云计算技术体系结构分为4...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 99,389
精华内容 39,755
关键字:

关于人员整合方案