暂无图片
暂无图片
暂无图片
暂无图片
暂无图片

企业数据库工作5:DB DevOps

程序猿读历史 2025-02-08
16

01

企业数据库工作1:数据库选型,除了TPS、QPS还要关注什么?



02

企业数据库工作2:团队培养,如何高效阅读数据库文档



03

企业数据库工作3:数据库连续性,我们该知道什么



04

企业数据库工作4:连续性,我们该怎么做



DevOps 早已不是新鲜词语,但目前行业内这一概念主要还是针对开发与运维的高效协作和敏捷发布,数据作为企业最核心资产,数据库又是承载核心资产的组件,却较少涉及。本文将详细讨论数据库 DevOps 的现状、问题以及解决方案,不涉及数据库的性能优化、备份恢复、监控告警等运维工作。
01 DB DevOps 企业现状

当前企业的数据库现状可用 “多、少、大、小” 四个字总结:

    多:类型多,数量多,环境多,使用人员多,生产变更多
    少:投入少,DBA少,维护窗口少。
    大:规模大,影响大,重要性大。
    小:小问题引起大故障,小人物扛大锅。 
    复制

    几乎在每个公司都能听到这样的抱怨。普通员工:执行一个数据库工单太费劲了;确定测试环境的表结构和生产一致吗?就看一个配置数据,不是用户数据,更加不是敏感信息,也要发起这么长的审批流程吗?管理层:我们100多位研发每天产生大量SQL,能保障没有性能问题吗?上次就是一个慢SQL,导致系统崩了几个小时;生产用户敏感数据都加密了吧。

    如果说这些抱怨还可以忍耐,那么下面这些问题却是每个IT团队无法回避的。业务方都希望尽快发布,而技术TL却对系统稳定性非常关注。其次由于研发人员众多,无法保证每个人的研发能力、数据库规范等有相同认知。这使每次数据库发布,一方面是需求紧急,希望尽快发布;而另一方面却无法保证发布质量,希望在可控的变更窗口,通过“人挑肩”的方式去规避风险。

    这种退而求其次的解决办法几乎让所有人都不满意,业务不满意发布效率,技术TL对系统稳定性提心吊胆,工程师们享受着996的福报时,还要忍受着shi一般的流程体验。

    这些抱怨、问题的来源,一方面是现代企业整个数据库架构是比较复杂的,根据 Redgate 2021 年数据库 DevOps 状态报告发现,70% 的企业使用一个以上的关系型数据库,48% 的团队使用三个或更多类型的数据库;另一方面是数据是企业的核心资产,而数据库又是承载这一核心的重要组件,企业却是通过复杂的制度、臃肿的流程、低效的操作来满足团队各角色之间对数据库、数据的不同要求。

    图片来自 Redgate 2021 State of Database DevOps

    为了解决数据库快速变更、安全交付,同时保障数据一致性、系统稳定性及合规性,Database DevOps 应运而生。那什么是DB DevOps呢?
    02 DB DevOps 是什么

    在讨论DB DevOps 前,先回顾下什么是 DevOps。其实行业对 DevOps 并没有一个明确的定义,只是在2007年前后,IT先行者们提出:软件开发者与软件维护人员的完全分离,给行业发展带来挑战了。人们希望有一种方式,能打通软件开发与运维壁垒,通过自动化、持续交付和跨团队协作,加速软件交付流程并提升系统稳定性,建立端到端的软件敏捷交付体系。

    • AWS的定义:https://aws.amazon.com/devops/what-is-devops/

    • 谷歌的定义:https://cloud.google.com/devops#section-2

    • 微软的定义:https://azure.microsoft.com/en-gb/overview/what-is-devops

    • IBM的定义:https://ibm.com/think/topics/devops

    而DB DevOps 是广义 DevOps 中的一个分类,即通过自动化、共同协作和持续集成、持续交付和持续部署(CI/CD),实现数据库变更的快速、安全交付,同时保障数据一致性、系统稳定性及合规性。从而有效的帮助研发团队快速响应业务需求,优化开发效率,以实现快速上线发布,同时使 DBA 更高效的管理数据库变更、版本控制和部署过程。

    一般企业中DB DevOps 主要工作包括以下内容:

    • 变更管理:跟踪数据库变更,并提供回滚和恢复功能。

    • 版本控制:管理数据库 schema & metadata 的版本。

    • 生产部署:将数据库变更部署到生产环境。

    • SQL审核:审核数据库生产变更,以确保生产变更符合技术规范以及企业安全要求。

    • 访问控制:实现数据屏蔽、访问控制、敏感数据自动检测&发现&加密等措施

    03 DB DevOps 怎么做

    前面说了,DB DevOps 是广义的 DevOps 子类,即通过自动化、共同协作和持续改进,实现数据库变更的快速、安全交付,同时保障数据一致性、系统稳定性及合规性。那如何去实现这一目标呢?这就需要用到相关数据库版本管理工具。

    提到数据库版本管理、变更发布工具,就不得不说两个老牌产品: Liquibase 和 Flyway ,他们都是国外商业公司开源的优秀数据库版本管理产品,其中Liquibase 诞生于2010年,Flyway 则是2012年。

    下图是笔者整理的国内外 DB DevOps 相关产品。从图中可知,目前国内有非常多优秀产品,比如DMS、Bytebase、SQLE、CloudDM、Yearning、GoInsight 等,限于篇幅本文重点介绍:Flyway、Archery 以及 NineData 

    3.1 Flyway

    Flyway 是老牌数据库版本管理、变更工具,其核心能力是将SQL脚本发布到数据库,并对SQL脚本进行版本管理。2019年,Flyway 被英国著名软件公司 Redgate 1000万美元收购,收购后其社区版依旧保持开源。目前,Flyway 在 github 上有 8.5k stars、1.5k forks,在starts 数上较大幅领先老对手 Liquibase 。

    Flyway 的核心能力是将用户要发布的SQL脚本,分发到开发、测试、生产等环境,同时保障每个环境的数据库变更指定版本,从而确保数据库变更的一致性和可重复性,避免因环境不同导致的问题。他的企业版提供了高级能力,比如版本回滚、SQL 脚本、数据库结构和数据对比等。

    Flyway 虽好可有一些不足。比如SQL审核能力并不强大,SQL 审核因子只有16个,而国内相关产品均有100+以上的审核因子。其次 Flyway 主要还是通过 CLI (Command Line Interface)模式交互,只有在非生产环境有一些简单的 GUI(Graphical User Interface)能力,这导致其 SQL 窗口能力并不强大。另外,Flyway 目前只支持不到30个数据库,而国内相关优秀产品支持50+以上。

    图片来自 Github Flyway

    3.2 Archery

    Archery是一款基于Python Flask框架开发的开源数据库管控平台。主要功能包括 SQL 工单提交、审核、执行、变更、备份、归档等功能,均通过GUI 交互。Archery 开源免费,目前在 github 上有 6.2k stars、1.7k forks,有着较活跃的社区。

    图片来自 Github Archery

    从其功能清单可以看出,Archery 主要对 MySQL  支持比较友好,在其他类型数据库上的功能并不多。同时 Archery 的SQL 审核规范是通过配置文件实现的,审批流程也相对简单。但作为一款由社区推动的数据库DevOps工具,对中小企业而言已是足够优秀,如果有能力在此基础上进行二次开发,将会是不错的选择。

    3.3 NineData

    NineData 是近年的数据库 DevOps 领域新秀产品,是一套云原生 SQL 开发工具,具有数据资产管理、数据查询、SQL 执行、数据编辑、数据导入导出、SQL 审批流、SQL 规范预检、审批流程、敏感数据保护等强大功能,帮助用户快速完成多种环境的数据库管理。

    从NineData 文档介绍看,目前支持 60+ 类型的数据库,SQL 审核规则近200项,以及丰富的 SQL 窗口能力。除此以外,NineData 还具备多种形式的数据加密、数据水印、白名单访问控制等安全访问控制,为企业构筑牢固的数据安全、访问安全红线。目前有三个版本,分别是个人版、专业和企业版,其中个人版永久免费。

    图片来自 NineData Document

    04 总结

    当下企业中的数据库“多、少、大、小” 特点下,数据库DevOps 是具有重大价值,通过自动化、共同协作和持续集成、持续交付和持续部署(CI/CD),实现数据库变更的快速、安全交付,同时保障数据一致性、系统稳定性及合规性,让天下没有难用的数据库。

    文章转载自程序猿读历史,如果涉嫌侵权,请发送邮件至:contact@modb.pro进行举报,并提供相关证据,一经查实,墨天轮将立刻删除相关内容。

    评论