Copilot commented on code in PR #3509: URL: https://github.com/apache/doris-website/pull/3509#discussion_r3015446308
########## i18n/zh-CN/docusaurus-plugin-content-docs/version-4.x/table-design/storage-format.md: ########## @@ -24,42 +24,58 @@ specific language governing permissions and limitations under the License. --> -Apache Doris 存储格式 V3 是在 Segment V2 格式基础上进行的重大演进。它通过元数据解耦与编码策略优化，专门针对大宽表、复杂数据类型（如 Variant）以及云原生存算分离场景提升性能。 +存储格式 V3 是 Segment V2 的继任者。核心变化：列元数据不再打包在 Segment Footer 中，而是存储到文件内的独立区域。这去掉了 V2 在列数达到几百甚至几千时遇到的元数据加载瓶颈。 ## 核心优化点 -### 外部列元数据 (External Column Meta) -* **优化背景**：在 Segment V2 中，所有列的元数据（`ColumnMetaPB`）都存储在 Segment 文件的 Footer 中。对于拥有数千列的大宽表或自动扩容的 Variant 场景，Footer 可能会膨胀到几 MB。 -* **优化思路**：V3 将 `ColumnMetaPB` 从 Footer 中剥离，转而存储在文件内的独立区域（External Column Meta Area）。 -* **收益**： - * **极速元数据加载**：显著减小 Segment Footer 体积，加快文件初次打开速度。 - * **按需加载**：元数据可以按需从独立区域加载，降低内存占用，提升对象存储（如 S3/OSS）上的冷启动查询性能。 +### 外部列元数据（External Column Meta） -### 数值类型 Plain 编码模式 (Integer Type Plain Encoding) -* **优化思路**：V3 默认将数值类型（如 `INT`, `BIGINT`）切换为 `PLAIN_ENCODING`（原始二进制存储），而非传统的 BitShuffle。 -* **收益**：配合 LZ4/ZSTD 压缩时，`PLAIN_ENCODING` 提供了更高的读取吞吐量和更低的 CPU 开销。在现代高速 IO 环境下，这种“解压换性能”的策略在扫描大体量数据时优势明显。 +V2 中，所有列的 `ColumnMetaPB` 都放在 Segment Footer 里。当表有几百甚至几千列时，Footer 可以膨胀到几 MB。打开一个 Segment 就要加载和反序列化全部元数据，即使查询只需读两个列。 Review Comment: Chinese grammar: “即使查询只需读两个列” is unidiomatic; “列” doesn’t take “个” here. Consider changing to “即使查询只需读两列” (or “只读两列数据”). ```suggestion V2 中，所有列的 `ColumnMetaPB` 都放在 Segment Footer 里。当表有几百甚至几千列时，Footer 可以膨胀到几 MB。打开一个 Segment 就要加载和反序列化全部元数据，即使查询只需读两列。 ``` ########## i18n/zh-CN/docusaurus-plugin-content-docs/current/table-design/storage-format.md: ########## @@ -24,42 +24,58 @@ specific language governing permissions and limitations under the License. --> -Apache Doris 存储格式 V3 是在 Segment V2 格式基础上进行的重大演进。它通过元数据解耦与编码策略优化，专门针对大宽表、复杂数据类型（如 Variant）以及云原生存算分离场景提升性能。 +存储格式 V3 是 Segment V2 的继任者。核心变化：列元数据不再打包在 Segment Footer 中，而是存储到文件内的独立区域。这去掉了 V2 在列数达到几百甚至几千时遇到的元数据加载瓶颈。 ## 核心优化点 -### 外部列元数据 (External Column Meta) -* **优化背景**：在 Segment V2 中，所有列的元数据（`ColumnMetaPB`）都存储在 Segment 文件的 Footer 中。对于拥有数千列的大宽表或自动扩容的 Variant 场景，Footer 可能会膨胀到几 MB。 -* **优化思路**：V3 将 `ColumnMetaPB` 从 Footer 中剥离，转而存储在文件内的独立区域（External Column Meta Area）。 -* **收益**： - * **极速元数据加载**：显著减小 Segment Footer 体积，加快文件初次打开速度。 - * **按需加载**：元数据可以按需从独立区域加载，降低内存占用，提升对象存储（如 S3/OSS）上的冷启动查询性能。 +### 外部列元数据（External Column Meta） -### 数值类型 Plain 编码模式 (Integer Type Plain Encoding) -* **优化思路**：V3 默认将数值类型（如 `INT`, `BIGINT`）切换为 `PLAIN_ENCODING`（原始二进制存储），而非传统的 BitShuffle。 -* **收益**：配合 LZ4/ZSTD 压缩时，`PLAIN_ENCODING` 提供了更高的读取吞吐量和更低的 CPU 开销。在现代高速 IO 环境下，这种“解压换性能”的策略在扫描大体量数据时优势明显。 +V2 中，所有列的 `ColumnMetaPB` 都放在 Segment Footer 里。当表有几百甚至几千列时，Footer 可以膨胀到几 MB。打开一个 Segment 就要加载和反序列化全部元数据，即使查询只需读两个列。 Review Comment: Chinese grammar: “即使查询只需读两个列” is unidiomatic; “列” doesn’t take “个” here. Consider changing to “即使查询只需读两列” (or “只读两列数据”). ```suggestion V2 中，所有列的 `ColumnMetaPB` 都放在 Segment Footer 里。当表有几百甚至几千列时，Footer 可以膨胀到几 MB。打开一个 Segment 就要加载和反序列化全部元数据，即使查询只需读两列。 ``` -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
