Repository: GreptimeTeam/docs
Pull request #1746: docs: tweak quick start
Author: login: killme2008
Created: 2025-05-16T01:09:11Z | Merged: 2025-05-19T03:46:45Z

## What's Changed in this PR

<!--
    Please confirm that you have revised the corresponding version of the document, ensuring it can run on the corresponding version of GreptimeDB. If other versions are involved, make the necessary adjustments accordingly.
    Note: `nightly` for the weekly built version, which is not released yet.
-->

Improve the quick start:
* Remove the tag column concepts
* Add indexes
* Adds searching logs SQL
* Notes for schemaless.

## Checklist

- [ ] Please confirm that all corresponding versions of the documents have been revised.
- [ ] Please ensure that the content in `sidebars.ts` matches the current document structure when you changed the document structure.
- [ ] This change requires follow-up update in localized docs.



Diff:
diff --git a/docs/getting-started/quick-start.md b/docs/getting-started/quick-start.md
index f54704f17e..9276961007 100644
--- a/docs/getting-started/quick-start.md
+++ b/docs/getting-started/quick-start.md
@@ -30,15 +30,17 @@ Or
 psql -h 127.0.0.1 -p 4003 -d public
 ```
 
+You can also use your browser to access the built-in DB dashboard at `http://127.0.0.1:4000/dashboard` to run the SQL queries in this document.
+
 ## Create tables
 
-Suppose you have a table named `grpc_latencies` that stores the gRPC latencies of your application.
+Suppose you have an event table named `grpc_latencies` that stores the gRPC services and processing latencies of your application.
 The table schema is as follows:
 
 ```sql
 CREATE TABLE grpc_latencies (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   method_name STRING,
   latency DOUBLE,
   PRIMARY KEY (host, method_name)
@@ -46,29 +48,35 @@ CREATE TABLE grpc_latencies (
 ```
 
 - `ts`: The timestamp when the metric was collected. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
-- `method_name`: The name of the RPC request method. It is a tag column.
+- `host`: The hostname of the application server, enabling [inverted index](/user-guide/manage-data/data-index.md#inverted-index).
+- `method_name`: The name of the RPC request method.
 - `latency`: The latency of the RPC request.
 
+And it's [append only](/user-guide/administration/design-table.md#when-to-use-append-only-tables) by setting `append_mode` to true, which is good for performance.
+
 Additionally, there is a table `app_logs` for storing application logs:
 
 ```sql
 CREATE TABLE app_logs (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   api_path STRING,
   log_level STRING,
-  `log` STRING,
+  log_msg STRING FULLTEXT INDEX WITH('case_sensitive' = 'false'),
   PRIMARY KEY (host, log_level)
 ) with('append_mode'='true');
 ```
 
 - `ts`: The timestamp of the log entry. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
+- `host`: The hostname of the application server, enabling inverted index.
 - `api_path`: The API path.
-- `log_level`: The log level of the log entry. It is a tag column.
-- `log`: The log message.
+- `log_level`: The log level of the log entry.
+- `log_msg`: The log message, enabling [fulltext index](/user-guide/manage-data/data-index.md#fulltext-index).
 
+ It's append only, too.
+ ::::tip
+We use SQL to ingest the data below, so we need to create the tables manually. However, GreptimeDB is [schemaless](/user-guide/ingest-data/overview.md#automatic-schema-generation) and can automatically generate schemas when using other ingestion methods.
+::::
 ## Write data
 
 Let's insert some mocked data to simulate collected metrics and error logs.
@@ -97,7 +105,7 @@ INSERT INTO grpc_latencies (ts, host, method_name, latency) VALUES
   ('2024-07-11 20:00:09', 'host2', 'GetUser', 114.0);
 ```
 
-After `2024-07-11 20:00:10`, `host1`'s latencies becomes unstable:
+After `2024-07-11 20:00:10`, `host1`'s latencies becomes unstable, fluctuating greatly with occasional spikes of several thousand milliseconds:
 
 ```sql
 
@@ -126,10 +134,10 @@ INSERT INTO grpc_latencies (ts, host, method_name, latency) VALUES
   ('2024-07-11 20:00:20', 'host2', 'GetUser', 95.0);
 ```
 
-Some error logs were collected when the `host1` latencies of RPC requests encounter latency issues.
+Some error logs were collected when the `host1` latencies of RPC requests encounter latency issues:
 
 ```sql
-INSERT INTO app_logs (ts, host, api_path, log_level, log) VALUES
+INSERT INTO app_logs (ts, host, api_path, log_level, log_msg) VALUES
   ('2024-07-11 20:00:10', 'host1', '/api/v1/resource', 'ERROR', 'Connection timeout'),
   ('2024-07-11 20:00:10', 'host1', '/api/v1/billings', 'ERROR', 'Connection timeout'),
   ('2024-07-11 20:00:11', 'host1', '/api/v1/resource', 'ERROR', 'Database unavailable'),
@@ -194,6 +202,26 @@ GROUP BY host;
 2 rows in set (0.11 sec)
 ```
 
+### Search logs by keyword
+
+Filter the log messages by keyword `timeout`:
+```sql
+SELECT * FROM app_logs WHERE lower(log_msg) @@ 'timeout' AND ts > '2024-07-11 20:00:00';
+```
+
+```sql
++---------------------+-------+------------------+-----------+--------------------+
+| ts                  | host  | api_path         | log_level | log_msg            |
++---------------------+-------+------------------+-----------+--------------------+
+| 2024-07-11 20:00:10 | host1 | /api/v1/billings | ERROR     | Connection timeout |
+| 2024-07-11 20:00:10 | host1 | /api/v1/resource | ERROR     | Connection timeout |
+| 2024-07-11 20:00:14 | host1 | /api/v1/billings | ERROR     | Timeout            |
+| 2024-07-11 20:00:14 | host1 | /api/v1/resource | ERROR     | Timeout            |
++---------------------+-------+------------------+-----------+--------------------+
+```
+
+The `@@` operator is used for [term searching](/user-guide/logs/query-logs.md).
+
 ### Range query
 
 You can use [range queries](/reference/sql/range.md#range-query) to monitor latencies in real-time.
@@ -232,6 +260,7 @@ you can easily and quickly determine the time of failure and the corresponding l
 The following SQL query uses the `JOIN` operation to correlate the metrics and logs:
 
 ```sql
+--- CTE using Range Query to query metrics and logs with aligned time windows ---
 WITH
   metrics AS (
     SELECT 
@@ -246,7 +275,7 @@ WITH
     SELECT 
       ts, 
       host,
-      count(log) RANGE '5s' AS num_errors, 
+      count(log_msg) RANGE '5s' AS num_errors,
     FROM
       app_logs 
     WHERE
@@ -284,6 +313,7 @@ ORDER BY
 8 rows in set (0.02 sec)
 ```
 
+We can see that during the time window when the gRPC latencies increases, the number of error logs also increases significantly, and we've identified that the problem is on `host1`.
 <!-- TODO need to fix bug
 
 ### Continuous aggregation
@@ -359,4 +389,4 @@ To further explore and utilize GreptimeDB:
 
 - [Visualize data using Grafana](/user-guide/integrations/grafana.md)
 - [Explore more demos of GreptimeDB](https://github.com/GreptimeTeam/demo-scene/)
-- [Read the user guide document to learn more details about GreptimeDB](/user-guide/overview.md)
+- [Learn GreptimeDB by user guide](/user-guide/overview.md)
diff --git a/i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start.md b/i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start.md
index b461fe5852..66d8b83f62 100644
--- a/i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start.md
+++ b/i18n/zh/docusaurus-plugin-content-docs/current/getting-started/quick-start.md
@@ -31,14 +31,16 @@ mysql -h 127.0.0.1 -P 4002
 psql -h 127.0.0.1 -p 4003 -d public
 ```
 
+你也可以通过浏览器访问 DB 内置的 Dashboard 地址 `http://127.0.0.1:4000/dashbaord` 运行本文档中的 SQL。
+
 ## 创建表
 
-假设你有一个名为 `grpc_latencies` 的表，用于存储的 gRPC 延迟。表 schema 如下：
+假设你有一个名为 `grpc_latencies` 的事件（Events）表，用于存储的 gRPC 调用接口以及它的处理时间。表 schema 如下：
 
 ```sql
 CREATE TABLE grpc_latencies (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   method_name STRING,
   latency DOUBLE,
   PRIMARY KEY (host, method_name)
@@ -46,28 +48,35 @@ CREATE TABLE grpc_latencies (
 ```
 
 - `ts`：收集指标时的时间戳，时间索引列。
-- `host`：主机名，tag 列。
+- `host`：主机名，设置了[倒排索引](/user-guide/manage-data/data-index.md#倒排索引)。
 - `method_name`：RPC 请求方法的名称，tag 列。
-- `latency`：RPC 请求的延迟。
+- `latency`：RPC 请求的响应时间。
+
+并且通过将 `append_mode` 设置为 true 来启用 [Append Only](/user-guide/administration/design-table.md#何时使用-append-only-表)模式，这通常对性能有帮助。
 
 此外，还有一个名为 `app_logs` 的表用于存储日志：
 
 ```sql
 CREATE TABLE app_logs (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   api_path STRING,
   log_level STRING,
-  `log` STRING,
+  log_msg STRING FULLTEXT INDEX WITH('case_sensitive' = 'false'),
   PRIMARY KEY (host, log_level)
 ) with('append_mode'='true');
 ```
 
 - `ts`：日志条目的时间戳，时间索引列。
-- `host`：主机名，tag 列。
+- `host`：主机名，设置了倒排索引。
 - `api_path`：API 路径。
 - `log_level`：日志级别，tag 列。
-- `log`：日志消息。
+- `log_msg`：日志消息内容，设置了[全文索引](/user-guide/manage-data/data-index.md#全文索引)。
+
+它也采用了 Append Only 模式。
+::::tip
+我们在下面使用 SQL 来导入数据，因此需要手动创建表。但 GreptimeDB 本身是 [schemaless](/user-guide/ingest-data/overview.md#自动生成表结构) 的，在使用其他写入方法时可以自动生成 schema。
+::::
 
 ## 写入数据
 
@@ -96,7 +105,7 @@ INSERT INTO grpc_latencies (ts, host, method_name, latency) VALUES
   ('2024-07-11 20:00:09', 'host2', 'GetUser', 114.0);
 ```
 
-在 `2024-07-11 20:00:10` 之后，`host1` 的延迟变得不稳定：
+在 `2024-07-11 20:00:10` 之后，`host1` 的响应时间变得不稳定，处理时间大幅波动，偶尔会出现数千毫秒的峰值：
 
 ```sql
 
@@ -125,10 +134,10 @@ INSERT INTO grpc_latencies (ts, host, method_name, latency) VALUES
   ('2024-07-11 20:00:20', 'host2', 'GetUser', 95.0);
 ```
 
-当 `host1` 的 gRPC 请求的延迟遇到问题时，收集了一些错误日志。
+当 `host1` 的 gRPC 请求的响应时间遇到问题时，收集了一些错误日志：
 
 ```sql
-INSERT INTO app_logs (ts, host, api_path, log_level, log) VALUES
+INSERT INTO app_logs (ts, host, api_path, log_level, log_msg) VALUES
   ('2024-07-11 20:00:10', 'host1', '/api/v1/resource', 'ERROR', 'Connection timeout'),
   ('2024-07-11 20:00:10', 'host1', '/api/v1/billings', 'ERROR', 'Connection timeout'),
   ('2024-07-11 20:00:11', 'host1', '/api/v1/resource', 'ERROR', 'Database unavailable'),
@@ -170,7 +179,7 @@ SELECT *
 5 rows in set (0.14 sec)
 ```
 
-你还可以在过滤数据时使用函数。例如，你可以使用 `approx_percentile_cont` 函数按主机分组计算延迟的第 95 百分位数：
+你还可以在过滤数据时使用函数。例如，你可以使用 `approx_percentile_cont` 函数按主机分组计算响应时间的 95 百分位数：
 
 ```sql
 SELECT 
@@ -191,6 +200,27 @@ GROUP BY host;
 2 rows in set (0.11 sec)
 ```
 
+
+### 通过关键词搜索日志
+
+通过关键词  `timeout`  过滤日志消息：
+```sql
+SELECT * FROM app_logs WHERE lower(log_msg) @@ 'timeout' AND ts > '2024-07-11 20:00:00';
+```
+
+```sql
++---------------------+-------+------------------+-----------+--------------------+
+| ts                  | host  | api_path         | log_level | log_msg            |
++---------------------+-------+------------------+-----------+--------------------+
+| 2024-07-11 20:00:10 | host1 | /api/v1/billings | ERROR     | Connection timeout |
+| 2024-07-11 20:00:10 | host1 | /api/v1/resource | ERROR     | Connection timeout |
+| 2024-07-11 20:00:14 | host1 | /api/v1/billings | ERROR     | Timeout            |
+| 2024-07-11 20:00:14 | host1 | /api/v1/resource | ERROR     | Timeout            |
++---------------------+-------+------------------+-----------+--------------------+
+```
+
+`@@` 操作符用于[短语搜索](/user-guide/logs/query-logs.md)。
+
 ### Range query
 
 你可以使用 [range query](/reference/sql/range.md#range-query)来实时监控延迟。例如，按 5 秒窗口计算请求的 p95 延迟：
@@ -226,6 +256,7 @@ ALIGN '5s' FILL PREV;
 通过组合两个表的数据，你可以快速地确定故障时间和相应的日志。以下 SQL 查询使用 `JOIN` 操作关联指标和日志：
 
 ```sql
+--- CTE 分别使用 Range Query 查询指标和日志，时间窗口对齐 --
 WITH
   metrics AS (
     SELECT 
@@ -240,7 +271,7 @@ WITH
     SELECT 
       ts, 
       host,
-      count(log) RANGE '5s' AS num_errors, 
+      count(log_msg) RANGE '5s' AS num_errors,
     FROM
       app_logs 
     WHERE
@@ -278,6 +309,7 @@ ORDER BY
 8 rows in set (0.02 sec)
 ```
 
+我们可以看到当 gRPC 响应时间增大的时间窗口内，错误日志也显著增多，并且确定问题在 `host1`。
 <!-- TODO need to fix bug
 
 ### 持续聚合
@@ -351,5 +383,5 @@ grpc_metrics,host=host2,method_name=GetUser latency=110,code=1 17207280210000000
 
 - [使用 Grafana 可视化数据](/user-guide/integrations/grafana.md)
 - [探索更多 GreptimeDB 的 Demo](https://github.com/GreptimeTeam/demo-scene/)
-- [阅读用户指南文档以了解更多关于 GreptimeDB 的详细信息](/user-guide/overview.md)
+- [阅读用户指南学习 GreptimeDB](/user-guide/overview.md)
 
diff --git a/i18n/zh/docusaurus-plugin-content-docs/version-0.14/getting-started/quick-start.md b/i18n/zh/docusaurus-plugin-content-docs/version-0.14/getting-started/quick-start.md
index b461fe5852..66d8b83f62 100644
--- a/i18n/zh/docusaurus-plugin-content-docs/version-0.14/getting-started/quick-start.md
+++ b/i18n/zh/docusaurus-plugin-content-docs/version-0.14/getting-started/quick-start.md
@@ -31,14 +31,16 @@ mysql -h 127.0.0.1 -P 4002
 psql -h 127.0.0.1 -p 4003 -d public
 ```
 
+你也可以通过浏览器访问 DB 内置的 Dashboard 地址 `http://127.0.0.1:4000/dashbaord` 运行本文档中的 SQL。
+
 ## 创建表
 
-假设你有一个名为 `grpc_latencies` 的表，用于存储的 gRPC 延迟。表 schema 如下：
+假设你有一个名为 `grpc_latencies` 的事件（Events）表，用于存储的 gRPC 调用接口以及它的处理时间。表 schema 如下：
 
 ```sql
 CREATE TABLE grpc_latencies (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   method_name STRING,
   latency DOUBLE,
   PRIMARY KEY (host, method_name)
@@ -46,28 +48,35 @@ CREATE TABLE grpc_latencies (
 ```
 
 - `ts`：收集指标时的时间戳，时间索引列。
-- `host`：主机名，tag 列。
+- `host`：主机名，设置了[倒排索引](/user-guide/manage-data/data-index.md#倒排索引)。
 - `method_name`：RPC 请求方法的名称，tag 列。
-- `latency`：RPC 请求的延迟。
+- `latency`：RPC 请求的响应时间。
+
+并且通过将 `append_mode` 设置为 true 来启用 [Append Only](/user-guide/administration/design-table.md#何时使用-append-only-表)模式，这通常对性能有帮助。
 
 此外，还有一个名为 `app_logs` 的表用于存储日志：
 
 ```sql
 CREATE TABLE app_logs (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   api_path STRING,
   log_level STRING,
-  `log` STRING,
+  log_msg STRING FULLTEXT INDEX WITH('case_sensitive' = 'false'),
   PRIMARY KEY (host, log_level)
 ) with('append_mode'='true');
 ```
 
 - `ts`：日志条目的时间戳，时间索引列。
-- `host`：主机名，tag 列。
+- `host`：主机名，设置了倒排索引。
 - `api_path`：API 路径。
 - `log_level`：日志级别，tag 列。
-- `log`：日志消息。
+- `log_msg`：日志消息内容，设置了[全文索引](/user-guide/manage-data/data-index.md#全文索引)。
+
+它也采用了 Append Only 模式。
+::::tip
+我们在下面使用 SQL 来导入数据，因此需要手动创建表。但 GreptimeDB 本身是 [schemaless](/user-guide/ingest-data/overview.md#自动生成表结构) 的，在使用其他写入方法时可以自动生成 schema。
+::::
 
 ## 写入数据
 
@@ -96,7 +105,7 @@ INSERT INTO grpc_latencies (ts, host, method_name, latency) VALUES
   ('2024-07-11 20:00:09', 'host2', 'GetUser', 114.0);
 ```
 
-在 `2024-07-11 20:00:10` 之后，`host1` 的延迟变得不稳定：
+在 `2024-07-11 20:00:10` 之后，`host1` 的响应时间变得不稳定，处理时间大幅波动，偶尔会出现数千毫秒的峰值：
 
 ```sql
 
@@ -125,10 +134,10 @@ INSERT INTO grpc_latencies (ts, host, method_name, latency) VALUES
   ('2024-07-11 20:00:20', 'host2', 'GetUser', 95.0);
 ```
 
-当 `host1` 的 gRPC 请求的延迟遇到问题时，收集了一些错误日志。
+当 `host1` 的 gRPC 请求的响应时间遇到问题时，收集了一些错误日志：
 
 ```sql
-INSERT INTO app_logs (ts, host, api_path, log_level, log) VALUES
+INSERT INTO app_logs (ts, host, api_path, log_level, log_msg) VALUES
   ('2024-07-11 20:00:10', 'host1', '/api/v1/resource', 'ERROR', 'Connection timeout'),
   ('2024-07-11 20:00:10', 'host1', '/api/v1/billings', 'ERROR', 'Connection timeout'),
   ('2024-07-11 20:00:11', 'host1', '/api/v1/resource', 'ERROR', 'Database unavailable'),
@@ -170,7 +179,7 @@ SELECT *
 5 rows in set (0.14 sec)
 ```
 
-你还可以在过滤数据时使用函数。例如，你可以使用 `approx_percentile_cont` 函数按主机分组计算延迟的第 95 百分位数：
+你还可以在过滤数据时使用函数。例如，你可以使用 `approx_percentile_cont` 函数按主机分组计算响应时间的 95 百分位数：
 
 ```sql
 SELECT 
@@ -191,6 +200,27 @@ GROUP BY host;
 2 rows in set (0.11 sec)
 ```
 
+
+### 通过关键词搜索日志
+
+通过关键词  `timeout`  过滤日志消息：
+```sql
+SELECT * FROM app_logs WHERE lower(log_msg) @@ 'timeout' AND ts > '2024-07-11 20:00:00';
+```
+
+```sql
++---------------------+-------+------------------+-----------+--------------------+
+| ts                  | host  | api_path         | log_level | log_msg            |
++---------------------+-------+------------------+-----------+--------------------+
+| 2024-07-11 20:00:10 | host1 | /api/v1/billings | ERROR     | Connection timeout |
+| 2024-07-11 20:00:10 | host1 | /api/v1/resource | ERROR     | Connection timeout |
+| 2024-07-11 20:00:14 | host1 | /api/v1/billings | ERROR     | Timeout            |
+| 2024-07-11 20:00:14 | host1 | /api/v1/resource | ERROR     | Timeout            |
++---------------------+-------+------------------+-----------+--------------------+
+```
+
+`@@` 操作符用于[短语搜索](/user-guide/logs/query-logs.md)。
+
 ### Range query
 
 你可以使用 [range query](/reference/sql/range.md#range-query)来实时监控延迟。例如，按 5 秒窗口计算请求的 p95 延迟：
@@ -226,6 +256,7 @@ ALIGN '5s' FILL PREV;
 通过组合两个表的数据，你可以快速地确定故障时间和相应的日志。以下 SQL 查询使用 `JOIN` 操作关联指标和日志：
 
 ```sql
+--- CTE 分别使用 Range Query 查询指标和日志，时间窗口对齐 --
 WITH
   metrics AS (
     SELECT 
@@ -240,7 +271,7 @@ WITH
     SELECT 
       ts, 
       host,
-      count(log) RANGE '5s' AS num_errors, 
+      count(log_msg) RANGE '5s' AS num_errors,
     FROM
       app_logs 
     WHERE
@@ -278,6 +309,7 @@ ORDER BY
 8 rows in set (0.02 sec)
 ```
 
+我们可以看到当 gRPC 响应时间增大的时间窗口内，错误日志也显著增多，并且确定问题在 `host1`。
 <!-- TODO need to fix bug
 
 ### 持续聚合
@@ -351,5 +383,5 @@ grpc_metrics,host=host2,method_name=GetUser latency=110,code=1 17207280210000000
 
 - [使用 Grafana 可视化数据](/user-guide/integrations/grafana.md)
 - [探索更多 GreptimeDB 的 Demo](https://github.com/GreptimeTeam/demo-scene/)
-- [阅读用户指南文档以了解更多关于 GreptimeDB 的详细信息](/user-guide/overview.md)
+- [阅读用户指南学习 GreptimeDB](/user-guide/overview.md)
 
diff --git a/versioned_docs/version-0.14/getting-started/quick-start.md b/versioned_docs/version-0.14/getting-started/quick-start.md
index f54704f17e..9276961007 100644
--- a/versioned_docs/version-0.14/getting-started/quick-start.md
+++ b/versioned_docs/version-0.14/getting-started/quick-start.md
@@ -30,15 +30,17 @@ Or
 psql -h 127.0.0.1 -p 4003 -d public
 ```
 
+You can also use your browser to access the built-in DB dashboard at `http://127.0.0.1:4000/dashboard` to run the SQL queries in this document.
+
 ## Create tables
 
-Suppose you have a table named `grpc_latencies` that stores the gRPC latencies of your application.
+Suppose you have an event table named `grpc_latencies` that stores the gRPC services and processing latencies of your application.
 The table schema is as follows:
 
 ```sql
 CREATE TABLE grpc_latencies (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   method_name STRING,
   latency DOUBLE,
   PRIMARY KEY (host, method_name)
@@ -46,29 +48,35 @@ CREATE TABLE grpc_latencies (
 ```
 
 - `ts`: The timestamp when the metric was collected. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
-- `method_name`: The name of the RPC request method. It is a tag column.
+- `host`: The hostname of the application server, enabling [inverted index](/user-guide/manage-data/data-index.md#inverted-index).
+- `method_name`: The name of the RPC request method.
 - `latency`: The latency of the RPC request.
 
+And it's [append only](/user-guide/administration/design-table.md#when-to-use-append-only-tables) by setting `append_mode` to true, which is good for performance.
+
 Additionally, there is a table `app_logs` for storing application logs:
 
 ```sql
 CREATE TABLE app_logs (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   api_path STRING,
   log_level STRING,
-  `log` STRING,
+  log_msg STRING FULLTEXT INDEX WITH('case_sensitive' = 'false'),
   PRIMARY KEY (host, log_level)
 ) with('append_mode'='true');
 ```
 
 - `ts`: The timestamp of the log entry. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
+- `host`: The hostname of the application server, enabling inverted index.
 - `api_path`: The API path.
-- `log_level`: The log level of the log entry. It is a tag column.
-- `log`: The log message.
+- `log_level`: The log level of the log entry.
+- `log_msg`: The log message, enabling [fulltext index](/user-guide/manage-data/data-index.md#fulltext-index).
 
+ It's append only, too.
+ ::::tip
+We use SQL to ingest the data below, so we need to create the tables manually. However, GreptimeDB is [schemaless](/user-guide/ingest-data/overview.md#automatic-schema-generation) and can automatically generate schemas when using other ingestion methods.
+::::
 ## Write data
 
 Let's insert some mocked data to simulate collected metrics and error logs.
@@ -97,7 +105,7 @@ INSERT INTO grpc_latencies (ts, host, method_name, latency) VALUES
   ('2024-07-11 20:00:09', 'host2', 'GetUser', 114.0);
 ```
 
-After `2024-07-11 20:00:10`, `host1`'s latencies becomes unstable:
+After `2024-07-11 20:00:10`, `host1`'s latencies becomes unstable, fluctuating greatly with occasional spikes of several thousand milliseconds:
 
 ```sql
 
@@ -126,10 +134,10 @@ INSERT INTO grpc_latencies (ts, host, method_name, latency) VALUES
   ('2024-07-11 20:00:20', 'host2', 'GetUser', 95.0);
 ```
 
-Some error logs were collected when the `host1` latencies of RPC requests encounter latency issues.
+Some error logs were collected when the `host1` latencies of RPC requests encounter latency issues:
 
 ```sql
-INSERT INTO app_logs (ts, host, api_path, log_level, log) VALUES
+INSERT INTO app_logs (ts, host, api_path, log_level, log_msg) VALUES
   ('2024-07-11 20:00:10', 'host1', '/api/v1/resource', 'ERROR', 'Connection timeout'),
   ('2024-07-11 20:00:10', 'host1', '/api/v1/billings', 'ERROR', 'Connection timeout'),
   ('2024-07-11 20:00:11', 'host1', '/api/v1/resource', 'ERROR', 'Database unavailable'),
@@ -194,6 +202,26 @@ GROUP BY host;
 2 rows in set (0.11 sec)
 ```
 
+### Search logs by keyword
+
+Filter the log messages by keyword `timeout`:
+```sql
+SELECT * FROM app_logs WHERE lower(log_msg) @@ 'timeout' AND ts > '2024-07-11 20:00:00';
+```
+
+```sql
++---------------------+-------+------------------+-----------+--------------------+
+| ts                  | host  | api_path         | log_level | log_msg            |
++---------------------+-------+------------------+-----------+--------------------+
+| 2024-07-11 20:00:10 | host1 | /api/v1/billings | ERROR     | Connection timeout |
+| 2024-07-11 20:00:10 | host1 | /api/v1/resource | ERROR     | Connection timeout |
+| 2024-07-11 20:00:14 | host1 | /api/v1/billings | ERROR     | Timeout            |
+| 2024-07-11 20:00:14 | host1 | /api/v1/resource | ERROR     | Timeout            |
++---------------------+-------+------------------+-----------+--------------------+
+```
+
+The `@@` operator is used for [term searching](/user-guide/logs/query-logs.md).
+
 ### Range query
 
 You can use [range queries](/reference/sql/range.md#range-query) to monitor latencies in real-time.
@@ -232,6 +260,7 @@ you can easily and quickly determine the time of failure and the corresponding l
 The following SQL query uses the `JOIN` operation to correlate the metrics and logs:
 
 ```sql
+--- CTE using Range Query to query metrics and logs with aligned time windows ---
 WITH
   metrics AS (
     SELECT 
@@ -246,7 +275,7 @@ WITH
     SELECT 
       ts, 
       host,
-      count(log) RANGE '5s' AS num_errors, 
+      count(log_msg) RANGE '5s' AS num_errors,
     FROM
       app_logs 
     WHERE
@@ -284,6 +313,7 @@ ORDER BY
 8 rows in set (0.02 sec)
 ```
 
+We can see that during the time window when the gRPC latencies increases, the number of error logs also increases significantly, and we've identified that the problem is on `host1`.
 <!-- TODO need to fix bug
 
 ### Continuous aggregation
@@ -359,4 +389,4 @@ To further explore and utilize GreptimeDB:
 
 - [Visualize data using Grafana](/user-guide/integrations/grafana.md)
 - [Explore more demos of GreptimeDB](https://github.com/GreptimeTeam/demo-scene/)
-- [Read the user guide document to learn more details about GreptimeDB](/user-guide/overview.md)
+- [Learn GreptimeDB by user guide](/user-guide/overview.md)


Reviews:
user: login: nicecui
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-16T03:27:18Z
user: login: nicecui
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-16T03:30:37Z
user: login: nicecui
state: COMMENTED
author_association: COLLABORATOR
submitted_at: 2025-05-16T03:31:37Z
user: login: fengjiachun
body: en part LGTM
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-05-16T03:36:40Z
user: login: killme2008
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-16T18:34:44Z
user: login: nicecui
state: APPROVED
author_association: COLLABORATOR
submitted_at: 2025-05-17T07:01:46Z
user: login: sunng87
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-19T02:26:20Z
user: login: killme2008
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-05-19T03:10:42Z
user: login: sunng87
state: APPROVED
author_association: MEMBER
submitted_at: 2025-05-19T03:46:38Z

Review comments:
diff_hunk: @@ -32,43 +32,49 @@ psql -h 127.0.0.1 -p 4003 -d public
 
 ## Create tables
 
-Suppose you have a table named `grpc_latencies` that stores the gRPC latencies of your application.
+Suppose you have a wide event table named `grpc_latencies` that stores the gRPC latencies of your application.
 The table schema is as follows:
 
 ```sql
 CREATE TABLE grpc_latencies (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   method_name STRING,
   latency DOUBLE,
   PRIMARY KEY (host, method_name)
 ) with('append_mode'='true');
 ```
 
 - `ts`: The timestamp when the metric was collected. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
-- `method_name`: The name of the RPC request method. It is a tag column.
+- `host`: The hostname of the application server, enabling [inverted index](/user-guide/manage-data/data-index#inverted-index).
path: docs/getting-started/quick-start.md
user: login: nicecui
body: ```suggestion
- `host`: The hostname of the application server, enabling [inverted index](/user-guide/manage-data/data-index.md#inverted-index).
```
created_at: 2025-05-16T03:23:39Z
author_association: COLLABORATOR
diff_hunk: @@ -32,43 +32,49 @@ psql -h 127.0.0.1 -p 4003 -d public
 
 ## Create tables
 
-Suppose you have a table named `grpc_latencies` that stores the gRPC latencies of your application.
+Suppose you have a wide event table named `grpc_latencies` that stores the gRPC latencies of your application.
 The table schema is as follows:
 
 ```sql
 CREATE TABLE grpc_latencies (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   method_name STRING,
   latency DOUBLE,
   PRIMARY KEY (host, method_name)
 ) with('append_mode'='true');
 ```
 
 - `ts`: The timestamp when the metric was collected. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
-- `method_name`: The name of the RPC request method. It is a tag column.
+- `host`: The hostname of the application server, enabling [inverted index](/user-guide/manage-data/data-index#inverted-index).
+- `method_name`: The name of the RPC request method.
 - `latency`: The latency of the RPC request.
 
+And it's append only.
+
 Additionally, there is a table `app_logs` for storing application logs:
 
 ```sql
 CREATE TABLE app_logs (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   api_path STRING,
   log_level STRING,
-  `log` STRING,
+  log_msg STRING FULLTEXT INDEX WITH('case_sensitive' = 'false'),
   PRIMARY KEY (host, log_level)
 ) with('append_mode'='true');
 ```
 
 - `ts`: The timestamp of the log entry. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
+- `host`: The hostname of the application server, enabling inverted index.
 - `api_path`: The API path.
-- `log_level`: The log level of the log entry. It is a tag column.
-- `log`: The log message.
+- `log_level`: The log level of the log entry.
+- `log_msg`: The log message, enabling [fulltext index](/user-guide/manage-data/data-index#fulltext-index).
path: docs/getting-started/quick-start.md
user: login: nicecui
body: ```suggestion
- `log_msg`: The log message, enabling [fulltext index](/user-guide/manage-data/data-index.md#fulltext-index).
```
created_at: 2025-05-16T03:23:59Z
author_association: COLLABORATOR
diff_hunk: @@ -32,43 +32,49 @@ psql -h 127.0.0.1 -p 4003 -d public
 
 ## Create tables
 
-Suppose you have a table named `grpc_latencies` that stores the gRPC latencies of your application.
+Suppose you have a wide event table named `grpc_latencies` that stores the gRPC latencies of your application.
 The table schema is as follows:
 
 ```sql
 CREATE TABLE grpc_latencies (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   method_name STRING,
   latency DOUBLE,
   PRIMARY KEY (host, method_name)
 ) with('append_mode'='true');
 ```
 
 - `ts`: The timestamp when the metric was collected. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
-- `method_name`: The name of the RPC request method. It is a tag column.
+- `host`: The hostname of the application server, enabling [inverted index](/user-guide/manage-data/data-index#inverted-index).
+- `method_name`: The name of the RPC request method.
 - `latency`: The latency of the RPC request.
 
+And it's append only.
+
 Additionally, there is a table `app_logs` for storing application logs:
 
 ```sql
 CREATE TABLE app_logs (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   api_path STRING,
   log_level STRING,
-  `log` STRING,
+  log_msg STRING FULLTEXT INDEX WITH('case_sensitive' = 'false'),
   PRIMARY KEY (host, log_level)
 ) with('append_mode'='true');
 ```
 
 - `ts`: The timestamp of the log entry. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
+- `host`: The hostname of the application server, enabling inverted index.
 - `api_path`: The API path.
-- `log_level`: The log level of the log entry. It is a tag column.
-- `log`: The log message.
+- `log_level`: The log level of the log entry.
+- `log_msg`: The log message, enabling [fulltext index](/user-guide/manage-data/data-index#fulltext-index).
 
+ It's append only, too.
+ ::::tip
+We use SQL to ingest the data below, so we need to create the tables manually. However, GreptimeDB is [schemaless](/user-guide/ingest-data/overview/#automatic-schema-generation) and can automatically generate schemas when using other ingestion methods.
path: docs/getting-started/quick-start.md
user: login: nicecui
body: ```suggestion
We use SQL to ingest the data below, so we need to create the tables manually. However, GreptimeDB is [schemaless](/user-guide/ingest-data/overview.md#automatic-schema-generation) and can automatically generate schemas when using other ingestion methods.
```
created_at: 2025-05-16T03:24:14Z
author_association: COLLABORATOR
diff_hunk: @@ -194,6 +200,24 @@ GROUP BY host;
 2 rows in set (0.11 sec)
 ```
 
+### Search logs by keyword
+
+Filter the log messages by keyword `timeout`:
+```sql
+SELECT * FROM app_logs WHERE lower(log_msg) @@ 'timeout' AND ts > '2024-07-11 20:00:00';
+```
+
+```sql
++---------------------+-------+------------------+-----------+--------------------+
+| ts                  | host  | api_path         | log_level | log_msg            |
++---------------------+-------+------------------+-----------+--------------------+
+| 2024-07-11 20:00:10 | host1 | /api/v1/billings | ERROR     | Connection timeout |
+| 2024-07-11 20:00:10 | host1 | /api/v1/resource | ERROR     | Connection timeout |
+| 2024-07-11 20:00:14 | host1 | /api/v1/billings | ERROR     | Timeout            |
+| 2024-07-11 20:00:14 | host1 | /api/v1/resource | ERROR     | Timeout            |
++---------------------+-------+------------------+-----------+--------------------+
+```
+
path: docs/getting-started/quick-start.md
user: login: nicecui
body: It is recommended to add a link to `/user-guide/logs/query-logs.md#simple-term-matching`
created_at: 2025-05-16T03:27:15Z
author_association: COLLABORATOR
diff_hunk: @@ -32,43 +32,49 @@ psql -h 127.0.0.1 -p 4003 -d public
 
 ## Create tables
 
-Suppose you have a table named `grpc_latencies` that stores the gRPC latencies of your application.
+Suppose you have a wide event table named `grpc_latencies` that stores the gRPC latencies of your application.
 The table schema is as follows:
 
 ```sql
 CREATE TABLE grpc_latencies (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   method_name STRING,
   latency DOUBLE,
   PRIMARY KEY (host, method_name)
 ) with('append_mode'='true');
 ```
 
 - `ts`: The timestamp when the metric was collected. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
-- `method_name`: The name of the RPC request method. It is a tag column.
+- `host`: The hostname of the application server, enabling [inverted index](/user-guide/manage-data/data-index#inverted-index).
+- `method_name`: The name of the RPC request method.
 - `latency`: The latency of the RPC request.
 
+And it's append only.
path: docs/getting-started/quick-start.md
user: login: nicecui
body: ```suggestion
- Set `append_mode` to true to preserve duplicate rows.
```
created_at: 2025-05-16T03:30:36Z
author_association: COLLABORATOR
diff_hunk: @@ -32,43 +32,49 @@ psql -h 127.0.0.1 -p 4003 -d public
 
 ## Create tables
 
-Suppose you have a table named `grpc_latencies` that stores the gRPC latencies of your application.
+Suppose you have a wide event table named `grpc_latencies` that stores the gRPC latencies of your application.
 The table schema is as follows:
 
 ```sql
 CREATE TABLE grpc_latencies (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   method_name STRING,
   latency DOUBLE,
   PRIMARY KEY (host, method_name)
 ) with('append_mode'='true');
 ```
 
 - `ts`: The timestamp when the metric was collected. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
-- `method_name`: The name of the RPC request method. It is a tag column.
+- `host`: The hostname of the application server, enabling [inverted index](/user-guide/manage-data/data-index#inverted-index).
+- `method_name`: The name of the RPC request method.
 - `latency`: The latency of the RPC request.
 
+And it's append only.
+
 Additionally, there is a table `app_logs` for storing application logs:
 
 ```sql
 CREATE TABLE app_logs (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   api_path STRING,
   log_level STRING,
-  `log` STRING,
+  log_msg STRING FULLTEXT INDEX WITH('case_sensitive' = 'false'),
   PRIMARY KEY (host, log_level)
 ) with('append_mode'='true');
 ```
 
 - `ts`: The timestamp of the log entry. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
+- `host`: The hostname of the application server, enabling inverted index.
 - `api_path`: The API path.
-- `log_level`: The log level of the log entry. It is a tag column.
-- `log`: The log message.
+- `log_level`: The log level of the log entry.
+- `log_msg`: The log message, enabling [fulltext index](/user-guide/manage-data/data-index#fulltext-index).
 
+ It's append only, too.
path: docs/getting-started/quick-start.md
user: login: nicecui
body: ```suggestion
- Set `append_mode` to true to preserve duplicate rows.
```
created_at: 2025-05-16T03:31:37Z
author_association: COLLABORATOR
diff_hunk: @@ -32,43 +32,49 @@ psql -h 127.0.0.1 -p 4003 -d public
 
 ## Create tables
 
-Suppose you have a table named `grpc_latencies` that stores the gRPC latencies of your application.
+Suppose you have a wide event table named `grpc_latencies` that stores the gRPC latencies of your application.
 The table schema is as follows:
 
 ```sql
 CREATE TABLE grpc_latencies (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   method_name STRING,
   latency DOUBLE,
   PRIMARY KEY (host, method_name)
 ) with('append_mode'='true');
 ```
 
 - `ts`: The timestamp when the metric was collected. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
-- `method_name`: The name of the RPC request method. It is a tag column.
+- `host`: The hostname of the application server, enabling [inverted index](/user-guide/manage-data/data-index#inverted-index).
+- `method_name`: The name of the RPC request method.
 - `latency`: The latency of the RPC request.
 
+And it's append only.
+
 Additionally, there is a table `app_logs` for storing application logs:
 
 ```sql
 CREATE TABLE app_logs (
   ts TIMESTAMP TIME INDEX,
-  host STRING,
+  host STRING INVERTED INDEX,
   api_path STRING,
   log_level STRING,
-  `log` STRING,
+  log_msg STRING FULLTEXT INDEX WITH('case_sensitive' = 'false'),
   PRIMARY KEY (host, log_level)
 ) with('append_mode'='true');
 ```
 
 - `ts`: The timestamp of the log entry. It is the time index column.
-- `host`: The hostname of the application server. It is a tag column.
+- `host`: The hostname of the application server, enabling inverted index.
 - `api_path`: The API path.
-- `log_level`: The log level of the log entry. It is a tag column.
-- `log`: The log message.
+- `log_level`: The log level of the log entry.
+- `log_msg`: The log message, enabling [fulltext index](/user-guide/manage-data/data-index#fulltext-index).
 
+ It's append only, too.
path: docs/getting-started/quick-start.md
user: login: killme2008
body: To preserve duplicate rows is not the purpose but the side effect. Append only is for performance.
created_at: 2025-05-16T18:34:44Z
author_association: MEMBER
diff_hunk: @@ -30,45 +30,53 @@ Or
 psql -h 127.0.0.1 -p 4003 -d public
 ```
 
+You can also use your browser to access the built-in DB dashboard at `http://{db_host}:4000/dashboard` to run the SQL queries in this document.
path: docs/getting-started/quick-start.md
user: login: sunng87
body: ```suggestion
You can also use your browser to access the built-in DB dashboard at `http://127.0.0.1:4000/dashboard` to run the SQL queries in this document.
```
created_at: 2025-05-19T02:20:56Z
author_association: MEMBER
diff_hunk: @@ -30,45 +30,53 @@ Or
 psql -h 127.0.0.1 -p 4003 -d public
 ```
 
+You can also use your browser to access the built-in DB dashboard at `http://{db_host}:4000/dashboard` to run the SQL queries in this document.
+
 ## Create tables
 
-Suppose you have a table named `grpc_latencies` that stores the gRPC latencies of your application.
+Suppose you have a wide event table named `grpc_latencies` that stores the gRPC services and processing latencies of your application.
path: docs/getting-started/quick-start.md
user: login: sunng87
body: the table is not wide at all..
created_at: 2025-05-19T02:21:45Z
author_association: MEMBER
diff_hunk: @@ -30,45 +30,53 @@ Or
 psql -h 127.0.0.1 -p 4003 -d public
 ```
 
+You can also use your browser to access the built-in DB dashboard at `http://{db_host}:4000/dashboard` to run the SQL queries in this document.
+
 ## Create tables
 
-Suppose you have a table named `grpc_latencies` that stores the gRPC latencies of your application.
+Suppose you have a wide event table named `grpc_latencies` that stores the gRPC services and processing latencies of your application.
path: docs/getting-started/quick-start.md
user: login: killme2008
body: Ok. Let's say it's an event table.
created_at: 2025-05-19T03:10:42Z
author_association: MEMBER

PR comments:
user: login: cloudflare-workers-and-pages[bot]
created_at: 2025-05-16T01:18:48Z
body: ## Deploying greptime-docs with &nbsp;<a href="https://pages.dev"><img alt="Cloudflare Pages" src="https://user-images.githubusercontent.com/23264/106598434-9e719e00-654f-11eb-9e59-6167043cfa01.png" width="16"></a> &nbsp;Cloudflare Pages

<table><tr><td><strong>Latest commit:</strong> </td><td>
<code>dd8bae8</code>
</td></tr>
<tr><td><strong>Status:</strong></td><td>&nbsp;✅&nbsp; Deploy successful!</td></tr>
<tr><td><strong>Preview URL:</strong></td><td>
<a href='https://41eb6da8.greptime-docs.pages.dev'>https://41eb6da8.greptime-docs.pages.dev</a>
</td></tr>
<tr><td><strong>Branch Preview URL:</strong></td><td>
<a href='https://feature-tweak-quick-start.greptime-docs.pages.dev'>https://feature-tweak-quick-start.greptime-docs.pages.dev</a>
</td></tr>
</table>

[View logs](https://dash.cloudflare.com/baee2593068c89990bf86c4ea1c28258/pages/view/greptime-docs/41eb6da8-fc4b-476f-86f0-ce63716b8bd9)

author_association: NONE
user: login: killme2008
created_at: 2025-05-16T18:42:17Z
body: If there are no more suggestions, I will translate it to chinese.
author_association: MEMBER