据 2023 年的数据显示，互联网广告发布收入达到 7190.6 亿元，同比增长 33.4%。当今互联网广告已经深入到我们的日常生活中，成为不可或缺的一部分。
1. 计算广告的业务流程
在传统的计算广告业务流程中，广告的展示需要涉及多个参与方，包括用户、广告主、媒体平台、广告交易平台（ADX），以及需求方平台（DSP）等。并且，这一过程通常需要经历十几次的交互才能最终完成广告的展示。
整个广告展示过程需要控制在 100 到 200 毫秒之内完成，以确保用户体验和企业效益的最大化。在这一高效率要求中，数据库的能力对于广告系统的性能至关重要：
-
快速读写能力：广告系统频繁地更新和检索数据，包括用户行为数据、广告表现数据等，广告加载时间对用户体验至关重要，因此需要一个能够支持高速读写操作的数据库。
-
可扩展性：随着用户量和数据量的增加，数据库需要能够水平和垂直扩展，使得广告系统可以处理更多的查询和存储需求。
-
高可用性：对于广告系统来说，数据库的高可用性至关重要，均配有灾难恢复计划和备份机制，以应对数据中心故障等极端情况以确保广告服务的连续性和稳定性。
2. 广告行业数据库解决方案的演进
基于业务场景的演进，广告系统也在不断升级业务解决方案。
在早期阶段，广告系统选择采用高性能的 Redis 内存型数据库，来满足整个业务流程对低延迟的诉求。
随着广告行业规模逐年增长，广告系统的数据总量以及存储成本水涨船高，Redis + MySQL 成为新的方案。业务将热点数据导入 Redis 中，将冷数据存储至 MySQL，整个广告系统在性能和成本两者间做到最优。
不过，Redis 和 MySQL 之间通过手工维护实现冷热数据的流转的运维方法，已经无法在大规模业务场景下，及时响应业务最新的变化。
基于 SSD 构建部署的 KV 数据库成为了新的解决方案。
3. PegaDB 提供全方面的解决方案
百度智能云数据库 PegaDB（Redis 容量型） 基于增强型 SSD 云盘构建，通过自研内核实现冷热数据的自动分离与交换。同时，提供配套的异地多活、Bulkload 等企业级特性，可以满足现代广告系统对高效率、高可用性和低成本的综合需求。
结合广告场景中的具体问题， PegaDB 在产品层、架构层、业务应用层给出了全方面的解决方案升级：
-
在产品层，通过内存 + SSD 结合的方式，基于自研内核支持冷热数据自动分离与交换，解决了数据同步一致性的问题；
-
在架构层，提供了采用异地多活的高可用架构的方案，实了跨地域数据灾备与自动化同步；
-
在业务应用层，快速灌库 Bulkload 实现大批量数据的快速导入，相比传统方法数据导入速度提升 5~10 倍。
3.1 冷热数据分离与交换
3.1.1 传统方案
考虑到兼顾性能与成本，广告行业传统通常采用的是 Redis + MySQL 架构设计，热数据存放在内存型数据库 Redis 中 ，全量存储数据存放在 MySQL 。
应用会首先访问 Redis 数据库，若 Redis 中有该数据，则将该数据直接从内存返回给应用。若 Redis 中没有该数据，则会进一步查询 SSD 中的 MySQL，再返回给应用。如果该数据在短时间内被频繁访问，则升级为热数据，由运维人员手工将数据从 MySQL 同步至 Redis，以便加速应用的下一次访问速度。
在大规模场景下，这不仅会拖慢系统性能，同时也会增加业务人员的工作量。
3.1.2 基于 PegaDB 的解决方案
PegaDB产品将内存与 SSD 相结合，内存支持毫秒级在线数据处理，SSD 提供数据持久化能力，实现数据高可靠。同时内核自研的冷热数据分离与交换功能，解决了数据同步一致性的问题。
PegaDB 可对广告位的配置信息以及策略信息等数据进行冷热分离。更新 Cache 的逻辑设定为每 10 秒钟一个周期，每周期清空 LRU Cache 中的旧数据（即最长时间未被访问的数据，被视为冷数据），同时更新最新的热点数据，将热点数据加载到缓存中。
热点数据在内存中实现高效访问，而非频繁访问的冷数据存储在 SSD 中。借助 LRU 算法淘汰机制实现冷热数据高效切换，及时响应业务动态变化，确保广告系统一直处于高性能状态。同时，有效避免人工大量处理的问题，节省人工成本。
在处理大规模业务数据时，PegaDB 单 GB 成本比传统 Redis 解决方案降低超过 70%，同时保持了接近原有 Redis 性能的 80%。
3.1.3 具体实现
-
PegaDB 会维护一个 LRU Cache，用于缓存热数据，通过 LRU 机制淘汰冷数据。
-
数据读取时，优先访问 LRU Cache 中的 key，若命中则返回 Cache。若未命中则从 DB 读取数据，读取后自动数据同步到 LRU Cache，下次就可以在 LRU Cache 中直接访问到该数据。
-
通过读操作可将最新的值缓存到 Cache 中，更新 Cache 的逻辑一般以 10s 为周期，每 10s 进行一次操作，清空 LRU Cache 的旧数据，更新最新的热数据。时间周期可按业务需要调整。
3.2 异地多活
3.2.1 传统方案
在多地域数据管理中，保持数据的同步性常常着面临诸多挑战。不同地域的数据信息同步需要使用专业的数据复制和同步工具（如 GoldenGate、SharePlex 等）手动写入，并且操作过程中需要专业人员执行、维护。
此外，还有一种方法是将数据库的事务日志定期或实时传输到远程地点，然后在远程数据库上重放这些日志来实现数据同步。尽管这种方法可以在不同地域之间同步数据，但整个过程复杂性高、时间周期长。
3.2.2 基于 PegaDB 的解决方案
PegaDB（Redis 容量型）推出了自研的多活实例组方案。多活实例组由至多 5 个实例组成, 每个实例均可以进行本地域读写，无需专业人员手动写入、维护，每个地域数据由同步组件自动化同步至其他地域，省时省力。多活实例组应用场景如下：
-
异地多活: 业务需求应用就近访问同时数据整体一致。
-
数据灾备: 可实现同城灾备、两地三中心灾备及三地灾备等多种数据灾备场景。
基于 PegaDB 的异地多活同步通道单向可达 5 万 QPS。本地域读写与单实例的延迟基本一致。跨地域间同步，延迟几十毫秒至几百毫秒。
通过异地多活的架构设计解决了多地域数据同步一致性的问题。同时，数据自动化同步至其他地域，无需专业数据复制与同步工具手动写入，节省了人力成本。
3.2.3 具体实现
在异地多活集群中，每个实例都会为其配置一个数据同步组件，这个同步组件的叫做 SyncAgent。单个分片内部，只有主节点的 SyncAgent 会工作。SyncAgent 会解析 Redis 生成的 AOF 并将增量的 AOF 同步到目标集群。
在PegaDB架构中，引入operator header，用于为生成 AOF 中的每一条命令增加一个编号，这样SyncAgent 就可以记录下 opid 来追踪同步进度，当 SyncAgent 故障重启后，SyncAgent 会从之前的同步位点继续同步，避免数据丢失。
3.3 Bulkload 快速灌库
3.3.1 传统方案
在双十一大促等特殊活动时，客户需要增加广告投放和活动预算，此时需要将大批量数据快速导入数据库。大批量的数据导入占用资源会影响线上业务。
按照传统协议的命令，批量写入数据一方面写入速度有限，另一方面写入数据占用资源会使得线上业务访问延迟增加，影响用户体验。
3.3.2 基于 PegaDB 的解决方案
依托 RTA 业务场景大数据平台的高并发处理能力和自身存储引擎的数据编排能力，数据灌库（Bulkload）支持大规模的数据通过专属通道直接传入存储引擎。数据导入速度相比传统提升 5~10 倍，并减少了对在线业务的影响。
基于PegaDB 的离线灌库方案从数据库层面解决了业务场景批量离线快速灌库、全量数据原子生效、秒级切库和回滚等需求。在业务层面解决了传统数据库只能通过标准协议逐条写入数据，写入速度慢、资源占用影响线上业务的问题。
3.3.3 具体实现
-
准备原始数据：使用百度智能云对象存储 BOS ，业务将原始 KV 数据以指定的格式写到文件并上传到 BOS。
-
生成 SST 文件：借助百度智能云 MapReduce 平台 BMR ，业务向 BMR 平台提交 MR 作业，业务需要指定两个 BOS 地址，分别为原始 KV 数据文件 BOS 地址和生成 SST 文件输出的 BOS 地址。MR 作业的功能是将原始 KV 数据转化为 PegaDB 能够识别和加载的 SST 文件。
-
注入 SST 文件：业务提交注入任务，在注入完成后，新注入的 SST 文件对 PegaDB 可见，但对业务不可见。每一批生成的 SST 文件会对应一个命名空间 namespace，注入完成后，集群会新增一个 namespace，新 namespace 则表示刚注入的数据。（通过 API 可以查询）
-
数据切换：业务提交切换任务，将数据切换到新注入的 namespace。切换完成后，线上访问的对象为新注入的数据。切换耗时为秒级，不断连不阻写。（若数据不合预期，业务可以提交切换任务回切到老的 namespace）
-
数据删除：切换完成后，老数据还会占用磁盘空间，业务可以在命令空间提交删除老数据的任务，整个删除的任务流程耗时为分钟级，任务完成后，磁盘空间会立即腾出，删除过程不断连不阻写。
4. 客户案例
目前，PegaDB 已经帮助互联网视频公司、AI 设备终端公司、营销科技公司等实现了广告系统升级。
其中，度秘将 PegaDB 作为其广告系统数据库，用于存储广告物料、投放数据和用户画像等。通过 PegaDB 对缓存数据和物料耗时数据的优化，度秘实现了数据之间的高效同步和大规模数据批量导入效率的显著提升，实现运维成本降低 50%+，不同地域业务数据之间高效同步，大规模数据批量导入效率提升 5 倍+。