Mobile and Wireless Database Access for Pervasive Computing - PowerPoint PPT Presentation

1 / 96
About This Presentation
Title:

Mobile and Wireless Database Access for Pervasive Computing

Description:

Adaptability and Mobile Client-Server Models. Location ... impersonation, theft, trust. consuming resources in a foreign environment. damage to fixed hosts? ... – PowerPoint PPT presentation

Number of Views:339
Avg rating:3.0/5.0
Slides: 97
Provided by: scie360
Category:

less

Transcript and Presenter's Notes

Title: Mobile and Wireless Database Access for Pervasive Computing


1
Mobile and Wireless Database Access for Pervasive
Computing
An IEEE ICDE 2000 Tutorial on
  • Panos K. Chrysanthis
  • University of Pittsburgh Carnegie Mellon
    University
  • Evaggelia Pitoura
  • University of Ioannina
  • panos_at_cs.pitt.edu pitoura_at_cs.uoi.gr

2
Outline
  • Motivating Example
  • Issues Mobility, Wireless Communication,
    Portability
  • Adaptability and Mobile Client-Server Models
  • Location Management
  • Broadcast data dissemination
  • Disconnected database operations
  • Mobile Access to the Web
  • Mobility in Workflow Systems
  • State of Mobile DB Industry and Research Projects
  • Unsolved Problems

3
Party on Friday
  • Update Smart Phones calendar with guests names.
  • Make a note to order food from Dinner-on-Wheels.
  • Update shopping list based on the guests drinking
    preferences.
  • Dont forget to swipe that last can of beers UPS
    label.
  • The shopping list is always up-to-date.

4
Party on Friday
  • AutoPC detects a near Supermarket that advertises
    sales.
  • It accesses the shopping list and your calendar
    on the Smart Phone.
  • It informs you the soda and beer are on sale, and
    reminds you.
  • that your next appointment is in 1 hour.
  • There is enough time based on the latest traffic
    report.

5
Party on Friday
  • TGIF
  • Smart Phone reminds you that you need to order
    food by noon.
  • It downloads the Dinner-on-Wheels menu from the
    Web on your PC with the guests preferences
    marked.
  • It sends the shopping list to your
  • CO-OPs PC.
  • Everything will be delivered by the time
  • you get home in the evening.

6
Mobile Applications
  • Expected to create an entire new class of
    Applications
  • new massive markets in conjunction with the Web
  • Mobile Information Appliances - combining
    personal computing and consumer electronics
  • Applications
  • Vertical vehicle dispatching, tracking, point of
    sale
  • Horizontal mail enabled applications, filtered
    information provision, collaborative computing

7
Mobile and Wireless Computing
  • Goal Access Information Anywhere, Anytime,
    and in Any Way.
  • Aliases Mobile, Nomadic, Wireless, Pervasive,
    Invisible, Ubiquitous Computing.
  • Distinction
  • Fixed wired network Traditional distributed
    computing.
  • Fixed wireless network Wireless computing.
  • Wireless network Mobile Computing.
  • Key Issues Wireless communication, Mobility,
    Portability.

8
Wireless Communication
  • Cellular - GSM (Europe), TDMA CDMA (US)
  • FM 1.2-9.6 Kbps Digital 9.6-14.4 Kbps
    (ISDN-like services)
  • Public Packet Radio - Proprietary
  • 19.2 Kbps (raw), 9.6 Kbps (effective)
  • Private and Share Mobile Radio
  • Wireless LAN - wireless LAN bridge (IEEE 802.11)
  • Radio or Infrared frequencies 1.2 Kbps-15 Mbps
  • Paging Networks typically one-way communication
  • low receiving power consumption
  • Satellites wide-area coverage (GEOS, MEOS,
    LEOS)
  • LEOS 2.4 Kbps (uplink), 4.8Kbps (downlink)

9
Mobile Network Architecture
10
Future Wireless Communication
  • Source Rysavy Research, 1999

11
Wireless characteristics
  • Variant Connectivity
  • Low bandwidth and reliability
  • Frequent disconnections
  • predictable or sudden
  • Asymmetric Communication
  • Broadcast medium
  • Monetarily expensive
  • Charges per connection or per message/packet
  • Connectivity is weak, intermittent and expensive

12
Portable Information Devices
  • PDAs, Personal Communicators
  • Light, small and durable to be easily carried
    around
  • dumb terminals InfoPad, ParcTab projects,
  • palmtops, wristwatch PC/Phone, walkstations
  • will run on AA /Ni-Cd/Li-Ion batteries
  • may be diskless
  • I/O devices Mouse is out, Pen is in
  • wireless connection to information networks
  • either infrared or cellular phone
  • specialized HW (for compression/encryption)

13
Portability Characteristics
  • Battery power restrictions
  • transmit/receive, disk spinning, display, CPUs,
    memory consume power
  • Battery lifetime will see very small increase
  • need energy efficient hardware (CPUs, memory) and
    system software
  • planned disconnections - doze mode
  • Power consumption vs. resource utilization

14
Portability Characteristics
  • Resource constraints
  • Mobile computers are resource poor
  • Reduce program size interpret script languages
    (Mobile Java?)
  • Computation and communication load cannot be
    distributed equally
  • Small screen sizes
  • Asymmetry between static and mobile computers

15
Mobility Characteristics
  • Location changes
  • location management - cost to locate is added to
    communication
  • Heterogeneity in services
  • bandwidth restrictions and variability
  • Dynamic replication of data
  • data and services follow users
  • Querying data - location-based responses
  • Security and authentication
  • System configuration is no longer static

16

What Needs to be Reexamined?
  • Operating systems
  • File systems
  • Data-based systems
  • Communication architecture and protocols
  • Hardware and architecture
  • Real-Time, multimedia, QoS
  • Security
  • Application requirements and design
  • PDA design Interfaces, Languages


17

Query/Transaction
Processing
  • Concern moves from CPU time and network delays to
    battery power and communication costs (including
    tariffs)
  • Updates may take the form of long-running
    transactions
  • nodes may continue in disconnected mode
  • need new transaction models Chrysanthis 93,
    Satya 94
  • Move data vs. move query/transaction
  • Context (location) based query responses
  • Consistency, autonomy, recovery
  • Approximate answers
  • Stable storage for logs, data -- stabilize at
    servers?
  • Providing uniform access in a heterogeneous
    environment
  • Design of human-computer interfaces (pen-based
    computing)
  • Updated system info Location information, user
    profiles

18
Recurrent Themes
  • Handling disconnections (planned failures?)
  • caching strategies
  • managing inconsistencies
  • Delayed write-back and prefetch use network idle
    times
  • increases memory requirements
  • Buffering/batching allows bulk transfers
  • Partitioning and replication
  • triggered by relocation
  • Compression increase effective BW
  • increases battery power requirements
  • Receiving needs less power than sending

19
Issues in Information Provision
  • tariff
  • scalability massive users accessing read-only
    data
  • security (of data and user profiles/location)
  • impersonation, theft, trust
  • consuming resources in a foreign environment
  • damage to fixed hosts?
  • approximate answers
  • consistency, autonomy, recovery
  • PDAs are unreliable
  • prioritization of actions upon reconnection
  • providing uniform access in a heterogeneous
    environment
  • design of human-computer interfaces (pen-based
    computing)

20
Outline
  • Motivating Example
  • Issues Mobility, Wireless Communication,
    Portability
  • Adaptability and Mobile Client-Server Models
  • Location Management
  • Broadcast data dissemination
  • Disconnected database operations
  • Mobile Access to the Web
  • Mobility in Workflow Systems
  • State of Mobile DB Industry and Research Projects
  • Unsolved Problems

21
Mobility in Db Applications
  • Need to adapt to constantly changing environment
  • network connectivity
  • available resources and services
  • By varying and (re)negotiating
  • the partition of duties between the mobile and
    static elements
  • the quality of data available at the mobile host
  • Example Fidelity (degree to which a copy of data
    matches the reference copy at the server)

22
Adaptability
  • Where should support for mobility and
    adaptability be placed?

Application-Aware
Laissez-Faire
Application Transparent
() existing applications continue to work
unchanged (-) too general, cannot take advantage
application semantics (-) may not be attainable
(e.g., during a long disconnection)
(-) applications must be re-written which may be
very complicated (-) no focal point of control to
resolve potentially incompatible application
demands or to enforce limits on resource usage
23
Adaptive Applications
  • Need
  • Measurement of QoS and communication with
    application
  • A mechanism to monitor the level and quality of
    information and inform applications about
    changes.
  • Programmer Interface for Application-Aware
    Adaptation
  • Applications must be agile able to reveive
    events in an asynchronous manner and react
    appropriately
  • A central point for managing resources and
    authorizing any application-initiated request.

24
Application Awareness
  • Need for.
  • A mechanism to monitor the level and quality of
    information and inform applications about
    changes.
  • Applications must be agile able to reveive
    events in an asynchronous manner and react
    appropriately (triggers)
  • A central point for managing resources and
    authorizing any application-initiated request.

25
C-SA-C Server-side Agent
  • C-SA-C The Client/Server-side Agent/Server
    Model
  • Splits the interaction between the mobile client
    and server client-agent and agent-server
  • different protocols for each part of the
    interaction
  • each part may be executed independently of the
    other

26
Responsibilities of the Agent
  • Messaging and queying
  • Manipulate data prior to their transmission to
    the client
  • perform data specific compression
  • batch together requests
  • change the transmission order

27
Role of the Agent
  • Surrogate or proxy of the client
  • Any communication to/from the client goes through
    the agent
  • Offload functionality from the client to the
    agent
  • Application (service) specific
  • provides a mobile-aware layer to specifc services
    or applications (e.g., web-browsing or database
    access)
  • handles all requests from mobile clients
  • Filters
  • provide agents that operate on protocols
  • E.g., an MPEG-agent or a TCP-agent

28
C-CA-S Client-side Agent
  • C-SA-S The Client/Client-side Agent/Server Model
  • caching
  • background prefetching and hoarding
  • various communication optimizations

29
C-I-S Client Server Agents
Wireless Link
Fixed Network
Agent
Client
Server
Agent
Mobile Host
  • C-I-S Client/Intercept/Server Model
  • Caching, prefetching etc
  • various communication optimizations at both ends
  • E.g., asynchronous queued RPC
  • relocate computation between the agents
  • Client interoperability

30
Mobile Agents
  • Mobile agents are migrating processes associated
    with an itinerary
  • dynamic code and state deployment
  • Implement the agents of the previous
    architectures as mobile agents, E.g.,
  • server-side agents can relocate during handoff
  • client-side agent dynamically move on and off the
    client
  • Relocatable dynamic objects (RDO) Rover
  • Implement the communication using mobile agents
  • clients submit/receive mobile agents to/from the
    server
  • E.g., Compacts Pro-Motion

31
A Taxonomy
32
Outline
  • Motivating Example
  • Issues Mobility, Wireless Communication,
    Portability
  • Adaptability and Mobile Client-Server Models
  • Location Management
  • Broadcast data dissemination
  • Disconnected database operations
  • Mobile Access to the Web
  • Mobility in Workflow Systems
  • State of Mobile DB Industry and Research Projects
  • Unsolved Problems

33
Locating Moving Objects
  • Example of moving objects
  • mobile devices (cars, cellular phones, palmtops,
    etc)
  • mobile users (locate users independently of the
    device they are currently using)
  • mobile software (e.g., mobile agents)
  • How to find their location - Two extremes
  • Search everywhere
  • Store their current location everywhere
  • Searching vs. Informing

34
Locating Moving Objects
  • What (granularity), where (availability) and when
    (currency) to store

at all sites
Availability
At selective sites (e.g., at frequent callers)
the whole network
nowhere
Exact location
some partition
Currency
Granularity
Never update
Always update (at each movement)
35
Architectures of Location DBs
  • Two-tier Schemes (similar to cellular phones)
  • Home Location Register (HLR) store the location
    of each moving object at a pre-specified location
    for the object
  • Visitor Location Register (VLR) also store the
    location of each moving object mo at a register
    at the current region
  • Hierarchical Schemes
  • Maintain multiple registries

36
Two-tier Location DBs
  • Search
  • Check the VLR at your current location
  • If object not in, contact the objects HLR
  • Update
  • Update the old and new VLR
  • Update the HLR

37
Hierarchical Location DBs
Maintain a hierarchy of location registers
(databases) A location database at a higher level
contains location information for all objects
below it

38
Hierarchical Location DBs
Call
caller
39
Hierarchical Location DBs
Move
new location
old location
40
Hierarchical vs. Two-tier
() No pre-assigned HLR () Support
Locality (-) Increased number of operations
(database operations and communication
messages) (-) Increased load and storage
requirements at the higher-levels
41
Locating Moving Objects
Partitions
P3
P4
P5
P1
P2
User x
User x
42
Locating Moving Objects
  • Caching
  • cache the callees location at the caller
  • (large Call to Mobility Ratio)
  • Replication
  • replicate the location of a moving object at its
    frequent callers (large CMR)
  • Forwarding Pointers
  • do not update the VLR and the HLR, leave a
    forwarding pointer from the old to the new VLR
    (small CMR)
  • When and how forwarding pointers are purged?
  • Concurrency, coherency and recovery/checkpointing
    of location DBs

43
Querying Moving Objects
  • Besides locating moving objects, answer more
    advanced queries, e.g.,
  • find the nearest service
  • send a message to all mobile objects in a
    specific geographical reafion
  • Location queries spatial, temporal or
    continuous
  • Issues representation, evaluation and
    imprecision

Most current research assumes a centralized
location database
44
Querying Moving Objects
  • How to model the location of moving objects?
  • Dynamic attribute (its value change with time
    without an explicit update) e.g., in MOST
  • For example, dynamic attribute A with three
    sub-attributes A.value, A.updatetime and
    A.function
  • (function of a single variable t that has value
    0 at time t0)
  • The value of A at A.updatetime is A.value
  • at time A.updatetime t0 is A.value
    A.function(t0)

45
Querying Moving Objects
  • How to represent and index moving objects?
  • Spatial indexes do not work well with
    dynamically changing values
  • Value-time representation
  • An object is mapped to a trajectory Kollios
    99

46
Outline
  • Motivating Example
  • Issues Mobility, Wireless Communication,
    Portability
  • Adaptability and Mobile Client-Server Models
  • Location Management
  • Broadcast data dissemination
  • Disconnected database operations
  • Mobile Access to the Web
  • Mobility in Workflow Systems
  • State of Mobile DB Industry and Research Projects
  • Unsolved Problems

47

Information
Dissemination
  • Goal Maximize query capacity of servers,
    minimize energy per query at the client.
  • Focus Read-only transactions (queries).
  • Clients send update data to server
  • Server resolves update conflicts, commits updates
  • 1. Pull PDAs demand, servers respond.
  • backchannel (uplink) is used to request data and
    provide feedback.
  • poor match for asymmetric communication.

48
Information Dissemination
  • 2. Push Network servers broadcast data, PDA's
    listen.
  • PDA energy saved by needing receive mode only.
  • scales to any number of clients.
  • data are selected based on profiles and
    registration in each cell.

49
Information Dissemination
  • 3. Combinations Push and Pull (Sharing the
    channel).
  • Selective Broadcast Servers broadcast "hot"
    information only.
  • "publication group" and "on-demand" group.
  • On-demand Broadcast Servers choose the next item
    based on requests.
  • FCFS or page with maximum of pending requests.

50
Broadcast Data Dissemination
  • business data, e.g., Vitria, Tibco
  • election coverage data
  • stock related data
  • traffic information
  • sportscasts, e.g., Praja
  • Datatacycle Herman
  • Broadcast disks

51
Organization of Broadcast data
  • Flat broadcast the union of the requested data
    cyclic.
  • Skewed (Random)
  • broadcast different items with different
    frequencies.
  • goal is that the inter-arrival time between two
    instances of the same item matches the clients'
    needs.

52
Broadcast Disks
  • Multi-Disks Organization Acharya et. al,
    SIGMOD95
  • The frequency of broadcasting each item depends
    on its access probability.
  • Data broadcast with the same frequency are viewed
    as belonging to the same disk.
  • Multiple disks of different sizes and speeds are
    superimposed on the broadcast medium.
  • No variant in the inter-arrival time of each item.

A B A C
53

Selective
Tuning
  • Basic broadcast access is sequential
  • Want to minimize client's access time and tuning
    time.
  • active mode power is 250mW, in doze mode 50µW
  • What about using database access methods?
  • Hashing broadcast hashing parameters h(K)
  • Indexing index needs to be broadcast too
  • "self-addressable cache on the air"
  • () "listening/tuning time" decreases
  • (-) "access time" increases

54
Access Protocols
  • Two important factors affect access time
  • Size of the broadcast
  • Directory miss factor - you tune in before your
    data but after your directory to the data!
  • Trade-Off ? Size means ? Miss factor
  • Trade-Off ? Size means ? Miss factor

55
Indexing
  • (1,M) Indexing
  • We broadcast the index M times during one version
    of the data.
  • All buckets have the offset to the beginning of
    the next index segment.
  • Distributed Indexing
  • Cuts down on the replication of index material
  • Divides the index into
  • replicated top L levels, non-replicated bottom
    4-L levels
  • Flexible Indexing
  • Broadcast divided into p data segments with
    sorted data.
  • A binary control index is used to determine the
    data segment
  • A local index to locate the specific item within
    the segment

56

Caching in
Broadcasting
  • Data are cache to improve access time
  • Lessen the dependency on the server's choice of
    broadcast priority
  • Traditionally, clients cache their "hottest" data
    to improve hit ratio
  • Cache data based on PIX
  • Probability of access (P)/Broadcast
    frequency (X).
  • Cost-based data replacement is not practical
  • requires perfect knowledge of access
    probabilities
  • comparison of PIX values with all resident pages
  • Alternative LIX, LRU with broadcast frequency
  • pages are placed on lists based on their
    frequency (X)
  • lists are ordered based on L, the running avg. of
    interaccess times
  • page with lowest LIX L/X is replaced

57
Prefetching in Broadcasting
  • Client prefetch page in anticipation of future
    accesses
  • No additional load to the server and network
  • Prefetching instead of waiting for page miss can
    reduce the cost of a miss
  • PT prefetching heuristic Archarya et al. 96
  • - pt Access Probability (P) period (T) before
    page appears next
  • - A broadcast page b replaces the cached page c
    with lowest pt value
  • Team tag - Teletext approach Ammar 87
  • Each page is associated with a set of pages most
    likely to be requested next
  • When p is requested, D (Dcache size) associated
    pages are prefetched
  • Prefetching stops when client submit a new
    request

58

Cache
Invalidation Techniques
  • When?
  • Synchronous send invalidation reports
    periodically
  • Asynchronous send invalidation information for
    an item as soon as its value changes E.g., Bit
    Sequences Jing 95
  • To whom?
  • Stateful server to affected clients
  • Stateless server broadcast to everyone
  • What?
  • invalidation only which items were updated
  • propagation the values of updated items are sent
  • aggregated information/ materialized views

59

Synchronous
Invalidation
  • Stateless servers are assumed.
  • Types of client Workalcholic and sleepers
    Barbara Sigmod 94
  • Strategies
  • Amnestic Terminals broadcast only the
    identifiers of the items that changed since the
    last invalidation report
  • abort T, if x ? RS(T) appears in the
    invalidation report
  • Timestamp Strategy broadcast the timestamps of
    the latest updates for items that have occurred
    in the last w seconds.
  • abort T, if ts(x) gt
    tso(T)
  • Signature Strategy broadcast signatures.
  • A signature is a compressed checksum similar to
    the one used for file comparison.

60

Consistency and
Currency
  • Only committed data are included in the broadcast
  • Does a client read current and consistent data?
  • Currency interval is the fraction of bcycle that
    updates are reflected
  • Span(T) is the of currency intervals from which
    T read data
  • if Span(T) 1, the T is correct (read consistent
    data)
  • else ?
  • ... several consistency models

61
Consistency Criteria
  • Latest value clients read the most recent value
    of a data item Garcia-Molina TODS82, Acharya
    VLDB96
  • Serializability Certification reports Barbara
    ICDCS97
  • Update consistency clients commit of their reads
    are not invalidated read mutually consistent
    data
  • F-Matrix method Shanmugasundaram SIGMOD99
  • 2-level serializability Each client is
    serializable with respect to the server
  • SGT method PitouraChrysanthis ICDS99
  • Multiversion PitouraChrysanthis VLDB99

62
Currency in Multiversion Schemes

Multiversioning with invalidation
Versioning Multiversioning
Invalidation
begin (first read)
first invalidation
commit
Ts lifetime
10
VLDB 1999
63
Adaptive Hybrid Broadcast
  • Cycle-based, bidirectional hybrid broadcast
    server
  • Issues
  • Dynamic computation of bandwidth allocated to
    each broadcast mode
  • Dynamic classification of data items (periodic
    vs. on-demand)
  • Scheduling periodic and on-demand broadcasts

64
An Approach
  • After each broadcast cycle, items classified as
    periodic or on-demand, depending on bandwidth
    savings expected
  • Periodic broadcast occupies up to BWThreshold
  • Periodic broadcast program is computed to satisfy
    all deadlines of periodic data
  • On-demand broadcast uses on-line EDF
  • (Earliest Deadline First) algorithm batching

65
Outline
  • Motivating Example
  • Issues Mobility, Wireless Communication,
    Portability
  • Adaptability and Mobile Client-Server Models
  • Location Management
  • Broadcast data dissemination
  • Disconnected database operations
  • Mobile Access to the Web
  • Mobility in Workflow Systems
  • State of Mobile DB Industry and Research Projects
  • Unsolved Problems

66
Database Systems Issues
  • Issues
  • Battery power restrictions
  • Resource restrictions
  • Bandwidth restrictions and variability
  • Frequent/planned disconnections
  • Solutions
  • Power conservation techniques
  • Wireless broadcast, broadcast disks
  • Disconnected operations
  • Hoarding, caching, prefetching, consistency
    management
  • Programmer Interface for Application-aware
    Adaptation.

67
Disconnected Operations
  • Issues
  • Cache misses are more expensive in mobile
    environments.
  • Data availability for disconnected operation
  • Data consistency given that global communication
    is costly
  • Autonomy vs. Consistency
  • Solutions
  • Caching
  • Prefetching
  • Hoarding
  • Eventual consistency
  • Assumption simultaneous sharing other than
    read is rare.
  • Update conflict detection/resolution

68
Caching
  • What to cache?
  • Entire files, directories, tables, objects
  • Portions of files, directories, tables, objects
  • When to cache? Is simple LRU sufficient?
  • LRU captures an aspect of temporal locality
  • Predictive/semantic caching based on the
    semantics distance between data/request
  • E.g., clustering of queries Ren 99

69
Prefetching
  • Online strategy to improve performance
  • prepaging
  • prefetching of file
  • prefetching of database objects
  • What to fetch?
  • access tree (semantic structure)
  • probabilistic modeling of user behavior
  • Old idea that can be used during network idle
    times
  • Combine delayed writeback and prefetch

70
Hoarding
  • Planned and Accidental disconnections are not
    considered failures.
  • New idea - Hoarding
  • a technique to reduce the cost of cache misses
    during disconnection.
  • That is, load before disconnect and be ready.
  • How to do hoarding?
  • user-provided information (client-initiated
    disconnection)
  • explicitly specify which data
  • Implicitly based on the specified application
  • access structured-based (use past history)
  • E.g., tree-based in file systems, access paths
    (joins) in DBs

71
Hoarding in DB Systems
  • Granularity of Hoarding
  • RDBMS ranges from tables, set of tables, whole
    relations
  • OO OR DBMS objects, set of objects or class
  • Hoard by issuing queries or materialized views
  • User may explicit issue hoarding queries
  • E.g., Create View with Update-On clause Lauzac
    98
  • OO query to describe hoarding profiles
    Gruber 94
  • History of past references both queries and data
    objects
  • Hoard Keys - an extended database organization
    Badrinath 98
  • hoard keys are used to partition a relation in
    disjoint logical horizontal fragments

72
Processing the Log
  • What information to keep in the log for effective
    reintegration and log optimization?
  • Data values, timestamps, operations
  • Goal Keep the log size small to
  • Save memory
  • Reduce cost for update propagation and
    reintegration
  • When to optimize the log
  • Incrementally each time a new operation is added
  • Before propagation or integration
  • Optimizations are system specific
  • E.g., keep last write record, drop records of
    inverted operations

73
Cache Coherence/Data Consistency
  • "Lazy" or weak consistency promises high
    availability
  • Consider some conflicts (e.g., write-write
    conflicts)
  • Read-any/Write-any
  • Other schemes are costly
  • Pessimistic replication schemes/Quorum schemes
  • Server-initiated callbacks for cache invalidation
    (e.g., Leases).
  • Optimistic replication schemes
  • System support for
  • detection of conflicts version vector,
    timestamps
  • automatic resolution or manual resolution (tools)

74
Techniques to Increase Autonomy
  • Mobile Database Consistency
  • When a mobile database M shares a data item with
    another database D, it is involved in a global
    integrity constraint C.
  • Transactions on both M and D may suffer
    unbounded and unpredictable delays - No local
    commitment.
  • What about localizing the constraints no global
    constraints?
  • Localization
  • reformulates C so that M accepts a local
    constraint C instead
  • Local transactions remain local.
  • When C is violated at a node, it requests the
    others for re-localization, i.e., a dynamic
    readjustment of C.
  • No need for a distributed transaction.
  • No inconsistency from concurrent requests

75
Localization of Constraints
  • Simple Example
  • Let x and y be two data items at two nodes.
  • C J.x K.y gt D is a global constraint.
  • Localization yields two local constraints
  • x gt L1 and y gt L2
  • where L1 and L2 are constants chosen such that
    J.L1 K.L2 gt D
  • Re-localization L1, L2 can be changed node y
    increases L2 before node x decreases L1

76
Localization Methods
  • Escrowing Logically partitions aggregated items
  • Escrow transactions ONeil 86
  • Demarkation protocol Barbara 91
  • Geormetric Method Mazumdar 99 Enhanced
    Escrowing
  • It tackles quadratic inequalities
  • Fragmentation Walborn 95 Physically
    partitions item with constraints localized within
    the individual fragments
  • Fragmentable objects fragments are merged to the
    originating position
  • Reorderable Objects fragments can be
    re-organized during the merging

77
Two-tier Transaction Models
  • Tentatively Committed Transactions
  • Transactions tentatively commit on a mobile unit
  • Make their results locally visible leading to
    abort dependencies
  • Certification based on application or system
    defined criteria
  • invalidated trans. are aborted, reconcile, or
    compensated
  • Isolation-Only Transactions Lu 94
  • First-class transactions for connected operations
  • immediately commit at the server, globally
    serializable
  • Second-class transactions for disconnected
    operations
  • tentatively commit, locally serializable, no
    failure atomicity
  • validation criteria global serializability,
    global certifiability
  • invalidated trans. are aborted, reexecuted, or
    compensated.

78
Two-tier transaction Models
  • Two-tier Replication Gray 95
  • Base transactions and Tentative transactions
    (disconnected)
  • Upon reconnection, tentative transactions are
    reprocessed as base transactions on master data
    version
  • Application semantics are used to increase
    concurrency and acceptance (e.g., commutative
    operations)
  • (Mobile) Escrow Transactions
  • Transactions are validated locally by localizing
    constraints
  • Local commitment ensures global commitment

79
Mobile Transactions
  • Distributed transactions involving both mobile
    and fixed hosts.
  • Traditional approaches are too restrictive.
  • Mobile Open Nested Transactions Chrysanthis 93
  • Goals sharing of partial results while in
    execution,
  • maintaining computation state on a fixed
    host,
  • moving transactions on/off a mobile host
    and across fixed hosts.
  • Components Atomic transactions, Compensatable
    transaction, Reporting transactions and
    Co-transactions.
  • Properties Component isolation, semantic
    atomicity Components may commit/abort
    independently

80
Mobile Transactions
  • Kangaroo Transactions Dunham 97
  • Transaction relocation is achieved by splitting
    the transaction during hand-off. One Joey
    transaction per cell.
  • The Clustering Model Pitoura 95
  • A distributed database is divided into weak and
    strict clusters
  • Data in a cluster are mutually consistent
  • Inconsistency between clusters is bounded and
    resolved by merging them either
  • during transaction commitments, or
  • when connectivity improves
  • A mobile transaction is decomposed into Strict
    and Weak transactions based on consistency
    requirements
  • Only strict transactions ensure durability and
    currency of reads

81
Failure Recovery
  • Emphasis has been on recording global checkpoints
  • Periodically store the state of a distributed
    application with mobile components.
  • DB Failure Recovery Logging and checkpointing
  • Failures can be soft or hard
  • Soft failure can be recovered from the locally
    stored log and checkpoint
  • Hard failure require hard checkpoints stored in
    the fixed network.
  • Issues
  • When to propagate the log and create a hard
    checkpoint?
  • Where to store hard checkpoints to speed up
    recovery and reduce its cost?

82
Database Interface
  • Desirable features
  • Semantic simplicity formulation of queries
    without special knowledge
  • Interaction with a pointing device
  • Disconnected query specification
  • QBI (Query By Icons) Massari-Chrysanthis 95
  • Iconic language requiring minimum typing
  • Semantic data model that hides details
  • Metaquery tools for query formulation during
    disconnections

83
Outline
  • Motivating Example
  • Issues Mobility, Wireless Communication,
    Portability
  • Adaptability and Mobile Client-Server Models
  • Location Management
  • Broadcast data dissemination
  • Disconnected database operations
  • Mobile Access to the Web
  • Mobility in Workflow Systems
  • State of Mobile DB Industry and Research Projects
  • Unsolved Problems

84
Mobile Access to the Web
  • Three-tier Architectures Client - Web Server -
    Data Server
  • Web Server can act like a server-side agent
  • Prefetching at its cache can hide some latency
  • Scripts at the Web server can perform
    user-specified filtering and processing.
  • Most solutions use a Web proxy to avoid any
    changes to the browsers and servers.
  • Pythia Fox96
  • Mobile Browser (MOWSER) Joshi 96
  • Distillation highly lossy, real-time,datatype
    specific compression that preserves semantic
    content
  • WebExpress Housel 97

85
WebExpress
  • Utilizes the C-I-S Model
  • Goals reduce traffic volume and reduce latency
  • Intercept any http request and perform four
    optimizations
  • Caching at both CSA SSA of graphics and html
    objects
  • Differencing only changes are communicated
  • Long-live TCP/IP Connection CSA SSA use a
    single TCP connection
  • Header reduction SSA includes the required
    browser capabilities. They are not sent by the
    CSA.
  • While disconnected (off-line mode) uses CSA cache

86
Advances in Mobile Web Servers
  • W4 for Wireless WWW bartlett 94 Mosaic on PDA
  • Dynamic Documents Tcl scripts that execute
    within the mobile browser to customize the html
    documents
  • Dynamic URLs Mobisaic 94 They support mobile
    web servers and work with active pages.
  • IPiC Shrinivasan 99 A match head sized web
    server

87
Mobility in Workflows
  • Workflows are automated business processes.
  • involve coordinated execution of multiple
    long-running tasks or activities
  • Workflow system coordinates the workflow
    execution.
  • Processing entities (clients) are where the
    activities are executed and can be mobile.
  • disconnections among procesing entities (clients)

88
Workflow Disconnected Operations
  • A pessimistic approach Exotica
  • Prior to disconnection, each client
  • reserves the activities it plans to work by
    locking
  • hoards the relative to the activities data
    (requests from the server the input containers of
    the activities)
  • During disconnection,
  • stores results in its local stable memory
  • Upon reconnection,
  • the results are reported back to the server

89
Mobile Agents in Workflows
  • A Mobile Agent Workflow Model INCAS
  • No centralized workflow server
  • Each workflow process is model as a mobile agent
    called Information Carrier (INCA). Each INCA
  • encapsulates the private data of the workflow
  • carries a set of rules that control the flow
    between the activities of the INCA computation
  • maintains the history (log) of its execution
  • Each INCA is initially submitted to a procesisng
    entity (client) and roams among processing
    entities to achieve its goal

90
Outline
  • Motivating Example
  • Issues Mobility, Wireless Communication,
    Portability
  • Adaptability and Mobile Client-Server Models
  • Location Management
  • Broadcast data dissemination
  • Disconnected database operations
  • Mobile Access to the Web
  • Mobility in Workflow Systems
  • State of Mobile DB Industry and Research Projects
  • Unsolved Problems

91
Mobility Middleware in the Market
  • Most middleware market are based on TCP/IP and
    socket-oriented connections
  • Wireless-friendly TCP versions have been proposed
    but no major products adopted it
  • Microsofts Remote Access supports cellular
    communication by integrating Shivas PPP suite
  • Shivas PPP (Point-to-Point protocol) suit
    provide a remote access client to either wired or
    mobile servers
  • E.g., mobile clients can access Tuxedo
    transaction services
  • MobileWare Office Server An agent-based
    middleware that supports Lotus Notes, Web access,
    database replication, etc.
  • Connection profiles, checkpointing,compression,
    security

92
State of Mobile DB Industry
  • Sybase SQL Remote (Sybase SQL AnyWhere)
  • MobiLink Centralized model to control
    replication
  • Application-specific bi-directional
    synchronization using scripts
  • UltraLite in-memory dbms (50KB)
  • ORACLE
  • Oracle Mobile Agents middleware
  • Oracle 8 Lite supports bi-directional
    replication between a client and a server
    (50-750KB)
  • Oracle Replication Manager supports replication
    across multiple servers based on the peer-to-peer
    model
  • MS SQLServer
  • Merge replication and conflict resolution
  • Alternative clients Outlook and MS ACCESS
  • IBM DB2 Everywhere (100KB)

93
Case Study Coda
  • Client-Server System with two classes of
    replication w.r.t. consistency
  • Disconnected vs. Weakly connected
  • Hoarding, Caching/Server callback, No Prefetching
  • During connections Allows AFS clients (Venus)
    to hoard files.
  • hierarchical, prioritized cache management ?
    equilibrium.
  • track dependencies, bookmarks
  • During disconnections Venus acts as (emulates)
    a server
  • generates (temp) fids, services request to
    hoarded files.
  • On reconnection, Venus integrates locally
    changed files to servers.
  • Considers only write-write conflicts - no notion
    of atomicity
  • User conflict resolution/ Application-aware
    adaptation Odyssey
  • Use optimistic replication technique

94
Coda Client Space Management
  • Space requirements - 10MB
  • space for hoarding applications
  • space use during Emulation (in particular
    logging)
  • space for Recoverable Virtual Memory (cache
    directory, symbolic link, status of block etc.)
  • Free disk space techniques
  • compression of file cache and RVM (space vs.
    computation time)
  • abort updates made by users (reduce log space)
  • allow file cache and RVM to be copy to flush
    cards/floppy disks.

95
Case Study Consistency in Bayou
  • A bottom-up approach to specific design problems
  • more distributed than coda, more emphasis on
    "small" clients
  • Key features
  • read-any/write-any to enhance availability
  • anti-entropy protocol for eventual consistency
  • dependency checks on each write
  • dependency set
  • If queries (run at server) do return the expected
    results
  • Application-specific resolution of update
    conflicts
  • Primary server to commit writes and set order
  • Session consistency guarantees
  • How effective is anti-entropy?

96
Anti-entropy Protocol
  • Server propagates write among copies.
  • Eventual all copies "converge" towards the same
    state.
  • Eventual reach identical state if no new updates.
  • Pair-to-peer anti-entropy
  • each server periodically selects another server
  • exchange writes and agree on the performed order
  • reach identical state after performing the same
    writes in the same order.

97
Case Study Rover
  • Rover Joseph 97 provides an environment for the
    development of mobile applications
  • Applications are split into client and server
    part communicating with Queued RPCs
  • Application code and data are encapsulated within
    Relocatable Dynamic Objects (RDOs)
  • Access Managers at client and server handle RDOs
  • Clients operational log is lazily transfer to
    the server
  • Disconnections are supported by the local cache
  • Some support for primary copy, optimistic
    consistency

98
Case Study Pro-Motion
  • Pro-Motion Chrysanthis 97 is designed for the
    development of mobile database applications.
  • It shares similar architecture as Rover with a
    multi-tier C-I-S model.
  • Compact is the unit of caching and hoarding
  • It encapsulates cached data, methods, consistency
    rules and obligations (e.g., deadlines).
  • Supports both tentatively committed transactions
  • and two-tier replication.

99
Case Study Rome
  • Rome Fox 99 goals is the timely and in context
    delivery of information
  • Information should be received when and where it
    is needed
  • Its fundamental building block are the triggers
  • pieces of data bundled with contextual
    information
  • Condition (location ? R) ? (time ? t) ? action
  • It is similar to active databases but with
    decentralized management
  • It provides an extensible framework and building
    blocks leveraging on internet service.

100
Unsolved Problems
  • Integration and evaluation of algorithms with
    applications
  • Broadcast disks
  • Information update/consistency and data temporal
    coherence - meet time constraints of requests
  • Relation between server broadcasting and client
    caching.
  • Multiple broadcast channels and multiple database
    access
  • Efficient, scalable, adaptive mechanisms
  • Location handling
  • Trigger management
  • Programmer Interface for Application-aware
    adaptation
  • Data fidelity vs. consistency
  • Semantic consistency needs metadata/requirements
  • Multimedia and QoS

101
To Recap
  • Mobile and wireless computing attempts to deliver
    todays and tomorrows applications on
    yesterdays hardware and communication
    infrastructure!

102
Summary
  • need for mutual consistency currency
  • need efficient, scalable, adaptive mechanisms
  • semantic consistency needs metadata
  • temporal consistency needs user req.
  • weak consistency with caches
  • many open issues

103

Broadcast
  • Broadcast as an air-cache for storing frequently
    requested data
  • Continoulsy adjust the broadcast content to
    match the database hot-spot
  • How? By observing the broadcast misses -
    requests for data not on the broadcast

104
Outline
  • broadcast environments
  • issues in reading consistent data --
    on time
  • semantic consistency
  • correctness criteria
  • mechanisms for disseminating (control) data
  • exploiting caches
  • temporal consistency

105
Client-Server Communication Model
  • Asymmetric communication environments
  • Server broadcasts data to clients using
    high bandwidth broadcast links
  • Clients listen to the broadcast to fetch data
  • Clients communicate with the server using
    low bandwidth upstream links
  • Update handling
  • Clients send update data to server
  • Server resolves update conflicts, commits
    updates, and broadcasts updates to clients

106
Semantic Consistency
Update x and z
TrBegin
TrEnd
time (broadcast cycles)
Are x, y, and z mutually consistent?
107
Time Constrained Broadcasts
108
Temporal Consistency
  • Meet data temporal coherence
  • improve currency of data read by clients
  • attach validity interval for each broadcast data
    object
  • Meet time constraints (deadlines) of requests

109
Outline
  • broadcast environments
  • issues in reading consistent data on time
  • semantic consistency
  • correctness criteria
  • mechanisms for disseminating (control) data
  • exploiting caches
  • temporal consistency

110
Serializability in Bcast Env.
  • Serializability a global property
  • dynamic conflict resolution gt excessive comm.
  • e.g., locking
  • acquiring read locks by client transactions
  • server swamped with lock requests
  • client uses precious uplink bandwidth
  • avoid potential conflicts
  • clients must be conservative
  • unilaterally disallow certain correct
    executions
  • unnecessary aborts

111
Serialization Orders
T2 T4
T4T1T2
T2T3T4
But, global history is not serializable
112
Serializability?
all read-only transactions 1. required to see the
same serial order of update
transactions -- even if executing at different
clients 2. required to be serializable w.r.t.
all the update transactions -- even if
updates do not affect the values read
unnecessary and inappropriate
113
Broadcast Data Requirements
  • Mutual consistency
  • -- server maintains
  • mutually consistent data
  • -- clients read mutually consistent data
  • Currency
  • -- clients see data that is current

114
A Sufficient Criterion
  • All update transactions are serializable.
  • Each read-only transaction is serializable
    with respect to the update transactions it
    (directly or indirectly) reads from.

115
Implications
If clients know update schedule
read-only transactions need not contact the
server. gt addresses the primary problems with
serializability
116
Summary
  • need for mutual consistency currency
  • need efficient, scalable, adaptive mechanisms
  • semantic consistency needs metadata
  • temporal consistency needs user req.
  • weak consistency with caches
  • many open issues

117
Field Computing
118

Assumptions for
Broadcast Disks
  • Wireless data broadcasting can be viewed as
    "storage on the air".
  • Periodic broadcast - broadcast cycles or bcycles
  • Bucket logical unit of broadcast
  • Each bucket has an address or sequence number
    within the broadcast.
  • Data changes often
  • Each successive broadcast may differ in size and
    content
  • No updates during a particular broadcast.
  • Client has no prior knowledge of the structure
    or content of the broadcast.
  • Clients are interested in fetching a particular
    record identified by a key.
  • Access time avg time elapsed between the
    beginning of the search for an item to the
    reading of it from the broadcast channel
  • Listening/Tuning time the amount of time spent
    listening to the broadcast channel

119

Access protocol
  • Index buckets hold the directory, data buckets
    hold data.
  • User tunes in to find out when a needed index
    bucket is broadcasted.
  • Synchronize by accessing a pointer that tells the
    user when to tune in for the data.
  • After you synchronize you must access the data in
    the same broadcast.
  • Tune in to the data at the right time.

120

(1,M) Indexing
  • We broadcast the index M times during one version
    of the data.
  • After broadcasting 1/M of the file we broadcast
    the index.
  • All buckets have the offset to the beginning of
    the next index segment.
  • Data access protocol for record with key Q
  • Listen to current bucket.
  • Read the offset.
  • Go to sleep till the next index segment
  • From the index determine when Q arrives.
  • (May have to follow several levels of
    indexes.)
  • Tune in again to pick up record.

121

Distributed
Indexing
  • Goal Let's cut down on the replication of index
    material
  • Solution It is sufficient to broadcast only the
    portion of the index which describes the data
    segment that follows. No replication.
  • Problem with the no replication approach.
  • User can't determine when relevant indexing is
    coming!
  • Number of probes grows linearly with number of
    levels in tree, and
  • the number of pointers in an index bucket. Very
    bad.
  • New Solution Distributed indexing. Divide the
    index into
  • replicated top l levels
  • non-replicated bottom 4-l levels
  • Result Index overhead vs. tuning time

122

Flexible Indexing
  • broadcast divided into p data segments.
  • data items are assumed sorted
  • a control index is associated with each segment
  • binary control index to determine the data
    segment
  • local index to locate the specific item within
    the segment

123

Mobility
  • bandwidth restrictions and variability
  • bursty network activity - during connections
  • handling disconnections (planned failures?)
  • caching strategies
  • managing inconsistencies
Write a Comment
User Comments (0)
About PowerShow.com