DOCSLIB.ORG

A Simultaneous Execution Scheme for Database Caching

Total Page：16

File Type：pdf, Size：1020Kb

Download full-text PDF Read full-text
A Simultaneous Execution Scheme for Database Caching A Simultaneous Execution Scheme for Database Caching Der Fakult¨at Mathematik, Naturwissenschaften und Informatik der Brandenburgischen Technischen Universit¨at Cottbus zur Erlangung des akademischen Grades Doktor der Ingenieurwissenschaften (Dr.-Ing.) genehmigte Dissertation vorgelegt von Diplom-Informatiker Steffen Jurk geboren am 29. November 1974 in Apolda Gutachter: Prof. Dr. rer. nat. habil. Bernhard Thalheim Prof. Dr. rer. pol. habil. Hans-Joachim Lenz Prof. Dr.-Ing. Jens Nolte Tag der m¨undlichen Pr¨ufung: 12.12.2005 Hiermit erkl¨are ich, dass ich die vorliegende Dissertation selbst¨andig verfasst habe. Cottbus, den September 22, 2006 ........................ Steffen Jurk, Striesower Weg 22, D–03044 Cottbus Email: [email protected] ii Abstract Database caching techniques promise to improve the performance and scalability of client- server database applications. The task of a cache is to accept requests of clients and to compute them locally on behalf of the server. The content of a cache is filled dynamically based on the application and users’ data domain of interest. If data is missing or concurrent access has to be controlled, the computation of the request is completed at the central server. As a result, applications benefit from quick responses of a cache and load is taken from the server. The dynamic nature of a cache, the need of transactional consistency, and the complex nature of a request make database caching a challenging field of research. This thesis presents a novel approach to the shared and parallel execution of stored procedure code between a cache and the server. Every commercial database product provides such stored procedures that are coded in a complete programming language. Given a request in form of such a procedure, we introduce the concept of split twin transactions that logically split the procedure code into two parts, say A and B, such that A is executed at the cache and B at the server in a simultaneous and parallel manner. Furthermore, we analyse the procedure code to detect suitable parts. To the best of our knowledge, this has not yet been addressed by any existing approaches. Within a detailed case study, we show that our novel scheme improves the performance of existing caching approaches. Furthermore, we demonstrate that different load conditions of the system require different sizes of the parts A and B to gain maximal performance. As a result, we extend database caching by a new dimension of optimization, namely by splitting of the procedure code into A and B. To solve this problem of dynamically balancing the code execution between cache and server, we define the maximum performance of a database cache over time and propose a stochastic model to capture the average execution time of a procedure. Based on the exe- cution frequencies of primitive database operations, the model allows us to partially predict the response times for different sizes of A and B, hence providing a partial solution to the optimization problem. iii iv Zusammenfassung Datenbank-Cache-Techniken versprechen eine Verbesserung von Client-Server-Anwendungen hinsichtlich Performance und Skalierbarkeit. Anfragen werden direkt an den Cache geleitet und mit Hilfe lokal gespeicherter Daten ausgef¨uhrt. Der Cache-Inhalt wird dabei dynamisch entsprechend dem Verhalten von Anwendungen und Benutzern gef¨ullt. Fehlen dem Cache Daten oder erfordert die Ausf¨uhrung der Anfrage die Pr¨ufung transaktionaler Konsistenz, wird die Anfrage vom Server vervollst¨andigt. Anwendungen profitieren von schnellen Antworten des Caches und der Entlastung des Servers. Das dynamische Umfeld, die transaktionale Kon- sistenz und die Komplexit¨at der Anfragen bilden zusammen einen interessanten Forschungs- bereich f¨rEffizienzsteigerung von Client-Server-Systemen. In der vorliegenden Arbeit wird eine neue Technik zur geteilten und parallelen Ausf¨uhrung von Prozeduren aufgezeigt. Nahezu jedes kommerzielle Datenbanksystem bietet heutzutage derartige Prozeduren, die in einer vollst¨andigen Programmiersprache implementiert sind und auf der Ebene des Datenbanksystems ausgef¨uhrt werden. Als Erweiterung f¨ur Prozeduren werden Geteilte Zwillingstransaktionen vorgestellt, die den Code logisch in zwei Teile A und B teilen, so dass A vom Cache und B vom Server zeitgleich ausgef¨uhrt werden. M¨ogliche Teilungen des Codes werden vorweg durch eine Code-Analyse ermittelt. Entsprechend meinen Erkenntnissen wurde dieses Problem bisher von keiner der existierenden Techniken betrachtet. In einer detaillierten Fallstudie wird die verbesserte Performance der hier dargestellten Methoden aufgezeigt. Weiterhin wird gezeigt, dass verschiedene Lastbedingungen eine unter- schiedliche Dimensionierung der Teile A und B zum Erreichen der maximalen Performance erfordern. Somit er¨offnet die richtige Wahl von A und B eine neue Dimension zur Optimierung von Datenbank-Cache-Techniken. Um das Problem des dynamischen Ausbalancierens der Code-Ausf¨uhrung auf einem Cache sowie dem Server zu l¨osen, wird die zeitabh¨angige maximale Cache-Performance und ein stochastisches Modell zur Erfassung der durchschnittlichen Ausf¨uhrungszeit von Prozeduren definiert. Basierend auf Ausf¨uhrungsh¨aufigkeiten von elementaren Datenbankoperationen erm¨oglicht das Modell die partielle Vorhersage von Antwortzeiten f¨ur verschiedene Dimen- sionierungen von A und B. Somit wird eine partielle L¨osung des Optimierungsproblems er- reicht. v vi Contents Abstract iii Zusammenfassung v I Overview and Motivation 1 1 Introduction 3 1.1 DatabaseCaching ................................. 4 1.2 ProblemStatement................................ 6 1.3 Outline ....................................... 8 2 Database Caching Techniques 9 2.1 TheNeedforDatabaseCaching. ... 9 2.2 DatabaseCacheDesign ............................. 12 2.3 Request Execution and Concurrency Control . ....... 15 2.4 Loading the Cache and Self-Adaptation . ...... 18 2.5 A Classification of Caching Schemes . ..... 20 2.6 Related Fields to Database Caching . ..... 22 2.6.1 MobileDatabases.............................. 22 2.6.2 IntegrityEnforcement . 24 3 Problem Analysis 27 3.1 TheExample .................................... 27 3.2 TraditionalCachingSchemes . 28 3.2.1 Avoidance-Based Protocols . 29 3.2.2 Detection-Based Protocols . 31 3.2.3 Discussion.................................. 32 3.3 ASimultaneousExecutionScheme . 33 3.3.1 TwinTransactions ............................. 33 3.3.2 Partial Execution and Re-Use of Query Results . ...... 34 3.3.3 TheRunTimeOptimizationProblem . 39 3.4 SummaryandDiscussion . .. .. .. .. .. .. .. .. 40 vii II Split Twin Transactions for Database Caching 43 4 A Client-Server Database System for Twin Transactions 45 4.1 Overview ...................................... 45 4.2 Data Definition and Stored Procedures . ...... 48 4.2.1 TablesandConstraints . 48 4.2.2 TheLanguageofStoredProcedures . 48 4.2.3 Low-LevelProcedures . 50 4.3 TheExecutionEngine .............................. 52 4.4 TableFragmentation .. .. .. .. .. .. .. .. .. 54 4.4.1 The Definition of Fragments . 54 4.4.2 Fragment Access of Queries and Low-Level Updates . ...... 55 4.4.3 The Management of Fragments . 57 4.4.4 FragmentVersions ............................. 59 4.5 Fragment Replication and Synchronization . ......... 61 4.5.1 Propagate Updates to Caches . 62 4.5.2 Receive Updates from the Server . 63 4.5.3 Dynamic Data Replication . 65 4.6 Executability of IO Statements . ..... 65 4.7 TwinTransactions ................................ 66 4.7.1 Unique Execution and Tuple Identifiers . 67 4.7.2 Consistent Twin Transaction . 69 4.8 RelatedWork.................................... 71 4.9 SummaryandDiscussion . .. .. .. .. .. .. .. .. 72 5 A Simultaneous Execution Scheme for Split Procedure Code 75 5.1 Split Twin Transactions — An Overview . ..... 76 5.2 TheQueryResultCache............................. 79 5.3 ExecutionattheCache ............................. 80 5.3.1 ThePartialExecutionModel . 80 5.3.2 HandlingIOStatements . 83 5.3.3 CompletinganExecution . 84 5.4 ExecutionattheServer ............................ 84 5.4.1 RetrievingQueryResultsfromtheQRC . 84 5.4.2 HandlingIOStatements . 87 5.4.3 VerifyingQueryResults . 88 5.4.4 CompletinganExecution . 88 5.5 Identify Dependencies within the Procedure Code . .......... 89 5.6 Correctness of Split Twin Transactions . ........ 94 5.7 RelatedWork.................................... 95 5.8 SummaryandDiscussion . .. .. .. .. .. .. .. .. 96 viii 6 Case Study — The ONE-System 99 6.1 Architecture.................................... 99 6.1.1 DatabaseSchemaandProcedureCode . 99 6.1.2 The Client-Server Database System . 100 6.1.3 A Traditional Execution Scheme . 101 6.1.4 The Simultaneous Execution Scheme . 103 6.2 ExperimentalSetup ............................... 104 6.2.1 UsedHard-andSoftware .. .. .. .. .. .. .. 104 6.2.2 ParametersofExperiments . 105 6.2.3 TheExecutionofExperiments . 106 6.3 ComparisonoftheExecutionSchemes . 108 6.3.1 The Traditional Execution Scheme . 108 6.3.2 The Simultaneous Execution Scheme With Dependent Queries . 113 6.3.3 The Simultaneous Execution Scheme With Independent Queries . 117 6.4 Other Related Experimental Results . 120 6.4.1 Performance of Slow Database Caches . 121 6.4.2 Sharedvs.NormalMode .. .. .. .. .. .. .. 122 6.5 SummaryandDiscussion . .. .. .. .. .. .. .. .. 125 III Self-Adaptive Load Balancing between Cache and Server 127 7 Dynamics, Performance and the Optimization 129 7.1 The Dynamics of Client-Server Database Systems . ......... 129 7.2 CacheExecutionPerformance. 133 7.2.1
Load more

Recommended publications
  • A Program Optimization for Automatic Database Result Caching
    rtifact A Program Optimization for Comp le * A t * te n * te A is W s E * e n l l C o L D C o P * * c u e m s Automatic Database Result Caching O E u e e P n R t v e o d t * y * s E a a l d u e a t Ziv Scully Adam Chlipala Carnegie Mellon University, Pittsburgh, PA, USA Massachusetts Institute of Technology CSAIL, [email protected] Cambridge, MA, USA [email protected] Abstract formance bottleneck, even with the maturity of today’s database Most popular Web applications rely on persistent databases based systems. Several pathologies are common. Database queries may on languages like SQL for declarative specification of data mod- incur significant latency by themselves, on top of the cost of interpro- els and the operations that read and modify them. As applications cess communication and network round trips, exacerbated by high scale up in user base, they often face challenges responding quickly load. Applications may also perform complicated postprocessing of enough to the high volume of requests. A common aid is caching of query results. database results in the application’s memory space, taking advantage One principled mitigation is caching of query results. Today’s of program-specific knowledge of which caching schemes are sound most-used Web applications often include handwritten code to main- and useful, embodied in handwritten modifications that make the tain data structures that cache computations on query results, keyed off of the inputs to those queries. Many frameworks are used widely program less maintainable.
    [Show full text]
  • Managing Cache Consistency to Scale Dynamic Web Systems
    Managing Cache Consistency to Scale Dynamic Web Systems by Chris Wasik A thesis presented to the University of Waterloo in fulfilment of the thesis requirement for the degree of Master of Applied Science in Electrical and Computer Engineering Waterloo, Ontario, Canada, 2007 c Chris Wasik 2007 AUTHORS DECLARATION FOR ELECTRONIC SUBMISSION OF A THESIS I hereby declare that I am the sole author of this thesis. This is a true copy of the thesis, including any required final revisions, as accepted by my examiners. I understand that my thesis may be made electronically available to the public. ii Abstract Data caching is a technique that can be used by web servers to speed up the response time of client requests. Dynamic websites are becoming more popular, but they pose a problem - it is difficult to cache dynamic content, as each user may receive a different version of a webpage. Caching fragments of content in a distributed way solves this problem, but poses a maintainability challenge: cached fragments may depend on other cached fragments, or on underlying information in a database. When the underlying information is updated, care must be taken to ensure cached information is also invalidated. If new code is added that updates the database, the cache can very easily become inconsistent with the underlying data. The deploy-time dependency analysis method solves this maintainability problem by analyzing web application source code at deploy-time, and statically writing cache dependency information into the deployed application. This allows for the significant performance gains distributed object caching can allow, without any of the maintainability problems that such caching creates.
    [Show full text]
  • A Trigger-Based Middleware Cache for Orms
    A Trigger-Based Middleware Cache for ORMs Priya Guptay, Nickolai Zeldovich, and Samuel Madden MIT CSAIL, yGoogle Abstract. Caching is an important technique in scaling storage for high-traffic web applications. Usually, building caching mechanisms involves significant effort from the application developer to maintain and invalidate data in the cache. In this work we present CacheGenie, a caching middleware which makes it easy for web application developers to use caching mechanisms in their applications. CacheGenie provides high-level caching abstractions for common query patterns in web applications based on Object-Relational Mapping (ORM) frameworks. Using these abstractions, the developer does not have to worry about managing the cache (e.g., insertion and deletion) or maintaining consistency (e.g., invalidation or updates) when writing application code. We design and implement CacheGenie in the popular Django web application framework, with PostgreSQL as the database backend and memcached as the caching layer. To automatically invalidate or update cached data, we use trig- gers inside the database. CacheGenie requires no modifications to PostgreSQL or memcached. To evaluate our prototype, we port several Pinax web applications to use our caching abstractions. Our results show that it takes little effort for applica- tion developers to use CacheGenie, and that CacheGenie improves throughput by 2–2.5× for read-mostly workloads in Pinax. 1 Introduction Developers of popular web applications often struggle with scaling their application to handle many users, even if the application has access to many server machines. For stateless servers (such as HTTP front-ends or application servers), it is easy to spread the overall load across many machines.
    [Show full text]
  • Tuning Websphere Application Server Cluster with Caching Ii Tuning Websphere Application Server Cluster with Caching Contents
    Tuning WebSphere Application Server Cluster with Caching ii Tuning WebSphere Application Server Cluster with Caching Contents Tuning WebSphere Application Server Data replication service .........20 Cluster with Caching .........1 Setting up and configuring caching in the test Introduction to tuning the WebSphere Application environment ..............22 Server cluster with caching .........1 Caching proxy server setup ........23 Summary for the WebSphere Application Server Dynamic caching with Trade and WebSphere . 23 cluster with caching tests ..........1 Enabling WebSphere Application Server Benefits of using z/VM..........2 DynaCache .............25 Hardware equipment and software environment . 3 CPU utilization charts explained ......26 Host hardware.............3 Test case scenarios and results ........27 Network setup.............4 Test case scenarios ...........27 Storage server setup ...........4 Baseline definition parameters and results . 29 Client hardware ............4 Vary caching mode ...........31 Software (host and client) .........4 Vary garbage collection policy .......36 Overview of the Caching Proxy Component ....5 Vary caching policy...........37 WebSphere Edge Components Caching Proxy . 5 Vary proxy system in the DMZ .......42 WebSphere Proxy Server .........6 Scaling the size of the DynaCache ......45 Configuration and test environment ......6 Scaling the update part of the Trade workload. 47 z/VM guest configuration .........6 Enabling DynaCache disk offload ......50 Test environment ............7 Comparison between
    [Show full text]
  • Database Performance Tuning Guide
    Oracle® Database Database Performance Tuning Guide 21c F32091-03 August 2021 Oracle Database Database Performance Tuning Guide, 21c F32091-03 Copyright © 2007, 2021, Oracle and/or its affiliates. Contributing Authors: Glenn Maxey, Rajesh Bhatiya, Immanuel Chan, Lance Ashdown Contributors: Hermann Baer, Deba Chatterjee, Maria Colgan, Mikael Fries, Prabhaker Gongloor, Kevin Jernigan, Sue K. Lee, William Lee, David McDermid, Uri Shaft, Oscar Suro, Trung Tran, Sriram Vrinda, Yujun Wang This software and related documentation are provided under a license agreement containing restrictions on use and disclosure and are protected by intellectual property laws. Except as expressly permitted in your license agreement or allowed by law, you may not use, copy, reproduce, translate, broadcast, modify, license, transmit, distribute, exhibit, perform, publish, or display any part, in any form, or by any means. Reverse engineering, disassembly, or decompilation of this software, unless required by law for interoperability, is prohibited. The information contained herein is subject to change without notice and is not warranted to be error-free. If you find any errors, please report them to us in writing. If this is software or related documentation that is delivered to the U.S. Government or anyone licensing it on behalf of the U.S. Government, then the following notice is applicable: U.S. GOVERNMENT END USERS: Oracle programs (including any operating system, integrated software, any programs embedded, installed or activated on delivered hardware, and modifications of such programs) and Oracle computer documentation or other Oracle data delivered to or accessed by U.S. Government end users are "commercial computer software" or "commercial computer software documentation" pursuant to the applicable Federal Acquisition Regulation and agency-specific supplemental regulations.
    [Show full text]
  • Application-Level Caching with Transactional Consistency by Dan R
    Application-Level Caching with Transactional Consistency by Dan R. K. Ports M.Eng., Massachusetts Institute of Technology (2007) S.B., S.B., Massachusetts Institute of Technology (2005) Submitted to the Department of Electrical Engineering and Computer Science in partial fulllment of the requirements for the degree of Doctor of Philosophy in Computer Science at the MASSACHUSETTSINSTITUTEOFTECHNOLOGY June 2012 © Massachusetts Institute of Technology 2012. All rights reserved. Author...................................................... Department of Electrical Engineering and Computer Science May 23, 2012 Certied by . Barbara H. Liskov Institute Professor esis Supervisor Accepted by . Leslie A. Kolodziejski Chair, Department Committee on Graduate eses 2 Application-Level Caching with Transactional Consistency by Dan R. K. Ports Submitted to the Department of Electrical Engineering and Computer Science on May 23, 2012, in partial fulllment of the requirements for the degree of Doctor of Philosophy in Computer Science abstract Distributed in-memory application data caches like memcached are a popular solution for scaling database-driven web sites. ese systems increase performance signicantly by reducing load on both the database and application servers. Unfortunately, such caches present two challenges for application developers. First, they cannot ensure that the application sees a consistent view of the data within a transaction, violating the isolation properties of the underlying database. Second, they leave the application responsible for locating data in the cache and keeping it up to date, a frequent source of application complexity and programming errors. is thesis addresses both of these problems in a new cache called TxCache. TxCache is a transactional cache: it ensures that any data seen within a transaction, whether from the cache or the database, reects a slightly stale but consistent snap- shot of the database.
    [Show full text]
  • A Program Optimization for Automatic Database Result Caching
    A program optimization for automatic database result caching The MIT Faculty has made this article openly available. Please share how this access benefits you. Your story matters. Citation Scully, Ziv, and Adam Chlipala. “A Program Optimization for Automatic Database Result Caching.” 44th ACM SIGPLAN Symposium on Principles of Programming Languages, Paris, France 15-21 January, 2017. ACM Press, 2017. 271–284. As Published http://dx.doi.org/10.1145/3009837.3009891 Publisher Association for Computing Machinery (ACM) Version Author's final manuscript Citable link http://hdl.handle.net/1721.1/110807 Terms of Use Creative Commons Attribution-Noncommercial-Share Alike Detailed Terms http://creativecommons.org/licenses/by-nc-sa/4.0/ rtifact A Program Optimization for Comp le * A t * te n * te A is W s E * e n l l C o L D C o P * * c u e m s Automatic Database Result Caching O E u e e P n R t v e o d t * y * s E a a l d u e a t Ziv Scully Adam Chlipala Carnegie Mellon University, Pittsburgh, PA, USA Massachusetts Institute of Technology CSAIL, [email protected] Cambridge, MA, USA [email protected] Abstract formance bottleneck, even with the maturity of today’s database Most popular Web applications rely on persistent databases based systems. Several pathologies are common. Database queries may on languages like SQL for declarative specification of data mod- incur significant latency by themselves, on top of the cost of interpro- els and the operations that read and modify them. As applications cess communication and network round trips, exacerbated by high scale up in user base, they often face challenges responding quickly load.
    [Show full text]
  • Middle-Tier Database Caching for E-Business *
    Middle-Tier Database Caching for e-Business * Qiong Luo # Sailesh Krishnamurthy ÷ C. Mohan ~ Hamid Pirahesh ~ Honguk Woo ° Bruce G. Lindsay ~ Jeffrey F. Naughton # • Work done at IBM Almaden Research Center #Computer Sciences Dept, University of Wisconsin, Madison, WI 53706 • Department of EECS, UC Berkeley, Berkeley, CA 94720 5IBM Almaden Research Center, 650 Harry Road, San Jose, CA 95120 °Department of Computer Sciences, University of Texas-Austin, Austin, TX 78712 Contact email: {[email protected], [email protected]} ABSTRACT usually at the application server, of a multi-tier web site infrastructure. Example commercial products include the While scaling up to the enormous and growing Internet Database Cache of Oracle 9i Internet Application Server [19] and population with unpredictable usage patterns, E-commerce TimesTen's Front-Tier [22]. applications face severe challenges in cost and manageability, especially for database servers that are deployed as those applications' backends in a multi-tier configuration. Middle-tier database caching is one solution to this problem. In this paper, we present a simple extension to the existing federated features in I-WIP DB2 UDB, which enables a regular DB2 instance to become a DBCache without any application modification. On deployment Figure 1: Middle-Tier Databas Caching of a DBCache at an application server, arbitrary SQL statements generated from the unchanged application that are intended for a In a multi-tier e-Business infrastructure, middle-tier database backend database server, can be answered: at the cache, at the caching is attractive because of improvements to the following backend database server, or at both locations in a distributed attributes: manner.
    [Show full text]
  • Performance Analysis of a Database Caching System in a Grid Environment
    FACULTY OF ENGINEERING OF THE UNIVERSITY OF PORTO Performance Analysis of a Database Caching System In a Grid Environment Luis Albino Nogueira Ramos Graduated in Informatics and Computing Engineering By the Faculty of Engineering of the University of Porto Dissertation submitted in partial fulfillment of the requirements for the degree of Master of Informatics Engineering Dissertation prepared under the supervision of Dr. Gabriel de Sousa Torcato David from the Department of Electrical and Computer Engineering of the Faculty of Engineering of the University of Porto Porto, September 2007 to little birds who are the secrets of living Resumo O CERN é o maior centro de investigação em física de partículas do mundo onde milhares de físicos estudam os constituintes fundamentais da matéria. O maior projecto do CERN é o Large Hadron Collider (LHC), um acelerador de partículas constituído por vários detectores que observam e registam as colisões de partículas que acontecem no LHC. A LHC Computing Grid (LCG) fornece à comunidade de físicos uma infra-estrutura de computação distribuída para armazenamento, distribuição e análise dos 15 PB de dados produzidos por ano pelo LHC. A LCG fornece serviços e infra-estruturas para a replicação e acesso distribuído a dados em ficheiros. Dado que parte dos dados são armazenados em bases de dados, serviços e infra-estruturas similares são necessários para esses dados. O projecto Distributed Deployment of Databases (LCG3D) fornece a infra-estrutura de distribuição de bases de dados da LCG e é responsável pela investigação de técnicas de distribuição de bases de dados a usar na LCG. As técnicas de distribuição de bases de dados usadas são: a solução comercial para replicação de bases de dados Oracle Streams, e o sistema de cache de bases de dados FroNtier.
    [Show full text]
  • A Trigger-Based Middleware Cache for Orms
    A Trigger-Based Middleware Cache for ORMs Priya Gupta, Nickolai Zeldovich, and Samuel Madden MIT CSAIL Abstract. Caching is an important technique in scaling storage for high-traffic web applications. Usually, building caching mechanisms involves significant ef- fort from the application developer to maintain and invalidate data in the cache. In this work we present CacheGenie, a caching middleware which makes it easy for web application developers to use caching mechanisms in their applications. CacheGenie provides high-level caching abstractions for common query patterns in web applications based on Object-Relational Mapping (ORM) frameworks. Us- ing these abstractions, the developer does not have to worry about managing the cache (e.g., insertion and deletion) or maintaining consistency (e.g., invalidation or updates) when writing application code. We design and implement CacheGenie in the popular Django web applica- tion framework, with PostgreSQL as the database backend and memcached as the caching layer. To automatically invalidate or update cached data, we use trig- gers inside the database. CacheGenie requires no modifications to PostgreSQL or memcached. To evaluate our prototype, we port several Pinax web applications to use our caching abstractions. Our results show that it takes little effort for appli- cation developers to use CacheGenie, and that CacheGenie improves throughput by 2–2.5× for read-mostly workloads in Pinax. 1 Introduction Developers of popular web applications often struggle with scaling their application to handle many users, even if the application has access to many server machines. For stateless servers (such as HTTP front-ends or application servers), it is easy to spread the overall load across many machines.
    [Show full text]
  • Apollo: Learning Query Correlations for Predictive Caching in Geo-Distributed Systems
    Apollo: Learning Query Correlations for Predictive Caching in Geo-Distributed Systems Brad Glasbergen Michael Abebe Khuzaima Daudjee University of Waterloo University of Waterloo University of Waterloo [email protected] [email protected] [email protected] Scott Foggo Anil Pacaci University of Waterloo University of Waterloo [email protected] [email protected] ABSTRACT The performance of modern geo-distributed database applications is increasingly dependent on remote access latencies. Systems that cache query results to bring data closer to clients are gaining popularity but they do not dynamically learn and exploit access patterns in client workloads. We present a novel prediction frame- work that identifies and makes use of workload characteristics obtained from data access patterns to exploit query relationships (a) Datacenter Locations (b) Edge Node Locations within an application’s database workload. We have designed and implemented this framework as Apollo, a system that learns query Figure 1: Google’s datacenter and edge node locations [21]. patterns and adaptively uses them to predict future queries and cache their results. Through extensive experimentation with two different benchmarks, we show that Apollo provides significant 1. SELECT C_ID FROM CUSTOMER WHERE performance gains over popular caching solutions through reduced C_UNAME = @C_UN and C_PASSWD = @C_PAS query response time. Our experiments demonstrate Apollo’s ro- bustness to workload changes and its scalability as a predictive cache for geo-distributed database applications. 2. SELECT MAX(O_ID) FROM ORDERS WHERE O_C_ID = @C_ID 1 INTRODUCTION Modern distributed database systems and applications frequently 3. SELECT ... FROM ORDER_LINE, ITEM have to handle large query processing latencies resulting from the WHERE OL_I_ID = I_ID and OL_O_ID = @O_ID geo-distribution of data [11, 13, 41].
    [Show full text]
  • SQL Query Cache for the Mysql Database System
    Masaryk University Faculty}w¡¢£¤¥¦§¨ of Informatics !"#$%&'()+,-./012345<yA| SQL query cache for the MySQL database system Master Thesis Brno, April 2002 Martin Klemsa Hereby I state that this thesis is my genuine copyrighted work which I elaborated all by myself. All sources and literature that I used or consulted are properly cited and their complete reference is given. Acknowledgements I would like to thank Jan Pazdziora, the advisor of my thesis, for his help throughout the work. I am very grateful for his advice and valuable discussions. I would also like to thank Michael “Monty” Widenius – the MySQL chief developer – for a never- -ending stream of suggestions. Another thanks go to my family and my friends for their support during the period of time when I was working on this thesis. i Abstract MySQL is a free open source database server. For the purpose of increasing its performance, this paper presents an SQL query cache enhancement for the server. This new feature aims at increasing the server response speed, reducing its load and saving its resources by storing results of evaluated selection queries and retriev- ing them in case of their repeated occurrance. Reviews of previous work done on related subjects are given. System overview of the developed SQL query cache is presented together with a discussion of the problems encountered during its design and implementation. The comparison with the newly released version of the MySQL which contains a built-in query cache is also brought. Benchmarks shown to prove the performance increase of the modified server with repeated selection queries and a discussion about further enhancement and refinement possibilities conclude this paper.
    [Show full text]