200 likes | 267 Views
Explore approaches, queries, and systems for querying the physical world, from warehousing to distributed methods. Learn how devices with advanced capabilities are reshaping query processing. Dive into execution plans and considerations for efficient querying in modern environments.
E N D
Querying the Physical World Son, In Keun Lim, Yong Hun
Outline • Introduction • Kinds of Queries • Warehousing vs. Distributed approach • Device Database System • Query Execution Plans • Conclusion
Future Computing Environments • The widespread deployments of devices • sensors, actuators, and mobile devices • with power, memory, and communication capabilities • devices are interconnected and accessible from local and wide area networks • What is a device? • physical object with computing and communication capabilities
Kinds of Queries • Historical Queries • typically aggregate queries over historical data • “For each rainfall sensor, display the average level of rainfall for 1999” • Snapshot queries • concerns the device network at a given point in time • “Retrieve the current rainfall level for all sensors in Tompkins County” • Long-running queries • concern the device network over a time interval • “For the next five hors, retrieve every 30 seconds the rainfall level for all sensors in Tompkins County”
Warehousing approach • Traditional query processing • A warehousing approach – data are extracted in a predefined way and store in a centralized DB system DBMS Query Query requesters Result NETWORK Raw data Raw data Raw data • ATM Machine • Airplane/Ship/Train • Etc
Warehousing approach(cont’d) • Dissociates access to devices from the query workload • Transfer large amounts of raw data from devices to the database server • Wastes valuable resources(network resources, processing power) • Modern devices include processing capabilities that could be used to process data locally
Distributed Approach • New way for query processing • Small-scale mobile devices will have self-computing power, memory, and communication capabilities Query processor Meta- Information Query Query requesters Result NETWORK Sub query Sub result • ATM Machine • Airplane/Ship/Train • Etc
Distributed Approach(cont’d) • The query determines the data that are extracted from remote sites • The query determines where possibly portions of queries are executed on devices • Device Database System • access devices directly when processing queries
Device Database System • What is a device? • A mini-server supporting functions • Functions like acquiring data • Functions like actuating (Triggers) • Device types • Synchronous devices returns results immediately • Asynchronous devices may move, may be unconnected, therefore returns results after an arbitrary period of time
Representation of Functions • User Representation : ADT • modeling each type of device in the network as an ADT • the public interface of the ADT corresponds to the specific functions supported by the device • Internal Representation : Virtual Relation • tabular relation of a function
Virtual Relation • Attributes • Inputs to the function • Arguments to the function • Output of the function • Timestamp of the function • Properties • records are never updated or deleted • is naturally partitioned over the network=> a distributed DB
Query Execution Plan • Performance metrics • Throughput and response time • Resource usage and reaction time • Notation • Joins are between R and VRs • Rs are centrally located tables (like a list of sensors) • VRs are distributed (like a VR representing a device function)
Traditional Query Execution Plan • Materialize VR • Do Join at Front End • Centralized • Bottleneck, not scalable
Query Execution Plan A • Virtual records are produced once on each site for a snapshot query • Virtual records are produced repetitively for a long-running query • Whenever you get a new records, do a join
Query Execution Plan B • Semi-join : send joining attribute to devices • Use processing power of devices more • let them do the join • Send back only valid records • Reduced network traffic
Query Execution Plan C • Just send the condition • Again do the join at the center
Experiments 1 • Nodes outside the target region • Plan C predictably shows no consumption (the transfer of the condition is negligible) • Plan B amortizes • Plan A accumulates
Experiment 2 • Nodes inside the target region • Plan C shows growth, similar to Plan A • Plan B grows much more • The difference is the cost of performing a selection – low compared to cost of sending data.
Conclusions • Flexible • Scalable • Optimizer assume global knowledge • Query plans must adapt dynamically and be robustness
Future Expectations • A lot of self-computing devices which have their own memory, communication capability will exist in the future world (already?) • Refrigerator, Television, Vending Machine… • Hot issues are going to be • How to maintain device meta-information with a decentralized approach (P2P?) • Which information should be stored carefully at the data warehouse and which device should be accessed • Information retrieval will be more important • How to make query execution plans