SINA: Scalable Incremental Processing of Continuous Queries in Spatio-temporal Databases Mohamed F. Mokbel, Xiaopeng Xiong, Walid G. Aref

1
SINA Scalable Incremental Processing of
Continuous Queries in Spatio-temporal
DatabasesMohamed F. Mokbel, Xiaopeng Xiong,
Walid G. Aref
Presented by Nilu Thakur Prasad Sriram
2
Introduction (1/3)

• Moving query on stationary objects

Find the nearest gas station(s) within 1 miles of
moving red car
3
Introduction (2/3)

• Another Example.
• Moving query on moving objects

Continuously find all police cars within 3 miles
of the moving red car
4
Introduction (3/3)

• Another Example.
• Stationary query on moving objects

Continuously find all vehicles within 1 miles of
my house
My House
5
Problem Definition

• Input
• Given a large number of mobile/stationary objects
  and continuous spatio-temporal queries
• Output
• Produce fast, complete and correct results
• Objective
• Continuous evaluation
• Scalability in terms of number of queries
• Report only updates to previous answer
• Constraints
• Any delay in query response might result in
  outdated answer
• Limited Network bandwidth

6
Contributions

• Shared execution paradigm
• Groups similar queries in a query table
• R-tree/FUR tree index for spatial join on moving
  objects
• Q-tree index for spatial join on moving queries
• Differ from previous approaches of using R-tree
  and Q index structure for moving query on moving
  object (Instead uses spatial join assuming no
  indexing structure)
• Incremental evaluation (Most Significant)
• Maintains an in-memory table to store positive
  and negative updates
• Negative updates may cancel previous positive
  update vice versa
• Sends a set of updates to queries every T time

7
Shared execution

• Spatial join between moving objects moving
  queries

8
An example to understand Spatial-Join
Q represents Objects P represents Queries black
circle Non-moving objects, dashed line
represents moving queries
9
State diagram of SINA
10
Step I-Hashing

• Two in-memory hash table with N buckets for
  storing moving objects
• moving queries
• One in-memory query table to keep track of upper
  left and lower right
• corners of query region
• Hashing --gt probing --gtstoring

11
Step II-Invalidation
Map objects and queries to one or more disk-based
NN grid cells Flush out the buckets containing
moved objects and queries If object maps to same
grid then the object has not moved Else Add the
object entry in this grid cell Look for queries
that contain this object. Remove these objects
from the queries by sending negative
updates. Repeat the same procedure for
invalidating queries.
Query entry
Object entry
12
Step III- Joining

• No additional data structure
• Two spatial join operations for each grid cell
• Join in-memory objects with in-disk queries
• Join in-memory moving queries with in-disk
  objects
• Send updated answers to clients
• Clear all memory data structures

13
Experimental Evidence

• Methodology
• Experiments performed on synthetic data
• Used Network-Based Generator of Moving Objects
• Input to generator is road map of city of
  Oldenburg, Germany
• Theorem-Proving
• Validation criteria
• Comparison with other non-incremental algorithms
  based on
• Size of the results
• Impact of grid size
• Scalability with number of objects
• Performance in terms of CPU and I/O time
• Advantages
• Very much appropriate to check correctness
  efficiency of proposed algorithm where rich
  datasets with various problem features are not
  available.
• Disadvantages
• Real world conditions might differ from
  experimental results

14
Rewrite today

• Assumptions
• No unreasonable assumptions made. In fact,
  removes some previous assumptions made by other
  related techniques
• Preservations
• Incremental way of sending updates
• Shared execution
• Not having assumptions about computational
  capabilities of client
• Improvements
• Incorporate some techniques to determine the
  optimal T i.e., time between sending updates
• Through experiments
• Learning based on the past statistics about how
  valid the previous updates were
• Extend to handle queries involving huge object
  histories