diff options
Diffstat (limited to 'chapters/tail-latency.tex')
| -rw-r--r-- | chapters/tail-latency.tex | 30 |
1 files changed, 30 insertions, 0 deletions
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. |