diff options
Diffstat (limited to 'chapters/sigmod23/framework.tex')
| -rw-r--r-- | chapters/sigmod23/framework.tex | 48 |
1 files changed, 24 insertions, 24 deletions
diff --git a/chapters/sigmod23/framework.tex b/chapters/sigmod23/framework.tex index 0f3fac8..2f2515b 100644 --- a/chapters/sigmod23/framework.tex +++ b/chapters/sigmod23/framework.tex @@ -1,7 +1,7 @@ \section{Dynamization of SSIs} \label{sec:framework} -Our goal, then, is to design a solution to indepedent sampling that is +Our goal, then, is to design a solution to independent sampling that is able to achieve \emph{both} efficient updates and efficient sampling, while also maintaining statistical independence both within and between IQS queries, and to do so in a generalized fashion without needing to @@ -98,7 +98,7 @@ define the decomposability conditions for a query sampling problem, \end{enumerate} \end{definition} -These two conditions warrant further explaination. The first condition +These two conditions warrant further explanation. The first condition is simply a redefinition of the standard decomposability criteria to consider matching the distribution, rather than the exact records in $R$, as the correctness condition for the merge process. The second condition @@ -114,7 +114,7 @@ problems. First, we note that many SSIs have a sampling procedure that naturally involves two phases. First, some preliminary work is done to determine metadata concerning the set of records to sample from, and then $k$ samples are drawn from the structure, taking advantage of -this metadata. If we represent the time cost of the prelimary work +this metadata. If we represent the time cost of the preliminary work with $P(n)$ and the cost of drawing a sample with $S(n)$, then these structures query cost functions are of the form, @@ -213,7 +213,7 @@ $k$ records have been sampled. \end{example} Assuming a Bentley-Saxe decomposition with $\log n$ blocks and assuming -a constant number of repetitions, the cost of answering a decomposible +a constant number of repetitions, the cost of answering a decomposable sampling query having a pre-processing cost of $P(n)$, a weight-determination cost of $W(n)$ and a per-sample cost of $S(n)$ will be, \begin{equation} @@ -241,7 +241,7 @@ satisfied by either the search problem or data structure. Unfortunately, neither approach can work as a ``drop-in'' solution in the context of sampling problems, because of the way that deleted records interact with the sampling process itself. Sampling problems, as formalized here, -are neither invertable, nor deletion decomposable. In this section, +are neither invertible, nor deletion decomposable. In this section, we'll discuss our mechanisms for supporting deletes, as well as how these can be handled during sampling while maintaining correctness. @@ -397,7 +397,7 @@ Section~\ref{sec:sampling-implementation}. \subsubsection{Bounding Rejection Probability} -When a sampled record has been rejected, it must be resampled. This +When a sampled record has been rejected, it must be re-sampled. This introduces performance overhead resulting from extra memory access and random number generations, and hurts our ability to provide performance bounds on our sampling operations. In the worst case, a structure @@ -413,7 +413,7 @@ we have the opportunity to remove deleted records. This will cause the record counts associated with each block of the structure to gradually drift out of alignment with the "perfect" powers of two associated with the Bentley-Saxe method, however. In the theoretical literature on this -topic, the solution to this problem is to periodically repartition all of +topic, the solution to this problem is to periodically re-partition all of the records to re-align the block sizes~\cite{merge-dsp, saxe79}. This approach could also be easily applied here, if desired, though we do not in our implementations, for reasons that will be discussed in @@ -449,7 +449,7 @@ is not sufficient. Fortunately, this passive system can be used as the basis for a system that does provide a bound. This is because it guarantees, whether tagging or tombstones are used, that any given deleted -record will \emph{eventually} be cancelled out after a finite number +record will \emph{eventually} be canceled out after a finite number of reconstructions. If the number of deleted records gets too high, some or all of these deleted records can be cleared out by proactively performing reconstructions. We call these proactive reconstructions @@ -524,7 +524,7 @@ that is both tunable, and generally more performant, at the cost of some additional theoretical complexity. There has been some theoretical work in this area, based upon nesting instances of the equal block method within the Bentley-Saxe method~\cite{overmars81}, but these methods are -unwieldy and are targetted at tuning the worst-case at the expense of the +unwieldy and are targeted at tuning the worst-case at the expense of the common case. We will take a different approach to adding configurability to our dynamization system. @@ -532,7 +532,7 @@ Though it has thus far gone unmentioned, some readers may have noted the astonishing similarity between decomposition-based dynamization techniques, and a data structure called the Log-structured Merge-tree. First proposed by O'Neil in the mid '90s\cite{oneil96}, -the LSM Tree was designed to optmize write throughout for external data +the LSM Tree was designed to optimize write throughout for external data structures. It accomplished this task by buffer inserted records in a small in-memory AVL Tree, and then flushing this buffer to disk when it filled up. The flush process itself would fully rebuild the on-disk @@ -543,13 +543,13 @@ layered, external structures, to reduce the cost of reconstruction. In more recent times, the LSM Tree has seen significant development and been used as the basis for key-value stores like RocksDB~\cite{dong21} and LevelDB~\cite{leveldb}. This work has produced an incredibly large -and well explored parameterization of the reconstruction procedures of +and well explored parametrization of the reconstruction procedures of LSM Trees, a good summary of which can be bound in this recent tutorial paper~\cite{sarkar23}. Examples of this design space exploration include: different ways to organize each "level" of the tree~\cite{dayan19, -dostoevsky, autumn}, different growth rates, buffering, sub-partioning +dostoevsky, autumn}, different growth rates, buffering, sub-partitioning of structures to allow finer-grained reconstruction~\cite{dayan22}, and -approaches for allocating resources to auxilliary structures attached to +approaches for allocating resources to auxiliary structures attached to the main ones for accelerating certain types of query~\cite{dayan18-1, zhu21, monkey}. @@ -561,7 +561,7 @@ following four elements for use in our dynamization technique, \begin{itemize} \item A small dynamic buffer into which new records are inserted \item A variable growth rate, called as \emph{scale factor} - \item The ability to attach auxilliary structures to each block + \item The ability to attach auxiliary structures to each block \item Two different strategies for reconstructing data structures \end{itemize} This design space and its associated trade-offs will be discussed in @@ -585,28 +585,28 @@ $N_B \cdot 2^i$ records in the $i$th block. We call this unsorted array the \emph{mutable buffer}. \Paragraph{Scale Factor.} In the Bentley-Saxe method, each block is -twice as large as the block the preceeds it There is, however, no reason +twice as large as the block the precedes it There is, however, no reason why this growth rate couldn't be adjusted. In our system, we make the growth rate a user-specified constant called the \emph{scale factor}, $s$, such that the $i$th level contains $N_B \cdot s^i$ records. -\Paragraph{Auxilliary Structures.} In Section~\ref{ssec:sampling-deletes}, +\Paragraph{Auxiliary Structures.} In Section~\ref{ssec:sampling-deletes}, we encountered two problems relating to supporting deletes that can be -resolved through the use of auxilliary structures. First, regardless +resolved through the use of auxiliary structures. First, regardless of whether tagging or tombstones are used, the data structure requires support for an efficient point-lookup operation. Many SSIs are tree-based and thus support this, but not all data structures do. In such cases, -the point-lookup operation could be provided by attaching an auxilliary +the point-lookup operation could be provided by attaching an auxiliary hash table to the data structure that maps records to their location in the SSI. We use term \emph{shard} to refer to the combination of a -block with these optional auxilliary structures. +block with these optional auxiliary structures. In addition, the tombstone deletion mechanism requires performing a point lookup for every record sampled, to validate that it has not been deleted. This introduces a large amount of overhead into the sampling process, as this requires searching each block in the structure. One approach that can be used to help improve the performance of these searches, -without requiring as much storage as adding auxilliary hash tables to +without requiring as much storage as adding auxiliary hash tables to every block, is to include bloom filters~\cite{bloom70}. A bloom filter is an approximate data structure that answers tests of set membership with bounded, single-sided error. These are commonly used in LSM Trees @@ -687,7 +687,7 @@ s^{i+1}$ records. If tiering is used, each level will contain up to $s$ SSIs, each with up to $N_B \cdot s^i$ records. The scale factor, $s$, controls the rate at which the capacity of each level grows. The framework supports deletes using either the tombstone or tagging policy, -which can be selected by the user acccording to her preference. To support +which can be selected by the user according to her preference. To support these delete mechanisms, each record contains an attached header with bits to indicate its tombstone or delete status. @@ -735,7 +735,7 @@ compaction is complete, the delete proportions are checked again, and this process is repeated until all levels satisfy the bound. Following this procedure, inserts have a worst case cost of $I \in -\Theta(B_M(n))$, equivalent to Bently-Saxe. The amortized cost can be +\Theta(B_M(n))$, equivalent to Bentley-Saxe. The amortized cost can be determined by finding the total cost of reconstructions involving each record and amortizing it over each insert. The cost of the insert is composed of three parts, @@ -773,7 +773,7 @@ cost of a delete is the same as cost of doing a point lookup, as the "delete" itself is simply setting a bit in the header of the record, once it has been located. There will be $\Theta(\log_s n)$ total shards in the structure, each with a look-up cost of $L(n)$ using either the -SSI's native point-lookup, or an auxilliary hash table, and the lookup +SSI's native point-lookup, or an auxiliary hash table, and the lookup must also scan the buffer in $\Theta(N_B)$ time. Thus, the worst-case cost of a tagged delete is, \begin{equation*} @@ -792,7 +792,7 @@ to sample from the unsorted buffer as well. There are two approaches for sampling from the buffer. The most general approach would be to temporarily build an SSI over the records within the buffer, and then treat this is a normal shard for the remainder of the sampling procedure. -In this case, the sampling algorithm remains indentical to the algorithm +In this case, the sampling algorithm remains identical to the algorithm discussed in Section~\ref{ssec:decomposed-structure-sampling}, following the construction of the temporary shard. This results in a worst-case sampling cost of, |