# 特性规格
对于高级压缩（ADVANCED）：
- TPCC只开启策略、不开调度对原有业务无影响。
- TPCC不开启压缩策略对原有业务无影响。
- TPCC.bmsql_order_line设置ILM策略（只识别完成派送的订单为冷行）不调度，TPmC劣化不高于2%（56核CPU370GB内存+3TB SSD硬盘，350GB SharedBuffer）。
- TPCC.bmsql_order_line设置ILM策略（只识别完成派送的订单为冷行）后台默认参数调度时，TPmC劣化不高于5%（56核CPU370GB内存+3TB SSD硬盘，350GB SharedBuffer）。
- 单线程ILM Job带宽约100MB/秒（56核CPU370GB内存+3TB SSD硬盘，350GB SharedBuffer）。 度量方式：根据执行压缩的开始时间和结束时间以及压缩的页面个数计算带宽。
  
- get查询访问压缩数据比非压缩数据性能劣化，驱动侧不高于10%，plsql侧不高于15%（32MB SharedBuffer，6万页面数据）。
- multi-get查询访问压缩数据比非压缩数据性能劣化，驱动侧不高于30%，plsql侧不高于40%（32MB SharedBuffer，6万页面数据）。
- table-scan查询访问压缩数据比非压缩数据性能劣化，驱动侧不高于30%，plsql侧不高于40%（32MB SharedBuffer，6万页面数据）。
- TPCH.lineitem表压缩比（全冷行）不小于2:1。
- 对于TPCC的Orderline表，以及TPCH的Lineitem、Orders、Customer、Part表的测试表明，数值型字段较多时，压缩率高于LZ4和ZLIB；而文本型字段较多时，压缩率介于LZ类和LZ+Huffman组合类的压缩算法之间。
- 如果指定high级别压缩策略：
  - 压缩率：以tpch.lineitem表为例，high级别比medium级别压缩率Astore和Ustore提升10%。
  
  - 性能：ZSTD算法适用于对性能不敏感的历史业务场景，访问压缩行的性能会有较大劣化。以TPCC场景为例：默认压缩参数设置（关闭元数据压缩等），4张流水表bmsql_history、bmsql_new_order、bmsql_oorder、bmsql_order_line都压缩，再执行TPCC业务，1000仓500并发下，Astore性能劣化可能超过30%，Ustore性能劣化可能超过40%。
   
- 对于TPCH.lineitem表（scale = 1）及TPCC.bmsql_order_line、bmsql_history、bmsql_oorder、bmsql_customer表（32仓），默认参数场景且表未压缩情况下（采样率20%，采样数据量\>12MB），GET_COMPRESSION_RATIO接口（数据全压）预测压缩率平均误差不超过10%。
- sysbench场景，默认压缩参数下，开启元数据压缩，与不压缩相比，执行查询（read only） - 过滤条件带rowid性能下降不超过70%。
 
对于索引压缩（ADVANCED）：
- high级别压缩策略下，单线程对TPCC标准模型的4张流水表bmsql_history、bmsql_new_order、bmsql_oorder、bmsql_order_line索引build压缩，build耗时平均劣化不超过50%。
- medium级别压缩策略下，单线程对TPCC标准模型的4张流水表bmsql_history、bmsql_new_order、bmsql_oorder、bmsql_order_line索引build压缩，build耗时平均劣化不超过30%。
- high级别压缩策略下，对TPCC标准模型的4张流水表bmsql_history、bmsql_new_order、bmsql_oorder、bmsql_order_line索引build压缩，平均压缩率为5比1。
- medium级别压缩策略下，对TPCC标准模型的4张流水表bmsql_history、bmsql_new_order、bmsql_oorder、bmsql_order_line索引build压缩，平均压缩率2.5比1。
- medium级别压缩策略下，CPU：88U，内存：384GB，磁盘：64TB，TPCC场景，4张流水表bmsql_history、bmsql_new_order、bmsql_oorder、bmsql_order_line堆表和索引都压缩后（关闭元数据压缩），执行TPCC业务，1000仓500并发下，与只压缩堆表相比，性能下降不超过10%。
- medium级别策略下，CPU：88U，内存：384GB，磁盘：64TB，索引和堆表都压缩后（关闭元数据压缩），与只压缩堆表相比，sysbench执行查询（read only）和写入（insert）性能下降不超过10%。
 
对于copy批量导入时压缩：
- 典型场景压缩率：具体压缩率和数据集以及数据分布相关。以tpch.lineitem表为例，copy批量导入的压缩率和调度时压缩保持一致2:1。
- 性能规格（以16U，64GB为例，默认压缩参数下，即不开启元数据压缩、索引压缩等参数）：
  1. 导入压缩时性能：
     - 以TPCC和TPCH场景为例，默认压缩相关参数下（不开启元数据压缩等），copy单线程导入，与直接copy导入数据相比，copy导入时压缩的性能（耗时）劣化低于20%（导入后再创建索引，tpch.lineitem表，以及TPCC的bmsql_history，bmsql_oorder和bmsql_order_line表）。
     
     - 对于压缩率较低的表，由于压缩无I/O收益，并且增加了CPU消耗，这种表copy导入的性能劣化可能较为严重，例如tpcc.bmsql_customer表的性能劣化可能在30%以上，因此对于压缩率较低的表不建议执行copy导入压缩。
      
  
  2. 导入压缩后性能：和调度压缩保持一致，TPCC的4张流水表bmsql_history，bmsql_new_order，bmsql_oorder和bmsql_order_line导入时压缩，不开启元数据压缩和索引压缩，全压缩后再执行TPCC业务，1000仓500并发下，性能下降不超过10%。
   

- 压缩策略以copy指定策略为准，覆盖表/分区策略：
  - 对于表：以copy指定策略为准，忽略表上ILM压缩策略，即便表上无ILM压缩策略，也执行压缩并导入。
  
  - 对于分区：以copy指定策略为准，即便某个partition上无ILM压缩策略，对于导入到这个分区上的数据也会执行压缩。
   

- copy批量导入压缩后的大小，和页面填充因子fillfactor保持一致。
- copy导入压缩会调用编码、压缩算法，会导致CPU算力消耗增加；并且由于数据流分为压缩和非压缩两部分，每个表/分区可能会增加10MB左右的内存使用。
 
对于跨页透明压缩（TURBO）：
- 功能及资源规格（medium压缩级别：默认compress unit = 16，encoder = none）：
  - 金融典型数据集整库压缩比约4:1，等权压缩比约5:1；物流典型数据集整库压缩比约6:1，等权压缩比约7:1。
  
  - 压缩解压需要使用内存资源，在开启线程池下，额外需要：最大并发会话数× 1MB的内存；
  
  - 压缩元数据管理需要增加内存资源，额外需要：share buffer大小的1/128的内存。
  
  - 双写区会增加实例级独立文件，文件大小上限2GB。
  
  - 备机需要放开JOB任务约束。
   
- 以下场景可能导致压缩表磁盘空间占用的变化：
  - 主从节点由于使用了不同的GUC参数turbo_compress_pattern_encoder（不同的模式编码器），可能造成主从节点的压缩表有不同的大小。
  
  - 出于性能考虑，pattern encoder仅在ILM任务压缩的场景下生效，其他压缩场景不生效，因此在开启了pattern encoder后，可能会随着同步压缩场景的触发产生一定存储空间的膨胀，可通过ILM压缩任务消除膨胀。
  
  - 压缩表执行逻辑扩容，由于pattern encoder仅在ILM任务压缩场景下应用，因此逻辑扩容后表数据会有小幅膨胀（膨胀率不超过pattern encoder的压缩率增益，通常为30%左右）。当前只能在扩容结束后，通过定时ILM压缩任务消除膨胀，且gsilmpolicy_seq值会出现跳变（压缩表扩容产生的中间对象会消耗sequence值）。
   
- 跨页压缩性能评估方法：
  ```
  大容量典型用户场景： 
  1、CPU : 2P，内存 ：1TB，磁盘类型 EVS (超高IO型4块组条带化） 或 SAS/SATA SSD （4块组RAID0），搭配NVMe缓存进行加速 
  2、SATA SSD读带宽500MB/s，SAS SSD读带宽1GB/s 
  3、用户数据压缩比5：1 
  4、medium压缩级别：默认compress unit = 16，encoder = none
  ```
  1. 跨页压缩/解压会增加IO资源消耗产生读写放大问题，单次读写IO资源消耗增大3\~4倍。
  
  2. 跨页压缩/解压会增加CPU算力消耗，以zstd-level1官方benchmark规格为例：压缩速率500MB/s，解压速率1660MB/s，那么在跨页压缩默认配置下，那么单页面解压读耗时增大的计算方法为：
     ```
     方法1：(compress unit数据大小/解压速率 + compress unit压缩后数据大小/磁盘读速率) / (单页面大小/磁盘读速率)
     ```
     下面进行举例说明：
     ```
     举例1：(1)SAS SSD读带宽1GB/s，用户数据压缩比5:1，可得单页面加载的总耗时会增加约13倍。磁盘性能较好，IO耗时接近CPU耗时，会导致CPU解压代价的整体占比变高，此时CPU算力会成为瓶颈(2)SATA SSD读带宽为500MB/s，用户数据压缩比为5：1，单页面加载耗时增加则约8倍。综上，磁盘性能越好，单页面加载的劣化越明显。
     ```
     备注：实际用户场景中，业务访问大多具有一定的局部性，不太会出现所有场景都需要冷加载这么极端的情况出现，因此，整体性能结果可参考TPCC冷温热模型的实际测试结果。
     
  
  3. 跨页压缩会导致涉及到MAINFORK压缩文件的访问均会由于解压及IO放大问题引入性能劣化，性能劣化评估方法为：
     ```
     方法2：压缩性能影响评估方法：读压缩页面产生的IO读放大及解压造成的额外耗时倍数N × 压缩页面的业务量占比X%
     ```
     
  
  4. 跨页压缩会导致主机recovery时从双写区恢复的时间增加，在开启backend刷脏的情况下，增加时间的度量方法为：
     ```
     方法3：(需要从双写区读取数据的总IO量 + 需要写回到磁盘的总IO量) / IO吞吐量，总IO量的计算方法为512K × 同一时刻写双写区的会话数量
     ```
     备注：在冷温热模型下，实际上并发会话刚好同时走到写双写区的概率是非常低的，预计对主机故障恢复的时间影响为毫秒级。
     
  
  5. 跨页压缩会导致主/备及日志回放阶段性能劣化、导致备机读性能劣化、导致增量build性能劣化、导致增量备份恢复性能劣化，增加时间的度量参考[3]。