任何一家企业想要获得持续性的发展与盈利，“降本”是难以绕开的命题。在企业普遍进行数字化转型的今天，研发成本占据了总成本非常大的部分，而随着企业业务量的发展，数据也呈指数级增长，因此数据库成为研发成本的一个重要环节。那么，大容量数据存储如何做到技术降本呢？
保证在极限吞吐量且不损失、性能稳定的前提下完成降本目标，变得至关重要，这也是 OceanBase 正在做的事 —— 为大容量数据存储如何做到技术降本提供思路。OceanBase 具备以下几个特性：
- LSM-Tree 高级压缩引擎：显著降低70-90%的存储成本。OceanBase 的存储引擎是基于 LSM-Tree 自研的一套高级压缩的存储引擎，相比于MySQL B+ 树存储结构下每个页中都会有一些空隙，天然压缩比会更好。并在此之上又进行了2次压缩，包括行列混存的存储格式和通用压缩，显著降低大容量数据存储。
- 单集群多租户整合实例：对于多应用多实例的企业，如何提升资源利用率，降低运维难度是技术人员所关注的。OceanBase 通过多台机器和资源部署成一个资源池，为每个租户定向划分独属资源，并可随时随地动态调整规格，支持灵活调度所有资源，优化大容量数据存储资源规划。因此，企业直接管理一套 OceanBase 集群就可以，运维难度显著降低。
根据 OceanBase的产品特性和能力，整体而言，可以按照原有 MySQL 实例规格之和的 80%-95%，存储容量之和的 15%-20%，估算 OceanBase 集群的规格大小。下面我们通过两个例子，来具体看一下大容量数据存储如何做到技术降本的方案制定和效果判断。
Eg.1 中小型公司的大容量数据存储如何做到技术降本
对于中小型公司，比如图中的例子，该公司有一个 16C 的 RDS，2 个 4C 的 RDS，以及 4 个 2C 的 RDS，这是一个非常常见的产品阵列。
- 16C 的 RDS，最大的库，用在公司核心的对外业务，资源占有率也比较高；
- 2 个 4C 的 RDS，用在一些二级业务，比如说库存、订单之类的系统，资源占有率可能相对较低；
- 4 个 2C 的 RDS，这些比较小的零散实例，用在内部的业务。
总之，这些库的资源占用率会根据他们业务属性的不同，有所波动，所以在运维时，也会比较麻烦，那大容量数据存储如何做到技术降本？如下图所示，16C + 2*4C + 4*2C = 32C；3TB + 2TB + 1TB = 6TB，如果将其迁移到OceanBase 上，一套 30C 的 OceanBase 集群 ，1.5TB 的存储就可以完全支撑所有业务，并且将原来的零散资源变到一个比较健康的水位。
在 MySQL 中，OceanBase 高可用版本对标 MySQL 的集群版，然后也要多可用部署，并且是独享规格。由于OceanBase 是技术降本，所以这里将二者的总吞吐量进行了对比，在 sysbench read-write 1000 并发场景下，降本约 30%，具体数据见下图，直观分析了大容量数据存储如何做到技术降本。
Eg.2 大型公司的大容量数据存储如何做到技术降本
某大型公司，该公司有 32C 的 RDS 支撑核心业务，16C 的 RDS 支撑二级业务，5 个 4C 的 RDS 支撑内部小业务。总体资源利用率与上个案例相差不大，总计算资源 32C + 16C + 5*4C = 68C；10TB + 5TB + 5TB = 20TB，了解他们的大容量数据存储如何做到技术降本？此时如果在 OceanBase 上，一套 62C 的 OceanBase 集群加上 4TB 的存储就可以承载这套集群。
关于怎么去规划大容量数据存储的成本，这里简单介绍一下二者的区别。在 sysbench read-write 1000 并发场景下，在 MySQL 中，假设计算资源 68C 的话，会有 136C 作为备机，存在很大的资源浪费。而在OceanBase 中，我们有 62C 的计算资源，通过主备打散的方案把所有机器利用起来，总成本降低约 40%，具体数据可见下图。
所以，关于大容量数据存储的问题，OceanBase 的“降本”是通过技术手段进行降本，希望数据库的总体价值得到提升，不管是数据吞吐量、高可用能力、Online DDL 能力等，还是运维友好度，都可以不随着成本的降低而丢失。
