“我是甲方，如果你要向我推销K-DB，你得给我讲清楚几件事;我为什么要买你?如果说你的产品是为了顶掉我当前用得好好的产品，你得告诉我，凭什么?”--田永江

　　导语：本期访谈对象田永江，2011年DB2十大风云人物、Oracle技术专家、某银行数据库负责人。和田永江的会面是在浪潮深圳分公司的K-DB技术开放日活动现场，虽然早有耳闻，但这是我第一次见到他，干练的平头，锐利的眼神，说话很有气场，语速不快但逻辑性强。这也是田永江第一次接触K-DB，不是给浪潮站台，而是一个资深DBA扩充知识广度、了解业界动态所需。

　　在数据库领域摸爬滚打20年，让他在数据库架构、大数据量处理、性能问题分析解决、故障定位分析方面有着丰富的经验。多家银行IT部从业背景，让他对如何将不同数据库产品和技术合理地运用到银行信息系统中有着自己独到的见解。

　　在1个多小时的采访过程中，田永江给了我很多意外，相对网上诸多DBA对国产数据库的一脸鄙视和挖苦，作为数据库资深专家，他显得更为理性，田永江并不吝啬对K-DB优异之处的褒奖，也会毫不避讳的指出K-DB不足之处，其独到、深刻的见解令人印象深刻。其次，能将各种数据库技术用最通俗易懂的方式表述出来的受访者，在我以往的采访经历中并不多见，功底深厚由此可见。这次采访，也打破了我一贯以来对银行“暴力”选型的认知，银行不差钱的选型模式或将成为过去。

　　以下内容来自老鱼采访实录整理：

　　老鱼：今天这个活动下来，你对K-DB有何评价?

　　田永江：基本符合预期，我跟盖国强有过多次交流，之前也听他讲过一些对K-DB的了解和看法，今天来是为了进一步印证。确实，从今天的活动来看，大家对K-DB的简单易用评价都比较好，特别是从Oracle迁移到K-DB的工具，如果用的是标准SQL，基本上不用改，工作量非常小，这方面做得非常不错。

　　当然，我们也看到K-DB相比Oracle还是有些滞后，特别是Oracle 12c的数据库分片(Sharding)、多租户等功能是K-DB目前还没有的。在这种情况下，K-DB就需要想清楚自己的定位。

　　我是甲方，如果你要向我推销K-DB，你得给我讲清楚几件事;我为什么要买你?如果说你的产品是为了顶掉我当前用得好好的产品，你得告诉我，凭什么?

　　因此，定位很重要，因为会影响到用户的定位。K-DB的天花板有多高，决定了用户能设定的天花板有多高。K-DB到底是要做一个大而全的数据库?还是做一个轻量级的数据库?

　　老鱼：你如何看待K-DB全兼容Oracle的做法?

　　田永江：我们看到Oracle在数据库发展史上，起到了一定的引领作用，那么K-DB选择和Oracle如此相近的做法，说的不好听叫取巧，说的好听，是站在巨人的肩膀上往前走，就我个人而言，我觉得是一种不错的选择。

　　国内有好几家数据库厂商在产品架构上都想做得和Oracle接近，但总有不同，最多的差异体现在数据存储上，有用存储的，也有不用存储的，而是利用分布式架构把数据写到多个节点上的。用存储的时候，我是用分布式的存储，还是用集中式的存储更好?如果是一个集中式的存储，那么它的容量不够的时候，我怎么实现扩容?扩容的时候是我只增加容量还是我的性能都能提升?用户自己管还是DBMS管?不同的数据库这块做法会有不同。

　　我觉得各有利弊，RAC的扩展性，包括K-DB的扩展性，如果是计算资源不够了，加一台主机是可以的。如果是存储资源不够了，就这种共享式存储，实际上是把问题交给用户自己。比如说我用分布式存储，自己搭建一个存储系统，由我自己来实现它的高可用性和弹性伸缩，性能扩展的作用，然后再把它当成一个传统的共享存储，交给数据库来用。

　　把这些事情交由数据库解决还是用户解决，是两种不同的选择，我觉得可能分布式存储会更好一点，更符合潮流。

　　老鱼：都说银行不差钱!选型只选高大上的产品!是这样吗?

　　田永江：这话不能说不对，但也不绝对。跟大部分行业比，银行的确显得不差钱，有点高大上,这和银行业务高要求的特点有很大关系。但如果跟几年前比，相对而言多花点钱，只要把事办好的时代已经过去，那么做也不合理，IT部门作为一个成本中心，应该考虑价值和成本。

　　在三年前，我们选产品，选厂家，是要看Gartner报告的，如果你连前三都不是，可能连门都进不了。而现在不一样了，选型时一方面会考虑成本;另一方面是自主可控的需求;除此之外，我们对未来技术趋势也会有自己的总体判断，要符合发展趋势。

　　都说银行业务对数据的要求高，不能停也不能错，其实这也不是百分之百，再重要的东西，你把它像剥洋葱一样的剥开以后，实际上都是一层一层的，确实有它最重要最核心的东西，一点都不能错，一会都不能停，同时也会有一些不那么重要的东西，用不着那么高的保障，因此我们的系统并非都是高大上的，也会有比较LOW的。另一方面，互联网金融业务发展很快，在技术平台选择上也需要打破传统的界限。这意味着，在满足可用性要求的前提下，我们也会追求性价比，如果产品、技术确实能满足我们的需求，在Gartner没有评测的细分领域，或者未达到Gartner评名靠前的产品，也是有机会的。

　　老鱼：银行数据库选型主要考虑哪些因素?

　　田永江：如果要高度概括银行数据库选型要点，其实就是可用性、性能和安全三件事情，当然每件事情下面又有N多要求。

　　可用性，是我们最关心的问题。如集群软件的健壮性如何?网络出现故障的时候，它多长时间能够恢复?包括它恢复时候的一些细节。心跳可以接几个网络，可不可以支持不同的网络，这都是我们的要求。在可用性方面，在银行业会有非常高的标准和要求。

　　可用性其实又分两个层面，高可用和容灾，第一个层面是屹立不倒，刚才讲的这些都是屹立不倒。还有一个层面是容灾，它万一倒了，一方面我能快速恢复，就是我快速把倒了的扶起来。万一扶不起来，我有一个备用的，能够快速地接管切换、恢复业务。

　　安全性方面，是不是有很好的审计，有很好的安全访问控制，有权限的分离等等，都是我们非常关注的。

　　性能就显而易见了，如果我们系统对数据量的规模要求很高，对交易的并发度要求很高，对响应时间要求很高，你这个数据库能不能支撑这么大的交易量?当它不行的时候，你扩展性又如何?都是我们要考虑的因素。

　　老鱼：你觉得未来在银行业，分布式会取代集中式的架构吗?

　　田永江：这个涉及的因素比较多，比如说银行从业人员技能，投资保护等。

　　从技术潮流讲，我觉得若干年后，银行除了最核心最重要的那些东西，要放在像390、400、Oracle RAC、DB2 PureScale这样最高保障的环境下以外，分布式架构应该是一个最合理的架构。

　　当然分布式并不一定能解决所有的问题，比如最典型的就是贷款，贷款有一个额度，比如分行今天的贷款额度是十亿，你每一笔贷款都要查询和扣减额度。这时候你把数据分得再开，最终每一笔交易都去请求这个额度时，就会形成瓶颈，分布式的优势就没有了。

　　老鱼：你认为数据库未来的发展趋势会是怎样的?

　　田永江：当今技术领域数据库一直都是个难题最多的领域，现在存储、网络、操作系统、主机，甚至应用的难题都已解决，比方说故障恢复方面，遇到故障时的处理方法，都是说我重启一下，或者我把它隔离了就行了，因为它没有状态，没有客户数据资料，没有那么高的一致性要求，只有数据库还做不到这样，因为最终的一致性是压给了数据库。

　　我们看到互联网流派提到现在是应用为王的时代，既然难题都在数据库，为什么不去把真正有一致性、完整性需求的部分才交给数据库，其他的都交给应用去做呢?应用会更复杂，对应用的要求会更高，但是你的系统会更加健壮，对数据库的需求会更低，加上分库分表，这也是互联网之所以能够采用MySQL的一个理由，它对数据库的要求降低了。

　　数据技术领域呈现多元化趋势，传统数据库，加速用的内存数据库、分布式缓存，非关系数据库都在发展，要适应越来越大的应用规模，不同的业务和数据类型，要满足海量数据规模、超高交易量、很快的响应时间，需要综合运用多种平台和技术，来搭建一个好的架构，满足高可用、高性能、高扩展性的需求，另一方面，和制造业从提供产品到提供服务、解决方案的转型做法一致，数据库也要提供服务、提供解决方案，让数据库服务功能更强大，使用更便捷、更标准化、更敏捷，生态环境更加完善。