update Readme Evaluation

README.md

@@ -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运行结果总结：**
 
 整体来看，输出结果是正常的：