DBProxy: a dynamic data cache for web applications

Amiri, Khalil; Park, Sang‐Hyun; Tewari, Renu; Padmanabhan, Sriram

doi:10.1109/icde.2003.1260881

Cited by 87 publications

(70 citation statements)

References 15 publications

Supporting

Mentioning

Contrasting

Unclassified

Order By: Relevance

“…IBM DBCache [2,17], IBM DBProxy [3], and NEC CachePortal [16] all implement database query caching for web applications. Of these DBProxy uses a relation-based cache representation and sophisticated query processing at each proxy server, enabling a proxy to generate a response to an uncached query if the result can be composed from data retrieved by other cached queries.…”

Section: Related Workmentioning

confidence: 99%

“…Recently, a number of systems have been proposed with a similar architecture for scaling the delivery of databasebacked dynamic content [3,2,17,22]. In each of these systems users interact with proxy servers that mimic a traditional three-tiered architecture (containing a web server to handle user requests, an application server to generate dynamic content, and a database server as a backend data repository).…”

Section: Introductionmentioning

confidence: 99%

See 1 more Smart Citation

Scalable query result caching for web applications

et al. 2008

View full text Add to dashboard Cite

The backend database system is often the performance bottleneck when running web applications. A common approach to scale the database component is query result caching, but it faces the challenge of maintaining a high cache hit rate while efficiently ensuring cache consistency as the database is updated. In this paper we introduce Ferdinand, the first proxy-based cooperative query result cache with fully distributed consistency management. To maintain a high cache hit rate, Ferdinand uses both a local query result cache on each proxy server and a distributed cache. Consistency management is implemented with a highly scalable publish / subscribe system. We implement a fully functioning Ferdinand prototype and evaluate its performance compared to several alternative query-caching approaches, showing that our high cache hit rate and consistency management are both critical for Ferdinand's performance gains over existing systems.

show abstract

Section: Related Workmentioning

confidence: 99%

Section: Introductionmentioning

confidence: 99%

Scalable query result caching for web applications

et al. 2008

View full text Add to dashboard Cite

show abstract

“…Using the second assumption, their system solves strong consistency management of the servers. DBProxy [4] observed that most applications issue template-based queries and these queries have the same structure that contains different string or numeric constraints. AutoPart [14] deals with large scientific databases where the continuous insertions limit the application of indexes and materialized views.…”

Section: Automated Physical Design Solutionsmentioning

confidence: 99%

Automatic Physical Database Tuning Middleware for Web-Based Applications

Patvarczki

Heffernan

2011

Advances in Databases and Information Systems

View full text Add to dashboard Cite

Abstract. In this paper we conceptualize the database layout problem as a state space search problem. A state is a given assignment of tables to computer servers. We begin with a database and collect, for use as a workload input, a sequence of queries that were executed during normal usage of the database. The operators in the search are to fully replicate, horizontally partition, vertically partition, and de-normalize a table. We do a time intensive search over different table layouts, and at each iteration, physically create the configurations, and evaluate the total throughput of the system. We report our empirical results of two forms. First, we empirically validate as facts the heuristics that Database Administrators (DBAs) currently use as in doing this task manually: for tables that have a high ratio of update, delete, and insert to retrieval queries one should horizontally partition, but for a small ratio one should fully replicate a table. Such rules of thumb are reasonable, however we want to parameterize some common guidelines that DBAs can use. Our second empirical result is that we applied this search to our existing data test case and found a reliable increase in total system throughput. The search over layouts is very expensive, but we argue that our method is practical and useful, as entities trying to scale up their Web-based applications would be perfectly happy to spend a few weeks of CPU time to increase their system throughput (and potentially reduce the investment in hardware). To make this search more practical, we want to learn reasonable rules to guide the search to eliminate many layout configurations that are not very likely to succeed. The second aspect of our project (not reported here) is to use the created configurations as input into a machine learning system, to create general rules about when to use the different layout operators.

show abstract

“…Goldstein and Larson [7] show the potential of materializing views within a relational system to dramatically improve performance of expensive queries. Both Amiri, et al [8] and Larson, Goldstein, and Zhou [9] addresses caching relational query results using materialized views. Amiri, et al perform caching in edge caches separate from the origin database which reduces load on the origin server, but maintaining consistency of cached results requires that the origin database propagate every update, delete, and insert operation to all caches, making it unsuitable for environments with high write throughput.…”

Section: Related Workmentioning

confidence: 99%

Enabling Fine-Grained HTTP Caching of SPARQL Query Results

Williams

Weaver

2011

The Semantic Web – ISWC 2011

View full text Add to dashboard Cite

Abstract. As SPARQL endpoints are increasingly used to serve linked data, their ability to scale becomes crucial. Although much work has been done to improve query evaluation, little has been done to take advantage of caching. Effective solutions for caching query results can improve scalability by reducing latency, network IO, and CPU overhead. We show that simple augmentation of the database indexes found in common SPARQL implementations can directly lead to effective caching at the HTTP protocol level. Using tests from the Berlin SPARQL benchmark, we evaluate the potential of such caching to improve overall efficiency of SPARQL query evaluation.

show abstract

DBProxy: a dynamic data cache for web applications

Abstract: Abstract

Cited by 87 publications

References 15 publications

Scalable query result caching for web applications

Scalable query result caching for web applications

Automatic Physical Database Tuning Middleware for Web-Based Applications

Enabling Fine-Grained HTTP Caching of SPARQL Query Results

Contact Info

Product

Resources

About