OceanBase 认为，云数据库作为数字化的核心基础设施，必须为企业用户提供极致的性价比，真正降低 TCO，才能长期稳定地支撑业务的创新与发展。本文将分享 OB Cloud（OceanBase Cloud）对云数据库实现可持续降低 TCO 的思考，介绍我们在数据库云化架构下的技术创新思路和方案。
下文主要讨论计算与存储两类成本，降低这两类成本可以立竿见影地看到降低 TCO 的效果。
一、降低计算成本：用更少的计算资源，带来更强的性能
原生分布式：所有计算节点均能提供读写服务，无 Standby 节点。与集中式数据库不同，作为降低 TCO 的有效手段，OceanBase 分布式数据库可以为用户提供多节点多写的能力，业务系统能够充分利用 OceanBase 集群所有节点的计算资源，并随着集群规模增长呈水平线性扩展。
单机分布式一体化：更少的计算资源与更强的计算性能，降低 TCO 的同时保证业务高效运作。单机分布式一体化架构让 OceanBase 引擎实现了两个飞跃：一是更少的计算资源，支持更小的部署规格，满足中小规模企业的需求。二是更强的性能，单机性能媲美甚至超越传统集中式数据库，同等硬件环境下，OceanBase 的 OLTP 性能是 MySQL 企业版 8.0 的 1.9 倍（Sysbench 基准测试结果），OLAP 性能是 Greenplum 6.22.1 的 5 至 6 倍（TPC-H 100GB 基准测试）。
HTAP：一份数据同时支持高性能的 TP 与 AP 混合负载。传统的在线 AP 分析架构会带来三个问题：成本、延迟、复杂度，需要有一个额外的 AP 计算与存储成本，而在实际生产系统中经常出现数据同步延迟或者同步出错导致的线上故障。OceanBase 的底层采用了一个基于 LSM-Tree 的行列混合式存储方案，能够在 OLTP 和 OLAP 二者性能取得很好的平衡。同时，OceanBase 也支持 OLTP 和 OLAP 的资源隔离，实现更可靠的负载管控，帮助降低 TCO。
原生内置的多租户机制：提升数据库资源利用率与管理效率。OceanBase 内置多租户机制，可以将多个 MySQL 实例合并到一个集群中。以蚂蚁集团实践为例，一个典型场景是将有波峰、波谷的业务放入一个集群，比如白天跑业务、晚上跑批和分析，混合部署能够充分利用整个集群的资源和存储空间，由此降低 TCO。
二、降低存储成本：在高性能的前提下，实现更高效的压缩
自适应数据压缩特性：超高数据压缩机制，节省 70~90% 数据库存储成本，降低 TCO
OceanBase 的存储引擎基于 LSM-Tree 存储管理机制，增量数据写内存的 MemTable，之后数据会定期转储与合并，将数据合并到基线 SSTable 中。
OceanBase 单机存储引擎
OceanBase 也利用上述优势实现了一个全新的数据压缩特性，已在蚂蚁及外部客户的业务中经过较长时间实践，切实帮助企业降低 TCO。该设计包括行列混合存储以及高效的数据编码技术，可以大幅减少业务的存储空间。通过自适应编码压缩技术，OceanBase 可以根据数据内容（按列）自动选择最合适的编码算法，OceanBase 数据库提供了多种按列进行压缩的编码格式，根据实际数据定义进行选择，包括列存数据库中常见的字典编码、游程编码 (Run-Length Encoding)、整形差值编码 (Delta Encoding)，以及常量编码、字符串前缀编码、Hex编码、列间等值编码、列间子串编码等。
从客户业务场景的实践效果来看，业务系统迁移过程中，数据压缩能够让存储空间降低到 1/3，也有场景能够直接下降 90% 的存储空间，降低 TCO。更为重要的是，在压缩目标实现的同时，OceanBase 的查询性能不会下降，相反，写入（合并）性能反而会有一定程度的提升。
Paxos 多副本机制优化，计算/存储/网络成本均下降 67%
数据库经典的三副本部署结构，需要将数据存在三个副本，每个副本上均有全量的日志文件与数据文件。这类副本结构在 OceanBase 称之为全功能（Full）副本，进一步地，如果一个节点上所有副本均是全功能副本，我们称呼这个节点是一个全功能节点。在大多数场景中，业务均采用三个全功能节点部署的方案。
假设我们以这个三副本结构为基准，计算和存储都需要 100% 的成本。OceanBase 4.0 版本之前提供日志（Log）副本的机制，日志副本仅参与 Paxos 的投票与日志复制的日志，日志副本并不会存基线数据，所有节点上所有副本均是日志副本，称之为日志节点。这个日志节点上只有日志文件、无数据文件，存储成本约下降 33%，同时因为日志节点只需要参与投票与日志复制，对节点的性能要求较低，计算成本下降 20%，这种即是 OceanBase 支持降低 TCO 的 F-F-L（2F1L）结构。
从 OceanBase 4.0 开始，我们将日志节点变成仲裁（Arbitration）节点，仲裁节点仅参与 Paxos 的投票无需日志复制，这样的方式可以让仲裁节点变得非常轻量，无需日志节点与数据文件，存储成本会下降 33%，对性能要求极小所以计算成本也可以下降 33%，也因为无日志复制，能够减少额外的网络带宽成本，同时支持跨城的轻量部署，有效降低 TCO。
Paxos 多副本优化路径
灵活的云存储介质：提供最合适的云存储介质与云存储成本
OB Cloud（OceanBase Cloud）部署在云上之后首先需要基于降低 TCO 的前提下考虑云存储的选择，云厂商给各种不同的业务场景提供丰富的云存储选择，但也存在不少限制。以阿里云为例：本地 SSD 盘、本地 HDD 盘、高效云盘、SSD 云盘、ESSD 云盘（PL0、PL1、PL2、PL3），其中本地盘性能（延迟、IOPS、抖动等）都是数据库的最佳选择，但是其最的缺陷即盘的空间大小和机型规格绑定。以 ecs.i2.2xlarge 为例，只能选择 2 * 1788GiB 的本地盘，ecs.i2.4xlarge 则是 4 * 1788GiB 的本地盘，也受限于机型，仅有部分本地盘机型可以选择本地盘。云盘则有按需使用的优势，但是它存在的问题也比较明显，比如说因为云盘的访问需要走网络，所以延迟比本地盘高，各种网络抖动比较明显，IOPS 也受限于 ECS 的规格。
OB Cloud（OceanBase Cloud）综合了降低 TCO 的考虑，针对云盘做了非常多的优化，也特别针对历史库归档场景进行优化，支持将业务的历史“冷”数据归档到 OceanBase 数据库低成本存储（如 HDD、ESSD PL0 中），后续会支持自动冷热数据分离，可自动将“冷”数据归档到成本更低的对象存储（如阿里云的 OSS、AWS 的 S3 等）中。
OceanBase 认为，云数据库作为数字化的核心基础设施，必须为企业用户提供极致的性价比，降低 TCO ，真正实现降本增效，才能长期稳定地支撑业务的创新与发展。
