930 likes | 1.66k Views
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
E N D
Mobile computing • Portable computing devices and wireless communications • Can access data from anywhere, anytime • Example: • Brokerage services • News reporting • Traffic/Vehicle services
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
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
Mobile databases • How to guarantee ACID properties • Environment requires new strategies for: • Processing transactions • Concurrency control - caching • Data dissemination • Querying – location dependency
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
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
DB DB
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
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
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?
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
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
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
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
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
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
Assume best of both Mobile DBs for next few topics to consider problems/solutions
Data Management Issues • Environment requires new strategies for: • Querying – location dependency • Concurrency control • Processing transactions • Security • Data dissemination • Recovery/fault tolerance
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
Location-based services • Location dependent cache information may become stale • Frequently updated location dependent queries • Apply spatial queries to refresh cache problem
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
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
Recovery and Fault tolerance • Site, media, transaction and communication failures • Voluntary shutdown not a site failure • Transaction failures can occur during handoff
Security • Mobile data less secure than data at fixed location • Data is more volatile • Must manage and authorize access to critical data
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
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
Broadcast-based data dissemination approaches Push-based data broadcasting Pull-based data broadcasting Hybrid data broadcasting Broadcasting
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
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
Pull-based broadcast • also called adaptive approaches • data items are broadcast on-demand • only requested data will appear as “data on air”
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)
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
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
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
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?
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?
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
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
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
Mobile Databases • Research Issues – 2007 MDM • Atomic commit protocol • Data dissemination • Spatio-temporal range queries • Adhoc networks - data integrity, data replication
Ph. D. student: Weigang Ni Data Management in Adaptive Broadcast Environments
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.
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.
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.
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
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