path: root/chapters/beyond-dsp.tex

\chapter{Generalizing the Framework}

\begin{center}
    \emph{The following chapter is an adaptation of work completed in collaboration with Dr. Dong Xie and Dr. Zhuoyue Zhao
    and published
    in PVLDB Volume 17, Issue 11 (July 2024) under the title "Towards Systematic Index Dynamization".
    }
    \hrule
\end{center}


\label{chap:framework}

\section{Introduction}

In the previous chapter, we discussed how several of the limitations of
dynamization could be overcome by proposing a systematic dynamization
approach for sampling data structures. In doing so, we introduced
a multi-stage query mechanism to overcome the non-decomposability of
these queries, provided two mechanisms for supporting deletes along with
specialized processing to integrate these with the query mechanism, and
introduced some performance tuning capability inspired by the design space
of modern LSM Trees. While promising, these results are highly specialized
and remain useful only within the context of sampling queries. In this
chapter, we develop new generalized query abstractions based on these
specific results, and discuss a fully implemented framework based upon
these abstractions.

More specifically, in this chapter we propose \emph{extended
decomposability} and \emph{iterative deletion decomposability} as two
new, broader classes of search problem which are strict supersets of
decomposability and deletion decomposability respectively, providing a
more powerful interface to allow the efficient implementation of a larger
set of search problems over a dynamized structure. We then implement
a C++ library based upon these abstractions which is capable of adding
support for inserts, deletes, and concurrency to static data structures
automatically, and use it to provide dynamizations for independent range
sampling, range queries with learned indices, string search with succinct
tries, and high dimensional vector search with metric indices. In each
case we compare our dynamized implementation with existing dynamic
structures, and standard Bentley-Saxe dynamizations, where possible.

\section{Beyond Decomposability}

We begin our discussion of this generalized framework by proposing
new classes of search problems based upon our results from examining
sampling problems in the previous chapter. Our new classes will enable
the support of new types of search problem, enable more efficient support
for certain already supported problems, and allow for broader support
of deletes. Based on this, we will develop a taxonomy of search problems
that can be supported by our dynamization technique.


\subsection{Extended Decomposability}

As discussed in Chapter~\cite{chap:background}, the standard query model
used by dynamization techniques requires that a given query be broadcast,
unaltered, to each block within the dynamized structure, and then that
the results from these identical local queries be efficiently mergable
to obtain the final answer to the query. This model limits dynamization
to decomposable search problems (Definition~\ref{def:dsp}).

In the previous chapter, we considered various sampling problems as
examples of non-decomposable search problems, and devised a technique for
correctly answering queries of that type over a dynamized structure. In
this section, we'll retread our steps with an eye towards a general
solution, that could be applicable in other contexts. For convenience,
we'll focus exlusively on independent range sampling. As a reminder, this
search problem is defined as,

\begin{definitionIRS}[Independent Range Sampling~\cite{tao22}]
    Let $D$ be a set of $n$ points in $\mathbb{R}$. Given a query
    interval $q = [x, y]$ and an integer $k$, an independent range sampling
    query returns $k$ independent samples from $D \cap q$ with each 
    point having equal probability of being sampled.
\end{definitionIRS}

We formalize this as a search problem $F_\text{IRS}:(\mathcal{D},
\mathcal{Q}) \to \mathcal{R}$ where the record domain is $\mathcal{D}
= \mathbb{R}$, the query parameters domain consists of order triples
containing the lower and upper boudns of the query interval, and the
number of samples to draw, $\mathcal{Q} = \mathbb{R} \times \mathbb{R}
\times \mathbb{Z}^+$, and the result domain containts subsets of the
real numbers, $\mathcal{R} = \mathcal{PS}(\mathbb{R})$.

$F_\text{IRS}$ can be solved using a variety of data structures, such as
the static ISAM solution discussed in Section~\ref{ssec:irs-struct}. For
our example here, we will use a simple sorted array. Let $\mathcal{I}$
be the sorted array data structure, with a specific instance $\mathscr{I}
\in \mathcal{I}$ built over a set $D \subset \mathbb{R}$ having $|D| =
n$ records. The problem $F_\text{IRS}(\mathscr{I}, (l, u, k))$ can be
solved by binary searching $\mathscr{I}$ twice to obtain the index of
the first element greater than or equal to $l$ ($i_l$) and the last
element less than or equal to $u$ ($i_u$). With these two indices,
$k$ random numbers can generated on the interval $[i_l, i_u]$ and the
records at these indices returned. This sampling procedure is described
in Algorithm~\ref{alg:array-irs} and runs in $\mathscr{Q}_\text{irs}
\in \Theta(\log n + k)$ time.

\SetKwFunction{IRS}{IRS}
\begin{algorithm}
\caption{Solution to IRS on a sorted array}
\label{alg:array-irs}
\KwIn{$k$: sample size, $[l,u]$: lower and upper bound of records to sample}
\KwOut{$S$: a sample set of size $k$}
\Def{\IRS{$(\mathscr{I}, (l, u, k))$}}{
    \Comment{Find the lower and upper bounds of the interval}
    $i_l \gets \text{binary\_search\_lb}(\mathscr{I}, l)$ \;
    $i_u \gets \text{binary\_search\_ub}(\mathscr{I}, u)$ \;
    \BlankLine
    \Comment{Initialize empty sample set}
    $S \gets \{\}$ \;
    \BlankLine
    \For {$i=1\ldots k$} {
        \Comment{Select a random record within the inteval}
        $i_r \gets \text{randint}(i_l, i_u)$ \;

        \Comment{Add it to the sample set}
        $S \gets S \cup \{\text{get}(\mathscr{I}, i_r)\}$ \;
    }
    \BlankLine
    \Comment{Return the sample set}
    \Return $S$ \;
}
\end{algorithm}

It becomes more difficult to answer $F_\text{IRS}$ over a data structure
that has been decomposed into blocks, because the number of samples
taken from each block must be appropriately weighted to correspond to the
number of records within each block falling into the query range. In the
classical model, there isn't a way to do this, and so the only solution
is to answer $F_\text{IRS}$ against each block, asking for the full $k$
samples each time, and then downsampling the results corresponding to
the relative weight of each block, to obtain a final sample set.

Using this idea, we can formulate $F_\text{IRS}$ as a $C(n)$-decomposable
problem by changing the result set type to $\mathcal{R} =
\mathcal{PS}(\mathbb{R}) \times \mathbb{R}$ where the first element
in the tuple is the sample set and the second argument is the number
of elements falling between $l$ and $u$ in the block being sampled
from. With this information, it is possible to implement $\mergeop$
using Bernoulli sampling over the two sample sets to be merged. This
requires $\Theta(k)$ time, and thus $F_\text{IRS}$ can be said to be
a $k$-decomposable search problem, which runs in $\Theta(\log^2 n + k
\log n)$ time. This procedure is shown in Algorithm~\ref{alg:decomp-irs}.

\SetKwFunction{IRSDecomp}{IRSDecomp}
\SetKwFunction{IRSCombine}{IRSCombine}
\begin{algorithm}[!h]
    \caption{$k$-Decomposable Independent Range Sampling}
    \label{alg:decomp-irs}
    \KwIn{$k$: sample size, $[l,u]$: lower and upper bound of records to sample}
    \KwOut{$(S, c)$: a sample set of size $k$ and a count of the number
           of records on on the interval $[l,u]$}
    \Def{\IRSDecomp{$\mathscr{I}_i, (l, u, k)$}}{
        \Comment{Find the lower and upper bounds of the interval}
        $i_l \gets \text{binary\_search\_lb}(\mathscr{I}_i, l)$ \;
        $i_u \gets \text{binary\_search\_ub}(\mathscr{I}_i, u)$ \;
        \BlankLine
        \Comment{Initialize empty sample set}
        $S \gets \{\}$ \;
        \BlankLine
        \For {$i=1\ldots k$} {
            \Comment{Select a random record within the inteval}
            $i_r \gets \text{randint}(i_l, i_u)$ \;

            \Comment{Add it to the sample set}
            $S \gets S \cup \{\text{get}(\mathscr{I}_i, i_r)\}$ \;
        }
        \BlankLine
        \Comment{Return the sample set and record count}
        \Return ($S$, $i_u - i_l$) \;
    }
    \BlankLine

    \Def{\IRSCombine{$(S_1, c_1)$, $(S_2, c_2)$}}{
        \Comment{The output set should be the same size as the input ones}
        $k \gets |S_1|$ \;
        \BlankLine
        \Comment{Calculate the weighting that should be applied to each set when sampling}
        $w_1 \gets \frac{c_1}{c_1 + c_2}$ \;
        $w_2 \gets \frac{c_2}{c_1 + c_2}$ \;
        \BlankLine
        \Comment{Initialize output set and count}
        $S \gets \{\}$\;
        $c \gets c_1 + c_2$ \;
        \BlankLine
        \Comment{Down-sample the input result sets}
        $S \gets S \cup \text{bernoulli}(S_1, w_1, k\times w_1)$ \;
        $S \gets S \cup \text{bernoulli}(S_2, w_2, k\times w_2)$ \;
        \BlankLine
        \Return $(S, w)$
    }
\end{algorithm}

While this approach does allow sampling over a dynamized structure, it is
asymptotically inferior to Olken's method, which allows for sampling in
only $\Theta(k \log n)$ time~\cite{olken89}. However, we've already seen
in the previous chapter how it is possible to modify the query procedure
into a multi-stage process to enable more efficient solutions to the IRS
problem. The core idea underlying our solution in that chapter was to
introduce individualized local queries for each block, which were created
after a pre-processing step to allow information about each block to be
determined first. In that particular example, we established the weight
each block should have during sampling, and then creating custom sampling
queries with variable $k$ values, following the weight distributions. We
have determined a general interface that allows for this procedure to be
expressed, and we define the term \emph{extended decomposability} to refer
to search problems that can be answered in this way.

More formally, consider search problem $F(D, q)$ capable of being
answered using a data structure instance $\mathscr{I} \in \mathcal{I}$
built over a set of records $D \in \mathcal{D}$ that has been decomposed
into $m$ blocks, $\mathscr{I}_1, \mathscr{I}_2, \ldots, \mathscr{I}_m$
each corresponding to a partition of $D$, $D_1, D_2, \ldots, D_m$. $F$
is an extended-decomposable search problem (eDSP) if it can be expressed
using the following interface,

\begin{itemize}
\item $\mathbftt{local\_preproc}(\mathscr{I}_i, q) \to \mathscr{M}_i$ \\
    Pre-process each partition, $D_i$, using its associated data
    structure, $\mathscr{I}$ and generate a meta-information object
    $\mathscr{M}_i$ for use in local query generation.

\item $\mathbftt{distribute\_query}(\mathscr{M}_1, \ldots, \mathscr{M}_m,
       q) \to q_1, \ldots, q_m$\\
        Process the set of meta-information about each block and produce
        individual local queries, $q_1, \ldots, q_m$, for each block.

\item $\mathbftt{local\_query}(\mathscr{I}_i, q_i)  \to r_i$ \\
        Evaluate the local query with parameters $q_i$ over the data
        in $D_i$ using the data structure $\mathscr{I}_i$ and produce
        a partial query result, $r_i$.

\item $\mathbftt{combine}(r_1, \ldots, r_m) \to R$ \\ 
        Combine the list of local query results, $r_1, \ldots, r_m$ into
        a final query result, $R$.
\end{itemize}

Let $P(n)$ be the cost of $\mathbftt{local\_preproc}$, $D(n)$ be
the cost of $\mathbftt{distribute\_query}$,  $\mathscr{Q}_\ell(n)$
be the cost of $\mathbftt{local\_query}$, and $C_e(n)$ be the cost
$\mathbftt{combine}$. To solve a search problem with this interface
requires calling $\mathbftt{local\_preproc}$ and $\mathbftt{local\_query}$
once per block, and $\mathbftt{distribute\_query}$ and
$\mathbftt{combine}$ once. For a Bentley-Saxe dynamization then, with
$O(\log_2 n)$ blocks, the worst-case cost of answering an eDSP is,
\begin{equation}
\label{eqn:edsp-cost}
O \left( \log_2 n \cdot P(n) + D(n) + \log_2 n \cdot \mathscr{Q}_\ell(n) + C_e(n) \right)
\end{equation}

As an example, we'll express IRS using the above interface and
analyze its complexity to show that the resulting solution as the
same $\Theta(log^2 n + k)$ cost as the specialized solution from
Chapter~\ref{chap:sampling}.  We use $\mathbftt{local\_preproc}$
to determine the number of records on each block falling on the
interval $[l, u]$ and return this, as well as $i_l$ and $i_u$ as the
meta-information. Then, $\mathbftt{distribute\_query}$ will perform
weighted set sampling using a temporary alias structure over the
weights of all of the blocks to calculate the appropriate value
of $k$ for each local query, which will consist of $(k_i, i_{l,i},
i_{u,i})$. With the appropriate value of $k$, as well as the indices of
the upper and lower bounds, pre-calculated, $\mathbftt{local\_query}$
can simply generate $k_i$ random integers and return the corresponding
records. $\mathbftt{combine}$ simply combines all of the local results
and returns the final result set. Algorithm~\ref{alg:edsp-irs} shows
each of these operations in psuedo-code.


\SetKwFunction{preproc}{local\_preproc}
\SetKwFunction{distribute}{distribute\_query}
\SetKwFunction{query}{local\_query}
\SetKwFunction{combine}{combine}
\begin{algorithm}[t]
    \caption{IRS with Extended Decomposability}
    \label{alg:edsp-irs}
    \KwIn{$k$: sample size, $[l,u]$: lower and upper bound of records to sample}
    \KwOut{$R$: a sample set of size $k$}

    \Def{\preproc{$\mathscr{I}_i$, $q=(l,u,k)$}}{
        \Comment{Find the indices for the upper and lower bounds of the query range}
        $i_l \gets \text{binary\_search\_lb}(\mathscr{I}_i, l)$ \;
        $i_u \gets \text{binary\_search\_ub}(\mathscr{I}_i, u)$ \;
        \BlankLine
        \Return $(i_l, i_u)$ \;
    }

    \BlankLine
    \Def{\distribute{$\mathscr{M}_1$, $\ldots$, $\mathscr{M}_m$, $q=(l,u,k)$}}{
        \Comment{Determine number of records to sample from each block}
        $k_1, \ldots k_m \gets \mathtt{wss}(k, \mathscr{M}_1, \ldots \mathscr{M}_m)$ \;
        \BlankLine
        \Comment{Build local query objects}
        \For {$i=1..m$} {
            $q_i \gets (\mathscr{M}.i_l, \mathscr{M}.i_u, k_i)$ \;
        }

        \BlankLine
        \Return $q_1 \ldots q_m$ \;
    }

    \BlankLine
    \Def{\query{$\mathscr{I}_i$, $q_i = (i_{l,i},i_{u,i},k_i)$}}{
 
        \For {$i=1\ldots k_i$} {
            \Comment{Select a random record within the inteval}
            $i_r \gets \text{randint}(i_{l,i}, i_{u,i})$ \;

            \Comment{Add it to the sample set}
            $S \gets S \cup \{\text{get}(\mathscr{I}_i, i_r)\}$ \;
        }

        \Return $S$ \;
    }

    \BlankLine
    \Def{\combine{$r_1, \ldots, r_m$, $q=(l, u, k)$}}{
        \Comment{Union results together}
        \Return $\bigcup_{i=1}^{m} r_i$ 
    }
\end{algorithm}

These operations result in $P(n) \in \Theta(\log n)$, $D(n) \in
\Theta(\log n)$, $\mathscr{Q}(n,k) \in \Theta(k)$, and $C_e(n) \in
\Theta(1)$. At first glance, it would appear that we arrived at a
solution with a query cost of $O\left(\log_2^2 n + k\log_2 n\right)$,
and thus fallen short of our goal. However, Equation~\ref{eqn:edsp-cost}
is only an upper bound on the cost. In the case of IRS, we can leverage an
important problem-specific detail to obtain a better result: the total
cost of the local queries is actually \emph{independent} of the number
of shards.

For IRS, the cost of $\mathbftt{local\_query}$ is linear to the number
of samples requested. Our initial asymptotic cost assumes that, in the
worst case, each of the $\log_2 n$ blocks is sampled $k$ times. But
this is not true of our algorithm. Rather, only $k$ samples are taken
\emph{in total}, distributed across all of the blocks. Thus, regardless
of how many blocks there are, there will only be $k$ samples drawn,
requiring $k$ random number generations, etc. As a result, the total
cost of the local query term in the cost function is actually $\Theta(k)$.
Applying this result gives us a tighter bound of,
\begin{equation*}
\mathscr{Q}_\text{IRS} \in \Theta\left(\log_2^2 n + k\right)
\end{equation*}
which matches the result of Chapter~\ref{chap:sampling} for IRS sampling
in the absence of deletes. The other sampling problems considered in
Chapter~\ref{chap:sampling} can be similarly implemented using this
interface, with the same performance as their specialized implementations.


\subsection{Iterative Deletion Decomposability}

We next turn out attention to support for deletes. Efficient delete
support in Bentley-Saxe dynamization is provably impossible~\cite{saxe79},
but, as discussed in Section~\ref{ssec:dyn-deletes} it is possible
to support them in restricted situations, where either the search
problem is invertible (Definition~\ref{def:invert}) or the data
structure and search problem combined are deletion decomposable
(Definition~\ref{def:background-ddsp}).  In Chapter~\ref{chap:sampling},
we considered a set of search problems which did \emph{not} satisfy
any of these properties, and instead built a customized solution for
deletes that required tight integration with the query process in order
to function. While such a solution was acceptable for the goals of that
chapter, it is not sufficient for our goal in this chapter of producing
a generalized system.

Additionally, of the two types of problem that can support deletes, the
invertible case is preferable. This is because the amount of work necessary
to support deletes for invertible search problems is very small. The data
structure requires no modification (such as to implement weak deletes),
and the query requires no modification (to ignore the weak deletes) aside
from the addition of the $\Delta$ operator. This is appealing from a
framework design standpoint. Thus, it would also be worth it to consider
approaches for expanding the range of search problems that can be answered
using the ghost structure mechanism supported by invertible problems.

A significant limitation of invertible problems is that the result set
size is not able to be controlled. We do not know how many records in our
local results have been deleted until we reach the combine operation and
they begin to cancel out, at which point we lack a mechanism to go back
and retrieve more. This presents difficulties for addressing important
search problems such as top-$k$, $k$-NN, and sampling. In principle, these
queries could be supported by repeating the query with larger-and-larger
$k$ values until the desired number of records is returned, but in the
eDSP model this requires throwing away a lot of useful work, as the state
of the query must be rebuilt each time. 

We can resolve this problem by moving the decision to repeat the query
into the query interface itself, allowing retries \emph{before} the
result set is returned to the user and the local meta-information objects
discarded. This allows us to preserve this pre-processing work, and repeat
the local query process as many times as is necessary to achieve our
desired number of records. From this obervation, we propose another new
class of search problem: \emph{iterative deletion decomposable} (IDSP). The
IDSP definition expands eDSP with a fifth operation,

\begin{itemize}
	\item $\mathbftt{repeat}(\mathcal{Q}, \mathcal{R}, \mathcal{Q}_1, \ldots,
        \mathcal{Q}_m) \to (\mathbb{B}, \mathcal{Q}_1, \ldots,
        \mathcal{Q}_m)$ \\
	Evaluate the combined query result in light of the query. If
	a repetition is necessary to satisfy constraints in the query
	(e.g., result set size), optionally update the local queries as
	needed and return true. Otherwise, return false.
\end{itemize}

If this routine returns true, it must also modify the local queries as
necessary to account for the work that remains to be completed (e.g.,
update the number of records to retrieve). Then, the query process resumes
from the execution of the local queries. If it returns false, then the
result is simply returned to the user. If the number of repetitions of
the query is bounded by $R(n)$, then the following provides an upper
bound on the worst-case query complexity of an IDSP,

\begin{equation*}
    O\left(\log_2 n \cdot P(n) + D(n) + R(n) \left(\log_2 n \cdot Q_s(n) +
	       C_e(n)\right)\right)
\end{equation*}

It is important that a bound on the number of repetitions exists,
as without this the worst-case query complexity is unbounded. The
details of providing and enforcing this bound are very search problem
specific. For problems like $k$-NN or top-$k$, the number of repetitions
is a function of the number of deleted records within the structure,
and so $R(n)$ can be bounded by placing a limit on the number of deleted
records. This can be done, for example, using the full-reconstruction
techniques in the literature~\cite{saxe79, merge-dsp, overmars83}
or through proactively performing reconstructions, such as with the
mechanism discussed in Section~\ref{sssec:sampling-rejection-bound},
depending on the particulars of how deletes are implemented.

As an example of how IDSP can facilitate delete support for search
problems, let's consider $k$-NN. This problem can be $C(n)$-deletion
decomposable, depending upon the data structure used to answer it, but
it is not invertible because it suffers from the problem of potentially
returning fewer than $k$ records in the final result set after the results
of the query against the primary and ghost structures have been combined.
Worse, even if the query does return $k$ records as requested, it is
possible that the result set could be incorrect, depending upon which
records were deleted, what block those records are in, and the order in
which the merge and inverse merge are applied.

\begin{example}
Consider the $k$-NN search problem, $F$, over some metric index
$\mathcal{I}$. $\mathcal{I}$ has been dynamized, with a ghost
structure for deletes, and consists of two blocks, $\mathscr{I}_1$ and
$\mathscr{I}_2$ in the primary structure, and one block, $\mathscr{I}_G$
in the ghost structure. The structures contain the following records,
\begin{align*}
\mathscr{I}_1 &= \{ x_1, x_2, x_3, x_4, x_5\} \\
\mathscr{I}_2 &= \{ x_6, x_7, x_8 \} \\
\mathscr{I}_G &= \{x_1, x_2, x_3 \}
\end{align*}
where the subscript indicates the proximity to some point, $p$. Thus,
the correct answer to the query $F(\mathscr{I}, (3, p))$ would be the
set of points $\{x_4, x_5, x_6\}$.

Querying each of the three blocks independently, however, will produce
an incorrect answer. The partial results will be,
\begin{align*}
r_1 = \{x_1, x_2, x_3\} \\
r_2 = \{x_6, x_7, x_8\} \\
r_g = \{x_1, x_2, x_3\}
\end{align*}
and, assuming that $\mergeop$ returns the $k$ elements closest to $p$
from the inputs, and $\Delta$ removes matching elements, performing
$r_1~\mergeop~r_2~\Delta~r_g$ will give an answer of $\{\}$, which
has insufficient records, and performing $r_1~\Delta~r_g~\mergeop~r_2$
will provide a result of $\{x_6, x_7, x_8\}$, which is wrong.
\end{example}

From this example, we can draw two conclusions about performing $k$-NN
using a ghost structure for deletes. First, we must ensure that all of
the local queries against the primary structure are merged, prior to
removing any deleted records, to ensure correctness. Second, once the
ghost structure records have been removed, we may need to go back to
the dynamized structure for more records to ensure that we have enough.
Both of these requirements can be accomodated by the IDSP model, and the
resulting query algorithm is shown in Algorithm~\ref{alg:idsp-knn}. This
algorithm assumes that the data structure in question can save the
current traversal state in the meta-information object, and resume a
$k$-NN query on the structure from that state at no cost. 

\SetKwFunction{repeat}{repeat}
\afterpage{\clearpage}
\begin{algorithm}[p]
    \caption{$k$-NN with Iterative Decomposability}
    \label{alg:idsp-knn}
    \KwIn{$k$: result size, $p$: query point}
    \Def{\preproc{$q=(k, p)$, $\mathscr{I}_i$}}{
        \Return $\mathscr{I}_i.\text{initialize\_state}(k, p)$ \;
    }

    \BlankLine
    \Def{\distribute{$\mathscr{M}_1$, ..., $\mathscr{M}_m$, $q=(k,p)$}}{
        \For {$i\gets1 \ldots m$} {
            $q_i \gets (k, p, \mathscr{M}_i)$ \;
        }

        \Return $q_1 \ldots q_m$ \;
    }

    \BlankLine
    \Def{\query{$\mathscr{I}_i$, $q_i=(k,p,\mathscr{M}_i)$}}{
        $(r_i, \mathscr{M}_i) \gets \mathscr{I}_i.\text{knn\_from}(k, p, \mathscr{M}_i)$ \;
        \Comment{The local result stores records in a priority queue}
        \Return $(r_i, \mathscr{M}_i)$  \;
    }

    \BlankLine
    \Def{\combine{$r_1, \ldots, r_m, \ldots, r_n$, $q=(k,p)$}}{
        $R \gets \{\}$ ;
        $pq \gets \text{PriorityQueue}()$ ;
        $gpq \gets \text{PriorityQueue}()$ \; 
        \Comment{Results $1$ through $m$ are from the primary structure,
        and $m+1$ through $n$ are from the ghost structure.}
        \For {$i\gets 1 \ldots m$} {
            $pq.\text{enqueue}(i, r_i.\text{front}())$ \;
        }

        \For {$i \gets m+1 \ldots n$} {
            $gpq.\text{enqueue}(i, r_i.\text{front}())$
        }

    \BlankLine
    \Comment{Process the primary local results}
        \While{$|R| < k \land \neg pq.\text{empty}()$} {
            $(i, d) \gets pq.\text{dequeue}()$ \;

            $R \gets R \cup r_i.\text{dequeue}()$ \;
            \If {$\neg r_i.\text{empty}()$} {
                $pq.\text{enqueue}(i, r_i.\text{front}())$ \;
            }
        }

    \BlankLine
    \Comment{Process the ghost local results}
    \While{$\neg gpq.\text{empty}()$} {
        $(i, d) \gets gpq.\text{dequeue}()$ \;

        \If {$r_i.\text{front}() \in R$} {
            $R \gets R / \{r_i.\text{front}()\}$ \;

            \If {$\neg r_i.\text{empty}()$} {
                $gpq.\text{enqueue}(i, r_i.\text{front}())$ \;
            }
        }
    }

        \Return $R$ \;
    }
    \BlankLine
    \Def{\repeat{$q=(k,p), R, q_1,\ldots q_m$}} {
        $missing \gets k - R.\text{size}()$ \;
        \If {$missing > 0$} {
            \For {$i \gets 1\ldots m$} {
                $q_i \gets (missing, p, q_i.\mathscr{M}_i)$ \;
            }

            \Return $(True, q_1 \ldots q_m)$ \;
        }

        \Return $(False, q_1 \ldots q_m)$ \;
    }
\end{algorithm}




\subsection{Search Problem Taxonomy}

Having defined two new classes of search problem, it seems sensible
at this point to collect our definitions together with pre-existing
ones from the classical literature, and present a cohesive taxonomy
of the search problems for which our techniques can be used to
support dynamization. This taxonomy is shown in the Venn diagrams of
Figure~\ref{fig:taxonomy}. Note that, for convenience, the search problem
classications relevant for supporting deletes have been seperated out
into a seperate diagram. In principle, this deletion taxonomy can be
thought of as being nested inside of each of the general search problem
classifications, as the two sets of classification are orthogonal. That
a search problem falls into a particular classification in the general
taxonomy doesn't imply any particular information about where in the
deletion taxonomy that same problem might also fall.

\begin{figure}[t]
	\subfloat[General Taxonomy]{\includegraphics[width=.49\linewidth]{diag/taxonomy}
    \label{fig:taxonomy-main}} 
	\subfloat[Deletion Taxonomy]{\includegraphics[width=.49\linewidth]{diag/deletes} \label{fig:taxonomy-deletes}}
	\caption{An overview of the Taxonomy of Search Problems, as relevant to
		our discussion of data structure dynamization. Our proposed extensions
        are marked with an asterisk (*) and colored yellow. 
    }
	\label{fig:taxonomy}
\end{figure} 

Figure~\ref{fig:taxonomy-main} illustrates the classifications of search
problem that are not deletion-related, including standard decomposability
(DSP), extended decomposability (eDSP), $C(n)$-decomposability
($C(n)$-DSP), and merge decomposability (MDSP). We consider ISAM,
TrieSpline~\cite{plex}, and succinct trie~\cite{zhang18} to be examples
of MDSPs because the data structures can be constructed more efficiently
from sorted data, and so when building from existing blocks, the data
is already sorted in each block and can be merged while maintaining
a sorted order more efficiently. VP-trees~\cite{vptree} and alias
structures~\cite{walker74}, in contrast, don't have a convenient
way of merging, and so must be reconstructed in full each time. We
have classified sampling queries in this taxonomy as eDSPs because
this implementation is more efficient than the $C(n)$-decomposable
variant we have also discussed. $k$-NN, for reasons discussed in
Chapter~\ref{chap:background}, are classified as $C(n)$-decomposable.

The classification of range scans is a bit trickier. It is not uncommon
in the theoretical literature for range scans to be considered DSPs, with
$\mergeop$ taken to be the set union operator. From an implementation
standpoint, it is sometimes possible to perform a union in $\Theta(1)$
time. For example, in Chapter~\ref{chap:sampling} we accomplished this by
placing sampled records directly into a shared buffer, and not having an
explicit combine step at all. However, in the general case where we do
need an explicit combine step, the union operation does require linear
time in the size of the result sets to copy the records from the local
result into the final result. The sizes of these results are functions
of the selectivity of the range scan, but theoretically could be large
relative to the data size, and so we've decided to err on the side of
caution and classify range scans as $C(n)$-decomposable here. If the
results of the range scan are expected to be returned in sorted order,
then the problem is \emph{certainly} $C(n)$-decomposable.
Range
counts, on the other hand, are truly DSPs.\footnote{
    Because of the explicit combine interface we use for eDSPs, the
    optimization of writing samples directly into the buffer that we used
    in the previous chapter to get a $\Theta(1)$ set union cannot be used
    for the eDSP implementation of IRS in this chapter. However, our eDSP
    sampling in Algorithm~\ref{alg:edsp-irs} samples \emph{exactly} $k$
    records, and so the combination step still only requires $\Theta(k)$
    work, and the complexity remains the same.
} Point lookups are an example of a DSP as well, assuming that the lookup
key is unique, or at least minimally duplicated. In the case where
the number of results for the lookup become a substantial proportion
of the total data size, then this search problem could be considered
$C(n)$-decomposable for the same reason as range scans.

Figure~\ref{fig:taxonomy-deletes} shows the various classes of search
problem relevant to delete support. We have made the decision to
classify invertible problems (INV) as a subset of deletion decomposable
problems (DDSP), because one could always embed the ghost structure
directly into the block implementation, use the DDSP delete operation
to insert into that block, and handle the $\Delta$ operator as part of
$\mathbftt{local\_query}$. We consider range count to be invertible,
with $\Delta$ taken to be subtraction. Range scans are also invertible,
technically, but the cost of filtering out the deleted records during
result set merging is relatively expensive, as it requires either
performing a sorted merge of all of the records (rather than a simple
union) to cancel out records with their ghosts, or doing a linear
search for each ghost record to remove its corresponding data from the
result set.  As a result, we have classified them as DDSPs instead,
as weak deletes are easily supported during range scans with no extra
cost. Any records marked as deleted can simply be skipped over when
copying into the local or final result sets. Similarly, $k$-NN queries
admit a DDSP solution for certain data structures, but we've elected to
classify them as IDSPs using Algorithm~\ref{alg:idsp-knn} as this is
possible without making any modifications to the data structure to support
weak deletes, and not all metric indexing structures support efficient
point lookups that would be necessary to support weak deletes. We've also
classified IRS as an IDSP, which is the only place in the taxonomy that
it can fit. Note that IRS (and other sampling problems) are unique in this
model in that they require the IDSP classification, but must actually
support deletes using weak deletes. There's no way to support ghost structure
based deletes in our general framework for sampling queries.\footnote{
    This is in contrast to the specialized framework for sampling in
    Chapter~\ref{chap:sampling}, where we heavily modified the query
    process to make tombstone (which is analogous to ghost structure)
    based deletes possible.
}

\section{Dynamization Framework}

With the previously discussed new classes of search problems devised, we
can now present our generalized framework based upon those models. This
framework takes the form of a header-only C++20 library which can
automatically extend data structures with support for concurrent inserts
and deletes, depending upon the classification of the problem in the
taxonomy of Figure~\ref{fig:taxonomy}. The user provides the data
structure and query implementations as template parameters, and the
framework then provides an interface that allows for queries, inserts,
and deletes against the new dynamic structure. Specifically, in addition
to accessors for various structural information, the framework provides
the following main operations,

\begin{itemize}
\item \texttt{int insert(RecordType); } \\
    This function will insert a record into the dynamized structure,
    and will return $1$ if the record was successfully inserted, and $0$
    if it was not. Insertion failure is part of the concurrency control
    mechanism, and failed inserts should be retried after a short delay.
    More details of this are in Section~\ref{ssec:dyn-concurrency}.

\item \texttt{int erase(RecordType);} \\
    This function will delete a record from the dynamized structure,
    returning $1$ on success and $0$ on failure. The meaning of a
    failure to delete is dependent upon the delete mechanism in use,
    and will be discussed in Section~\ref{ssec:dyn-deletes}.

\item \texttt{std::future query(QueryParameters); } \\
    This function will execute a query with the specified parameters
    against the structure and return the result. This interface is
    asynchronous, and returns a future immediately, which can be used
    to access the query result once the query has finished executing.

\end{itemize}

It can be configured with a template argument to run in single-threaded
mode, or multi-threaded mode. In multi-threaded mode, the above routines
can be called concurrently without any necessary synchronization in
user code, and without requiring any special modification to the data
structure and queries, beyond those changes necessary to use them in
single-threaded mode.

\subsection{Basic Principles}

Before discussing the interfaces that the user must implement to
use their code with our framework, it seems wise to discuss the
high level functioning and structure of the framework, the details
of which inform certain decisions about the necessary features
that the user must implement to interface with it. The high level
structure and organization of the framework is similar to that of
Section~\ref{ssec:sampling-framework}.

The framework requires the user to specify types to represent the
record, query, and data structure (which we call a shard). The
details of the interface requirements for these types are discussed in
Section~\ref{ssec:dyn-interface}, and are enforced using C++20's concepts
mechanism.

\begin{figure}
    \centering %\vspace{-3mm}
	\subfloat[\small Leveling]{\includegraphics[width=.5\textwidth]{diag/leveling} \label{fig:dyn-leveling}}
	%\vspace{-3mm}
	\subfloat[\small Tiering]{\includegraphics[width=.5\textwidth]{diag/tiering} \label{fig:dyn-tiering}}
	%\vspace{-3mm}
    \caption{\small An overview of the general structure of the
    dynamization framework using (a) leveling and
    (b) tiering layout policies, with a scale factor 3. 
    Each shard is shown as a 
    dotted box, wrapping its associated dataset ($D_i$) and index ($I_i$). }
	\label{fig:dyn-framework}
	%\vspace{-3mm}
\end{figure}

Internally, the framework consists of a sequence of \emph{levels} with
increasing record capacity, each containing one or more \emph{shards}. The
layout of these levels is defined by a template argument, the \emph{layout
policy}, and an integer called the \emph{scale factor}. The latter governs
how quickly the record capacities of each level grow, and the former
controls how those records are broken into shards on the level and the
way in which records move from level to level during reconstructions. The
details of layout policies, reconstruction, etc., will be discussed in
a later section.

Logically ``above'' these levels is a small unsorted array, called the
\emph{mutable buffer}. The mutable buffer is of user-configurable size,
and all inserts into the structure are first placed into it. When
the buffer fills, it will be flushed into the structure, requiring
reconstructions to occur in a manner consistent with the layout policy
in order to make room. A simple graphical representation of the framework
and two of its layout policies is shown in Figure~\ref{fig:dyn-framework}.

The framework provides two mechanisms for supporting deletes: tagging
and tombstones. These are identical to the mechanisms discussed in
Section~\ref{ssec:sampling-deletes}, with tombstone deletes operating by
inserting a record identicle to the one to be deleted into the structure,
with an indicator bit set in the header, and tagged deletes performing
a lookup of the record to be deleted in the structure and setting
a bit in its header directly. Tombstone deletes are used to support
invertible search problems, and tagged deletes are used for deletion
decomposable search problems. While the delete procedure itself is handled
automatically by the framework based upon the specified mechanism, it is
the user's responsible to appropriately handle deleted records in their
query and shard implementations.


\subsection{Interfaces}
\label{ssec:dyn-interface}

In order to enforce interface requirements, our implementation takes
advantage of C++20 concepts. There are three major sets of interfaces
that the user of the framework must implement: records, shards, and
queries. We'll discuss each of these in this section.

\subsubsection{Record Interface}

The record interface is the simplest of the three. The type used as a
record only requires an implementation of an equality comparison operator,
and is assumed to be of fixed length. Beyond this, the framework places
no additional constraints and makes no assumptions about record contents,
their ordering properties, etc. Though the records must be fixed length,
variable length data can be supported using off-record storage and
pointers if necessary. Each record is automatically wrapped by the
framework with a header that is used to facilitate deletion support.
The record concept is shown in Listing~\ref{lst:record}, along with
the wrapped header type that is used to interact with records within
the framework.

\begin{lstfloat}
\begin{lstlisting}[language=C++]
template 
concept RecordInterface = requires(R r, R s) {
  { r == s } -> std::convertible_to;
};


template  struct Wrapped {
  uint32_t header;
  R rec;

  inline void set_delete();
  inline bool is_deleted() const; 
  inline void set_tombstone(bool val);
  inline bool is_tombstone() const;

  inline bool operator==(const Wrapped &other) const;
};
\end{lstlisting}
\caption{The required interface for record types in our dynamization framework.}
\label{lst:record}
\end{lstfloat}

\subsubsection{Shard Interface}

Our framework's underlying representation of the data structure is called
a \emph{shard}. The provided shard structure should provide either a full
implementation of the data structure to be dynamized, or a shim around
an existing implementation that provides the necessary functions for our
framework to interact with it. Shards must provide two constructors:
one from an unsorted set of records, and another from a set of other
shards of the same type. The second of these constructors is to allow for
efficient merging to be leveraged for merge decomposable search problems.

Shards can also expose a point lookup operation for use in supporting
deletes for DDSPs. This function is only used for DDSP deletes, and so can
be left off when this functionality isn't necessary. If a data structure
doesn't natively support an efficient point-lookup, then it can be added
by including a hash table or other data structure in the shard if desired.
This function accepts a record type as input, and should return a pointer
to the record that exactly matches the input in storage, if one exists,
or \texttt{nullptr} if it doesn't. It should also accept an optional
boolean argument that the framework will pass \texttt{true} into if it
is don't a lookup for a tombstone. This flag is to allow the shard to
use various tombstone-related optimization, such as using a Bloom filter
for them, or storing them seperately from the main records, etc.

Shards should also expose some accessors for basic meta-data about
its contents. In particular, the framework is reliant upon a function
that returns the number of records within the shard for planning
reconstructions, and the number of deleted records or tombstones within
the shard for use in proactive compaction to bound the number of deleted
records. The interface also requires functions for accessing memory
usage information, both the memory use for the main data structure
being dynamized, and also any auxilliary memory (e.g., memory used
for an auxiliary hash table). These memory functions are used only for
informational purposes.

The concept for shard types is shown in Listing~\ref{lst:shard}. Note
that all records within shards are wrapped by the framework header. It
is up to the shard to handle the removal of deleted records based on
this information during reconstruction.

\begin{lstfloat}
\begin{lstlisting}[language=C++]

template 
concept ShardInterface = RecordInterface 
  && requires(SHARD shard, const std::vector &shard_vector,
              bool b, BufferView bv,
              typename SHARD::RECORD rec) {
  {SHARD(shard_vector)};
  {SHARD(std::move(bv))};

  {
    shard.point_lookup(rec, b)
    } -> std::same_as *>;

  { shard.get_record_count() } -> std::convertible_to;
  { shard.get_tombstone_count() } -> std::convertible_to;
  { shard.get_memory_usage() } -> std::convertible_to;
  { shard.get_aux_memory_usage() } -> std::convertible_to;

};
\end{lstlisting}
\label{listing:shard}
\caption{The required interface for shard types in our dynamization
framework.}
\end{lstfloat}


\subsubsection{Query Interface}

The most complex interface required by the framework is for queries. The
concept for query types is given in Listing~\ref{listing:query}. In
effect, it requires implementing the full IDSP interface from the
previous section, as well as versions of $\mathbftt{local\_preproc}$
and $\mathbftt{local\query}$ for pre-processing and querying an unsorted
set of records, which is necessary to allow the mutable buffer to be
used as part of the query process.\footnote{
    In the worst case, these routines could construct temporary shard
    over the mutable buffer, and use this to answer queries.
} The $\mathbftt{repeat}$ function is necessary even for
normal eDSP problems, and should just return \texttt{false} with no other
action in those cases. The interface also allows the user to specify
whether the query process should abort after the first result is obtained,
which is a useful optimization for point lookups.

This interface allows for the local and overall query results to be
independently specified of different types. This can be used for a
variety of purposes. For example, an invertible range count can have
a local result that includes both the number of records and the number
of tombstones, while the query result itself remains a single number.
Additionally, the framework makes no decision about what, if any,
collection type should be used for these results. A range scan, for
example, could specified the result types as a vector of records, map
of records, etc., depending on the use case.

There is one significant difference between the IDSP interface and the
query concept implementation. For efficiency purposes, \texttt{combine}
does not return the query result object. Instead, the framework
itself initializes the object, and then passes it by reference into
\texttt{combine}. This is necessary because \texttt{combine} can be called
multiple times, depending on whether the query must be repeated. Adding
it as an argument to \texttt{combine}, rather than returning it,
allows for the local query results to be discarded completely, and new
results generated and added to the existing result set, in the case
of a repetition. Without this modification, the user would either need
to define an additional combination operation for final result types,
or duplicate effort in the combine step on each repetition.

\begin{lstfloat}

\begin{lstlisting}[language=C++]

template 
concept QueryInterface =
    requires(PARAMETERS *parameters, LOCAL *local, LOCAL_BUFFER *buffer_query,
             SHARD *shard, std::vector &local_queries,
             std::vector &local_results, RESULT &result,
             BufferView *bv) {
      {
        QUERY::local_preproc(shard, parameters)
      } -> std::convertible_to;

      {
        QUERY::local_preproc_buffer(bv, parameters)
      } -> std::convertible_to;

      { QUERY::distribute_query(parameters, local_queries, buffer_query) };

      { QUERY::local_query(shard, local) } -> std::convertible_to;

      {
        QUERY::local_query_buffer(buffer_query)
      } -> std::convertible_to;

      { QUERY::combine(local_results, parameters, result) };

      {
        QUERY::repeat(parameters, result, local_queries, buffer_query)
      } -> std::same_as;

      { QUERY::EARLY_ABORT } -> std::convertible_to;
    };
\end{lstlisting}

\label{listing:query}
\caption{The required interface for query types in our dynamization
framework.}
\end{lstfloat}


\subsection{Internal Mechanisms}

\subsubsection{Inserts and Layout Policy}

\begin{algorithm}[t]
	\caption{Insertion with Dynamization Framework}
	\label{algo:insert}
	\KwIn{$r$: new record to insert}
	\If{\texttt{buffer is not full}}{
		$\texttt{buffer.append}(r)$\;
		\Return
	}
	$\texttt{idx} \gets 0$\;
	\For{$i \gets 0 \cdots \texttt{n\_levels}$}{
		\If{$\texttt{level}_i \texttt{ can hold records in }\texttt{level}_{i - 1}$}{
			\texttt{idx} = i\;
			\Break\;
		}
	}
	\For{$i \gets \texttt{idx} \cdots 1$}{
        \If{layout\_policy = \texttt{LEVELING}} {
            $\texttt{level}_i \gets
            \texttt{merge\_shards}(\texttt{level}_i, \texttt{level}_{i - 1})$ \;
        }

        \If{layout\_policy = \texttt{TIERING}} {
            $\texttt{new\_shard} \gets \texttt{merge\_shards}(\texttt{level}_{i-1})$ \;
            $\texttt{level}_i \gets \texttt{add\_shard}(\texttt{level}_i, \texttt{new\_shard})$  \;
        }
	}
    $\texttt{level}_0 \gets \texttt{add\_shard}(\texttt{level}_0, \texttt{build\_shard}(\texttt{buffer}))$\;
	$\texttt{buffer.append}(r)$\;
	\Return
\end{algorithm}


\Paragraph{Asymptotic Complexity.}

\subsubsection{Delete Policy}

\Paragraph{Asymptotic Complexity.}

\Paragraph{Asymptotic Complexity.}

\subsubsection{Queries}


\begin{algorithm}[t]
	\caption{Query with Dynamization Framework}
	\label{algo:query-framework}
	\KwIn{$q$: query parameters, $b$: mutable buffer, $S$: static index shards at all levels}
	\KwOut{$R$: query results}
	
    $\mathscr{S}_b \gets \texttt{local\_preproc}_{buffer}(b, q);\ \ \mathscr{S} \gets \{\}$ \;
    \For{$s \in S$}{$\mathscr{S} \gets \mathscr{S}\ \cup (s, \texttt{local\_preproc}(s, q))$\;}
    $(q_b, q_1, \ldots q_m) \gets \texttt{distribute\_query}(\mathscr{S}_b, \mathscr{S}, q)$ \;
    $\mathcal{R} \gets \{\}; \ \ \texttt{rpt} \gets \bot$ \;
    \Do{\texttt{rpt}}{
		$locR \gets \{\}$ \;
        $locR \gets locR \cup \texttt{local\_query}_{buffer}(b, q_b)$ \;
        % the subscript in this one is wonky. Maybe do an array of Qs?
		\For{$s \in S$}{$locR \gets locR \cup \texttt{local\_query}(s, q_s)$}
        %\Comment{For \red{name}, use \texttt{tombstone\_lookup} to remove all deleted records. }
		%\If{\textbf{not} \texttt{SKIP\_DELETE\_FILTER}}{$locR \gets \texttt{filter\_deletes}(locR, S)$}
        $\mathcal{R} \gets \mathcal{R} \cup \texttt{combine}(locR, q_b, q_1, \ldots, q_m)$\;
        $(\texttt{rpt}, q_b, q_1, \ldots,
        q_m) \gets \texttt{repeat}(q, \mathcal{R}, q_b, q_1,\ldots, q_m)$\;
	}
    \Return{$\mathcal{R}$}
	
\end{algorithm}

\Paragraph{Asymptotic Complexity.}

\subsection{Concurrency Control}

\section{Evaluation}
\subsection{Experimental Setup}
\subsection{Design Space Evaluation}

\begin{figure}
	%\vspace{0pt}
	\centering
    \subfloat[Insertion Throughput \\ vs. Buffer Size]{\includegraphics[width=.4\textwidth]{img/fig-ps-mt-insert} \label{fig:ins-buffer-size}}
	\subfloat[Insertion Throughput \\ vs. Scale Factor]{\includegraphics[width=.4\textwidth]{img/fig-ps-sf-insert} \label{fig:ins-scale-factor}}
    \\ %\vspace{-2mm}
    \subfloat[Query Latency vs. Buffer Size]{\includegraphics[width=.4\textwidth]{img/fig-ps-mt-query} \label{fig:q-buffer-size}}
	\subfloat[Query Latency vs. Scale Factor]{\includegraphics[width=.4\textwidth]{img/fig-ps-sf-query} \label{fig:q-scale-factor}}
	%\vspace{-2mm}
    \caption{Design Space Evaluation (Triespline)}
    %\vspace{-2mm}
\end{figure}


\subsection{Independent Range Sampling}

\begin{figure*}
	%\vspace{0pt}
	\centering
	\subfloat[Update Throughput]{\includegraphics[width=.32\textwidth, trim=5mm 5mm 0 0]{img/fig-bs-irs-insert} \label{fig:irs-insert}}
	\subfloat[Query Latency]{\includegraphics[width=.32\textwidth, trim=5mm 5mm 0 0]{img/fig-bs-irs-query} \label{fig:irs-query}} 
	\subfloat[Index Overhead]{\includegraphics[width=.32\textwidth, trim=5mm 5mm 0 0]{img/fig-bs-irs-space} \label{fig:irs-space}}
	%\vspace{-3mm}
	\caption{IRS Index Evaluation}
	\label{fig:irs}
	%\vspace{-6mm}
\end{figure*}


\begin{align*}
    \text{Insert:} \quad &\Theta\left(\log_s n\right) \\
    \text{Query:}  \quad &\Theta\left(\log_s n \log_f n + \frac{k}{1 - \delta}\right) \\
    \text{Delete:} \quad &\Theta\left(\log_s n \log_f n\right)
\end{align*}


\subsection{k-NN Search}

\begin{figure*}
		\subfloat[Update Throughput]{\includegraphics[width=.32\textwidth, trim=5mm 5mm 0 0]{img/fig-bs-knn-insert} \label{fig:knn-insert}}
		\subfloat[Query Latency]{\includegraphics[width=.32\textwidth, trim=5mm 5mm 0 0]{img/fig-bs-knn-query} \label{fig:knn-query}} 
		\subfloat[Index Overhead]{\includegraphics[width=.32\textwidth, trim=5mm 5mm 0 0]{img/fig-bs-knn-space} \label{fig:knn-space}} 
		%\vspace{-3mm}
        \caption{k-NN Index Evaluation}
        %\vspace{-3mm}
        \label{fig:knn-eval}
\end{figure*}


\begin{align*}
    \text{Insert:} \quad &\Theta\left(\log_s n\right) \\
    \text{Query:}  \quad &\Theta\left(N_B + \log n \log_s n\right ) \\
    \text{Delete:} \quad &\Theta\left(\log_s n \right)
\end{align*}

\subsection{Range Scan}

\begin{figure*}
		\centering
		\subfloat[Update Throughput]{\includegraphics[width=.32\textwidth, trim=5mm 5mm 0 0]{img/fig-bs-rq-insert} \label{fig:rq-insert}}
		\subfloat[Query Latency]{\includegraphics[width=.32\textwidth, trim=5mm 5mm 0 0]{img/fig-bs-rq-query} \label{fig:rq-query}} 
		\subfloat[Index Overhead]{\includegraphics[width=.32\textwidth, trim=5mm 5mm 0 0]{img/fig-bs-rq-space} \label{fig:rq-space}} 
        %\vspace{-3mm}
		\caption{Learned Index Evaluation}
		%\vspace{-3mm}
		\label{fig:eval-learned-index}
\end{figure*}

\subsection{String Search}

\begin{figure*}
    \centering
	\subfloat[Update Throughput]{\includegraphics[width=.32\textwidth, trim=5mm 2mm 0 0]{img/fig-bs-fst-insert} \label{fig:fst-insert}} 
	\subfloat[Query Latency]{\includegraphics[width=.32\textwidth, trim=5mm 2mm 0 0]{img/fig-bs-fst-query} \label{fig:fst-query}} 
	\subfloat[Index Overhead]{\includegraphics[width=.32\textwidth, trim=5mm 2mm 0 0]{img/fig-bs-fst-space} \label{fig:fst-size}} 
    %\vspace{-3mm}
    \caption{FST Evaluation}
    %\vspace{-5mm}
\end{figure*}

\begin{align*}
    \text{Insert:} \quad &\Theta\left(\log_s n\right) \\
    \text{Query:}  \quad &\Theta\left(N_B + \log n \log_s n\right ) \\
    \text{Delete:} \quad &\Theta\left(\log_s n \right)
\end{align*}

\subsection{Concurrency}

\begin{figure}
    \centering
	%\vspace{-2mm}
	\includegraphics[width=.5\textwidth]{img/fig-bs-irs-concurrency} 
	%\vspace{-2mm}
	\caption{IRS Thread Scaling}
	\label{fig:irs-concurrency}
	%\vspace{-2mm}
\end{figure}

\section{Conclusion}