updates

1 files changed, 8 insertions, 8 deletions

diff --git a/chapters/sigmod23/framework.tex b/chapters/sigmod23/framework.tex
index b3a8215..1eb2589 100644
--- a/chapters/sigmod23/framework.tex
+++ b/chapters/sigmod23/framework.tex
@@ -512,19 +512,19 @@ 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 optimize write throughput for external data
+the LSM tree was designed to optimize write throughput 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
+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
-structure (a B+Tree), including all of the currently existing records
+structure (a B+tree), including all of the currently existing records
 on external storage. O'Neil also proposed version which used several,
 layered, external structures, to reduce the cost of reconstruction.
 
-In more recent times, the LSM Tree has seen significant development and
+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 parametrization of the reconstruction
-procedures of LSM Trees, a good summary of which can be bounded in
+procedures of LSM trees, a good summary of which can be bounded 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
@@ -534,7 +534,7 @@ auxiliary structures attached to the main ones for accelerating certain
 types of query~\cite{dayan18-1, zhu21, monkey}. This work is discussed
 in greater depth in Chapter~\ref{chap:related-work}.
 
-Many of the elements within the LSM Tree design space are based upon the
+Many of the elements within the LSM tree design space are based upon the
 specifics of the data structure itself, and are not applicable to our
 use case.  However, some of the higher-level concepts can be imported and
 applied in the context of dynamization. Specifically, we have decided to
@@ -590,7 +590,7 @@ that can be used to help improve the performance of these searches,
 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
+with bounded, single-sided error. These are commonly used in LSM trees
 to accelerate point lookups by allowing levels that don't contain the
 record being searched for to be skipped. In our case, we only care about
 tombstone records, so rather than building these filters over all records,
@@ -599,7 +599,7 @@ the sampling performance of the structure when tombstone deletes are used.
 
 \Paragraph{Layout Policy.} The Bentley-Saxe method considers blocks
 individually, without any other organization beyond increasing
-size. In contrast, LSM Trees have multiple layers of structural
+size. In contrast, LSM trees have multiple layers of structural
 organization. Record capacity restrictions are enforced on structures
 called \emph{levels}, which are partitioned into individual data
 structures, and then further organized into non-overlapping key ranges.