two questions that come to mind the design of an
play

Two Questions that come to mind The Design of an Acquisitional Query - PDF document

Two Questions that come to mind The Design of an Acquisitional Query One of the major purposes of Sensor Networks? Processor For Sensor Networks Monitoring (data collection using sensors) What is the biggest limitation of sensor networks? By:


  1. Two Questions that come to mind The Design of an Acquisitional Query One of the major purposes of Sensor Networks? Processor For Sensor Networks Monitoring (data collection using sensors) What is the biggest limitation of sensor networks? By: Samuel Madden, Michael J. Franklin, Power Joseph M. Hellerstein and Wei Hong Presented by: Ibrahim Noorzaie 1 2 Outline Main Ideas Acquisitional Issues Main ideas When and how often data is physically acquired and delivered to query Introduction processing operators Sensor Networks Overview Regular SQL used to optimize data acquisition techniques Influence query optimization, dissemination and execution Acquisitional Query Language TinyDB - a special purpose distributed query processor designed Power-Aware Optimization for sensor networks Power Sensitive Dissemination and Routing Techniques to reduce power consumption Processing Queries Topics from supplemental paper Summary and Conclusion 3 4 Introduction Basic Architecture Queries are submitted at the base-station One of main difference between WSN and other Ad-hoc networks is minimum Parsing, optimization at the base-station human interaction Interaction: configuration of network routes, recharging or tuning parameters Energy efficiency to support long term operation Availability of data not assumed at the time of request Request for data (queries) are not blocking and can run for days and months TinyDB an aquisitional query processor Supports select, join, project and data aggregation with power consumption in mind Some questions about data acquisition answered When should data be sampled? Which sensor nodes are relevant to a data request (query)? What order of sampling data? Is it worth processing a particular sample? 5 6 1

  2. Outline Sensor Network Overview Main ideas An early application of WSN was natural habitat monitoring Some restrictions/requirements: Introduction No maintenance for up to a year Sensor Networks Overview Monitor sea birds Acquisitional Query Language Monitor burrows (coming/going, temperature, light etc.) Power consumption is a serious issue Power-Aware Optimization Data collection intervals (cycles) Power Sensitive Dissemination and Routing Processing Queries Topics from supplemental paper Summary and Conclusion 7 8 Properties of Sensor Devices Communication in Sensor Networks Power is main issue Frequent enough data collection cycles for correct representation Typical radio range for low power radio is between a few to 100 ft. Longer sleep times for longer operation of the system Radio range depends on transmission in environmental conditions TinyDB best suited for data collection and power consumption Multi-hop networking is useful in such situation schemes Communication in Mica motes Power consumption in Motes withTinyDB Broadcast : any node in the network can hear anything Power consumption in four phases (sleeping, processing, Snooping processing/listening, transmitting) Acknowledgments only from neighboring nodes Per-message, link-level (hop count) acknowledgements from neighbors No end to end communication The processor and radio are idle 9 10 Communication in Sensor Networks Outline Queries in Sensor networks Main ideas Queries disseminated using routing tree Introduction Several trees could be made due to multiple parents. This could help support multiple queries Sensor Networks Overview Acquisitional Query Language Query SELECT light Power-Aware Optimization WHERE x>3 AND x<7 Power Sensitive Dissemination and Routing Processing Queries Topics from supplemental paper Summary and Conclusion 11 12 2

  3. Acquisitional Query Language Acquisitional Query Language Focus is on when and how often samples are acquired The sensors table is a virtual unbounded table ACQL is a subset of standard SQL with support for WSN functions All data is streamed back to the root in online fashion (stream) Queries are distributed and data collection can last for specified amount of time A single table manages all the sensors in the network Certain operations such as sort, symmetric join etc. are not possible Data is sampled from sensors at certain intervals which are spaced an epoch apart Storage Point (Window): data can be buffered in a node for use Tuple is a unique row in the data table by other queries Comparing three types of queries: Standard SQL Query: Makes it possible to do sort, joins etc. Uses interpolation when intervals are different SELECT nodeid,light,temp FROM sensors; SELECT count(*) CREATE TinyDB Query: FROM sensors AS s, recentlight As r1 English Query: STORAGE POINT recentlight SIZE 8 WHERE r1.nodeid = s.nodeid AS (SELECT nodeid, light FROM sensors Return nodeid, light and AND s.light < r1.light SELECT nodeid,light,temp SAMPLE INTERVAL 10s) temperature data from FROM sensors SAMPLE INTERVAL 10s sensors. SAMPLE INTERVAL 1s FOR 10s 13 14 Acquisitional Query Language Event-Based Queries TinyDB can use aggregate functions to reduce the amount of TinyOS uses events to conserve power traffic in the network Events are triggered either by another query or the OS Following type of query also know as sliding window query TinyDB uses the same model in data collection Will report average volume over last 30s once every 5s, sampling once Events trigger data collection cycles per second. Events can also serve as stopping conditions for queries Event-based query: SELECT WINAVG(volume, 30s, 5s) FROM sensors ON EVENT bird-detect (loc): SAMPLE INTERVAL 1s SELECT AVG (light), AVG (temp), event.loc FROM sensors AS s WHERE dist (s.loc, event.loc) < 10m Queries assigned ids can be stopped anytime using “STOP SAMPLE INTERVAL 2s for 30s QUERY id” command or a specific time limit can be set Events are local (not-distributed) currently 15 16 Event-Based Queries Lifetime-Based Queries Researchers are not concerned with low level details of power management etc. Lifetime-Based query SELECT nodeid, accel FROM sensors LIFETIME 30 days TinyDB figures out best sampling rate by considering: Joules of energy remaining Cost of transmitting sensor data Cost of accessing sensor data Etc. 17 18 3

  4. Lifetime-Based Queries Lifetime-Based Queries In the previous calculation the user has no control over sampling Estimation rate The user can set a minimum sample rate to keep data meaningful. Energy to collect and transmit one sample (including children) MIN SAMPLE RATE r data Available power per hour If estimated rate lower than r, then r used 19 20 Outline Power-Aware Optimization Main ideas Introduction We discuss (power) optimization, query dissemination and execution Sensor Networks Overview Queries are parsed (into binary) and optimized at the base-station before dissemination Acquisitional Query Language Optimizer needs information (metadata) about nodes Power-Aware Optimization Metadata could include local attributes, events and user-define functions Power Sensitive Dissemination and Routing Processing Queries Topics from supplemental paper Summary and Conclusion 21 22 Metadata Management Ordering of Sampling and Predicates Nodes in TinyDB keep a catalog of local information called We discuss how meta data is used in query optimization metadata Power consumption depends on sensor types Metadata used in query optimization, query dissemination and result processing Metadata also used to keep information on TinyDB’s aggregate functions Monotonic and Exemplary or Summary COUNT is monotonic, MIN is Exemplary, AVERAGE is SUMMARY Metadata of a single attribute Short circuiting could be very useful for conserving power SELECT accel, mag FROM sensors WHERE accel > c1 AND mag > c2 SAMPLE INTERVAL 1s 23 24 4

Recommend


More recommend