docs(tianmu): Update docs and contributors (#561) (#563)

* docs(tianmu): Update the docs of the intro and architecture

* style(trouble&FAQ): Update the style

* docs(Contributor): Update the Contributor list

* fix(docs): fix the wrong link

Docs/00-about-stonedb/architecture.md

@@ -146,8 +146,6 @@ The working process of the Knowledge Grid is as follows:
 ![Step3.png](./KnowledgeGrid-3.png)
 ### StoneDB Loader Parser
 StoneDB Loader Parser is a module responsible for data import and export. It processes `LOAD DATA INFILE` and `SELECT ... INTO FILE` operations. StoneDB provides an independent client to import data from various sources, written in different programming languages. Before data is imported, it is preprocessed, such as data compression and construction of Knowledge Nodes. In this way, operations such as parsing, verification, and transaction processing are eliminated when the data is being processed by the storage engine.
-### Replication Manager
-The high-availability structure of StoneDB includes a replication engine called Replication Manager to ensure strong consistency between the primary and secondary databases. Different from binlog replication used by MySQL to replicate original data, Replication Manager can directly replicate compressed data since data stored in StoneDB is compressed, without the need for decompression. This greatly reduces the traffic required for transmitting data.
 ### Compress
 Compress is the module for compressing data and supports more than 20 compression algorithms such as PPM, LZ4, B2, and Delta. In StoneDB, data is stored by column. Since data records stored in a column are of the same data type, StoneDB can dynamically choose the most efficient compression algorithm based on the data type defined for the column. More repeated values in a column indicates higher compression ratio of the column. Compression not only saves storage space but also I/O and memory resources.
 ### Decompress

Docs/00-about-stonedb/intro.md

@@ -26,6 +26,4 @@ StoneDB supports various compression algorithms, such as PPM, LZ4, B2, and Delta
 ### Knowledge Grid
 In StoneDB, Data Packs are classified into relevant Data Packs, irrelevant Data Packs, and suspect Data Packs. This classification helps filter out irrelevant Data Packs. StoneDB needs only to read metadata of relevant Data Packs, and decompress suspect Data Packs and then examine the data records to filter relevant data records. If the result set of the relevant Data Packs can be directly obtained through their Data Pack Nodes (also known as metadata nodes), relevant Data Packs will not be decompressed. The process of handling relevant Data Packs does not consume I/O, since no data is decompressed.
 ### High-performance import
-StoneDB provides an independent client to import data from various sources, written in different programming languages. Before data is imported, it is preprocessed, such as data compression and construction of Knowledge Nodes. In this way, operations such as parsing, verification, and transaction processing are eliminated when the data is being processed by the storage engine.
-### Push-based vectorized query execution
-When processing a query, StoneDB pushes column-based Data Packs from one operator to another based on the execution plan. Compared to the execution model used by row-oriented databases, push-based execution prevents in-depth calls of stacks and saves resources.
\ No newline at end of file
+StoneDB provides an independent client to import data from various sources, written in different programming languages. Before data is imported, it is preprocessed, such as data compression and construction of Knowledge Nodes. In this way, operations such as parsing, verification, and transaction processing are eliminated when the data is being processed by the storage engine.
\ No newline at end of file

Docs/02-getting-started/quick-start.md

@@ -7,7 +7,7 @@ sidebar_position: 3.3
 
 This topic presents some examples to show you that the StoneDB has superior performance than InnoDB on processing bulk insert of data, compressing data, and executing analytical queries.
 ## **Step 1. Deploy a test environment**
-Before using StoneDB, prepare your test environment according to instructions provided in [Quick Deployment](./quick-deployment.md) and start StoneDB.
+Before using StoneDB, prepare your test environment according to instructions provided in [Quick Deployment](./quick-deployment/quick-deployment-57.md) and start StoneDB.
 ## **Step 2. Prepare test data**
 Perform the following steps to generate test data.
 ### **1. Create a database**

Docs/04-developer-guide/00-compiling-methods/compile-using-docker.md

@@ -162,7 +162,7 @@ After the `make` commands are successful, you can choose either to compress the
 [root@06f1f385d3b3 build]# tar -zcPvf /home/stonedb56.tar.gz /stonedb56/
 ```
 ### Directly use StoneDB in the container
-You can refer to [Quick Deployment](.../../../../02-getting-started/quick-deployment) or the following code to deploy and use StoneDB in the container.
+You can refer to [Quick Deployment](.../../../../02-getting-started/quick-deployment/quick-deployment-56.md) or the following code to deploy and use StoneDB in the container.
 ```bash
 [root@06f1f385d3b3 build]# cd /stonedb56/install/
 

website/i18n/zh/docusaurus-plugin-content-blog-community/main.md

@@ -8,11 +8,12 @@ StoneDB 社区由用户、贡献者和社区独有的文化所组成。他们将
 - ![RingsC](https://avatars.githubusercontent.com/u/5336722?v=4 "title:RingsC,to://github.com/ringsc")
 - ![hustjieke](https://avatars.githubusercontent.com/u/18331104?v=4 "title:hustjieke,to://github.com/hustjieke")
 - ![dupeiliang](https://avatars.githubusercontent.com/u/39800914?v=4 "title:dupeiliang,to://github.com/dupeiliang")
+- ![andyli](https://avatars.githubusercontent.com/u/15212006?v=4 "title:andyli,to://github.com/andyli029")
 - ![SPzhang](https://avatars.githubusercontent.com/u/31213457?v=4 "title:SPzhang,to://github.com/zsp108")
 - ![CodingSuen](https://avatars.githubusercontent.com/u/69141572?v=4 "title:CodingSuen,to://github.com/CodingSuen")
-- ![jun-lihaijun](https://avatars.githubusercontent.com/u/103155258?v=4 "title:jun-lihaijun,to://github.com/jun-lihaijun")
-- ![XueDong-Chen](https://avatars.githubusercontent.com/u/34465107?v=4 "title:XueDong-Chen,to://github.com/XueDong-Chen")
-- ![zhx8817](https://avatars.githubusercontent.com/u/63028664?v=4 "title:zhx8817,to://github.com/zhx8817")
+- ![jun-lihaijun](https://avatars.githubusercontent.com/u/103155258?v=4 "title:jun-lihaijun,to://github.com/lihaijun-jun")
+- ![DandreChen](https://avatars.githubusercontent.com/u/34465107?v=4 "title:DandreChen,to://github.com/DandreChen")
+- ![isredstar](https://avatars.githubusercontent.com/u/63028664?v=4 "title:isredstar,to://github.com/isredstar")
 - ![konghaiya](https://avatars.githubusercontent.com/u/106147765?v=4 "title:konghaiya,to://github.com/konghaiya")
 - ![Nliver](https://avatars.githubusercontent.com/u/34496563?v=4 "title:Nliver,to://github.com/Nliver")
 - ![Yeekin-](https://avatars.githubusercontent.com/u/101704468?v=4 "title:Yeekin-,to://github.com/Yeekin-GYJ")
@@ -20,6 +21,11 @@ StoneDB 社区由用户、贡献者和社区独有的文化所组成。他们将
 - ![LuiciferYi](https://avatars.githubusercontent.com/u/24913493?v=4 "title:LuiciferYi,to://github.com/LuiciferYi")
 - ![litaihong](https://avatars.githubusercontent.com/u/79444526?v=4 "title:litaihong,to://github.com/lylth")
 - ![haitaoguan](https://avatars.githubusercontent.com/u/105625912?v=4 "title:haitaoguan,to://github.com/haitaoguan")
+- ![shangyanwen](https://avatars.githubusercontent.com/u/107781103?v=4 "title:shangyanwen,to://github.com/shangyanwen")
+- ![adofsauron](https://avatars.githubusercontent.com/u/3915817?v=4 "title:adofsauron,to://github.com/adofsauron")
+- ![fuxiang](https://avatars.githubusercontent.com/u/26853590?v=4 "title:fuxiang,to://github.com/gougexuanli")
+- ![lujiashun](https://avatars.githubusercontent.com/u/112846998?v=4 "title:lujiashun,to://github.com/lujiashun")
+- ![xuejiao-joy](https://avatars.githubusercontent.com/u/107540910?v=4 "title:xuejiao-joy,to://github.com/xuejiao-joy")
 ```
 
 

website/i18n/zh/docusaurus-plugin-content-docs/current/00-about-stonedb/architecture.md

@@ -134,8 +134,6 @@ select min(t2.D) from t1,t2 where t1.B=t2.C and t1.A>15;
 ![knowledgegrid-3](./KnowledgeGrid-3.png)
 ### StoneDB Loader Parser
 数据导入导出模块，即处理 LOAD DATA INFILE 与 SELECT … INTO FILE 任务。StoneDB 提供独立的数据导入客户端，支持不同的数据源环境，支持多语言架构。数据在导入前，首先会进行预处理，如数据压缩和知识节点的构建。数据经过预处理后，进入存储引擎无需再次执行解析、数据验证以及事务处理等操作。
-### Replication Manager
-StoneDB 复制管理模块，与 MySQL 的主从复制架构类似，StoneDB 为了保证数据的一致性，会在 Master 上执行写操作，然后通过复制技术传输到 Slave。与 MySQL 不同的是 StoneDB 存储的不是原始数据，而是压缩后的数据。如果使用 binlog 的方式来复制，会导致网络上产生大量数据流量，为了解决这个问题，StoneDB 实现了基于压缩后数据包的高效数据复制支持，相对于 binlog 复制，该技术可以大大降低网络传输所需的数据量。
 ### Compress
 数据压缩模块，在 StoneDB 中，数据是按照列模式进行组织的，这种数据组织形式对各类压缩算法十分友好，可依据数据类型选择合适的高效压缩算法。StoneDB 可以支持多达20多种自适应压缩算法，目前主要使用的有PPM、LZ4、B2、Delta 等。如果列的重复值越高，压缩效果越好。数据压缩后，不仅可以节约存储成本，还可以节约IO和内存。
 ### Decompress

website/i18n/zh/docusaurus-plugin-content-docs/current/00-about-stonedb/intro.md

@@ -44,7 +44,3 @@ StoneDB 会根据不同的数据类型选择不同的压缩算法，目前支持
 ### 高性能导入
 
 StoneDB 提供独立的数据导入客户端，支持不同的数据源环境，支持多语言架构。数据在导入前，首先会进行预处理，如数据压缩和知识节点的构建。数据经过预处理后，进入存储引擎无需再次执行解析、数据验证以及事务处理等操作。
-
-### 基于推送的矢量化查询处理
-
-StoneDB 通过执行计划将矢量块（列式数据切片）从一个运算符推送到另一个运算符来处理查询，与基于元组的处理模型相比，基于推送的执行模型避免了深度调用堆栈，并节省了资源。

website/i18n/zh/docusaurus-plugin-content-docs/current/08-troubleshooting/resource-bottleneck.md

@@ -25,65 +25,115 @@ PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
   ......
 ```
 第一行
-10:12:21：当前系统时间
-up 5 days：自上一次系统启动后到现在的运行天数
-4 user：登录到系统的用户数
-load average：过去1分钟、5分钟、15分钟，系统负载的平均值
+
+- `10:12:21`：当前系统时间
+
+- `up 5 days`：自上一次系统启动后到现在的运行天数
+
+- `4 user`：登录到系统的用户数
+
+- `load average`：过去1分钟、5分钟、15分钟，系统负载的平均值
+
 第二行
-total：系统进程总数
-running：处于运行状态的进程数
-sleeping：处于休眠状态的进程数
-stopped：处于被停止状态的进程数
-zombie：处于僵尸状态进程数
+
+- `total`：系统进程总数
+
+- `running`：处于运行状态的进程数
+
+- `sleeping`：处于休眠状态的进程数
+
+- `stopped`：处于被停止状态的进程数
+
+- `zombie`：处于僵尸状态进程数
+
 第三行
-us：用户进程占用CPU的百分比
-sy：系统进程占用CPU的百分比
-ni：优先级被改变过的进程占用CPU的百分比
-id：空闲CPU占用的百分比
-wa：IO等待占用CPU的百分比
-hi：硬件中断占用CPU的百分比
-si：软件中断占用CPU的百分比
-st：虚拟化环境占用CPU的百分比
+
+- `us`：用户进程占用CPU的百分比
+
+- `sy`：系统进程占用CPU的百分比
+
+- `ni`：优先级被改变过的进程占用CPU的百分比
+
+- `id`：空闲CPU占用的百分比
+
+- `wa`：IO等待占用CPU的百分比
+
+- `hi`：硬件中断占用CPU的百分比
+
+- `si`：软件中断占用CPU的百分比
+
+- `st`：虚拟化环境占用CPU的百分比
+
 需要重点关注CPU的使用率，当us值较高时，说明用户进程消耗CPU时间较多，如果长时间超过50%时，应尽快优化应用服务。当sy值较高时，说明系统进程消耗CPU时间较多，比如可能是操作系统配置不合理或者出现操作系统的Bug。当wa值较高时，说明系统IO等待比较严重，比如可能是发生了大量的随机IO访问，IO带宽出现瓶颈。
+
 第四行
-total：物理内存总大小，单位为M
-free：空闲的内存大小
-used：已使用的内存大小
-buff/cache：已缓存的内存大小
+
+- `total`：物理内存总大小，单位为M
+
+- `free`：空闲的内存大小
+
+- `used`：已使用的内存大小
+
+- `buff/cache`：已缓存的内存大小
+
 第五行
-total：Swap大小
-free：空闲的Swap大小
-used：已使用的Swap大小
-avail Mem：已缓存的Swap大小
+
+- `total`：Swap大小
+
+- `free`：空闲的Swap大小
+
+- `used`：已使用的Swap大小
+
+- `avail Mem`：已缓存的Swap大小
+
 进程列表
-PID：进程的id
-USER：进程的拥有者
-PR：进程的优先级，值越小越优先执行
-NI：进程nice值，正值表示降低进程优先级，负值表示提高进程优先级，nice取值范围为(-20,19)，默认情况下，进程的nice值为0
-VIRT：进程占用的虚拟内存大小
-RES：进程占用的物理内存大小
-SHR：进程占用的共享内存大小
-S：进程状态，其中S表示休眠，R表示正在运行，Z表示僵死状态，N表示该进程优先值为负数
-%CPU：进程CPU使用率
-%MEM：进程内存使用率
-TIME+：进程启动后占用CPU的总时间，即占用CPU使用时间的累加值
-COMMAND：进程启动命令名称
+
+- `PID`：进程的id
+
+- `USER`：进程的拥有者
+
+- `PR`：进程的优先级，值越小越优先执行
+
+- `NI`：进程nice值，正值表示降低进程优先级，负值表示提高进程优先级，nice取值范围为(-20,19)，默认情况下，进程的nice值为0
+
+- `VIRT`：进程占用的虚拟内存大小
+
+- `RES`：进程占用的物理内存大小
+
+- `SHR`：进程占用的共享内存大小
+
+- `S`：进程状态，其中S表示休眠，R表示正在运行，Z表示僵死状态，N表示该进程优先值为负数
+
+- `%CPU`：进程CPU使用率
+
+- `%MEM`：进程内存使用率
+
+- `TIME+`：进程启动后占用CPU的总时间，即占用CPU使用时间的累加值
+
+- `COMMAND`：进程启动命令名称
+
 **出现CPU使用率高诊断方法**：
 1）找出调用的函数
 ```shell
 top -H
 perf top -p xxx
 ```
-注：xxx为top -H返回最消耗CPU的进程。
+:::info
+xxx为top -H返回最消耗CPU的进程。
+:::
+
 2）找出消耗CPU的SQL
 ```shell
 pidstat -t -p <mysqld_pid> 1 5
 select * from performance_schema.threads where thread_os_id = xxx\G
 select * from information_schema.processlist where id = performance_schema.threads.processlist_id\G
 ```
-注：xxx为pidstat返回最消耗CPU的线程。
+:::info
+xxx为pidstat返回最消耗CPU的线程。
+:::
 ## 内存
 top、vmstat、free都可以检查内存的使用情况。
+
 free返回结果示例如下：
 ```shell
 # free -g
@@ -91,19 +141,25 @@ total        used        free      shared  buff/cache   available
 Mem:            251          44           1           0         205         205
 Swap:             7           0           7
 ```
-total：物理内存总大小，total = used + free + buff/cache
-used：已使用的内存大小
-free：空闲的内存大小
-shared：共享内存大小
-buff/cache：缓存内存大小
-available：可用物理内存大小，available = free + buff/cache
+- `total`：物理内存总大小，total = used + free + buff/cache
+- `used`：已使用的内存大小
+- `free`：空闲的内存大小
+- `shared`：共享内存大小
+- `buff/cache`：缓存内存大小
+- `available`：可用物理内存大小，available = free + buff/cache
+
 **出现内存使用率高诊断方法**：
+
 1）检查配置是否合理，例如：操作系统物理内存128G，而分配给数据库实例110G，由于操作系统进程和其它应用程序也需要内存，很容易导致内存被消耗光；
+
 2）检查并发连接数是否过高，read_buffer_size、read_rnd_buffer_size、sort_buffer_size、thread_stack、join_buffer_size、binlog_cache_size都是session级别的，连接数越多，需要的内存就越多，因此这些参数也不能设置太大；
+
 3）检查是否有不合理的join，例如：多表关联时，执行计划中驱动表的结果集比较大，需要循环多次执行，容易导致内存泄漏；
+
 4）检查打开文件数是否过多和table_open_cache是否设置合理，访问一个表时，会将该表放入缓存区table_open_cache，目的是下次可以更快的访问，但如果table_open_cache设置太大，且打开的表又多的情况下，是很消耗内存的。
 ## IO
 iostat、dstat、pidstat都可以检查IO的使用情况。
+
 iostat返回结果示例如下：
 ```shell
 # iostat -x 1 1
@@ -117,20 +173,34 @@ sda               0.00     0.00    0.00    0.00     0.04     0.00    85.75     0
 sdb               0.06     0.11    7.61    1.10  1849.41    50.81   436.48     0.36   40.93   46.75    0.48   1.56   1.35
 dm-0              0.00     0.00    0.28    0.19     8.25    12.05    87.01     0.00    4.81    7.37    0.94   1.61   0.08
 ```
-rrqm/s: 每秒进行merge的读操作数
-wrqm/s: 每秒进行merge的写操作数
-r/s：每秒读IO次数
-w/s：每秒写IO次数
-rkB/s：每秒读IO大小，单位为KB
-wkB/s：每秒写IO大小，单位为KB
-avgrq-sz：平均请求大小，单位为扇区（512B）
-avgqu-sz：在驱动请求队列和在设备中活跃的平均请求数
-await：平均IO响应时间，包括在驱动请求队列里的等待和设备的IO响应时间
-r_await：每次读操作IO响应时间
-w_await：每次写操作IO响应时间
-svctm：磁盘设备的IO平均响应时间
-%util：设备忙处理IO请求的百分比（使用率），磁盘的繁忙程度
-r/s + w/s：IOPS
+- `rrqm/s`: 每秒进行merge的读操作数
+
+- `wrqm/s`: 每秒进行merge的写操作数
+
+- `r/s`：每秒读IO次数
+
+- `w/s`：每秒写IO次数
+
+- `rkB/s`：每秒读IO大小，单位为KB
+
+- `wkB/s`：每秒写IO大小，单位为KB
+
+- `avgrq-sz`：平均请求大小，单位为扇区（512B）
+
+- `avgqu-sz`：在驱动请求队列和在设备中活跃的平均请求数
+
+- `await`：平均IO响应时间，包括在驱动请求队列里的等待和设备的IO响应时间
+
+- `r_await`：每次读操作IO响应时间
+
+- `w_await`：每次写操作IO响应时间
+
+- `svctm`：磁盘设备的IO平均响应时间
+
+- `%util`：设备忙处理IO请求的百分比（使用率），磁盘的繁忙程度
+
+- `r/s + w/s`：IOPS
+
 **出现IO使用率高诊断方法**：
 1）找出使用率最高的磁盘设备
 ```shell
@@ -150,4 +220,8 @@ pidstat -dt -p mysqld_id 1
 select * from performance_schema.threads where thread_os_id = xxx\G
 select * from information_schema.processlist where id = performance_schema.threads.processlist_id\G
 ```
-注：xxx为pidstat返回最消耗IO的线程。
+:::info
+
+xxx为pidstat返回最消耗IO的线程。
+
+:::
\ No newline at end of file

website/i18n/zh/docusaurus-plugin-content-docs/current/09-FAQ/troubleshoot-faq.md

@@ -18,20 +18,36 @@ sidebar_position: 10.3
 如果操作系统日志、error日志和trace日志的信息不足以分析数据库实例crash的原因，需要开启core dump。开启core dump后，当数据库实例再次发生crash时，会生成core dumpfile，用gdb分析生成的core dumpfile。
 ## 数据库实例挂起了该怎么办？
 数据库实例挂起可能发生的原因：
-1）系统负载高
-2）连接数满
-3）磁盘空间满
-4）MDL锁等待
-5）Bug
+
+1. 系统负载高
+
+2. 连接数满
+
+3. 磁盘空间满
+
+4. MDL 锁等待
+
+5. Bug
+
 需要收集的日志：
-1）查看连接数是否满了
-如果连接数超过参数max_connections的阀值，新的连接是无法连接数据库实例的。
-2）查看磁盘空间是否满了
+
+1. 查看连接数是否满了
+
+如果连接数超过参数 max_connections 的阀值，新的连接是无法连接数据库实例的。
+
+2. 查看磁盘空间是否满了
+
 如果磁盘空间满了，DML产生的binlog是无法写入磁盘文件的。
-3）查看是否有锁等待
-如果show processlist有大量"Waiting for table metadata lock"等待的返回，需要找到阻塞者，并kill阻塞者。
-4）收集mysqld进程的堆栈
-如果进程处于假死、死循环状态时，pstack可以跟踪进程的堆栈。在一段时间内，多执行几次pstack，如果堆栈总停留在同一个位置，这个位置就特别需要关注，很可能就是出问题的地方。
-pstack在抓取进程的堆栈时会触发一个SIGSTOP信号（类似发出kill -19命令），实际上pstack调用的是gdb的命令。gdb通常会发起SIGSTOP信号来停止进程的运行，因此在生产环境执行pstack命令的时候一定要格外小心，因为可能会导致应用服务停止运行一小会儿。
-输出所有线程堆栈的信息：pstack mysqld_pid >> mysqld_pid.log
+
+3. 查看是否有锁等待
+
+如果`show processlist`有大量`"Waiting for table metadata lock"`等待的返回，需要找到阻塞者，并kill阻塞者。
+
+4. 收集 mysqld 进程的堆栈
+ 
+如果进程处于假死、死循环状态时，pstack 可以跟踪进程的堆栈。在一段时间内，多执行几次 pstack，如果堆栈总停留在同一个位置，这个位置就特别需要关注，很可能就是出问题的地方。
+
+pstack 在抓取进程的堆栈时会触发一个 SIGSTOP 信号（类似发出 kill -19 命令），实际上 pstack 调用的是 gdb 的命令。gdb  通常会发起 SIGSTOP 信号来停止进程的运行，因此在生产环境执行 pstack 命令的时候一定要格外小心，因为可能会导致应用服务停止运行一小会儿。
+
+输出所有线程堆栈的信息：`pstack mysqld_pid >> mysqld_pid.log`