Vijay Kumar & Nitin Prabhu SCE, Computer Networking University of Missouri-Kansas City

HDC - Hot Data Caching in Mobile Database Systems Vijay Kumar & Nitin Prabhu SCE, Computer Networking University of Missouri-Kansas City Kansas City, MO 64110, USA kumarv@umkc.edu Panos K. Chrysanthis Computer Science University of Pittsburgh Pittsburgh, PA 15260, USA panos@cs.pitt.edu Presenter: Mohamed A. Sharaf Computer Science University of Pittsburgh

HDC - Hot Data Caching in Mobile Database Systems • Outline • Mobile Database System & Mobile transaction Processing • Overlay data caching in mobile environment • Transaction processing with overlay caching • Performance evaluation • Conclusions

Mobile Database System – MDS This architecture is based on GSM (Global System for Mobile Communication) • Base Station Controller (BSC) • It manages the activities of a set of BSs • Database Server (DBS) • All mobile transactions are processed by one or more DBS • A MU reaches a set of DBSs through its BS • Base Station (BS) • A BS serves a cell. • It manages communication in its cell. • It communicates with BSC through wired line. • Mobile Unit (MU) • A mobile user interacts with MDS by submitting trans-actions through this unit • It communicates with the Base Station (BS) through a wireless channel • Examples: PDA, laptop, or a cell phone

Efficient Mobile Transaction Processing • A challenge: Due to communication and resource constraints as well as disconnected operations • Current solutions: • Execute on MU all locally submitted transactions by caching all required data (data shipping) • Submit all transactions for execution at the database servers (transaction shipping) • Combination of data and transaction shipping based on some criteria. E.g., - Execute locally RO transaction; ship update transactions - Keep data expanding transactions, ship data reducing ones

Our Goal • Problem Statement: Maximize the throughput (Minimize the response time) of read-only transactions submitted at a mobile unit • Contribution: An integrated data-transaction shipping scheme that uses hot data caching to maximize correct local execution of read-only transactions • Approach: An overlay caching of hot data that: • Maximizes the number of transactions satisfied by the cached snapshot of the database • Minimizes rollbacks due to inconsistent data views

HDC - Hot Data Caching in Mobile Database Systems • Topics covered • Introduction to Mobile Database System • Data caching in mobile environment • Transaction processing • Performance • Conclusions

Overlay caching: Basic Idea! • Overlay caching is a kind of group optimization • A user initiates transactions through a MU. • with specific data requirements from databases • MU rebuilds its cache in phases • it requests a set of data at a time based on multiple transactions’ needs • rather than incrementally, one at a time, based on the needs of a single transaction in-progress • Thus, it has two advantages • incurs less communication overhead and • reduces transaction aborts since each data in a set are consistent with each other

Data identification for caching A user initiates transactions through a MU. Then, the MU performs the following steps: • Identifies the transaction’s data requirement • Preprocessing method • Profile-driven method • Builds a data structure, refer to as “cache matrix”, to store these data • Combines the new needed data with the data already cached

Data identification phase – An example “1” means: The transaction needs the data item Data Items • Low sum value identifies the least popular data item • Remove the least popular item • Remove transactions that access the least popular item Transactions

Data identification phase – An example (cont.) The elimination continues until the number of data items is less than or equal to the cache size Example, if cache size = 4, then cache matrix is: Hot Data = Data items for caching D1, D10, D15, D30  current cache contents (empty initially) = D1, D10, D15, D30 Warm Data = Data items required by T1, T3, T4, T5, T7, and T10

Transaction execution • A transactions will fall into one of the following classes: • Active Transaction (AT): • Uses the hot data and it is immediately scheduled for execution • Waiting Transaction (WT): • Uses the warm data and it is transferred to the wait queue • New Transaction: • Will join the AT or WT according to its data requirements • How to schedule the execution of the transaction mix ?

Transaction Scheduling • Schedule the new transaction immediately for execution if all of its required data is available in cache (i.e., hot data) • Add the new transaction to the wait queue if few of its needed data is available in cache (i.e., warm data) • Send the new transaction to the DBS if none of its needed data is available in cache (i.e., cold data) • After a predefined interval, create a new cache matrix and refresh the cache • Some of the waiting transactions will become active • Some of the waiting transactions will continue waiting • To avoid starvation, a waiting transaction is sent to the server after a predefined number of cache refreshes

Simulation Model • Assumptions: • An upper limit on the number of transactions that can be executed concurrently, called MPL • A new cache matrix is created if the number of waiting transactions is equal to MPL • A waiting transaction is shipped to the server after two cache refreshes

Performance measurement Average transaction wait time with cache size

Performance measurement % of transactions executed in each phase

Performance comparison Percentage Transaction executed at MU in HDC and LFU

Performance comparison Transaction wait time in HDC and LFU

Performance comparison Throughput with MPL in HDC and LFU

Conclusions & Next Step • The two major contributions of this work: • The Hot Data Caching (HDC) policy, an overlay caching scheme, which is especially suitable for the mobile transaction processing • A transaction scheduling mechanism that integrates data and transaction shipping to reduce the average transaction wait time • Preliminary Performance results show that: • our proposed HDC increases the number of transactions that are locally executed at the mobile host. • hence HDC significantly reduces transactions’ wait time compared to existing caching policies. • Future work: • Detail experimental evaluation with real workloads • Investigate the potential synergy between data broadcasting and HDC caching

Final Remarks • A new version of the paper will be available soon at our web site: http://db.cs.pitt.edu • For questions and comments please email us • panos@cs.pitt.edu • kumarv@umkc.edu • Thank you & Happy New year!!

Vijay Kumar & Nitin Prabhu SCE, Computer Networking University of Missouri-Kansas City