1. Sensor Networks: Implications for Database Systems and Vice-Versa Michael Franklin January 2004 http://www.cs.berkeley.edu/~franklin UCB Sensor Day

2. 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

3. 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. These are the traditionalarguments Here’s why the techniques carry over

4. Declarative Queries in Sensor Nets SELECT nestNo, light FROM sensors WHERE light > 400 EPOCH DURATION 1s EpochnestNoLightTempAccelSound 01455xxx 02389xxx 11422xxx 12405xxx Sensors “Report the light intensities of the bright nests.”EpochnestNoLightTempAccelSound 01455xxx 02389xxx Many sensor network applications can be described using query language primitives. Many sensor network applications can be described using query language primitives. – Potential for tremendous reductions in development and debugging effort.

5. Aggregation Query Example EpochregionCNT(…)AVG(…) 0North3360 0South3520 1North3370 1South3520 “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 Regions w/ AVG(sound) > 200

6. In Network Aggregation: Example Benefits 2500 Nodes 50x50 Grid Depth = ~10 Neighbors = ~20

7. 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

8. One View of the Design Space Filtering, Cleaning, Alerts Monitoring, Time-series Data mining (recent history) Archiving (provenance and schema evolution) On-the-fly processing Disk-based processing Combined Stream/Disk Processing Time Scale seconds years

9. Another View of the Design Space Filtering, Cleaning, Alerts Monitoring, Time-series Data mining (recent history) Archiving (provenance and schema evolution) Several Readers Central Office Regional Centers Geographic Scope local global

10. One More View of the Design Space Filtering, Cleaning, Alerts Monitoring, Time-series Data mining (recent history) Archiving (provenance and schema evolution) Degree of Detail Aggregate Data Volume Dup Elim history: hrs Interesting Events history: days Trends/Archive history: years

11. “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.