Browse Source

finish running bench & update report

main
kevinyao0901 1 month ago
parent
commit
209af51ffc
2 changed files with 49 additions and 1 deletions
  1. +49
    -1
      README.md
  2. BIN
      Report/png/benchmark.png

+ 49
- 1
README.md View File

@ -184,9 +184,57 @@ Status DBImpl::DeleteIndex(const std::string& fieldName) {
测试结果:
![error](Report\png\test_result.png)
**Benchmark测试运行结果及分析:**
![error](.\Report\png\benchmark.png)
1. **插入时间 (Insertion time for 100001 entries: 516356 microseconds)**
这个时间(516356 微秒,约 516 毫秒)看起来是合理的,特别是对于 100001 条记录的插入操作。如果你的数据插入过程没有特别复杂的计算或操作,这个时间应该是正常的,除非硬件性能或其他因素导致延迟。
2. **没有索引的查询时间 (Time without index: 106719 microseconds)**
这个时间是查询在没有索引的情况下执行的时间。106719 微秒(大约 107 毫秒)对于没有索引的查询来说是可以接受的,尤其是在数据量较大时。如果数据库没有索引,查找所有相关条目会比较耗时。
3. **创建索引的时间 (Time to create index: 596677 microseconds)**
这个时间(596677 微秒,约 597 毫秒)对于创建索引来说是正常的,尤其是在插入了大量数据后。如果数据量非常大,索引创建时间可能会显得稍长。通常情况下,创建索引的时间会随着数据量的增加而增大。
4. **有索引的查询时间 (Time with index: 68 microseconds)**
这个时间(68 微秒)非常短,几乎可以认为是一个非常好的优化结果。通常,索引查询比没有索引时要快得多,因为它避免了全表扫描。因此,这个时间是非常正常且预期的,说明索引大大加速了查询。
5. **查询结果 (Found 1 keys with index)**
这里显示索引查询找到了 1 个键。是正常的, `name=Customer#10000` 应该返回 1 条记录。
6. **数据库统计信息 (Database stats)**
```
Compactions
Level Files Size(MB) Time(sec) Read(MB) Write(MB)
--------------------------------------------------
0 2 6 0 0 7
1 5 8 0 16 7
```
这些信息表明数据库的压缩(Compaction)过程。`Level 0` 和 `Level 1` 显示了数据库的文件数和大小。此部分数据正常,意味着数据库在处理数据时有一些 I/O 操作和文件整理。
7. **删除索引的时间 (Time to delete index on field 'name': 605850 microseconds)**
删除索引的时间(605850 微秒,约 606 毫秒)比创建索引的时间稍长。这个时间是合理的,删除索引通常会涉及到重新整理数据结构和清理索引文件,因此可能比创建索引稍慢。
**benchmark运行结果总结:**
整体来看,输出结果是正常的:
- **插入和索引创建时间**:插入数据和创建索引所需的时间相对较长,但考虑到数据量和索引的生成,时间是合理的。
- **有索引的查询时间**:索引加速了查询,这部分的时间(68 微秒)非常短,表现出色。
- **删除索引的时间**:删除索引需要稍长时间,这也是常见的现象。
---
## 总结

BIN
Report/png/benchmark.png View File

Before After
Width: 1124  |  Height: 353  |  Size: 61 KiB

||||||
x
 
000:0
Loading…
Cancel
Save