Mobile Databases

1

• Mobile Databases

2
Mobile computing

• Portable computing devices and wireless
  communications
• Can access data from anywhere, anytime
• Example
• Electronic valets
• News reporting
• Brokerage services
• Automated salesforces

3
Software problems

• Origins in distributed systems
• Problems more challenging
• Asymmetric communication bandwidth
• Limited and intermittent connectivity
• Limited life of power supply of mobile units
• Changing topology of network

4
Mobile Computing Architecture

• Fixed hosts FH fixed network
• Base stations BS gateway to fixed and wireless
  network
• Mobile units MU can be clients or hosts
• Geographic mobility domain divided into cells
• Each supported by a BS
• Movement of mobile units unrestricted
• Must maintain info access contiguity

5
Network Architecture
6
MANET

• Mobile adhoc networks
• MUs do not need to communicate via a fixed
  network
• In MANET, MU responsible for routing own data,
  acting as BS
• Must be able to handle changes in network topology

7
MANET

• Peer-to-peer
• No central control
• Difficult for transaction processing and data
  consistency
• Example applications
• Multi-user games
• Shared white-boards
• Battle information sharing
• Distributed calendars

8
Caching

• To compensate for high latency and unreliable
  connectivity
• Frequently accessed data is cached
• Can work offline if necessary
• Dozing energy conserving state, unreachable
  state
• Can add proxies for unreachable components
• Proxies keep track of updates to cache

9
Database Management Issues

• Entire DB distributed among wired components
• Full or partial replication
• Base station or fixed host has DBMS functionality
• Also able to locate mobile units
• Query and transaction management features for
  mobile environment

10
DM Issues

• Alternatively DB distributed among wired and
  wireless components
• Data management shared among base stations, fixed
  hosts and mobile units

11
Data distribution and replication

• Data unevenly distributed among BS and MU
• Consistency constraints and cache management
• Cache provides most frequently accessed data

12
Transaction models

• Mobile transaction may execute on several BSs
• Central coordination lacking if data distributed
  among wireless components
• Long lived transactions
• ACID properties difficult to guarantee

13
Query processing

• Must know location of data
• Query optimization more difficult because of
  mobility and resource changed of MU
• MU may be in transit or may cross cell boundaries

14
Recovery and Fault tolerance

• Site, media, transaction and communication
  failures
• Voluntary shutdown not a site failure
• Transaction filures can occur during handoff

15
Location-based services

• Location dependent cache information may become
  stale
• Frequently updated location dependent queries
• Then applying spatial queries to refresh cache -
  problem

16
Security

• Mobile data less secure than data at fixed
  location
• Data is more volatile
• Must manage and authorize access to critical data

17
Broadcasting

• Because of latency, server can handle fewer
  clients in same amount of time
• Broadcasting acceptable solution
• Scalable single broadcast of data item can
  satisfy all outstanding requests for data item

18
Related Research -- Data Dissemination (cont.)

• Broadcast-based data dissemination approaches
• Push-based data broadcasting
• Pull-based data broadcasting
• Hybrid data broadcasting

19
Push-based broadcasting

• Data contents within a file or database are
  repeatedly broadcast through the broadcast
  channel
• channel becomes a disk
• clients can retrieve data as it goes by
• expected wait time for a data item is the same

20
Flat broadcasting
21
Broadcast Disks

• broadcast data in different frequencies according
  to their relevant importance
• multi-level memory hierarchy
• hot data are broadcast more frequently then cold
  data
• Data with similar access frequency are grouped
  into disks

22
Server Broadcast Program
23
Pull-based broadcast

• also called adaptive approaches
• data items are broadcast on-demand
• only requested data will appear as data on air

24
Pull-based

• Data broadcasting is prioritized according to
  some metrics
• Most common algorithms are
• First come Fist Served (FCFS) broadcasts the
  pages in the order they are requested.
• Most Requests First (MRF) broadcasts the page
  with maximum number of pending requests.
• Most Requests First Lowest (MRFL) is essentially
  the same as MRF- breaks ties in favor of page
  with the lowest access probability.
• Longest Wait First (LWF) selects the page that
  has the largest total waiting time, i.e., the sum
  of the time that all pending request for the item
  have been waiting. (RW is approximation)

25
(No Transcript)
26
Hybrid data Broadcasting

• mixes both push and pull
• clients to send pull requests for misses on the
  backchannel
• server supports a Broadcast Disk plus interleaved
  responses to the pulls on the front channel
• alleviate the problem of excessively long waiting
  time for some data

27
Related Research -- Indexing

• Clients can save battery power by turning into
  active mode only when interested data are
  broadcast
• (1, m) index method (Imielinski, et al. 94)
• Index is broadcast m times during the broadcast
  of one version of the file

28
Related Research Indexing (cont.)
29
Data Consistency

• Challenges in mobile environments
• Database server typically is stateless,
  especially under broadcast systems
• Mobile clients often cannot maintain a sustained
  network connection
• How to ensure conflict serializability?

30
Data Consistency

• a mobile client may often experience
  voluntary/involuntary disconnections
• Then, it can only read and update data copied
  onto their local cache
• What if data cached updated during disconnection?

31
Concurrency control

• Two-tier replication algorithm (Gray et al. 1996)
• Tentative and Base transacations
• Tentative transactions are transactions executed
  over local copies if disconnected
• tentative transaction will be submitted to the
  server and reprocessed before final installation
• Can be aborted by the server due to the conflicts
  with other transactions
• Base transactions (transactions work only on
  master data)
• transaction becomes durable when the base
  transaction completes
• Drawback deadlocks, system unscalable

32
Concurrency Control

• Certification reports (Barbara, 97)
• Consists of the read/write sets of recently
  committed transactions
• Broadcast periodically by the server
• Clients execute part of validation work locally

33
Concurrency Control

• Optimistic Concurrency Control with Update
  Timestamp (OCC-UTS)
• Server broadcasts invalidation report (IR), which
  contains new timestamps of newly updated data
  items
• If any accessed data item in a local executing
  transaction has an older timestamp, the local
  transactions is aborted

34
Virtual Locks (Ni)

• Lock-based concurrency control approach
• Using server authorization to eliminate
  transaction restarts
• Authorization information is broadcast in the
  broadcast cycle header
• Treat read-only and update transactions
  differently

35
Virtual Locks (cont.)

• Server schedules the data broadcast in the
  following way
• Read-only transactions data requests will be
  satisfied unconditionally
• Update transactions data requests are satisfied
  only if they pass the conflict resolution.

36
Virtual Locks (cont.)

• Read-only transaction
• Does not need explicit server authorization
• May not send data requests to the server as long
  as the required data is on the air within one
  broadcast cycle.
• Commit locally

37
Virtual Locks (cont.)

• Update transaction
• Client always sends the data requests to the
  server
• Can only proceed when it is authorized to begin,
  i.e., its transaction id appears on the air
• Transaction will be submitted to the server for
  final installment

38
Experimental results (uniform access)
39
Experimental Results (Zipf access)
40
(No Transcript)
41
Related Research -- Indexing

• Clients can save battery power by turning into
  active mode only when interested data are
  broadcast
• (1, m) index method (Imielinski, et al. 94)
• Index is broadcast m times during the broadcast
  of one version of the file

42
Related Research Indexing (cont.)
43
Data Consistency

• Challenges in mobile environments
• Database server typically is stateless,
  especially under broadcast systems
• Mobile clients often cannot maintain a sustained
  network connection
• How to ensure conflict serializability?

44
Data Consistency

• a mobile client may often experience
  voluntary/involuntary disconnections
• Then, it can only read and update data copied
  onto their local cache
• What if data cached updated during disconnection?

45
Concurrency control

• Two-tier replication algorithm (Gray et al. 1996)
• Tentative and Base transacations
• Tentative transactions are transactions executed
  over local copies if disconnected
• tentative transaction will be submitted to the
  server and reprocessed before final installation
• Can be aborted by the server due to the conflicts
  with other transactions
• Base transactions (transactions work only on
  master data)
• transaction becomes durable when the base
  transaction completes
• Drawback deadlocks, system unscalable

46
Concurrency Control

• Certification reports (Barbara, 97)
• Consists of the read/write sets of recently
  committed transactions
• Broadcast periodically by the server
• Clients execute part of validation work locally

47
Concurrency Control

• Optimistic Concurrency Control with Update
  Timestamp (OCC-UTS)
• Server broadcasts invalidation report (IR), which
  contains new timestamps of newly updated data
  items
• If any accessed data item in a local executing
  transaction has an older timestamp, the local
  transactions is aborted

48
Virtual Locks (Ni)

• Lock-based concurrency control approach
• Using server authorization to eliminate
  transaction restarts
• Authorization information is broadcast in the
  broadcast cycle header
• Treat read-only and update transactions
  differently

49
Virtual Locks (cont.)

• Server schedules the data broadcast in the
  following way
• Read-only transactions data requests will be
  satisfied unconditionally
• Update transactions data requests are satisfied
  only if they pass the conflict resolution.

50
Virtual Locks (cont.)

• Read-only transaction
• Does not need explicit server authorization
• May not send data requests to the server as long
  as the required data is on the air within one
  broadcast cycle.
• Commit locally

51
Virtual Locks (cont.)

• Update transaction
• Client always sends the data requests to the
  server
• Can only proceed when it is authorized to begin,
  i.e., its transaction id appears on the air
• Transaction will be submitted to the server for
  final installment

52
Experimental results (uniform access)
53
Experimental Results (Zipf access)
54
(No Transcript)
55
(No Transcript)
56
(No Transcript)
57
(No Transcript)
58
(No Transcript)