Interactive Data Exploration Using Semantic Windows
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Interactive Data Exploration Using
Semantic Windows
Alexander Kalinin Ugur Cetintemel Stan Zdonik
Brown University Brown University Brown University
akalinin@cs.brown.edu ugur@cs.brown.edu sbz@cs.brown.edu
ABSTRACT
We present a new interactive data exploration approach,
called Semantic Windows (SW), in which users query for
multidimensional “windows” of interest via standard DBMS-
style queries enhanced with exploration constructs. Users
can specify SWs using (i) shape-based properties, e.g., “iden-
tify all 3-by-3 windows”, as well as (ii) content-based proper-
ties, e.g., “identify all windows in which the average bright-
ness of stars exceeds 0.8”. This SW approach enables the Figure 1: Exploration queries searching for bright
interactive processing of a host of useful exploratory queries star clusters (left) and periods of high average stock
that are difficult to express and optimize using standard prices (right). Some results are highlighted.
DBMS techniques.
SW uses a sampling-guided, data-driven search strategy to Unfortunately, traditional DBMSs are designed and opti-
explore the underlying data set and quickly identify windows mized for supporting neither interactive operation nor ex-
of interest. To facilitate human-in-the-loop style interactive ploratory queries. Users typically have to write very com-
processing, SW is optimized to produce online results dur- plex queries (e.g., in SQL), which are hard to optimize and
ing query execution. To control the tension between online execute efficiently. Moreover, users often have to wait until
performance and query completion time, it uses a tunable, a query finishes without getting any intermediate (online)
adaptive prefetching technique. To enable exploration of big results, which is often sufficient for exploratory purposes.
data, the framework supports distributed computation. Consider the following data exploration framework. A
We describe the semantics and implementation of SW as user examines a multidimensional data space by posing a
a distributed layer on top of PostgreSQL. The experimental number of queries that find rectangular regions of the data
results with real astronomical and artificial data reveal that space the user is interested in. We call such regions windows.
SW can offer online results quickly and continuously with After getting some results, the user might decide to stop the
little or no degradation in query completion times. current query and move to the next one. Or she might want
to study some of the results more closely by making any of
Categories and Subject Descriptors them the new search area and asking for more details. Let
us look at two illustrative examples in Figure 1.
H.2.4 [Database Management]: Systems—query process-
ing Example 1. A user wants to study a data set containing
information about stars and other objects in the sky (e.g.,
Keywords SDSS [1]). She wants to find a rectangular region in the sky
satisfying the following properties:
Data exploration; Query processing • The shape of the region must be 3◦ by 2◦ , assuming an-
gular coordinates (e.g., right ascension and declination).
1. INTRODUCTION • The average brightness of all stars within the region must
The amount of data stored in database systems has been be greater than 0.8.
constantly increasing over the past years. Users would like
The example above describes a spatial exploration case,
to perform various exploration tasks with interactive speeds.
where windows of interest correspond to two-dimensional
Permission to make digital or hard copies of all or part of this work for personal or regions of the sky. However, the framework can be used for
classroom use is granted without fee provided that copies are not made or distributed other cases, e.g., for one-dimensional time-based data:
for profit or commercial advantage and that copies bear this notice and the full citation
on the first page. Copyrights for components of this work owned by others than the Example 2. A user studies trading data for some com-
author(s) must be honored. Abstracting with credit is permitted. To copy otherwise, or pany. The search area represents stock values over a period
republish, to post on servers or to redistribute to lists, requires prior specific permission of time. The user wants to find a time interval (i.e., a one-
and/or a fee. Request permissions from permissions@acm.org. dimensional region) having the following properties:
SIGMOD’14, June 22–27, 2014, Snowbird, UT, USA
• The interval must be of length from 1 to 3 years.
Copyright is held by the owner/author(s). Publication rights licensed to ACM.
ACM 978-1-4503-2376-5/14/06 ...$15.00.
• The average of stock prices within the interval must be
http://dx.doi.org/10.1145/2588555.2593666. greater than 50.
By defining windows of interest in terms of their desired trees or R-trees. To estimate utilities we collect a sample of
properties, users can express a variety of exploration queries. the data offline and store it in the DBMS.
Such properties, which we call conditions, can be specified We conducted an experimental evaluation using synthetic
based on the shape of a window (e.g., the length of a time and real data. For the latter we used SDSS [1]. The experi-
interval) and an aggregate function of the data contained mental results show that in many cases our framework can
within (e.g., the average stock value within an interval). offer online results quickly and continuously, outperform-
Traditional SQL DBMSs cannot deal with the type of ing traditional DBMSs significantly. For the comparison we
queries presented here in an efficient and compact way. Avail- used a complex SQL query, mentioned above, and query
able constructs, such as GROUP BY and OVER, do not allow completion time of SW queries is often better. Due to the
users to define and explore all valid windows. Although it is complexity of the query, the query processor was not able
possible to express such queries with a SQL query involving to plan and execute it efficiently. However, even when the
a number of recursive Common Table Expressions (CTEs), framework performs worse in total time, the difference can
such a query would be difficult to optimize due to its com- be eliminated or significantly reduced by prefetching.
plexity. In summary, the proposed SW framework:
Another important requirement in data exploration is in- • Allows users to interactively explore data in terms of
teractivity. Since the amount of data users have to explore multidimensional windows and select interesting ones via
is generally large, it is important to provide online results. shape- and content-based predicates.
This allows the user to interrupt the query and modify it • Provides online results quickly, facilitating human-in-the-
to better reflect her interests. Moreover, many applications loop processing needed for interactive data exploration.
can be satisfied with a subset of results, without the need • Uses a data-driven search algorithm integrated with strat-
to compute all of them. Most SQL implementations do not ified sampling, adaptive prefetching and data placement
allow such functionality, making users wait for results until to offer interactive online performance without sacrificing
the entire query is finished. query completion times.
Our approach treats an exploration query as a data-driven • Offers a diversification approach that allows users to di-
search task. The search space consists of all possible win- rect the search for qualifying SWs in unexplored regions
dows, which can vary in size and overlap. We use a cost- of the search space, thus allowing the user to control the
benefit analysis to quantify a utility measure to rank the classical exploration vs. exploitation trade-off.
windows and decide on the order by which we will explore • Provides an efficient distributed execution framework that
them. We use sampling to estimate values for conditions on partitions the data space to allow parallelism while effec-
the data, which allows us to compute a distance from these tively dealing with partition boundaries.
values to the values specified in the query. We then guide The remainder of the paper is organized as follows. Sec-
the search using a utility estimate, which is a combination of tion 2 gives a formal description of the framework. Section
this distance, called benefit, and the cost of reading the cor- 3 describes extensions for SQL to support SW queries. Sec-
responding data from disk. We use shape-based conditions tion 4 gives a description of the algorithm and our prefetch-
to prune parts of the search space. ing technique. Section 5 talks about the architecture and
Since logical windows may not correspond to the physical implementation details. Section 6 provides results of the
placement of data on disk, reading multiple dispersed win- experimental evaluation. Section 7 reviews related work.
dows may result in a significant I/O overhead. The overhead Section 8 concludes the paper.
comes from seeks and reading the same data pages multiple
times. Thus there is a tension between online performance 2. SW MODEL AND QUERIES
and query completion time. To control this tension, we use a
Assume a data set S containing objects with attributes
prefetching technique: by prefetching additional data when
a1 , . . . , am (e.g., brightness, price, etc.) and coordinates
reading a window and thus decreasing the number of dis-
x1 , . . . , xn . Thus, S constitutes an n-dimensional search
persed reads, it is possible to reduce the overhead and fin-
area with dimensions d1 , . . . , dn . We will often specify S in
ish the query faster. However, this approach might result
terms of the intervals it spans (e.g., S = [L1 , U1 ) × [L2 , U2 )
in worse online performance, since delays for online results
for a two-dimensional data set). Next, we define a grid
might increase. To manage this trade-off, we use an adap-
on top of S. The grid GS is defined as a vector of steps:
tive prefetching algorithm that dynamically adjusts the size
(s1 , s2 , . . . , sn ). It divides each interval [Li , Ui ) into disjoint
of prefetching during execution. While new results are being
sub-intervals of size si , starting from Li : [Li , Li + si ) ∪ [Li +
discovered, we prefetch less to keep delays to a minimum.
si , Li + 2si ) ∪ · · · ∪ [Li + k · si , Ui ). The last sub-interval
When no new results can be found, we start to prefetch more
might have size less than si , which has no impact on the
to speed up the execution and finish the query faster. Ad-
discussion. Thus, S is divided into a number of disjoint
ditionally, we allow users to control the prefetching strategy
cells. The search space of an SW query consists of all pos-
to favor one side of the trade-off or the other.
sible windows. A window is a union of adjacent cells that
Our new framework, which we call Semantic Windows
constitutes an n-dimensional rectangle. Since the grid de-
(SW), can be implemented as a layer on top of existing
termines the windows available for exploration, the user can
DBMSs. For experimentation purposes, we implemented a
specify a particular grid for every query.
distributed version of the framework on top of PostgreSQL.
Let us revisit examples presented in the Introduction. Ex-
The computation is done by multiple workers residing on
ample 1 could be represented as follows:
different nodes, which interact between themselves and with
• d1 = ra, d2 = dec, a1 = brightness 1 .
the DBMS via TCP/IP. To explore windows efficiently, we
• S = [100◦ , 300◦ ) × [5◦ , 40◦ ), GS = (1◦ , 1◦ ).
require efficient execution of multidimensional range queries,
and Example 2 as:
which can be achieved via common index structures, like B-
• d1 = time, a1 = price.• GS = (1 year), S = [1999/02/01, 2003/11/30) SELECT LB(ra), UB(ra), LB(dec), UB(dec),
An objective function f (w) is a scalar function, defined AVG(brightness)
for window w. There are two types of objective functions: FROM sdss
• Content-based. They are computed over objects belong- GRID BY ra BETWEEN 100 AND 300 STEP 1,
ing to the window. Since the value must be scalar, this dec BETWEEN 5 AND 40 STEP 1
type is restricted to aggregates (average, sum, etc). We HAVING AVG(brightness) > 0.8 AND
further restrict them to be distributive and algebraic [6]. LEN(ra) = 3 AND
This is done for efficiency purposes — the value of f (w) LEN(dec) = 2
must be computable from the corresponding values of the
cells in w. We discuss this in more detail in Section 5.
• Shape-based. They describe the shape of a window and do Figure 2: An SW query written with the proposed
not depend on data within the window. We restrict our- SQL extensions
selves to the following functions: card(w) and lendi (w).
The former defines the number of cells in w, which we example, we provide experimental results for PostgreSQL
call the cardinality of w. The latter is the length of w in in Section 6. More importantly, the query performs an ag-
dimension di in cells. Assuming w spans interval [li , ui ) gregation in the beginning. This means the computation is
in di , lendi (w) = uis−l
i
i
. Other functions, for example blocked until all cells have been computed. Such a query
computing the perimeter or area, are possible. would not be able to output online results. Techniques like
A condition c is a predicate involving an objective func- online aggregation [8] are very limited here, since exact, not
tion. The result of computing condition c for window w approximate, results are required. Also, applying online ag-
is denoted as wc . The framework is restricted to algebraic gregation to such a complex query is challenging at best.
comparisons, for example f (w) > 50. To address these problems we propose to extend SQL to
The conditions for Example 1 can be defined as: lenra (w) = directly express SW queries. Our extensions are as follows:
3, lendec (w) = 2 and avg brightness(w) > 0.8. For Exam- • The new GRID BY clause for defining the search space.
ple 2, the conditions can be expressed as: lentime (w) ≥ 1, This clause replaces GROUP BY (both cannot be used at
lentime (w) ≤ 3 and avg price(w) > 50. the same time).
An SW query can now be defined as QSW = {S, GS , C}, • New functions that can be used for describing windows.
where C is a set of conditions. The result of the query is Namely, LB(di ), U B(di ) to compute the lower and upper
defined as: RESQ = {w ∈ WS |∀c ∈ C : wc = true}, where boundaries of a window in dimension di . Other functions
WS is a set of all windows, defined by GS . are possible depending on the user’s needs.
• New functions for defining shape-based conditions. Namely,
LEN (di ), which is equivalent to lendi (w). This function
3. EXISTING SQL EXTENSIONS FOR DATA is syntactic sugar, since it is possible to compute it by
EXPLORATION using boundary functions introduced above.
As a first option, we look into expressing SW queries using Additionally, we reuse the existing SQL HAVING clause to
SQL. While SQL has constructs for working with groups of define conditions for the query. Figure 2 shows how Example
tuples, such as GROUP BY and OVER, they are insufficient for 1 can be expressed with the proposed extensions.
expressing all possible windows. GROUP BY does not allow In the GRID BY clause, BETWEEN defines the boundaries of
overlapping groups, which makes it impossible to express the search area for every dimension and STEP defines steps
overlapping windows. OVER allows users to study a group of the grid (ra, dec are attributes of sdss and serve as di-
of tuples (also called window in SQL) in the context of the mensions). The query is processed in the same way as a
current tuple via PARTITION BY clause. However, it allows GROUP BY query in SQL, except that instead of groups it
only one such a group for every tuple, not a series of groups works with windows defined via the GRID BY clause. HAVING
with different shapes. Thus, only a subset of possible win- has the same meaning — filtering windows that do not sat-
dows can be expressed this way. The standard SQL is even isfy conditions. Since SELECT outputs windows, only func-
more restrictive and does not allow functions to be used tions describing a window can be used there: the ones de-
in PARTITION BY. This makes it difficult to express multidi- scribing the shape and the ones that were used for defin-
mensional windows at all. ing conditions. Similar restrictions are imposed in the SQL
One general way, which we implemented, is to express an standard for GROUP BY queries.
SW query as follows:
1. Compute objective function values for every cell of the 4. THE SW FRAMEWORK
grid via GROUP BY.
2. Generate every possible window by combining cells, using 4.1 Data-Driven Online Search
recursive CTEs. Values for the objective functions are We first describe our basic algorithm for executing SW
computed by combining the values of the cells. queries with online results. Logically, the search process can
3. Filter windows that do not satisfy the conditions. be described as follows:
This type of query leads to two major problems. First, due 1. Data set S is divided into cells ci as specified by grid GS .
to its complexity most traditional query optimizers would 2. All possible windows w are enumerated and explored one
likely have hard time executing the query efficiently. As an by one in an arbitrary order.
1
The original SDSS data does not contain a brightness at- 3. If window w satisfies all conditions (i.e., {∀c ∈ C : wc =
tribute. However, this attribute or a similar one can be true}), the window belongs to the result.
computed from other attributes using an appropriate func- This suggests a naive algorithm to compute an SW query.
tion. The algorithm presented in this section is designed to pro-vide online results in an efficient way. The main idea is to estimations. In this case only the windows for which new
dynamically generate promising candidate windows as the data is available are actually updated.
search progresses and explore them in a particular order. The procedure begins by determining the initial windows
The search space of all possible windows is structured as via the StartW indows() function. Since the search space
a graph. First we define relationships between windows. might be large, it is important to aggressively prune win-
Giving a window w, an extension of w is a window w0 , which dows. Suppose the user specifies a shape-based condition
is constructed by combining cells of w with a number of that defines the minimum length n for resulting windows in
adjacent cells from its neighborhood. If w0 is extended in a some dimension (e.g., lendi (w) ≥ n). StartW indows() does
single dimension and direction from w, it is called a neighbor. not generate windows that cannot satisfy this condition, ef-
An example can be seen in Figure 3. A two-dimensional fectively pruning initial parts of the graph. Otherwise, the
search area is divided into four cells, labeled 1 through 4. search starts from cells. A similar check is made in the
Window 1|2|3|4 2 is an extension of window 1, since it is GetN eighbors() function, which generates all neighbors of
produced by adding adjacent cells 2 through 4. At the same the current window. It checks for conditions that specify the
time, 1|2|3|4 is a neighbor of 1|2, since 1|2 is extended only maximum length in a dimension (e.g., lendj (w) ≤ m) and
in the vertical dimension and the only direction — “down”. does not generate neighbors that violate such conditions.
The resulting search graph consists of vertices representing Since the number of windows can be very large, at some
windows and edges connecting neighbors. point the priority queue may not fit into memory. It is
With the search graph defined, we use a heuristic best-first possible to spill the tail of the queue into disk and keep only
search approach to traverse it. The heuristic is based on the its head in memory. When a new window has a low utility,
utility of a window, which will be discussed in more detail it is appended to the tail (in any order). When the head
in Section 4.2. In a nutshell, utility is a combination of the becomes small enough, part of the tail is loaded into memory
cost of reading a window from disk and the potential benefit and priority-sorted, if needed. For efficiency, the tail can
of the window, which is a measure of how likely the window be separated into several buckets of different utility ranges
is to satisfy the query conditions. The resulting algorithm where windows inside a bucket have an arbitrary ordering.
is presented as pseudo-code below: While additional pruning, based on other conditions, might
further increase the efficiency of the algorithm, it is not safe
Algorithm 1 Heuristic Online Search Algorithm to apply in general. Since providing approximate results
is not an option we consider, it is not possible to discard
Input: search space S, grid GS , conditions C
a window or its extensions solely on the basis of estima-
Output: resulting windows RESQ
tions. Content-based conditions must be checked on the
exact data. In general, extensions have to be explored as
procedure HeuristicSearch(S, GS , C)
well, since they too can produce valid results. However, in
P Q ← ∅, RESQ ← ∅ . PQ — priority queue
some restricted cases, it is possible to prune them.
StartW ← StartW indows(S, GS , C)
One example is the so-called anti-monotone constraints
for all w ∈ StartW do
[9]. In case of a content-based condition sum(w) < 10 and
EstimateU tility(w)
assuming sum() can produce only non-negative values, it
insert(P Q, w) . utility as priority
is possible to prune all windows that contain the current
while ¬empty(P Q) do window w0 if sum(w0 ) ≥ 10, since sum() is monotonic on
w ← pop(P Q) the size of a window. The length and cardinality of a window
U pdateU tility(w) are other examples of such functions. Since they are data-
if U tility(w) ≥ U tility(top(P Q)) then independent, the corresponding conditions are always safe to
Read(w) . read from disk if needed use for pruning, which our algorithm supports. Such anti-
U pdateResult(RESQ , C, w) monotone pruning, however, would not necessarily decrease
N ← GetN eighbors(w, S, GS ) the amount of data that has to be read. Windows that just
for all n ∈ N do overlap with w0 might still be valid candidates for the result.
EstimateU tility(n)
insert(P Q, n) 4.2 Computing Window Utilities
else The utility of a window is a combination of its cost and
insert(P Q, w) benefit. The cost determines how expensive it is to read a
window from disk. Since the grid is defined at the logical
The algorithm uses a priority queue to explore candidate level without considering the underlying data distribution,
windows according to their utilities. The utility is estimated some windows may be more expensive to read than others,
before a window is read from disk via a precomputed sample. if the data distribution is skewed. Also, since windows over-
Since estimations might improve while new data is read from lap, the cost of a window may decrease during the execution
disk during the search, when the next window is popped if some of its cells have already been read as parts of other
from the queue, we update its utility via the U pdateU tility() windows. We assume that the system caches objective func-
function. This can be seen as lazy utility update. If the win- tion values for every cell it reads, so it is not necessary to
dow still has the highest utility, it is explored (i.e., read from read a cell multiple times. The cost is computed as follows.
disk and checked for satisfying the conditions). Otherwise, Let |S| = n, |GS | = m, where |S| is the total number of
it is returned to the queue to be explored later. Addition- objects in the data set and |GS | is the total number of cells.
ally, we periodically update the whole queue to avoid stale Let the number of objects belonging to non-cached cells of
window w be |w|nc . Then the cost Cw of the window is
2
c1 | . . . |ck labels a window consisting of cells c1 through ck computed as: Cw = |w| nc
n/m
= |w|nc
n
m
.In case data does not have considerable skew, the cost
is approximately equal to the number of non-cached cells
belonging to the window. However, in general the cost might
differ significantly, depending on the skew. To compute the
cost accurately, it is necessary to estimate the number of
objects in a window. We use a precomputed sample for the
initial estimations and update these estimations during the
execution as we read data. When reading a window, we
not only compute the objective function values, but also the
number of objects for every cell. This results in computing
an additional aggregate for the same cells, which does not
incur any overhead. Figure 3: The search graph for an SW query, an-
The second part of the utility computation is benefit esti- notated with benefits, costs, utilities and objective
mation. Here, we determine how “close” a window is to sat- function estimations
isfying the user-defined conditions. First, we compute the
benefit for every condition independently. The framework (bottom) of windows specify benefits, costs and utilities as
currently supports only comparisons as conditions, but the b, c and u respectively. Initially, only the values for cells are
approach can be generalized for other types of predicates. computed, and the values for other windows are computed
Assume an objective function f (w) and the corresponding when they are explored. The search progresses as follows:
condition in the form: f (w) op val, where op is a compari- 1. Since there are no shape-based conditions, the search
son operator. We assume f (w) can be estimated for window starts with cells. Initially, P Q = [2, 3, 1, 4], and the algo-
w via the precomputed sample. Let the estimated value be rithm picks cell 2, which is read from disk. It generates
fw . Then the benefit bfw for condition f for window w is two neighbors: 1|2 and 2|4. f (w) is estimated from the
computed as follows: sample, and the windows are put into the queue. Note
n o that C1|2 = C1 = 1, C2|4 = C4 = 2, since cell 2 has
already been read.
(
f max 0, 1 − |fweps
−val|
if fw op val = f alse
bw = 2. P Q = [3, 1|2, 1, 2|4, 4]. The algorithm picks cell 3 and
1 if fw op val = true reads it from disk. It generates its neighbors: 1|3 and
3|4.
The value eps determines the precision of the estimation
3. P Q = [1|3, 1|2, 1, 2|4, 3|4, 4]. The next window to explore
and is introduced to normalize the benefit value to be be-
is 1|3. It is processed in the same way and generates the
tween 0 and 1. It often can be determined for a particu-
only neighbor possible — 1|2|3|4.
lar function based on the distance of the corresponding at-
4. P Q = [1|2, 1, 1|2|3|4, 2|4, 3|4, 4]. The search moves to
tribute values from val. For example, if f = avg(ai ), then
window 1|2. Since cells 1 and 2 have already been read,
max{|val − min(ai )|, |val − max(ai )|} can serve as eps. Al-
the window is not read from disk and explored in mem-
ternatively, a value of the magnitude of val can be taken
ory. Its only extension, 1|2|3|4, was generated already
initially and then updated as the search progresses.
and is skipped.
The total benefit Bw of window w is computed as the
5. P Q = [1, 1|2|3|4, 2|4, 3|4, 4]. The search then goes through
minimum of the individual benefits, since a resulting window
1, 1|2|3|4, 2|4, 3|4 and, finally, 4 in the order of their
must satisfy all conditions: Bw = minf ∈C bfw .
utilities. Due to caching, all windows except 1|2|3|4 are
Since bfw ∈ [0, 1], it follows that Bw ∈ [0, 1]. The utility of
checked in memory, and when 1|2|3|4 is explored, only
window w is a combination of the benefit and cost:
cell 4 is read from disk.
Cw At every step, after a window is read from disk, the con-
Uw = sBw + (1 − s) 1 − min ,1 dition is checked. If the window satisfies the condition, it is
k
output to the user. Otherwise, it is filtered.
The cost is divided by k to normalize it to [0, 1]. In case
the user did not provide any restrictions on the maximum
cardinality for windows, k is equal to m. Otherwise, it is 4.3 Progress-driven Prefetching
equal to the maximum possible cardinality inferred from Reconsider the heuristic search algorithm presented in
shape-based conditions. The parameter s (s ∈ [0, 1]) is the Section 4.1. Every time a window is explored, all of its cells
weight of the benefit. Lowering the value allows exploring that do not reside in the cache have to be read from disk. If
cheaper, but promising, windows first, while increasing it the grid contains a large number of cells, the search process
prioritizes windows with higher benefits at the expense of might perform a large number of reads, which might incur
the cost. Intuitively, it is better to first explore windows considerable overhead. If the data placement on disk does
with high benefits and use the cost as a tie-breaker, picking not correspond to the locality implied by windows, reading
the cheaper window when benefits are close to each other. even a single window might result in touching a large num-
We illustrate the algorithm with the search graph from the ber of pages dispersed throughout the data file. The problem
previous section, presented in Figure 3. The exact param- goes beyond disk seeks. If only a small portion of objects
eters for the search area are irrelevant. Assume the whole from each page belongs to the window, these pages have
data set contains n = 200 objects and the number of ob- to be re-read later when other windows touch them. This
jects in cells 1, 2, 3 and 4 (m = 4) is 50, 20, 30 and 100 might create thrashing. An implementation of the algorithm
respectively. We assume that eps = 10, k = 4 and s = 21 . that does not modify the database engine cannot deal with
The only condition is f (w) > 13 and the estimated values this problem. The problem might be partially remedied by
fw are specified on top of windows. The numbers to the left clustering the data, yet there are times when users cannotchange the placement of data easily. The ordering might Algorithm 2 Prefetch Algorithm
be dictated by other types of queries users run on the same Input: window w, prefetch size p
data. Another possible way is to materialize the grid by pre- Output: window to read w0
computing all cells. However, this requires that the query
parameters (i.e., the search area, the grid and functions) be procedure Prefetch(w, p)
known in advance. Since exploration can often be an unpre- w0 ← w
dictable ad hoc process, we assume the parameters may vary for i = 1 → n do . n — number of dimensions
between queries. In this case, materialization performed for for dir ∈ {lef t, right}
Q do
every query will make online answering impossible. max ← Cw0 + p k6=i lendk (w0 )
To address this problem, we use an adaptive prefetch- repeat
ing strategy. Our framework explores windows in the same ext ← GetN eighbor(w0 , di , dir)
way, but it prefetches additional cells with every read. The if Cext ≤ max then
window is extended to a new window, according to the def- w0 ← ext
inition of the extension from Section 4.1. When the size until Cext > max
of prefetching increases, intermediate delays might become
more pronounced due to the additional data read with every
can be found. This allows us to finish the query faster. We
window. At the same time, due to the decreased number of
assume that the number of consecutive false positives due
reads, this reduces the overhead and the query completion
to sampling errors is not going to be large, so online perfor-
times. Decreasing the size of prefetching has the opposite ef-
mance will not suffer.
fect. While this approach can be seen as offering a trade-off
The pseudo-code of Algorithm 2 describes how a window
between the online performance and query completion time,
is extended according to the value of p. The size defines a
we show that, in some cases, prefetching can be beneficial
“cost budget” for the extension. This budget is applied as a
for both, as we demonstrate through experiments.
number of possible extension cells independently for every
During the search it is beneficial to dynamically change
direction in every dimension. The budget-based approach
the size of prefetching. A read can have two outcomes. Posi-
allows us to address a possible data skew. Since for a fixed
tive reads result in reading cells that belong to the resulting
dimension a window can be extended in two directions, we
windows. It might be the window just read or windows
denote them as lef t and right.
overlapping with it. While new results keep coming, the
framework prefetches a constant default amount, controlled
by a parameter. By setting this parameter users can favor 4.4 Diversifying Results: Exploration vs. Ex-
a particular side of the trade-off. On the other hand, a false ploitation
positive read does not contribute to the result, reading cells
Our basic SW strategy is designed for “exploitation” in
that do not belong to the resulting windows. A false positive
that it is optimized to produce qualifying SWs as quickly
can happen for two reasons:
as possible without taking into account what parts of the
• The remaining data does not contain any more results.
underlying data space these results may come from. In many
To confirm this, the search process still has to finish read-
data exploration scenarios, however, a user may want to
ing the data. All remaining reads are going to be false
get a quick sense of the overall data space, requiring the
positives. In this case the best strategy would be to read
underlying algorithm to efficiently “explore” all regions of
it in as few requests as possible.
the data, even though this may slow down query execution.
• Due to sampling errors, utilities might be estimated in-
With the basic algorithm, when a number of resulting
correctly. Since new results are still possible, it is better
windows is output, other promising windows that overlap
to continue reading data via select, short requests.
with them will have reduced costs and higher utilities due
Since it is basically impossible to distinguish between the
to the cached cells. Such windows will be explored first,
two cases without seeing all the data, we made the prefetch-
which might favor results located close to each other. In
ing strategy adapt to the current situation. In this new
some cases it might be desirable to jump to another part of
technique, which we refer to as progress-driven prefetching,
the search space that contains promising, but possibly more
the size of prefetching increases with every new consecutive
expensive, windows. This way the user might get a better
false positive read, which addresses the first case. When a
understanding of the search area and results it contains. We
positive read is encountered, the size is reset to the default
considered two approaches to achieve that.
value to switch back at providing online results. The size of
The first approach is to include a notion of diversity of
prefetching, p, is computed as:
results within the utility computation. We define a clus-
p = (1 + α)α+f p reads − 1 ter of results as an MBR (Minimum Bounding Rectangle)
containing all resulting windows that overlap each other.
α ≥ 0 is the parameter that controls the default prefetch- Discovering all final clusters faster might give a better un-
ing size. We call it the aggressiveness of prefetching. In case derstanding of the whole result. When a new window is
α = 0, p = 0 and no additional data is read. Increasing α re- explored we compute the minimum Euclidean distance dist
sults in increasing the default prefetching size, which favors from the window to the clusters already found. The distance
the query completion time. f p reads is the number of con- is normalized to [0, 1] and included as a part of the window’s
0
secutive false positives. When it increases, p increases expo- benefit: Bw = Bw +dist
2
, resulting in the modified utility Uw0 .
nentially. If a new result is discovered, f p reads is set to 0, If the window being explored belongs to a cluster, we find
and p is automatically reset. This corresponds to the adapt- the next highest-utility window w0 with a non-zero dist and
able strategy described above. The exponential increase was compare utilities Uw0 and Uw0 0 . If w0 has a higher utility,
chosen so that the size would grow quickly in case no results it is explored first. We call this a “jump”. With this ap-When a new window is explored, only the cells that are not
in the cache are read. We assume that the objective values
for all cells can fit into memory. This is a fair assumption,
since data objects themselves do not have to be cached.
Sample Maintenance. The Data Manager maintains a
sample that is used for estimating objective function values
and the number of objects for every cell that has not been
read from disk. We assume that a precomputed sample is
available in the beginning of query execution. The parts of
the sample belonging to other partitions are requested from
the corresponding workers.
DBMS Interaction and I/O. When a request for a window
is made, the Data Manager performs the read via a query
to the underlying DBMS. It requests objective function val-
ues for non-cached cells belonging to the window in a single
query. These values are combined with the cached ones at
the Window Processor producing the objective value for the
Figure 4: Distributed SW architecture window. Windows consisting entirely of cached cells are pro-
cessed without the DBMS. We assume that the value of an
proach, promising windows might be stifled by consecutive objective function for a window can be combined from the
jumps. To avoid this problem, the jumping is turned off at values of cells the window consists of. All common aggre-
the current step if the last jump resulted in a false positive. gates (e.g., min(), sum(), avg(), etc.) support this property.
Another approach is to divide the whole search area into Remote Requests. When a window spans multiple parti-
sub-areas, according to a user’s specification. For exam- tions, the Data Manager requests objective values for the
ple, a time-series data might be divided into years. Each cells belonging to other partitions from other workers. If
sub-area has its own queue of windows and the search al- a remote worker does not have the data in cache, it delays
ternates between them at every step. If a window spans the request until the data becomes available. Eventually it
multiple sub-areas, it belongs to the sub-area containing its is going to read all its local data and, thus, will be able to
left-most coordinate point, which we call the window’s an- answer all requests. After every disk read, the worker checks
chor. This approach is similar to the online aggregation over if it can fulfill more requests. If so, it returns the data to
a GROUP BY query [8], where different groups are explored at the requester. At the same time, the requester continues to
the (approximately) same pace. Since some sub-areas might explore other windows. When the remote data comes, the
not contain results, the approach may cause large delays. At corresponding windows are computed and reinserted into the
the same time, it makes the exploration more uniform. queue. The only way a worker may block is when it has fin-
ished exploring its entire sub-area and is waiting for remote
data. Thus, the total query time is essentially dominated by
5. ARCHITECTURE AND IMPLEMENTA- the total disk time of the slowest worker.
TION
We implemented the framework as a distributed layer on 6. EXPERIMENTAL EVALUATION
top of PostgreSQL, which is used as a data back-end. The For the experiments we used the prototype implementa-
algorithm is contained within a client that interacts with tion described in Section 5, written in C++. Single-node
the DBMS. To perform distributed computation, the clients, experiments were performed on a Linux machine (kernel
which we call workers, can work in parallel under the super- 3.8) with an Intel Q6600 CPU, 4GB of memory and WD
vision of a coordinator. The coordinator is responsible for 750GB HDD. All experiments with the distributed version
starting workers, collecting all results and presenting them presented in Section 6.7 were performed using EBS-optimized
to the user. The search area is partitioned into disjoint sub- m1.large Amazon EC2 instances (Amazon Linux, kernel 3.4).
areas among the workers. A window belongs to the worker Data Sets For the experiments, we used three synthetic
responsible for the sub-area containing the window’s anchor, data sets and SDSS [1]. Each synthetic data set was gener-
its leftmost point. Since some windows span multiple par- ated according to a predefined grid. The number of tuples
titions, the worker is responsible for requesting the corre- within each cell was generated using a normal distribution
sponding cell data from other workers. An overview of the with a fixed expectation. Each synthetic data set contains
distributed architecture is shown in Figure 4. eight clusters of tuples, where a cluster is defined as a union
The worker consists of the Query Executor, which imple- of non-empty adjacent cells. We generated three queries, one
ments the search algorithm, including various optimizations for each data set, which select four clusters. These target
such as prefetching. The Window Processor is responsible clusters differ in their distance from each other, which we call
for computing utilities and objective function values (exact spread. Essentially, each data set contains the same clusters
and estimated), based on the information about cells pro- (and tuples), although their coordinates differ. Thus, each
vided by the Data Manager. The Data Manager implements query has the same conditions, which allowed us to measure
all the logic related to reading cells from disk, maintain- the effect of the spread in a clean way. The parameters of
ing additional cell meta-data, and requesting cell data from the query are: S = [0, 1000000) × [0, 1000000), s1 = s2 =
other workers. This includes: 10000, card() ∈ (5, 10), avg() ∈ (20, 30).
Caching. The cache contains objective function values for For the SDSS data set, the situation is different. It is
all cells read from disk and requested from other workers. hard to ensure the same cleanliness of the experiment whendealing with different spreads of the result. We thus chose
three queries with (approximately) the same selectivity and Table 1: Query completion times for different ag-
different spreads. However, in this case the conditions for gressiveness values (in seconds)
Dataset No pref α = 0.5 α = 1.0 α = 2.0
each query differ and the search process explores different
Synth-x 28,206.84 13,521.55 8,602.45 6,957.33
candidate windows in every case. The parameters of the Synth-clust 1,123.12 859.08 886.01 817.59
queries are: S = [113, 229) ×√ [8, 34), s1 = s2 = 0.5, card() ∈
SDSS-dec 26,725.05 4,542.17 3,145.15 2,109.76
(10, 20)/(5, 10)/(15, 20), avg( rowv 2 + colv 2 ) ∈ (95, 96)/ SDSS-clust 1,510.59 1,145.37 1,130 1,158.29
(100, 101)/(181, 182), where ra, dec (from the relational SDSS)
are dimensions, / divides high, medium and low spread re-
spectively and rowv, colv are velocity attributes.
6.1 Query Completion Times
Each of the data sets takes approximately 35GB of space, In this experiment we studied the effect of the data place-
as reported by the DBMS. PostgreSQL’s shared buffer size ment and prefetching on the query completion time. Table 1
was set at 2GB. Computing an objective function for a win- provides the results for the high spread query. Other queries
dow is transformed into a SQL prepared statement call. The exhibited the same trend. α denotes the aggressiveness of
statement is basically a range query, defining the window, prefetching, where “No pref” means no prefetching.
with a GROUP BY clause to compute individual cells. For the To establish a baseline for the comparison, we ran a cor-
efficient execution of range queries, we created a GiST index responding SQL query (as described in Section 3) in Post-
for each data set 3 The size of each index is approximately greSQL and measured the total and I/O (disk) time. Due to
1GB. Each query results in a bitmap index scan, reading the the nature of the SQL query, PostgreSQL did a single read of
data pages determined during the scan and an aggregation the data file, and then aggregated and processed all windows
to compute the objective function. PostgreSQL performed in memory. For the synthetic data set, the query resulted in
all aggregates in memory, without spilling to disk. 1,457.84s total and 677.94s I/O time. For SDSS the query
Data Placement Alternatives As described in Section resulted in 3,589.93s total and 849.70s I/O time. The differ-
4.3, the placement of data on disk has a profound impact ence between the synthetic and SDSS times was due to small
on the performance of the algorithm. In the experimental differences in the size of the data sets and the parameters of
evaluation we considered three options: the queries (SDSS selected more windows, which resulted in
• Ordering tuples by one of the coordinates (e.g., order by more CPU overhead for PostgreSQL).
the x-axis). In this case windows generally contain tuples As Table 1 shows, in case when data is physically clus-
heavily dispersed around the data file. We denote this tered on disk (-clust), the framework is able to outperform
option as “Synth/SDSS-axis” in text (e.g., “SDSS-ra”). PostgreSQL even without using prefetching. This is due to
• Clustering the tuples according to the GiST index. This a very small CPU overhead for the framework. When using
reduces the dispersion of tuples, but since R-trees do not prefetching, the difference becomes even more pronounced.
guarantee efficient ordering, there still might be consid- In the “SDSS-clust” case, using α = 2.0 resulted in 30% less
erable overhead for each range query. This option is de- completion time. It is important to mention that the frame-
noted with suffix “-ind”. work starts outputting results from the beginning, while the
• Clustering the tuples by their coordinates in the data file. SQL approach outputs all results only at the end.
One common way to do this is to use a space-filling curve. In case the data is physically dispersed on disk (-x and
Since we used a Hilbert curve, we denoted this option -dec ordering), prefetching allowed us to reduce the comple-
with suffix “-H”. Another way is to cluster together tuples tion time significantly, i.e., by an order of magnitude. In the
from the same part of the search area. For example, case of SDSS, the framework eventually started outperform-
tuples from each of the eight synthetic clusters are placed ing PostgreSQL, while for the synthetic data a considerable
together on disk, but no locality is enforced between the overhead remained. In general, the performance improve-
clusters. This is a convenient option in case more data is ment depends on the properties of the data set, such as
added and the search area is extended, since it does not the degree of skew or the number of clusters. Despite the
destroy the Hilbert ordering. We define this option with remaining overhead for the synthetic data, we believe the
suffix “-clust”. framework remains very useful even in such cases, since it
Stratified Sampling We used a stratified sampling ap- starts outputting results quickly.
proach to estimate utilities. Assuming the total number of
cells is m and the total sample budget is n tuples, each cell 6.2 Online Performance
n
is sampled with t = m tuples. If a cell contains fewer tu-
This experiment studies the effect of prefetching on online
ples than t, all its tuples are included in the sample and
performance (i.e., delays with which results are output). As
the remaining cell budget is distributed among other cells.
the previous experiment showed, increasing the prefetching
The idea is similar to the idea of fundamental regions [4] and
size reduces the query completion time. At the same time,
congressional sampling [2]. A cell is a logical choice for a fun-
it should increase delays for results since the amount of data
damental region. Each cell is independently sampled with
read with each window increases. To present the experiment
SRS (Simple Random Sampling). Since cells effectively have
more clearly, instead of showing individual result times, we
different sampling ratios, we store the ratio with each sam-
show times to deliver a portion of the entire result (a percent-
pled tuple to correctly estimate the required values, which is
age of the total number of answers). The time to find all the
the common way to do this. All experiments reported were
answers (i.e., 100% in the figures) and the completion time
performed using a 1% stratified sample.
of the query generally differ. The former might be smaller,
since even when all answers are found, the search process has
3 to read the remaining data to confirm this. This means users
In PostgreSQL, GiST indexes are used instead of R-trees,
which would be a logical choice for SW queries. can be sure the result is final only when the query finishes14000 12000
12000 10000
10000
Time (Seconds)
8000
Time (Seconds)
8000
6000
6000
4000
4000
2000 PostgreSQL
2000 PostgreSQL
0
0 1.0 5.0 10.0 20.0 40.0 60.0 80.0 100.0
1.0 5.0 10.0 20.0 40.0 60.0 80.0 100.0
Percentage of the results
Percentage of the results
No Prefetch a = 0.5 a = 2.0
High spread Medium spread Low Spread a = 0.25 a = 1.0
7000 1600
1400 PostgreSQL
6000
1200
5000
Time (Seconds)
Time (Seconds)
1000
4000
800
3000 600
2000 400
PostgreSQL
200
1000
0
0 1.0 5.0 10.0 20.0 40.0 60.0 80.0 100.0
1.0 5.0 10.0 20.0 40.0 60.0 80.0 100.0
Percentage of the results
Percentage of the results
No Prefetch a = 0.5 a = 2.0
High spread Medium spread Low Spread a = 0.25 a = 1.0
Figure 5: Online performance of the synthetic Figure 6: Online performance of the high-spread
queries (Synth-x, top: α = 0.5, bottom: α = 2.0) synthetic query (top: Synth-x, bottom: Synth-clust)
completely. We provide the PostgreSQL baseline, explained dows and used different sizes for prefetching), which made
in the previous section, as a dotted line in the figures. the direct comparison of different queries meaningless.
Figure 5 shows the online performance of all three queries We should mention that first results are output in 10 sec-
with different spreads for the synthetic data set (sorted by onds in most cases and in 80 seconds in worst cases. This
the axis x). All queries behaved approximately the same, fulfills one of the most important goals: start delivering on-
since at every step the algorithm considers windows from the line results fast.
whole search space. The differences were due to the physical
placement of data. For the case of α = 2.0 the final result 6.3 Physical Ordering of Data
was found faster for the low spread query. Since in this case Here we studied the effect of the physical data placement,
clusters were situated close to each other, prefetching large described in Section 4.3, in more detail. Table 2 presents
amounts of data around one cluster allowed the algorithm statistics of data file reads for three different ordering op-
to “touch” another, nearby, cluster as well. Other orderings tions described at the beginning of Section 6. We ran a
of the data set resulted in the same behavior. single query (one per data set) and used systemtap probes
Figure 6 shows the online performance of the high-spread in PostgreSQL to collect the statistics. In the table, “To-
query for the “Synth-x” and “Synth-clust”. For “Synth-x” tal” refers to the total time of reading all blocks, without
larger aggressiveness values resulted in much better online considering the time to process the tuples.
performance during the whole execution, although α = 2.0
created longer delays at some points. The situation changes
with the beneficial clustered ordering. While values up to Table 2: Disk statistics for the synthetic dataset
Data set Total Mean/Dev Reads Re-reads
α = 1.0 behaved approximately the same, α = 2.0 created (s) read (ms) (blks) (blks)
much longer delays. This exposes a trade-off between the Synth-x 24,987 2.4/2.5 10,476,601 6,477,523
query completion time savings coming from prefetching data Synth-ind 3,053 0.7/1.7 4,217,096 218,018
and the delays for online results. Figure 7, which shows the Synth-clust 738 0.2/0.8 4,001,263 2,185
results for the high spread SDSS query, demonstrates the Synth-H 747 0.2/0.8 4,000,592 1,514
same trend. If the user is not aware of the ordering, α = 1.0
might be considered a “safe” value on average, which both When the physical ordering did not work well with range
provides considerable savings and does not cause large initial queries (i.e., -x), the DBMS effectively had to read the same
delays. For advanced usage, the aggressiveness should be data file more than twice (see the “Re-reads” column), which
made available to users to control. If the user is satisfied supports the thrashing claim made in Section 4.3. More-
with the current online results, she can increase the value to over, since each range query resulted in multiple dispersed
finish the query faster. If the ordering is not beneficial (e.g., reads, the time of a single read grew considerably and be-
axis-based), the value should not be set to less than α = 1.0. came more unpredictable (see the “Mean/Dev” column), be-
Other queries exhibited the same trend and are not show. cause of seeks. SDSS showed the same results.
We do not show the results similar to Figure 5 for SDSS.
Since different spread queries for SDSS differ in the num- 6.4 Prefetching Strategies
ber of results and query parameters, the algorithm behaved The size of prefetching depends on the number of consec-
different each time (e.g., considered different candidate win- utive false positive reads. We call such a prefetching strat-9000 14000
8000
12000
7000
Time (Seconds) 10000
Time (Seconds)
6000
5000 8000
4000 PostgreSQL 6000
3000
4000
2000
2000
1000
0 0
1.0 5.0 10.0 20.0 40.0 60.0 80.0 100.0 10.0 20.0 40.0 60.0 80.0 100.0 Total time
Percentage of the results Percentage of the results
No Prefetch a = 1.0 Static, a = 1.0 Static, a = 2.0
a = 0.5 a = 2.0 Dynamic, a = 1.0 Dynamic, a = 2.0
4000 14000
PostgreSQL
3500 12000
3000
10000
Time (Seconds)
Time (Seconds)
2500
8000
2000
6000
1500
4000
1000
500 2000
0 0
1.0 5.0 10.0 20.0 40.0 60.0 80.0 100.0 10.0 20.0 40.0 60.0 80.0 100.0 Total time
Percentage of the results Percentage of the results
No Prefetch a = 1.0 Static, a = 1.0 Static, a = 2.0
a = 0.5 a = 2.0 Dynamic, a = 1.0 Dynamic, a = 2.0
Figure 7: Online performance of the high-spread Figure 8: Online performance of the static and dy-
SDSS query (top: SDSS-dec, bottom: SDSS-clust) namic prefetching (SDSS-dec, top: low-spread SDSS
query, bottom: medium-spread SDSS query)
egy “dynamic”. However, even in the absence of false posi-
tives, there is a default amount of prefetching at every step,
namely (1 + α)α − 1. We call the strategy where the aggres- Table 3: Times to discover clusters for the medium-
siveness does not depend on the number of false positives, spread SDSS query (SDSS-clust, no pref, in seconds)
“static”. The experiment presented in this section studies Strategy First cluster 5 clusters All clusters
the difference in online performance between the two. Original 12.55 56.06 223.53
Figure 8 presents the online performance of both strategies Dist jumps 11.41 56.85 158.03
for two different SDSS queries (dec-axis ordering). Other Utility jumps 11.43 54.36 171
queries showed the same trend. “Total time” bars show the 4 static 19.78 56.40 674.19
9 static 43.13 122.90 1132.10
completion time (“100%” bars show the time to find all re-
16 static 33.58 154.85 825.58
sults). For the same aggressiveness level, the dynamic strat-
egy was better in both online and total performance. When
α = 2.0, the difference seems less pronounced, although parameter — the number of candidates to consider for a
for the “Total time” it reached about 900 seconds for the jump. On the other hand, “Utility jumps” does not require
low-spread and 700 seconds for the medium-spread query. any parameters. The results show that the static strate-
It is evident that taking false positives into account makes gies might perform significantly worse. While for the jump
prefetching more efficient. strategies the online performance remained approximately
the same, static strategies resulted in much larger delays for
6.5 Diversity of Results online results, since they forced uniform exploration across
its groups. Such uniform exploration, while serving a differ-
The experiment presented in this section studies different
ent purpose, might still be beneficial for discovering clusters
diversity strategies from Section 4.4. The resulting times to
in some cases. When we ran the same experiment for the
discover a number of clusters for the medium-spread SDSS
low-spread SDSS query, static strategies reduced the time to
query (clustered ordering, no prefetching) are presented in
find all clusters from 1,219 seconds to 130/339/694 seconds
Table 3. By discovering a cluster we mean finding at least
one window belonging to the cluster. Since clusters are un- for the 4/9/16 static strategy correspondingly. The jump
known in advance, we provide the times after analyzing the strategies did not help at all. This was due to poor window
final result. “Original” refers to the basic algorithm of Sec- estimations, which are essential to make effective jumps.
tion 4.1. “Utility jumps” refers to the approach with mod-
ifying the utility, described in Section 4.4. “Dist jumps” 6.6 Impact of Estimation Errors
examines the best k candidates (from the priority queue) at Since the search process is guided by sampling-based esti-
each step and chooses the furthest from the current clusters. mations, the estimation quality plays an important role on
“X static” refers to another strategy from Section 4.4, where performance. We measured the online performance with an
the search area is evenly divided into X sub-areas. “ideal” 100% sample and then started introducing Gaussian
Initially, the original and the two jump strategies per- noise into it. Figure 9 presents online performance results
formed similarly. However, the time to discover all clusters for medium-spread queries for both data sets (clustered or-
was reduced by 40% comparing with the original approach. dering, no prefetching). The noise percentage equals to the
While “Dist jumps” performed slightly better, it requires a mean of a Gaussian distribution (“No noise” corresponds toYou can also read
