东方国信XCloud DB直击“海量数据+多元场景”

如今数据量爆发增长且海量集聚,应用场景也随之变得越来越复杂多元……

曾经垄断市场的国外数据库纷纷遇到发展瓶颈,市场被打着“数据库自主研发”标签的创新企业掀起层层波浪……

在这样的背景下,其实任何一种技术想要得到极高的关注度及普适度,最终都要迈进“应用”这道门。

简单来说,探索场景、技术提升、落地应用这个“全套”不能少!

身处国产数据库发展的红利期,东方国信首席架构师金正皓也认为,不断追求数据库的功能完备以促进更多场景的适配,这一点在现阶段尤为重要。

说到东方国信,说到架构师金正皓,就不得不提及XCloud DB这款新一代分布式数据库产品,接下来小编就以这款数据库产品为蓝本,解读XCloud DB面向海量数据与多元场景的新表现。

概括来说,XCloud DB,定位于分析型应用领域的新一代大规模并行处理数据库,在并行任务规划、弹性计算、行列混合存储、代码生成等方面有进行了很多技术优化与创新。

东方国信XCloud DB直击“海量数据+多元场景”_第1张图片

东方国信首席架构师 金正皓

关于弹性能力的提升,XCloud DB有绝招!

内行人都了解,分布式数据库实现弹性计算的能力相对困难,一方面需要服务器具备高性能配置,另一方面还需要将大量数据进行动态迁移, 这会使硬件和处理时间的成本大大提高。

目前来看,分布式数据库实现弹性计算通常会采取两种方式,一种是数据库云化,另一种是将计算与存储分离。

数据库的云化通常采用容器技术实现资源的调度和隔离,这种方式将会面临:数据库上云如何越快越好?怎样有效解决构建混合云的困难?如何降低虚拟化带来的性能损耗以及公有云环境与内部网络环境的有效沟通等诸多问题。

如今,计算和存储分离的方式在业界也已经有许多尝试,作为增加数据库弹性机制的必要条件被广泛探索,例如一些高性能分布式存储技术以及RDMA技术等,但实用化还需时日。

令人惊讶的是,XCloud DB提出并实践了更为有效、实用的弹性计算策略。

当接收到多组SQL请求时,XCloud DB依据请求的资源开销估算进行集群内统一调度分配,并结合多副本读取实现计算本地化和IO并行化。

在高并发场景下资源响应采取延迟换吞吐策略来降低集群压力、提升系统吞吐量,这个情况下弹性计算策略能够实现整体集群的自动负载均衡,并做到最大化利用软硬件资源,以达到高并发需求。
东方国信XCloud DB直击“海量数据+多元场景”_第2张图片

分布式弹性计算与传统分布式计算对比

同时从系统扩展性角度出发,金正皓表示,弹性计算的基础其实是计算与存储的有效分离。

因为只有完成分离,计算资源的伸展和收缩才能更加自如,这种技术配置突破了传统MPP数据库的局限性。第一代MPP数据库很大程度上是通过数据与计算资源的密切绑定实现的,因此其在处理大量数据、动态扩容或者缩容的时候就会产生无法回避的技术障碍。XCloud DB可以被认为是云化部署和动态调整计算资源的系统,具有更好的系统扩展性。

关于多租户计算资源隔离与数据共享并存的问题

计算资源得到弹性分配的同时,如何保证租户之间既共用相同的系统或程序组件,又能让数据隔离,这就是多租户技术要解决的问题。

不同于传统多租户模式采取独立库、共享库但隔离数据架构或者共享库并共享数据架构的方式,XCloud DB允许用户依据不同业务场景,进行租户划分、隔离与管理集群计算资源与存储资源,同时通过队列限制用户使用集群计算与存储资源的比率,达到租户级别的资源分配与隔离的效果。

东方国信XCloud DB直击“海量数据+多元场景”_第3张图片

XCloud DB隔离模式示意图

具体来说,关于多租户隔离,包括CPU的隔离、内存隔离以及存储隔离,这三个层次的隔离手段XCloud DB目前均已具备。但就目前的行业发展来看,在网络和IO隔离方面并没有特别好的技术手段。

租户之间既要有隔离,也要有数据的共享机制。

这种共享需求契合了国内大数据应用的场景。不但数据量大,使用者也多,数据仓库外围接入的第三方系统也已经越来越多。数据隔离与共享就更需要有像XCloud DB这样的产品给出完整的解决方案。

关于节点与资源分配的优化

在超大规模分布式系统中,所有服务器都需要协同工作,即便是单个节点宕机(单点故障 SPOF),都有可能导致整个系统运行的中断,所以高可靠以及高可用性是此类系统的必要标签。

关于节点宕机问题,金正皓表示在XCloud DB产品的研发中就已经考虑到。

XCloud DB通过高效的跨节点数据分布与多备份机制,强一致性的保存多副本元数据与内容数据,应对节点故障所产生的影响,让这种故障所引起的性能干扰可以被其余节点均摊。

问题来了,这样的备份机制是否会影响调动的流畅性呢?因为还是增加存储的负担了。

金正皓认为,这种形式确实会额外增加一些存储,但实际上这是保证数据安全的一个必要手段,也可以说多副本的技术开销实际上是不得已而为之。

在分布式系统中,因某一节点的故障造成数据丢失,是任何用户都不愿意看到的情况。XCloud DB解决这一问题的方法是采用多副本机制,即对于同一份数据,在分布式系统中实现多节点多拷贝,以保证整体数据的安全性。

传统情况下,一个节点宕机后,通常将负载转移到另一台服务器上,但可能会导致整体性能下降一半。 金正皓说 “我们做到的数据副本备份,就可以更均匀一些。举个例子,如果有50个节点,一两个节点宕机,整体性能上,无论是处理量还是并发量,可能只下降五十分之一。”

除了节点宕机,计算资源分配不均也是大规模分布式系统面临的另一个挑战。

XCloud DB的企业部署节点通常可以达到数百个,企业级产品也可以轻松达到数十个节点。随着企业的数据量、并发访问量的扩容,数据、节点规模也不断扩张。在这一过程中,东方国信始终保持与客户共同成长。

金正皓表示,很多集群在两三年间不断扩展,不同批次的机器常常同时使用。早期的机器,可能CPU、处理能力、核数、内存数量等方面,都与新的机器不一样,存在系统不均衡的问题, XCloud DB采取的策略是,基于HDFS的分布式存储结构,搭配计算本地化的动态调配机制,在线新增删除节点时,无须进行大规模的数据重新分配,横向扩展能力很高。

对等架构让数据库服务更高效可用

据了解,一般的主从架构的分布式系统,主节点需要双机热备解决单点故障问题,不但元数据和状态同步压力大,主节点还容易成为系统瓶颈,造成横向扩展能力弱等问题,但是XCloud DB却不需要担心。

这主要归功于master对等架构设计。

在master对等架构中,依靠一个全局可见的元数据服务,任何一个节点都可以成为查询请求的入口,消除系统瓶颈点,更容易做到资源的负载均衡。

东方国信XCloud DB直击“海量数据+多元场景”_第4张图片

对等式架构与主从架构

通常,在数据库处理中经常遇到表达式的计算,这其中有复杂的逻辑判断、分支跳转、函数调用等处理,XCloud DB基于LLVM的代码生成技术,可以做到减少大量的冗余判断、计算和虚函数调用开销,有效提升计算性能。

过去,国内数据库市场被国外大牌厂商长时间垄断,技术人才每每说起不免捶胸顿足;如今身处技术换代的红利期,像金正皓一样的国产数据库研发架构师始终相信,立足场景与应用提升数据库技术水平,一定会让这个春天更加绵长,XCloud DB只是个开始!

你可能感兴趣的:(数据库,XCloud-DB,东方国信,场景化)