点击上方👆蓝字关注我们！
为什么要做数据库选型
数据库选型的重要性与难点
发展数字经济是当下各行各业的重要方向。支撑数字经济的底座是软件，特别是基础软件，可以说基础软件是整个数字经济的坚实底座。在基础软件领域，有三大基础软件，分别是操作系统、数据库系统和中间件。我们每天日常生活中的方方面面，背后都离不开这些基础软件的支撑，其中数据库系统是业务数据的载体，比如银行卡上的余额，是非常重要的数据，不能有任何差错，数据库在所有IT系统中的地位都是重中之重。
数据库作为基础软件的重要性不言而喻，各行各业的数字系统都离不开数据库系统。但不同行业特点不同，行业需求也就不同。面对着业界上百种数据库类型，到底应该如何根据自己的业务特征去选择最合适的数据库系统？这个问题非常的重要，因为如果数据库选择不合适，可能会让业务系统停摆，造成严重经济损失。所谓合适的数据库系统，不仅仅要满足业务需求，还要尽可能降低成本，减轻运维管理难度，满足业务未来的发展等等。这是个复杂的问题， 因为各行各业的业务场景各不相同，对数据库的需求和使用场景差异很大，可选择的数据库系统也是几十上百种，如此一组合下来，对于非数据库专业人士，选择复杂度非常高。
本文的目的就是要尝试回答这个重要且复杂的问题。如果您计划将 IT 业务系统部署在火山引擎之上，可以参考本文的思路，选择合适的火山引擎云数据库服务，为业务应用打造坚实的数据库底座。
数据库发展与类型简介
数据库系统在上世纪 70 年代初出现，至今已经发展了半个多世纪，其理论、技术与产品已经非常丰富，呈现出百花齐放的景象。根据其特点可以大概分为 关系型数据库管理系统（RDBMS） ， 非关系型数据库（NoSQL） ， NewSQL 、 云原生数据库 、 分布式数据库 等等。每一类数据库中使用不同的技术实现，又可以分化出不同的产品类型。根据 DB-Engines 的统计，数据库产品数量已经有将近 400 种，数据库厂商也有几百家，如下图所示，不同数据库产品的实际应用规模也大有不同，其中关系型数据库管理系统是所有数据库中使用最广泛的一类。同时，根据卡内基梅隆大学维护的全球数据库信息库（dbdb.io）显示，数据库系统种类已经多达 870 种，可谓是欣欣向荣，让人眼花缭乱。
纵观整个数据库发展史，关系型数据库系统是历史最悠久并且使用最广泛的一类数据库系统，其理论基础是基于 IBM 研究员 E.F.Codd 博士在 1970 年提出的“关系模型（Relational model）”。关系型数据库也是过去几十年里各行各业使用最多最广泛的数据库类型。
随着 2000 年之后移动互联网的大规模爆发，催生出了丰富多彩的面向互联网的应用，这些应用共同的特点是并发量非常高，数据量特别大。基于这些互联网的新场景与新需求，又出现了 NoSQL 数据库技术，其理论基础主要是由 Eric Brewer 提出的 CAP 定理以及 Dan Pritchett 提出的 BASE 原则。
再往后，业界将关系型数据库与 NoSQL 数据库的优势进行了融合，出现了 NewSQL 数据库，随着云原生技术的入场与爆发，又有了云原生数据库。
关系型数据库 将数据存储于二维表格之中，数据以行为单位，一行数据表示一个实体信息，每一行数据的属性都是相同的，通过 SQL 语言进行操作，容易理解，广泛应用于企业的 ERP、CRM、财务系统和交易系统等核心业务系统。其 最大的特点是支持事务，遵循 ACID，保证数据强一致性 。业界常见的关系型数据库又分商业数据库与开源数据库，其中主流的商业关系型数据库代表有 Oracle、SQL Server、DB2 等；主流的开源关系型数据库代表有 MySQL、PostgreSQL、MariaDB 等。
NoSQL ，Not Only SQL，"不仅仅是 SQL"，广泛应用于以互联网业务为代表的场景。NoSQL 数据库又可以 细分为 KV 型 NoSQL 数据库（以 Redis 为代表）、文档型 NoSQL 数据库（以 MongoDB 为代表）、宽列型 NoSQL 数据库（以 HBase 为代表）、时序型 NoSQL 数据库（以 InfluxDB 为代表）以及图 NoSQL 数据库（以 Neo4j 为代表） 。虽然这些类型都属于 NoSQL 数据库范畴，但是不同类型的 NoSQL 数据库所适用的场景各有不同，需要根据业务特征选择合适的 NoSQL 数据库。
其中 KV 型 NoSQL 数据库适用于需要超高性能，读远多于写，并且可以容忍数据部分丢失的场景，例如作为关系型数据库的外部缓存，用于提升系统整体的读性能，减轻关系型数据库的读压力。
文档型 NoSQL 数据库使用的是一种半结构化的数据模型（json 或 xml 格式），与关系型数据库相比，文档型 NoSQL 是没有 Schema 的，由于没有 Schema 的特性，可以随意地存储与读取数据，因此文档型 NoSQL 数据库解决了关系型数据库表结构扩展不方便的问题。
宽列型 NoSQL 数据库，主要用在大数据、OLAP 场景。其特点是可以提供海量的存储容量，PB 级别数据量可以轻松存储，并且成本较低。
时序型 NoSQL 数据库主要应用在一些与时间强相关的数据模型，例如 IoT、监控数据等场景。对于时间序列相关的数据，时序型 NoSQL 数据库的处理与关系型数据库的处理方式是不一样的，时序型 NoSQL 数据库主要是有效地收集、存储和查询高频产生的各种时间序列数据，对此做了专门的设计和优化，专门用于这类场景。
图 NoSQL 数据库主要用于处理“关系”数据。这里的“关系”不是关系型数据库中的关系，而是指不同对象之间的联系。例如，社交关系(人与人的关系)、推荐关系(人与物的关系)、关联关系(物与物的关系)等等。这类数据用关系型数据库很难处理，特别是在互联网海量数据条件下更复杂，所以图 NoSQL 数据库主要是针对这类场景做了专门的设计与优化，用于进行“关系”数据的存储与查询。
从技术角度出发，数据库可以分为关系型数据库与 NoSQL 数据库。 从场景角度出发，数据库又可以分为 OLTP 数据库与 OLAP 数据库 。OLTP（Online trancaction processing），是关系型数据库的主要应用，侧重于交互式的事务处理，例如银行交易、在线订单处理等。OLAP（Online analytical processing) 是数据仓库系统的主要应用，支持复杂的分析操作，侧重分析决策支持，并且提供直观易懂的查询结果，主要跟大数据系统关系紧密。OLTP 与 OLAP 系统之间通常会使用 ETL 进行连接。
本文主要侧重于 OLTP 系统的选型指南，也就是上图中圆圈中的范围，包含关系型数据库与 NoSQL 数据库 。OLAP 与大数据相关不在本文讨论范围。
选型基本方法论
在开始介绍数据库选型方法论之前，首先需要介绍一个理念： “数据库选型没有银弹” 。就是说没有任何一款数据库可以满足所有业务场景的需求，找不到一个可以包打天下的数据库。
如果真有“数据库银弹”，那也就不必做数据库选型了，直接用银弹就行，数据库世界也就不会出现如此多种类的数据库技术和产品类型了。
所以需要根据不同的业务场景、业务需求去选择一款最适合的数据库系统，这也是本文所要讨论的核心问题。
参与选型的角色
数据库选型不仅仅是一个技术选择，而是一个全局选择。后面会从多种视角多个方面来说明做数据库选型需要考虑的因素，包括应用接口、数据模型、性能、稳定性、成本、运维复杂度、高可用性、安全性、扩展性等方面。
数据库选型是一个全局选择，参与到选择中的角色主要有三类：
- 开发人员 ，代表了业务和应用本身。
- DBA ，代表了数据库管理角色。
- 财务部门 ，代表了成本控制角色。
财务部门主要关注的是数据库系统的成本 ，需要根据业务系统的规模、重要性等方面决定财务投入，简单说就是准备花多少钱建设与维护数据库系统。投入越多，可以获得更强的数据库能力，也可以聘请更专业的 DBA 进行数据库维护，保障数据库系统稳定运行。企业组织中越是重要核心的数据库系统，会获得更多的资源投入。
DBA，Database Administrator，是数据库管理员的简称。从名字就能看出来， DBA 是负责管理数据库系统的角色，主要关注数据库的可运维性，包括监控告警、备份恢复、升级迁移、问题诊断工具、调优工具等 ；稳定性，包括高可用性、自动主从切换、手动主从切换、会话管理等；性能，包括 QPS、时延、吞吐量等；可扩展性，包括灵活变配、计算扩容、存储扩容等；安全性，包括 SQL 审计、操作审计、数据加密、数据脱敏等。
开发人员，是应用程序的设计者与开发者，也是数据库系统的实际使用者，开发人员设计的应用程序会直接与数据库进行交互，利用数据库进行数据的高效存取 。开发人员跟 DBA 的关注点有类似的地方，例如开发人员也会关注数据库的性能、稳定性、可扩展性。但除此之外，开发人员更关注的是数据库提供的接口和支持的数据模型，这一点直接决定了应用应该选择什么样的数据库。接口与数据模型包括了是否支持 SQL、是否遵循 ACID、数据一致性等等。
数据库选型考虑
数据库选型 首先需要考虑的应该是业务应用所服务的场景 ，是 OLTP 场景还是 OLAP 场景。如果是 OLAP，建议参考大数据相关选型指导；如果是 OLTP，可以参考本文的选型指导。
接下来是考虑应用的数据模型 。数据模型可以是关系型、半结构化、非结构化、KV 型等等。如果是关系型，可以选择关系型数据库；如果是 KV 型，可以选择 Redis；如果是非结构化或半结构化，可以从 NoSQL 数据库系列中选择适合的种类，需要看具体的数据模型。
如果业务应用对事务 ACID 是强需求，那么关系型数据库将会是最佳的选择，例如 MySQL、PostgreSQL 等。
接着要考虑业务应用对数据一致性的要求 。如果业务应用需要强一致性，那么优先选择关系型数据库；如果业务应用可以接受数据的最终一致性，那么各类 NoSQL 数据库都可以成为待选项，具体结合数据模型做进一步考虑。其中，MongoDB 可以通过调整本身的某些参数达到数据强一致的效果，开发人员需要关注。
此外， 除了考虑业务应用现阶段的需求，还需要为未来做考虑，这里面最重要的就是预估业务增量，包括对性能、数据量的预估 。如果业务在未来增速可能会很快，会需要更强的数据处理能力，或者需要更大的数据容量，那么也需要同时考虑数据库的可扩展性，通过扩展来获取更强的数据处理能力以及更大的数据存储空间，以保证业务应用可以平稳运行。
火山引擎云数据库选型参考
火山引擎云数据库提供了丰富的云数据库产品类型，包括开源数据库与自研数据库，同时也提供了完整的数据库生态服务，包括数据库迁移服务与数据库统一管理服务。接下来会简单介绍每一种数据库的特点与适用场景，便于选型参考。
关系型数据库 RDS
火山引擎云数据库 RDS 是关系型数据库的合称 ，RDS 支持 MySQL 引擎、PostgreSQL 引擎、SQL Server（暂未上线，敬请期待）引擎，同时提供了数据库管理、安全、灾备、监控、迁移等全套解决方案。 RDS 基于云原生架构部署，在扩展性、弹性和性价比方面有很大的优势 。
火山引擎云数据库 RDS 可以广泛应用于 互联网电商、游戏、在线交易 等场景，也可以承载传统 ERP、CRM 等业务数据，具备高可用、高性能、灵活易用等特点，已有多个行业的客户正在使用火山引擎云数据库 RDS 承载其在线核心业务系统。
云原生数据库 veDB MySQL
veDB MySQL 完全兼容开源 MySQL，采用计算存储分离架构 ，最大支持 128TiB 的结构化数据存储，单个数据库集群最多可扩展至 16 个计算节点，包含 1 个主节点与 15 个读节点。基于云原生数据库设计理念，云数据库 veDB MySQL 既融合了商业数据库高性能、高可靠、高可用的特征，又具有开源数据库简单开放、快速迭代、高效扩展的优势。经过字节跳动内部关键业务场景的锤炼和打磨，veDB MySQL 能够为企业提供安全可靠、性能优越、功能丰富的数据库服务。
veDB MySQL 已经在字节跳动内部广泛使用，承载了内部多条业务线的业务，例如抖音、广告、小说等业务。在 2021 年的春晚红包雨活动中，全国一共发起了 703 亿次红包雨互动，其中 veDB MySQL 的读 QPS 峰值达到 500w+，写峰值达到 360w+，良好的支持了当时的红包雨活动 。
veDB 现在正在公测阶段，欢迎试用 ： https://www.volcengine.com/product/vedb-mysql
缓存数据库 Redis
火山引擎缓存数据库 Redis 提供的是托管型的缓存数据库服务，兼容开源 Redis 数据库引擎 ，帮助您在云上轻松、快速地构建 Redis 数据库。缓存数据库 Redis 提供了高性能且安全的 Redis 数据库解决方案，按需计费结合动态扩展能力能够显著地帮助企业降低成本，同时也有助于消除管理、运维数据库的复杂性。
缓存数据库 Redis 在开源社区 Redis 架构上进行了大量优化，采用字节跳动内部实践的 Achemy 架构，极大提升了 Redis 集群的规模与稳定性。
文档数据库 MongoDB
火山引擎文档数据库 MongoDB 版是一款完全兼容开源 MongoDB 协议，且具备高可用、高性能的在线云数据库服务 。文档数据库 MongoDB 支持多种架构，能够满足业务灵活部署的需求。除副本集实例架构外，文档数据库 MongoDB 还提供了分片集群架构，以满足海量数据业务场景，同时提供了灾备、备份及恢复、监控等全套解决方案。在互联网（游戏、电商、直播、资讯、社交）、新零售等行业都有广泛的应用。 火山引擎文档数据库 MongoDB 即将上线 MongoDB 5.0 版本，敬请期待 。
表格数据库 HBase
火山引擎表格数据库 HBase 是基于 Apache HBase 提供的全托管 NoSQL 服务，兼容标准 HBase 访问协议 ，具备低成本存储、高吞吐、灵活扩展等优势。
表格数据库 HBase 具备以下优势，帮助您构建理想应用：
- 支持 KeyValue 数据模型。
- 高可用架构，Master 为包含两个节点的主备模式，支持 HA 实时检测。
- 存储和计算分离保证数据的高可靠，存储采用多副本机制，可用性不低于 99.5%。
- 支持实例变配，包括横向扩容和纵向扩缩容，还提供了监控告警等功能，实例管理简单方便。
图数据库 veGraph
图数据库 veGraph 是一款以属性图为基础结构数据的分布式云原生数据库，提供了海量关系的数据存储和毫秒级的在线查询服务，广泛应用于社交网络、欺诈检测、推荐引擎、知识图谱等场景 。
图数据库 veGraph 主要具备如下特性：
- 有向属性图。基于有向属性图（Property Graph），由点、边、点类型、边类型以及属性组成。
- 可视化图平台。查询结果可视化，支持图形化地展示数据的关联性，便于更高效地分析数据。
- 图管理。提供图管理、Schema 管理和通过图形化界面来配置数据导入等功能。
- 图查询语言。支持 Gremlin 图查询语言。
生态工具 DTS
火山引擎数据库传输服务 DTS（Database Transmission Service）提供了数据迁移、数据同步、数据订阅于一体的数据库数据传输管理服务 ，支持关系型数据库、非关系型数据库数据源间的数据传输，降低数据库之间数据流通复杂性，可在业务不停服的前提下轻松完成数据库迁移上云。相较于第三方迁移工具，数据库传输服务 DTS 可以更方便地创建和管理丰富多样、高性能、高安全可靠的传输链路。
小结
在传统自建数据库模式下，DBA 人员需要承担的运维工作会非常繁杂，从主机、存储、操作系统到数据库，每一层都涉及到复杂的运维操作。但是在云计算时代，火山引擎云数据库提供了完善的数据库运维体系，将很多常规数据库管理动作都封装为自动化功能，DBA 无需再去执行很多复杂的运维命令，直接通过火山引擎云数据库控制台一键即可完成。同时火山引擎云数据库控制台上也提供了完善的数据库指标监控仪表盘，可以从多种维度观测数据库系统的运行情况，让 DBA 对数据库运行状态做到心中有数。
火山引擎云数据库极大的简化了复杂的数据库运维工作，通过自动化、平台化的方式把 DBA 从繁琐的运维工作中解放出来。同时火山引擎云数据库也提供了高可用部署、自动/手动主备切换、自动/手动备份、灵活升降配等功能，又进一步的降低了 DBA 的运维工作量，提高了数据库系统的灵活性。 DBA 可以投入更多精力去关注数据库系统其他方面，例如性能优化，帮助开发人员优化 SQL 等 。
在成本方面，火山引擎云数据库提供按量计费与包年包月的计费方式，相较于自建数据库的模式，避免了一次性投入大量资金，做到只为使用的资源付费，极大的降低了数据库的成本。
以上就是火山引擎云数据库提供的产品与能力，如果我们将这些云数据库产品做一个横向比较，把数据库选型过程中关注的细节进行对比，我们可以得到下面的云数据库能力对比表格。再结合前面介绍的数据库选型方法论，就可以为业务应用选择合适的数据库系统。
注：* 代表还未上线，敬请期待。
我们把选型方法论和火山引擎云数据库产品能力结合在一起，就可以得到了如下的一张选型流程图，按照流程可以确定应用需要的云数据库类型，供大家参考。
测试验证与优化
为了确保选择的云数据库可以满足业务应用需要，可以稳定支撑业务应用的运行，非常建议将业务应用与云数据库放在一起进行全面的验证与测试工作。主要验证兼容性、性能、异常处理等方面。也可以通过一些测试工具来测试云数据库的性能峰值是否满足业务需求，例如 RDS MySQL 可以使用 sysbench 工具，Redis 可以使用 Memtier-benchmark 工具 。
在测试过程中，通过云数据库提供的监控系统，收集测试过程中云数据库的各项指标，例如 CPU 负载、内存使用率、连接数、响应时间、慢查询等指标。通过收集到的各项参数指标，找到业务应用或云数据库的性能瓶颈所在，并进行相应的调优。
火山引擎云数据库线上文档也有性能测试相关白皮书，提供了测试工具、测试方法和性能结果等内容，可以作为性能测试的参考内容 。
如果出现整体测试效果不佳的情况，一方面需要由 DBA 调整云数据库规格、参数，另一方面需要开发人员检查应用使用云数据库的方式，最常见的就是进行 SQL 优化，例如 SQL 查询中没有加索引，或者加了索引但因为某种原因导致索引失效等。除 SQL 优化之外，业务拆分也是常见的优化手段，即将业务数据与压力分散到不同的数据库实例之上，这样既可以保证性能，又可以进行故障隔离。在整体测试效果不佳的时候，需要检查每一个环节，优化每一个环节。
火山引擎云数据库提供了强大的性能、稳定性和功能支撑，但不意味着业务应用不需要遵守一些标准的开发规范，特别是一些 SQL 规范。只有在业务应用与云数据库都做到各自最优的时候，整体系统才可以达到一个最优的情况，让业务平稳且高性能的运行。需要开发人员与 DBA 一起紧密配合，业务需要根据自身特征选择数据库，也需要根据数据库特征调整业务逻辑，互相配合才能达到最佳效果。
总结与展望
数据库一直是 IT 系统基础中的基础，核心中的核心。正所谓“基础不牢，地动山摇”，数据库如果出现问题，即使是很小的问题，也会成倍放大最终对业务系统造成严重的影响。所以业务系统对数据库的选择需要非常谨慎。
本文介绍了数据库系统的分类与每一类数据库适合的场景，也从技术和场景细节方面说明了不同的业务特征应该选择何种数据库产品。根据选型流程图的指导，业务应用可以选择出合适的数据库类型。同时也介绍了火山引擎云数据库的产品种类和各种特征，结合选型方法论，可以帮助业务应用在火山引擎上选择出合适的云数据库作为业务应用的底座。在业务系统正式上线之前，还需要开发人员与 DBA 进行紧密的配合，对整体系统进充分的测试与优化，保障业务系统可以高性能、平稳的运行。
火山引擎提供了丰富的云数据产品类型，可以满足大部分业务场景的需求。云原生数据库 veDB 现在正在进行公测，欢迎试用。后续火山引擎云数据库还会陆续推出图数据库 veGraph、时序数据库、数据库工作台 DBW 等一系列相关产品，敬请期待。
关于作者与团队
魏巍，火山引擎存储&数据库产品解决方案架构师 ，负责存储&数据库产品在泛互联网行业的解决方案拓展工作。
火山引擎存储&数据库产品解决方案团队 ，是由资深的存储&数据库解决方案架构师组成，团队致力于帮助企业与组织更好的使用火山引擎云存储与云数据库产品，针对实际业务场景设计最优的解决方案，用专业技术助力组织和企业实现业务成功。
活动推荐
11 月 24 日晚，火山引擎开发者社区邀请到了火山引擎和 vivo 的两位容器技术专家，将为大家直播分享企业级容器云平台的建设过程，剖析字节跳动和 vivo 利用云原生技术降本增效的实践， 扫描下方二维码 或点击【 阅读原文 】即可报名！