精华内容
下载资源
问答
  • 2018-04-03 10:28:28
    本文分析了ERP企业管理系统和CRM客户关系管理系统的功能重叠之处,详细提出了ERP企业管理系统与CRM客户关系管理系统整合的业务方案设计、技术方案设计、方案的实施规划。
      1 、对管理软件系统和数据库的调整要求
      从软件功能和数据结构上讲,ERP企业管理系统与CRM客户关系管理系统的整合部分主要体现在它们之间的交叉与重叠处:
      (1)客户管理:ERP企业管理系统与CRM客户关系管理系统都需要客户的基本信息,而且ERP管理系统还应该可以查询客户同企业的交往史而CRM管理系统的服务模块不仅要可以查询查询客户同企业的交往史,还可以查询客户的服务史;
      (2)产品管理:ERP企业管理系统与CRM客户关系管理系统都要用到产品的基本信息、产品的BOM表、产品的客户化配置和报价等;
      (3)工作流管理:ERP企业管理系统与CRM客户关系管理系统中虽都有工作流管理,但两者的工作方式是一样的,但是ERP和CRM涉及的领域不尽相同:CRM客户关系管理系统主要涉及市场、客户,其工作流围绕客户,ERP企业管理系统则更多涉及生产、制造和供应,企业可以对其加以控制;
      (4)工作人员管理:ERP企业管理系统与CRM客户关系管理系统都要涉及企业员工的基本状况和工作安排情况,但CRM系统管理的范围显然要小得多,而ERP系统则对人力资源作出相对全面的管理;
      (5)营销管理:ERP管理系统的营销主要是简单地提供一些市场资料和营销资料,相对来讲比较简单,而CRM管理系统则提供了相当完善的营销管理功能,特别是强调一对一的营销思想;
      (6)销售管理:CRM系统在销售管理方面强调的是过程,讲究机会管理、一对一管理和联系人管理等,而ERP系统中更多地强调结果,讲究销售计划和销售成绩等;
      (7)客户服务和支持:ERP系统只提供简单的客户投诉记录及其解决情况,没有就客户服务和支持作全面的管理,而CRM则实现了这种全面管理,尤其强调客户关怀;
      (8)订单管理:ERP企业管理系统与CRM客户关系管理系统都有订单管理,两者可以说是完全重叠的,不过这种重叠是建立在企业的ERP之上的,因为订单是生产计划的输入变量;
      (9)信息交流:信息交流如同一般的报表,CRM与ERP系统的很多使用者都需要查询对方系统中的一般信息。根据以上对于ERP和CRM系统功能模块的分析,本着强项功能合并的原则,对两者进行整合,即重叠的功能模块应以功能强大的一方为覆盖方,交叉的功能模块则应根据业务流程需要进行梳理、融合,以提高整体功能。
    更多相关内容
  • XX物流整合方案报告

    2020-12-20 20:22:20
    这一款整理发布的XX物流整合方案报告,适合超市管理人员学习参考超市管理分类中的XX物流整合方...该文档为XX物流整合方案报告,是一份很不错的参考资料,具有较高参考价值,感兴趣的可以下载看看
  • 电子制造业企业借助IBM人员整合与协作解决方案,企业可以构建一个统一的、动态的工作环境,实现不同人员之间的互动,包括员工之间、上下级之间以及跨部门之间的协作,在提高工作效率的同时,改善人员之间的关系。
  • 如何能在众多的系统中应付突发的故障,把分散的数据资源合理利用,增加银行服务业务,针对银行省级分行前置系统的现状,该银行确定了基于IBM x440+FAStT700+VMware进行系统整合方案,将10至20个原有中小系统整合到...
  • IBM 存储整合解决方案

    2020-07-08 16:24:50
    IBM 存储整合解决方案利用公共的技术人员、磁盘和磁带资源,按同一道程序对所有的集中化数据进行管理,并通过简单地使用工作控制语言(JCL),可以方便地访问不同平台中的数据拷贝。
  • 这一款整理发布的圣诞、元旦、春节整合营销方案,适合超市管理人员学习参考超市管理分类中的圣...该文档为圣诞、元旦、春节整合营销方案,是一份很不错的参考资料,具有较高参考价值,感兴趣的可以下载看看
  • 这一款整理发布的斯米克时尚陶瓷超市开业整合策划方案,适合超市管理人员学习参考超市管理分类...该文档为斯米克时尚陶瓷超市开业整合策划方案,是一份很不错的参考资料,具有较高参考价值,感兴趣的可以下载看看
  • 医院网络营销整合方案适用于国内各类医院的网络营销人员,有效解决医院网络营销问题。
  • 新老系统迁移及整合方案

    千次阅读 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、数据质量测试是非常重要的一个环节。

    展开全文
  • 建设原则: 整体设计,突出重点 I统筹规划,分步实施 整合资源,协同共享 水务创新,务实高效 优化机制,统一标准 增强保障,要见成效 ...借助信息化手段,提升全市水务人员的业务水平,构筑有效的工作评价体系
  • 4.1.11 人员培训计划、技术转移方案 216 4.1.11.1. 培训方案 216 4.1.11.1.1. 培训对象和内容 216 4.1.11.1.2. 培训目的 217 4.1.11.1.3. 培训原则与培训质量保证体系 218 (1) 培训的师资力量 219 4.1....
  • 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。大致的架构图如下:





    展开全文
  • 许多部门开展专网视频直播系统实施研讨会,并提出了可行性的专业高清视频会议解决方案,并且需要支持专网部署的网络视频会议软件。 专网视频会议系统拓扑图 目前,5G专网具有大宽带、广连接、低延时、高安全性的...

    许多部门开展专网视频直播系统实施研讨会,并提出了可行性的专业高清视频会议解决方案,并且需要支持专网部署的网络视频会议软件。

    专网视频会议系统拓扑图

    专网视频会议系统拓扑图

    目前,5G专网具有大宽带、广连接、低延时、高安全性的优势。同时,5G专网可以与现有的IT网络兼容互通,满足部署区域化、网络需求个性化、行业应用场景化的特点。5G融合部署缩短建设周期、降低成本,这对于企业来说是一个利好的消息。

    软硬一体兼容性好

    部队专网视频会议对安全性要求极高,视频会议系统部署在部队专网,它与互联网在物理上完全隔离。可以很好的保障军事信息的安全。采用连通宝软硬一体专网视频会议解决方案,不会因为软硬设备不兼容让会议效果大打折扣,专网内实现的视频会议更加稳定流畅。

    互动直播模式适合推广

    同时,软硬一体的专网视频会议系统互动性功能更丰富,互动直播模式无需终端投入,更容易扩大覆盖面,所以是比较适合整个部队系统进行推广,保障了专网视频会议的实时性和远程多方协同能力。

    专网视频会议直播系统功能丰富

    采用软硬一体专网视频会议系统培训,不仅可以保证画质清晰度,还可以保证整个培训会议的流畅性,也支持音视频互动、电子白板、实现局域网桌面共享、同屏批注、文档共享非常适合各种专网内的培训。

    终端投入以及扩容成本低

    专网视频会议系统平台建设成本降低,与硬件视频会议相比投入会更低,在费用方面适合大面积推广,增加人员,只需要再次购买授权就可以。
    安全性
    最后一点是最为重要的部队专网部署的视频会议直播系统,最重要的就是安全性,连通宝专网视频会议解决方案做到从访问到传输双层安全防护,能够保障军事信息的安全性。

    展开全文
  • CDP营销方案 不仅仅是数据整合

    千次阅读 2022-03-15 14:55:58
    传统的数据备份解决方案专注在对数据的周期性备份上,因此一直伴随有备份窗口、数据一致性以及对生产系统的影响等问题。 这是百度百科对CDP的定义,这对中国的企业来说应该还是一个新的概念,对它的了解,并不深入...
  • Mysql数据库切分及整合方案

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

    2018-07-31 14:43:27
    最新的安防智能管理方案,多平台整合,监控流量 人员定位 婴儿看护 ICU接入 消费演练 给排水 气体检测 等第三方接入
  • 数据切分及整合方案

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

    2020-03-04 08:52:08
    IBM 的Rational解决方案(包括为架构师、开发人员、测试人员和项目经理准备的新产品)将整个开发团队都整合到Eclipse架构上来,并实现了企业内部业务、开发和运行的紧密衔接,使其成为目前端到端软件开发中可用的第...
  • 03-微服务架构及解决方案

    万次阅读 多人点赞 2021-07-08 18:07:22
    所谓单体应用一般是基于idea/eclipse,maven等建一个工程,然后基于SpringBoot,spring,mybatis框架进行整合,接下来再写一堆dao、mapper、service、controller,再加上一些的配置文件,有可能还会引入redis、...
  • SpringBoot是企业级开发的整体整合解决方案,特别用于快速构建微服务应用,旨在用简单的方式让开发人员适应各种开发场景; 本视频着重介绍SpringBoot的使用和内部原理;内容包含微服务概念、配置文件、日志框架的...
  • 另外元数据管理系统需要将服务作为一类元数据管理起来,以便运维人员查看基于服务的数据流向; 3) 服务生成模块 该模块提供服务生成管理界面,展示元数据系统获取的数据源表结构和字段信息,管理...
  • SpringBoot是企业级开发的整体整合解决方案,特别用于快速构建微服务应用,旨在用最简单的方式让开发人员适应各种开发场景。 SpringBoot全套视频分为上下两部;本视频《SpringBoot高级》属于下部,着重介绍...
  • 上海臻图信息将运用数字孪生技术,结合物联网、地理信息、云计算等平台,有针对性的对公交行业内的车辆、站点/站场、指挥调度管理业务的需求,设计一套完整的端与端之间的三维可视化系统解决方案,实现“可视、可控...
  • 2014年起,“大数据”概念首次被正式写入...然而,初涉数据领域的教育行业同时也面临着相当大的难题,还需要更加体系和全面的解决方案。 教育行业信息化现状 现如今,大多数高校的信息化建设已经得到全面发展...
  • 项目管理第四章项目整合管理

    千次阅读 2020-09-05 19:45:12
    项目整合管理包括以下选择:资源分配,平衡竞争需求,研究各种备选方案,为实现项目目标而在建过程,管理各个项目知识领域之间的依赖关系。 项目整合管理子过程: 制定项目章程:编写一份正式批准项目并授权项目...
  • Springboot整合flink过程思考

    千次阅读 2021-12-10 16:32:44
    本人不是专业的后端开发,以下只代表个人看法,如有问题请指出。 目标 希望将flink的开发变成和Springboot注解开发一样,提高开发效率...解决方案一 不使用@Autowired 而且在open中通过getBean()获取对应的实例,但是这
  • 整合”兼具统一、合并、沟通和集成的性质选择资源分配方案、平衡相互竞争的目标和方案,以及管理项目管理知识领域之间的依赖关系。当过程之间发生相互作用时,项目整合管理就显得非常必要。在项目管理过程组的各...
  • 千万数据的分库分表方案

    万次阅读 2018-07-24 01:21:22
    这是项目中有一定量级的数据或用户,都会遇到的一个...常用的切分方案 数据的切分(Sharding)根据其切分规则的类型,可以分为两种切分模式。一种是按照不同的表(或者Schema)来切分到不同的数据库(主机)之上,...
  • 为了满足市场需求,从人员成长、技术能力乃至开源软件的专业认证上,联想正在一步步不断的打造并加强自身的整合能力。目前,联想在软件开发方面已在全球部署了数千名开发人员,现已将联想平台产品基于混合云的部署...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 112,638
精华内容 45,055
关键字:

关于人员整合方案