|
|
|
@ -613,6 +613,109 @@ Level Files Size(MB) Time(sec) Read(MB) Write(MB) |
|
|
|
|
|
|
|
删除索引的时间（605850 微秒，约 606 毫秒）比创建索引的时间稍长。这个时间是合理的，删除索引通常会涉及到重新整理数据结构和清理索引文件，因此可能比创建索引稍慢。 |
|
|
|
|
|
|
|
> 根据这些结果，以下是吞吐、延迟、和写放大的分析： |
|
|
|
> |
|
|
|
> ------ |
|
|
|
> |
|
|
|
> ### **吞吐量** |
|
|
|
> |
|
|
|
> 吞吐量衡量的是系统在单位时间内能处理的操作量。根据插入时间和查询时间，可以推算吞吐量。 |
|
|
|
> |
|
|
|
> 1. **插入操作的吞吐量** |
|
|
|
> |
|
|
|
> - 插入时间为 516,356 微秒（约 516 毫秒）。 |
|
|
|
> |
|
|
|
> - 记录总数为 100,001。 |
|
|
|
> |
|
|
|
> - $$ |
|
|
|
> 吞吐量 = 总操作数总时间\frac{\text{总操作数}}{\text{总时间}}。 |
|
|
|
> $$ |
|
|
|
> |
|
|
|
> |
|
|
|
> |
|
|
|
> - $$ |
|
|
|
> 吞吐量=100,0010.516≈193,798 条/秒吞吐量 = \frac{100,001}{0.516} \approx 193,798 \, \text{条/秒} |
|
|
|
> $$ |
|
|
|
> |
|
|
|
> |
|
|
|
> |
|
|
|
> 2. **查询操作的吞吐量** |
|
|
|
> |
|
|
|
> - 有索引的查询时间为 68 微秒（非常快）。 |
|
|
|
> |
|
|
|
> - $$ |
|
|
|
> 查询操作吞吐量 = 10.000068≈14,705,882 次/秒\frac{1}{0.000068} \approx 14,705,882 \, \text{次/秒}。 |
|
|
|
> $$ |
|
|
|
> |
|
|
|
> |
|
|
|
> |
|
|
|
> - 无索引的查询时间为 106,719 微秒。 |
|
|
|
> $$ |
|
|
|
> 无索引的查询吞吐量=10.106719≈9.37 次/秒无索引的查询吞吐量 = \frac{1}{0.106719} \approx 9.37 \, \text{次/秒} |
|
|
|
> $$ |
|
|
|
> |
|
|
|
> |
|
|
|
> ------ |
|
|
|
> |
|
|
|
> ### **延迟** |
|
|
|
> |
|
|
|
> 延迟是单个操作所需的时间，可以从实验结果中直接得出： |
|
|
|
> |
|
|
|
> 1. **插入延迟** |
|
|
|
> $$ |
|
|
|
> 平均插入延迟 = 516,356100,001≈5.16 微秒/条\frac{516,356}{100,001} \approx 5.16 \, \text{微秒/条}。 |
|
|
|
> $$ |
|
|
|
> |
|
|
|
> |
|
|
|
> 2. **查询延迟** |
|
|
|
> |
|
|
|
> - 有索引的查询延迟：68 微秒。 |
|
|
|
> - 无索引的查询延迟：106,719 微秒。 |
|
|
|
> |
|
|
|
> ------ |
|
|
|
> |
|
|
|
> ### **写放大** |
|
|
|
> |
|
|
|
> 写放大是写入数据量与实际写入磁盘数据量的比值。根据数据库统计信息，可以估算写放大： |
|
|
|
> |
|
|
|
> 1. **统计数据** |
|
|
|
> |
|
|
|
> - 数据量：插入 100,001 条记录，假设每条记录大小为 64 字节，总大小约为 |
|
|
|
> $$ |
|
|
|
> 100,001×64=6.4 MB100,001 \times 64 = 6.4 \, \text{MB} |
|
|
|
> $$ |
|
|
|
> 。 |
|
|
|
> |
|
|
|
> - 压缩日志显示： |
|
|
|
> |
|
|
|
> - 读取数据量：16 MB。 |
|
|
|
> - 写入数据量：14 MB（Level 0 和 Level 1 总写入量）。 |
|
|
|
> |
|
|
|
> 2. **计算写放大** |
|
|
|
> $$ |
|
|
|
> 写放大 = 总写入量数据量=146.4≈2.19\frac{\text{总写入量}}{\text{数据量}} = \frac{14}{6.4} \approx 2.19。 |
|
|
|
> $$ |
|
|
|
> |
|
|
|
> |
|
|
|
> - 这个写放大值在 LSM 树中属于合理范围，尤其是数据量较大时。 |
|
|
|
> |
|
|
|
> ------ |
|
|
|
> |
|
|
|
> ### **总结** |
|
|
|
> |
|
|
|
> - **吞吐量**： |
|
|
|
> - 插入操作约为 **193,798 条/秒**。 |
|
|
|
> - 有索引的查询吞吐量为 **14,705,882 次/秒**，而无索引的查询吞吐量仅为 **9.37 次/秒**。 |
|
|
|
> - **延迟**： |
|
|
|
> - 插入操作的平均延迟为 **5.16 微秒/条**。 |
|
|
|
> - 有索引的查询延迟远低于无索引的查询延迟（68 微秒 vs 106,719 微秒）。 |
|
|
|
> - **写放大**： |
|
|
|
> 写放大约为 **2.19**，表明索引的写入效率较高，但仍需注意在高频写入场景中的性能影响。 |
|
|
|
> |
|
|
|
> 如果进一步优化，建议从减少写放大（例如改进合并机制）和提升无索引查询性能入手，以平衡系统资源。 |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
**benchmark运行结果总结：** |
|
|
|
|
|
|
|
整体来看，输出结果是正常的： |
|
|
|
|
kevinyao0901
1 week ago