数据库架构优化的12种组合方式与风险解读

大家好，我是韩锋，一个数据库领域资深从业者（好吧，我是个70后）。近些年来，主要从事数据库产品、架构等工作。本文我将以个人感受，谈谈在新时期下数据库架构优化工作的一些问题，供大家参考。

下面的分享，我将从外部环境对数据库架构的影响、当前架构中若干热门的技术问题、之前的架构实践经历，以及个人如何成长等方面谈谈我的感受。

首先谈下外部因素对架构工作的影响。有些同学可能会感到疑惑，架构问题不是技术问题嘛，为什么还要考虑外部因素？这里是有个误区的，架构的本质是为了解决企业的业务问题，针对某一问题可能有很多种解法，选择最为合适的（而非最优的）是考验一个架构师的核心能力。

正如上图中，右下角的描述“脱离企业环境的架构，都是耍流氓”。那么影响架构的外部因素有哪些呢？

下面将以一个较为传统的企业客户视角，看看其内外部的需求是什么？这些因素都将对后续的架构设计，带来很大的影响。

对于外在需求部分，可分为如下几个方面（有优先级顺序）：

对于内在需求部分，可分为如下几个方面（有优先级顺序）：

企业、部门、团队的情况，也会对架构选择有所影响。

如之前环境篇开篇谈到的问题，公司所处行业、性质及发展阶段对架构选择存在不同影响，这里就不赘述了。

下面的技术篇中，我将谈到企业使用数据库的方式及对当前一些技术选择的个人观点。

这是较为传统的一种方式。企业购买大型商业数据库软件，并对应购买服务支持工作。在过去三、四十年里，这是主流方式。可以说也很好地满足了各类企业的快速发展。只是随着近二十年来，互联网化的变革，对此种方式产生了不小的冲击。

这种方式适合传统企业，对数据库要求较高，自有技术能力有限，未来发展相对固定的情况。未来发展随着商业数据库的发展而变化，从总体来看，未来云化的需求对其冲击较大。此外，在国产化、自主可控化等要求下，也会对这个模式影响较大。

风险分析：

这一方式也较为常见。在前一方式中，随着企业使用商业软件的深入，自有服务需求就变得迫切起来。通过建立自有服务体系，可以更好地满足企业自身需求。这种方式，适合有一定技术积累的传统企业。未来发展随着商业数据库的发展而变化，总体相对稳定。

风险分析：

在风险方面，与前者类似。其中技术风险上，自有人员对商业产品的把控，较原厂还是有所差距。当然对应人员风险就降低，通过自有人员对产品把控力更大。

随着开源数据库的日益成熟，越来越多的企业开始使用开源数据库。但相较于商业数据库，开源方案对企业自有技术能力要求较高。因此，很多考虑搭上开源浪潮的企业，采用这种方式。适用于转型中的企业，从商业走向开源，这种方式可以在一定程度上规避风险。但一般为过渡阶段，长期来看还是要培养企业自有的服务能力。

风险分析：

这是典型的“互联网”玩法，也是较为常见的一种方式。适用于规模较大，企业定制化要求较高的场景。发展成熟可考虑向企业内部私有云或数据库产品、方案方向发展，甚至对外赋能。

风险分析：

风险分析与上者类似，突出人员风险，需长期培养投入。

这是方案3的一种特殊情况。企业不是使用原生开源产品，而是使用第三方公司定制开源方案，可能是纯软件，也可能是软硬一体式。这类方式，会针对开源软件的不足，做定制化改进，满足企业级软件的需求。但这种方式一般企业无法自己独立运维，需要借助第三方公司的商业支持。对数据库的企业级特性有较高要求，但原生开源数据库又无法满足的情况。对于短期内有去除商业数据库的需求场景，非常适合。随着国内对开源数据库使用水平不断深入，有越来越多的此类初创型企业出现。非常看好这种模式的未来发展。

风险分析：

企业私有化部署方案，是一种云化折中方案。受限于一些特殊国情，有些企业无法直接使用公有云，但又急需类似公有云的平台能力。因此，某些云厂商或数据库厂商提供了一种私有云化部署方案，可简单理解为将云搬回家。

过去有种说法，说私有云会逐步萎缩，公有云会一统天下。但从近两年的国内云市场发展来看，私有云的发展速度某些指标甚至超过公有云。当我们现在大谈“toB”市场成为下一个蓝海时，这种模式也是toB服务市场的一个重要组成部分。这种方式，适合于大型企业，长期看好。

风险分析：

其风险点除了在财力方面，更多是考虑在对厂商的技术依赖性。相较于传统方案，这种方式的依赖性甚至更高。厂商一般提供很好的私有云，及对应其自有公有云的打通方案；但对其他公有云或企业自有平台，则较难打通。

这是一种上云使用的初级阶段，企业仅使用云的IaaS部分，其余均自建。这种方式可充分利用公有云带来的弹性优势，将企业原有的技术积累延续到云端。对于企业来说，这种方式也是最为“平滑”的，甚至应用可以不做更多感知，仍然像使用企业内部IT资源一样，使用公有云资源。很适合于有多云、跨云需求的场合。但缺点是无法利用云厂商技术能力带来的附加值。

风险分析：

风险不大，仅仅是依赖公有云底层，很容易迁移到其他云厂商或迁回自有。

这是一种较为特殊的情况。企业选择将商业数据库，构建在公有云上。但其没有选择云厂商提供的，而是自主构建或选择第三方厂商协助完成。这往往是一些中小型的企业，其规模不足以支持私有化部署，而应用又依赖于商业数据库产品。企业想要充分利用云的弹性，因此组合出这种使用方式。

风险分析：

风险在于，某些商业数据库针对云场景的不予支持，企业有一定技术风险。要么有比较强大的自主技术能力，要么依赖于第三方服务厂商。

这是云厂商推出的最为“传统”的数据库服务，也是目前最多的一种选择。云厂商基于开源的数据库版本+自有的平台服务，构建其数据库产品。其核心的数据库与开源的版本，是完全一致的，各家比拼的更多是平台服务能力。这种方式对于企业的运维要求很低，基本可以依赖于云厂商提供的能力（除了个别高可用、容灾需求外）。这一方案比较适合于初期上云企业，可逐步摸索云与原有方式的区别。

风险分析：

数据库自身风险不大，毕竟其使用的与开源同一版本，技术上可迁移至其他云厂商。当数据库版本升级后，也可以享受到对应的技术红利。但对平台服务，是存在一定依赖的，各家能力不同，需要有适应过程。此外，运维依赖云厂商，也存在一定技术风险。自主的技术能力，会逐步丧失。

云厂商除了提供与开源一致版本外，一般还提供私有定制版本。它往往是基于某开源数据库某一版本的深度定制，针对某些特性做了加强。当然有些以反馈社区的方式，回馈给开源（可能未来会merge入新版），但很多仅存在“云私有DB”。如企业有针对某一特殊场景（如秒杀）或其他方面（如金融级数据同步）的强需求，可考虑使用此方案。当然使用也意味着与云厂商深度绑定。此外，在平台服务方面，与上面情况类似。这种方案比较适合于对数据库有一定要求，而原生开源版本又不支持的情况。

风险分析：

风险在于绑定单一厂商，一般很难下来。这与使用大型商业数据库的情况类似。当然可以在应用端做个设计，尽量减少对特性的依赖。此外，因为是定制版本，未来开源版本的升级可能不会短时间内支持，甚至可能不会考虑支持，完全走向独立分支的道路。针对这点，企业也是需要关注的。

某些大的云厂商，除了上述两种外，可通过自研数据库方式，增加未来的产品竞争力。从最新的Gatner报告来看，更多的云厂商加入进来，这也给数据库整体市场带来了活力。从预测来看，均一致看好云原生数据库的未来发展。相较于前两种方式，这类数据库更是诞生于云，从设计之初就更多考虑了云化环境特点，因此极具竞争力。

当然，从目前来看，现有云原生还处于“初级”阶段，未来在解决了更大规模扩展性、多读多写能力等后，其将真正进入井喷式发展。现有各大厂，在这一领域纷纷重点布局，加大投入。对企业而言，无疑又多了一种选择，特别是某些场景（如海量数据等），原生开源、扩展开源产品均无法满足。

风险分析：

风险类似上面，甚至有过之。企业应用将完全依赖于厂商产品。尽管很多是宣传兼容开源或商业数据库，但毕竟不是同一产品。这点还需要企业仔细评估。此外，针对兼容性、备份恢复、高可用、数据同步、跨云容灾等，都是值得投入研究的。

这是一类小众的方案，其背景是缘起于数据库厂商与云厂商的蛋糕划分问题。有些数据库厂商（如MongoDB）不希望将云数据库市场由云厂商主导，而是希望可由自身主导，构建不依赖于云厂商的独立生态。目前这种方式国内见得不多。

受到众多互联网公司的影响，很多传统企业对于开源方案也是跃跃欲试。但在选择之前，也要看到，开源方案并不是免费的“蛋糕”。让我们来看看，开源方案的利与弊。

对于托管类数据库产品而言，其核心功能还是要跟官方产品走。当然，各个大厂都有着自己多年丰富的实践经验，并具备一定的内核研发能力。于是，往往针对原生产品做一些定制化的改造，进而提供与原生产品差异化的能力。改造方向上，往往倾向于下面几类：

针对上述定制化后产品，有时就成为某种“银弹”，对于企业客户很具吸引力；但事情也具有两面性，对于这些特殊之处的依赖，也会导致客户对产品的依赖。这也是某些客户犹豫之处。在我看来，这个问题的要点在于企业处于的发展阶段。不同阶段的企业，核心诉求不同，在此处的考虑角度也会不同。

 ② 外围功能

除了核心功能外，还有些非数据库核心能力，但对于企业使用必不可少的功能。例如：监控、备份恢复、优化、容灾等等。如果没有云的话，这些能力往往是需要企业花费精力去自建的。哪怕企业数据库规模不大、使用复杂度不高，使用开源数据库也能满足需求，但上述需求还是要满足的。于是，前两年平台很火，很多企业都自建了自己的内部运维平台，构建上述能力。当然这种方式有利有弊。利之处在于，企业可以根据自身需求度身定制，满足个性化需求；弊之处在于，构建能力及花费资源长期维护。

如果说，上述功能企业还是可以较容易具备的，那么云功能则相对门槛有些高了。这里所说的“云功能”，是指例如弹性扩缩容等类。这类能力，往往需要依托于强大的底座能力，是需要较大的研发投入和长期积累才能具备。在某些特定的场合下，这一能力对企业很具吸引力，例如业务形态、幅度变化很大的企业客户。

企业选择上云，往往不是仅依靠一两款产品，而更多是看中云端生态功能。对于企业来讲，如何通过云端打通技术瓶颈，快速具备业务能力成为核心。例如从数据埋点、数据捕捉、数据存储、数据计算到分析展示，如果全流程都可以在云端无缝集成，对于企业来说，是很具有吸引力的。

无疑，这是云数据库颇具优势的方案。企业如果想通过自建方式解决类似问题，没有高素质的人才是不行的。然而，一方面此类人才稀缺且价格不菲；另一方面即使已有人才，也要面临如何留住等问题。毕竟对于大多数企业来说，专业技术人员更多是辅助性岗位，对高级专业人员来说也面临长期发展等问题。而云数据库方案，则不存在此问题，你大可以在很短时间内享受到大厂的“脑力”资源，而且不必担心出现断档等问题。

针对这点，是需要企业充分衡量的。如果通过自建方式，是初期投入大，中长期投入较少，存在一个明显的波动性。如果通过外购云服务方式，则相对较为平均。两者的财力分配方式不同。当然，云有一个明显的优势，就是弹性。企业可根据自身情况，灵活选择，随时调整。

这是企业往往容易忽略的问题，时间投入也是一种成本。当你的企业快速发展，需要短时间具备某种能力；当你面临新业务上线，而后台IT就迟迟跟不上节奏。隐形的时间成本，有时对企业颇为重要；对稍纵即逝的业务机会来说，稳健、敏捷的IT支撑能力很重要。

很多企业是需要一个“兜底”的服务，即尽量降低企业的IT风险，保证企业的正常运营。自建的方式可以解决，但需要构建起整套的能力，投入不小；也可以通过购买外部服务的方式，这种就需要考察对方的技术实力、并解决互相扯皮等问题。云厂商，则不存在此问题，基本可做到风险可控。

作为三大核心基础软件之一，数据库在整个IT技术中占据重要的位置。随着近些年来中国经济的快速发展，特别是庞大的人口基数带来的红利效应，互联网技术在中国蓬勃发展。甚至在某些技术场景下，相较于国外有着更高的要求。这也促进国内企业在IT基础技术（包括数据库）上取得了长足的进步。国内企业对数据库的使用大致走过了“商业->开源->开源+定制->自研”逐步演进的道路。近些年来，随着技术、资本、人才的积累，国内的数据库领域取得很大的突破。

从数据库技术本身而言，随着分布式、云原生、软硬一体化、人工智能等技术的出现，为自研数据库代替大型传统商业数据库，实现弯道超车提供了可能。同时这些技术的出现，也解决了很多传统数据库固有的问题，突破了旧有架构的缺陷，更好地满足客户对海量、弹性、安全、性能等方面的要求。没有传统数据库厂商的历史包袱，新兴厂商站在更高的起点上，实现对传统厂商的超越。

虽然有些企业在去除大型商业数据库实践上，已经有十余年的时间；但大多数都是限于企业内部。受限于其内部场景，很多实践经验是很难复用到外部企业。且也没有一个完整、成熟的商业化产品提供此类服务。但是近些年来，已可以明显看到一些变化，以云厂商为代表，正在将企业内部多年的经验积累以产品的化的方式输出，帮助广大客户完成这一过程。

针对这样一个基础软件的替换，我们需要清醒地认识到，不是简单的“苹果换成桔子”的过程。这需要从架构设计、程序开发、运维安全等多个角度去看待。之前很多企业在抛弃传统商业数据库上举步维艰，正是因为缺乏必要的经验指导，无法将好的技术快速落地并稳定运行。在这里需要重点强调的是，很多企业认为选择一个功能非常强大的数据库，就可以帮着自己摆脱传统商业数据库。其实，这是一个大大的误区。功能强大的产品，不一定是适合你，要想完成这一过程，云数据库厂商的实施经验不可或缺。只有“好的产品+丰富经验+良好服务”，才能最终达成这一目标。

企业（特别是传统企业）在数据库使用上，按需求的优先级排序，可分为服务、生态、自主、成本等多个因素。这里最被企业看中的，正是“服务”一环。很多企业使用大型商业数据库多年，已经习惯于传统数据库厂商的“交钥匙”工程，非常看重其完备的服务能力，使得企业可以安心于业务。即使每年付出昂贵的服务费，企业仍然可以接受。这点也是国内厂商的短板，要在短时间内建立其等同于国外数十年积累的企业服务能力，不是一朝一夕的功夫。这是需要国内厂商静下心来，苦练内功，加大投入。经过几年来的积累，国内的云厂商已具备了较为成熟交付服务提醒，形成了规范化的服务能力。

传统大型商业数据库，颇令人诟病的一点就是“贵”。究其根本原因，一方面是其商业策略有关，此外也有人力成本、服务方式等因素有关。此外，还有很容易忽略的一点，就是旧有架构的问题。随着新架构的演进、技术的突破，特别是“数据库+云”的结合，为客户提供更灵活、更具性价比的数据库方案成为可能。

随着数字经济的到来，各类企业都在做着数字化转型，新的业态也不断涌现。这对于支撑企业数字化转型的重要基础设施—数据库，提出了更高的要求。如何满足快速多变的业务模式创新？如何满足快速发展的业务规模需求？等等诸如此类的问题，都是数据库产品需要考虑的。国产数据库正是站在这一高点，从国内情况出发，有针对性地推出很多功能，满足这种创新。

下面以笔者之前在某公司的实践过程，谈谈对架构实践的理解。这里将从需求、资源、路径、成长角度来谈。

第一步，就是现状分析。俗话说，磨刀不误砍柴工，只有对现状充分的了解，找出核心痛点，才能有助于问题的解决。无论是从架构调整还是其他工作都是如此，只有解决痛点才是对公司有价值的。

第二步，就是路径演进。很多架构工作或其他技术工作，都不是一蹴而就的，而是有个逐步演进的过程。正如上面提到的，在之前公司的数据库开发设计规范的落地，也是走过了文档化->技术宣讲->自研平台的过程。

团队的情况也很重要。只有统一思想、明确方向，才能有助于最终落地起效。

最后，我们谈谈对架构师作为个人成长方向的一些问题。相信很多做技术的同学都存在上述的问题：做技术还是做管理？年龄因素怎么看？技术革新太快，如何破？等等。

首先我们从企业内部数据应用层次来看，从最为原始的满足事务型处理需求，DBA更多是充当救火队员的角色；到逐步规模化、体系化，DBA通过平台处理运维工作甚至可做到预防性运维；再到运维工作已不是主要矛盾，企业开始关注数据库设计、开发质量问题，DBA需要更多考虑架构侧问题；最终到脱离具体变相的库的形态，而从更为维的数据层面考虑企业内的数据架构问题。

企业内部对数据的应用层次的演进，其实也是DBA从运维、平台、设计、优化、架构的演进过程。可以说，伴随者企业发展，数据一线从业者都会慢慢具备一定的架构类职能。这也是技术人，比较理想的一个发展路线。

从一段时间来看，DBA职业正受到很大的冲击，这里包括：

这是个老生常谈的问题，做技术还是做管理？我的观点是，选择哪条路径，取决于个人特质，不同的思维方式适合做不同的工作。不要勉强自己做不适合的职业选择。

技术的路能走多长？这是很多人的疑问。难道每个人都能发展成为CTO吗？显然这是不现实的。无论是技术路线还是管理路线，其发展都是有阶段性的。对于迈入到更高的台阶，都存在一定比例的选择率。大部分人，是无法上升到更高的阶段，要理性地看待这一问题。并在达到自己阶段瓶颈后，找出后续的发展路线。说句时髦的话，就是所谓第二成长曲线。

承接上面，每个人发展都是存在一个阶段性上限。当达到这一阶段时，你会发现很难突破自己，此时可以考虑所谓T字性人才发展策略，即横向发展。但这里需要注意的是，一定是在某一领域内接近自己所能达到上限，因为这会决定你的“视野”问题。在横向发展的选择上，可以有很多。例如右面列出的技术上的其他领域、业务方向的沉淀或者参与人的工作（管理）之中。

Q1：如何看待列式数据库的前景以及其在互联网企业中应用场景？

A：列式数据库，主要是说数据存储方式采用列存方式。现在很多数据库都支持行、列混存的模式。其面对数据分析类场景时，列式存储天然有其优势。企业中的分析场景，可以考虑使用列式存储。

Q2：开源数据库的安全隐患大吗？安全性是否需要重点考虑？

A：开源数据库的安全问题，不能一概而论。只是一般意义上，开源产品在某些企业特性上较商业产品还是有所欠缺，安全性是其中之一。当然，随着很多开源产品在企业中的到日益广泛的应用，安全性问题也得到很多开源的重视，不断补齐、增强这方面的能力。

Q3：如何选择国产数据库？

A：随着近些年来国产数据库的蓬勃发展，无论从产品数量、成熟度还是使用广泛程度，都取得了长足的进步。在企业考虑选择使用国产数据库时，个人建议优先考虑功能、服务、生态、性能的因素（有优先级顺序）。

Q4：如何看待国产数据库，特别是分布式国产数据库的前景？

A：无论从内外部环境，还是IT本身发展规律，都很看好国产数据库的发展。这也是我们必要需要经历的一个过程。比较欣喜的看到，近些年来国产数据库发展很快，并逐步获得很多关注。相信在不久的未来，必将得到更大的发展和普及。

分布式数据库，是一个发展方向，其在解决容量、性能等核心问题上，有着天然的优势。随着学术上的成熟，在工程领域已经很多产品出现，并取得不错的成绩。

Q5：分库分表清除历史数据有什么需要注意的点？

A：分库分表架构下，对于清理数据会带来一定的复杂度。核心点在于有统一的清除标识，方便进行清理工作。

Q6：请问CK数据库怎么解决并发支持不高的情况？

A：对CK了解不多，谈写粗浅认识。对于分析型数据库而言，并发问题是个老大难问题。其核心问题是在于资源瓶颈。场景的解决方式：1.通过扩展资源，提高吞吐能力，变相提升并发支持能力；2.通过资源隔离方式，满足部分高并发场景需求；3.通过拆分方式，分流并发需求等。

Q7：类似于TiDB这种整合的数据架构解决方案，前景您怎么看？

A：非常看好类似TiDB的整合方案。整合方案的核心点在于，数据集中存储、统一接口、统一管理，这对于用户是很有吸引力的。解决了用户对于管理、运维、人力、开发、成本等多方面的问题。当然，还是有小部分场景无法通过整合架构解决，但对于大多数客户、大多数场景，整合架构还是适用的。

Q8：对于数据库技能的积累上，是如何储备的呢？SQL、NoSQL、NewSQL是否都有必涉足？

A：存储哪些技能，核心还是取决于现实需求。这里不仅包括数据库技能，也包括其他技能是同样的道理。技术发展演进是很快的，需要人员具备快速学习的基本能力。只有适应这种变化，才能更好地适应未来发展。

Q9：请评估一下阿里的AnalyticDB这种实时分析型数据库，并且还能支持高并发？

A：AnalyticDB是阿里云自研的云原生数据仓库。在其初始设计中，就考虑了高并发的需求。在其前端接入节点部分，是支持扩展能力，可提供近似线性的扩展能力支持。

Q10：数据库架构师的方向可以突破35岁的限制吗？

A：架构方向，是技术人发展的一个方向。对于人员的知识结构、经验积累等，均有较高的要求。在年龄方面，限制度较其他岗位（如研发）要宽泛很多。我本人经历，也是在35+，才开始转型到架构方向。

特别推荐一个分享架构+算法的优质内容，还没关注的小伙伴，可以长按关注一下：

长按订阅更多精彩▼
如有收获，点个在看，诚挚感谢