https://tianchi.aliyun.com/competition/entrance/532117/information
竞赛题目背景
PolarDB是阿里云瑶池旗下的自研云原生数据库。自6年前诞生伊始，PolarDB产品日益成熟，持续进行创新，并维护了大量云上核心用户的海量数据。PolarDB在业界率先提出了计算、内存、共享存储的三层解耦架构。PolarDB是国内首个使用共享存储架构的数据库产品，基于自研的PolarStore高性能网盘，拥有高IO性能和存储弹性。
在PolarDB的共享存储架构中，主节点与多个只读节点共同读写统一的高性能存储。共享存储部分使用“按量计费”的方式，对实际产生的持久化数据收取存储费用，“数据页”在持久化数据中占比最高。如果能对数据页压缩存储，将进一步降低用户的使用成本，从而提升产品价值。同时压缩的数据页也将降低整体的IO负载，从而提升性能。
数据页有一些突出特点，将影响压缩方法的设计：
1.数据被统一划分为16KB的数据页，以达到最佳的磁盘IO效率
2.数据由B+树维护，相同表内的数据字段格式统一
3.数据页读写性能较为敏感，将直接影响数据库整体性能
赛题大纲
典型的数据库存储引擎中，用户读写请求并不直接读写持久化数据。Buffer Pool承接了对数据页的本地高频读写，从磁盘中读取数据页成为“Clean Page”，将不再被频繁访问的“Dirty Page”写回磁盘。
本次赛题专注于单个数据表的持久化数据读写，如图中红色部分所示。选手需要在给定的数据页读写接口下实现数据压缩与解压算法，并设计持久化数据的组织方式。比赛分为初赛和复赛两阶段。初赛与复赛使用相同的赛题，但有不同的要求与评分标准。初赛只评测“数据压缩率”，复赛将加入性能评测。
赛题
在给定的数据页读写接口下，实现数据压缩与解压算法。接口示例：
class PageEngine {
public:
// Open engine
static RetCode Open(const std::string& path, Engine** eptr);
// Close engine
virtual ~PageEngine();
// Write 16KB page into disk
virtual RetCode pageWrite(uint32_t page_no, const void *buf);
// Read 16KB page from disk
virtual RetCode pageRead(uint32_t page_no, void *buf);
}
注意：
1.简单起见，所有读写仅涉及单一数据表，因此只使用一个page_no索引数据页
2.参数page_no表示数据库一个数据文件中的数据页编号，从0开始依次递增1，每个数据页固定16KB大小
3.参数path为可供读写的持久化数据目录，除此目录外均没有读写权限
4.参数buf为预先分配的16KB内存空间
a.在pageRead中需读取磁盘并将数据页16KB内容解压后写入buf中
b.在pageWrite中需将buf所指向的16KB内容压缩后持久化至磁盘
评测逻辑
我们提供阿里云4vCPU ECS + 200GB PL1 ESSD的线上测评环境，提交代码将自动触发在线测评。
初赛
初赛不对性能做任何要求，仅评测“数据压缩率”。具体来说：
1.内存限制50MB（不含测评程序使用的内存）
2.只允许读写给定的path目录
3.评测Trace将单线程运行，每条Trace执行不超过6553600次读写
4.原始数据表大小不超过10GB，page_no不超过655360
5.每条测评Trace超时时间为30分钟
1)正确性评测：
评测程序对数据页进行单线程的读写：
1.读取到的数据需与此前最后一次写入的相同
2.数据读写是交替进行的，相同数据页可能读写多次
3.读取未写入过的数据页是未定义行为，不做要求
2)性能评测：
评测程序按照多个预先选定的Trace进行数据读写，数据及读写Trace采样于PolarDB测试实例。每条Trace运行完成后，将统计数据目录下文件总大小S，计算S除以原始数据大小 即“数据压缩率”作为最终分数，越低越好。
复赛
数据库对读写的性能较为敏感，同时对数据的持久性及故障安全有很高的要求。
具体来说，在初赛的基础上：
1.评测Trace将多线程并行执行，不再保持单线程运行
2.数据压缩率将根据初赛结果选定一个最大限值
3.数据页读写的性能将作为测评的唯一评分指标
4.程序需要是故障安全的
1)正确性评测：
评测程序对数据页进行多线程的读写：
1.对数据页的读写会按page_no打散至多个线程执行，特定一个数据页只会由特定一个线程执行读写。因此程序需要做多线程安全的设计，但无需考虑单个数据页被多个线程同时读写时的一致性问题
2.测评程序可能在某次读写完成后kill进程并重启测评，重启后从尚未完成的数据页读写开始继续执行。程序应当保证已完成的数据写入不会丢失。简单起见，故障不会中断正在进行中的读写操作。
2)性能评测：
评测程序按照多个预先选定的Trace进行多线程数据读写和故障重启，数据及读写Trace采样于PolarDB测试实例。每条读写Trace执行完成时，将统计Trace整体执行时间T，计算总数据页读写次数除以T 即“IOPS” 作为最终分数，越高越好。
注意：“数据压缩率”大于限值将无法完赛，不计入成绩。“数据压缩率”本身不再记分。
赛题规则及选手提交说明
语言限定：C/C++
程序目标
下载样例程序，编译并运行本地测试：https://atomgit.com/polardb_tianchi/page_compression_2023
阅读include/page_engine.h代码了解基类PageEngine定义
page_engine/目录包含了示例接口实现，能够运行本地测试但未实现数据压缩
template/目录包含了空白接口模板，可在此基础上实现自己的数据页压缩引擎
test/目录包含了不同场景的本地测试脚本，可在提交线上测评前本地运行
请参赛选手详细阅读README文件与示例代码，按照接口标准和编译要求实现，并于比赛开始后提交代码。
‒ 下载示例数据，调优程序性能：https://atomgit.com/polardb_tianchi/page_compression_2023_sample_trace
提交评测
打包一个zip格式压缩包提交，确保广度优先遍历到的第一个page_engine文件夹为提交测评的接口实现目录
排名规则
比赛正式开始后方可提交代码，在线测评环境完成测评后将上传分数并排名。编译失败、内存OOM、运行超时、正确性评测不通过、压缩率大于限值(复赛) 等异常，均不作为有效成绩。
初赛：根据“数据压缩率”记分并排名
复赛：根据“IOPS”记分并排名
作弊说明
试图获取非公开的测评原始数据，试图绕过内存、目录权限等资源限制，及其他影响比赛公平的行为，将被判定为作弊
评测限制
因评测资源有限，赛事方会对选手的评测次数进行一定的限制，以“提交结果”栏显示为准
参考材料
innodb数据页的内部结构：https://www.leviathan.vip/2019/04/18/InnoDB的文件组织结构/#数据页-Index
阿里云ESSD (块存储) 性能特点：https://help.aliyun.com/document_detail/25382.html
