“Database Plus”，是近期比较火热的一个理念，其最早是由我前同事、现SphereEx公司CEO张亮率先提出的，并通过开源项目 ShardingSphere(下文简称SS) 做了工程化实现。作为一名数据库领域从业者，对这一理念有着自己的一些解读。

1、对 Database Plus 的解读

作为数字基础设施的核心，数据库扮演着愈发重要的作用。从数据库承担的最为朴素的职能来看，可大致分为两个部分即存储和计算。作为数据的主要载体，数据库的一大职能是完成数据的存储，保证数据安全可用;第二大职能为数据计算，即在存储基础上提供数据的上层计算。这里所说的计算具有非常宽泛范畴，既包括对数据简单的CRUD，也包括对数据的高阶分析、挖掘及更为广阔的其他计算场景。随着近些年数字化转型深化，数据被提到更高层面得到重视，数据种类、规模迅速膨胀，同时企业对数据使用呈现多样化特点且针对特性能力提出更高要求。相应的也对数据底层基础设施之一的数据库提出了相应的要求。这里可集中表现在实时性、敏捷性、安全性、可用性、经济性、智能化、高性能、强管控、自主化、开放性、融合化及创新性等诸多方面。这部分可参考之前文章数字化转型下数据库面临的12个挑战

而Database Plus 理念的核心定位，正是基于上述现状，创造性地提出在底层数据库不变的情况下，通过在其上层构建增强计算引擎，突破原有数据库功能局限，提升数据基础设施整体功能上限。通过对 Database Plus 理念产品 ShardingSphere功能研读，其对数据计算做了三层划分。一是原生数据库的计算能力，根据数据库的不同，其原生计算能力各有差异。SS 实现与底层数据库的解耦，可灵活对接多种数据源，充分复用原生数据库提供的基础能力。二是基础计算的增强能力，这部分主要是指对数据库自有核心能力的增强。受限于宿主数据库的功能缺失，可通过此方式增强其能力。比较典型的能力如数据分片、分布式事务、分布式查询优化等。三是数据应用计算的增强能力，数据最终是要参与到应用中才能发挥价值，在这一过程中需要对数据产生大量业务计算。很多原生数据库是不具备或不擅长处理这种应用类计算。可通过这一模式扩展增强计算。比较典型的能力如数据加密、数据脱敏、数据压测、访问审计等。

过去针对这三类需求，通常有两种路径。一种路径是通过不断增强数据库内核，不断叠加功能满足一、二类诉求，很多功能强大的数据库产品不断涌现，但也不可避免面临内核的复杂、庞大及臃肿，同时也大幅抬高工程化实现难度和复杂度。第二种路径是构建很多垂直的数据应用满足第三类诉求。这种方式不在数据库自身实现，而是通过完全独立的应用系统完成。当然在企业中就会面临运维繁多技术产品和大量竖井式的应用而无法整合的窘境。我们从 SS 的实现上看，其提出可插拔理念及上层插件化应用，可用一种形象的比喻来概括就是“双擎动力+涡轮增压“。这一从汽车领域衍生过来的概念，可很好地诠释其实现理念。原生的数据库提供的基础算力引擎，如传统的汽油发动机;SS提供的基础计算增强可比喻为涡轮增压部分，其在原生数据库计算引擎之上，增强其能力;第三部分应用计算的增强则可理解为第二引擎，如新兴的电力引擎。通过这种混合动力+涡轮增压的配置，可大幅提升原有动力系统，满足用户更好的动力要求。但同时有一点不可忽视，就是无论怎么增强对用户是无感的，用户可见的只是动力增强了。还原到真实场景下，就是用户依然会使用数据库，依然通过SQL语句计算数据和管理数据库，但对应数据库自身已经是一个“Super Database”了。

除此之外，Database Plus 理念还有一点不容忽视。这里谈到的plus的概念，是非常多元的，可以在其上叠加大量的功能。这些功能是灵活的、发散的，甚至是个性化。而作为传统数据库的定位是标准的、统一的基础软件，很难满足上述要求。而作为 Database Plus 理念实践产品 SS，率先提出了“插件化、可插拔”思想，可满足对灵活多变的计算支持，同时借助平台层提供的统一标准的访问方式，旨在打造数据库上层应用、管理的标准。用户及生态合作伙伴，完全可根据自身场景需求丰富插件能力，提升产品功能外延。打造出属于自己的“DIY DB”或“组件化DB”的产品。SS 本身也是希望能吸引到更多的共享者，打造完整的数据库使用生态。

2、外部挑战及Db Plus解决之道

上文谈到了数字化转型深化中对数据库提出的若干挑战，这里我们就若干挑战内容稍微展开说明并谈谈作为Database Plus理念的实践者 SS 是如何解决这些问题的。

大规模

数据规模爆炸式增长是目前面临的痛点问题之一。为解决这一问题，比较常规的就是数据分片，即通过数据的打散降低单体数据处理规模，因而可承载更大的数据量。目前分布式数据库的处理思路基本都是这种。这其中的难点问题在于数据分片的规则是什么?一种方式是采用内置的分片策略，用户无需感知。这种方式的用户体验很好，用户可完全按照一个“BIG DB”来使用它。很多在数据分片下的能力，完全可以系统内置。很多原生分布式数据库产品就是这种策略，它的功能上限很高，比较符合使用者对数据库的定位。但这一方式有不可回避的问题在于，分布式架构的引入所造成稳定性、高性能及其他功能缺失。第二种方式是开放分片策略，用户可根据业务需求干预分片的位置。这种方式对用户有一定浸入性，但也做到更好掌控。很多基于中间件演进的分布式数据库产品基于此类。这类产品稳定性相对更好，可满足高性能要求等。ShardingSphere 的策略与第二种方式类似，只是做的更为极致，其原生提供了更为丰富和强大的分片能力的同时，还提供给用户充分的自主权，可完成精细粒度的用户定制工作。

实时性

实时性对企业数字化转型尤为重要，实时鲜活的数据对企业尤为重要。传统单机/集中式数据库通过存储结构优化、缓存的引入、执行计划优化、软硬件结合等方面很好地满足了实时性要求。但在分布式条件下，上述优化手段不再有效。此外，分布式架构下数据库需要跨组件参与计算也拖慢数据实时性反馈。如何复用单机/集中式数据库的能力，在分布式场景下满足需求成为关键。SS提供的Driver模式，给人眼前一亮的感觉。其将增强计算能力上移到应用侧，缩短访问链路，提升整体性能，满足对数据实时性的要求。当然，这一方式有天然缺陷，仅限于Java应用可使用。

安全性

数据安全，是近些年来的热门话题。从监管方的频频出台各项政策，可见一斑。作为承载数据的主体，数据库首当其冲将更为重视安全问题。从数据存储、数据访问、数据传输、数据应用等多角度解决数据安全问题。传统的处理方式是通过数据库与安全系统配合来完成上述要求，用户需要依赖引入外部安全应用软件并去适配多种数据库来完成。SS 的插件化理念，可通过引入多种安全插件能力来完成，并且对外提供标准数据库接口。针对多数据库栈的问题，也可通过灵活的适配能力来解决，甚至在上层提供统一的数据视角，完成高阶的数据安全治理行为。

可用性

可用性，是数据库需提供的基本保障。之前单机架构或集中式架构，一般是通过高可用硬件+软件来解决;对于新兴的分布式架构来说，其组件更多也更为复杂，且对于硬件也无较多要求，这就要求软件本身提供更高要求。SS 的处理思想是利用底层数据库原生高可用能力，并打通与后者的感知能力。充分利用成熟数据库的自身能力完成。当然，这种方式存在局限，针对全局的可用性是无法解决的，目前只能在单体层面解决。

经济性

随着数据存储规模越来越大，对数据计算要求越来越高，整体数据存储和计算的成本也整体提高。特别是在现有分布式架构下，对资源消耗尤为明显。上述都造成用户较高的经济成本。SS 走了另一条道路，它通过计算逻辑上移，将计算资源和应用合并部署，减少对底层资源新的需求，可提高经济性。当然这里需要考虑资源冲突问题，它的最新版本似乎解决了这个问题。

简化融合

数字化深化带来的技术需求的多元化，与之对应的产品方案也呈现同样的态势，对于数据库方面尤为明显。虽然可以通过统一管理角度去简化管理，但对于用户而言仍然不得不去面对复杂的使用问题。如果通过统一接口提供能力，无疑对用户非常有吸引力，这就是简化融合诉求的来源。Database Plus 倡导的在数据库上层构建统一、标准、开放的生态，正契合这一诉求。未来对数据库的使用，完全可根据上层统一标准来实施。针对如数据安全、访问审计、访问控制等诉求，都可考虑在上层解决。当然这里面难点不少，如何抽象屏蔽下层复杂细节值得深思。

自主可控

对基础软件来说，自主可控非常关键。作为数字化的载体，数据库的自主可控能力尤为重要。近些年国产化诉求日益高涨，也有着这方面的考虑。这其中值得关注的一点是关于开源的使用。SS 作为Apache开源的顶级项目，在这里无疑是有优势的。通过顶级、权威开源基金会的扶植，会使得开源项目更加健康发展。

3、对 Database Plus 的发展畅想

Database Plus，作为一种新的数据使用思想，还处在相对早期阶段。但通过这一理念落地的成果-SS，已展示出不错的发展态势。在底层成熟的数字基础设施之上，以开放、标准、可插拔为指导原则，构建面向增值能力的数据应用基础平台。帮助用户快速提升数据应用水平，构建标准的数字化基础设施，其前景未来可期!

作者介绍

韩锋，51CTO社区编辑，CCIA（中国计算机协会）常务理事，前OracleACE，腾讯TVP，阿里云MVP，dbaplus等多家社群创始人或专家团成员。有着丰富的一线数据库架构、软件研发、产品设计、团队管理经验。曾担任多家公司首席DBA、数据库架构师等职。在云、电商、金融、互联网等行业均有涉猎，精通多种关系型数据库，对NoSQL及大数据相关技术也有涉足，实践经验丰富。曾著有数据库相关著作《SQL优化最佳实践》、《数据库高效优化》。

关键词： 基础设施 数据安全 分布式数据库 计算能力 涡轮增压