MOBILE COMPUTING AND DATABASES by malj

VIEWS: 4 PAGES: 38

									Mobile Databases
Two aspects of mobility:


 user mobility: users communicate (wireless)
  “anytime, anywhere, with anyone”
 device portability: devices can be connected
  anytime, anywhere to the network
  Wireless vs. mobile
  Examples

                      stationary computer
                      notebook in a hotel
                      wireless LANs in historic buildings
                      Personal Digital Assistant (PDA)
The demand for mobile communication creates the
 need for integration of wireless networks into existing
 fixed networks:
  local area networks: standardization of IEEE 802.11,
   ETSI (HIPERLAN)
  Internet: Mobile IP extension of the internet protocol IP
  wide area networks: e.g., internetworking of GSM and ISDN
Mobile Computing Architecture
Terminology


Fixed Network (FN)
Base Station (BS) (Mobile Support Station -
 (MSS))
Fixed Hosts (FH)
Cell - Area covered by BS (1-2 miles)
Handoff - Changing BS by intercell move
Mobile Host (MH) (Mobile Unit (MU))
Location Management

Tracking mobile user
User associated with home
 location server (Home Agent)
May augment by searching in local
 area first
May augment with user profiles
Mobile IP
  Triangle Routing
  Route Optimization
  Location Control (Routing Agent)
Mobile Applications

Information Services (Yellow Pages)
Law Enforcement and Medical
 Emergencies
Sales and Mobile Offices
Weather, Traffic, Sports, Entertainment
Technology Push


Internet: ftp, telnet, email, http,html
Advancing Wireless Communication
 Technologies
Laptop, Notebook, and Palmtop Computers
Data Management Issues

Speed of wireless link
Mobility
Location dependent data; Location specific
 queries
Limited by battery power
Disconnection (Voluntary, Involuntary)
Replication/Caching
Handoff
Medical Example


Ambulance arrives/departs
Closest hospital
Access patient records
Update patient records
Hospital personnel
Order medical supplies
Mobile DB Research


Transaction Processing
Caching - Replication
Broadcast Disks
Agents
Mobility
Location Dependent Data
Recovery
ACID (?)
Location Dependent Data
Value of data depends on location
Temporal Replication - One consistent value at
 one time
Spatial Replication - Multiple different correct
 data values at one time
Temporal Consistency - All data objects satisfy
 a given set of integrity constraints.
Spatial Consistency - Consistency constraints
 satisfied within Data Region.
Location Dependent Queries

Result depends on location
Different from traditional distributed goal of
 location independence
Ex: Yellow Pages, Directions, Map
Predicates based on location: “Find the
 cheapest hotel in Chennai.”
Location constraints: “Find the nearest hotel (to
 me).”
Similarity to Spatial Queries


Spatial Data: Data associated with space
 occupied by object.
Types of spatial queries: contains,
 contained in, intersects, neighboring, east
 of, etc.
Spatial data structures
Spatial operators
Spatial selects and joins
Differences from Spatial Queries


Client is actually moving
Location of client may be    Spatial data is dynamic
 part of the query itself
May depend on direction of movement
Data may not directly contain location
 information
Includes temporal features as well
Querying Moving Objects

Moving Objects Spatio-Temporal (MOST) data
 model
  Dynamic Attributes - Change over time
  Queries over temporal history:
     Instantaneous - Ex: “Find all restaurants I’ll reach in the
      next half hour. ”
     Continuous - Ex: “Find all restaurants within 5 miles.” The
      answer continuously changes as the MU moves.
     Persistent - Ex: “Find the cars that travel greater than 10
      miles in the next half hour.”
Future Temporal Logic (FTL) language
Query Optimization

How best to satisfy the information request
 made by the client?
Different Cost Factors: I/O, network
Different Access Options: cache, FN, broadcast
Dynamic and Adaptable - environment changes
Alternative plans include deciding (based on
 state of MH and environment) whether to
 access in the cache at the MH, to request a
 mobile transaction, or to obtain from a broadcast
 disk.
Caching

Placing data at MU. Usually on disk.
Faster to access from MU than from DBMS in
 fixed network.
Facilitates disconnected operation.
Adaptive to connection mode.
Not just another replica
Pull based
Most work on files not databases
Caching Functions


Data fetching
  Granularity (Page, file, table)
Replacement
Coherency
  Callback - Servers send invalidation messages to
   clients.
  Detection - Clients send queries to servers to.
Updating during disconnect
Data integration when reconnected
Prefetching vs.. Hoarding

Both prefetch data in anticipation of future use.
Prefetching
  Objective is to improve performance (throughput or
   response time).
  Cache miss not catastrophic.
Hoarding
  Objective is to fetch all needed data into MU cache
   prior to disconnect. Thus the goal is to facilitate
   disconnected operation.
  Cache miss is catastrophic.
  OK to overfetch
Mobile Transaction (MT)

Database transaction requested from a MU.
 May execute in FN or MU
Issues
     Disconnect/Handoff
     Mobility
     Location Dependent Data
     Long lived
     MU Resources/ Power
     Recovery/Restart
     Management
MT Requirements
Keep autonomy of local DBMS
Interactive
Advanced transaction models
  Nested
  Multidatabase
Request from MU
Execute anywhere
Capture movement
ACID (?)
MT Approaches

No consensus on accepted approach
MU may not have primary copy of data
  Transaction Proxy: MU does no transaction
   processing
  Read Only Transaction: MU only reads data
  Weak Transaction: Read and update cached data;
   Must synchronize updates with primary copy on FN.
MU may have primary copy of data
MU may access data on other MUs
MT Recovery
Transaction, site, media, network failure - More
 frequent than in wired network.
Different types of failures (partial)
  Handoff
  Voluntary disconnection
  Battery problems
  Lose computer??
Database log plus transaction log
May need compensating transactions
Atomicity for MT


Weaken or provide different types of atomicity
May decompose transaction into
 subtransactions
May require atomicity at lower than transaction
 level
Atomic commitment difficult (expensive)
Global commit/Local Commit
Consistency for MT


Weakening isolation and atomicity may weaken
 this as well.
May divide data into clusters with consistency
 within clusters.
Reintegration of updates after reconnect may
 cause many conflicts.
May use bounded inconsistency.
Impacted by location dependent data
Isolation for MT


May be too restrictive
Can’t always do at MU (disconnection)
Isolation at lower levels in transaction
Commitment at different levels of transaction
Cooperating transactions
Durability for MT


Durability for partial results
May want durability for parts of transactions.
Due to conflicts at reconnect, even durability of
 subtransactions may not be guaranteed.
Local commit vs.. Global commit
MT Concurrency Control

                    1) T1: Lock(Xa);

Mobility of MUs           Read(Xa)                                        Server B
                                              2) T1 moves to B              Cell B
                        Server A
 may increase            Cell A                                                Xb
                                                                               Yb
 message traffic            Xa
                            Ya
                                               3) T1: Lock(Yb);
                                                      Read(Yb)
 for lock
 management                                6) T1: Unlock(Yb);
                                                   Commit;

MU failure may
 leave some data                       7) T1: Unlock(Xa);
                                               Commit;
                                                                       4) T1 moves to C

 locked /unlocked                                Xc
                                                 Yc               5) T1: Lock(Zc);
                                                 Zc                     Write(Zc);
                                                                         Unlock(Zc);
                                              Server C                   Commit
                                               Cell C
  Revised Optimistic Locking

 O2PL-MT
                            LOCK   W_INTEND R_LOCK W_LOCK
 Read locks may be         HELD

  executed at multiple   LOCK
                         REQUEST
  servers.               W_Intend No       Yes    No

 Read unlock can be     R_Lock    No      Yes    No
  executed at any site
                         W_Lock    No      No     No
Kangaroo Transaction (KT)


Built on top of global transactions
Captures data and movement behavior
Data Access Agent in BS - Maintains
 logging and transaction status
Logging at BS
Flexible atomicity
Restart after disconnect
Kangaroo Transaction (cont’d)

Local Transaction - Sequence of read and write
 operations ending in commit or abort
Global Transaction - Sequence of global or local
 transactions
Joey Transaction - Sequence of global and local
 transactions ending in commit, abort, or split
Kangaroo Transaction - Sequence of one or
 more Joeys with last one ending in commit or
 abort.
KT and Movement
Clustering Model

Transaction model is designed to maintain
 consistency of the database.
Database is divided into clusters.
Data is divided into core and quasi copies.
Mobile transactions and operations are
 decomposed into a set of weak and strict
 transactions.
Clustering Model (cont’d)

Weak operations access only data in the same
 cluster. Strict operations allowed database wide
 access. Two copies of data can be maintained
 (strict and weak).
Clusters defined based on location and user
 profile.
Transaction Proxy: updates the transaction
 which are executed at mobile host in the server.
MT Research Limitations


Architectural Assumptions
No support for location dependent data
Few Implementations
  Agent

Application dispatched by and
 working for the client.                    Client   Server


Agent:
  Solves disconnect problem
  Solves slow bandwidth problem   Client    Agent    Server


Client-Agent-Server
Type - Client,Server,Application,User
     Movement - Static,Dynamic
     Number - Single, Multiple
Conclusion


Combine different approaches
Semantic caching
Query Optimization
Adaptive Data Broadcasting
Performance Benchmarks
Location Dependent Queries

								
To top