在电脑前的每一刻，我们都在和键盘“对话”——写报告、敲代码、聊消息，手指无意识地敲击着按键。但你有没有想过：哪颗键被你按得最频繁？编程时总依赖的快捷键是哪些？键盘上哪些键其实在“闲置”？



通过网盘分享的文件：TraceBoard

链接: https://pan.baidu.com/s/1Z4fx7rf80oUMU10oUTQBpA?pwd=wsth 提取码: wsth

一款叫 **TraceBoard** 的开源工具，就能把这些“隐形”的按键数据变成清晰的分析，不管是想优化打字效率，还是为设计提供依据，它都能派上用场。

![](https://blog.lc044.love/static/img/8774f14af9866b6597d9854a26eddeeb.image.webp)

## 一、TraceBoard 是什么？
简单说，它是一款**跨平台开源的键盘按键统计工具**。

不同于普通工具只记录“敲了多少字”，TraceBoard 能精准追踪每一颗键的使用频率，再通过可视化图表呈现结果。它不仅是个人用户的“打字习惯显微镜”，更是开发者、设计师优化产品的“数据指南针”。


## 二、核心功能：不止统计，更懂你的需求
TraceBoard 的功能不复杂，但每一个都戳中实际需求，没有多余操作。

1. **精准的按键统计**  
   实时记录所有按键的触发次数，小到“Shift”“Ctrl”，大到字母键、数字键，都能清晰计数。你能直接看到“空格键用了500次”“编程时‘{’键比‘}’键多按30次”，摸清自己的打字偏好。

2. **直观的数据可视化**  
   不会让你对着一堆数字头疼——它会用**柱状图、热力图**把数据画出来。高频按键一目了然，比如你能快速发现“自己敲代码时，‘Tab’和‘Enter’是Top 3按键”，无需手动计算。

3. **开源可定制，灵活适配场景**  
   作为开源项目，你完全可以按自己的需求改：比如给程序员加一个“快捷键组合统计”（比如统计“Ctrl+C”“Ctrl+V”的使用次数），或给文字工作者加“标点符号使用分析”，没有功能限制。

4. **全平台兼容，不用挑设备**  
   不管你用 Windows、macOS 还是 Linux，都能安装使用，无需担心“系统不支持”的问题，一台电脑就能开启统计。


## 三、谁适合用？看这3类场景就懂
TraceBoard 不是“小众工具”，不同人群都能找到自己的用法：

- **个人用户：优化习惯，摸清设备**  
  - 效率党：通过高频按键，调整快捷键或键盘布局（比如把常用键放在更顺手的位置）；  
  - 设备党：知道哪颗键磨损最快，提前准备替换键帽，延长键盘寿命。

- **键盘/外设设计师：找对设计方向**  
  不用靠“主观猜测”用户习惯——收集多份 TraceBoard 数据，就能知道“用户更需要大尺寸的‘Backspace’键”“‘Caps Lock’键使用频率极低”，设计出更贴合需求的键盘。

- **开发者：让产品更懂用户**  
  做输入法、代码编辑器时，能通过数据判断“用户常用哪些符号”“哪组快捷键最受欢迎”，比如给输入法加“高频符号快捷栏”，让产品更易用。


## 四、5分钟上手：用起来超简单
不用复杂的配置，跟着三步走就能开启统计：

1. 打开 [TraceBoard](https://github.com/LC044/TraceBoard)；  
2. 根据自己的操作系统，下载对应版本的安装包（或克隆项目源码）；  
3. 按照仓库里的 **README 文档**操作——几乎没有复杂依赖，点击安装、确认权限，就能开始实时统计。


## 结语：从“盲目打字”到“读懂键盘”
TraceBoard 最棒的地方，是把“看不见的习惯”变成了“能分析的数据”。

如果你是个人用户，它能帮你优化打字效率、保护键盘；如果你是开发者或设计师，它能给你的产品设计提供真实的用户数据支撑。

现在就去 GitHub 搜“TraceBoard”，花5分钟开启统计，看看你的键盘到底藏着哪些习惯吧！

每天敲上千次键盘？TraceBoard 帮你揭开按键习惯的秘密

你是否遇到过这样的困扰？从网盘下载的图片导入相册后，拍摄日期全变成了下载时间；截图或处理过的照片总是 “丢失” 拍摄日期，导致相册按时间排序时混乱不堪……



别担心！今天分享一个超实用的 **软件神器**，只需文件名中的时间信息，就能自动修复图片的 EXIF 拍摄日期，让相册管理回归井然有序～

**下载地址：** https://pan.baidu.com/s/1J0XRvdvalprGTePu5rV9Ag?pwd=eeh6 

### 🔍 **四大核心功能，解决日期管理难题**

* **智能提取**：支持多种日期格式（YYYYMMDD\_HHMMSS、时间戳等），精准解析文件名
* **自动校验**：过滤 1970-2035 年外的无效日期，确保数据合理
* **元数据修复**：一键写入 `DateTimeOriginal` 等字段，适配主流相册排序规则
* **灵活模式**：强制覆盖或保留最早日期，满足不同修复需求

### ✨ **核心原理揭秘：三步搞定日期修复**

1. **提取时间**：通过正则表达式 “扫描” 文件名，捕获如 `20231001_143000` 或时间戳等格式

    ```python
    # 示例：匹配 YYYYMMDD_HHMMSS 格式
    pattern = r"(\d{8})[ _\.-](\d{6})" 
    match = re.search(pattern, "Photo_20231001_143000.jpg") 
    ```
2. **校验有效性**：确保提取的日期在合理范围内，避免 “未来照片” 或 “穿越时间”
3. **写入 EXIF**：使用 `piexif` 库修改图片元数据，自动更新拍摄时间

### 📌 **3 步玩转脚本修复（附保姆级代码）**

1. **安装依赖**：

    ```bash
    pip install piexif  # 仅需一行命令，轻松安装工具库
    ```
2. **运行脚本**：

    * 将图片放入指定文件夹，修改代码中的 `img_path` 和 `new_path`
    * 运行后自动生成带正确日期的新图片

    ```python
    if __name__ == '__main__': 
        img_path = './待修复图片/Screenshot_20231001_143000.jpg' 
        new_path = './修复后图片/正确日期照片.jpg' 
        modify_image(ImageFile(img_path), save_path=new_path) 
    ```
3. **批量处理**：添加循环逻辑，一键修复整个文件夹图片
4. 运行结果

![image.png](https://blog.lc044.love/static/img/01192a9a40403b39489a47bcf663c3cf.image.webp)

### 🚀 **完整代码 &amp; 工具下载**

🔗 GitHub仓库：[https://github.com/LC044/EasyBox](https://github.com/LC044/EasyBox)

![image.png](https://blog.lc044.love/static/img/f2756d8910cdb9d7410d0fb7df8d216a.image.webp)
💡 **提示**：仓库内包含示例图片和详细注释，新手也能轻松上手！

EasyBox——一个开源的多功能工具箱

# TPCC测试方法—benchmarksql
## 一、环境准备
　　操作系统：openEuler 22.03 x86_64

　　前提条件：openGauss已经编译并安装成功，gsql可以正常连接数据库

　　需要的依赖：ant

```bash
sudo dnf install ant
```

### 1.1 创建新用户
　　连接数据库`gsql -r -p 5432`，创建远程连接用户tpcc，并授予SYSADMIN管理员权限。

```sql
CREATE USER tpcc PASSWORD 'Tpcc@123';
ALTER USER tpcc SYSADMIN;
create database tpccdb;
```

　　这里用户tpcc用于做benchmaksql的测试用户，测试数据库为tpccdb，该用户赋予管理员权限。

### 1.2 安装BenchMarkSQL
1. 下载并上传BenchMarkSQL 下载BenchMarkSQL源码包，并上传和解压。 下载地址：[https://sourceforge.net/projects/benchmarksql/](https://sourceforge.net/projects/benchmarksql/)
2. 将benchmarksql-5.0.zip 压缩包上传至服务器上并解压。 解压

```bash
unzip benchmarksql-5.0.zip
```

### 1.3 下载openGauss JDBC驱动
　　BenchMarkSQL使用JDBC驱动包，连续各种数据库，故需要下载openGauss对应版本的JDBC驱动包。

+ 下载地址：[https://opengauss.org/zh/download/](https://opengauss.org/zh/download/)


![](https://blog.lc044.love/static/img/eded6a5527da085cb3fe68158ffad6a1.image.webp)

　　上传openGauss-5.0.0-JDBC.tar.gz到benchmarksql-5.0/lib/postgres/路径，并解压。openGauss的JDBC驱动解压后有两个jar包（`postgresql.jar`和`opengauss-jdbc-5.0.0.jar`），解压前需要将benchmarksql-5.0/lib/postgres/路径下原有的`postgresql.jar`文件删除，然后将解压后的两个jar包复制到benchmarksql-5.0/lib/postgres/路径下。

```bash
cd ~/benchmarksql-5.0/lib/postgres/
# 删除原有的postgresql.jar
mv postgresql.jar postgresql.jar.bak
tar -xzvf openGauss-5.0.0-JDBC.tar.gz
```

### 1.4 编译BenchMarkSQL
```bash
cd ~/benchmarksql-5.0
ant
```

![](https://blog.lc044.love/static/img/ebfc752906ffa6c4f9ef963a8dd53c52.image.webp)

## 二、修改配置
### 2.1 创建openGauss的props文件
　　benchmarksql-5.0/run/ 路径下的 Props.*为BenchMarkSQL的测试配置文件，在生成测试数据和执行测试时，BenchMarkSQL都会使用该文件。

　　可复制已有的props.*模板，修改为可用于openGauss的配置文件。

```bash
cd ~/benchmarksql-5.0/run
cp props.pg props.opengauss
nano props.opengauss
```

　　写入如下信息，具体配置根据注释修改

```bash
db=postgres
driver=org.postgresql.Driver
// 数据库的ip、端口和数据库名
conn=jdbc:postgresql://127.0.0.1:33000/tpccdb
// 前面创建的数据库用户名
user=tpcc
// 数据库密码
password=Tpcc@123

// 数据仓数量
warehouses=100
// 数据创建工作线程数
loadWorkers=25

// 测试过程的连接终端数（并发数）
terminals=100
// 每个终端运行的事务数，该参数与下面的runMins是两种测试策略，所以设置每个终端运行的事务数之后测试时间必须设置为0
runTxnsPerTerminal=0
// 测试时间，如果设置了测试时间，那么runTxnsPerTerminal参数必须为0
runMins=15
//Number of total transactions per minute，0代表无限制
limitTxnsPerMin=0

//Set to true to run in 4.x compatible mode. Set to false to use the
//entire configured database evenly.
terminalWarehouseFixed=false

//The following five values must add up to 100
//The default percentages of 45, 43, 4, 4 & 4 match the TPC-C spec
newOrderWeight=45
paymentWeight=43
orderStatusWeight=4
deliveryWeight=4
stockLevelWeight=4

// Directory name to create for collecting detailed result data.
// Comment this out to suppress.
resultDirectory=my_result_%tY-%tm-%td_%tH%tM%tS
osCollectorScript=./misc/os_collector_linux.py
osCollectorInterval=1
// 服务器ssh连接的用户名和地址（Tpcc测试机必须跟数据库服务器设置ssh互信）
osCollectorSSHAddr=shuaikangzhou@127.0.0.1
// 监控的磁盘和网卡，可以设置多个，用空格隔开，网卡命名方式net_xxx，xxx是设备名,磁盘命名方式 blk_xxx，xxx是磁盘名
osCollectorDevices=net_eth4 blk_sdc
```

+ 网卡查看方式

```bash
ifconfig
```

![](https://blog.lc044.love/static/img/504c3ac164c90ba4ac51b24028cf42b8.image.webp)

这里网卡显示为zttddzk7rq，全拼写成 net_zttddzk7rq

+ 磁盘查看方式

```bash
lsblk
```

‍选择数据库数据存储目录所挂载的磁盘，这里显示整个根目录(/)都挂载到sdc磁盘了，所以磁盘名为blk_sdc


![](https://blog.lc044.love/static/img/145a75168cf11da30c2e518d6bece8d4.image.webp)

+ 如果服务器ssh用的不是默认端口需要修改benchmarksql-5.0/src/OSCollector/OSCollector.java文件修改之后需要重新编译

![](https://blog.lc044.love/static/img/2c13b2ee78ddf6baaf8d363ab89c4680.image.webp)
```bash
    if (sshAddress != null)
    {
        cmdLine.add("ssh");
        // cmdLine.add("-t");
        cmdLine.add(sshAddress);
        cmdLine.add("-p 2222");
    }
```

## 三、开始测试
### 3.1 生成测试数据。
```bash
cd ~/benchmarksql-5.0/run
./runDatabaseBuild.sh props.opengauss
```


![](https://blog.lc044.love/static/img/8fa84a2001acb481a59ea1913e279e0c.image.webp)

### 3.2 压力测试
```bash
 ./runBenchmark.sh props.opengauss
```


![](https://blog.lc044.love/static/img/74c21fb90984c76f9ba03e19fe56296e.image.webp)

　　测试完成之后会在当前目录下生成测试结果，位于./my_result_xxxx-xx-xx_xxxx文件夹下

![](https://blog.lc044.love/static/img/f22b7bbe6a18732a9ed5addd5bec895c.image.webp)

### 3.3 生产压测报告
　　该操作需要安装R语言的环境，生成报告之前需要检查一下R语言环境是否存在。

```bash
R --version
```

![](https://blog.lc044.love/static/img/1b9728f7849bf4c8b199c502cefa001b.image.webp)

　　如果没有R语言环境需要手动下载源码并编译

+ 生成报告

```bash
cd benchmarksql-5.0/run
./generateGraphs.sh my\_result\_2023-xx-xx\_xxxxxx
./generateReport.sh my\_result\_2023-xx-xx\_xxxxxx
```

+ 生成图片


![](https://blog.lc044.love/static/img/c337035e2395ef8dde4c8f63e5332ed9.image.webp)

+ 生成报告

![](https://blog.lc044.love/static/img/dbe90ccc987abda315b1dfcf5e211789.image.webp)

　　下载my_result_2023-05-04_142051文件夹到桌面，使用浏览器打开文件夹内的report.html文件


![](https://blog.lc044.love/static/img/2c735fc9a0f1c87b7cf60d050cbeeb71.image.webp)

### 3.4 清理数据
　　该操作会将数据库仓库全部删除，再次测试需要重新创建数据

```bash
./runDatabaseDestroy.sh props.opengauss
```

## 四、其他说明
### 4.1 修改openGauss监听地址
　　默认配置只能本机连接数据库，为了不影响性能，TPCC客户端尽量不要跟数据库在同一台机器上，此时需要修改数据库的配置以便局域网内的其他设备可以连接。

　　找到数据库的数据目录

1. **编辑** ****`pg_hba.conf`**** **配置文件** 添加连接配置

```bash
host    all             all             172.19.0.0/16            sha256
```

2. 编辑`postgresql.conf`文件 编辑配置文件，将：

```properties
listen_addresses = 'localhost'  # 或默认只监听127.0.0.1
```

 修改为：

```properties
listen_addresses = '*'  # 允许监听所有网络接口（包括局域网IP）
```

 也可以指定具体的局域网 IP（如`172.19.0.209`），但`*`更灵活。

3. 重启数据库

### 4.2 日志配置
　　benchmarksql-5.0/run/log4j.properties文件是日志文件的配置信息，可以修改这个配置将不同的日志输出到不同的文件里，方便后续解析日志信息

```plain
# log4j.rootLogger=TRACE, CONSOLE, E, T
log4j.rootLogger=DEBUG, CONSOLE, E, FILE  # 日志记录器的名称

log4j.appender.CONSOLE=org.apache.log4j.ConsoleAppender
log4j.appender.CONSOLE.Threshold=INFO
log4j.appender.CONSOLE.layout=org.apache.log4j.PatternLayout
log4j.appender.CONSOLE.layout.ConversionPattern= %d{HH:mm:ss,SSS} [%t] %-5p %x %C{1} : %m%n

log4j.appender.E=org.apache.log4j.RollingFileAppender
log4j.appender.E.Threshold=WARN
log4j.appender.E.File=benchmarksql-error.log
log4j.appender.E.MaxFileSize=100MB
log4j.appender.E.MaxBackupIndex=1
log4j.appender.E.layout=org.apache.log4j.PatternLayout
log4j.appender.E.layout.ConversionPattern= %d{HH:mm:ss,SSS} [%t] %-5p %x %C{1} : %m%n

log4j.appender.T=org.apache.log4j.FileAppender
log4j.appender.T.Threshold=TRACE
log4j.appender.T.File=benchmarksql-trace.log
log4j.appender.T.append=false
log4j.appender.T.layout=org.apache.log4j.PatternLayout
log4j.appender.T.layout.ConversionPattern= %d{HH:mm:ss,SSS} [%t] %-5p %x %C{1} : %m%n

# 文件输出配置
log4j.appender.FILE=org.apache.log4j.FileAppender   # 将日志写入文件里
log4j.appender.FILE.Threshold=DEBUG   # 日志的级别
log4j.appender.FILE.File=benchmarksql-debug.log   # 日志文件名
log4j.appender.FILE.DatePattern='.'yyyyMMdd_HHmmss
log4j.appender.FILE.Append=false   # true：不清空文件直接追加到文件末尾，false：先清空文件再写日志
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c - %m%n
```

### 4.3 统计内存占用
　　下面的配置可以将debug日志输出到benchmarksql-debug.log文件里

```plain
# 文件输出配置
log4j.appender.FILE=org.apache.log4j.FileAppender   # 将日志写入文件里
log4j.appender.FILE.Threshold=DEBUG   # 日志的级别
log4j.appender.FILE.File=benchmarksql-debug.log   # 日志文件名
log4j.appender.FILE.DatePattern='.'yyyyMMdd_HHmmss
log4j.appender.FILE.Append=false   # true：不清空文件直接追加到文件末尾，false：先清空文件再写日志
log4j.appender.FILE.layout=org.apache.log4j.PatternLayout
log4j.appender.FILE.layout.ConversionPattern=%d{yyyy-MM-dd HH:mm:ss} %-5p %c - %m%n
```

　　修改benchmarksql-5.0/src/client/jTPCC.java的最后一个函数，在倒数第三行添加`log.debug(informativeText);`就能将统计信息写入日志里

```java
synchronized private void updateStatusLine()
    {
    long currTimeMillis = System.currentTimeMillis();

    if(currTimeMillis > sessionNextTimestamp)
    {
        StringBuilder informativeText = new StringBuilder("");
        Formatter fmt = new Formatter(informativeText);
        double tpmC = (6000000*fastNewOrderCounter/(currTimeMillis - sessionStartTimestamp))/100.0;
        double tpmTotal = (6000000*transactionCount/(currTimeMillis - sessionStartTimestamp))/100.0;

        sessionNextTimestamp += 1000;  /* update this every seconds */

        fmt.format("Term-00, Running Average tpmTOTAL: %.2f", tpmTotal);

        /* XXX What is the meaning of these numbers? */
        recentTpmC = (fastNewOrderCounter - sessionNextKounter) * 12;
        recentTpmTotal= (transactionCount-sessionNextKounter)*12;
        sessionNextKounter = fastNewOrderCounter;
        fmt.format("    Current tpmTOTAL: %d", recentTpmTotal);

        long freeMem = Runtime.getRuntime().freeMemory() / (1024*1024);
        long totalMem = Runtime.getRuntime().totalMemory() / (1024*1024);
        fmt.format("    Memory Usage: %dMB / %dMB          ", (totalMem - freeMem), totalMem);

        System.out.print(informativeText);
        log.debug(informativeText);
        for (int count = 0; count < 1+informativeText.length(); count++)
        System.out.print("\b");
    }
    }
```

　　修改之后需要重新编译

```java
cd bencmarksql-5.0/
ant
```

　　可以写一个简单的脚本解析日志文件的内存占用情况

```java
2025-09-16 12:35:27 DEBUG jTPCC - Term-00, Running Average tpmTOTAL: 59875.17    Current tpmTOTAL: 39209184    Memory Usage: 333MB / 915MB 
```

　　新建一个Python文件：run/misc/memory.py 写入下面内容

```python
import re
import pandas as pd
import matplotlib.pyplot as plt
import os
import sys

def main():
    # 检查命令行参数
    if len(sys.argv) != 2:
        print("用法: python memory_usage_plot.py <日志文件路径>")
        sys.exit(1)
    
    # 获取命令行输入的日志文件路径
    log_file = sys.argv[1]
    
    # 验证文件是否存在
    if not os.path.exists(log_file):
        print(f"错误: 文件 '{log_file}' 不存在")
        sys.exit(1)
    
    # 用来存储数据
    timestamps = []
    used_mem = []
    total_mem = []
    
    # 匹配日志中时间和 Memory Usage
    pattern = re.compile(r"(\d{4}-\d{2}-\d{2} \d{2}:\d{2}:\d{2}).*Memory Usage: (\d+)MB / (\d+)MB")
    
    with open(log_file, "r") as f:
        for line in f:
            match = pattern.search(line)
            if match:
                timestamps.append(match.group(1))
                used_mem.append(int(match.group(2)))
                total_mem.append(int(match.group(3)))
    
    if not timestamps:
        print("警告: 未在日志文件中找到任何内存使用记录")
        sys.exit(0)
    
    # 构建 DataFrame
    df = pd.DataFrame({
        "timestamp": pd.to_datetime(timestamps),
        "used_mb": used_mem,
        "total_mb": total_mem
    })
    
    # 计算相对时间（分钟），从0开始
    start_time = df["timestamp"].iloc[0]
    df["minutes_since_start"] = (df["timestamp"] - start_time).dt.total_seconds() / 60
    
    # 绘制曲线
    plt.figure(figsize=(12, 6))
    plt.plot(df["minutes_since_start"], df["used_mb"], label="Used Memory (MB)", color="blue")
    plt.plot(df["minutes_since_start"], df["total_mb"], label="Total Memory (MB)", color="orange", linestyle="--")
    plt.xlabel("Minutes Since Start")
    plt.ylabel("Memory (MB)")
    plt.title("BenchmarkSQL Memory Usage Over Time")
    plt.legend()
    plt.grid(True)
    plt.tight_layout()
    
    # 获取日志文件所在目录
    log_dir = os.path.dirname(log_file)
    # 构建图片保存路径（与日志文件同目录）
    image_path = os.path.join(log_dir, "memory_usage_curve.png")
    
    # 保存图片
    plt.savefig(image_path, dpi=150)
    print(f"曲线已保存为 {image_path}")

if __name__ == "__main__":
    main()

```

　　运行脚本：

```python
python ./misc/memory benchmark-debug.log
```

　　此时就会在benchmark-debug.log所在的目录下生成一个内存占用图（memory_usage_curve.png）

![](https://blog.lc044.love/static/img/f8f7445b81741e9cc5d4d8069cbd57ae.image.webp)


## 五、自动化测试脚本


```bash
sh runTpcc.sh -a -c -w 200 -n 3
```

### 5.1 参数说明

* -a: 开启ATF，默认不开启
* -c: 重建数据仓，默认不重建（相关细节在server.sh里）
* -w k: 数据仓大小（仅支持200、400、1000），默认为200
* -n k: 连续测试k次，默认为1
* -m jvm_max_mem: 限制JVM最大堆内存，默认不限制

### 5.2 前置准备
1. 修改props.* 文件里的连接参数
2. 打开server.sh，根据教程修改下面几个变量

```bash
# 远程服务器信息 - 请根据实际情况修改以下信息

remote_server="zhousk@192.168.200.209"

# 远程服务器用户名和主机地址，例如：root@192.168.1.100，需要与本机设置互信

db_dir="/mnt/nvme2n1/zhousk/data/data_n1"
TABSPACE2_DIR="/mnt/nvme3n1/zhousk/data/data_n1"
TABSPACE3_DIR="/mnt/nvme4n1/zhousk/data/data_n1"

XLOG_DIR="/mnt/raid0/zhousk/data/data_n1/pg_xlog"

backup_dir="/mnt/nvme4n1/zhousk/backup/${warehouses}w"
```

1. benchmarksql测试机与数据库服务器配置互信

2. 创建原始数据，根据[教程](../README.md)分别生成仓数为100、200、1000的数据库，分别将整个数据库目录备份到backup_dir文件夹下

    例如：100仓的数据库目录为/mnt/nvme4n1/zhousk/backup/100w

3. 数据分盘，在不同硬盘上分别创建以下四个文件夹并把实际目录写到server.sh文件里

    * db_dir：测试数据库数据目录
    * TABSPACE2_DIR：数据表空间的软连接地址（在其他磁盘上）
    * TABSPACE3_DIR：另一个数据表空间的软连接地址
    * XLOG_DIR：xlog软连接地址

> PS: 为避免数据干扰每次测试前都会，删除四个文件夹下的数据然后将对应仓数的备份数据复制到db_dir下，然后创建四个软连接将数据分散到多个硬盘上

### 5.3 查看报告

使用`runTpcc.sh`之后每次测试完成之后都会在结果文件夹下生成一个 `report.html`, 需要将整个文件夹下载到本地才能查看，比较麻烦。

`app.py` 提供了一个网络服务器，可以通过浏览器查看测试报告

#### 5.4 使用方法

```bash
python3 app.py
```

在浏览器打开 `http://ip:8000` （ip为benchmarksql的ip地址）来查看报告


![](https://blog.lc044.love/static/img/a703e4c2df27f6b8258bd4db7d895a04.image.webp)

### 5.5 源代码

[https://github.com/LC044/BenchmarkSQL](https://github.com/LC044/BenchmarkSQL)
　　‍



TPCC测试方法—benchmarksql

## 一、了解 PaddleOCR

在当今数字化时代，数据安全与便捷性愈发受到重视。许多企业与个人在处理文档、图片等数据时，对文字识别有着强烈需求，却担忧数据在云端处理时的隐私泄露风险。



PaddleOCR 的私有部署方案应运而生，它允许用户将文字识别服务搭建在本地环境，极大地增强了数据的隐私性。通过在私有服务器或本地设备上部署，企业敏感文件、个人私密文档等无需上传至外部云端，有效避免了数据在传输与存储过程中的泄露风险。同时，私有部署带来了使用上的便利性，无需依赖不稳定的网络连接，用户可随时随地快速调用 OCR 服务，实现对各类文档的高效处理，提升工作效率。


PaddleOCR 是百度基于飞桨深度学习框架研发的一款开源 OCR 工具，旨在打造一套丰富、领先且实用的 OCR 工具库，打通数据准备、模型训练、压缩和推理部署的全流程。它采用深度学习技术，先对图片进行缩放、灰度化、去噪等预处理操作，以提高文字识别的准确率。接着，运用深度学习模型检测图片中的文字区域，并将其转换为电脑可识别的边界框。最后，利用另一个深度学习模型识别边界框中的文字，将其转化为电脑可识别的文本。接下来，我们将详细介绍如何使用 Docker 在本地进行 PaddleOCR 的部署，让您轻松搭建属于自己的高效文字识别系统。


## 二、使用 Docker 部署 PaddleOCR

### （一）配置Dockerfile文件

创建文件名为`Dockerfile`的文件。

参考官方的[安装教程](https://www.paddleocr.ai/main/version3.x/installation.html)可以直接从官方的镜像源拉取paddlepaddle镜像，然后下载paddleocr以及部署paddleocr需要的paddlex，安装完成之后接着使用paddleocr命令执行一次文字识别，该操作是为了初始化模型，会从官方直接下载模型文件。最后通过`paddlex`服务化部署paddleocr，可以通过https服务调用ocr接口。

```dockerfile
FROM ccr-2vdh3abv-pub.cnc.bj.baidubce.com/paddlepaddle/paddle:3.0.0

# 切换工作目录
WORKDIR /paddle

# # 安装 PaddleOCR 和 PaddleX 依赖
# RUN pip install paddlex
RUN pip install paddlex[ocr-core]
RUN paddlex --install serving
RUN paddleocr ocr -i https://paddle-model-ecology.bj.bcebos.com/paddlex/imgs/demo_image/general_ocr_002.png \
    --use_doc_orientation_classify False \
    --use_doc_unwarping False \
    --use_textline_orientation False

# 默认命令：启动 PaddleX OCR 服务
CMD ["paddlex", "--serve", "--pipeline", "OCR"]
```

在 Dockerfile 所在目录执行：

```bash
docker build -t paddleocr:1.0 .
```

运行容器

```bash
docker run -d -p 9080:8080 --name paddleocr paddleocr:1.0
```

此时paddleocr服务就运行成功了，日志会输出以下内容


![image.png](https://blog.lc044.love/static/img/296cced381b433c61a2a54ffc604e25b.image.webp)

然后可以通过三、测试与验证来测试ocr效果，如果需要使用docker compose 部署可以参考下面内容。

### （二）配置Docker Compose 文件

创建docker-compose.yaml文件，然后把上面的`Dockerfile`文件和docker-compose.yaml文件放在一个文件夹下。

```yaml
services:
  paddleocr:
    build: .
    container_name: paddleocr
    stdin_open: true
    tty: true
    restart: always #重启策略
    volumes:
      - ./:/paddle
    shm_size: "8g"
    ports:
      - "9090:8080"   # 映射宿主机端口到容器
```

在docker-compose.yml所在目录执行：

```bash
docker-compose up -d  # -d表示后台运行
```

### （三）在绿联NAS上部署

#### 使用 Docker Compose 部署容器

在 UGOS Pro 系统上，推荐使用项目 Docker Compose 快速部署容器，适合需同时管理多个容器的场景，这种方法简化了容器的部署与管理工作。以下是使用 Docker Compose 部署 paddleocr 的详细步骤。

#### 在docker目录下创建一个空文件夹 paddleocr

将上面的`Dockerfile`和Docker Compose 配置文件上传到该文件夹。

#### 进入 Docker 项目界面

在 UGOS Pro 系统中，打开 Docker 应用，点击【项目】 \> 【创建】，启动项目创建向导。

#### 配置 Docker Compose 文件

在项目创建向导中，选择存放路径为前面创建的paddleocr文件夹，导出docker compose配置，点击`立即部署`，系统会自动拉取镜像并启动容器。

部署完成后执行下面的测试脚本。

## 三、测试与验证

### （一）运行测试案例

部署完成后，就可以对 PaddleOCR 进行测试了。我们先准备一张简单的测试图片，比如一张写有 “欢迎使用 PaddleOCR” 的白底黑字图片，假设图片名为 “test.jpg” 。

接下来，通过命令行或编写 Python 脚本来进行测试。如果使用 Python 脚本，可以按照以下步骤进行：

1. 打开文本编辑器，创建一个新的 Python 文件，比如 “[test_ocr.py](http://test_ocr.py)”。
2. 在文件中编写以下代码：

```Python
import base64
import requests

API_URL = "http://192.168.1.113:9090/ocr"

def ocr(image_path):
    with open(image_path, "rb") as file:
        file_bytes = file.read()
        file_data = base64.b64encode(file_bytes).decode("ascii")

    payload = {"file": file_data, "fileType": 1}

    response = requests.post(API_URL, json=payload)

    assert response.status_code == 200
    result = response.json()["result"]
    for i, res in enumerate(result["ocrResults"]):
        print(res["prunedResult"])
        ocr_img_path = f"ocr_{i}.jpg"
        with open(ocr_img_path, "wb") as f:
            f.write(base64.b64decode(res["ocrImage"]))
        print(f"Output image saved at {ocr_img_path}")
    return result

# 使用示例
if __name__ == "__main__":
    # 原始图片路径
    input_image_path = "./data/test.jpg"
    import time
    st = time.time()
    # 使用优化后的图片进行OCR识别
    result = ocr(output_image_path)
    et = time.time()
    for i, res in enumerate(result["ocrResults"]):
        # 打印识别结果
        print(res["prunedResult"]['rec_texts'])
    print(f'耗时：{et-st:.1f}s')

```

3. 保存文件，然后在命令行中运行该脚本。如果你的 Python 环境已经配置好，在命令行中进入到 “[test_ocr.py](http://test_ocr.py)” 所在的目录，运行命令 “python [test_ocr.py](http://test_ocr.py)” ，脚本就会读取图片，将其转换为 base64 编码后发送给 PaddleOCR 服务，并接收返回的识别结果。

### （二）检查识别结果

运行测试脚本后，我们需要检查识别结果是否准确。在脚本的输出中，会看到类似以下的内容：

```json
{'model_settings': {'use_doc_preprocessor': True, 'use_textline_orientation': True}, 'doc_preprocessor_res': {'model_settings': {'use_doc_orientation_classify': True, 'use_doc_unwarping': True}, 'angle': 0}, 'dt_polys': [[[49, 22], [96, 20], [98, 46], [51, 49]], [[51, 71], [98, 71], [98, 100], [51, 100]], [[51, 122], [98, 122], [98, 148], [51, 148]], [[53, 173], [99, 173], [99, 200], [53, 200]], [[51, 224], [98, 224], [98, 251], [51, 251]], [[49, 273], [99, 276], [97, 304], [47, 304]]], 'text_det_params': {'limit_side_len': 64, 'limit_type': 'min', 'thresh': 0.3, 'max_side_limit': 4000, 'box_thresh': 0.6, 'unclip_ratio': 1.5}, 'text_type': 'general', 'textline_orientation_angles': [0, 0, 0, 0, 0, 0], 'text_rec_score_thresh': 0.0, 'return_word_box': False, 'rec_texts': ['桌面', '下载', '文档', '图片', '音乐', '视频'], 'rec_scores': [0.99993896484375, 0.9999144673347473, 0.9977823495864868, 0.9996212720870972, 0.9995757937431335, 0.9998965859413147], 'rec_polys': [[[49, 22], [96, 20], [98, 46], [51, 49]], [[51, 71], [98, 71], [98, 100], [51, 100]], [[51, 122], [98, 122], [98, 148], [51, 148]], [[53, 173], [99, 173], [99, 200], [53, 200]], [[51, 224], [98, 224], [98, 251], [51, 251]], [[49, 273], [99, 276], [97, 304], [47, 304]]], 'rec_boxes': [[49, 20, 98, 49], [51, 71, 98, 100], [51, 122, 98, 148], [53, 173, 99, 200], [51, 224, 98, 251], [47, 273, 99, 304]]}
```

在这个结果中，“rec_texts” 字段就是识别出的文本内容，我们可以将其与图片中的实际文字进行对比，判断识别是否准确。这里识别出的 “欢迎使用 PaddleOCR” 与图片内容一致，说明识别是正确的。“rec_scores” 字段表示识别结果的置信度，取值范围是 0 到 1，越接近 1 表示置信度越高，识别结果越可靠，这里的置信度为 0.9987，说明识别结果的可信度很高。“dt_polys” 字段表示文字在图片中的位置，以四边形的四个顶点坐标来表示，通过这些坐标可以在图片上绘制出文字的位置框，进一步验证识别的准确性。如果识别结果不准确，可能是由于图片质量不佳、模型不匹配、参数设置不当等原因导致的，可以尝试对图片进行预处理、更换模型或调整参数来提高识别准确率。

### 

未来，PaddleOCR 在绿联 NAS 上的私有部署应用前景极为广阔，其强隐私性与便利性将进一步凸显。在文档处理方面，结合自动化脚本和其他办公工具，能够实现文档的自动分类、内容提取和关键词检索。例如，将 PaddleOCR 与 Python 的办公库相结合，当新文档存入绿联 NAS 时，可自动触发 PaddleOCR 进行文字识别，随后依据识别内容将文档分类至不同文件夹，大幅提升文档管理效率，且整个过程数据始终在本地，隐私安全得以保障。在图像分析领域，与图像识别技术结合，可实现对图片中文字和物体的同时识别与分析，应用于安防监控中的文字标识识别、智能相册中的文字信息提取等场景，让用户在本地即可快速处理分析图像，无需等待网络传输与云端处理。此外，还可探索 PaddleOCR 在多语言环境下的自动化翻译流程，将识别出的文字快速翻译成多种语言，满足跨国交流和文档处理的需求，全程在私有环境内运行，数据安全无虞。相信随着技术的不断发展和探索，PaddleOCR 在绿联 NAS 上的私有部署会发挥出更大价值，为我们的工作和生活带来更多便利与创新，在保障隐私的同时，提供高效、便捷的文字识别解决方案。

绿联NAS+Docker：解锁PaddleOCR高效文字识别新姿势

# openGauss通信协议
　客户端可以通过两种 "子协议" 来发送请求，分别是 `simple query` 和 `extened query`。使用 `simple query` 时，客户端发送字符串文本请求，后端收到后立即处理并返回结果（gsql）；使用 `extened query` 时，发送请求的过程被分为若干步骤，通常包括 Parse，Bind ， Execute和Sync。本文主要关注 `extened query`。
 
## 一、消息格式
　　客户端和服务端所有通信都通过消息流进行。消息的第一个字节标识消息类型，随后四个字节标识消息内容的长度（该长度包括这四个字节本身），具体的消息内容由消息类型决定。

![](https://blog.lc044.love/static/img/972f04fedcb2afc606c674868bc982e1.image.webp)

　　openGauss 目前支持如下客户端消息类型：

```c++
switch (qtype) {
        case 'a': /* Not reach : Trigger shipped to DN */
        case 'A': /* AC WLM */
        case 'b': /* Barrier */
        case 'B': /* bind */
        case 'c': /* copy done */
        case 'C': /* close */
        case 'D': /* describe */
        case 'd': /* copy data */
        case 'e': /* Thread ID */
        case 'E': /* execute */
        case 'f': /* copy fail */
        case 'F': /* fastpath function call */
        case 'g': /* GXID */
        case 'G': /* PGXCBucketMap and PGXCNodeId */
        case 'h': /* hybrid message query */
        case 'H': /* flush */
        case 'i': /* Instrumentation */
        case 'I': /* Push, Pop schema name */
        case 'j': /* Check gtm mode */
        case 'J': /* Trace ID */
        case 'k': /* Global session ID */
        case 'K': /* client conn driver net_time */
        case 'l': /* get and handle csn for csnminsync */
        case 'L': /* Link gc_fdw */
        case 'M': /* Command ID */
        case 'n': /* Committing */
        case 'N': /* Commit csn */
        case 'o': /* role name */
        case 'O': /* to reset openGauss thread in pooler stateless reuse mode */
        case 'p': /* Process Pid */
        case 'P': /* parse */
        case 'q': /* Query ID */
        case 'Q': /* simple query */
        case 'r': /* Plan ID with sync */
        case 'R': /* Reply collect info */
        case 's': /* Snapshot */
        case 'S': /* sync */
        case 't': /* Timestamp */
        case 'T': /* consistency point */
        case 'u': /* AUTONOMOUS_TRANSACTION simple query */
        case 'U': /* batch bind-execute */
        case 'V': /* client conn driver support trace info*/
        case 'W': /* WLM Control Group */
        case 'w': /* dynamic WLM */
        case 'x': /* imcs populate query */
        case 'X': /* terminate */
        case 'y': /* sequence from cn 2 dn */
        case 'Y': /* plan with params */
        case 'z': /* PBE for DDL */
        case 'Z': /* simple plan  */
        default:
            break;
}
```

　　服务端收到如上消息的处理流程可以参考 [PostgresMain](https://github.com/postgres/postgres/blob/bf68b79e50e3359accc85c94fa23cc03abb9350a/src/backend/tcop/postgres.c#L4277)。服务端发送给客户端的消息有如下类型（不完全）：

```java
switch (c) {
          case 'K': //receive dbTime
          case 'A': // Asynchronous Notify
          case '1': // Parse Complete (response to Parse)
          case 't': // ParameterDescription
          case '2': // Bind Complete (response to Bind)
          case '3': // Close Complete (response to Close)
          case 'n': // No Data (response to Describe)
          case 's':  // Portal Suspended (end of Execute)
          case 'C':  // Command Status (end of Execute)
          case 'D': // Data Transfer (ongoing Execute response)
          case 'E': // Error Response (response to pretty much everything; backend then skips until Sync)
          case 'I':  // Empty Query (end of Execute)
          case 'N': // Notice Response
          case 'S': // Parameter Status
          case 'Z': // Ready For Query (eventual response to Sync)
          case 'G': // CopyInResponse
          case 'H': // CopyOutResponse
          case 'c': // CopyDone
          case 'd': // CopyData
          default:
            throw new IOException("Unexpected packet type: " + c);
}
```

　　客户端处理如上服务端消息的流程可以参考 PostgreSQL libqp 的实现 [pqParseInput3](https://github.com/postgres/postgres/blob/c9d29775195922136c09cc980bb1b7091bf3d859/src/interfaces/libpq/fe-protocol3.c#L63)。

　　openGauss 通信协议包括两个阶段： `startup` 阶段和常规 `normal` 阶段。 `startup` 阶段，客户端尝试创建连接并发送授权信息，如果一切正常，服务端会反馈状态信息，连接成功创建，随后进入 `normal` 阶段。 `normal` 阶段，客户端发送请求至服务端，服务端执行命令并将结果返回给客户端。客户端请求结束后，可以主动发送消息断开连接。

　　`normal` 阶段，客户端可以通过两种 "子协议" 来发送请求，分别是 `simple query` 和 `extened query`。使用 `simple query` 时，客户端发送字符串文本请求，后端收到后立即处理并返回结果（gsql）；使用 `extened query` 时，发送请求的过程被分为若干步骤，通常包括 Parse，Bind ， Execute和Sync。

## 二、**Extended Query 处理流程**
　　在 openGauss 中，**Extended Query（扩展查询，JDBC默认协议）**  是一种通过多个步骤拆分 SQL 执行过程的协议，主要用于参数化查询，能有效避免 SQL 注入、提升重复执行效率。**Extended Query** 不允许在一个请求中包含多条 SQL 命令，否则会报语法错误 **（** Extended Query模式下**JDBC会自动拆分一条语句的多个SQL）** 。Extended Query 协议通常包括 5 个步骤，分别是 Parse，Bind，Describe（可选），Execute 和 Sync。以下分别介绍各个阶段的处理流程。


![](https://blog.lc044.love/static/img/8d23abc8e2cb8fc345b650af5caea21e.image.webp)

### 2.1. Parse（解析）：生成语法树
+ **作用**：客户端发送不带参数的 SQL 模板（如`SELECT * FROM users WHERE id = $1`），服务端收到该消息后，调用 `exec_parse_message` 函数进行处理，进行语法分析、语义分析和重写，同时会创建一个 Plan Cache 的结构，用于缓存后续的执行计划。![](https://blog.lc044.love/static/img/374335e5ca95978cf7fb24998256ef5b.image.webp)
+ **关键操作**：
    - 检查 SQL 语法是否正确（如关键字拼写、语句结构）。
    - 验证表、列等对象是否存在（语义校验）。
    - 生成解析树，存储在服务器的内存中，并返回一个**Parse Complete**消息（包含解析树的标识，如`Portal`或`Statement` ID）。
+ **示例**：客户端发送`Parse("SELECT * FROM users WHERE id = $1")`，服务器返回解析成功的确认。


### 2.2. Bind（绑定）：关联参数与执行计划
+ **作用**：客户端发送参数值（如`$1 = 123`），服务器将参数与解析树绑定，生成**执行计划**（Execution Plan）。openGauss 收到该消息后，调用 `exec_bind_message` 函数进行处理。为之前保存的 Prepared Statement 创建执行计划并将其保存在 Plan Cache 中，创建一个 `Portal` 用于后续执行。

> 在 openGauss 内核中，Portal 是对查询执行状态的一种抽象，该结构贯穿执行器运行的始终。
>


![](https://blog.lc044.love/static/img/b1071543ff660a21bb7818bcee366078.image.webp)

+ **关键操作**：
    - 校验参数类型是否与表字段匹配（如`id`是整数，`$1`不能是字符串）。
    - 基于参数值和数据库统计信息（如索引分布），优化器生成最优执行计划（如选择索引扫描还是全表扫描）。
    - 生成一个**Portal**（可理解为 “执行上下文”），包含绑定后的执行计划，返回`Bind Complete`消息。
+ **示例**：客户端发送`Bind(参数: [123])`，服务器将`123`与`$1`绑定，生成针对`id=123`的执行计划。

### 2.3. Execute（执行）：执行查询并返回结果
+ **作用**：客户端触发执行已绑定的 Portal，服务器执行执行计划，返回结果。`Execute` 消息中可以指定返回的行数，若行数为 0，表示返回所有行。

![](https://blog.lc044.love/static/img/a4ac10ef0d479f546b0db9c2dce70c53.image.webp)

+ **关键操作**：
    - 按照执行计划执行数据操作（如查询、插入、更新）。
    - 若为查询语句，将结果集分批返回给客户端（可通过`Fetch`控制返回行数）。
    - 若为写操作（如`INSERT`），执行事务日志记录和数据页更新。
+ **示例**：客户端发送`Execute(Portal ID)`，服务端收到消息后，执行 `Bind` 阶段创建的 Portal，执行结果通过 `DataRow` 消息返回给客户端，执行完成后发送 `CommandComplete`消息。![](https://blog.lc044.love/static/img/eabdbf92439790ba803eb73d486b32f8.image.webp)msg示例：INSERT 0 1

### 2.4. Sync（同步）：结束当前查询流程
+ **作用**：客户端发送`Sync`消息，服务器清理本次查询的资源，结束当前会话的查询流程。
+ **关键操作**：
    - 释放 Portal 占用的内存资源（解析树、执行计划等）。
    - 向客户端返回`ReadyForQuery`消息，表明当前会话处于 “就绪状态”，可接收新的查询。
+ **示例**：客户端发送`Sync`，服务器清理资源，等待下一次查询请求。

### 2.5. 批量管线与 Sync
　　对于一次执行的多条SQL语句，JDBC会自动将语句拆分成多个单独的SQL语句，每条SQL语句都独立执行Parse/Bind/Describe/Execute流程

```java
String sql = "INSERT INTO users (name, age) VALUES ('Alice', 30);select * from users where age=?;select * from users;select * from users;select * from users;select * from users;";
PreparedStatement pstmt = conn.prepareStatement(sql);
pstmt.setInt(1, 30); 
pstmt.execute();
```

![](https://blog.lc044.love/static/img/594959d0e43911a5328a1e042779f1bf.image.webp)

+ 为了减少往返延迟，JDBC 驱动通常将多条语句的 Parse/Bind/Describe/Execute 消息依次**排队发送**（pipelining），而不是一次一收一发，如果数据量小的话仅需一次RTT即可完成通信。
+ 当所有语句对应的 Execute 都发出后，客户端发送一个 **Sync** 消息，表示“这一批所有命令都发完了，请一次性返回结果，最后给我一个 ReadyForQuery”。
+ **服务器 → 客户端**
    - 按照收到的命令顺序依次返回 ParseComplete、BindComplete、RowDescription（若有）、DataRow、CommandComplete……
    - 在最后，返回 **ReadyForQuery**，表示事务状态可查（空闲/活动/回滚），客户端可开始下一次交互。

　　‍



openGauss通信协议

👨🏻‍💻这是一个充满知识💬的链接，快点进来看看你的好友给你分享了什么干货吧❣️