1 / 93

Mobile Databases

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

liam
Télécharger la présentation

Mobile Databases

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related