diff options
| author | Douglas B. Rumbaugh <doug@douglasrumbaugh.com> | 2025-07-07 11:36:15 -0400 |
|---|---|---|
| committer | Douglas B. Rumbaugh <doug@douglasrumbaugh.com> | 2025-07-07 11:36:15 -0400 |
| commit | 05aab7bd45e691a0b0f527d0ab4dd7cae0b3ec55 (patch) | |
| tree | be19b76016630bc7c7cdfb482e71b158c93fbd38 /chapters/conclusion.tex | |
| parent | 0dc1a8ea20820168149cedaa14e223d4d31dc4b6 (diff) | |
| download | dissertation-05aab7bd45e691a0b0f527d0ab4dd7cae0b3ec55.tar.gz | |
update
Diffstat (limited to 'chapters/conclusion.tex')
| -rw-r--r-- | chapters/conclusion.tex | 17 |
1 files changed, 17 insertions, 0 deletions
diff --git a/chapters/conclusion.tex b/chapters/conclusion.tex index 13457b5..eb4cf72 100644 --- a/chapters/conclusion.tex +++ b/chapters/conclusion.tex @@ -61,6 +61,21 @@ update support. In particular, our framework must also support the following additional features, \begin{enumerate} + \item \textbf{Automatic Tuning of Insertion Rejection Rate.} \\ + The tail latency control system discussed + in Chapter~\ref{chap:tail-latency} is based upon setting a + rejection rate parameter for inserts, which must be tuned for + the data structure being dynamized. The current version treats + this as a user-specified constant parameter, but it would be + ideal for this parameter to be automatically determined based + on the performance of the framework. In particular, we noted in + Chapter~\ref{chap:tail-latency} that having it fixed to a single + value is sub-optimal for some data structures, and there also + exist opportunities to dynamically adjust it based on the actual + rate of inserts into the system to achieve better throughput. The + design of a system for doing this automatic rejection rate tuning is + an important next step for the framework. + \item \textbf{Support for external storage.} \\ While we did have an implementation of sampling framework discussed in Chapter~\ref{chap:sampling} that used an external @@ -69,6 +84,7 @@ following additional features, to extend it with support for external structures, as well as evaluate whether our proposed techniques still function effectively in this context. + \item \textbf{Crash recovery.} \\ It is critical for a database index to support crash recovery, so that it can be recovered to a state consistent with the rest of @@ -77,6 +93,7 @@ following additional features, inefficient crash recovery is straightforward: All operations can be logged and replayed in the event of a crash. But this is highly inefficient, and so a better scheme must be devised. + \item \textbf{Distributed systems support.} \\ The append-only and decomposed nature of dynamized indices make them seem a natural fit in a distributed systems context. This was |