在测试的8小时期间，PolarDB完成了2.2万亿次数据操作，tpmC波动率仅为0.16%，保障了100%的数据正确性，这同时也体现了PolarDBLimitless超大集群的性能稳定性。

这一新纪录模拟了16亿用户同时上线进行交易，其处理能力相当于天猫2020双11订单峰值场景的59倍，成功扛起全球最大流量洪峰。

阿里云智能集团副总裁、数据库产品事业部负责人李飞飞在2025阿里云PolarDB开发者大会上表示：“PolarDB登顶TPC-C排行榜，不仅是阿里云自身技术实力的证明，更说明国产数据库在性能和性价比方面均已达到全球领先水平。”

据了解，TPC-C是由TPC组织制定的针对衡量在线事务处理（OLTP）系统性能的基准测试，被誉为数据库领域的“奥林匹克”，是全球最具公信力的测试标准，也是商业数据库证明自身实力的硬性门槛之一。

该基准测试会考察关系型数据库系统的全链路能力，包括2大衡量标准：性能（tpmC）和性价比（price/tpmC）。

TPC-C测试由一系列严苛的基准测试模型组成，是一场长达40小时的数据库性能“极限挑战”赛，测试过程包括全压力测试、故障容灾测试、数据库ACI测试。

1.1 数据库选型的重要性与难点

发展数字经济是当下各行各业的重要方向。支撑数字经济的底座是软件，特别是基础软件，可以说基础软件是整个数字经济的坚实底座。在基础软件领域，有三大基础软件，分别是操作系统、数据库系统和中间件。我们每天日常生活中的方方面面，背后都离不开这些基础软件的支撑，其中数据库系统是业务数据的载体，比如银行卡上的余额，是非常重要的数据，不能有任何差错，数据库在所有 IT 系统中的地位都是重中之重。

数据库作为基础软件的重要性不言而喻，各行各业的数字系统都离不开数据库系统。但不同行业特点不同，行业需求也就不同。面对着业界上百种数据库类型，到底应该如何根据自己的业务特征去选择最合适的数据库系统？这个问题非常的重要，因为如果数据库选择不合适，可能会让业务系统停摆，造成严重经济损失。所谓合适的数据库系统，不仅仅要满足业务需求，还要尽可能降低成本，减轻运维管理难度，满足业务未来的发展等等。这是个复杂的问题， 因为各行各业的业务场景各不相同，对数据库的需求和使用场景差异很大，可选择的数据库系统也是几十上百种，如此一组合下来，对于非数据库专业人士，选择复杂度非常高。

本文的目的就是要尝试回答这个重要且复杂的问题。如果您计划将 IT 业务系统部署在火山引擎之上，可以参考本文的思路，选择合适的火山引擎云数据库服务，为业务应用打造坚实的数据库底座。

1.2 数据库发展与类型简介

数据库系统在上世纪 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 为代表 ) 以及图 NoSL 数据库 ( 以 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 与大数据相关不在本文讨论范围。

2. 选型基本方法论

在开始介绍数据库选型方法论之前，首先需要介绍一个理念：” 数据库选型没有银弹 “。就是说没有任何一款数据库可以满足所有业务场景的需求，找不到一个可以包打天下的数据库。

如果真有 ” 数据库银弹 “，那也就不必做数据库选型了，直接用银弹就行，数据库世界也就不会出现如此多种类的数据库技术和产品类型了。

所以需要根据不同的业务场景、业务需求去选择一款最适合的数据库系统，这也是本文所要讨论的核心问题。

2.1 参与选型的角色

数据库选型不仅仅是一个技术选择，而是一个全局选择。后面会从多种视角多个方面来说明做数据库选型需要考虑的因素，包括应用接口、数据模型、性能、稳定性、成本、运维复杂度、高可用性、安全性、扩展性等方面。

数据库选型是一个全局选择，参与到选择中的角色主要有三类：

● 开发人员，代表了业务和应用本身。

● DBA，代表了数据库管理角色。

● 财务部门，代表了成本控制角色。

财务部门主要关注的是数据库系统的成本，需要根据业务系统的规模、重要性等方面决定财务投入，简单说就是准备花多少钱建设与维护数据库系统。投入越多，可以获得更强的数据库能力，也可以聘请更专业的 DBA 进行数据库维护，保障数据库系统稳定运行。企业组织中越是重要核心的数据库系统，会获得更多的资源投入。

DBA，Database Administrator，是数据库管理员的简称。从名字就能看出来，DBA 是负责管理数据库系统的角色，主要关注数据库的可运维性，包括监控告警、备份恢复、升级迁移、问题诊断工具、调优工具等；稳定性，包括高可用性、自动主从切换、手动主从切换、会话管理等；性能，包括 QPS、时延、吞吐量等；可扩展性，包括灵活变配、计算扩容、存储扩容等；安全性，包括 SQL 审计、操作审计、数据加密、数据脱敏等。

开发人员，是应用程序的设计者与开发者，也是数据库系统的实际使用者，开发人员设计的应用程序会直接与数据库进行交互，利用数据库进行数据的高效存取。开发人跟 DBA 的关注点有类似的地方，例如开发人员也会关注数据库的性能、稳定性、可扩展性。但除此之外，开发人员更关注的是数据库提供的接口和支持的数据模型，这一点直接决定了应用应该选择什么样的数据库。接口与数据模型包括了是否支持 SQL、是否遵循 ACID、数据一致性等等。

2.2 数据库选型考虑

数据库选型首先需要考虑的应该是业务应用所服务的场景，是 OLTP 场景还是 OLAP 场景。如果是 OLAP，建议参考大数据相关选型指导；如果是 OLTP，可以参考本文的选型指导。

接下来是考虑应用的数据模型。数据模型可以是关系型、半结构化、非结构化、KV 型等等。如果是关系型，可以选择关系型数据库；如果是 KV 型，可以选择 Redis；如果是非结构化或半结构化，可以从 NoSQL 数据库系列中选择适合的种类，需要看具体的数据模型。

如果业务应用对事务 ACID 是强需求，那么关系型数据库将会是最佳的选择，例如 MySQL、PostgreSQL 等。

接着要考虑业务应用对数据一致性的要求。如果业务应用需要强一致性，那么优先选择关系型数据库；如果业务应用可以接受数据的最终一致性，那么各类 NoSQL 数据库都可以成为待选项，具体结合数据模型做进一步考虑。其中，MongoDB 可以通过调整本身的某些参数达到数据强一致的效果，开发人员需要关注。

此外，除了考虑业务应用现阶段的需求，还需要为未来做考虑，这里面最重要的就是预估业务增量，包括对性能、数据量的预估。如果业务在未来增速可能会很快，会需要更强的数据处理能力，或者需要更大的数据容量，那么也需要同时考虑数据库的可扩展性，通过扩展来获取更强的数据处理能力以及更大的数据存储空间，以保证业务应用可以平稳运行。

3. 火山引擎云数据库选型参考

火山引擎云数据库提供了丰富的云数据库产品类型，包括开源数据库与自研数据库，同时也提供了完整的数据库生态服务，包括数据库迁移服务与数据库统一管理服务。接下来会简单介绍每一种数据库的特点与适用场景，便于选型参考。

3.1、关系型数据库 RDS

火山引擎云数据库 RDS 是关系型数据库的合称，RDS 支持 MySQL 引擎、Postgre SQL 引擎、SQL Server ( 暂未上线，敬请期待 ) 引擎，同时提供了数据库管理、安全、灾备、监控、迁移等全套解决方案。RDS 基于云原生架构部署，在扩展性、弹性和性价比方面有很大的优势。

火山引擎云数据库 RDS 可以广泛应用于互联网电商、游戏、在线交易等场景，也可以承载传统 ERP、CRM 等业务数据，具备高可用、高性能、灵活易用等特点，已有多个行业的客户正在使用火山引擎云数据库 RDS 承载其在线核心业务系统。

3.2 云原生数据库 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

3.3 缓存数据库 Redis

火山引擎缓存数据库 Redis 提供的是托管型的缓存数据库服务，兼容开源 Redis 数据库引擎，帮助您在云上轻松、快速地构建 Redis 数据库。缓存数据库 Redis 提供了高性能且安全的 Redis 数据库解决方案，按需计费结合动态扩展能力能够显著地帮助企业降低成本，同时也有助于消除管理、运维数据库的复杂性。

缓存数据库 Redis 在开源社区 Redis 架构上进行了大量优化，采用字节跳动内部实践的 Achemy 架构，极大提升了 Redis 集群的规模与稳定性。

3.4 文档数据库 MongoDB

火山引擎文档数据库 MongoDB 版是一款完全兼容开源 MongoDB 协议，且具备高可用、高性能的在线云数据库服务。文档数据库 MongoDB 支持多种架构，能够满足业务灵活部署的需求。除副本集实例架构外，文档数据库 MongoDB 还提供了分片集群架构，以满足海量数据业务场景，同时提供了灾备、备份及恢复、监控等全套解决方案。在互联网（游戏、电商、直播、资讯、社交）、新零售等行业都有广泛的应用。火山引擎文档数据库 MongoDB 即将上线 MongoDB 5.0 版本，敬请期待。

3.5 表格数据库 HBase

火山引擎表格数据库 HBase 是基于 Apache HBase 提供的全托管 NoSQL 服务，兼容标准 HBase 访问协议，具备低成本存储、高吞吐、灵活扩展等优势。

表格数据库 HBase 具备以下优势，帮助您构建理想应用：

支持 KeyValue 数据模型。

● 高可用架构，Master 为包含两个节点的主备模式，支持 HA 实时检测。

● 存储和计算分离保证数据的高可靠，存储采用多副本机制，可用性不低于 99.5%。

● 支持实例变配，包括横向扩容和纵向扩缩容，还提供了监控告警等功能，实例管理简单方便。

3.6 图数据库 veGraph

图数据库 veGrap 是一款以属性图为基础结构数据的分布式云原生数据库，提供了海量关系的数据存储和毫秒级的在线查询服务，广泛应用于社交网络、欺诈检测、推荐引擎、知识图谱等场景。

图数据库 veGraph 主要具备如下特性：

● 有向属性图。基于有向属性图（Property Graph），由点、边、点类型、边类型以及属性组成。

● 可视化图平台。查询结果可视化，支持图形化地展示数据的关联性，便于更高效地分析数据。

● 图管理。提供图管理、Schema 管理和通过图形化界面来配置数据导入等功能。

● 图查询语言。支持 Gremlin 图查询语言。

3.7 生态工具 DTS

火山引擎数据库传输服务 DTS（Database Transmission Service）提供了数据迁移、数据同步、数据订阅于一体的数据库数据传输管理服务，支持关系型数据库、非关系型数据库数据源间的数据传输，降低数据库之间数据流通复杂性，可在业务不停服的前提下轻松完成数据库迁移上云。相较于第三方迁移工具，数据库传输服务 DTS 可以更方便地创建和管理丰富多样、高性能、高安全可靠的传输链路。

3.8 小结

在传统自建数据库模式下，DBA 人员需要承担的运维工作会非常繁杂，从主机、存储、操作系统到数据库，每一层都涉及到复杂的运维操作。但是在云计算时代，火山引擎云数据库提供了完善的数据库运维体系，将很多常规数据库管理动作都封装为自动化功能，DBA 无需再去执行很多复杂的运维命令，直接通过火山引擎云数据库控制台一键即可完成。同时火山引擎云数据库控制台上也提供了完善的数据库指标监控仪表盘，可以从多种维度观测数据库系统的运行情况，让 DBA 对数据库运行状态做到心中有数。

火山引擎云数据库极大的简化了复杂的数据库运维工作，通过自动化、平台化的方式把 DBA 从繁琐的运维工作中解放出来。同时火山引擎云数据库也提供了高可用部署、自动 / 手动主备切换、自动 / 手动备份、灵活升降配等功能，又进一步的降低了 DBA 的运维工作量，提高了数据库系统的灵活性。DBA 可以投入更多精力去关注数据库系统其他方面，例如性能优化，帮助开发人员优化 SQL 等。

在成本方面，火山引擎云数据库提供按量计费与包年包月的计费方式，相较于自建数据库的模式，避免了一次性投入大量资金，做到只为使用的资源付费，极大的降低了数据库的成本。

以上就是火山引擎云数据库提供的产品与能力，如果我们将这些云数据库产品做一个横向比较，把数据库选型过程中关注的细节进行对比，我们可以得到下面的云数据库能力对比表格。再结合前面介绍的数据库选型方法论，就可以为业务应用选择合适的数据库系统。

注： * 代表还未上线，敬请期待。

我们把选型方法论和火山引擎云数据库产品能力结合在一起，就可以得到了如下的一张选型流程图，按照流程可以确定应用需要的云数据库类型，供大家参考。

4. 测试验证与优化

为了确保选择的云数据库可以满足业务应用需要，可以稳定支撑业务应用的运行，非常建议将业务应用与云数据库放在一起进行全面的验证与测试工作。主要验证兼容性、性能、异常处理等方面。也可以通过一些测试工具来测试云数据库的性能峰值是否满足业务需求，例如 RDS MySQL 可以使用 sysbench 工具，Redis 可以使用 Memtier-benchmark 工具。

在测试过程中，通过云数据库提供的监控系统，收集测试过程中云数据库的各项指标，例如 CPU 负载、内存使用率、连接数、响应时间、慢查询等指标。通过收集到的各项参数指标，找到业务应用或云数据库的性能瓶颈所在，并进行相应的调优。

火山引擎云数据库线上文档也有性能测试相关白皮书，提供了测试工具、测试方法和性能结果等内容，可以作为性能测试的参考内容。

如果出现整体测试效果不佳的情况，一方面需要由 DBA 调整云数据库规格、参数，另一方面需要开发人员检查应用使用云数据库的方式，最常见的就是进行 SQL 优化，例如 SQL 查询中没有加索引，或者加了索引但因为某种原因导致索引失效等。除 SQL 优化之外，业务拆分也是常见的优化手段，即将业务数据与压力分散到不同的数据库实例之上，这样既可以保证性能，又可以进行故障隔离。在整体测试效果不佳的时候，需要检查每一个环节，优化每一个环节。

火山引擎云数据库提供了强大的性能、稳定性和功能支撑，但不意味着业务应用不需要遵守一些标准的开发规范，特别是一些 SQL 规范。只有在业务应用与云数据库都做到各自最优的时候，整体系统才可以达到一个最优的情况，让业务平稳且高性能的运行。需要开发人与 DBA 一起紧密配合，业务需要根据自身特征选择数据库，也需要根据数据库特征调整业务逻辑，互相配合才能达到最佳效果。

5. 总结与展望

数据库一直是 IT 系统基础中的基础，核心中的核心。正所谓 ” 基础不牢，地动山摇 “，数据库如果出现问题，即使是很小的问题，也会成倍放大最终对业务系统造成严重的影响。所以业务系统对数据库的选择需要非常谨慎。

本文介绍了数据库系统的分类与每一类数据库适合的场景，也从技术和场景细节方面说明了不同的业务特征应该选择何种数据库产品。根据选型流程图的指导，业务应用可以选择出合适的数据库类型。同时也介绍了火山引擎云数据库的产品种类和各种特征，结合选型方法论，可以帮助业务应用在火山引擎上选择出合适的云数据库作为业务应用的底座。在业务系统正式上线之前，还需要开发人员与 DBA 进行紧密的配合，对整体系统进行充分的测试与优化，保障业务系统可以高性能、平稳的运行。

火山引擎提供了丰富的云数据产品类型，可以满足大部分业务场景的需求。云原生数据库 veDB 现在正在进行公测，欢迎试用。后续火山引擎云数据库还会陆续推出图数据库 veGraph、时序数据库、数据库工作台 DBW 等一系列相关产品，敬请期待。

十年前，时任亚马逊云科技高级副总裁的Andy Jassy（现任Amazon CEO）在首届亚马逊云科技re:Invent大会上宣布推出Amazon Redshift预览版。与昂贵、缺乏弹性并需要投入大量的运营人力和资金的传统本地数据仓库解决方案相比，Amazon Redshift有了质的飞跃。

亚马逊首席技术官Werner Vogels在2012年11月28日的博文里表示：“我们很高兴推出了Amazon Redshift预览版，这是一个高性能、全托管的PB级云数仓服务。该服务的性能将显著提升客户的数据分析效率。Amazon.com的数据仓库团队一直在试用Amazon Redshift，他们对规模高达20亿行的数据集进行了一系列的典型查询，并将Amazon Redshift与本地数据仓库进行比较，结果显示Amazon Redshift将速度提高了10-150倍！”

这也是为何当时还是高级产品经理的Rahul Pathak以及整个Amazon Redshift团队，在该服务宣布推出之日充满信心。Rahul Pathak现任亚马逊云科技数据分析副总裁，他回忆：“我们没料到的是它会这么受客户欢迎。在提供预览版时，我们先让客户注册，了解他们的数据量和工作负载。约三天左右，我们就发现客户对Amazon Redshift的需求量比原先预计的整年需求量还多10倍。于是，我们在re:Invent一结束就迅速增加硬件订单，以确保在2013年初Amazon Redshift正式可用时能有充足的数据中心硬件支持。还好提前提供了预览版，否则我们将应接不暇。”

从那时起，Amazon Redshift团队一直加紧创新，满足客户不断增长的各种需求。如今，数以万计的客户每天使用Amazon Redshift处理EB级的数据，为高性能商业智能（BI）报告、仪表板应用程序、数据探索和实时分析等分析工作负载提供支持。

关于Redshift的起源

Rahul：在Amazon Redshift推出的前几年，我们的很多客户就已经把除了数据仓库之外的所有工作负载迁移到了云端。数据仓库常常是客户在企业本地运行的最后一个应用，而且他们仍面临如成本高昂、带有惩罚性质的许可费、难以扩展，并且无法分析所有数据等重重挑战。客户的诉求之一便是希望在云中大规模地运行具备足够性价比的数据仓库来分析所有数据，同时兼顾性能。

随后，我们开始着手构建、运营一个代号为Cookie Monster的全新项目。当时，客户数据量正在爆炸式增长，这些数据不仅来自关系型数据库，还包括各种各样的数据源。客户试用了Redshift的一个早期测试版，发现结果返回速度快得惊人，比他们之前使用的系统快了10到20倍，以至于他们还以为系统出现了问题。当然，我们也收到一些客户对某些早期功能不满意的反馈。我们及时与这些客户取得联系，了解他们面临的挑战、反馈，并在2013年2月该服务正式上线之前进行了调整。

当我们推出Amazon Redshift，并宣布定价为每年1000美元/TB时，人们简直不敢相信我们推出了一个性价比如此之高的服务。我们在几分钟内而不是几个月就能为客户提供一个数据仓库，这吸引了所有人的关注，被业界称为一个真正的游戏规则改变者。

Ippokratis：当时，我在IBM研究院从事数据库技术工作，我们意识到，以云服务的方式提供数据仓库将颠覆游戏规则。使用客户的本地系统通常需要几天或几周时间才能解决的问题，使用像Redshift这样的云数据仓库则只需要几分钟，应用云服务明显加快了创新的速度。

就传统的本地数据仓库而言，通常需要花费几个月甚至几年时间才能将新功能更新到最新的软件版本中；而在云端，新功能可以在几周内推出，客户无需改变其应用程序中的任何一行代码。Amazon Redshift的发布是一个拐点，让我对云和云数据仓库产生了真正的兴趣，并选择加入了亚马逊云科技。[Ippokratis于2015年10月作为首席工程师加入Amazon Redshift团队]。

关于Amazon Redshift在过去的十年中的发展

Ippokratis：为了满足客户的需求，Amazon Redshift已进入快速迭代过程。我们主要聚焦四个维度：1）满足客户高效处理日益复杂的分析查询的需求；2）客户需要处理更多数据，需要从数据中获得洞察的用户数量也大幅增长；3）客户需要更易于操作的系统；4）客户希望将Amazon Redshift与亚马逊云科技其他服务进行集成。

Amazon Redshift从诞生之日起，我们就致力于让它能为客户提供卓越的的高性价比。团队从一开始，就专注于尽最大可能降低核心查询执行延迟，以便系统能够响应更多作业请求，客户能够运行更多工作负载，并支持日常分析。为此，Amazon Redshift生成高度优化的C++代码，然后将其发送到并行数据库中的分发器，并执行这些高度优化的代码。这种方法让Amazon Redshift在查询执行方式上独树一帜，也使它一直成为服务的核心。

我们从来没有停止过创新，一直竭力为客户提更好的性能。另一个让我感兴趣的点是，客户在传统商业智能中，通常会为需要长时间运行的作业进行系统优化。但当我们从深入分析客户行为时，我们发现在每天运行的数十亿次查询中，90%的查询执行时间不到一秒。这一惊人发现打破了人们对数据仓库期望的传统认知，同时也改变了我们着力优化的代码方向。

Rahul：正如Ippokratis提到的，客户需要处理更多的数据，并使用这些数据为整个组织挖掘数据价值，这是我们重点关注的第二个方向。数据分析一直非常重要，但在八或十年前，却不一定是客户的关键任务应用。现在，这种情况已经改变，企业核心业务流程依赖于Amazon Redshift的高可用性和高性能。过去十年中，为支持这一目标，Amazon Redshift在架构上最大的变化是引入Redshift Managed Storage (RMS)，将计算和存储分离，并聚焦各自领域，大举创新。

RMS支持跨多个可用区，具有99.999999999%的耐久性和99.99%的可用性。RMS既管理用户数据，也管理交易元数据。

另一个重大趋势是客户希望在不同的数据集之间进行查询和整合。我们在2017年推出了Redshift Spectrum，让Amazon Redshift成为云中第一个支持查询Amazon S3数据的数据仓库。之后Amazon Redshift运行查询的能力也得到进一步证实，该服务能够扫描Amazon S3以及集群中EB级的数据进行查询。这是另一个改变游戏规则的重要时刻。

像纳斯达克这样的客户已经广泛使用这种方式来查询本地磁盘上的数据，获得最高的性能，同时利用Amazon Redshift与数据湖的完美集成，实现对整个历史数据的高性能查询。除了查询数据湖，Amazon Redshift还支持对Amazon Aurora和Amazon RDS等交易型数据存储的综合查询，这也是一大创新。客户真正意义上拥有一个高性能的分析系统，能够查询所有重要数据，无需像其他系统那样管理复杂的集成过程。

Ippokratis: 易用性是我们关注的第三个方向。传统本地数据仓库需要企业IT部门配备专门的数据库管理员。过去十年中，客户期望已经发生了变化。现在，如果把数据仓库作为一种服务来提供，系统必须能够自动调整、修复和优化。这已经成为我们关注的一个重要领域，通过将机器学习和自动化纳入系统，增强易用性，减少管理员的工作量。

Rahul：在易用性方面，我想到了三个创新。第一是并发扩展。与工作负载管理类似，客户以前必须手动调整并发，或重置手动分割的工作负载集群。现在，系统会自动部署新的资源，自动伸缩，客户无需采取任何行动。

第二是自动表优化功能。系统能够通过查看工作负载和数据布局，并自动建议数据应该如何在集群节点中排序和分布。这个优化是一个不断学习的过程，它能够持续根据工作负载的变化进行调整，这是一个非常厉害的功能。

客户总是在增加更多数据集和更多用户，昨天的最优选到明天可能就不复存在了。Amazon Redshift可以自动识别，并根据数据存储进行调优。关于如何分析数据在多节点并行处理系统中的最佳分布键，这是个非常有趣的话题，我们在几年前发布的一篇图优化论文中专门进行了分析。我们对最佳分布键进行了自动优化，并加入了对数据压缩编码的处理。在一个分析系统中，如何压缩数据对结果有很大影响，因为扫描的数据越少，查询就越快。过去，客户必须自己决定选择什么样的压缩编码格式。现在，Amazon Redshift可以自动确定如何正确编码数据，为数据和工作负载提供尽可能高的性能。

第三个创新是去年re:Invent上推出的Amazon Redshift Serverless。Redshift Serverless可在几秒钟内自动设置和扩展资源，让客户无需管理数据仓库集群，即可以为PB级数据规模运行高性能分析工作负载，更轻松地从数据中快速获取洞察。通过Redshift Serverless，客户只需要配置一个endpoint即可与他们的数据进行互动，Redshift Serverless将自动扩展并自动管理系统，从根本上消除了复杂性。

客户可以只关注他们的数据，设置限制参数来管理预算，我们可在设定好的限制条件之下提供最佳性能。这是在易用性方面取得的另一个巨大进步，因为它无需客户进行任何操作。就目前客户对Redshift Serverless预览版的反馈来看，客户对该服务的表现非常满意。我们也很高兴推出了Amazon Redshift Serverless正式可用版本。

Ippokratis: 第四个重点是与其他亚马逊云科技服务的集成。集成是客户的使用行为从传统BI向前进化的重要方向。如今，云数据仓库是一个中心枢纽，与广泛的亚马逊云科技服务紧密集成。首先，我们为客户提供了将数据仓库中的数据与数据湖连接起来的能力。之后，客户表示需要访问Amazon Aurora和Amazon RDS等运营数据库中的高速业务数据，于是，Amazon Redshift增加了对OLTP交易数据库的访问支持。然后，我们增加了对流数据的支持，以及与Amazon SageMaker和Amazon Lambda的集成，客户就可以在不移动数据的情况下运行机器学习训练和推理，并进行通用计算。很明显，我们已经从传统BI系统转化成为深度集成的一组亚马逊云科技服务。

Rahul：集成的另一个重要方面是与机器学习服务。通过Redshift ML，数据分析师和数据库开发人员可以在Amazon Redshift中使用熟悉的 SQL 命令轻松创建、训练和应用机器学习模型。我们构建了从SQL语言创建模型的能力，它将数据摄取到Amazon S3并调用Amazon SageMaker，使用自动机器学习建立最合适的模型，并基于数据提供预测。

模型经高效编译并返回数据仓库，让客户无需额外的计算和成本，即可运行高性能推理。这种集成的优势在于，Amazon SageMaker中的每一次创新也就意味着Redshift ML变得更好。这是客户可以从我们的服务集成中受益的另一种方式。

集成的另一个重要的方向是Data Sharing。一旦使用 RA3 实例，将计算和存储层分离，就可以打开Data Sharing，让客户有能力与同一账户、其他账户、或者跨区域的集群共享数据。这意味着可以将数据消费者和生产者分开，实现现代化的数据网格等等架构上的创新。客户可以在不复制数据的情况下分享数据，从而达成不同账户间的数据一致性。

例如，数据科学家组别的用户可以安全地在共享数据中工作，报表或营销组的用户也可以。我们还将Data Sharing与Amazon Data Exchange整合在一起，客户可以搜索并订阅最新的第三方数据集，并在Amazon Redshift中立即进行查询。从释放数据潜能的角度来看，这种整合再次改变了游戏规则，帮助第三方供应商数据变现，更为用户提供安全、实时的数据访问和许可，方便在内部和跨组织进行高性能分析。Amazon Redshift是一个极其丰富的数据生态系统的一部分，这是一个巨大的优势，能满足客户在公司的各个组织之间更方便的提供/获取数据的需求。

展望Redshift及云数据仓库的发展前景

Rahul：未来，客户将产生越来越多的数据，他们希望更经济高效地分析这些数据。虽然数据量呈现指数级增长，但很显然，客户并不希望他们的成本也以指数级增长。这就要求我们继续创新，进一步提升性能以确保单位数据处理成本持续下降。

我们将继续在软件、硬件、芯片和机器学习应用等方面进行创新。在过去的10年中，我们已经兑现了这一承诺，今后亦将如此。

我非常自豪于我们团队目前取得的诸多成就，同时，我也同样对我们正在执着努力的事业而热血沸腾。

客户总是希望拥有更好的可用性，希望他们的数据是安全的以及与更多数据源整合的可能性，我们也计划继续围绕这些方向优化服务体验。可以确定的是，我们有能力提供极具高性价比、深度集成和安全可靠的服务，帮助客户创造更多价值。

Ippokratis: 这是一段不可思议的旅程。我们一直在与客户一路前行，不断重构。这背后离不开亚马逊云科技领导团队的支持，但更重要的是团队中出色的工程师、经理和产品团队，他们让一切成为可能。

​

亚马逊云科技大中华区产品部总经理陈晓建表示：“数据作为企业的核心资产和创新的主要推动力，企业需要率先夯实数据库这一新基建，为数字化转型打下坚实的地基。作为云计算领域的引领者，亚马逊云科技不断推动云服务的创新，也在积极探索公有云架构与数据库演进的结合，希望通过云原生数据库服务的创新，帮助各行业企业展开云上创新之旅。”

随着数字化进程的不断提速，各行业企业面对数据量指数级暴涨和数据类型及应用场景的多元细分等诸多挑战，对数据库性能、扩展性、高可用性以及成本效益等需求也愈发严苛。其中，传统行业企业由于行业的特定应用需求以及历史遗留数据等，面临的挑战更为艰巨。例如，汽车行业企业需要处理如车联网产生的海量以及多样化数据；制造业中的智能家居/设备类企业，需要管理不同生命周期数据并生成洞察；金融业需要减少成本并提升风险控制能力等等。云数据库尤其是云原生数据库由于具有强大性能、高可用性、可扩展性、支持多场景需求且具备成本效益等优势，正成为越来越多传统行业企业的选择。

率先开启云上托管数据库服务，引领并推动云原生数据库服务的发展

亚马逊云科技一直在引领云计算的发展，并推动云数据库的迭代与发展。早在2009年，亚马逊云科技就发布了Amazon Relational Database Service(Amazon RDS)，从此开启了云上托管数据库服务的新模式。Amazon RDS从开始支持MySQL一种，发展到现在已支持六大数据库引擎。我们早在2007年发布了Dynamo论文，定义了NoSQL运动，并于2012年推出首个云原生数据库Amazon DynamoDB，让数据库以前所未有的方式拥抱云计算的高性能、可扩展性和高可用性，开启了云原生数据库的序幕。2014年，我们推出了云原生的关系型数据库Amazon Aurora，该服务目前是亚马逊云科技历史上用户数量增速最快的云服务。为了进一步简化客户在创建、维护和扩展数据库方面的工作，我们还推出了多种具有Serverless特性的数据库，让数据库的扩展性及自动伸缩容量达到新的高度，其中Amazon Aurora Serverless V2可以在几分之一秒内将数据库工作负载从数百个事务扩展到数十万个事务，与按照峰值负载配置容量的成本相比，最多可节省 90% 的数据库成本。

赋能汽车行业处理海量以及多样化数据

随着汽车行业企业在自动驾驶和车联网等创新领域的布局，汽车早已从只是机械系统即硬件上的创新，发展为机械加电子系统的创新。汽车企业需要处理海量的、多种类型的数据如汽车基础数据、交通和基础设施数据、用户及其行为等数据，并从中充分挖掘数据的价值，为企业的业务创新和运营效率提升提供原动力。

企业要高效处理不同类型数据，就需要为不同业务场景找到“理想”的数据库。亚马逊云科技的数据库服务广泛支持关系、键值、文档、内存、图、时间序列、宽列和分类账八大数据库类型，“专库专用”为企业提供极致性能。例如，可使用云原生的关系数据库Amazon Aurora以及时序数据库Amazon Timestream管理汽车基础数据，使用键/值数据库Amazon DynamoDB和文档数据库Amazon DocumentDB管理交通和基础设施数据，使用图数据库Amazon Neptune管理用户行为数据等。其中，Amazon DynamoDB专为海量数据、超大型工作负载而生，可以为超大规模的应用程序提供支持。

赋能制造业释放数据不同生命周期价值并获得数据洞察

数据是驱动制造业企业加速发展的关键因素。除海量、多种类型数据的挑战外，制造业企业往往还会面临如管理不同生命周期数据、解决数据孤岛等挑战。以智能家居/设备企业为例，企业可能需要管理包括基于家庭的自动化设备（如电灯、白色家电、电视等）、家庭安全和监控设备（如智能恒温器、安全摄像头等）以及家庭网络设备所产生的（如WIFI路由器和调制解调器）具有生命周期性质的数据，并希望从这些数据中获得洞察，为最终用户提供更好的服务体验。

随着时间的推移，企业需要处理的数据量增长迅速，企业往往需要在成本、访问频率之间进行平衡。为解决客户的这些挑战，亚马逊云科技提供具有数据分层功能的数据库服务，包括Amazon Timestream、Amazon DynamoDB以及Amazon ElastiCache for Redis，可以帮助制造业企业将大量低访问频率的历史数据进行冷热数据分离，并自动进行分层存储。该功能可广泛应用于制造业的智能家居、智能可穿戴设备和工业生产设备监控产生的数据生命周期管理场景，帮助企业提升性能并优化成本。

此外，亚马逊云科技图数据库Amazon Neptune可以存储数十亿个关系，可将图数据查询延迟降低到毫秒级，帮助制造业企业创建工业知识图谱或整合产品关系数据以提供数据洞察。西门子工业自动化产品成都生产及研发基地利用Amazon Neptune构建云边一体产线知识图谱应用试点，有效管理工业生产环境下的众多生产元素，满足现实生产过程中的复杂需求，为生产人员提供及时专业的现场自助式服务。西门子工业自动化产品(成都)有限公司信息技术部经理杨健表示：“建设工业制造系统的数字化需要借助工业知识图谱，基于Amazon Neptune，我们初步实现了产线故障知识图谱，这让我们具备了云端弹性的计算调度能力和海量扩展的数据处理能力，机器学习功能的加入让知识图谱具备了自我进化的能力。我们相信云原生数据库将是制造业实现数字化的重要路径。”

赋能金融业加强风险控制并拓展全球业务

金融行业正通过数字化转型来推动新应用场景的发展，但却面临高昂的数据库成本、众多海量数据来源以及风险控制效率低下等挑战。以风险控制为例，随着数字化、电子化的发展，金融风险日益呈现规模化、隐蔽性、动态变化的特征，这给金融机构带来了巨大的识别挑战。金融机构希望通过实时的对大规模数据进行复杂的关联链路分析，提升风险控制。其中，亚马逊云科技Amazon Neptune专为挖掘数据间复杂关系而优化设计，能在几毫秒内查询数十亿种关系，且无需运维操作即可针对海量数据随时添加新的数据维度，可帮助金融机构提升风险控制。

面对需要支持全球业务提升客户体验及业务连续性需求，亚马逊云科技提供全球数据库解决方案，可帮助金融机构轻松将数据库读取扩展至世界范围，让数据更靠近各地区的用户。亚马逊云科技还提供三个可用区的灾备保护能力，有效保障金融机构全球业务的一致性与连续性。亚马逊云科技全球数据库服务具体包括Amazon Aurora Global Database、 Amazon DynamoDB Global Tables、Amazon Neptune Global Database、Amazon DocumentDB Global Clusters以及Amazon ElastiCache for Redis Global Datastore。

此外，亚马逊云科技构建了强大的合作伙伴网络，通过合作伙伴网络成员的服务帮助各行业客户基于云上托管以及云原生数据开展创新。深圳市融聚汇信息科技有限公司（融聚汇）是一家金融数据服务提供商，为超过100家机构客户提供境外金融信息服务。融聚汇产品总监向坤表示：“行情资讯数字化是我们的客户实现服务升级的核心驱动力。基于亚马逊云科技云原生的高性能关系数据库服务Amazon Aurora，融聚汇构建了一站式的金融行情SaaS服务云平台，能够让客户简便、快速地进行应用服务和应用创新，实现低成本的数字化转型。通过Amazon Aurora，我们将数据跨区存储，实现了无感灾难恢复，可用性可以达到99.99%；每秒并发查询效率也提升了近5倍，进一步满足金融业务场景高并发的需求；在成本方面，Aurora的弹性扩展能力还帮助我们节约了30%的硬件成本。”

北京——2021年12月9日，亚马逊云科技在2021 re:Invent全球大会上，宣布推出三项数据库功能，让客户可根据其业务需求更加轻松、经济地扩展和运行数据库服务。新发布的功能包括：面向客户业务应用程序的托管数据库服务，客户可定制底层的数据库和操作系统；降低不经常访问数据存储成本的Amazon DynamoDB表分类；以及使用机器学习更好地诊断和修复数据库相关性能问题的新服务。这些创新让客户可以更轻松、经济地大规模管理数据。

随着越来越多的应用程序需要以低延迟和高性能处理 PB 级甚至 EB 级数据，单一通用数据库无法满足客户希望以高可用、可靠和高性能的方式大规模利用和管理数据的需求。为此，越来越多的客户为满足其特有的需求而寻找合适的数据库。亚马逊云科技提供广泛和深入的专门构建的数据库服务，包括键/值数据库服务 Amazon DynamoDB，图数据库服务Amazon Neptune，内存数据库服务Amazon ElasticCache和Amazon MemoryDB，文档数据库服务 Amazon DocumentDB，宽列数据库服务Amazon Keyspace (兼容Apache Cassandra)，时序数据库服务Amazon Timestream，分类账数据库服务Amazon Quantum Ledger Database (Amazon QLDB)。亚马逊云科技是运行开源数据库的最佳场所，有超过10万的客户选择Amazon Aurora，Amazon Aurora与MySQL及PostgreSQL全面兼容，以传统商业数据库十分之一的成本即可享有其具有的高性能和可用性。许多客户也选择在亚马逊云科技上运行商业数据库，以便利用云服务卓越的可扩展性、安全性和弹性。完全托管的关系型数据库服务Amazon Relational Database Service (Amazon RDS)，让用户可以轻松地在云中设置、操作和扩展 Oracle 和 Microsoft SQL Server 数据库。亚马逊云科技拥有超过 15 种专门构建的数据库服务，让客户可以用最合适的工具完成工作，并具有高可用、高性能、可靠和安全性。此次推出的三项数据库功能为客户提供了更多选择以及更高的性价比。

亚马逊云科技数据库与分析副总裁Raju Gulabani表示：“客户希望为其重要的应用场景使用专门优化的数据库服务，从而提供灵活、可扩展和可靠的用户体验，同时不必在管理基础设施上投入大量资源以及产生额外的成本。我们很高兴能够通过本次新发布的数据库功能，为客户提供更多的灵活性和选择，以更高的性能以及更优化的成本，支持客户最关键的业务应用程序。亚马逊云科技所提供的数据库服务无论是深度还是广度无人能及，并且我们还在持续为客户创新。”

完全托管的数据库服务Amazon RDS Custom，客户可定制业务应用程序的数据库和操作系统

Amazon RDS易于部署、运维和扩展，因此成为客户希望在云上运行 Oracle 和 Microsoft SQL Server 等商业数据库的选择。客户使用Amazon RDS可省去诸如配置容量、扩展和备份数据等费时的管理任务。但是，某些业务应用程序需要自定义底层的Oracle 和 Microsoft SQL Server 数据库环境和操作系统（如 Microsoft Dynamics AX、Microsoft SharePoint 和 Oracle PeopleSoft）。客户为了完全控制底层数据库环境和操作系统，通常需要在自建的环境（如 Amazon EC2 或本地）中运行这些应用程序。虽然自建方式带来了高度可配置性，但同时客户需要花费时间在硬件配置、数据库部署、补丁和备份等管理任务上。这些需要自定义数据库和操作系统的客户真正需要的是能自动化无差别的管理任务，更轻松地在亚马逊云科技上运行这些应用程序。

Amazon RDS Custom 可自动部署、操作和扩展与常见业务应用程序紧密集成的Oracle 和 Microsoft SQL Server 数据库，同时可自定义业务应用程序底层的数据库和操作系统。运行此类业务应用程序的客户，通过 Amazon RDS Custom，可不必担心费时的管理任务，如配置和扩展硬件、数据库部署、补丁和备份等。客户可使用Amazon RDS Custom配置其数据库环境和底层操作系统，修改设置，安装自定义补丁，并集成第三方软件，满足其业务应用程序的需求（如自定义数据库小版本、第三方安全和诊断软件或特定的文件系统配置）。Amazon RDS Custom自动监控数据库环境和操作系统，并检测影响 Amazon RDS Custom 性能的用户配置。一旦发现问题，Amazon RDS Custom将尝试自动解决。对于无法自动修复的配置错误，Amazon RDS Custom 会通知客户，并提供建议的解决步骤。客户可以轻松地将需要自定义的 Oracle 和 Microsoft SQL Server 数据库迁移到 Amazon RDS Custom，省去自己管理数据库的繁琐。欲开始使用Amazon RDS Custom，请访问aws.amazon.com/rds/custom。

Amazon DynamoDB Standard-Infrequent Access (Standard-IA) 表分类可以使存储非经常访问数据的DynamoDB表的成本降低高达60%

Amazon DynamoDB 无需管理服务器或集群，即可在几乎任何规模下提供高吞吐量和一致的毫秒级响应时间，成为客户处理大容量 NoSQL 工作负载的选择。随着DynamoDB工作负载模式变得更加多样化，在有些客户的工作负载中，数据存储成为其主要成本，有些较少被访问的数据却需要具有快速响应能力。例如以前的社交媒体帖子、电子商务订单和视频游戏成绩等，这些场景的数据容量随着时间积累不断增长，会产生大量的存储费用，但这些数据仍然需要高吞吐量，当请求时需要立即可用。客户为了优化这些场景中的存储成本，会通过编写代码将旧的、访问频率较低的数据从DynamoDB 移动到成本更低的存储替代方案（如 Amazon S3）。

客户使用新的Amazon DynamoDB Standard-Infrequent Access (Standard-IA) 表分类，表分类可以使存储非经常访问数据的DynamoDB表的成本降低高达60%。DynamoDB Standard-IA 表分类的存储成本比标准 DynamoDB 表低多达60%，对于存储成本占主要成本的表来说，它是最划算的选择。相比之下，在吞吐量相同的情况下，DynamoDB Standard 表分类的成本比 Standard-IA 表分类最多低20%，对于吞吐量占主要成本的表来说，仍然是更划算的选择。客户可以在 Amazon DynamoDB Standard 和DynamoDB Standard-IA 表类之间切换，不会影响表性能，也不需要更改代码来优化其存储的数据类型的支出。欲开始使用DynamoDB Standard-IA 表类，请访问aws.amazon.com/dynamodb/standard-ia。

Amazon DevOps Guru for RDS借助机器学习只需几分钟即可更好地检测、诊断和解决难以发现的数据库性能问题并提供建议，无需数日

Amazon DevOps Guru 是一项由机器学习赋能的服务，通过自动检测问题并推荐特定的补救措施，让开发人员可以更轻松地提高应用程序可用性。目前，Amazon DevOps Guru 会提醒客户注意 Amazon RDS 引擎的问题。但是确定数据库相关问题的确切原因既复杂又耗时，为确定导致问题的原因，通常需要招募数据库管理员手动运行诊断工具和查询。一旦确定了问题的原因，数据库管理员需要进行额外的分析来充分了解问题（例如分析特定于数据库的指标、事件和等待条件或提取和分析相关 SQL 语句），然后才能提供如何修复问题的指导。因此，通常需要花费几个小时或几天的时间才能发现和补救数据库问题，可能会影响应用程序可用性或降低用户体验。

Amazon DevOps Guru for RDS是 Amazon DevOps Guru 中一项由机器学习提供支持的新功能，可自动检测和诊断数据库中的性能瓶颈和操作问题，并提供详细的修复建议，让开发人员可以在几分钟内而不是几天就能解决问题。Amazon DevOps Guru for RDS基于 Amazon DevOps Guru 检测数据库相关问题，涵盖 Amazon RDS 中其他与性能相关的问题检测（如资源过度使用以及不正确的SQL 查询行为）。Amazon DevOps Guru for RDS帮助客户快速解决与数据库相关的性能和使用问题， 可以在出现问题时立即通知开发人员，并提供有关根本原因的诊断信息、问题的详细信息以及智能修复建议。例如，如果检测到与数据库意外高负载相关的应用程序性能问题时，Amazon DevOps Guru for RDS 会进行根本原因分析，找到导致问题的确切 SQL 语句，发送包含问题原因和影响范围的通知，并建议纠正措施，以帮助客户快速解决问题。Amazon DevOps Guru for RDS目前支持Amazon Aurora，并计划在2022年支持其他Amazon RDS数据库服务。欲开始使用Amazon DevOps Guru for RDS，请访问aws.amazon.com/devops-guru/features/devops-guru-for-rds。

Mercado Libre是一家领先的拉丁美洲电子商务领域技术公司。“尽管用户不经常查看他们过去的订单，但他们希望在需要时能够随时获得过去的订单、重新订购商品以及产品信息。” Mercado Libre核心IT服务总监兼SRE和DBA负责人Oscar Mullin表示：“通过Amazon DynamoDB Standard-IA存储用户不经常访问的数据，将帮助我们大幅节省成本，同时将让我们获得如Amazon DynamoDB一样的高性能、可访问性和可靠性。”

NetApp是一家以云为主导、以数据为中心的软件公司，让企业可以自由地将数据用于其应用之中，提升业务。NetApp Cloud Volumes高级副总裁兼总经理Ronen Schwartz表示：“NetApp提供云服务，让企业能够轻松地从本地迁移到云，运行高效、经济的关系型数据库和运营项目。但是，对于需要自定义应用底层数据库环境和操作系统的企业，则无法迁移到云中完全托管的数据库服务。通过Amazon RDS Custom，这些企业现在可以为需要自定义操作系统和数据库的应用提供托管数据库服务。企业可以在NetApp ONTAP上运行Amazon RDS Custom，获得先进的数据保护、更高的效率和持续优化。”

亚马逊运营科技（Amazon Fulfillment Technologies）为亚马逊运营中心设计、开发和运营物流技术解决方案，包括全球范围内的自动化Amazon Robotics。“我的团队管理着一个大型车队数据库。Amazon DevOps Guru for RDS可帮助我们识别比监控阈值范围更广的性能异常，并且不会过于嘈杂。”亚马逊运营科技首席数据库工程师Brent Bigonger表示：“Amazon DevOps Guru for RDS 的机器学习驱动的洞察作为前期预警系统，让我们能够快速检测、诊断和修复与性能相关的问题。”

Singular通过统一分散的数据、应用归因和揭示加速增长的洞察力来简化营销数据。“在Singular，我们捕获、分析和完善数十亿个数据点，为我们的客户提供最准确、及时和可操作的跨平台分析。即使数据不常用，也需要能立刻访问，这对给客户提供最佳见解以快速发展业务至关重要。” Singular数据基础设施主管Ofir Nir表示：“Amazon DynamoDB Standard-IA表分类能够简化我们对长期数据存储的管理和访问，同时具有如Amazon DynamoDB的性能、耐用性和数据可用性，它将帮助我们进一步优化成本，并为我们的客户提供更好的用户体验。”

NTT DOCOMO是日本领先的移动运营商。NTT DOCOMO服务设计部高级经理Chikara Mitsui表示，“我们为客户和NTT DOCOMO内部团队管理45个独立的应用。这些团队为NTT DOCOMO的公共服务和公司员工的商业应用提供基础组件。我们很高兴使用Amazon DevOps Guru for RDS，利用由机器学习驱动的洞察，完成对数据库相关的各种性能问题的快速检测、诊断和修复。Amazon DevOps Guru为我们的应用堆栈提供了单一的洞察视图，使我们的团队能够专注于构建更可靠的服务，而不是调查运维问题。”

Delphix提供自动化的DevOps数据平台，为实现隐私合规开展数据脱敏，保护数据免受勒索软件影响，并为持续集成/持续开发（CI/CD）和数字化转型提供高效的虚拟数据。Delphix的产品管理副总裁Jason Grauel表示，“通过Amazon RDS Custom，Delphix的客户可以加速将数据库迁移到托管服务，消除拖慢应用程序开发速度的数据相关问题。现在，客户可以测试数据确保跟快节奏的DevOps保持同步，同时获得Amazon RDS Custom自动化的运营优势。”

在Andy Jassy三小时主题演讲中，令人印象深刻的有几个数据。

从0到100亿美元 用了十年多时间 从300亿美元到460亿美元仅用一年时间

回顾AWS发展历史，在收入方面AWS花了123个月时间来实现收入达到100亿美元的规模，花了23个月实现下一个100亿美元的增量，用13个月时间达到了300亿美元时间，只用了12个月时间从300亿美元增长到460亿美元，每增长100亿的时间正在缩短。AWS正基于一个超级大的基数在成长，年增长率达29%。

借力于云计算的蓬勃发展以及AWS在云计算的SaaS、IaaS、PaaS层生意的强劲的增长。AWS在全球企业IT排名跃升至第五位，已经跻身Oracle、SAP之前。

云计算只占到全球IT市场份额的4%

尽管云计算在十多年内席卷整个IT市场，但从数据来看，云计算只占到全球IT市场份额的4%。在云计算领域，据Gartne在2020年8月发布的《2019年全球公有云IaaS和PaaS市场份额报告》，AWS占到了45%的市场份额。Andy Jassy认为大部分的计算正在向云迁移，在未来十到二十年，确实AWS面临更多增长潜力。

2020年的疫情，也推动了更多企业从传统IT向云上迁移。正如中国互联网界自嘲的那样，中国传统互联网已经开始被新兴互联网所替代。而传统IT体系，也在进一步瓦解，云计算趋势不可阻挡。

已有35万个数据库迁移至AWS上

 Andy Jassy给出的数据，目前已经迁移到AWS上的数据库是35万个，这让很多分析师都感到惊讶。

事实上，从2019年这一数据就在爆发式增长。光2019年就有20万个数据库迁移上云，超过2016-2018年的总和，其中不乏三星电子、道琼斯这样的行业巨头。

标志性事件来自于AWS自己。2019年10月，Amazon消费者业务正式完成对Oracle数据库的迁移工作，将近7500个Oracle数据库、75PB级数据库全部迁移到AWS 云数据库服务，包括Amazon DynamoDB，Amazon Aurora， Amazon Relational Database Service（Amazon RDS和Amazon Redshift等。

2020年7月，三星电子已将全球超过11亿用户的数据库迁移到Amazon Aurora云数据库。

在今年亚马逊re:Invent主题演讲中，Andy Jassy提到了数据库的一些重要趋势，这也是接下来若干年里云数据库对传统IT体系发起的又一轮挑战。

数据库的痛点一直困扰着企业，因为数据库很难管理，企业需要雇佣大量的数据库专业人员做设置、打补丁、调优、容错等工作。早在十年前，AWS就发布了托管数据库服务，很受企业欢迎。尽管RDS关系型数据库服务（Relational Database Service）增长速度很快，但大部分的关系型数据库仍然是本地的。传统的商业数据库提供商如微软、甲骨文的产品很贵，因为专有而增加客户的使用难度，企业需要不断投入人力、财力打造强大与专业的数据库团队才能驾驭。客户在快速地向开放式数据库引擎MySQL Server转，但难度还是非常大，AWS在这样的背景下推出了Amazon Aurora。

Andy Jassy表示，“Aurora是与MySQL和PostgreSQL兼容的，它是专门为云打造的，它有非常强的这种性能可用性，可以匹敌高端商业数据库，而成本要低得多。可以说Aurora是AWS史上增长最快的一个云服务，有超过10万的用户在使用Aurora，像Airbnb、阿斯利康、BP、英国石油、哥伦比亚广播公司等等，为什么它增长这么快、人们这么喜欢这个服务呢？因为我们不断地聆听客户的心声，把客户的反馈放到我们的产品开发上。”

AWS加强了用无服务器的架构来支持Aurora，打造Aurora Severless，可以实现自动配置，自动为客户设定Aurora，在5到50秒内实现自动的扩展，当每次需要时，可以将容量翻倍。

此次亚马逊re:Invent，AWS发布新一代Amazon Aurora Serverless，Amazon Aurora Serverless v2可在不到一秒的时间内扩展至支持数十万个事务,与按业务高峰需求进行资源配置的方式相比,可节省高达90%的成本。

同时，AWS宣布了Babelfish for Aurora PostgreSQL,作为Amazon Aurora的一项新功能,该功能让客户在几乎无需更改代码的情况下,直接在Amazon Aurora PostgreSQL上运行SQL Server应用程序。另外,AWS分享了Babelfish for PostgreSQL开源项目的计划,此项目将使用宽松式的Apache2.0许可,并将在GitHub上发布。这一系列创新将使得Amazon Aurora Serverless对各种工作负载更具吸引力,将Amazon Aurora和PostgreSQL的优势带给更多的企业组织。

Andy Jassy介绍称Babelfish for Aurora已经可以注册使用，Babelfish for Postgre的开源项目在2021年会推出。

从Aurora到Babelfish for Aurora PostgreSQL，让客户摆脱了传统数据库供应商常见的惩罚性业务行为，AWS发起了对传统IT体系的进一步挑战。可以预见的是未来将有更多的数据库迁移上云，市场想象空间巨大，而AWS也将成为最大的赢家。（Ralf）

以下为译文

时下，我们正处于一个日新月异的时代，而优秀应用的响应时间往往需要被控制在0.1秒内。这也意味着，如果可接受网络通信时间为50毫秒，那么开发者必须在剩余的50毫秒内处理数据并进行响应。要实现这一点毫无疑问会需求毫秒级的数据库响应时间，在同时支撑上万个请求的场景中更是如此，而这样的需求当下只有少数几个灵活度极高、功能齐全的数据库才能满足。

在大数据处理情景中，洞见必须被快速收集并做出决策，而在没有复杂优化或折中的情况下，内存数据库可以在数秒内完成以往传统数据库数小时或者数分钟的工作。尽管如此，当下在内存数据库领域仍然存在诸多流言，大量人仍然认为内存数据库不可靠性、不一致并且伴随着昂贵的开销。然而最重要的是，还有人认为只要把数据库放到内存中就可以获得所需的性能。

流言1：所有内存数据库都很快

答案显然是否定的。即使当下大部分内存数据库都使用非常高效的语言编写，比如C和C++，但是它们仍然无法得到所需的响应需求，这主要基于以下几点原因：

1. 在不同数据库中，处理命令的复杂性是不同的。在高性能数据库中，处理命令会在最小复杂度下执行。最直接的影响就是就是，在数据集不断增大的情况下，你可能需要一直优化查询时间。

2. 查询效率同样不同。有些时候，数据库会把全部加载进内存的数据当做单一的BLOB（类似memcached的缓存机制），这显然是没有效率的——数据库应该具备分散存储和查询值的能力，以及有效地节约网络和内存开销，从而显著地降低应用程序处理时间。

3. 单线程和多线程架构的权衡。

多线程会尽可能的利用计算能力，无需数据库用户做任何处理，但是这个解决方案同样需要做大量的内部管理和同步，从而消耗大量的计算资源。在多线程模式下，锁开销可能会大幅度降低数据库性能。

单线程使用了一个非常简单的执行模型，在这个解决方案中不存在锁的问题，同时也只会耗费少许的计算性能，但毫无疑问的是，计算资源的管理将从数据库移交给用户。理想的解决方案肯定是让用户尽可能少地做资源管理，因为数据库管理本来就是个轻度资源密集型工作。

4. 零共享vs. 共享vs. 共享一切。共享会影响到系统的扩展性。在数据库体积不断增长的同时，性能也必须时刻满足实例的需求。零共享模型让所有实体都以独立单元的形式存在，从而避免了处理暴增后的通信开销，实现线性扩展能力。

5. 通过避免网络方面任务和减少TCP协议开销， 零延时分布式代理等内置加速组件可以显著地提升数据库性能。在某些情况下，代理也可能与数据库通信，以确定其是否作为主机上服务远程客户端的另一个本地客户端进程。

如果吞吐量和延时是主要目标，那么机构很显然需要选择一个可以实现毫秒级延时并最小化服务器需求的数据库。

流言2：内存计算是不可靠和不一致的

大多数NoSQL数据库（不只是内存数据库）在提交数据到磁盘或者副本之前都为客户端提供了acknowledgements （ack）。因此，这里很可能会造成数据不一致的情况。

CAP定理标明任何分布式计算机系统都不能同时具备一致性、可用性和分区容错性。不同的数据库会选择不同的类型，具体情形如下：选择CP模型表示开发者不用去关心一致性，但是在网络分割事件中写命令则是不允许的。如果选择AP模型则意味着数据库对读写一直可用，但是开发者在写应用程序代码时就需要考虑一致性问题，而不是期望数据库去完成这个操作。因此，请根据使用场景来选择合适的数据库模型。

流言3：内存计算很难扩展

扩展共有两个途径。首先通过给托管数据库的服务器纵向扩展，比如增加更多的CPU和内存；其次，通过向内存集群中添加更多的主机实现横向扩展。在许多数据库中，你可以在同一个节点上运行同一个数据集的多个分片，因此可以通过更有效率的计算资源利用来延缓扩展需求。同样，这里也可以将多个服务器的内存整合起来成为一个共享内存池，从而突破单机内存大小限制。现下，很多内存数据库同时允许这两种方法的扩展，通过动态的增加分配给数据库的核心和内存节点数量来最大化应用程序的响应能力。

流言4：内存计算是昂贵的

任何需要快速提升吞吐量的应用都面临着相同的问题：“一定等级的吞吐量究竟需要花多少钱”。举个例子，在1500万OPS情景下，运行在单Amazon EC2实例上的内存数据库会比非内存数据库便宜，但是如果使用数百台服务器达到同样的效果结果可能就会截然相反。

如果数据集规模是TB级别，内存的花费很显然会成为问题，然而当下已经有使用闪存扩展内存的技术存在，从而降低花费。但需要注意的是，使用闪存来扩展内存势必会影响到系统性能，因此这里理想的技术是控制闪存和内存的比例以达到一个理想的性价比。

综上所述，根据实际场景来选择合适的数据库技术将会大幅度提高资源利用效率。同时，新型数据库出现已有很长一段时间，因此抛弃不必要的成见才能让工作事半功倍。

原文链接：Busting 4 Myths of In-Memory Databases

翻译/OneAPM工程师

而增长速度最快的亚军是 PostgreSQL 最新排名第 4；第三名是 Cassandra 跻身前十。

伴随着“Web 2.0”理念的兴起，互联网正在由过去单纯的页面变成一个个平台，UGC 模式大行其道，新技术浪潮不断涌现，互联网上的数据正在呈几何级数的增长，而相应的，这些海量数据也在一定程度上被不断创造新平台的我们所遗忘。

有时候，放慢脚步四处看看，是为了将来走得更快。来自伦敦的创业公司Importio正是抱着这样的念头，打造出一款大数据平台软件。他们刚拿到 900 万美金的种子融资。

CEO David White 称，Importio 旨在以网站为数据源，打造动态的数据库，开发者和公司可以从中连接或提取数据，进而创造出新的数据。为此他们设计了一套十分简洁的交互界面，用户只需在你想要抓取数据的网站上进行几次简单的点击操作，Importio 会根据你的操作推算出你想要抓取的数据，进而创建一个与这些数据的实时连接，接下来你只需选择想要的导出形式（电子表格、数据库或是搜索索引），就可以获得一份指定内容、实时更新的数据了。

用简单的交互操作获取实时更新的海量数据，Importio 的想法非常妙，但有两点需要注意：第一，目前许多大型网站都有一套相应机制来抵御来自外部的数据抓取，Importio 的功效还有待检验；第二，这种抓取他人网站数据的做法很可能牵涉到一系列法律纠纷，Importio 在这方面还需要下一番功夫。

因此，选择一个合适的数据库对于游戏的成功就格外重要了。许多数据库都能支持少量的DAU。但是，当游戏玩家暴涨时，最好能有一个始终传递高性能同时支持更大量DAU的数据库。否则，如果你的游戏会因不能拓展而被玩家抛弃，那么你制作出这么一款有趣的游戏的努力就付诸东流了。

因为性能和延展性的优势，NoSQL数据库越来越多地用于社交游戏。但开源代码的NoSQL数据库项目似乎就像雨后春笋，在世界各地萌发，要从中做出选择可能是件棘手的工作。为社交游戏选择正确的NoSQL数据库可能非常困难，因为有各种各样的分类，如key-value、文件和纵列等。但哪一类才是最适合社交游戏的呢？

zynga-chart(from devopsangle.com)

key-value和文件型数据库可以增强大多数NoSQL对社交游戏的资源配置能力，这很大程度上是因为它们平衡以下4个关键指标：

1、NoSQL支持高性能。文件和key-value数据模式在内存和硬盘（文件）的单一物理空间中保存相关数据。这使用户可以始终快速地获取数据——避免读取和写入时时发生延迟。现在的游戏玩家不能忍受哪怕是最短的中断时间，否则他们就会认为程序很失败，然后就不再使用了。你要寻找的就是一种可以稳定维持毫秒读取和写入的数据库。

2、NoSQL具有动态弹性。因为文件方法将记录保存在“单独的地方”（一个文件放在邻近的物理位置中），所以要从一个服务器把数据转移到另一个上，同时保持连贯性、不发生中断，就要容易得多了。为了使数据库的工作能力与程序的总体性能要求有效匹配，必须在服务器之间转移数据，数据库必须能够增加或移除群集。如此操作的同时又不中断游戏的收益流，这对游戏的盈利性有重要影响。只需轻轻点击一个按扭就把服务器添加到数据层中，不需要改变程序本身，你要寻找的就是这样的数据库。

3、NoSQL具有架构灵活性。虽然所有NoSQL数据库都具有架构灵活性，但key-value和文件型数据库在这方面的优势更明显得多。在增加新纵列和分类时，纵列型数据库仍然需要维护。key-value或文件型数据库不需要数据库维护就能改变数据库架构。

4、NoSQL支持询问变更。用询问表现力（向数据库发问的能力，比如，“返回一份记录玩家于去年购买向日葵种子的所有农场的列表”）平衡架构灵活性往往是很重要的。文件型数据库在数据库层上提供索引和查询，而key-value型数据库只允许访问与给定键相关的数据记录。

如果你在考虑开发一款社交游戏，请考虑一下支持游戏成长的基础设施要求。正如我们所说的，管理社交游戏中的数据是最重要，也是很灵活的事。并行随机读取和吞吐率、数据格式灵活性都是NoSQL文体型数据库能应对的。你的数据库技术是最重要的基础建设组成部分。

via：游戏邦/gamerboom.com