Mobile Databases

1
Mobile Databases

• Ph. D. student Weigang Ni
• Data Management in Adaptive Broadcast
  Environments

2
Mobile databases

• Mobile database assumes a traditional database
  requiring ACID properties
• Clients are mobile (wireless)
• Environment requires new strategies for
• Concurrency control
• Processing transactions
• Data dissemination
• Querying location dependency

3
Challenges in data management

• Unique features in mobile computing environments
• Asymmetric communication bandwidth
• Server has much higher communication capacity
  than the clients
• Frequent disconnections
• Clients cannot keep network connection all the
  time
• Power limitations
• Mobile clients run on battery power
• Energy saving is a critical issue

4
Network Architecture
5
MANET

• While typically assume DB server on fixed network
• Mobile ad hoc network (MANET) is an autonomous
  system consisting of
• mobile nodes interconnected by wireless links
• often operating in stand-alone fashion
• without any assistance from a pre-existing
  network infrastructure
• DB server can be part of MANET
• Very complex most research in routing issues

6
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

7
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
• Still require ACID properties

8
DM Issues

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

9
Data distribution and replication

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

10
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

11
Query processing

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

12
Recovery and Fault tolerance

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

13
Location-based services

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

14
Security

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

15
Data dissemination

• How does a mobile client access the database
• Widely accepted approach is to broadcast the data
  Data on Air

16
Related Research -- Data Dissemination (cont.)

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

17
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

18
Flat broadcasting
19
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

20
Server Broadcast Program
21
Pull-based broadcast

• also called adaptive approaches
• data items are broadcast on-demand
• only requested data will appear as data on air
• How do decide which page to broadcast next?

22
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.
• 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)

23
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

24
Related Research Indexing (cont.)
25
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?

26
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?
• Virtual Locks (Ni 2003)

27
Lazy Data Request (LDR)

• Pull-based data broadcasting data are broadcast
  on demand (Stathatos, et al. 96)
• Scheduling algorithms
• First Come First Serve (FCFS)
• Most Requests First (MRF)
• Longest Wait First (LWF)
• Requests times Wait (R W)
• Other algorithms based broadcast histories,
  estimation of the probabilities of access for
  each data item.

28
Lazy Data Request (cont.)

• Existing algorithms mainly concern data access
  time.
• Whenever a client has a data request, it sends
  the request to the server Eager Data Request
  (EDR).
• Sending message consumes more battery power than
  receiving message.

29
Lazy Data Request (cont.)

• Motivation wanted data may have already been
  requested by other clients. Why not wait instead.
  Two possible results.
• Issues need to be addressed
• Mobile clients do not communicate with each
  other. Therefore, they cannot decide whether to
  wait or go ahead and send the request
• The system load changes dynamically. A predefined
  waiting time will not work well.

30
Lazy Data Request (cont.)

• Features of Lazy Data Request
• Client do not need to contact the server to get
  the system load information and waiting time.
• The waiting time is dynamically changing
  according to system load.
• LDR approach can apply to nearly all the existing
  on-demand broadcast algorithms

31
Server-side algorithm of LDR

• Step1. Let n be the total number of requested
  data items
• Step 2. Choose ?n data items to be broadcast
  next based on some scheduling algorithm (0 lt ?
  1)
• Step 3. Clear all existing requests for these ?n
  data times.
• Step 4. Broadcast the index section consisting of
  these ?n data items.
• Step 5. Broadcast the data items.
• Eg. Will broadcast (? 100) of data items

32
Client-side algorithm of LDR

• Wait until wanted data or index section is
  broadcast
• If wanted data items come
• download the data
• drop the local pending request
• else
• check the index section
• if wanted data ids in index section
• wait until data are broadcast
• else
• send the pending request(s) to the server

33
Discussion

• Algorithm still work without using index.
  However, index makes the data broadcast more
  predictable and further saves the data request
  messages.
• Adjust the value of ?,
• If ? 1, LDR becomes first come first served
  (FCFS) algorithm
• If ? is very small, LDR virtually becomes EDR as
  every time only a couple of data items are chosen
• Client waiting time is bounded.

34
Experimental results
35
Experimental results (cont.)
36
Conclusions

• Data management in mobile environments
• Concurrency control
• Algorithms proposed produce serializable
  histories
• Outperform existing algorithms
• Adaptive data broadcasting
• Algorithm proposed shows number of data request
  messages can be reduced
• Data access time does not increase