docs: publish v0.11.2 (#1427)

.github/scripts/check-front-matter.js

@@ -7,7 +7,8 @@ const github = require('@actions/github');
 // Add the special files here, for example, the template files
 const exceptionFiles = [
   'docs/user-guide/ingest-data/for-iot/grpc-sdks/template.md',
-  'i18n/zh/docusaurus-plugin-content-docs/current/user-guide/ingest-data/for-iot/grpc-sdks/template.md'
+  'i18n/zh/docusaurus-plugin-content-docs/current/user-guide/ingest-data/for-iot/grpc-sdks/template.md',
+  'i18n/zh/docusaurus-plugin-content-docs/version-0.11/user-guide/ingest-data/for-iot/grpc-sdks/template.md'
 ];
 
 // This function checks if a markdown file contains the required front matter.

i18n/zh/docusaurus-plugin-content-docs/version-0.11/greptimecloud/integrations/kafka.md

@@ -60,3 +60,8 @@ username = "<username>"
 password = "<password>"
 tls = {}
 ```
+
+## 参考文档
+
+请参考[通过 Kafka 写入数据](https://docs.greptime.cn/nightly/user-guide/ingest-data/for-observerbility/kafka)获取数据写入过程的详细信息。
+

i18n/zh/docusaurus-plugin-content-docs/version-0.11/reference/sql/alter.md

@@ -120,7 +120,7 @@ ALTER TABLE monitor MODIFY COLUMN load_15 STRING;
 `ALTER TABLE` 语句也可以用来更改表的选项。
 当前支持修改以下表选项：
 - `ttl`: 表数据的保留时间。
-- `compaction.twcs.time_window`: TWCS compaction 策略的时间窗口。
+- `compaction.twcs.time_window`: TWCS compaction 策略的时间窗口，其值是一个[时间范围字符段](/reference/time-durations.md)。
 - `compaction.twcs.max_output_file_size`: TWCS compaction 策略的最大允许输出文件大小。
 - `compaction.twcs.max_active_window_runs`: TWCS compaction 策略的活跃窗口中最多允许的有序组数量。
 - `compaction.twcs.max_inactive_window_runs`: TWCS compaction 策略的非活跃窗口中最多允许的有序组数量。

i18n/zh/docusaurus-plugin-content-docs/version-0.11/reference/sql/create.md

@@ -128,17 +128,7 @@ CREATE TABLE IF NOT EXISTS temperatures(
 ```
 `ttl` 值是一个字符串，支持以下类型的值：
 
-- 一个时间范围字符串，如 `1hour 12min 5s`，时间范围对象是时间段的连接。每个时间段由一个整数和一个后缀组成。支持的后缀有：
-    - `nsec`, `ns` – 纳秒（nanoseconds）
-    - `usec`, `us` – 微秒（microseconds）
-    - `msec`, `ms` – 毫秒（milliseconds）
-    - `seconds`, `second`, `sec`, `s` - 秒
-    - `minutes`, `minute`, `min`, `m` - 分钟
-    - `hours`, `hour`, `hr`, `h` - 小时
-    - `days`, `day`, `d` - 天
-    - `weeks`, `week`, `w` - 周
-    - `months`, `month`, `M` – 月，定义为 30.44 天
-    - `years`, `year`, `y` – 年，定义为 365.25 天
+- [时间范围字符串](/reference/time-durations.md)，如 `1hour 12min 5s`。
 - `forever`, `NULL`, `0s` （或任何长度为 0 的时间范围，如 `0d`）或空字符串 `''`，表示数据永远不会被删除。
 - `instant`, 注意数据库的 TTL 不能设置为 `instant`。`instant` 表示数据在插入时立即删除，如果你想将输入发送到流任务而不保存它，可以使用 `instant`，请参阅[流管理文档](/user-guide/flow-computation/manage-flow.md#manage-flows)了解更多细节。
 - 未设置，可以使用 `ALTER TABLE <table-name> UNSET 'ttl'` 来取消表的 `ttl` 设置，这样表将继承数据库的 `ttl` 策略（如果有的话）。

i18n/zh/docusaurus-plugin-content-docs/version-0.11/reference/time-durations.md

@@ -0,0 +1,46 @@
+---
+keywords: [时间范围, 时间跨度, 时间单位]
+description: 了解 GreptimeDB 中时间范围对象的表示方法，包括支持的时间单位和示例。
+---
+
+# 时间范围对象
+
+GreptimeDB 使用时间范围对象来表示各种上下文中的时间跨度，
+包括 SQL 查询、配置文件和 API 请求。
+时间持续时间表示为由连接的时间跨度组成的字符串，
+每个时间跨度由一个十进制数字序列和一个单位后缀表示。
+这些后缀不区分大小写，并且支持单数和复数形式。例如，`1hour 12min 5s`。
+
+每个时间跨度由一个整数和一个后缀组成。支持的后缀有：
+
+- `nsec`, `ns`: 纳秒
+- `usec`, `us`: 微秒
+- `msec`, `ms`: 毫秒
+- `seconds`, `second`, `sec`, `s`: 秒
+- `minutes`, `minute`, `min`, `m`: 分钟
+- `hours`, `hour`, `hr`, `h`: 小时
+- `days`, `day`, `d`: 天
+- `weeks`, `week`, `w`: 周
+- `months`, `month`, `M`: 定义为 30.44 天
+- `years`, `year`, `y`: 定义为 365.25 天
+
+在十进制整数后附加上述单位之一，表示等值的秒数。
+例如：
+
+- `1s`: 等效于 1 秒
+- `2m`: 等效于 120 秒
+- `1ms`: 等效于 0.001 秒
+- `2h`: 等效于 7200 秒
+
+以下写法无效：
+
+- `0xABm`: 不支持十六进制数字
+- `1.5h`: 不支持浮点数
+- `+Infd`: 不支持 `±Inf` 或 `NaN` 值
+
+以下是一些有效的时间范围示例：
+
+- `1h`: 一小时
+- `1h30m`, `1h 30m`: 一小时三十分钟
+- `1h30m10s`, `1h 30m 10s`: 一小时三十分钟十秒
+

i18n/zh/docusaurus-plugin-content-docs/version-0.11/user-guide/administration/performance-tuning-tips.md

@@ -46,7 +46,10 @@ region = "your-region"
 cache_capacity = "10G"
 ```
 
-写入缓存起到 write-through 缓存的作用，在将文件上传到对象存储之前，会先将它们存储在本地磁盘上。这可以减少第一次查询的延迟。以下示例展示了如何启用写入缓存。
+写入缓存起到 write-through 缓存的作用，在将文件上传到对象存储之前，会先将它们存储在本地磁盘上。这可以减少第一次查询的延迟。
+
+
+以下示例展示了在 `v0.12` 版本之前如何启用写入缓存。
 - `enable_experimental_write_cache` 开关可用来启用写入缓存。从 `v0.11` 版本开始，当配置对象存储服务的时候，该值将默认设置为 `true`，即启用。
 - `experimental_write_cache_size` 用来设置缓存的容量。从 0.11 版本开始，默认初始值为 `5GiB`。
 - `experimental_write_cache_path` 用来设置存储缓存文件的路径。默认情况下它位于数据主目录下。
@@ -70,6 +73,29 @@ experimental_write_cache_ttl = "8h"
 
 以下是一个例子：
 
+```toml
+[[region_engine]]
+[region_engine.mito]
+# 写入缓存的缓存大小。此缓存的 `type` 标签值为 `file`。
+write_cache_size = "10G"
+# SST 元数据的缓存大小。此缓存的 `type` 标签值为 `sst_meta`。
+sst_meta_cache_size = "128MB"
+# 向量和箭头数组的缓存大小。此缓存的 `type` 标签值为 `vector`。
+vector_cache_size = "512MB"
+# SST 行组页面的缓存大小。此缓存的 `type` 标签值为 `page`。
+page_cache_size = "512MB"
+# 时间序列查询结果（例如 `last_value()`）的缓存大小。此缓存的 `type` 标签值为 `selector_result`。
+selector_result_cache_size = "512MB"
+
+[region_engine.mito.index]
+## 索引暂存目录的最大容量。
+staging_size = "10GB"
+```
+
+
+
+对于 `v0.12` 之前的版本
+
 ```toml
 [[region_engine]]
 [region_engine.mito]
@@ -92,7 +118,7 @@ staging_size = "10GB"
 ```
 
 一些建议：
-- 至少将 `experimental_write_cache_size` 设置为磁盘空间的 1/10
+- 至少将写入缓存设置为磁盘空间的 1/10
 - 如果数据库内存使用率低于 20%，则可以至少将 `page_cache_size` 设置为总内存大小的 1/4
 - 如果缓存命中率低于 50%，则可以将缓存大小翻倍
 - 如果使用全文索引，至少将 `staging_size` 设置为磁盘空间的 1/10

i18n/zh/docusaurus-plugin-content-docs/version-0.11/user-guide/concepts/key-concepts.md

@@ -39,7 +39,7 @@ GreptimeDB 中的数据是强类型的，当创建表时，Auto-schema 功能提
 ## 索引
 
 索引是一种性能调优方法，可以加快数据的更快地检索速度。
-GreptimeDB 使用[倒排索引](/contributor-guide/datanode/data-persistence-indexing.md#倒排索引)来加速查询。
+GreptimeDB 提供多种类型的[索引](/user-guide/manage-data/data-index.md)来加速查询。
 
 ## View
 

i18n/zh/docusaurus-plugin-content-docs/version-0.11/user-guide/concepts/why-greptimedb.md

@@ -111,116 +111,3 @@ GreptimeDB 提供了一种称为时序表的新数据模型（见下图），以
 然而，我们对 schema 的定义不是强制性的，而是更倾向于 MongoDB 等数据库的无 schema 方法。
 表将在数据写入时动态自动创建，并自动添加新出现的列（Tag 和 Field）。
 
----
-keywords: [时序数据库, 云原生, 分布式, 高性能, 用户友好, 存算分离, PromQL, SQL, Python]
-description: 介绍 GreptimeDB 的特点、设计原则和优势，包括统一指标、日志和事件，云原生设计，高性能和用户友好等。
----
-
-# 为什么选择 GreptimeDB
-
-GreptimeDB 是一个云原生、分布式和开源的时序数据库，旨在处理、存储和分析大量的指标、日志和事件数据（计划中还包括 Trace）。
-它在处理涉及时序和实时分析的混合处理工作负载方面非常高效，同时为开发者提供了极佳的体验。
-
-可以阅读博客文章《[This Time, for Real](https://greptime.com/blogs/2022-11-15-this-time-for-real)》和《[Unifying Logs and Metrics](https://greptime.com/blogs/2024-06-25-logs-and-metrics)》了解我们开发 GreptimeDB 的动机。
-在这些文章中，我们深入探讨了 Greptime 高性能背后的原因以及一些突出的功能。
-
-## 统一的指标、日志和事件
-
-通过[时序表](./data-model.md)的模型设计、对 SQL 的原生支持以及存算分离架构带来的混合工作负载，
-GreptimeDB 可以同时处理指标、日志和事件，
-增强不同时间序列数据之间的关联分析，
-并简化架构、部署成本和 API。
-
-阅读 [SQL 示例](/user-guide/overview.md#sql-query-example) 了解详细信息。
-
-## 可用性、可扩展性和弹性
-
-从第一天起，GreptimeDB 就按照云原生数据库的原则设计，这意味着它能够充分利用云的优势。其一些好处包括：
-
-1. 高可用的按需计算资源，目标是实现 99.999% 的可用性和正常运行时间，即每年大约只有五分钟十五秒的停机时间。
-2. 弹性和可扩展性，允许开发者根据使用情况轻松扩展或缩减、添加或移动资源。
-3. 高可靠性和容错性以防止数据丢失。系统的目标是实现 99.9999% 的可用性率。
-
-这些功能共同确保 GreptimeDB 始终提供最佳的性能。
-下面是关于如何实现这些功能的额外技术解释。
-
-### 可弹性扩展的资源隔离
-
-![存储/计算分离，计算/计算分离](/storage-compute-disaggregation-compute-compute-separation.png)
-
-存储和计算资源是分离的，允许每个资源独立扩展、消耗和定价。
-这不仅大大提高了计算资源的利用率，还适配了“按需付费”的定价模式，避免了资源未充分利用的浪费。
-
-除了存储和计算隔离，不同的计算资源也被隔离，避免了因数据写入、实时查询以及数据压缩或降采样等任务产生的资源竞争，
-从而实现高效率的大规模实时分析。
-
-数据可以在多个应用程序之间共享而无需争用同一资源池，
-这不仅大大提高了效率，
-还可以根据需求提供无限的可扩展性。
-
-### 灵活的架构支持多种部署策略
-
-![GreptimeDB 的架构](/architecture-2.png)
-
-通过灵活的架构设计原则，不同的模块和组件可以通过模块化和分层设计独立切换、组合或分离。
-例如，我们可以将 Frontend、Datanode 和 Metasrc 模块合并为一个独立的二进制文件，也可以为每个表独立启用或禁用 WAL。
-
-灵活的架构允许 GreptimeDB 满足从边缘到云的各种场景中的部署和使用需求，同时仍然使用同一套 API 和控制面板。
-通过良好抽象的分层和封装隔离，GreptimeDB 的部署形式支持从嵌入式、独立、传统集群到云原生的各种环境。
-
-## 优异的成本效益
-
-GreptimeDB 利用流行的对象存储解决方案来存储大量的时序数据，例如 AWS S3 和 Azure Blob Storage，允许开发者只为使用的存储资源付费。
-
-GreptimeDB 使用自适应压缩算法，根据数据的类型和基数来减少数据量，以满足时间和空间复杂性约束。
-例如，对于字符串数据类型，当块的基数超过某个阈值时，GreptimeDB 使用字典压缩；
-对于浮点数，GreptimeDB 采用 Chimp 算法，该算法通过分析实际的时间序列数据集来增强 Gorilla（Facebook 的内存 TSDB）的算法，
-并提供比传统算法（如 zstd、Snappy 等）更高的压缩率和空间效率。
-
-## 高性能
-
-在性能优化方面，GreptimeDB 利用 LSM 树、数据分片和基于 Quorum 的 WAL 设计等不同技术来处理大量的时序数据写入时的工作负载。
-
-GreptimeDB 的查询引擎强大且快速，得益于矢量化执行和分布式并行处理，并结合了索引功能。
-为了提升数据修剪和过滤效率，GreptimeDB 构建了智能索引和大规模并行处理（MPP）架构。
-该架构使用独立的索引文件记录统计信息，类似于 Apache Parquet 的行组元数据，同时还使用了内置指标记录不同查询的工作负载。
-通过结合基于成本的优化（CBO）和开发者定义的提示，GreptimeDB 能够启发式地构建智能索引，从而进一步提升查询性能。
-
-## 易于使用
-
-### 易于部署和维护
-
-为了简化部署和维护过程，GreptimeDB 提供了 [K8s operator](https://github.com/GreptimeTeam/greptimedb-operator)、[命令行工具](https://github.com/GreptimeTeam/gtctl)、嵌入式[仪表盘](https://github.com/GreptimeTeam/dashboard)和其他有用的工具，
-使得开发者可以轻松配置和管理数据库。
-请访问我们官网的 [GreptimeCloud](https://greptime.com) 了解更多信息。
-
-### 易于集成
-
-GreptimeDB 支持多种数据库连接协议，包括 MySQL、PostgreSQL、InfluxDB、OpenTSDB、Prometheus Remote Storage 和高性能 gRPC。
-此外，还提供了多种编程语言的 SDK，如 Java、Go、Erlang 等。
-我们还在不断与生态系统中的其他开源软件进行集成和连接，以增强开发者体验。
-接下来将详细介绍三种流行的语言：PromQL、SQL 和 Python。
-
-PromQL 是一种流行的查询语言，
-允许开发者选择和聚合由 Prometheus 提供的实时时序数据。
-它比 SQL 更简单，适用于使用 Grafana 进行可视化和创建告警规则。
-GreptimeDB 原生支持 PromQL，查询引擎会将其转换为查询计划，对其进行优化和执行。
-
-SQL 是一种高效的工具，
-用于分析跨越较长时间跨度或涉及多个表（如 join）的数据。
-此外，它在数据库管理方面也非常方便。
-
-Python 在数据科学家和 AI 专家中非常流行。
-GreptimeDB 允许直接在数据库中运行 Python 脚本。
-开发者可以编写 UDF 和 DataFrame API，通过嵌入 Python 解释器来加速数据处理。
-
-### 简单的数据模型与自动创建表
-
-结合指标（Tag/Field/Timestamp）模型和关系数据模型（Table），
-GreptimeDB 提供了一种称为时序表的新数据模型（见下图），以表格形式呈现数据，由行和列组成，指标的 Tag 和 Value 映射到列，并强制时间索引约束表示时间戳。
-
-![时序表](/time-series-table.png)
-
-然而，我们对 schema 的定义不是强制性的，而是更倾向于 MongoDB 等数据库的无 schema 方法。
-表将在数据写入时动态自动创建，并自动添加新出现的列（Tag 和 Field）。
-

i18n/zh/docusaurus-plugin-content-docs/version-0.11/user-guide/deployments/configuration.md

@@ -305,9 +305,7 @@ cache_capacity = "10GiB"
 ```
 
 
-我们建议你不用设置缓存的目录，因为数据库会自动创建该目录。默认的缓存目录位于
-- `{data_home}`（`v0.11.2` 之后）
-- `{data_home}/object_cache`（`v0.11.2` 之前）
+我们建议你不用设置缓存的目录，因为数据库会自动创建该目录。默认的缓存目录位于 `{data_home}` 目录下。
 
 
 对于 v0.11 之前的版本，你需要通过在存储设置中配置 `cache_path` 来手动启用读取缓存：
@@ -326,6 +324,17 @@ cache_capacity = "5GiB"
 
 `cache_path` 指定存储缓存文件的本地目录，而 `cache_capacity` 则决定缓存目录中允许的最大文件总大小（以字节为单位）。你可以通过将 `cache_path` 设置为空字符串来禁用读取缓存。
 
+
+自 `v0.12` 之后，写入缓存不再是实验性的功能。你可以通过修改 mito 的配置调整缓存的大小
+
+```toml
+[[region_engine]]
+[region_engine.mito]
+
+write_cache_size = "10GiB"
+```
+
+
 对于 v0.11 之前版本的写入缓存，你需要在 `[region_engine.mito]` 部分将 `enable_experimental_write_cache` 设置为 `true` 来启用：
 
 ```toml
@@ -337,11 +346,7 @@ experimental_write_cache_path = "/var/data/s3_write_cache"
 experimental_write_cache_size = "5GiB"
 ```
 
-`experimental_write_cache_path` 的默认值是
-- `{data_home}`（`v0.11.2` 之后）
-- `{data_home}/object_cache/write`（`v0.11.2` 之前）
-
-
+`experimental_write_cache_path` 默认值位于 `{data_home}` 目录下。
 要禁用写入缓存，请将 `enable_experimental_write_cache` 设置为 `false`。
 
 更详细的信息请参阅[性能调优技巧](/user-guide/administration/performance-tuning-tips)。
@@ -526,7 +531,7 @@ fork_dictionary_bytes = "1GiB"
 | `inverted_index.intermediate_path`       | 字符串 | `""`          | 存放外排临时文件的路径 (默认 `{data_home}/index_intermediate`).                                                        |
 | `inverted_index.metadata_cache_size`     | 字符串 | `64MiB`       | 倒排索引元数据缓存大小 |
 | `inverted_index.content_cache_size`      | 字符串 | `128MiB`      | 倒排索引文件内容缓存大小 |
-| `inverted_index.content_cache_page_size` | 字符串 | `8MiB`        | 倒排索引文件内容缓存页大小。倒排索引文件内容以页为单位进行读取和缓存，该配置项用于调整读取和缓存的粒度，优化缓存命中率。 |
+| `inverted_index.content_cache_page_size` | 字符串 | `64KiB`        | 倒排索引文件内容缓存页大小。倒排索引文件内容以页为单位进行读取和缓存，该配置项用于调整读取和缓存的粒度，优化缓存命中率。 |
 | `memtable.type`                          | 字符串 | `time_series` | Memtable type.<br/>- `time_series`: time-series memtable<br/>- `partition_tree`: partition tree memtable (实验性功能)  |
 | `memtable.index_max_keys_per_shard`      | 整数   | `8192`        | 一个 shard 内的主键数<br/>只对 `partition_tree` memtable 生效                                                          |
 | `memtable.data_freeze_threshold`         | 整数   | `32768`       | 一个 shard 内写缓存可容纳的最大行数<br/>只对 `partition_tree` memtable 生效                                            |