Offering a Precision-Performance Tradeoff for AggregationQueries over Replicated Data∗

Chris Olston, Jennifer WidomStanford University

{olston, widom}@db.stanford.edu

AbstractStrict consistency of replicated data is infeasible ornot required by many distributed applications, so cur-rent systems often permitstale replication, in whichcached copies of data values are allowed to becomeout of date. Queries over cached data return an an-swer quickly, but the stale answer may be unbound-edly imprecise. Alternatively, queries over remotemaster data return a precise answer, but with poten-tially poor performance. To bridge the gap betweenthese two extremes, we propose a new class of repli-cation systems called TRAPP (Tradeoff in Replica-tion Precision and Performance). TRAPP systemsgive each user fine-grained control over the trade-off between precision and performance: Caches storeranges that are guaranteed to bound the current datavalues, instead of storing stale exact values. Userssupply a quantitativeprecision constraintalong witheach query. To answer a query, TRAPP systems au-tomatically select a combination of locally cachedbounds and exact master data stored remotely to de-liver a bounded answerconsisting of a range that isno wider than the specified precision constraint, thatis guaranteed to contain the precise answer, and thatis computed as quickly as possible. This paper de-fines the architecture of TRAPP replication systemsand covers some mechanics of caching data ranges. Itthen focuses on queries with aggregation, presentingoptimization algorithms for answering queries withprecision constraints, and reporting on performanceexperiments that demonstrate the fine-grained con-trol of the precision-performance tradeoff offered byTRAPP systems.

1 IntroductionMany environments that replicate information at multiplesites permitstale replication, rather than enforcing exactconsistency over multiple copies of data. Exact (transac-tional) consistency is infeasible from a performance per-spective in many large systems, for a variety of reasons

∗This work was supported by the National Science Foundation un-der grant IIS-9811947, by NASA Ames under grant NCC2-5278, andby a National Science Foundation graduate research fellowship.

Permission to copy without fee all or part of this material is grantedprovided that the copies are not made or distributed for direct commer-cial advantage, the VLDB copyright notice and the title of the publica-tion and its date appear, and notice is given that copying is by permis-sion of the Very Large Data Base Endowment. To copy otherwise, orto republish, requires a fee and/or special permission from the Endow-ment.

Proceedings of the 26th VLDB Conference,Cairo, Egypt, 2000.

as outlined in [12], and for many distributed applicationsexact consistency simply is not a requirement.

The World-Wide Web is a very general example of astale replication system, where master copies of pagesare maintained on Web servers and stale copies arecached by Web browsers. In the Web architecture, read-ing the stale cached data kept by a browser has sig-nificantly better performance than retrieving the mastercopy from the Web server (accomplished by pressing thebrowser’s “refresh” button), but the cached copy may bearbitrarily out of date. Another example of a stale repli-cation system is a data warehouse, where we can view thedata objects at operational databases as master copies,and data at the warehouse (or at multiple “data marts”) asstale cached copies. Querying the cached data in a ware-house is typically much faster than querying the mastercopies at the operational sites.

1.1 Running Example

As a scenario for motivation and examples throughoutthe paper, we will consider a simple replication systemused for monitoring a wide-area network linking thou-sands of computers. We assume that each node (com-puter) in the network tracks the average latency, band-width, and traffic level for each incoming network linkfrom another node. Administrators at monitoring sta-tions analyze the status of the network by collectingdata periodically from the network nodes. For each linkNi → Nj in the network, each monitoring station willcache the latest latency, bandwidth, and traffic level fig-ures obtained from nodeNj . Administrators want to askqueries such as:

Q1 What is the bottleneck (minimum bandwidth link)along a pathN1 → N2 → · · · → Nk?

Q2 What is the total latency along a pathN1 → N2 →· · · → Nk?

Q3 What is the average traffic level in the network?Q4 What is the minimum traffic level for fast links (i.e.,

links with high bandwidth and low latency)?Q5 How many links have high latency?Q6 What is the average latency for links with high traf-

fic?

While administrators would like to obtain current andprecise answers to these kinds of queries, collecting newdata values from each relevant node every time a queryis posed would take too long and might adversely affectthe system. Requiring that all nodes constantly send theirupdated values to the monitors is also expensive and gen-erally unnecessary. This paper develops a new approach

Page 1

precision

perf

orm

ance

Using cached (stale) data

Using source (fresh) data

(a) In current systemsprecision

perf

orm

ance

Using a combination ofcached and source data

(b) In TRAPP systems

Figure 1: Precision-performance tradeoff.

to replication and query processing that allows the userto control the tradeoff between precise answers and highperformance. In our example, the latency, bandwidth,and traffic level figures at each monitor are cached asranges, rather than exact values, and nodes send updatesonly when an exact value moves outside of a cachedrange. Queries such asQ1–Q6 above can be executedover the cached ranges and themselves return a range thatis guaranteed to contain the current exact answer. Whenan administrator poses a query, he can provide apreci-sion constraintindicating how wide a range is tolerablein the answer.

For example, suppose the administrator wishes tosample the peak latency periodically in some criticalarea, in order to decide how much money should be in-vested in upgrading the network. To make this decision,the administrator does not need to know the precise peaklatency at each query, but may wish to obtain an answerto within 5 milliseconds of precision. Our system auto-matically combines cached ranges with precise values re-trieved from the nodes in order to answer queries withinthe specified precision as quickly as possible.

1.2 Precision-Performance Tradeoff

In general, stale replication systems potentially offer theuser two modes of querying. In the first mode, whichwe call theprecise mode, queries are sent to the sourcesto get a precise (up-to-date) answer but with potentiallypoor performance. Alternatively, in what we call theim-precise mode, queries are executed over cached data toget an imprecise (possibly stale) answer very quickly. Inimprecise mode, usually no guarantees are given as toexactly how imprecise the answer is, so the user is left toguess the degree of imprecision based on knowledge ofdata stability and/or how recently caches were updated.Figure 1(a) illustrates the precision-performance tradeoffbetween these two extreme query modes.

The discrepancy between the extreme points in Figure1(a) leads to a dilemma: answers obtained in imprecisemode without any precision guarantees may be unaccept-able, but the only way to obtain a guarantee is to useprecise mode, which can place heavy load on the systemand lead to unacceptable delays. Many applications actu-ally require a level of precision somewhere between theextreme points. In our running example (Section 1.1),an administrator posing a query with aquantitative pre-cision constraintlike “within 5 milliseconds” should beable to find a middle ground between sacrificing preci-

sion and sacrificing performance.To address this overall problem, we propose a new

kind of replication system, which we call TRAPP(Tradeoff in Replication Precision and Performance).TRAPP supports a continuous, monotonically decreas-ing tradeoff between precision and performance, as char-acterized in Figure 1(b). Each query can be accompaniedby a custom precision constraint, and the system answersthe query by combining cached and source data so asto optimize performance while guaranteeing to meet theprecision constraint. The extreme points of our systemcorrespond to the precise and imprecise query modes de-fined above.

1.3 Overview of Approach

In addition to introducing the overall TRAPP architec-ture, in this paper we focus on a specific TRAPP replica-tion system called TRAPP/AG, for queries with aggre-gation over numeric (real) data. The conventional preciseanswer to a query with an outermost aggregation opera-tor is a single real value. In TRAPP/AG, we define abounded imprecise answer(hereafter calledbounded an-swer) to be a pair of real valuesLA and HA that de-fine a range[LA, HA] in which the precise answer isguaranteed to lie. Precision is quantified as the widthof the range(HA − LA), with 0 corresponding to ex-act precision and∞ representing unbounded impreci-sion. A precision constraint is a user-specified constantR ≥ 0 denoting the maximum acceptable range width,i.e., 0 ≤ HA − LA ≤ R.

To be able to give guaranteed bounds[LA, HA] asquery answers, TRAPP/AG requires cooperation be-tween data sources and caches. Specifically, let us sup-pose that when a source refreshes a cache’s value for adata objectO, along with the current exact value forOthe source sends a range[L, H ] called theboundof O.(We actually cover a more general case where the boundis a function of time.) The source guarantees that the ac-tual value forO will stay in this bound, or if the valuedoes exceed the bound then the source will immediatelysend a new refresh. Thus, the cache stores the bound[L, H ] for each data objectO instead of an exact value,and the cache can be assured that the current master valueof O is within the bound. When the cache answers aquery, it can use the bound values it stores to compute ananswer, also expressed in terms of a bound.

The small table in Figure 2 shows sample data cachedat a network monitoring station (recall Section 1.1),along with the current precise values at the networknodes. Theweightsmay be ignored for now. Each rowin Figure 2 corresponds to a network link between thelink from node and thelink to node. Recall that precisemaster values forlatency, bandwidth, andtraffic for in-coming links are measured and stored at thelink to node.In addition, for each link, the monitoring station stores abounded value forlatency, bandwidth, andtraffic. Thecache can use these bounded values to compute boundedanswers to queries.

Suppose a bounded answer to a query with aggrega-

Page 2

link latency bandwidth traffic refresh weightsfrom to cached precise cached precise cached precise cost W W ′ W ′′

1 N1 N2 [2, 4] 3 [60, 70] 61 [95, 105] 98 3 2 10 29.52 N2 N4 [5, 7] 7 [45, 60] 53 [110, 120] 116 6 2 10 23 N3 N4 [12, 16] 13 [55, 70] 62 [95, 110] 105 6 15 41.54 N2 N3 [9, 11] 9 [65, 70] 68 [120, 145] 127 8 25 25 N4 N5 [8, 11] 11 [40, 55] 50 [90, 110] 95 4 3 20 36.56 N5 N6 [4, 6] 5 [45, 60] 45 [90, 105] 103 2 2 15 31.5

Figure 2: Sample data for network monitoring example.

tion is computed from cached values, but the answer doesnot satisfy the user’s precision constraint,i.e., the answerbound is too wide. In this case, some data must be re-freshed from sources to improve precision. We assumethat there is a known quantitativecost associated withrefreshing data objects from their sources, and this costmay vary for each data item (e.g., in our example it mightbe based on the node distance or network path latency).We show sample refresh costs for our example in Figure2. Our system uses optimization algorithms that attemptto find the best combination of cached bounds and mas-ter values to use in answering a query, in order to min-imize the cost of refreshing while still guaranteeing theprecision constraint. In this way, TRAPP/AG offers acontinuous precision-performance tradeoff: Relaxing theprecision constraint of a query enables the system to relymore on cached data, which improves the performanceof the query. Conversely, tightening the constraint causesthe system to rely more on master data, which degradesperformance but yields a more precise answer.

1.4 Contributions

• We define the architecture of TRAPP replicationsystems, which offer each user fine-grained con-trol over the tradeoff between precision and per-formance, and propose a method for determiningbounds.

• We specify how to compute the five standard rela-tional aggregation functions over bounded data val-ues, considering queries with and without selectionpredicates, and with joins.

• We present algorithms for finding the minimum-cost set of tuples to refresh in order to answer anaggregation query with a precision constraint, withand without selection predicates. (Joins are dis-cussed but optimal algorithms are not provided.)We analyze the complexity of these algorithms, andin the cases where they are exponential we suggestapproximations.

• We have implemented all of our algorithms and wepresent some initial performance results.

2 Related WorkThere is a large body of work dedicated to systems thatimprove query performance by giving approximate an-swers. Early work in this area is reported in [22]. Mostof these systems use either precomputation (e.g., [26]),

sampling (e.g., [15]), or both (e.g., [11]) to give an an-swer with statistically estimated bounds, without scan-ning all of the input data. By contrast, TRAPP systemsmay scan all of the data (some of which may be boundsrather than exact values), to provide guaranteed ratherthan statistical results.

The previous work perhaps most similar to theTRAPP idea isQuasi-copies[2] and Moving ObjectsDatabases[29]. Like TRAPP systems, these two sys-tems are replication schemes in which cached values arepermitted to deviate from master values by a boundedamount. However, unlike in TRAPP systems, these sys-tems cannot answer queries by combining cached andmaster data, and thus there is no way for users to controlthe precision-performance tradeoff. Instead, the boundfor each data object is set independently of any query-based precision constraints. In Quasi-copies, bounds areset statically by a system administrator. In Moving Ob-jects Databases, bounds are set to maximize a single met-ric that combines precision and performance, eliminat-ing user control of this tradeoff. Furthermore, neither ofthese systems support aggregation queries.

The Demarcation Protocol [3] is a techniquefor maintaining arithmetic constraints in distributeddatabase systems. TRAPP systems are somewhat re-lated to this work since the bound of a data value formsan arithmetic constraint on that value. However, theDemarcation Protocol is not designed for modifyingarithmetic constraints the way TRAPP systems updatebounds as needed. Furthermore, the Demarcation Proto-col does not deal with queries over bounded data.

Both [19] and [28] consider aggregation queries withselections. The APPROXIMATE approach [19] pro-duces bounded answers when time does not permit theselection predicate to be evaluated on all tuples. How-ever, APPROXIMATE does not deal with queries overbounded data. The work in [28] deals with queries overfuzzy sets. While bounded values can be consideredas infinite fuzzy sets, this representation is not practi-cal. Furthermore, the approach in [28] does not considerfuzzy sets as approximations of exact values available fora cost.

In the multi-resolution relational data model[27],data objects undergo various degrees of lossy compres-sion to reduce the size of their representation. By readingthe compressed versions of data objects instead of thefull versions, the system can quickly produce approxi-mate answers to queries. By contrast, in TRAPP sys-tems performance is improved by reducing the number

Page 3

of data objects read from remote sources, rather than byreducing the size of the data representation. InDiver-gence Caching[16], a bound is placed on the number ofupdates permitted to the master copy of a data object be-fore the cache must be refreshed, but there are no boundson data values themselves.

Another body of work that deals with imprecisionin information systems isInformation Quality(IQ) re-search,e.g., [23]. IQ systems quantify the accuracy ofdata at the granularity of an entire data server. Since nobounds are placed on individual data values, queries haveno concrete knowledge about the precision of individ-ual data values from which to form a bounded answer.Therefore, IQ systems cannot give a guaranteed boundon the answer to a particular query.

Finally, data objects whose values are ranges canbe considered a special case of constrained values inConstraint Databases[20, 6, 7, 21, 4], or as null vari-ables with local conditions inIncomplete InformationDatabases[1]. However, no work in these areas thatwe know of considers constrained values as bounded ap-proximations of exact values stored elsewhere. Further-more, aggregation queries over a set with uncertain mem-bership (e.g., due to selection conditions over boundedvalues) are not considered.

3 TRAPP System Architecture

The overall architecture of a TRAPP system is illus-trated in Figure 3. Data Sourcesmaintain the exactvalueVi of each data objectOi, while Data Cachesstorebounds[Li, Hi] that are guaranteed to contain the ex-act values. Source values may appear in multiple caches(with possibly different bounds), and caches may containbounded values from multiple sources. A user submitsa query to theQuery Processorat a local data cache,along with a precision constraint. To answer the querywhile guaranteeing the constraint, the query processormay need to sendquery-initiated refresh requeststo theRefresh Monitorat one or more sources, which respondswith new bounds. The Refresh Monitor at each sourcealso keeps track of the bounds for each of its data objectsin each relevant cache. (Note that in the network moni-toring application we consider in this paper, each sourcemust only keep track of a small number of bounds. Inother applications a source may provide a large numberof objects to multiple caches, in which case a scalabletrigger system would be of great benefit [13].) The Re-fresh Monitor is responsible for detecting whenever thevalue of a data object exceeds the bound in some cache,and sending a new bound to the cache (avalue-initiatedrefresh).

When the cached bound of a data object is refreshedby its source, some cost is incurred. We consider the gen-eral case where each object has its own cost to refresh,although in practice it is likely that the cost of refreshingan object depends only on which source it comes from.(It also may be possible to amortize refresh costs for aset of values, as discussed in Section 8.) These costs areused by our algorithms that choose tuples to refresh in

V = 3V = 5

1

2

Refresh Monitor

User

constraintprecisionquery +

Query Processor

DataCaches

bounded

SourcesData

query-initiated

answer

refreshrequest

refresh

[L , H ] = [2, 6]

2

1 1

[L , H ] = [5, 9]2

Figure 3: TRAPP system architecture.

order to meet the precision constraint of a query at mini-mum cost.

The TRAPP architecture as presented in this papermakes some simplifying assumptions. First, althoughobject insertions or deletions do not occur on a regularbasis in our example application, insertions and deletionsare handled but they must be propagated immediatelyto all caches. (Section 8.3 discusses how this limitationmight be relaxed.) Second, the level of precision offeredby our system does not account for elapses of time whilesending refresh messages or while processing a singlequery. We assume that the time to refresh a bound issmall enough that the imprecision introduced is insignif-icant. Furthermore, we assume that value-initiated re-freshes do not occur during the time an individual queryis being processed. Addressing these issues is a topic forfuture work as discussed in Section 8.4.

Next, in Section 3.1 we discuss in more detail themechanics of bounded values and refreshing. Then inSection 3.2 we generalize bound functions to be time-varying functions. In Section 4 we discuss the executionof aggregation queries in the TRAPP/AG system, be-fore presenting our specific optimization algorithms forsingle-table aggregation queries in Sections 5 and 6. InSection 7 we present some preliminary results for aggre-gation queries with joins.

3.1 Refreshing Cached Bounds

The master copy of each data objectOi resides at a sin-gle source, and for TRAPP/AG we assume it is a singlereal value, which we denoteVi. Caches store a range ofpossible values (thebound) for each data object, whichwe denote[Li, Hi]. When a source sends a copy of dataobjectOi to a cache (arefreshevent at timeTr), in ad-dition to sendingOi’s current precise value, which wedenoteVi(Tr), it sends a bound[Li, Hi].

As discussed earlier, refreshes occur for one of tworeasons. First, if the master value of a data object ex-ceeds its bound stored in some cache (i.e., at current timeTc, Vi(Tc) < Li or Vi(Tc) > Hi), then the source is ob-ligated to refresh the cache with the current precise valueVi(Tc) and a new bound[Li, Hi]—a value-initiated re-fresh. Second, a query-initiated refresh occurs if a querybeing executed at a cache requires the current exact valueof a data object in order to meet its precision constraint.

Page 4

refreshinitiatedquery-

refreshinitiatedvalue-

(τ)Hi

(τ)iL

time τ

valu

e

(τ)Vi

Figure 4: Bound[Li(T ), Hi(T )] over time, overlaidwith precise valueVi(T ).

In this case, the source will sendVi(Tc) along with a newbound to the cache, and the precise valueVi(Tc) can beused in the query.

3.2 Bounds as Functions of Time

Section 3.1 presented a simple approach where the boundof each data objectOi is a pair of endpoints[Li, Hi]. Amore general and accurate approach is to parameterizethe bound by time:[Li(T ), Hi(T )]. In other words, theendpoints of the bound are functions of timeT . Thesefunctions have the property thatLi(Tr) = Hi(Tr) =Vi(Tr), whereTr is the refresh time. That is, the boundat the time of refresh has zero width and both endpointsequal the current value. As time advances pastTr, theendpoints of the bound diverge fromVi(Tr) such that thebound contains the precise value at all timesTc ≥ Tr:Li(Tc) ≤ Vi(Tc) ≤ Hi(Tc). Eventually, when anotherrefresh occurs, the source sends a new pair of boundfunctions to the cache that replaces the old pair. Figure 4illustrates the bound[Li(T ), Hi(T )] of a data objectOi

over time, overlaid with its precise valueVi(T ).All of the subsequent algorithms and results in this

paper are independent of how bounds are selected andspecified. In fact, in the body of the paper we assumethat any time-varying bound functions have been evalu-ated at the current timeTc, and we write[Li, Hi] to mean[Li(Tc), Hi(Tc)]. Also, we writeVi to mean the exactvalue at the current time:Vi(Tc). We have done somepreliminary work investigating appropriate bound func-tions, and have deduced that in the absence of additionalinformation about update behavior, appropriate functionsare those that expand according to the square-root ofelapsed time. That is:Hi(T ) − Li(T ) ∝

√T − Tr,

whereTr is the time of the most recent refresh. Theproportionality parameter, which determines the width ofthe bound, is chosen at run-time. The interested reader isreferred to [24] for details.

4 Query Execution for Bounded AnswersExecuting a TRAPP/AG query with a precision con-straint may involve combining precise data stored on re-mote sources with bounded data stored in a local cache.In this section we describe in general how bounded ag-gregation queries are executed, and we present a costmodel to be used by our algorithms that choose cached

data objects to refresh when answering queries. For theremainder of this paper we assume the relational model,although TRAPP/AG can be implemented with any datamodel that supports aggregation of numerical values.

For now we consider single-table TRAPP/AGqueries of the following form. Joins are addressed inSection 7.

SELECT AGGREGATE(T.a) WITHIN RFROM TWHERE PREDICATE

AGGREGATEis one of the standard relational aggrega-tion functions: COUNT, MIN, MAX, SUM, or AVG.PREDICATEis any predicate involving columns of tableT and possibly constants.R is a nonnegative real con-stant specifying the precision constraint, which requiresthat the bounded answer[LA, HA] to the query satisfies0 ≤ HA − LA ≤ R. If R is omitted thenR = ∞implicitly.

To compute a bounded answer to a query of this form,TRAPP/AG executes several steps:

1. Compute an initial bounded answer based on thecurrent cached bounds and determine if the preci-sion constraint is met. If not:

2. An algorithm CHOOSEREFRESH examines thecache’s copy of tableT and chooses a subset ofT ’stuplesTR to refresh. The source for each tuple inTR is asked to refresh the cache’s copy of that tuple.

3. Once the refreshes are complete, recompute thebounded answer based on the cache’s now partiallyrefreshed copy ofT .

Our CHOOSEREFRESH algorithm ensures that theanswer after step 3 is guaranteed to satisfy the precisionconstraint.

Sections 5 and 6 present details based on each specificaggregation function, considering queries with and with-out selection predicates. For each type of aggregationquery we address the following two problems:

• How to compute a bounded answer based on thecurrent cached bounds. This problem correspondsto steps 1 and 3 above.

• How to choose the set of tuples to refresh.This problem corresponds to step 2 above. ACHOOSEREFRESH algorithm isoptimal if itfinds the cheapest subsetTR of T ’s tuples to refresh(i.e., the subset with the least total cost) that guar-antees the final answer to the query will satisfy theprecision constraint for any precise values of the re-freshed tuples within the current bounds.

We are assuming that the cost to refresh a set of tuplesis the sum of the costs of refreshing each member of theset, in order to keep the optimization problem manage-able. This simplification ignores possible amortizationdue to batching multiple requests to the same source.

Page 5

Also recall that we assume a separate refresh cost maybe assigned to each tuple, although in practice all tuplesfrom the same source may incur the same cost.

Note that the entire setTR of tuples to refresh is se-lected before the refreshes actually occur, so the preci-sion constraint must be guaranteed for any possible pre-cise values for the tuples inTR. A different approach isto refresh tuples one at a time (or one source at a time),computing a bounded answer after each refresh and stop-ping when the answer is precise enough. See Section 8.2for further discussion.

5 Aggregation without Selection Predi-cates

This section specifies how to compute a bounded answerfrom bounded data values for each type of aggregationfunction, and describes algorithms for selecting refreshsets for each aggregation function. For now, we assumethat any selection predicate in the TRAPP/AG query in-volves only columns that contain exact values. Thus, inthis section we assume that the selection predicate has al-ready been applied and the aggregation is to be computedover the tuples that satisfy the predicate. TRAPP/AGqueries with selection predicates involving columns thatcontain bounded values are covered in Section 6, andjoins involving bounded values are discussed in Section7.

Suppose we want to compute an aggregate over col-umnT.a of a cached tableT . The value ofT.a for eachtupleti is stored in the cache as a bound[Li, Hi]. Whilecomputing the aggregate, the query processor has the op-tion for each tupleti of either reading the cached bound[Li, Hi] or refreshingti to obtain the master valueVi.The cost to refreshti is Ci. The final answer to the ag-gregate is a bound[LA, HA].

5.1 Computing MIN with No Selection Predicate

Computing the bounded MIN ofT.a is straightforward:

[LA, HA] = [minti∈T

(Li), minti∈T

(Hi)]1

The lowest possible value for the minimum (LA) occursif for all ti ∈ T , Vi = Li, i.e., each value is at thebottom of its bound. Conversely, the highest possiblevalue for the minimum (HA) occurs ifVi = Hi for alltuples. Returning to our example of Section 1.1, supposewe want to find the minimum bandwidth link along thepathN1 → N2 → N4 → N5 → N6, i.e., queryQ1.Applying the bounded MIN ofbandwidthto tuplesT ={1, 2, 5, 6} in Figure 2 yields[40, 55].

Choosing an optimal set of tuples to refresh fora MIN query with a precision constraint is alsostraightforward, although the algorithm’s justificationand proof of optimality is nontrivial (see [24]). TheCHOOSEREFRESHNO SEL/MIN algorithm choosesTR to be all tuples ti ∈ T such that Li <

1In this and all subsequent formulas, we definemin(∅) = +∞ andmax(∅) = −∞.

mintk∈T (Hk) − R, whereR is the precision constraint,independent of refresh cost. That is,TR contains all tu-ples whose lower bound is less than the minimum upperbound minus the precision constraint. If B-tree indexesexist on both the upper and lower bounds2, the setTR

can be found in time less thanO(|T |) by first using theindex on upper bounds to findmintk∈T (Hk), and thenusing the index on lower bounds to find tuples that sat-isfy Li < mintk∈T (Hk)−R. Without these two indexes,the running time for CHOOSEREFRESHNO SEL/MIN

is O(|T |).Consider again our example queryQ1, which finds

the minimum bandwidth along pathN1 → N2 → N4 →N5 → N6. CHOOSEREFRESHNO SEL/MIN withR = 10 would choose to refresh tuple 5, since it is theonly tuple among{1, 2, 5, 6} whose low value is lessthanmintk∈{1,2,5,6}(Hk) − R = 55 − 10 = 45. Afterrefreshing, tuple 5’s bandwidth value turns out to be50,so the new bounded answer is[45, 50].

The MAX aggregation function is symmetric toMIN. See [24] for details.

5.2 Computing SUM with No Selection Predicate

To compute the bounded SUM aggregate, we take thesum of the values at each extreme:

[LA, HA] = [∑

ti∈T

Li,∑

ti∈T

Hi]

The smallest possible sum occurs when all values areas low as possible, and the largest possible sum occurswhen all values are as high as possible. In our runningexample, the bounded SUM oflatencyalong the pathN1 → N2 → N4 → N5 → N6 (queryQ2) using thedata from Figure 2 is[19, 28].

The problem of selecting an optimal setTR of tuplesto refresh for SUM queries with precision constraints isbetter attacked as the equivalent problem of selecting thetuples not to refresh:TR = T −TR. We first observe thatHA−LA =

∑ti∈T Hi−

∑ti∈T Li =

∑ti∈T (Hi−Li).

After refreshing all tuplestj ∈ TR, we haveHj − Lj =0, so these values contribute nothing to the bound. Thus,after refresh,

∑ti∈T (Hi − Li) =

∑ti∈TR

(Hi − Li).These equalities combined with the precision constraintHA−LA ≤ R give us the constraint

∑ti∈TR

(Hi−Li) ≤R. The optimization objective is to satisfy this constraintwhile minimizing the total cost of the tuples inTR. Ob-serve that minimizing the total cost of the tuples inTR isequivalent to maximizing the total cost of the tuples notin TR. Therefore, the optimization problem can be for-mulated as choosingTR so as to maximize

∑ti∈TR

Ci

under the constraint∑

ti∈TR(Hi − Li) ≤ R.

It turns out that this problem is isomorphic to the well-known 0/1 Knapsack Problem[8], which can be statedas follows: We are given a setS of items that each haveweightWi and profitPi, along with a knapsack with ca-pacity M (i.e., it can hold any set of items as long as

2Section 8.3 briefly discusses indexing time-varying range end-points, a problem on which we are actively working.

Page 6

their total weight is at mostM ). The goal of the Knap-sack Problem is to choose a subsetSK of the items inSto place in the knapsack that maximizes total profit with-out exceeding the knapsack’s capacity. In other words,chooseSK so as to maximize

∑i∈SK

Pi under the con-straint

∑i∈SK

Wi ≤ M . To state the problem of se-lecting refresh tuples for bounded SUM queries as the0/1 Knapsack Problem, we assignS = T , SK = TR,Pi = Ci, Wi = (Hi − Li), andM = R.

Unfortunately, the 0/1 Knapsack Problem is knownto be NP-Complete [10]. Hence all known approachesto solving the problem optimally, such as dynamic pro-gramming, have a worst-case exponential running time.Fortunately, an approximation algorithm exists that, inpolynomial time, finds a solution having total profitthat is within a fractionε of optimal for any 0 <ε < 1 [17]. The running time of the algorithm isO(n · log n) + O((3

ε )2 · n). We use this algorithm forCHOOSEREFRESHNO SEL/SUM. Adjusting param-eterε in the algorithm allows us to trade off the runningtime of the algorithm against the quality of the solution.

In the special case of uniform costs (Ci = Cj forall tuplesti andtj), all knapsack objects have the sameprofit Pi, and the 0/1 Knapsack Problem has a polyno-mial algorithm [8]. The optimal answer then can befound by “placing objects in the knapsack” in order ofincreasing weightWi until the knapsack cannot hold anymore objects. That is, we add tuples toTR starting withthe smallestHi − Li bounds until the next tuple wouldcause

∑ti∈TR

(Hi − Li) > R. If an index exists on thebound widthHi − Li (see Section 8.3), this algorithmcan run in sublinear time. Without an index on boundwidth, the running time of this algorithm isO(n · log n),wheren = |T |.

Consider again queryQ2 that asks for the total latencyalong pathN1 → N2 → N4 → N5 → N6. Fig-ure 2 shows the correspondence between our problemand the Knapsack Problem by specifying the knapsack“weight” W = H − L for the latencycolumn of eachtuple in {1, 2, 5, 6}. Using the exponential (optimal)knapsack algorithm to find the total latency along pathN1 → N2 → N4 → N5 → N6 with R = 5, tuples 2and 5 are “placed in the knapsack” (whose capacity is5),leavingTR = {1, 6}. The bounded SUM oflatencyafterrefreshing tuples 1 and 6 is[21, 26].

5.2.1 Performance Experiments

CHOOSEREFRESHNO SEL/SUM uses the approxi-mation algorithm from [17] to quickly find a cheap setof tuplesTR to refresh such that the precision constraintis guaranteed to hold. We implemented the algorithmand ran experiments using90 actual stock prices thatvaried highly in one day. The high and low valuesfor the day were used as the bounds[Li, Hi], the clos-ing value was used as the precise valueVi, and the re-fresh costCi for each data object was set to a randomnumber between1 and 10. Running times were mea-sured on a Sun Ultra-1 Model 140 running SunOS 5.6.In Figure 5 we fix the precision constraintR = 100

CHOOSEREFRESH timeseco

nd

s

120

80

40

0

total refresh cost

approximation parameterε

tota

lco

st

0.10.080.060.040.020

360

345

330

Figure 5: CHOOSEREFRESHNO SEL/SUM time andrefresh cost for varyingε.

SUM with different values forR (ε = 0.1)

precision constraintR

perf

orm

ance

(ref

resh

cost

)

0501001404000

3000

2000

1000

0

Figure 6: Precision-performance tradeoff forCHOOSEREFRESHNO SEL/SUM.

and varyε in the knapsack approximation in order toplot CHOOSEREFRESH time and total refresh costof the selected tuples. Smaller values forε increasethe CHOOSEREFRESH time but decrease the refreshcost. However, since the CHOOSEREFRESH timeincreases quadratically while the refresh cost only de-creases by a small fraction, it is not in general advan-tageous to setε below 0.1 (which comes very close tooptimal) unless refreshing is extremely expensive.

In Figure 6 we fix the approximation parameterε =0.1 and varyR in order to plot precision (precision con-straint R) versus performance (total refresh cost) forour CHOOSEREFRESHNO SEL/SUM algorithm. Thisgraph, a concrete instantiation of Figure 1(b), clearlyshows the continuous, monotonically decreasing trade-off between precision and performance that characterizesTRAPP systems.

5.3 Computing COUNT with No Selection Predi-cate

When no selection predicate is present, computingCOUNT amounts to computing the cardinality of the ta-ble. Since we currently require all insertions and dele-tions to be propagated immediately to the data caches(Section 3), the cardinality of the cached copy of a tableis always equal to the cardinality of the master copy, sothere is no need for refreshes.

Page 7

5.4 Computing AVG with No Selection Predicate

When no selection predicate is present, the procedurefor computing the AVG aggregate is as follows. First,computeCOUNT , which as discussed in Section 5.3is simply the cardinality of the cachedT . Then, com-pute the bounded SUM as described in Section 5.2 withR = R · COUNT to produce[LSUM , HSUM ]. Finally,let:

[LA, HA] = [LSUM

COUNT,

HSUM

COUNT]

Since the bound widthHA − LA = HSUM−LSUM

COUNT ,by computing SUM such thatHSUM − LSUM ≤R · COUNT , we are guaranteeing thatHA − LA ≤R, and the precision constraint is satisfied. The run-ning time is dominated by the running time of theCHOOSEREFRESHNO SEL/SUM algorithm, which isgiven in Section 5.2.

Consider queryQ3 from Section 1.1 to compute theaverage traffic level in the entire network, and let preci-sion constraintR = 10. We first computeCOUNT = 6,and then compute SUM withR = R · COUNT =10 · 6 = 60. The column labeledW ′ in Figure 2 showsthe knapsack weight assigned to each tuple based on thecached bounds fortraffic. Using the optimal Knapsackalgorithm, the SUM computation will cause tuples 5and 6 to be refreshed, resulting in a bounded SUM of[618, 678]. Dividing by COUNT = 6 gives a boundedAVG of [103, 113].

6 Modifications to Incorporate SelectionPredicates

When a selection predicate involving bounded values ispresent in the query, both computing bounded aggre-gate results and choosing refresh tuples to meet the pre-cision constraint become more complicated. This sec-tion presents modifications to the algorithms in Section 5to handle single-table aggregation queries with selectionpredicates. We begin by introducing techniques commonto all TRAPP/AG queries with predicates, regardless ofwhich aggregation function is present.

Consider a selection predicate involving at least onecolumn ofT that contains bounded values. The systemcan partitionT into three disjoint sets:T−, T ?, andT +.T− contains those tuples that cannot possibly satisfy thepredicate given current bounded data.T+ contains tuplesthat are guaranteed to satisfy the predicate given currentbounded data. All other tuples are inT ?, meaning thatthere exist some precise values within the current boundsthat will cause the predicate to be satisfied, and other val-ues that will cause the predicate not to be satisfied. Theprocess of classifying tuples intoT−, T ?, andT + whenthe selection predicate involves at least one column withbounded values is detailed in [24]. The most interestingaspect is that filters overT that find the tuples inT + andT ? can always be expressed as simple predicates overbounded value endpoints, and all of our algorithms forcomputing bounded answers and choosing tuples to re-fresh examine only tuples inT+ andT ?. Therefore, the

classification can be expressed as SQL queries and opti-mized by the system, possibly incorporating specializedindexes as discussed in Section 8.3.

For examples in the remainder of this section we referto Figure 7, which shows the classification for three dif-ferent predicates over the data from Figure 2, both beforeand after the exact values are refreshed.

6.1 Computing MIN with a Selection Predicate

When a selection predicate is present, the bounded MINanswer is:

[LA, HA] = [ minti∈T+∪T ?

(Li), minti∈T+

(Hi)]

In the “worst case” forLA, all tuples inT ? satisfy thepredicate (i.e., they turn out to be inT +), so the smallestlower bound of any tuple that might satisfy the predi-cate forms the lower bound for the answer. In the “worstcase” forHA, tuples inT ? do not satisfy the predicate(i.e., they turn out to be inT−), so the smallest upperbound of the tuples guaranteed to satisfy the predicateforms the only guaranteed upper bound for the answer. Inour running example, consider queryQ4: find the mini-mumtraffic where(bandwidth > 50)∧ (latency < 10).The result using the data from Figure 2 and classifica-tions from Figure 7 is[90, 105].

CHOOSEREFRESHMIN choosesTR to be ex-actly the tuplesti ∈ T + ∪ T ? such thatLi <mintk∈T+(Hk) − R. This algorithm is essentially thesame as CHOOSEREFRESHNO SEL/MIN, and is cor-rect and optimal for the same reason (see [24]). Theonly additional case to consider is that refreshing tu-ples inT ? may move them intoT−. However, such tu-ples do not contribute to the actual MIN, and thus donot affect the bound of the answer[LA, HA]. Hence,the precision constraint is still guaranteed to hold. Aswith CHOOSEREFRESHNO SEL/MIN the runningtime for CHOOSEREFRESHMIN can be sublinear ifB-tree indexes are available on both the upper and lowerbounds. Otherwise, the worst-case running time forCHOOSEREFRESHMIN is O(n).

For our queryQ4 with precision constraintR = 10,CHOOSEREFRESHMIN choosesTR = {5, 6}, sincetuples 5 and 6 may pass the selection predicate and theirlow values are less thanmintk∈T+(Hk) − R = 105 −10 = 95. After refreshing, tuples 5 and 6 turn out notto pass the selection predicate, so the bounded MIN is[95, 105].

The MAX aggregation function is symmetric toMIN. See [24] for details.

6.2 Computing SUM with a Selection Predicate

To compute SUM in the presence of a selection predi-cate:

[LA, HA] = [∑

ti∈T+

Li +∑

ti∈T ?

∧Li<0

Li,∑

ti∈T+

Hi +∑

ti∈T ?

∧Hi>0

Hi]

Page 8

(bandwidth > 50) ∧ (latency < 10) latency > 10 traffic > 100before refresh after refresh before refresh after refresh before refresh after refresh

1 T + T + T− T− T ? T−

2 T ? T + T− T− T + T +

3 T− T− T + T + T ? T +

4 T ? T + T ? T− T + T +

5 T ? T− T ? T + T ? T−

6 T ? T− T− T− T ? T +

Figure 7: Classification of tuples intoT−, T ?, andT + for three selection predicates.

The “worst case” forLA occurs when all and only thosetuples inT ? with negative values forLi satisfy the selec-tion predicate and thus contribute to the result. Similarly,the “worst case” forHA occurs when only tuples inT ?

with positive values forHi satisfy the predicate.

The CHOOSEREFRESHSUM algorithm is similarto CHOOSEREFRESHNO SEL/SUM, which maps theproblem to the 0/1 Knapsack Problem (Section 5.2). Thefollowing two modifications are required. First, we ig-nore all tuplesti ∈ T−. Second, for tuplesti ∈ T ?, wesetWi to one of three possible values. IfLi ≥ 0, letWi = Hi − 0 = Hi. If Hi ≤ 0, let Wi = 0 − Li = −Li.Otherwise, letWi = (Hi−Li) as before. The idea is thatwe want to effectively extend the bounds for all tuples inT ? to include0, since it is possible that these tuples areactually inT− and thus do not contribute to the SUM(i.e., contribute value0). In the knapsack formulation, toextend the bounds to0 we need to adjust the weights asspecified above.

6.3 Computing COUNT with a Selection Predicate

The bounded answer to the COUNT aggregationfunction in the presence of a selection predicate is:[LA, HA] = [|T +|, |T +| + |T ?|]. For example, considerqueryQ5 from Section 1.1 that asks for the number oflinks that havelatency > 10. Figure 7 shows the classi-fication of tuples intoT−, T ?, andT +. Since|T +| = 1and|T ?| = 2, the bounded COUNT is [1, 3].

The CHOOSEREFRESHCOUNT algorithm isbased on the fact thatHA − LA = |T ?|, and thatrefreshing a tuple inT ? is guaranteed to removeit from T ?. Given these two facts, the optimalCHOOSEREFRESHCOUNT algorithm is to letTR

be the d|T ?| − Re cheapest tuples inT ?. Using aB-tree index on cost, this algorithm runs in sublineartime. Otherwise, the worst-case running time forCHOOSEREFRESHCOUNT requires a sort and isO(n · log n).

Consider again queryQ5 and supposeR = 1. Since|T ?| = 2, CHOOSEREFRESHCOUNT selectsTR ={5}, which is thed|T ?| − Re = d2 − 1e = 1 cheapesttuple inT ?. After updating this tuple (which turns out tobe inT +), the bounded COUNT is [2, 3].

6.4 Computing AVG with a Selection Predicate

6.4.1 Computing the Bounded Answer

Computing the bounded AVG when a predicate ispresent is somewhat more complicated than computingthe other aggregates. With a predicate, COUNT is abounded value as well as SUM, so it is no longer a sim-ple matter of dividing the endpoints of the SUM boundby the exact COUNT value (as in Section 5.4). To com-pute the lower bound on AVG, we start by computingthe average of the low endpoints of theT+ bounds, andthen average in the low endpoints of theT ? bounds oneat a time in increasing order until the point at which theaverage increases. Computing the upper bound on AVGis the reverse. For example, consider queryQ6 from Sec-tion 1.1 that asks for the average latency for links havingtraffic > 100. To compute the lower bound, we startby averaging the low endpoints ofT + tuples 2 and 4,and then average in the low endpoints ofT ? tuples 1 andthen 6 to obtain a lower bound on average latency of5.We stop at this point since averaging in furtherT ? tu-ples would increase the lower bound. This computationis formalized in [24], and has a worst-case running timeof O(n · log n).

A looser bound for AVG can be computed in lineartime by first computing SUM as[LSUM , HSUM ] andCOUNT as[LCOUNT , HCOUNT ] using the algorithmsfrom Sections 6.2 and 6.3, then setting:

[LA, HA] = [min(LSUM

HCOUNT,

LSUM

LCOUNT),

max(HSUM

LCOUNT,

HSUM

HCOUNT)]

In our example, [LSUM , HSUM ] = [14, 55] and[LCOUNT , HCOUNT ] = [2, 6]. Thus, the linear algo-rithm yields [2.3, 27.5]. Notice that this bound is in-deed looser than the[5, 11.3] bound achieved by theO(n · log n) algorithm above.

6.4.2 Choosing Tuples to Refresh

CHOOSEREFRESHAVG is our most complicated sce-nario. Details are provided in [24]. Here we give a verybrief description.

Our CHOOSEREFRESHAVG algorithm uses thefact that a loose bound on AVG can be achieved asa function of the bounds for SUM and COUNT, asin the linear algorithm in Section 6.4.1 above. We

Page 9

choose refresh tuples that provide bounds for SUM andCOUNT such that thebound for AVG as a function ofthe bounds for SUM and COUNT meets the precisionconstraint. This interaction is accomplished by using amodified version of the CHOOSEREFRESHSUM al-gorithm that understands how the choice of refresh tu-ples for SUM affects the bound for COUNT. This al-gorithm sets a precision constraint for SUM that takesinto account the changing bound for COUNT to guar-antee that the overall precision constraint on AVG ismet. CHOOSEREFRESHAVG preserves the Knap-sack Problem structure. Therefore, choosing refresh tu-ples for AVG can be accomplished by solving the 0/1Knapsack Problem, and it has the same complexity asCHOOSEREFRESHNO SEL/SUM (see Section 5.2).

In our example queryQ6 above, if we setR = 2 thenCHOOSEREFRESHAVG chooses a knapsack capacityof M = 4 and assigns a weight to each tuple as shownin the column labeledW ′′ in Figure 2. The knapsackoptimally “contains” tuples 2 and 4. After refreshing theother tuplesTR = {1, 3, 5, 6}, the bounded AVG is[8, 9].

7 Aggregation Queries with JoinsComputing the bounded answer to an aggregation querywith a join expression (i.e., with multiple tables in theFROMclause) is no different from doing so with a selec-tion predicate: in most SQL queries, a join is expressedusing a selection predicate that compares columns ofmore than one table. Our method for determining mem-bership of tuples inT+, T ?, andT− applies to join pred-icates as well as selection predicates. As before, theclassification can be expressed as SQL queries and op-timized by the system to use standard join techniques,possibly incorporating specialized indexes as discussedin Section 8.3.

On the other hand, choosing tuples to refresh is sig-nificantly more difficult in the presence of joins. First,since there are several “base” tuples contributing to each“aggregation” (joined) tuple, we can choose to refreshany subset of the base tuples. Each subset might shrinkthe answer bound by a different amount, depending howit affects theT +, T ?, T− classification combined withits effect on the aggregation column. Second, since eachbase tuple can potentially contribute to multiple aggre-gation tuples, refreshing a base tuple for one aggregationtuple can also affect other aggregation tuples. These in-teractions make the problem quite complex. We haveconsidered various heuristic algorithms that choose tu-ples to refresh for join queries. Currently, we are in-vestigating the exact complexity of the problem andhope to find an approximation algorithm with a tun-ableε parameter, as in the approximation algorithm forCHOOSEREFRESHSUM.

8 Status and Future WorkWe have implemented all of the bounded aggregationfunctions and CHOOSEREFRESH algorithms pre-sented in this paper, and implementation of the source-cache cooperation discussed in Sections 3.1 and 3.2 is

underway. In addition to testing our algorithms in a re-alistic environment, we plan to study how the choice ofbound width (Section 3.2) affects the refresh frequency,and we plan to investigate alternative methods of choos-ing bound functions.

This paper represents our initial work in TRAPPreplication systems, so there are numerous avenues forfuture work. We divide the future directions into four cat-egories: additional functionality (Section 8.1), choosingtuples to refresh (Section 8.2), improving performance(Section 8.3), and real-time and availability issues (Sec-tion 8.4).

8.1 Additional Functionality

• Expanding the class of aggregation queries weconsider. We want to devise algorithms forother aggregation functions, such as MEDIAN (forwhich we have preliminary results [9]) and TOP-n. In addition, we would like to extend our resultsto handle grouping on bounded values, enablingGROUP-BY and COUNT UNIQUE queries. Wewould also like to handle nested aggregation func-tions such as MAX(AVG), which requires under-standing how the precision of the bounded resultsof the inner aggregate affects the precision of theouter aggregate.

• Looking beyond aggregation queries. We be-lieve that the TRAPP idea can be expanded to en-compass other types of relational and non-relationalqueries having different precision constraints. Inour running example (Section 1.1), suppose wewish to find the lowest latency path in the networkfrom nodeNi to nodeNj . A precision constraintmight require that the value corresponding to the an-swer returned by TRAPP (i.e., the latency of the se-lected path) is within some distance from the valueof the precise best answer.

• Allowing users to express relative instead of ab-solute precision constraints. A relative precisionconstraint might be expressed as a constantP ≥0 that denotes an absolute precision constraint of2 · A · P , whereA is the actual answer. The dif-ficulty is thatA is not known in advance. Based onthe bound onA derived in the first pass from cacheddata alone, it is possible to find a conservative abso-lute precision constraintR ≤ 2 · A · P to use inour algorithms. However, it might be possible to re-design our algorithms to perform better with relativebounds.

• Considering probabilistic precision guarantees.TRAPP systems as defined in this paper im-prove performance by providing bounded answers,while offering absolute guarantees about precision.As discussed in Section 2, other approaches im-prove performance by giving probabilistic guaran-tees about precision. An interesting direction is tocombine the two for even better performance: pro-vide bounded answers with probabilistic precisionguarantees.

Page 10

• Considering applying our TRAPPideas tomulti-levelreplication systems, where each data objectresides on one source and there is a hierarchy ofdata caches.Refreshes would then occur betweena cache and the caches or sources one level below,with a possible cascading effect. A current exam-ple of such a scenario is Web caching systems (e.g.,Inktomi Traffic Server[18]), which reside betweenWeb servers and end-user Web browsers.

• Extending data visualization techniques to takeadvantage ofTRAPP. We are currently investigat-ing ways to extend data visualization systems (e.g.,[25]) to display images based on bounded data in-stead of precise data, perhaps by drawing fuzzy re-gions to indicate uncertainty. A visualization in aTRAPP setting could be modeled as a continuousquery in which precision constraints are formulatedin the visual domain and upheld by TRAPP.

8.2 Choosing Tuples to Refresh

• Adapting our CHOOSEREFRESHalgorithmsto take refresh batching into account. If mul-tiple query-initiated refreshes are sent to the samesource, the overall cost may be less than the sumof the individual costs. We would like to adaptour CHOOSEREFRESH algorithms to take intoaccount such cases where refreshing one tuple re-duces the cost of refreshing other tuples. Infact, the same adaptation may help us developCHOOSEREFRESH algorithms for queries in-volving join and group-by expressions. In both ofthese cases, refreshing a tuple for one purpose (onegroup or joined tuple) may reduce the subsequentcost for another purpose (group or joined tuple).

• Considering iterative CHOOSEREFRESHal-gorithms. Rather than choosing a set of tuples inadvance that guarantees adequate precision regard-less of actual exact values, we could refresh tuplesiteratively until the precision constraint is met. Inaddition to developing the alternative suite of algo-rithms, it will be interesting to investigate in whichcontexts an iterative method is preferable to thebatch method presented in this paper. Also, wecould use an iterative method to give bounded ag-gregation queries an “online” behavior [14], wherethe user is presented with a bounded answer thatgradually refines to become more precise over time.In this scenario, the goal is to shrink the answerbound as fast as possible.

8.3 Improving Performance

• Delaying the propagation of insertions and dele-tions to data caches.We are currently investigat-ing ways in which discrepancies in the number oftuples can be bounded, and the computation of thebounded answer to a query can take into accountthese bounded discrepancies. Sources will then nolonger be forced to send a refresh every time an ob-ject is inserted or deleted.

• Investigating specialized bound functions suit-able for update patterns with known properties.The bound function shape we suggested in this pa-per (Section 3.2) is based on the assumption that noinformation about the update pattern is available.

• Considering ways to amortize refresh costs byre-fresh piggybackingand pre-refreshing. When a(value- or query-initiated) refresh occurs, the sourcemay wish to “piggyback” extra refreshes along withthe one requested. These extra refreshes would con-sist of values that are likely to need refreshing in thenear future,e.g., if the precise value is very close tothe edge of its bound. The amount of refresh piggy-backing to perform would depend on the benefit ofdoing so versus the added overhead. Additionally,it might be beneficial to performpre-refreshing, bysending unnecessary refreshes when system load islow that may be useful in future processing.

• Investigating storage, indexing, and query pro-cessing issues over bounded values.We are cur-rently designing and evaluating schemes for index-ing bounds that are functions of time with a square-root shape, as discussed in Section 3.2. Also, weplan to weigh the advantages of using functionsfor bounds versus potential indexing improvementswhen bounds are constants. We also plan to studyways in which cached data objects stored as pairsof bound functions might be compressed. Withoutcompression, caches must store two values for eachdata object, and sources must transmit these twovalues for each tuple being refreshed. Furthermore,the Refresh Monitor at each source must keep trackof the bound functions for each remotely cacheddata object. Compression issues can be addressedwithout affecting the techniques presented in thispaper: our CHOOSEREFRESH algorithms areindependent of which bound functions are used orhow they are represented, and we have not yet fo-cused on query processing issues.

8.4 Real-time and Consistency Issues

• Handling refresh delay. Since message-passingover a network is not instantaneous, in a value-initiated refresh there is some delay between thetime a master value exceeds a cached bound and thetime the cache is refreshed. Consequently, a cachedbound can be “stale” for a short period of time. Oneway to avoid this problem is by pre-refreshing avalue when it is close to the edge of its bound.

• Evaluating concurrency control solutions. Ifvalue-initiated refreshes are permitted to occurduring the CHOOSEREFRESH computation orwhile a query is being evaluated (or in between), theanswer could reflect inconsistent data or could failto satisfy the precision constraint. One solution isto implement multiversion concurrency control [5],which would permit refreshes to occur at any time,while still allowing each in-progress query to readdata that was current when the query started.

Page 11

AcknowledgmentsWe thank Hector Garcia-Molina, Taher Haveliwala, Ra-jeev Motwani, and Suresh Venkatasubramanian for use-ful discussions. We also thank Joe Hellerstein and someanonymous referees for helpful comments on an initialdraft. Finally, we thank Sergio Marti for useful discus-sions about network monitoring.

References[1] S. Abiteboul, P. Kanellakis, and G. Grahne. On the representa-

tion and querying of sets of possible worlds. InProceedings ofthe ACM SIGMOD International Conference on Management ofData, pages 34–48, San Francisco, California, May 1987.

[2] R. Alonso, D. Barbara, H. Garcia-Molina, and S. Abad. Quasi-copies: Efficient data sharing for information retrieval systems.In Proceedings of the International Conference on ExtendingDatabase Technology, pages 443–468, Venice, Italy, March 1988.

[3] D. Barbara and H. Garcia-Molina. The Demarcation Protocol:A technique for maintaining linear arithmetic constraints in dis-tributed database systems. InProceedings of the InternationalConference on Extending Database Technology, pages 373–387,Vienna, Austria, March 1992.

[4] M. Benedikt and L. Libkin. Exact and approximate aggregation inconstraint query languages. InProceedings of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Sys-tems, pages 102–113, Philadelphia, Pennsylvania, May 1999.

[5] P. A. Bernstein, V. Hadzilacos, and N. Goodman.ConcurrencyControl and Recovery in Database Systems. Addison-Wesley,1987.

[6] A. Brodsky and Y. Kornatzky. The LyriC language: Queryingconstraint objects. InProceedings of the ACM SIGMOD Inter-national Conference on Management of Data, pages 35–46, SanJose, California, May 1995.

[7] A. Brodsky, V. E. Segal, J. Chen, and P. A. Exarkhopoulo. TheCCUBE constraint object-oriented database system. InProceed-ings of the ACM SIGMOD International Conference on Manage-ment of Data, pages 577–579, Philadelphia, Pennsylvania, June1999.

[8] T. H. Cormen, C. E. Leiserson, and R. L. Rivest.Introduction toAlgorithms. MIT Press, Cambridge, Massachusetts, 1990.

[9] T. Feder, R. Motwani, R. Panigrahy, C. Olston, and J. Widom.Computing the median with uncertainty. InProceedings of the32nd ACM Symposium on Theory of Computing, Portland, Ore-gon, May 2000.

[10] M. R. Garey and D. S. Johnson.Computers and Intractability:A Guide to the Theory of NP-Completeness. W. H. Freeman andCompany, New York, New York, 1979.

[11] P. B. Gibbons and Y. Matias. New sampling-based summarystatistics for improving approximate query answers. InProceed-ings of the ACM SIGMOD International Conference on Manage-ment of Data, pages 331–342, Seattle, Washington, June 1998.

[12] J. Gray, P. Helland, P. O’Neil, and D. Shasha. The dangers ofreplication and a solution. InProceedings of the ACM SIGMODInternational Conference on Management of Data, pages 173–182, Montreal, Canada, June 1996.

[13] E. N. Hanson, C. Carnes, L. Huang, M. Konyala, L. Noronha,S. Parthasarathy, J. B. Park, and A. Vernon. Scalable triggerprocessing. InProceedings of the 15th International Conferenceon Data Engineering, pages 266–275, Sydney, Austrialia, March1999.

[14] J. M. Hellerstein, R. Avnur, A. Chou, C. Hidber, C. Olston, V. Ra-man, T. Roth, and P. Haas. Interactive data analysis with CON-TROL. IEEE Computer, August 1999.

[15] J. M. Hellerstein and P. J. Haas. Online aggregation. InProceed-ings of the ACM SIGMOD International Conference on Manage-ment of Data, pages 171–182, Tucson, Arizona, May 1997.

[16] Y. Huang, R. Sloan, and O. Wolfson. Divergence caching inclient-server architectures. InProceedings of the Third Interna-tional Conference on Parallel and Distributed Information Sys-tems, pages 131–139, Austin, Texas, September 1994.

[17] O. H. Ibarra and C. E. Kim. Fast approximation algorithms forthe knapsack and sum of subset problems.Journal of the ACM,22(4):463–468, October 1975.

[18] Inktomi. Inktomi traffic server, 1999. http://www.inktomi.com/products/network/traffic/product.html.

[19] N. Jukic and S. Vrbsky. Aggregates for approximate query pro-cessing. InProceedings of ACMSE, pages 109–116, April 1996.

[20] P. C. Kanellakis, G. M. Kuper, and P. Z. Revesz. Constraintquery languages. InProceedings of the ACM SIGACT-SIGMOD-SIGART Symposium on Principles of Database Systems, pages299–313, Nashville, Tennessee, April 1990.

[21] G. M. Kuper. Aggregation in constraint databases. InProceed-ings of the First Workshop on Principles and Practice of Con-straint Programming, Newport, Rhode Island, April 1993.

[22] J. P. Morgenstein. Computer based management information sys-tems embodying answer accuracy as a user parameter. Ph.D. the-sis, U.C. Berkeley Computer Science Division, 1980.

[23] F. Naumann, U. Leser, and J. Freytag. Quality-driven integra-tion of heterogeneous information systems. InProceedings of theTwenty-Fifth International Conference on Very Large Data Bases,Edinburgh, U.K., September 1999.

[24] C. Olston and J. Widom. Offering a precision-performance trade-off for aggregation queries over replicated data. Technical re-port, Stanford University Computer Science Department, 2000.http://www-db.stanford.edu/pub/papers/trapp-ag.ps.

[25] C. Olston, A. Woodruff, A. Aiken, M. Chu, V. Ercegovac, M. Lin,M. Spalding, and M. Stonebraker. DataSplash. InProceedings ofthe ACM SIGMOD International Conference on Management ofData, pages 550–552, Seattle, Washington, June 1998.

[26] V. Poosala and V. Ganti. Fast approximate query answering usingprecomputed statistics. InProceedings of the IEEE InternationalConference on Data Engineering, page 252, Sydney, Australia,March 1999.

[27] R. L. Read, D. S. Fussell, and A. Silberschatz. A multi-resolutionrelational data model. InProceedings of the Eighteenth Inter-national Conference on Very Large Data Bases, pages 139–150,Vancouver, Canada, August 1992.

[28] E. A. Rundensteiner and L. Bic. Aggregates in possibilisticdatabases. InProceedings of the Fifteenth International Con-ference on Very Large Data Bases, pages 287–295, Amsterdam,The Netherlands, August 1989.

[29] O. Wolfson, B. Xu, S. Chamberlain, and L. Jiang. Moving ob-jects databases: Issues and solutions. InProceedings of the TenthInternational Conference on Scientific and Statistical DatabaseManagement, pages 111–122, Capri, Italy, July 1998.

Page 12