Mobile Databases

1. Mobile Databases

2. Mobile computing • Portable computing devices and wireless communications • Can access data from anywhere, anytime • Example: • Brokerage services • News reporting • Traffic/Vehicle services

3. Mobile DB • Mobile database – data management technology enabling use of databases on mobile computing environment • Data available anywhere independent of availability of fixed network • Can access public data using internet browser • Can access private data through distributed DB • Data on mobile and fixed hosts sharable in seamless way • More complex techniques needed to support this – distributed transaction processing, commit

4. Identifying Mobile characteristics • 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 • Mobile database assumes a traditional database requiring ACID properties

5. Mobile databases • How to guarantee ACID properties • Environment requires new strategies for: • Processing transactions • Concurrency control - caching • Data dissemination • Querying – location dependency

6. Mobile Computing Architecture • Mobile units MU or Mobile Hosts MH • Fixed hosts FH on fixed network • Base Station BS –serves as gateway to fixed and wireless network • Geographic mobility domain divided into cells • Mobile host wireless connection to BS of cell • Movement of mobile units unrestricted • Must maintain info for access contiguity

7. Mobile DB • Mobile DB mix of fixed and wireless network • DBS distributed among wired and wireless componen • Data management shared among base stations, fixed hosts and mobile units • MU – can be data client and/or data server • If a server, with DBMS functionality • minimally need R, W, C, A

8. DB DB

9. Mobile DB • When Mobile DB mix of fixed and wireless network • Fixed – FH location, high capacity, reliability, low connection cost • Wireless – support dynamic network topology, low capacity, reliability, high connection cost

10. Transaction • What is a transaction? • A Transaction is not always just an SQL query • A transaction is also: • From the time you login to SQL Plus until you exit

11. Mobile strategies • Provide data cache on mobile host • Cache replicas of frequently accessed data • Work offline • Reduce power consumption • Client may be unreachable • Dozing - energy conserving state • Out of reach • Proxies – used for unreachable (e.g. update info) • What if data cached updated during disconnection?

12. Mobile strategies • Resources of MU can be limited • Mobile hosts personalized • Bring in fraction of data need to access • MU has low security • Mobile DBs high degree of unavailability • Broadcasting accepted way to disseminate data

13. Mobile DB - Conservative • Can assume entire DB distributed among wired components • Full or partial replication • Base station or fixed host has DBMS functionality • Must be able to locate mobile units • Need query and transaction management features for mobile environment

14. Mobile DB - Conservative • How is this different from distributed non-mobile? • Difficult to maintain sustained connection to server • Database server typically is stateless, especially under broadcast systems • Mobile clients often cannot maintain a sustained network connection

15. MANET – Extreme DB • 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

16. MANET – Extreme DB • 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

17. Mobile DBs – Best of both • Alternatively assume DB distributed among wired and wireless components • What if MU has DBMS functionality? • MU can be laptop • Data management shared among base stations, fixed hosts and mobile units • More interesting problems!! But solvable

18. Assume best of both Mobile DBs for next few topics to consider problems/solutions

19. Data Management Issues • Environment requires new strategies for: • Querying – location dependency • Concurrency control • Processing transactions • Security • Data dissemination • Recovery/fault tolerance

20. 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

21. Location-based services • Location dependent cache information may become stale • Frequently updated location dependent queries • Apply spatial queries to refresh cache problem

22. 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 • Can add proxies for unreachable components • Proxies keep track of updates to cache

23. Data distribution and replication • Data unevenly distributed among BS and MU • To compensate for high latency and unreliable connectivity • Frequently accessed data is cached • Can work offline if necessary • Consistency constraints and cache management

24. Recovery and Fault tolerance • Site, media, transaction and communication failures • Voluntary shutdown not a site failure • Transaction failures can occur during handoff

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

26. Data Dissemination -Broadcasting Assumptions: Requests are read-only (Most are) • 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

27. Data Dissemination -Broadcasting Assumptions: Requests are read-only (Most are) • 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

28. Broadcast-based data dissemination approaches Push-based data broadcasting Pull-based data broadcasting Hybrid data broadcasting Broadcasting

29. 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

30. Flat broadcasting

31. 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

32. Server Broadcast Program

33. Pull-based broadcast • also called adaptive approaches • data items are broadcast on-demand • only requested data will appear as “data on air”

34. Pull-based • Data broadcasting is prioritized according to some metrics • Most common algorithms are: • First come First 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. (R*W is approximation)

35. Pull-based • MRF – best response time at high system loads and page requests uniformly distributed • LWF – best response time when page request distributed by Zipf

36. 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

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

38. Related Research – Indexing (cont.)

39. Data Consistency • Assumption: Read and Write transactions • Challenges in mobile environments • Difficult to maintain sustained connection to server • Database server typically is stateless, especially under broadcast systems • Mobile clients often cannot maintain a sustained network connection • How to ensure conflict serializability?

40. Research in Data Consistency • Assumptions: • Read and Write transactions • MU has DBMS functionality • Mobile unit 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?

41. Concurrency Control • Two-tier replication algorithm (Gray et al. 1996) • Tentative and Base transactions • 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 conflicts with other transactions • Base transactions (transactions work only on master data) • transaction becomes durable when the base transaction completes • Drawback – deadlocks, system unscalable

42. Certification reports - CR (Barbara, ’97) Consists of the read/write sets of recently committed transactions Broadcast periodically by the server Clients execute part of validation work locally Must submit to server for final validation Concurrency Control

43. 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

44. Mobile Databases • Research Issues – 2007 MDM • Atomic commit protocol • Data dissemination • Spatio-temporal range queries • Adhoc networks - data integrity, data replication

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

46. Lazy Data Request (LDR) • Pull-based data broadcasting – data are broadcast on demand (Stathatos, et al. ) • 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.

47. LDR • 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.

48. LDR • 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.

49. LDR • 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

50. 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 <  ≤ 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