summaryrefslogtreecommitdiffstats
path: root/chapters/conclusion.tex
diff options
context:
space:
mode:
authorDouglas B. Rumbaugh <doug@douglasrumbaugh.com>2025-07-07 11:36:15 -0400
committerDouglas B. Rumbaugh <doug@douglasrumbaugh.com>2025-07-07 11:36:15 -0400
commit05aab7bd45e691a0b0f527d0ab4dd7cae0b3ec55 (patch)
treebe19b76016630bc7c7cdfb482e71b158c93fbd38 /chapters/conclusion.tex
parent0dc1a8ea20820168149cedaa14e223d4d31dc4b6 (diff)
downloaddissertation-05aab7bd45e691a0b0f527d0ab4dd7cae0b3ec55.tar.gz
update
Diffstat (limited to 'chapters/conclusion.tex')
-rw-r--r--chapters/conclusion.tex17
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