AICCSA – 2005, Cairo, Egypt
HDC - Hot Data Caching in Mobile Database Systems
Vijay Kumar & Nitin Prabhu
Panos K. Chrysanthis
SCE, Computer Networking
University of Missouri-Kansas City
Kansas City, MO 64110, USA
kumarv@umkc.edu
Computer Science
University of Pittsburgh
Pittsburgh, PA 15260, USA
panos@cs.pitt.edu
Presenter:
Mohamed A. Sharaf
Computer Science
University of Pittsburgh
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
HDC - Hot Data Caching in Mobile Database Systems
Topics covered
Introduction to Mobile Database System
Data caching in mobile environment
Transaction processing
Performance
Conclusions
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
Mobile Database System – MDS
This architecture is based on GSM (Global System for Mobile Communication)
Base Database
Station Controller
(BSC)
Server (DBS)
••ItAll
manages
the activitiesare
of a
mobile transactions
set
of BSs
Baseby
Station
processed
one or(BS)
more DBS
• AMU
BSreaches
serves a cell.
•A
set of DBSs
Mobile
Unit (MU)
• It manages
communication
through
its BS
in
cell. user interacts
• Aits
mobile
• Itwith
communicates
with
BSC
MDS through
this
unit
through
wired line.with the
• It communicates
Base Station (BS) through
a wireless channel
• Examples: PDA, laptop, or
a cell phone
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
HDC - Hot Data Caching in Mobile Database Systems
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 Readonly transactions
Approach: An overlay caching of hot data that:
1. Maximizes the number of transactions satisfied by the
cached snapshot of the database
2. Minimizes rollbacks due to inconsistent data views
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
HDC - Hot Data Caching in Mobile Database Systems
Topics covered
Introduction to Mobile Database System
Data caching in mobile environment
Transaction processing
Performance
Conclusions
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
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
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
Data identification phase – An example
Data Items
D1
T1
1
D8
D10
1
D11
Transactions
D22
1
1
1
1
T5
1
T6
1
T7
1
1
1
1
1
1
3.Remove
transactions
access
the
popular item
2
4
1
1
1
1
1
T10
5
3
4
1
3
1
©
1.Low
sum
value
identifies the least
popular data item
2.Remove the
popular item
1
T8
Sum
D30
1
T4
T9
D20
1
T2
T3
D15
“1” means:
The transaction
needs the data
item
least
that
least
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
Data identification phase – An example
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:
D1
D10
D15
T2
T6
D30
1
1
T8
1
1
T9
1
1
Sum
2
3
1
1
3
1
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
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
HDC - Hot Data Caching in Mobile Database Systems
Topics covered
Introduction to Mobile Database System
Data caching in mobile environment
Transaction processing
Performance
Conclusions
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
Transaction execution
A transactions will fall into one of the following classes:
1.
Active Transaction (AT):
Uses the hot data and it is immediately scheduled for execution
2.
Waiting Transaction (WT):
Uses the warm data and it is transferred to the wait queue
3.
New Transaction:
Will join the AT or WT according to its data requirements
How to schedule the execution of the transaction mix ?
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
Transaction Scheduling
1.
Schedule the new transaction immediately for execution if all of its
required data is available in cache (i.e., hot date)
2.
Add the new transaction to the wait queue if few of its desired data
is available in cache (i.e., warm data)
3.
Send the new transaction to the DBS if none of its desired data is
available in cache (i.e., cold data)
4.
After a predefined interval, create a new cache matrix and refresh
the cache
5.
•
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
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
HDC - Hot Data Caching in Mobile Database Systems
Topics covered
Introduction to Mobile Database System
Data caching in mobile environment
Transaction processing
Performance
Conclusions
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
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
Blocked queue
Cache matrix created
Transaction result
Not all data
in cache
DBS arrival queue
MU (CPU)
New transaction
DBS (CPU)
No data item in
cache or execution
attempts > 2
Arrival queue
Completed transaction
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
Performance measurement
Average transaction wait time with cache size
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
Performance measurement
Cache
Initial cache
1 refresh
2 refresh
To server
100
12%
21%
7%
60%
150
23%
48%
7%
22%
200
30%
70%
0%
0%
250
39%
61%
0%
0%
% of transactions executed in each phase
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
Performance comparison
Percentage Transaction executed at MU in HDC and LFU
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
Performance comparison
Transaction wait time in HDC and LFU
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
Performance comparison
Throughput with MPL in HDC and LFU
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA
AICCSA – 2005, Cairo, Egypt
Conclusions
The work proposed the following:
1.
The Hot Data Caching (HDC) policy which is especially suitable
for the mobile transaction processing
2.
A transaction scheduling mechanism that integrates data and
transaction shipping to reduce the average transaction wait time
Preliminary results show that using our proposed HDC leads to
increasing the number of transactions that are locally executed at the
mobile host. This feature allows HDC to significantly reduces
transactions’ wait time compared to existing caching policies.
©
Vijay Kumar, Nitin Prabhu, Panos K. Chrysanthis, USA