|
|
@ -25,11 +25,11 @@ |
|
|
|
- [3. **二级索引的查询**](#3-二级索引的查询) |
|
|
|
- [4. **二级索引的删除**](#4-二级索引的删除) |
|
|
|
- [5. **`Put` 和 `Delete` 方法的内容**](#5-put-和-delete-方法的内容) |
|
|
|
- [6. 数据插入与删除的原子性实现](#6-数据插入与删除的原子性实现) |
|
|
|
- [7.持久化与恢复机制](#7-持久化与恢复机制) |
|
|
|
- [6. **数据插入与删除的原子性实现**](#6-数据插入与删除的原子性实现) |
|
|
|
- [7.**持久化与恢复机制**](#7-持久化与恢复机制) |
|
|
|
- [五,性能测试](#五性能测试) |
|
|
|
- [1. 测试流程](#1-测试流程) |
|
|
|
- [2. 结果分析](#2-结果分析) |
|
|
|
- [1. **测试流程**](#1测试流程) |
|
|
|
- [2. **结果分析**](#2结果分析) |
|
|
|
- [六,问题与解决方案](#六问题与解决方案) |
|
|
|
- [七,总结](#七总结) |
|
|
|
|
|
|
@ -561,6 +561,7 @@ Status DBImpl::Delete(const WriteOptions& options, const Slice& key) { |
|
|
|
|
|
|
|
|
|
|
|
## 五,性能测试 |
|
|
|
|
|
|
|
### 1.测试流程 |
|
|
|
|
|
|
|
**单元测试:** |
|
|
@ -592,22 +593,22 @@ Status DBImpl::Delete(const WriteOptions& options, const Slice& key) { |
|
|
|
|
|
|
|
### 2.结果分析 |
|
|
|
|
|
|
|
### 1. **总写入时间(Total time for 100001 writes)** |
|
|
|
#### 1. **总写入时间(Total time for 100001 writes)** |
|
|
|
|
|
|
|
- **结果**: 1464.65 ms |
|
|
|
- **分析**: 该值表示100001次写入操作所花费的总时间,接近1.46秒。这个时间段包括了所有写入操作和可能的其他处理,如日志记录和合并等。根据吞吐量(Throughput)可以看出每秒操作次数约为68277次,说明写入性能还是较为稳定。 |
|
|
|
|
|
|
|
### 2. **吞吐量(Throughput)** |
|
|
|
#### 2. **吞吐量(Throughput)** |
|
|
|
|
|
|
|
- **结果**: 68276.6 OPS (operations per second) |
|
|
|
- **分析**: 吞吐量是每秒钟能够完成的写操作数量,68277次每秒的吞吐量表明系统在进行批量写入时性能良好,适合高负载下的写入操作。 |
|
|
|
|
|
|
|
### 3. **平均延迟(Average latency)** |
|
|
|
#### 3. **平均延迟(Average latency)** |
|
|
|
|
|
|
|
- **结果**: 0.0133881 ms |
|
|
|
- **分析**: 平均延迟为0.0134毫秒,表示每个写入操作的平均响应时间非常低。延迟较低说明系统能够快速响应每个请求,这对需要低延迟的应用非常重要。 |
|
|
|
|
|
|
|
### 4. **P75 和 P99 延迟** |
|
|
|
#### 4. **P75 和 P99 延迟** |
|
|
|
|
|
|
|
- **结果**: P75 latency: 0.012 ms, P99 latency: 0.016 ms |
|
|
|
- 分析: |
|
|
@ -615,32 +616,32 @@ Status DBImpl::Delete(const WriteOptions& options, const Slice& key) { |
|
|
|
- **P99延迟**为0.016毫秒,表示99%的请求在0.016毫秒内完成。 |
|
|
|
- 这表明绝大多数请求的延迟都非常小,延迟稳定,且尾延迟(P99)也处于可接受范围。 |
|
|
|
|
|
|
|
### 5. **索引创建时间(Time to create index)** |
|
|
|
#### 5. **索引创建时间(Time to create index)** |
|
|
|
|
|
|
|
- **结果**: 661884 microseconds (~661.88 ms) |
|
|
|
- **分析**: 索引的创建时间接近660毫秒,可能由于索引数据结构的构建和填充过程。该时间相对较长,但不至于影响整体性能。 |
|
|
|
|
|
|
|
### 6. **索引查询时间(Time with index)** |
|
|
|
#### 6. **索引查询时间(Time with index)** |
|
|
|
|
|
|
|
- **结果**: 97 microseconds |
|
|
|
- **分析**: 使用索引进行查询的时间非常低,仅为97微秒。这表明通过索引可以显著提高查询性能,特别是在查询大数据量时,查询响应时间大幅降低。 |
|
|
|
|
|
|
|
### 7. **写放大(Write Amplification)** |
|
|
|
#### 7. **写放大(Write Amplification)** |
|
|
|
|
|
|
|
- **结果**: Write Amplification Factor: 2.24915 |
|
|
|
- **分析**: 写放大因子为2.25,表示系统写入的数据量是原始数据量的2.25倍。这个值较为理想,说明合并过程和磁盘上的写入是有效的,没有造成过多的额外写入。 |
|
|
|
|
|
|
|
### 8. **总数据写入量(Total data written)** |
|
|
|
#### 8. **总数据写入量(Total data written)** |
|
|
|
|
|
|
|
- **结果**: 7058762 bytes (~7.06 MB) |
|
|
|
- **分析**: 这是在进行100001次写入操作过程中,系统写入到磁盘的总字节数。与写放大因子2.25结合来看,系统的写入开销较为合理。 |
|
|
|
|
|
|
|
### 9. **索引删除时间(Time to delete index on field 'name')** |
|
|
|
#### 9. **索引删除时间(Time to delete index on field 'name')** |
|
|
|
|
|
|
|
- **结果**: 1235916 microseconds (~1235.92 ms) |
|
|
|
- **分析**: 删除索引所需的时间较长,接近1.24秒。这可能是因为索引结构的更新和删除操作涉及较多的计算和磁盘操作,影响了响应速度。 |
|
|
|
|
|
|
|
### 10. **数据库状态(Compactions)** |
|
|
|
#### 10. **数据库状态(Compactions)** |
|
|
|
|
|
|
|
- 分析: |
|
|
|
- 在Level 0上有1个文件,大小为3MB,写入了7MB的数据。 |
|
|
@ -649,7 +650,7 @@ Status DBImpl::Delete(const WriteOptions& options, const Slice& key) { |
|
|
|
|
|
|
|
------ |
|
|
|
|
|
|
|
### 总结 |
|
|
|
#### 总结 |
|
|
|
|
|
|
|
- 性能优点: |
|
|
|
- 吞吐量较高(68277 OPS),平均延迟和尾延迟较低,表明系统在高负载下能够稳定运行。 |
|
|
@ -673,7 +674,7 @@ Status DBImpl::Delete(const WriteOptions& options, const Slice& key) { |
|
|
|
|
|
|
|
## 六,问题与解决方案 |
|
|
|
|
|
|
|
### 1. **问题:如何避免**
`indexDb_` **的递归调用?** |
|
|
|
### 1.**问题:如何避免** `indexDb_` **的递归调用?** |
|
|
|
|
|
|
|
在实现 `Put` 和 `Delete` 方法时,由于 `indexDb_` 也调用了 `DBImpl` 的方法,可能导致递归调用的问题。具体表现为在 `indexDb_` 内部操作时仍会试图更新索引。 |
|
|
|
|
|
|
|