返回 登录
0

专访臧冰凌:数据库发展大趋势之X86化和云化

阅读8494

2016年11月25日,沃趣科技“智慧应用 数据先行”2016产品发布会暨新三板挂牌庆祝会在杭州华美达酒店隆重举行,会议汇集众多业内专家精英,聚焦云时代下的数据库发展新思路,探讨虚拟化云计算等一系列热点话题,信息交互,共同把握未来趋势。

借此契机,CSDN记者有幸邀请到沃趣科技技术组专家臧冰凌,围绕一些大家关心的话题进行采访,围绕数据库X86化和云化两大热点趋势,细数其从“门外看花”到实践探索,再到术业专攻的学习进阶之路。

图片描述

CSDN:首先能否请您先介绍一下自己,同时谈一谈您难忘的从业经历,以及感兴趣的技术?

臧冰凌:倘若从我的从业经历来看,其实比较复杂,因为我本身不是计算机专业的,而是会计专业出身。但机缘巧合之下,在大学时期,勤工俭学的经历让我偶然接触到了计算机,就喜欢上了这个专业。所以我从那时起到工作生涯前几年大部分时间都是靠自学,因此我一开始做过的事情比较杂,最早包括2001年比较多的兼容机组装维修,后来我又接触到了网络,接触到了cisco技术,从而对此产生了极大的兴趣,特别是对网络里的路由交换原理、路由协议等。

于是我就花了很长一段时间进行学习,后来我工作后的第一份工作就是和系统集成、和网络相关的。再后来大概是2003年的时候我来到了杭州,那时我所在的公司更多从事着主机存储系统集成的工作,而我的工作方向也就从网络转到了主机存储。到了第三份工作的时候,我就来到了朗新科技,这是一家电力行业的软件服务商,我在这里学到了很多东西。从我最早做系统集成、主机存储的工作,到后面因为工作需要,逐步转到DBA这个角色上来,从而真正开始全面接触数据库,接触Oracle,这些工作经历给了我很大的帮助。从早期的DBA日常运维管理,到SQL优化,我做了整整两年左右的SQL优化工作,其后再次由于工作需要,公司将我安排到了数据架构设计岗位,我又做了两三年的数据架构设计工作。再到沃趣,我则转向整个IT的售前咨询岗位。所以说我的工作经历比较杂,除了开发之外的工作我基本上都做过。

我感兴趣的事情,从我的工作经历可以看出来,我最早对计算机感兴趣,彼时只是个很朦胧的概念,觉得很神奇。之后接触到网络,其中有很多路由协议的概念,我被很多路由算法吸引了。然后我在做主机存储时,无意间接触到了数据库,觉得这个技术非常高深,一是它有很多抽象的逻辑概念,再者它与业务接触更紧密,较之网络路由技术,对用户的价值和帮助更大,我就开始越来越多地关注数据库这块技术,最终走向数据库架构师这样一个工作岗位。所以我是自己慢慢一步一步摸索走到了数据库这条道路上来。

CSDN:那么您目前在沃趣主要是负责的什么样的工作领域呢?

臧冰凌:目前我很大一部分精力投放在售前上,就是前期与用户交流产品,讲解技术,数据迁移、容灾备份规划,数据架构迁移规划等工作,包括售前交流和架构咨询两部分工作。另外,我会把售前过程中所收集到的用户需求和痛点进行提炼,总结成一些我们产品可以实现的功能,并负责给产品部门提供好的idea。

CSDN:目前越来越多的用户都在做数据库平台X86化的工作,对此您有什么好的建议?

臧冰凌:近几年,从阿里最早提出去IOE的概念之后,越来越多传统企业的用户在很认真地对待这件事,表示要去IOE,但实践过程中,去O这件事情可能比较麻烦,因为需要大量业务开发的投入,所以相对来说去I和去E这件事情就相对比较容易实现。在去I这个过程当中,很多用户会碰到这样的问题:去I之后,我也把我的数据库从小型机迁到X86上来了,但性能却并没有任何提升,甚至还出现了不同程度的衰退。这是因为我们在这个问题的认识上存在一定的误区,就是去I不是简单地把数据库从小型机存储平台迁移到X86平台上来,这个过程当中原来IOE这个平台的性能,或是可靠性等核心问题,并不在计算这一层。那我们现在简单地去I,去计算,并不能解决我们数据库真正的痛点,关键问题还是在于我们IO的性能。解决了IO性能问题之后,我们紧接着需要面对的就是平台的可靠性和维护性。如果认为去IOE只是简单的X86化,就错了。那我们团队现在做的一个任务,就是帮助用户做去I和去E的事情,为用户构建一个高性能的数据平台,同时在保证性能的前提下,确保用户数据库的可靠性和维护性,在这个过程当中,除了去IE之外,还要认真思考如何提升此后的存储的稳定性、扩展性、可维护性等。

CSDN:您刚刚提到有的用户发现进行X86化之后,出现了一些问题,这其中就包括原有的基于存储的容灾备份方法失效了,对此您有什么好的解决方案或建议?

臧冰凌:这个问题紧随去IOE之后而来,传统存储容灾备份的解决方案失效了,那我们在X86这个架构下面有没有合适的,或者是好的替代方案来实现在X86架构下的容灾备份?这里如果我们还遵循传统存储厂商的技术路线继续往下发展的话,是没有前途的。市场需要一个开放的架构,用户希望从某一个或某几个厂商的绑架中解放出来,所以市场需要一个更开放的技术来解决数据库的容灾备份问题,那么我们有什么合适的解决方案来做到这一点?我认为应该从传统的纯硬件解决数据容灾的思路上跳出来,那我们是否可以从更上层,或者说从软件层来解决数据容灾的备份?在这里我也有相对成熟的建议,可以考虑利用数据库的一些特性,及其自身的优势来解决数据库容灾,比如说在MySQL这个数据库平台下,我们可以用MySQL的强同步来解决,或者用MySQL的异步方案来解决数据库的异地容灾问题。而在Oracle环境下,我们可以基于Oracle的Active DataGuard技术来解决数据库本地,或者远程容灾的问题,再者是结合Oracle或MySQL的在线日志多副本保护技术来实现我们数据库的零丢失保护。

CSDN:通常,用户对数据容灾保护与业务连续性的追求是紧密相连的,对此有什么理解?

臧冰凌:业务的连续性和容灾保护这两点对传统企业,特别是传统的金融企业而言,是非常需要关注的。而这两点的重要程度基本不相上下,但是很多情况下,这两点会是一个矛盾体,我要保证我的数据容灾,那么我可能会在数据主库发生故障的情况下,需要花费一定的时间去解决数据零丢失的问题,进行数据找回工作,这就需要花费一定的时间做数据库恢复。这段时间我的业务在数据恢复过程当中,无法保证业务的连续性。因此如果要找到一个合适的解决方案,通常的解决思路还是针对不同数据库的不同访问特点来解决:

针对Oracle数据库,我们对于数据库的容灾和业务连续性的保护,通常是通过多副本的保护,以保证主备库之间的延迟尽可能低,低到什么程度?之间的差异可能就是在几秒钟之间的秒级差异,当主库挂起时,通过第二个维度的副本来快速实现容灾库的数据恢复,保证主库和备库的切换没有任何数据的丢失。而对于MySQL,我们可通过数据强同步的方法,保证主备库之间的完全一致性。

而在Oracle中,我们还有一种更好的解决方案,就是数据库双活,保证两个数据中心或两个园区之间的数据存在多个副本,任何一个数据中心挂起时,我另外一个数据中心的数据不会丢失,业务和服务不会退出,这就保证了业务数据的可靠性和业务的连续性。那么针对MySQL的这种场景,我们可通过多活数据中心的方案来解决,保证我们在多个数据中心的数据强一致性,那么任何一个数据中心挂起,另外一个数据中心的MySQL数据库依然可以提供读写服务,数据也不会退出,那此时数据保护和业务连续性都可以满足,根据资金投入和业务需求,在X86平台下有多种解决方案可以实现这两点需求。

CSDN:您刚刚也有提到提到同城双活,那能请您谈谈同城双活的技术难点以及它能给用户带来什么收益?

臧冰凌:从IT建设的初始阶段,用户就有数据库双活这种数据及平台高可用的追求,也就是说多活数据中心的追求伴随着IT建设的整个周期,所以并不是说最近几年才兴起的,只是最近几年用户把这样的需求提到了一个非常高的高度。初步展望,也许未来5年以后,同城双活的这种数据中心建设会成为用户IT建设的一个基本要求。那么经过几十年的发展,针对同城双活的需求,其实一直没有厂商提出一个非常完美的解决方案,它的问题难点在于物理限制,也就是说两个数据中心之间经过物理距离百公里的链路延迟,传统技术很难有好的解决方案来加以解决。同时,因为两个数据中心相跨越几十公里的距离,哪怕是高质量光纤,这两个链路上难免会有一个延迟抖动,可能还有施工实施,甚至一些人为暴力的破坏导致链路损害或延迟增加。但在这种情况下,传统的解决方案很难有一个好的链路感知技术,从而导致链路一旦出现抖动,就会造成我们的核心数据库出现短暂或长时间的夯起,直接影响到前端业务的响应,这就是双活的一些关键技术难点。那我们首先要解决第一个,就是对两个双活数据库之间的链路感知能力。第二点,就是感知到链路抖动或者延迟的情况下,还要有主动干预的机制来解决这个问题,在极短的时间内排除掉这种可以预期的故障。

另外谈及对于用户的益处,双活的数据中心可以做到用户遇到任何较大的自然灾害或意外风险时,将其数据损失风险降到一个最低水准,同时保证其业务不会停止,这也就保证了业务连续性,那对于金融行业一些重要的系统而言,业务连续性的价值至高无上。

CSDN:近两年,云计算已经深入人心,但对于传统企业来说,在数据库细分领域并没有非常完美的数据库云化技术或方案,对此你有什么好的建议?

臧冰凌:说到数据库云化,最近两年云计算的概念也非常火,但是云计算这个大概念往往隐藏了很多业务系统真正存在但很难解决的问题,比如数据库这种有状态感知的应用。那么公有云的平台下,例如阿里云、腾讯云,或亚马逊的云,一直没有基于Oracle数据库的云化的优秀解决方案。当然私有云厂商也有很多,比如说很多基于OpenStack私有云解决方案的厂商,在它们的云平台里同样没有提供好的Oracle数据库的云化解决方案。而对传统企业来说,其实它的应用库环境里面运行了大量Oracle的RAC环境。现有的云平台无法解决Oracle RAC的需求,这样云平台相当于只解决了我所需求的50%的工作,那么用户还得寻求更好的能解决关键的数据库云化的解决方案。那对于数据库云化的解决方案,我们的思路还是很清晰的,而且了解Oracle用户的需求和关切。对于Oracle 这种Share Anything的数据库RAC结构,我们需求全面而深刻了解它的架构,在这之上,我们可以进一步吸取现有云平台的优秀思想,底层平台我们可以遵循RAC架构来构建Oracle数据库的云平台,而不是一刀切,都基于无状态的云去构建我们的数据库云。而我们公司在这方面也做了大量的探索和研发投入,目前基于我们的QData构建的QData Cloud这样的Oracle数据库的云化解决方案,很好地解决了底层架构和上层管理的数据库云的需求。

CSDN:数据库的安全性和稳定性方面一直都是大家关注的重点,你们在这方面做了哪些部署和措施?

臧冰凌:数据库的安全性分为几个层次,第一,要保证数据库架构的高可用。比如坏了一个计算节点,要保证这个业务不停止;第二,就是数据的高可用,此处高可用当然包含数据多副本的保护,这就涉及到数据的容灾保护,就是数据放在一个地点,这个地点有可能出现物理上的整个灾难性损坏,那么我们需要数据跨越物理距离的多副本保护。第三,是数据的访问安全,也就是数据存储在这里,但是任何一个其他未经授权的人来访问这个数据,或者通过非法手段窃取数据时,他拿到的数据应该是经过加密的。我认为数据安全应该从以上这三个方面去考虑。

那么针对这三个方面我们的解决方案呢?通常像第一点数据多副本的保护,在我们的这个QData平台里,结合OData的特性,有数据两副本,或者三副本的数据保护。而在数据容灾的解决方案里,我们有QBackup数据库的本地或者远程容灾、数据零丢失保护的解决方案。针对数据安全,我们在MySQL的数据场景中,配有MySQL的数据表加密插件,在运行的MySQL数据库上加上这样一个插件,则针对所有的关键业务表进行数据加密,这样任何非法用户获得我的数据文件时,他打开以后这些数据文件呈现的其实是一个乱码的形态,它不能获得真实的业务数据。

另外是数据库的稳定性,数据库的稳定性又分为两个层次:1)数据库软件本身的稳定性;2)这个数据库所在平台的稳定性。那数据库软件的稳定性,我们紧跟着这个数据库的原厂,比如说Oracle、MySQL、Postgres……我们同这样的数据库厂商保持紧密合作,它们则报出相应的Bug,包括Bug的修复方案,对此,我们会有紧密的跟踪和研究,及时为用户提供风险警示。再者,从数据库平台稳定的角度,在QData Cloud解决方案里,我们会从底层的硬件选型到主机运行的主机平台的BIOS优化,到OS层面的内核参数优化,包括内核Bug的跟踪和数据库的参数优化跟踪,我们做了大量的研发工作,为用户提供了一个最为稳定可靠的数据库运行平台。

CSDN:起初您就谈到您是跟着自己的兴趣走,从自学开始一步一步扩大学习,过程中也积累了丰富的经验,那对于我们数据库领域的相关从业者而言,您有没有什么自己的建议经验可以分享吗?

臧冰凌:那就从学习的角度讲,我觉得兴趣是我们学习的一个最大的推动力。当今是一个信息爆炸的时代,我们接触到的知识途径方法也很多,那作为一个技术人员,如今技术的方向也非常多,一个人很难在每个技术领域都有比较好的深入跟踪和研究。所以最好是选定一个技术方向,然后在这个技术领域里做出坚定不移的研究投入,这会是一个很好的方法。如果一味盲目地想要把每个技术领域都学得很透的话,有可能你涉猎面很广,但是却都不够精。

评论