凌晨定时任务major compaction疑问

[数据库技术爱好者]

【 使用环境 】测试环境
【 OB or 其他组件 】OceanBase
【 使用版本 】社区版4.4.2
【问题描述】

• 问题1：基线数据如果没有发生修改，这部分数据也需要重写吗？
• 问题2：如果在此期间，仍有频繁的数据写入和修改，会有影响数据写入吗？看文档是会有一个快照点，是不是新写入的数据，哪怕跟基线数据有交集，在本次合并任务中会被直接忽略吗？
• 问题3：社区版的oceanbase是渐进式合并还是全量合并？

[淇铭]

@论坛小助手

[论坛小助手]

回答您的关于OceanBase社区版4.4.2凌晨定时任务major compaction（合并）的问题

问题1：基线数据如果没有发生修改，这部分数据也需要重写吗？

根据文档片段8中的信息，存储架构概述 → 存储引擎的功能 → 合并，当执行合并操作时，会基于一个统一的快照点进行处理。对于未被更改的数据块，它们虽然会被纳入到此次合并过程中，但并不意味着这些没有变化的基线数据必须完全重新写入磁盘。相反，在实际的物理层面上，这类未改变的数据更可能是通过某种方式复用已有的文件内容或索引信息，从而避免不必要的IO开销。不过，请注意具体实现细节可能会因版本不同有所差异。

问题2：如果在此期间，仍有频繁的数据写入和修改，会有影响数据写入吗？看文档是会有一个快照点，是不是新写入的数据，哪怕跟基线数据有交集，在本次合并任务中会被直接忽略吗？

• 对于正在进行的合并过程来说，确实存在一个特定时间点的全局快照用于确定参与此次合并的数据范围。任何在该快照点之后发生的写入或更新动作涉及的数据都不会影响当前正在进行的合并操作；也就是说，新增的数据记录以及对现有数据做的变更将不会反映在当前轮次的合并结果中，而是等待下一次的合并来处理。
• 在OceanBase的设计理念里，DML操作是纯粹针对内存中MemTable的操作，因此即使后台正在进行合并作业，这也不会直接影响到前台业务写入性能。只有当内存中的增量数据累积到一定程度需要刷新到磁盘上形成新的SSTable时，才有可能暂时性地对系统产生一定压力。但总体而言，这种设计旨在最小化对在线事务处理的影响。

问题3：社区版的OceanBase是渐进式合并还是全量合并？

• 根据合并管理概述 → 合并分类提供的说明，默认情况下，OceanBase数据库采用的是增量合并策略。这意味着系统主要关注那些已经被修改过的数据宏块来进行合并操作，而非每次都将所有静态数据重新读取一遍再与动态部分融合。
• 渐进式合并作为一种特殊的全量合并形式也被提及，它指的是分多轮次逐步完成整个集合的数据重写工作。然而，从给定的信息来看，并没有明确指出社区版4.4.2默认启用了渐进式合并特性。考虑到文档提到“增量合并极大地减少了合并的工作量，是OceanBase数据库目前默认的合并算法”，我们可以推测，在无特别配置的情况下，您所使用的版本大概率是以增量合为主导模式工作的。

希望上述解答能够帮助到您！如果有更多疑问或其他方面需要了解的内容，请随时告知。

详情请参考:

1. 列存 FAQ
2. OceanBase 数据库性能的影响因素
3. 自适应合并
4. 合并管理概述
5. 集群管理 FAQ
6. 存储架构概述
7. 使用 LOAD DATA 语句导入数据
8. 刷新物化视图

[AntTech_MO4OZE]

请看论坛小助手

[数据库技术爱好者]

很详细

[wkk2025]

666

[数据库技术爱好者]

在性能压力背景下，在凌晨2:00 major compaction执行时，SQL性能抖动很厉害。
存量业务数据特征：

• 39张表，其中大部分表是小表，小表统一使用的是纯行存，有5张大表，用的纯列存，大表的merge_engine统一使用的是delete_insert
• 大表业务特征：主要是插入，少量更新，更新的数据覆盖的时间范围是近两天，存量数据规模为千万级别

业务压力特征：

• 增量数据：会修改近两天的数据，这意味着昨天的基线数据数据会被破坏
• 查询业务：在近一个月的数据范围里做点查

问题：

• 查询性能抖动剧烈，平均几百毫秒增大到几秒
• 写入SQL偶尔出现写入超时

尝试做的一些优化：
ALTER SYSTEM SET default_progressive_merge_num = 200;
ALTER SYSTEM SET compaction_schedule_tablet_batch_cnt = 100000;
ALTER SYSTEM SET compaction_dag_cnt_limit = 50000;
ALTER SYSTEM SET compaction_low_thread_score = 40;
ALTER SYSTEM SET compaction_mid_thread_score = 20;
ALTER SYSTEM SET compaction_high_thread_score = 20;

有什么更好的优化建议吗？ @论坛小助手

[论坛小助手]

根据你提供的信息，业务数据量大且存在混合存储模式（行存与列存），同时还有大量的插入操作和少量的更新操作。针对凌晨2:00执行major compaction期间SQL性能抖动的问题，以及在近一个月的数据范围内做点查时遇到的查询性能下降问题，建议采取以下措施来进一步优化性能：\n1. 调整合并策略：由于你的场景中主要表是列存并且使用delete_insert作为merge_engine，考虑是否可以利用分层转储(Layered Dump)或渐进式合并(Progressive Merge)来减轻一次性全量合并对系统造成的冲击。通过适当增大default_progressive_merge_num值已经是一个好的尝试，但具体数值还需要结合实际负载测试调整。">", \

详情请参考:

1. 存储架构概述
2. default_progressive_merge_num

[数据库技术爱好者]

在此期间，如果增量数据涨得太快，memtable冻结转储到sstable跟不上速度，内存来不及释放，会有这种可能导致增量数据无法写入吗？
@论坛小助手

[论坛小助手]

增量数据写入速度过快导致MemTable冻结转储跟不上

根据文档中的信息，确实存在由于增量数据增长速度过快而导致MemTable冻结转储到SSTable跟不上速度，从而内存来不及释放的情况。这种情况下，可能会导致增量数据无法写入。具体来说：

1. MemTable写满：

   • 当MemTable的大小超过一定阈值时，需要将其冻结并转存到SSTable中以释放内存。如果这个过程跟不上数据写入的速度，就会导致MemTable写满。
   • 如果MemTable写满了，新的数据将无法继续写入，直到MemTable被成功转储到SSTable。

2. 写入限速机制：

   • 为了防止这种情况的发生，OceanBase提供了写入限速机制。可以通过设置writing_throttling_trigger_percentage和writing_throttling_maximum_duration来控制写入速度。
   • writing_throttling_trigger_percentage：当MemStore已使用的内存达到该百分比时，触发写入限速。
   • writing_throttling_maximum_duration：触发写入限速后，剩余MemStore内存分配完所需的时间。

3. 配置示例：

   • 您可以设置以下参数来开启写入限速：

     obclient> ALTER SYSTEM SET writing_throttling_trigger_percentage = 80;
     Query OK, 0 rows affected
     
     obclient> ALTER SYSTEM SET writing_throttling_maximum_duration = '2h';
     Query OK, 0 rows affected
     

4. 监控和调整：

   • 您可以通过系统视图V$OB_MEMSTORE来监控MemTable的状态，例如当前使用的总内存大小（MEMSTORE_USED）、内存大小限制（MEMSTORE_LIMIT）等。
   • 如果发现MemTable经常接近写满，可能需要进一步调整相关参数或增加硬件资源。

综上所述

• 是的，如果增量数据增长速度过快，MemTable冻结转储到SSTable的速度跟不上，确实会导致内存来不及释放，从而可能导致增量数据无法写入。
• 建议措施：
  1. 开启写入限速机制，并合理设置writing_throttling_trigger_percentage和writing_throttling_maximum_duration。
  2. 监控MemTable的状态，及时调整参数。
  3. 如果频繁出现MemTable写满的情况，考虑增加内存资源或优化数据写入模式。

希望这些信息能帮助您解决问题。如果有更多问题，请随时提问！

详情请参考:

1. 租户内存写满
2. 节点数据盘空间满
3. 转储
4. 在您开始前
5. 转储管理概述
6. 转储和合并概述
7. writing_throttling_maximum_duration
8. V$OB_MEMSTORE

[longzh85]

了解了学习了多谢提问

[数据库技术爱好者]

在major compaction期间，SELECT正在合并的数据，会有问题吗？ 原理是什么？

@论坛小助手

[论坛小助手]

在major compaction期间，执行SELECT查询正在合并的数据通常不会遇到问题。OceanBase的设计确保了在合并过程中数据的一致性和可用性。以下是详细的原理说明：

1. 快照隔离

• 快照点：在开始major compaction时，系统会基于一个统一的快照点来确定参与合并的数据范围。这个快照点确保了合并操作不会影响到在此之后新写入的数据。
• 多版本并发控制 (MVCC)：OceanBase使用MVCC机制来管理数据版本。这意味着在合并过程中，旧版本的数据仍然可以被读取，而新的写入操作则会被记录在新的版本中。因此，即使某些数据正在进行合并，读取操作仍然可以通过MVCC机制访问到正确的数据版本。

2. 数据一致性

• 读取不受影响：由于MVCC的存在，读取操作不会受到合并过程的影响。即使某个数据分片正在进行合并，查询仍然可以访问到该分片的最新可见版本。
• 合并后的数据可见性：当合并完成后，新的SSTable将包含最新的数据版本，并且这些数据会逐渐替代旧版本的数据。这一过程对查询是透明的，用户无需关心底层的具体实现。

3. 性能考虑

• 查询性能：虽然合并操作本身可能会占用一定的系统资源，但OceanBase的设计旨在最小化对查询性能的影响。合并操作通常会在后台进行，尽量减少对前台业务的影响。
• 资源调度：系统会根据当前的负载情况动态调整合并任务的优先级和资源分配，以确保前台业务的正常运行。

4. 特殊情况

• 长查询：如果查询涉及大量数据并且执行时间较长，可能会受到合并操作的影响。这种情况下，建议优化查询语句或增加系统的资源（如内存、CPU）。
• 合并策略：如果您发现合并操作对查询性能有显著影响，可以考虑调整合并策略，例如渐进式合并（Progressive Merge），以减少单次合并操作对系统的影响。

示例

假设有一个表 orders，正在进行major compaction，您执行以下查询：

SELECT * FROM orders WHERE order_id = 12345;

在这个查询中，无论合并操作是否正在进行，系统都会通过MVCC机制找到并返回order_id为12345的最新可见版本数据。

总结

• 在major compaction期间，执行SELECT查询通常是安全的，不会因为合并操作而返回错误或不一致的数据。
• OceanBase通过快照隔离和MVCC机制确保了数据的一致性和读取操作的连续性。
• 如果遇到性能问题，可以考虑优化查询、调整合并策略或增加系统资源。

希望这些信息能帮助您更好地理解在major compaction期间执行SELECT查询的行为。如果有更多问题，请随时提问！

具体信息可参考以下文档:

1. 合并管理概述
2. V$OB_COMPACTION_DIAGNOSE_INFO
3. V$OB_COMPACTION_SUGGESTIONS
4. OceanBase 数据库性能的影响因素
5. GV$OB_COMPACTION_DIAGNOSE_INFO

[数据库技术爱好者]

如果select的数据既有增量数据又有基线数据，oceanbase会怎么处理？
@论坛小助手

[论坛小助手]

在OceanBase中，如果SELECT查询的数据同时涉及增量数据（MemTable）和基线数据（SSTable），系统会通过以下方式处理：

1. 数据合并

OceanBase的读取操作需要将增量数据和基线数据进行合并，以返回最新的数据版本。具体步骤如下：

• 读取MemTable：首先，系统会从MemTable中读取最新的增量数据。
• 读取SSTable：然后，系统会从SSTable中读取基线数据。
• 合并数据：最后，系统会将这两部分数据进行合并，生成最终的结果集。

2. 多版本并发控制 (MVCC)

OceanBase使用多版本并发控制（MVCC）机制来管理数据版本。这意味着每个数据行都有一个版本号（通常是事务ID），系统会根据事务的可见性规则来决定哪些版本的数据是可见的。

• 事务可见性：当执行SELECT查询时，系统会根据当前事务的快照点（即事务开始时的时间点）来决定哪些数据版本是可见的。
• 合并最新版本：系统会将MemTable中的最新版本数据与SSTable中的基线数据进行合并，确保返回的数据是最新的且符合事务可见性的要求。

3. 性能优化

为了提高查询性能，OceanBase还采用了一些优化措施：

• Block Cache 和 Row Cache：OceanBase在内存中实现了Block Cache和Row Cache，以减少对基线数据的随机读取。这可以显著提高读取性能。
• 并行处理：OceanBase支持并行处理技术，可以将查询任务分成多个子任务并行执行，从而提高查询速度。

示例

假设有一个表 orders，其中既有增量数据也有基线数据。执行以下查询：

SELECT * FROM orders WHERE order_id = 12345;

在这个查询中，系统会执行以下步骤：

1. 从MemTable中读取：检查MemTable中是否有order_id为12345的最新记录。
2. 从SSTable中读取：如果MemTable中没有找到该记录，系统会从SSTable中读取基线数据。
3. 合并数据：将从MemTable和SSTable中读取到的数据进行合并，生成最终的结果集。

注意事项

• 查询性能：虽然OceanBase设计了多种优化措施，但如果查询涉及大量数据或复杂的合并操作，可能会对性能产生一定影响。建议优化查询语句或增加系统资源。
• 监控和调优：可以通过OceanBase的监控工具和系统视图来监控查询性能，并根据实际情况进行调优。

总结

在OceanBase中，SELECT查询同时涉及增量数据和基线数据时，系统会通过读取MemTable和SSTable的数据并进行合并，确保返回最新的数据版本。MVCC机制和各种缓存技术保证了数据的一致性和查询性能。

希望这些信息能帮助您更好地理解OceanBase在处理SELECT查询时的行为。如果有更多问题，请随时提问！

详情请参考:

1. 体验并行导入和数据压缩
2. 集群管理 FAQ
3. 备份架构
4. 存储架构概述
5. 使用 LOAD DATA 语句导入数据
6. 添加节点
7. 列存 FAQ
8. OceanBase 数据库性能的影响因素
9. OceanBase 数据库在 MySQL 模式租户下的扩展功能
10. 存储层估行

[数据库技术爱好者]

我现在遇到了一个问题，major compaction期间有大量数据写入，有insert和update，现在发现更新的业务事务非常容易失败，在major compaction之后，写入业务恢复正常，这有可能是什么原因？

@论坛小助手

[论坛小助手]

在major compaction期间，如果发现更新的业务事务非常容易失败，并且在compaction之后写入业务恢复正常，这可能是由以下几个原因导致的：

1. 内存资源不足

• MemTable写满：在major compaction期间，如果MemTable的增长速度超过了其转储到SSTable的速度，MemTable可能会写满。当MemTable写满时，新的写入操作将被阻塞，直到MemTable被成功转储。
• 解决方案：
  • 增加内存资源，特别是用于MemTable的内存。
  • 调整MemTable的大小和触发转储的阈值，例如通过设置memstore_limit_percentage来控制MemTable的大小。
  • 启用写入限速机制，通过设置writing_throttling_trigger_percentage和writing_throttling_maximum_duration来防止MemTable写满。

2. CPU和I/O资源争用

• 资源竞争：major compaction是一个资源密集型操作，会占用大量的CPU和I/O资源。如果系统资源有限，可能会导致写入操作因为资源不足而失败。
• 解决方案：
  • 增加系统的CPU和I/O资源。
  • 调整compaction的优先级和资源分配，例如通过设置compaction_dag_cnt_limit、compaction_low_thread_score、compaction_mid_thread_score和compaction_high_thread_score来控制compaction的资源使用。

3. 锁竞争

• 锁冲突：在major compaction期间，可能会涉及到对数据的锁定操作。如果更新操作频繁，可能会导致锁冲突，从而导致事务失败。
• 解决方案：
  • 优化事务隔离级别，尽量减少锁的持有时间。
  • 优化写入操作，减少单个事务的持续时间，避免长时间持有锁。

4. 系统负载过高

• 系统负载：在major compaction期间，系统负载可能会显著增加，导致整体性能下降。如果系统负载过高，可能会导致写入操作超时或失败。
• 解决方案：
  • 监控系统负载，确保系统有足够的资源处理写入操作。
  • 调整compaction的时间窗口，避免在高负载时段进行compaction。

5. 参数配置不当

• 参数配置：某些参数配置可能不适合当前的业务场景，导致在compaction期间出现性能问题。
• 解决方案：
  • 重新评估并调整相关参数，例如default_progressive_merge_num、compaction_schedule_tablet_batch_cnt等。
  • 根据实际业务需求和系统资源情况，调整这些参数以优化性能。

具体步骤

1. 监控MemTable状态：

   • 使用系统视图V$OB_MEMSTORE监控MemTable的状态，检查MEMSTORE_USED和MEMSTORE_LIMIT。
   • 如果发现MemTable经常接近写满，考虑增加内存资源或调整相关参数。

2. 调整写入限速机制：

   • 设置writing_throttling_trigger_percentage和writing_throttling_maximum_duration来控制写入速度。
   • 例如：

     ALTER SYSTEM SET writing_throttling_trigger_percentage = 80;
     ALTER SYSTEM SET writing_throttling_maximum_duration = '2h';
     

3. 调整compaction参数：

   • 重新评估并调整compaction相关的参数，例如compaction_dag_cnt_limit、compaction_low_thread_score、compaction_mid_thread_score和compaction_high_thread_score。
   • 例如：

     ALTER SYSTEM SET compaction_dag_cnt_limit = 50000;
     ALTER SYSTEM SET compaction_low_thread_score = 40;
     ALTER SYSTEM SET compaction_mid_thread_score = 20;
     ALTER SYSTEM SET compaction_high_thread_score = 20;
     

4. 优化事务隔离级别和锁管理：

   • 尽量减少事务的持续时间，避免长时间持有锁。
   • 优化SQL语句，减少锁的竞争。

5. 监控系统负载：

   • 使用OceanBase的监控工具和系统视图监控系统负载，确保系统有足够的资源处理写入操作。
   • 考虑在低负载时段进行compaction，避免在高负载时段进行。

希望这些信息能帮助您解决在major compaction期间写入操作失败的问题。如果有更多问题，请随时提问！

详情请参考:

1. 合并管理概述
2. V$OB_COMPACTION_DIAGNOSE_INFO
3. V$OB_COMPACTION_SUGGESTIONS
4. GV$OB_COMPACTION_DIAGNOSE_INFO

[Sunshining]

学习了，楼主问的问题很细呀

[数据库技术爱好者]

major compactoin期间锁竞争可以详细讲解一下吗？ @论坛小助手

[论坛小助手]

在OceanBase中，major compaction期间可能会出现锁竞争的情况，这会对更新操作（如INSERT和UPDATE）造成影响。以下是详细的讲解：

1. 锁的基本概念

在数据库系统中，锁是一种用于控制并发访问的机制。通过使用锁，可以确保多个事务在同时访问同一数据时不会发生冲突，从而保证数据的一致性和完整性。

2. OceanBase中的锁机制

OceanBase使用多版本并发控制（MVCC）来管理数据版本，但仍然需要在某些情况下使用锁来确保事务的隔离性和一致性。主要的锁类型包括：

• 行锁：对单个数据行进行锁定。
• 表锁：对整个表进行锁定。
• 意向锁：表示事务有意向对某个范围内的数据加锁。

3. major compaction期间的锁竞争

3.1 数据合并过程

在major compaction期间，系统会将MemTable中的增量数据与SSTable中的基线数据进行合并。这个过程中，可能会涉及到对数据的锁定操作，以确保数据的一致性。

3.2 锁竞争的原因

• 数据分片锁定：在合并过程中，系统可能会对数据分片进行锁定，以确保合并操作的原子性和一致性。如果此时有其他事务试图修改这些分片中的数据，就会发生锁竞争。
• 事务隔离级别：不同的事务隔离级别会导致不同程度的锁竞争。例如，在可重复读（Repeatable Read）隔离级别下，事务会持有更长时间的锁，从而增加锁竞争的可能性。
• 写入密集型操作：在compaction期间，如果有大量的写入操作（如INSERT和UPDATE），这些操作可能会频繁地请求锁，从而导致锁竞争。

4. 具体影响

在major compaction期间，由于系统资源被大量占用，锁竞争可能会导致以下问题：

• 事务超时：如果事务在等待锁的过程中超时，事务将会失败。
• 性能下降：锁竞争会增加事务的等待时间，从而降低整体性能。
• 死锁：如果多个事务互相等待对方释放锁，可能会导致死锁，进一步影响系统的可用性。

5. 解决方法

5.1 优化事务隔离级别

• 降低隔离级别：如果业务允许，可以考虑降低事务隔离级别，例如从可重复读（Repeatable Read）降低到读已提交（Read Committed）。这样可以减少锁的持有时间，减轻锁竞争。
• 使用乐观锁：对于一些读多写少的场景，可以考虑使用乐观锁机制，减少显式锁的使用。

5.2 优化写入操作

• 批量写入：尽量减少单个事务的写入量，避免长时间持有锁。
• 减少事务持续时间：优化SQL语句，减少事务的持续时间，尽快释放锁。

5.3 调整compaction策略

• 渐进式合并：使用渐进式合并（Progressive Merge）策略，逐步完成合并操作，减少一次性全量合并对系统的影响。
• 调整compaction时间窗口：避免在高负载时段进行compaction，选择在低负载时段进行。

5.4 监控和调优

• 监控锁状态：使用OceanBase的监控工具和系统视图（如V$OB_LOCKS）监控锁的状态，及时发现并解决锁竞争问题。
• 调整系统资源：增加系统的CPU、内存和I/O资源，提高系统的处理能力。

示例

假设有一个表 orders，在major compaction期间，系统可能会对部分数据分片进行锁定。如果此时有多个事务尝试更新这些分片中的数据，可能会发生锁竞争。

-- 事务A
BEGIN;
UPDATE orders SET status = 'completed' WHERE order_id = 12345;
COMMIT;

-- 事务B
BEGIN;
UPDATE orders SET status = 'shipped' WHERE order_id = 12345;
COMMIT;

如果事务A在等待锁的过程中超时，事务A将会失败。为了避免这种情况，可以采取上述优化措施。

总结

在major compaction期间，锁竞争是导致更新操作失败的一个常见原因。通过优化事务隔离级别、减少事务持续时间、调整compaction策略以及增加系统资源，可以有效缓解锁竞争问题。希望这些信息能帮助您更好地理解和解决这个问题。如果有更多问题，请随时提问！