Skip to content

Commit a32e728

Browse files
CerulimeCerulime
committed
IMPORTANT REPL and report
1 parent c651914 commit a32e728

File tree

7 files changed

+74640
-6
lines changed

7 files changed

+74640
-6
lines changed

‎.gitignore

Lines changed: 2 additions & 1 deletion
Original file line numberDiff line numberDiff line change
@@ -1 +1,2 @@
1-
/build
1+
/build
2+
/report/png

‎report/config.xlsx

29 KB
Binary file not shown.

‎report/delete.sql

Lines changed: 8 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,8 @@
1+
BEGIN TRANSACTION;
2+
EXPLAIN (analyse, buffers, verbose)
3+
select count(*) from flight.flights where departure like '%DEN%';
4+
EXPLAIN (analyse, buffers, verbose)
5+
DELETE FROM flight.flights WHERE departure like '%DEN%';
6+
EXPLAIN (analyse, buffers, verbose)
7+
select count(*) from flight.flights where departure like '%DEN%';
8+
ROLLBACK;

‎report/flights.sql

Lines changed: 74367 additions & 0 deletions
Large diffs are not rendered by default.

‎report/update.sql

Lines changed: 4 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,4 @@
1+
EXPLAIN (analyse, buffers, verbose)
2+
update flight.flights set departure = 'BBC' where departure like '%DEN%';
3+
EXPLAIN (analyse, buffers, verbose)
4+
update flight.flights set departure = 'DEN' where departure like '%BBC%';

‎report/数据库管理系统性能测试实验报告.md

Lines changed: 251 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,251 @@
1+
## 数据库管理系统性能测试实验报告
2+
3+
### 1、环境简介
4+
5+
- 操作系统
6+
- 系统版本：Windows 11家庭版
7+
- 补丁版本：23H2
8+
- 内核版本：22631.2361
9+
- 部分硬件信息
10+
- 处理器：Intel Core [email protected]
11+
- RAM：DDR4 4\*64-bit 16.0 GB
12+
- 内存频率：2133MHz
13+
- 内存CAS Latency：36
14+
- 硬盘性能：32MiB负载单线程随机4K读 25MB/s 写 80MB/s
15+
- 数据库管理系统
16+
- Postgresql-x64-16rc1
17+
- 配置文件：[config.xlsx](./config.xlsx)
18+
- 数据库客户端
19+
- Datagrip-2023.2.1
20+
- 程序开发环境
21+
- 项目名称：TinyDB
22+
- 编译套件：GCC 8.1.0 x86_64-w64-mingw32
23+
- 自动化构建工具：CMake 3.27.0
24+
- 语言标准：C++17
25+
26+
### 2、背景
27+
28+
#### 数据集
29+
30+
使用 [flights.sql](./flights.sql) SQL脚本构建。选择该数据集的原因如下：此数据集只有一张表，另外两个数据集films和shenzhen\_metro有超过一张表，且存在外键等更多约束条件，TinyDB无法支持这些特性。因此为了控制变量确定DBMS的性能优势，故选择较为简洁的数据集。
31+
32+
#### 性能测试项目
33+
34+
在TinyDB的底层实现中，重点操作是插入、查找、删除。我基于现实需求，判定该数据集的工作负荷是查询密集型，因此对模糊查询功能有针对性优化，精确查询的复杂度与模糊查询基本一致。在DBMS的执行计划中，该数据集对模糊查询和精确查询的查询逻辑并无较大差别，因此对查询功能的测试选择模糊查询。
35+
36+
从数据库操作命令角度看，性能测试涉及的命令有以下部分：
37+
38+
```sql
39+
INSERT INTO flights (departure, arrival, day_op, dep_time, carrier, airline, flightnum, duration, aircraft) VALUES ('ACC', 'AMS', '1234567', '21:50', 'KL', 'KL', 590, 420, '330');
40+
DELETE FROM flights WHERE departure like '%DEN%';
41+
UPDATE flights set departure = 'BBC' WHERE departure like '%DEN%';
42+
SELECT COUNT(*) FROM flights WHERE departure like '%DEN%' or arrival like '%DEN%';
43+
```
44+
45+
测试项目解释：
46+
47+
注1：由于个人计算机对性能测试的不稳定因素过多，包括但不限于：处理器性能波动、操作系统调度进程优先级差异、内存频率波动、数据库管理系统配置（例如auto）、后台其他程序的影响、单个操作的定义等。我无法精准说明每个“操作”的性能表现。因此在数据库管理系统的性能分析中，我使用自带的 `EXPLAIN` 命令分析不同语句的执行效果，所有测试结果仅对我本地数据集当时测试环境有效。虽然底层性能分析工具可以识别详细的处理器缓存命中、内存读写、硬盘读写性能，有助于分析缓冲区对DBMS的影响，但不考虑使用 Intel VTune 等处理器级别性能分析工具的原因是，我不知道DBMS的后台服务具体执行了哪些操作。我会在TinyDB的性能分析中使用此类软件，详细说明性能瓶颈。
48+
49+
注2：在刚启动数据库后台服务时，执行的第一条语句是没有缓冲区加速的。在粗略测试中，只观察语句执行结果的运行时间，无加速的查询语句的 `fetching time` 是有缓冲区加速的三倍左右，具体数值为44ms与15ms，该数据明显受到硬盘读写性能影响。我认为该数据集是作为查询平台的后端，仅管理员会进行航线的增减，因此是长期部署的查询密集型任务。对于刚启动服务的第一个查询语句性能损失并不是重点关注对象，因此在DBMS的性能分析中不会将读写硬盘的性能瓶颈作为主要考虑对象。
50+
51+
- `INSERT`
52+
53+
- `INSERT` 每次只能插入单条数据，因此在测试时会连续插入多条数据取平均值，计算单次插入的耗时。此命令仅作为单条插入的示例，实际测试的工作负荷为整张表共 $74349$ 条数据
54+
- 由于本数据集不涉及索引建立，不涉及网络延迟和多线程读写，且插入的数据结构单一，因此性能瓶颈在存储器上。鉴于数据量不超过数据库管理系统设置的缓冲区上限，可以判断RAM是主要的瓶颈。总插入执行耗时如下：
55+
> 摘要：在 19秒549毫秒中74,352/74,352 条语句已执行 (文件中有 13,010,756 个符号)
56+
57+
- `DELETE`
58+
59+
- `DELETE` 支持模糊删除，根据执行计划确定可以借此测试删除单条数据的耗时
60+
- 性能分析结果如下：
61+
```sql
62+
BEGIN TRANSACTION;
63+
EXPLAIN (analyse, buffers, verbose)
64+
select count(*) from flight.flights where departure like '%DEN%';
65+
EXPLAIN (analyse, buffers, verbose)
66+
DELETE FROM flight.flights WHERE departure like '%DEN%';
67+
EXPLAIN (analyse, buffers, verbose)
68+
select count(*) from flight.flights where departure like '%DEN%';
69+
ROLLBACK;
70+
```
71+
> Aggregate (cost=1695.19..1695.20 rows=1 width=8) (actual time=7.841..7.842 rows=1 loops=1)
72+
> Output: count(*)
73+
> Buffers: shared hit=759 dirtied=23
74+
> -> Seq Scan on flight.flights (cost=0.00..1688.36 rows=2731 width=0) (actual time=7.395..7.720 rows=2725 loops=1)
75+
> " Output: departure, arrival, day_op, dep_time, carrier, airline, flightnum, duration, aircraft"
76+
> Filter: ((flights.departure)::text ~~ '%DEN%'::text)
77+
> Rows Removed by Filter: 71624
78+
> Buffers: shared hit=759 dirtied=23
79+
> Planning Time: 0.092 ms
80+
> Execution Time: 7.866 ms
81+
>
82+
> Delete on flight.flights (cost=0.00..1688.36 rows=0 width=0) (actual time=6.066..6.066 rows=0 loops=1)
83+
> Buffers: shared hit=3484
84+
> -> Seq Scan on flight.flights (cost=0.00..1688.36 rows=2731 width=6) (actual time=4.720..5.119 rows=2725 loops=1)
85+
> Output: ctid
86+
> Filter: ((flights.departure)::text ~~ '%DEN%'::text)
87+
> Rows Removed by Filter: 71624
88+
> Buffers: shared hit=759
89+
> Planning Time: 0.056 ms
90+
> Execution Time: 6.083 ms
91+
>
92+
> Aggregate (cost=1695.19..1695.20 rows=1 width=8) (actual time=4.883..4.884 rows=1 loops=1)
93+
> Output: count(*)
94+
> Buffers: shared hit=759
95+
> -> Seq Scan on flight.flights (cost=0.00..1688.36 rows=2731 width=0) (actual time=4.880..4.880 rows=0 loops=1)
96+
> " Output: departure, arrival, day_op, dep_time, carrier, airline, flightnum, duration, aircraft"
97+
> Filter: ((flights.departure)::text ~~ '%DEN%'::text)
98+
> Rows Removed by Filter: 71624
99+
> Buffers: shared hit=759
100+
> Planning Time: 0.058 ms
101+
> Execution Time: 4.902 ms
102+
103+
- 利用事务机制回滚防止 `DELETE` 生效的同时，可以注意到几点关键性能信息
104+
105+
- 此分析是我多次执行这段语句的结果，两次查询的耗时差别较大，但顺序查询节点耗时不同。一方面是查询有数据和没有数据，另一方面是存在缓冲区数据页被污染的情况。前一个影响因素在两次运行之间等待时间较长时，会得到另一个结果：
106+
> Aggregate (cost=1695.19..1695.20 rows=1 width=8) (actual time=5.604..5.605 rows=1 loops=1)
107+
> Output: count(*)
108+
> Buffers: shared hit=759
109+
> -> Seq Scan on flight.flights (cost=0.00..1688.36 rows=2731 width=0) (actual time=5.149..5.489 rows=2725 loops=1)
110+
> " Output: departure, arrival, day_op, dep_time, carrier, airline, flightnum, duration, aircraft"
111+
> Filter: ((flights.departure)::text ~~ '%DEN%'::text)
112+
> Rows Removed by Filter: 71624
113+
> Buffers: shared hit=759
114+
> Planning Time: 0.092 ms
115+
> Execution Time: 5.645 ms
116+
>
117+
> Delete on flight.flights (cost=0.00..1688.36 rows=0 width=0) (actual time=6.104..6.105 rows=0 loops=1)
118+
> Buffers: shared hit=3484
119+
> -> Seq Scan on flight.flights (cost=0.00..1688.36 rows=2731 width=6) (actual time=4.844..5.238 rows=2725 loops=1)
120+
> Output: ctid
121+
> Filter: ((flights.departure)::text ~~ '%DEN%'::text)
122+
> Rows Removed by Filter: 71624
123+
> Buffers: shared hit=759
124+
> Planning Time: 0.057 ms
125+
> Execution Time: 6.120 ms
126+
>
127+
> Aggregate (cost=1695.19..1695.20 rows=1 width=8) (actual time=5.166..5.167 rows=1 loops=1)
128+
> Output: count(*)
129+
> Buffers: shared hit=759
130+
> -> Seq Scan on flight.flights (cost=0.00..1688.36 rows=2731 width=0) (actual time=5.162..5.162 rows=0 loops=1)
131+
> " Output: departure, arrival, day_op, dep_time, carrier, airline, flightnum, duration, aircraft"
132+
> Filter: ((flights.departure)::text ~~ '%DEN%'::text)
133+
> Rows Removed by Filter: 71624
134+
> Buffers: shared hit=759
135+
> Planning Time: 0.081 ms
136+
> Execution Time: 5.189 ms
137+
138+
- 注意到此时被污染的缓冲页面已经被写回磁盘，两次查询差别仅有数据量的不同。线性扫描节点的耗时差距为0.340ms，总时间差距为0.454ms。扫描节点的瓶颈为74.8%，统计函数的瓶颈为25.2%。而含有污染页面的耗时差距为2.964ms，可分析判定其中85%的性能耗时由23个被污染的缓冲页面所导致。
139+
- `DELETE` 操作在线性扫描节点的耗时与查询一致，额外耗时主要因为对较多缓冲区进行修改。由此可以判断，在对数据做删除操作时，性能瓶颈在缓冲区的读写性能和缓冲策略上。
140+
141+
- `UPDATE`
142+
- `UPDATE` 支持模糊更新，根据执行计划确定可以判断修改数据的耗时
143+
- 性能分析结果如下：
144+
```sql
145+
EXPLAIN (analyse, buffers, verbose)
146+
update flight.flights set departure = 'BBC' where departure like '%DEN%';
147+
EXPLAIN (analyse, buffers, verbose)
148+
update flight.flights set departure = 'DEN' where departure like '%BBC%';
149+
```
150+
> Update on flight.flights (cost=0.00..1671.81 rows=0 width=0) (actual time=9.770..9.771 rows=0 loops=1)
151+
> Buffers: shared hit=8827 dirtied=23 written=23
152+
> -> Seq Scan on flight.flights (cost=0.00..1671.81 rows=3054 width=30) (actual time=4.663..5.338 rows=2725 loops=1)
153+
> " Output: 'BBC'::character varying(5), ctid"
154+
> Filter: ((flights.departure)::text ~~ '%DEN%'::text)
155+
> Rows Removed by Filter: 71624
156+
> Buffers: shared hit=669
157+
> Planning Time: 0.080 ms
158+
> Execution Time: 9.790 ms
159+
>
160+
> Update on flight.flights (cost=0.00..1729.29 rows=0 width=0) (actual time=9.886..9.887 rows=0 loops=1)
161+
> Buffers: shared hit=8847 dirtied=22 written=22
162+
> -> Seq Scan on flight.flights (cost=0.00..1729.29 rows=81 width=30) (actual time=5.676..6.300 rows=2725 loops=1)
163+
> " Output: 'DEN'::character varying(5), ctid"
164+
> Filter: ((flights.departure)::text ~~ '%BBC%'::text)
165+
> Rows Removed by Filter: 71624
166+
> Buffers: shared hit=692
167+
> Planning Time: 0.063 ms
168+
> Execution Time: 9.905 ms
169+
170+
- 两次的顺序查询耗时分别为0.675ms和0.624ms，但总耗时接近10ms。由此可分析得知在对数据进行更新操作时，与删除操作一致，性能瓶颈在缓冲区的读写上，且查询的耗时占比在6.5%左右，可以忽略
171+
172+
- `SELECT`
173+
- 若 `SELECT` 查询的条目过多，检索数据的时间较高，即 `fetching time`。该性能指标与各级缓存的数据吞吐量相关，性能瓶颈在其他硬件上而不是数据库管理系统。根据执行计划确定，Count函数对性能没有显著影响，故使用此以减少输出数据量，减少查询外耗时
174+
175+
- 性能分析结果如下：
176+
```sql
177+
EXPLAIN (analyse, buffers, verbose) select * from flight.flights where departure like '%DEN%' or arrival like '%DEN%';
178+
EXPLAIN (analyse, buffers, verbose) select count(*) from flight.flights where departure like '%DEN%' or arrival like '%DEN%';
179+
```
180+
> Seq Scan on flight.flights (cost=0.00..1746.43 rows=5681 width=36) (actual time=0.308..9.555 rows=5576 loops=1)
181+
> " Output: departure, arrival, day_op, dep_time, carrier, airline, flightnum, duration, aircraft"
182+
> Filter: (((flights.departure)::text ~~ '%DEN%'::text) OR ((flights.arrival)::text ~~ '%DEN%'::text))
183+
> Rows Removed by Filter: 68773
184+
> Buffers: shared hit=624
185+
> Planning Time: 0.069 ms
186+
> Execution Time: 9.722 ms
187+
>
188+
> Aggregate (cost=1760.64..1760.65 rows=1 width=8) (actual time=8.415..8.416 rows=1 loops=1)
189+
> Output: count(*)
190+
> Buffers: shared hit=624
191+
> -> Seq Scan on flight.flights (cost=0.00..1746.43 rows=5681 width=0) (actual time=0.230..8.205 rows=5576 loops=1)
192+
> " Output: departure, arrival, day_op, dep_time, carrier, airline, flightnum, duration, aircraft"
193+
> Filter: (((flights.departure)::text ~~ '%DEN%'::text) OR ((flights.arrival)::text ~~ '%DEN%'::text))
194+
> Rows Removed by Filter: 68773
195+
> Buffers: shared hit=624
196+
> Planning Time: 0.073 ms
197+
> Execution Time: 8.436 ms
198+
199+
- 可以发现Count函数的运行时间不超过0.001ms，且两次查询都是使用顺序查询节点，过滤器一致，缓存命中一致。虽然多使用一次Count函数，但全条目查询的时间比Count的结果还多了1.286ms，因此查询外耗时为1.287ms。由该性能分析知晓，在进行 `SELECT` 测试时，建议使用Count函数，以减少线性查询器以外的耗时，便于对比性能。
200+
201+
### 3、TinyDB系统设计与实现
202+
203+
#### 需求分析
204+
205+
##### 功能性需求
206+
207+
该数据集将作为在线航线查询系统的后端数据库，TinyDB作为简易数据库管理系统后端实现，需要支持四种基本功能：插入、删除、修改、查询。TinyDB不需要支持的功能包括但不限于：多用户系统、网络交互、命令解析、高并发交互等。
208+
209+
TinyDB的交互方式为命令行交互，测试时使用项目测试文件。目标工作负载为查询密集型，处理数据的量级最高为100MB，目标性能在50ms内通过测试。安全方面对用户输入完全可信，不支持预编译等注入攻击防护策略，也不支持通用SQL语言的执行。
210+
211+
##### 非功能性需求
212+
213+
TinyDB将使用C++17标准开发，主要遵循 [CERT](https://wiki.sei.cmu.edu/confluence/display/seccode) 开发规范，使用CMake自动化构建工具便于跨平台模块化编译，发布版使用-O3编译选项。
214+
215+
#### 概要设计
216+
217+
##### 总体设计
218+
219+
TODO 系统架构、系统功能、处理流程、模块概述
220+
221+
##### 外部接口
222+
223+
- 外部用户通过命令行或命令文件与系统交互，没有提供硬件分析接口
224+
225+
- 用户交互的输入数据限定为以下六种：
226+
227+
> CREATE tablename (column1,column2,...,columnn);
228+
>
229+
> INSERT INTO tablename VALUES (column1,column2,...,columnn);
230+
>
231+
> DELETE FROM tablename;
232+
>
233+
> DELETE FROM tablename WHERE column LIKE 'data';
234+
>
235+
> UPDATE tablename SET column='data' WHERE column LIKE 'data';
236+
>
237+
> SELECT column1,column2,...,columnn FROM tablename WHERE column LIKE 'data';
238+
239+
其中，小写部分表示可根据需求自定义字符串，大写部分不可更改，特殊符号和空格不可更改。不同命令的返回值在模块设计中说明
240+
241+
##### 模块设计
242+
243+
TODO 模块描述、层次结构、模块间关系、模块核心接口
244+
245+
#### 详细设计
246+
247+
TODO 分为不同模块，各包含以下部分：算法设计、数据结构设计、接口实现、属性、参数。
248+
249+
### 4、TinyDB系统性能分析
250+
251+
### 5、实验结论

‎src/REPL.cpp

Lines changed: 8 additions & 5 deletions
Original file line numberDiff line numberDiff line change
@@ -129,7 +129,7 @@ Runtime::Statement REPL::parse_where(Runtime::Statement statement, const std::st
129129
last_size = now_size;
130130
success = process_input('\'');
131131
now_size = statement.datas.size();
132-
if (!success || now_size != last_size + 1 || p != len - 2)
132+
if (!success || now_size != last_size + 1 || input[p+1] != ';')
133133
return REPL::error_statement(input, __func__);
134134

135135
return statement;
@@ -148,7 +148,7 @@ Runtime::Statement REPL::parse_datas(Runtime::Statement statement, const std::st
148148
{
149149
auto last_size = statement.datas.size();
150150

151-
while (p < len && input[p] != ';')
151+
while (p < len && input[p] != ';' && input[p] != eof)
152152
{
153153
for (int i = 0; p + i < len; i++)
154154
{
@@ -189,7 +189,7 @@ Runtime::Statement REPL::parse_statement(const std::string &input_raw)
189189

190190
p = p + 2;
191191
statement = REPL::parse_datas(statement, input, len, p, ')');
192-
if (!Runtime::valid_statement(statement) || input[p] != ';')
192+
if (!Runtime::valid_statement(statement) || input[p+1] != ';')
193193
return REPL::error_statement(input, __func__);
194194

195195
return statement;
@@ -206,7 +206,7 @@ Runtime::Statement REPL::parse_statement(const std::string &input_raw)
206206

207207
p = p + 9;
208208
statement = REPL::parse_datas(statement, input, len, p, ')');
209-
if (!Runtime::valid_statement(statement) || input[p] != ';')
209+
if (!Runtime::valid_statement(statement) || input[p+1] != ';')
210210
return REPL::error_statement(input, __func__);
211211

212212
return statement;
@@ -252,11 +252,14 @@ Runtime::Statement REPL::parse_statement(const std::string &input_raw)
252252
if (!process_input('='))
253253
return REPL::error_statement(input, __func__);
254254

255-
p = p + 2;
255+
p = p + 3;
256256
if (!process_input('\''))
257257
return REPL::error_statement(input, __func__);
258258

259259
p = p + 1;
260+
if (input.compare(p + 1, 5, "WHERE"))
261+
return REPL::error_statement(input, __func__);
262+
p = p + 7;
260263
statement = REPL::parse_where(statement, input, len, p);
261264
return statement;
262265
}

0 commit comments

Comments
 (0)