Commit 格式规范

Commit 分为“标题”和“内容”。原则上标题全部小写。内容首字母大写。

  1. 标题

    [<type>](<scope>) <subject> (#pr)

    • <type>

      本次提交的类型，限定在以下类型（全小写）

      • fix：bug修复
      • feature：新增功能
      • feature-wip：开发中的功能，比如某功能的部分代码。
      • improvement：原有功能的优化和改进
      • style：代码风格调整
      • typo：代码或文档勘误
      • refactor：代码重构（不涉及功能变动）
      • performance/optimize：性能优化
      • test：单元测试的添加或修复
      • chore：构建工具的修改
      • revert：回滚
      • deps：第三方依赖库的修改
      • community：社区相关的修改，如修改 Github Issue 模板等。

      几点说明：

      1. 如在一次提交中出现多种类型，需增加多个类型。
      2. 如代码重构带来了性能提升，可以同时添加 [refactor][optimize]
      3. 不得出现如上所列类型之外的其他类型。如有必要，需要将新增类型添加到这个文档中。

    • <scope>

      本次提交设计的模块范围。因为功能模块繁多，在此仅罗列部分，后续根据需求不断完善。

      • planner
      • meta
      • storage
      • stream-load
      • broker-load
      • routine-load
      • sync-job
      • export
      • executor
      • spark-connector
      • flink-connector
      • datax
      • log
      • cache
      • config
      • vectorization
      • docs

      几点说明：

      1. 尽量使用列表中已存在的选项。如需添加，请及时更新本文档。

    • <subject>

      标题需尽量清晰表明本次提交的主要内容。

  2. 内容

    commit message 需遵循以下格式：

    1. issue：#7777
    3. your message
    1. 如无 issue，可不填。issue 也可以出现在 message 里。
    2. 一行原则不超过100个字符。

  3. 示例

    1. [fix](executor) change DateTimeValue's memory layout to load (#7022)
    3. Change DateTimeValue memory's layout to old to fix compatibility problems.
    1. [feat](log) extend logger interface, support structured log output(#6600)
    3. Support structured logging.
    1. [fix][feat-opt](executor)(load)(config) fix some memory bugs (#6699)
    3. 1. Fix a memory leak in `collect_iterator.cpp` (Fix #6700)
    4. 2. Add a new BE config `max_segment_num_per_rowset` to limit the num of segment in new rowset.(Fix #6701)
    5. 3. Make the error msg of stream load more friendly.
    1. [feat-opt](load) Reduce the number of segments when loading a large volume data in one batch (#6947)
    3. ## Case
    5. In the load process, each tablet will have a memtable to save the incoming data,
    6. and if the data in a memtable is larger than 100MB, it will be flushed to disk
    7. as a `segment` file. And then a new memtable will be created to save the following data.
    9. Assume that this is a table with N buckets(tablets). So the max size of all memtables
    10. will be `N * 100MB`. If N is large, it will cost too much memory.
    12. So for memory limit purpose, when the size of all memtables reach a threshold(2GB as default),
    13. Doris will try to flush all current memtables to disk(even if their size are not reach 100MB).
    15. So you will see that the memtable will be flushed when it's size reach `2GB/N`, which maybe much
    16. smaller than 100MB, resulting in too many small segment files.
    18. ## Solution
    20. When decide to flush memtable to reduce memory consumption, NOT to flush all memtable,
    21. but to flush part of them.
    23. For example, there are 50 tablets(with 50 memtables). The memory limit is 1GB,
    24. so when each memtable reach 20MB, the total size reach 1GB, and flush will occur.
    26. If I only flush 25 of 50 memtables, then next time when the total size reach 1GB,
    27. there will be 25 memtables with size 10MB, and other 25 memtables with size 30MB.
    28. So I can flush those memtables with size 30MB, which is larger than 20MB.
    30. The main idea is to introduce some jitter during flush to ensure the small unevenness
    31. of each memtable, so as to ensure that flush will only be triggered when the memtable
    32. is large enough.
    34. In my test, loading a table with 48 buckets, mem limit 2G, in previous version,
    35. the average memtable size is 44MB, after modification, the average size is 82MB