From 067bf27c8527352d6c88f7c3e7bb38a0e5b26ab3 Mon Sep 17 00:00:00 2001
From: Douglas Rumbaugh <dbr4@psu.edu>
Date: Mon, 2 Jun 2025 20:42:26 -0400
Subject: updates

---
 chapters/tail-latency.tex | 30 ++++++++++++++++++++++++++++++
 1 file changed, 30 insertions(+)

(limited to 'chapters/tail-latency.tex')

diff --git a/chapters/tail-latency.tex b/chapters/tail-latency.tex
index 0cdeeab..e63f3c9 100644
--- a/chapters/tail-latency.tex
+++ b/chapters/tail-latency.tex
@@ -960,3 +960,33 @@ at a variety of stall proportions.
 
 
 \section{Conclusion}
+
+In this section, we addressed the final of the three major problems of
+dynamization: tail latency. We proposed a technique for limiting the
+rate of insertions to match the rate of reconstruction that is able to
+match the worst-case optimized approach of Overmars~\cite{overmars81} on
+a single thread, and able to exceed it given multiple parallel threads.
+We then implemented the necessary mechanisms to support this technique
+within our framework, including a significantly improved architecture
+for scheduling and executing parallel and background reconstructions,
+and a system for rate limiting by rejecting inserts via Bernoulli sampling.
+
+We evaluated this system for fixed insertion rejection rates, and found
+significant improvements in tail latencies, approaching the practical lower
+bound we established using the equal block method, without requiring
+significant degradation of query performance. In fact, we found that
+this rate limiting mechanism provides a design space with more effective
+trade-offs than the one we examined in Chapter~\ref{chap:design-space},
+with the system being able to exceed the query performance of an
+equivalently configured tiering system for certain rate limiting
+configurations. The method has limitations, assigning a fixed rejection
+rate of inserts works well for linear time constructable structures like
+the ISAM Tree, but was significantly less effective for the VPTree, which
+requires $\Theta(n \log n)$ time to construct. For structures like this,
+it will be necessary to dynamically scale the amount of throttling based
+on the record count and size of reconstruction. Additionally, our current
+system isn't easily capable of reaching the ``ideal'' goal of being able
+to reliably trade query performance and insertion latency at a fixed
+throughput. Nonetheless, the mechanisms for supporting such features
+are present, and even this simple implementation represents a marked
+improvement in terms of both insertion tail latency and configurability.
-- 
cgit v1.2.3

