110 likes | 125 Views
Sensor Networks: Implications for Database Systems and Vice-Versa. UCB Sensor Day. Michael Franklin January 2004 http://www.cs.berkeley.edu/~franklin. Query-based interface to sensor networks Developed on TinyOS/Motes Benefits Ease of programming and retasking
E N D
Sensor Networks: Implications for Database SystemsandVice-Versa UCB Sensor Day Michael Franklin January 2004 http://www.cs.berkeley.edu/~franklin
Query-based interface to sensor networks • Developed on TinyOS/Motes • Benefits • Ease of programming and retasking • Extensible aggregation framework • Power-sensitive optimization and adaptivity • Sam Madden (Ph.D. Thesis) in collaboration with Wei Hong (Intel) and guidance (?) from Franklin and Hellerstein. http://telegraph.cs.berkeley.edu/tinydb
These are the traditional arguments Here’s why the techniques carry over Why Database Queries? • Declarative, Set-based approach. • Programmer productivity. • Robustness to change. • Let the system manage efficiency. • Semantics and High-level operators. • Framework for correctness criteria. • Pushing semantics down enables smarter implementations, code re-use. • Natural mapping of dataflow processing. • Query plans are networks of operators. • Query/Data duality enables intelligent routing.
Declarative Queries in Sensor Nets • Many sensor network applications can be described using query language primitives. • Potential for tremendous reductions in development and debugging effort. SELECT nestNo, light FROM sensors WHERE light > 400 EPOCH DURATION 1s “Report the light intensities of the bright nests.” Sensors
Regions w/ AVG(sound) > 200 Aggregation Query Example “Count the number occupied nests in each loud region of the island.” • SELECT region, CNT(occupied) AVG(sound) • FROM sensors • GROUP BY region • HAVING AVG(sound) > 200 • EPOCH DURATION 10s
In Network Aggregation: Example Benefits 2500 Nodes 50x50 Grid Depth = ~10 Neighbors = ~20
Telegraph: Monitoring Data Streams • Streaming Data • Network monitors • Sensor Networks • News feeds • Stock tickers • B2B and Enterprise apps • Supply-Chain, CRM, RFID • Trade Reconciliation, Order Processing etc. • (Quasi) real-time flow of events and data • Must manage these flows to drive business (and other) processes. • Can mine flows to create and adjust business rules. • Can also “tap into” flows for on-line analysis. http://telegraph.cs.berkeley.edu
seconds Time Scale years One View of the Design Space Archiving (provenance and schema evolution) Filtering,Cleaning,Alerts Monitoring, Time-series Data mining (recent history) Combined Stream/Disk Processing On-the-fly processing Disk-based processing
local Geographic Scope global Another View of the Design Space Archiving (provenance and schema evolution) Filtering,Cleaning,Alerts Monitoring, Time-series Data mining (recent history) Central Office Regional Centers Several Readers
Degree of Detail Aggregate Data Volume One More View of the Design Space Archiving (provenance and schema evolution) Filtering,Cleaning,Alerts Monitoring, Time-series Data mining (recent history) Dup Elim history: hrs Interesting Events history: days Trends/Archive history: years
“HiFi Systems” • High Fan-In, globally-distributed architecture • Think RFID-enabled supply chain/logistics • Telegraph-like nodes internal to the network • TinyDB-like sensor networks at the edges • Large data volumes generated at edges • Successive aggregation as you move into the center • Strong spatio-temporal focus • Would love to talk with people who have applications that might need this kind of infrastructure.