RealSync & Quest SharePlex 技术对比

http://blogold.chinaunix.net/u3/115561/showart_2249177.html

 

RealSync & Quest SharePlex 技术对比

DSG RealSync Quest SharePlex 公司概况： DSG中国于2002年8月在北京成立，目前总部在北京，员工60余人，在上海/广州/成都设有办事处，公司定位是数据安全和信息生命周期管理。 DSG是一个高速稳定发展的高科技公司，截至08年12月份就在中国市场拥有100多家高端用户，分布在数据量大的电信行业、安全性高的证券行业、环境复杂的政府行业。. DSG公司有一款数据复制产品Realsync与Quest公司的Shareplex是有竞争的。目前DSG该款产品在中国的客户数量是QUEST的3倍以上，装机数量更是远远高于QUEST公司。 l         产品成熟度 DSG Realsync的产品稳定成熟，且随着案例用户的增多，功能不断的增强，现在DSG为用户提供的不仅仅是一款工具，而是一个全面完善的客户化的解决方案，所以Realsync产品在中国的客户数量远多于QUEST公司，而Shareplex如果继续走工具提供的方式，用户将越来越少，市场会进一步萎缩。 l         支持服务 DSG为客户提供的都是原厂的专业服务，目前在上海/广州/成都设有的办事处，能够最有效的为全国用户提供直接服务。   Quest Software的业务方向是以数据库监控、调优和管理类的工具为主的，Shareplex仅仅是其中的一款小工具。 Quest中国是QUEST在中国的代理商易虹天地的基础上建立起来，目前该公司还是以前的服务团队，无法得到总部的有效支持，且国内人员对Shareplex产品熟悉并掌握的人员不超过3个工程师，这在国内的长江证券、杭州电信等项目中都得到体现。 l         产品成熟度 Shareplex的定位是工具产品的提供，因此功能固化单一，在简单环境下运行比较稳定，但在复杂环境下、或特殊功能要求下就无法满足用户的需求，这也是Shareplex在中国的证券行业一直没有案例、在海关总署、浙江省电信、贵州省联通等若干重大项目中遭遇退货的原因所在。 l         支持服务 Quest在中国的支持工程师数量很少，无法有效响应客户的服务；且在国内没有研发支持，无法实质性的响应客户。   案例情况： Realsync数据复制容灾应用     ●    电信行业：北京移动、广西移动、甘肃移动、贵州移动、青海移动、广西电信、陕西电信、贵州电信、四川电信、安徽电信、海南电信、福建电信、甘肃电信、宁夏电信、广东电信、杭州电信、舟山电信、绍兴电信、湖州电信、辽宁网通、山东联通、江西联通、福建联通、广西联通、湖南联通、江苏联通、四川联通、广东联通、贵州联通、湖北联通、内蒙联通、贵州联通、云南联通…     ●    金融行业：广发银行、中国国际金融有限公司、上海期货交易所、太平洋保险、中国金融期货交易所、华夏基金、易方达基金、招商基金、南方基金、鲁证期货、东吴期货、国泰君安期货、中大期货、银河证券、民族证券、宏源证券、新时代证券、上海证券、远东证券、太平洋证券、东兴证券、万联证券、金元证券、信达证券、江南证券、华泰证券、南京证券、信泰证券、东吴证券、长江证券、国联证券、东海证券、西南证券、山西证券、金通证券、中原证券、财达证券、西部证券、国盛证券、国海证券、华福证券、恒泰证券、湘财证券、华鑫证券、财富证券、中天证券、财通证券…     ●    政府行业： 北京电力、青海电力、四川电力、江西电力、天富热电 河北省地税、武汉财政、上海松江财政、 吉林省交通厅 、辽宁省征稽局、蛇口码头、宁波港 贵州公安、东营公安、深圳交警 青岛有线、泰州社保、中国邮政 长春一汽、济南钢铁、深圳神州通集团 河北省地税11地市征管数据集中容灾备份系统、江西省电力12地市营销数据集中容灾备份 ●    贵州联通、福建移动、北京地税、天津地税、洛阳公安、浙江电力、大连商品交易所、太平人寿、天安保险、WebEx、永乐家电、宝钢集团、香港国际货柜码头、盐田港 用户口碑： DSG Realsync在国内的行业中口碑非常好，能够为客户提供及时的技术服务和研发响应，不断满足用户的新需求。 海关总署： 2004年，海关总署采购了QUEST公司的产品用于北京与广州之间的异地数据复制容灾，使用半年后，产品一直处于不稳定状态，经常需要停机重启业务，服务不到位，于2004年年底遭到退货。 杭州电信： 2007年3月，QUEST公司与迪思杰竞争杭州电信的复制项目，迪思杰技术评分高，但QUEST低价中标，所以该项目被授给了QUEST，由于QUEST的产品实施需要长时间停业务，而电信接受不了，所以花了几个月时间也无法实施，工程拖延，于2007年年底遭到退货。 贵州联通： 贵州联通在使用shareplex过程中存在很多的问题，尤其是月底出帐后，每次都需要人工用dd命令作一次数据重新全同步，所以导致贵州联通在扩容项目中希望选择DSG公司产品。 其他… 售后服务： DSG Realsync在国内拥有50多人的售后服务队伍，分别在北京、上海和广州分布服务人员。 DSG Realsync承诺给用户提供7*24小时的不间断服务。 对于那些允许远程登录的用户，DSG承诺每周进行一次例行检查，对于那些不能远程登录的用户24小时电话响应，12小时达到现场响应。 DSG从来都是对客户需求随时响应，有求必应。 Quest中国是QUEST在中国的代理商易虹天地以挂靠的名义建立起来，目前该公司还是以前的服务团队，无法得到总部的有效支持，且国内人员对Shareplex产品熟悉并掌握的人员不超过3个工程师，这在国内的长江证券、杭州电信等项目中都得到体现。 而且QUEST的服务缺乏人性化，例如，在北京地税最近一次为3.10日晚上11点，且QUEST要求用户先支付高昂的年服务费后，才提供技术支持服务。 ●   研发的响应程度和新需求的支持 数据复制容灾系统在业务连续性中是非常关键的，这种系统的建设不是单纯的产品购买问题，而是涉及深入到应用系统逻辑的支持。对于数据复制系统上的后期支持，以及针对新业务的开发上都需要有厂商更大的支持。 DSG作为立足国内，面向世界的软件开发商，在国内设有研发中心和技术服务中心，在国内建有完善的售后服务体系。可以针对应用要求提供客户化支持，为该项目未来发展提供不间断的后续支持，提高响应速度。并且在工程实施方面将由DSG公司直接负责，保证了系统建设成功率。 如对于应用会用到的特殊功能（如延迟装载），DSG因为在国内有研发机构，因此能够及时响应。 ●   研发的响应程度和新需求的支持 而Quest在国内根本就没有研发团队，也谈不上对shareplex产品的核心支持，在经常出现问题后无法解决，根本就没有解决方案。而且在系统出现bug后不能及时修复，需要经过美国的研发团队配合。 从2004年和quest竞争以来，没有发现quest的产品在最近几年内有什么改进和大的进步，依然停留在几年前的样子。 技术细节： DSG RealSync与QUEST Shareplex都是通过对oracle log信息进行分析，生成交易指令后传输到容灾端进行重新装载的方式来实现容灾的。两个产品在实现原理上属于同类产品。但是在产品的功能上、性能上，在简化系统的实施、维护和支持国特殊需求方面存在一定的差距。 ●   功能的完善性 数据复制系统的实施过程包括两个阶段：全同步和实时增量同步。 实时增量同步过程是通过对log文件进行分析得到的。 但对实时同步之前必需将存量数据从生产系统导入到容灾系统上。这些数据不能通过log文件分析得到，所以需要另外的实现机制。 DSG Realsync支持了两个阶段的环节。 ●   功能的完善性 但Shareplex只提供了redo log的实时分析部分，根本就没有第一阶段的任何功能 ●   首次全同步功能具备，无须停业务 DSG公司在大量的实施案例过程中新开发了首次全同步功能（full_sync）。全同步产品(FULL SYNC)是我公司为实时复制产品配套开发的，该功能在整个容灾系统的建设、运行和容灾切换的各个运行环节中，具有以下各种重要而明显的优势： 优势一：无需停止业务、无需申请停机时间； 优势二：操作简单：只需要一条命令即可操作，无需过多人为干预； 优势三：多任务并发全同步，提高全同步性能，如8个并发任务下，在1～2小时完成300GB数据的全同步（该数据为有效的记录数据，而不是数据库分配容量）； 优势四：真正支持不同操作系统、不同存储系统、不同数据库版本之间的全同步； ●   首次全同步，没有好的解决方案 Shareplex只提供了实时同步功能，并不提供全同步功能。他们的全同步采用其他第三方的方式，主要包括存储拷贝方式（例如backup/restore，或者是mirror等方式）以及逻辑方式（主要是EXP/IMP）。如果采用这样的方式作全同步将会存在很大的问题： 存储拷贝和EXP/IMP方式都需要停止业务； 导出和导入时间非常长 ； 操作过程非常复杂，需要大量的人为干预。 从最近的杭州电信容灾项目来看，该项目已经签约给了shareplex，但由于其没有初始化功能，所以项目无法实施，到后来是由DSG公司利用realsync的首次全同步功能提供了迁移支持，并且将可能接替quest实施杭州电信容灾项目。 ●   源端日志分析的性能 从大量的应用情况来看DSG RealSync在处理性能上优于同类方案。 在福建电信项目中采取了积压日志分析的方式进行测试，预先产生4GB的日志数据，然后启动realsync测试其在多长时间内能够分析完这些数据。测试结果表名，在800秒内产生的4GB日志，realsync只需要100秒分钟即能分析完累积的日志，其速度远远高于产生日志的速度。 ●   源端日志分析的性能 同样在福建电信的项目中，Shareplex的日志分析速度远远低于Realsync的日志分析速度。 所以Shareplex在该项目中丢了。 ●   目标端装载性能 从大量的应用情况来看DSG RealSync在装载速度上优于同类方案。 在福建电信项目采取了并发交易测试方法进行测试，预先产生7GB的日志数据，然后启动realsync测试其在多长时间内能够装载完所有操作。测试结果表名，DSG RealSync是业界最快的，在1100秒装完了所有数据 ●   目标端装载性能 同样的测试环境中，shareplex厂商需要1600秒才能完成。 ●   单表修复功能 Realsync提供了单表重新全同步的机制进行修复。单表全同步的功能对于操作者来说使用非常简单： 第一：只需要一条命令就可以完成； 第二：不对生产系统产生任何影响，不需要业务中断； ●   单表修复功能 而Shareplex在需要全面修复某张表的时候，需要用exp/imp的方式进行，这时必需要求停止生产系统的业务。 ●   监控界面 DSG Realsync提供并在不断的完善GUI监控界面，对于进程、日志分析、数据装载、数据传输、队列监控等方面都提供了实时监测和错误告警手段 ●       监控界面 Shareplex还只提供了字符界面的管理手段，这种方式很难及时进行错误的告警，提高了维护难度。 而其宣称能够与foglight配合来实现图形界面的监控，但是请问foglight是免费给客户用吗？这是典型的强买强卖嘛，因为foglight可也不便宜呀。 ●   是否支持不同schema之间的同步 DSG Realsync可支持生产系统的schmea名字和目标端的schema名字不相同的情况下的数据复制。 更为重要的是支持两个不同schema名字之间的DDL复制支持，因为Realsync会自动的去替换DDL中的schmea名字 ●   是否支持不同schema之间的同步 Shareplex只能在两个完全相同的schema名字之间进行DDL的复制。 ●   是否一定要求表具有PK/UK索引 DSG Realsync在装载是采用rowid的方式来定位，而不依赖于PK/UK字段。 这样用户可根据需要在目标端创建不同的index，提高目标系统上的业务针对性 ●   是否一定要求表具有PK/UK索引 Shareplex必须依赖于PK/UK字段，而对于那些没有PK/UK字段的表，其也能够支持，但是性能却非常缓慢。 这样shareplex也必须要求两端的index最好是相同的，这样才能保证目标端的装载性能。 ●   复制任务的配置是否简单 DSG Realsync在配置需要复制的对象时具有非常灵活的方式，包括： 需要复制的schmea 不需要复制的schmea 需要复制的所有tables 不需要复制的所有tables ●   复制任务的配置是否简单 Shareplex在配置上，需要为每个table设置映射关系，而且还没有图形界面，试想一下在一个具有几千张上万张表的情况，如何快速的配置这么多的表呢？ ●商务灵活性 DSG Realsync的维护报价按照客户需求，按销售价格的百分比进行报价，在后期CPU升级、更换存储等情况下，不会另外收取费用。并且提供定期巡检服务。 ●   商务灵活性 Shareplex规定严格执行商务合同，在CPU升级、更换存储等情况下严格按照收费标准。在没有收到维护费用的情况下，不提供服务。