No sql query processing system for wireless ad hoc and sensor networks


Published on

J Gabriel Lima -

Published in: Technology
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

No sql query processing system for wireless ad hoc and sensor networks

  1. 1. The International Conference on Advances in ICT for Emerging Regions - ICTer2011 : 078-082 NoSQL Query Processing System for Wireless Ad-hoc and Sensor Networks T.A.M.C. Thantriwatte 1, and c.l. Keppetiyagama 2 University a/Colombo School a/Computing, No 35, Reid Avenue, Colombo 7, Sri Lanka 1, 2 chamath@ucsc. cmb . ac .lkAbstract- TinyDB and TikiriDB are query processing systems, The main objective of this research is to transform currentwhich have been used successfully in wireless sensor networks relational database model in WASN to NoSQL [6] database(WSN). These query processing systems provide a SQL query model. NoSQL mainly focuses on performance and scalability.interface to extract data from sensors and it has proven to be a NoSQL does not guarantee ACID properties and it does notconvenient programming interface in these environments. require a fixed table structure. We implemented NoSQL queryHowever, a relational database model that guarantees ACIDproperties is not a good match for a wireless sensor network processing system on Contiki operating system [7] and it wassince consistent connectivity or the uninterrupted operation of built on the code base of the existing TikiriDB [3] querythe sensor nodes cannot be expected. We noted that the NoSQL processing system.approach which does not rely on the ACID properties is a better The remainder of this paper is structured as follows. Inmatch for a query processing systems for WASNs. We developed Section II we reviewed the related work in current databasea NoSQL based query processing system on the Contiki abstractions and NoSQL. Section III presents the design ofoperating system that is popular among the WSN community. nosql query processing system and in Section IV we discussKeywords- Wireless ad-hoc and sensor networks, RDBMS, the implementation of it. Our experiments and the results areSQL, NoSQL, Database abstractions, Mesh routing, ACID presented in Section V. Our conclusion in Section VI and finally we conclude the paper with future work in Section VII. I. INTRODUCTION Wireless sensor networks (WSN) are distributed systems II. RELATED WORKtypically composed of embedded devices, each equipped with Existing WSN database abstractions use the SQL querya processing unit, a wireless communication interface, as well interface and relational database management systemas sensors and/or actuators. Many applications have been techniques. Currently there are several database abstractionsimplemented on sensor networks that show the versatility of available for WSN. TinyDB [2], TikiriDB [3] and Cougar [4]this technology, and some are already finding their way into are some of those database abstractions.the mainstream. Often, in these scenarios tiny battery powered A. TinyDBdevices are used for ease of deployment and increased TinyDB is the declarative database abstraction for TinyOSflexibility. This enables embedding, processing and [8] operating system. TinyDB provides a simple SQL querycommunication within the physical world, providing low-cost, interface. TinyDB architecture provides the sensor networkfine-grained interaction with the environment. user with a database file called sensor which stores the Two main abstractions are available for developing sensor data values collected from the sensor network. TinyDBapplications for WSNs; message passing interfaces and SQL uses a resource aware algorithm to collect data [1].query interfaces. First exposes the network to the TinyDB has a distributed query processor running on eachprogrammers and the second hides the complexity of the and every node in the sensor network. Users can submit theirnetwork with a database abstraction. There are two popular queries from the base station. Then the queries are optimizedquery processing systems for wireless sensor network, namely in the base station, because TinyDB uses power aware routing.TinyDB (for TinyOS) [2] and TikiriDB (for Contiki) [3]. After that the optimized query sent through the network usingThese query processing systems represent the sensors on the the power aware routing tree.sensor network as a table. Users can insert queries at the basestation, and it converts those queries into sensor node Acquisitional Query Processing (ACQP) is adopted forunderstandable format, and this query is sent to nodes to get TinyDB along with the traditional query features provided bythe results. SQL [1]. It determines where and what order of data should be collected to minimize the power usage of the network. At the Database abstractions currently used in WSN are based on same time TinyDB also increases the data accuracy.Relational Database Management Systems (RDBMS). Theserelational models use ACID properties (atomicity, consistency, In TinyDB user can specify the sample period of a query asisolation, durability). TinyDB and TikiriDB use SQL queries. a query parameter. Many queries like event-based, groupedHowever ACID properties cannot be guaranteed in a sensor aggregation and actuation queries provide useful services tonetwork. In a sensor network we cannot rely on consistent sensor network applications. TinyDB also supports dataconnectivity and sometimes sensor nodes may fail due to low logging and network health monitoring through spatial or some environmental constrains. Because of that, Queries can be prioritized in can get lost in the operational mode of the sensor network.Furthermore, some SQL operations such as join queries,aggregate queries are useless in this scenario.978-1-4577-1114-51111$26.00 ©2011 IEEE
  2. 2. NoSQL Query Processing System for Wireless Ad-hoc and Sensor Networks 79 Here we show the example of TinyDB query; Relational Database Management Systems (RDBMS). Considering on RDBMS, those databases are design for SELECT COUNT ( * ) FROM sensors AS s, recentLight AS guarantee ACID properties. But NoSQL databases did notrl WHERE rl.nodeid=s.nodeid AND s.light < rUight guarantee ACID properties. They basically design for theSAMPLE PERIOD lOs; [2] performances and scalability. Normally NoSQL databases areB. TikiriDB suitable for large set of data. TikiriDB [3] is another well known database abstraction for Working with large set of data using a table based databaseWASNs. TikiriDB is the database abstraction layer for Contiki systems, it needs lot of resources to store such massive dataoperating system. Comparing TikiriDB with TinyDB, and the operations are time consuming. With regards toTikiriDB support shared WASNs. NoSQL databases handle massive amount of data is much TikiriDB also provide a SQL query interface called easier, and the performances are very fast when comparingTikiriSQL to query the sensor network [3]. It is much more RDBMS. The only limitation of NoSQL is the memory andsimilar to conventional query language apart from additional the processing speed. NoSQL database systems uses key,syntax to comply with sensor network environment. SELECT value pair to store data so, if you want to keep your data in atemp, humid FROM sensors SAMPLE PERIOD 2 FOR 10; [3] persistent state and have access to them, then this would be anThis query returns node id, humidity level, and temperature ideal database system.level in every 2 second intervals for duration of 10 seconds Currently there are several NoSQL database managementfrom all the available sensors nodes in the sensor network. systems available. Facebooks Cassandra, LinkedIns ProjectThe results appended to the table as they are arriving to the Voldemort, Googles BigTable and Amazons Dynamo areuser. Thus the resulting table dynamically expands according some of them. Chordless, CouchDB, Db4o, GT.M, Hbase,to time. Hypertable, Memcachedb, Mnesia, MongoDB and Redis are some popular open source NoSQL projects as well. I) Client with TikiriSQL Library: The client sidefunctionalities of the TikiriDB is included in the TikiriSQL III. DESIGN OF NoSQL DATABASE ABSTRACTIONlibrary and used by a user program. It provides functions to In this section we discuss the design of NoSQL databaseissue SQL queries by the user program, parses the queries and abstraction for WSN from a higher level architecture tosends them to the Serial Forwarder (SF). TikiriSQL library detailed design.returns data to the user program which is received from the SF.Its main tasks are, 1) Accept queries from the user program, 2) A. Architecture of NoSQL Database AbstractionParse the query and put it to a manageable format, 3) If there Figure 1 illustrates the overall design architecture of thisare any syntactic and semantic errors, it returns warnings to research including all the main components, which discussedthe user. in detail in the sub sections 1) to 5). The possible semantic errors are SELECT queries with As displayed in Figure 1, NoSQL database abstractionundefined field names, EVENT queries with undefined event consists of eight main components which are directlynames. All the available field names and event names are kept contributing to the database abstraction. These eight mainin an XML configuration file. 1) If no errors, send this new components are; front end NoSQL query, Lexical analyzerformatted query to the serial forwarder, 2) Returns the query and parser, Query processor, Data packet, Serial forwarder10 returned from the SF to the user program, 3) This query ID plug-in, Mesh routing protocol, Executing query In sensorcan be used to issue a STOP query to stop an executing queryidentified by the query ID 4) Put the data received from the SFto data structures and make it available to the user formanipulation.C. Cougar @ Cougar is another well known approach to in-networkquery processing in sensor networks. It supports a platform fortesting query processing techniques over ad-hoc sensornetworks. Cougar mainly has three-tier architecture. It consists ..,of, • A query proxy • Front-end components • A graphical user interface Fig. I: Higher level design architecture Cougar is designed for in-network query processing. In­network processing reduces energy consumption and increase motes and finally the Redis NoSQL database.lifetime of sensor network significantly compared to 1) NoSQL Query: NoSQL queries play a major role intraditional centralized data extraction and analysis. Thus one this database abstraction. This is a novel approach for sensorof the main roles of the query proxy when processing user network database abstractions, because existing databasequeries is to perform in-network processing [4]. abstractions consists of traditional SQL queries for querying sensor networks. We designed NoSQL query syntaxes forD. NoSQL querying sensor networks. Most of these queries are similar to NoSQL means Not Only SQL. The concept of NoSQL RedisDB NoSQL queries, because we adopt RedisDBstarts from 1998. NoSQL databases are differing from architecture for our abstraction. Designed NoSQL queries are,1sl & 2nd September 2011 The International Conference on Advances in rCT for Emerging Regions - ICTer2011
  3. 3. 80 T.A.M.C. Thantriwatte, and c.1. Keppetiyagama • Select Query: Appropriate keyword followed by Redis key space is divided to 4096 hash slots. In order to relevant key achieve that, different nodes hold a subset of hash slots. All • Join Query: Appropriate keyword followed by relevant the nodes are connected to each other and the functionalities key followed by valid set condition for key of each and every node is equivalent. • Range Query: Appropriate keyword followed by IV. IMPLEMENTATION relevant key followed by valid range condition This section discusses the implementation of the NoSQL • Ranking Data: Appropriate keyword followed by key database abstraction for wireless ad-hoc and sensor networks and relevant member name in more detail. The focus is on how the NoSQL queries are • Get the key of members: Appropriate keyword followed executed in actual sensor motes and results are sent back to by relevant key the base station. Following sub sections A, B, C and 0 will NoSQL query interface is linked with a lexer. The lexer describe the implementation procedure of our NoSQLsyntactically analyses the NoSQL query according to the rules database abstraction for Contiki operating system.defined. Following sub section 2) introduces the A. NoSQL Grammar Implementationfunctionalities of the NoSQL lexer and the parser. We have used ANTLR tool to define our NoSQL grammar 2) Lexical Analyser and Parser: Input NoSQL query definitions. Fist we defined the NoSQL grammars for ourpass to lexical analyser, and it read the query characters from sensor network and then the ANTLR tool generates thethe input stream which is tokenized. These token identified appropriate lexical analyser and parser for it. Using ANTLRusing the predefined NoSQL lexer rules in the grammar file we can test and generate the parse tree of our NoSQL querieswhich are implemented using regular expressions. easily. Implemented NoSQL queries are; The main functionality of lexer is, generating a stream of • GET temp SET temp 2 FOR 100;tokens according to the NoSQL query and passing it to a • GET humid SET temp 2 FOR 100;parser for syntax analysis. It also ignores the whitespaces and • ZRANK temp 2.0;comments. • GET humid SET humid < 45; Parsing is the second stage of NoSQL grammar validationaccording to the predefined NoSQL grammar rules. Parser • ZRANK light 5.0;checks the syntax and semantics of the NoSQL query and 8. Data Packet Implementationgenerate the parse tree. If parser can find syntactic or semantic We had implemented the data packet according to theerrors in the query it produces an error message. Finally the parsed NoSQL query from the lexical analyzer and parser.parser produces a C code file according to the NoSQL query The size of the data packet is 128 bits and it is divided intoand which is passed to the query processor. following categories. 3) Query Processor: The query processor processes theC file generated by the parser and distinguishes the parts ofthe query such as query type, relevant keys and other queryconditions. According to these query parts it generates queryid, query message header and query pay load. After that theprocessed query is considered as a data packet, which is ready I , f -.L 1 -r ( 8 bits 8 bits 8 bits 8 bits 16 bits 32 bitsto be routed and executed in sensor motes. Fig. 2: Structure of data packet 4) Mesh Routing: In wireless mesh network concept,communication is done by using the ad-hoc mode, also calledas peer-to-peer. Nodes in a mesh network should be able to • No of fields: It mentions what are the fields we want todiscover each and every node and broadcast messages to all its sense from the sensor mote. According to the queryneighbors. relevant fields are set to the data packet. In mesh networks we used hybrid routing protocol to pass • No of expressions: This indicates the number ofour queries from the base station to destinations. Hybrid expressions that are appeared in the SET clause.protocols consist of both proactive and reactive routing • For example GET temp SET temp> 10 2 FOR 10; Inprotocols. Initially routing starts in proactive mode and then this query "temp> 10" will goes to No of expressionmove to reactive flooding in the network. In this research we section of the data packet.used the inbuilt mesh routing protocol which is in Rime stack • Input buffer 10: This defines the data source for thein Contiki [7] operating system for our network routing query. If this is zero, direct data from sensors is usedpurpose. for the query. None zero positive integer represents the 5) Redis Architecture: RedisDB is an open source, input buffer identification number. Usually, inputadvanced key-value storage [5]. It is often referred to as a data buffer is storage medium such as SO card.structure server since keys can contain Strings, Hashes, List, • Output buffer 10: This defines the location where theSets and Sorted-sets. Redis protocol consists of a network results of a query are stored. If this is zero, results arelayer where clients connect to port 6379. In Redis server there sent to the node who issued the query. None zeroare different kinds of replies according to client requests. They positive integer represents the out buffer identificationare error reply, integer reply, bulk replies, multi-bulk replies number. Usually, output buffer is storage medium suchand nil elements in multi-bulk replies. as SO card.The International Conference on Advances in ICT for Emerging Regions - ICTer20 l1 1sl & 2nd September 2011
  4. 4. NoSQL Query Processing System for Wireless Ad-hoc and Sensor Networks 81 • Epoch duration: This is used to define the time duration • ZINTERSTORE destination numkeys key [key ...]: between two executions of the query. The value of Intersect multiple Sorted-sets and store the resulting this should be greater than zero. The duration is Sorted-set in a new key. specified in seconds. Epoch duration is set in the SET clause of the query. V. RESULTS • Number of epochs: This defines the number of query In this section, we evaluate the implementation of NoSQL executions. Zero causes to execute the query infinite query processing system for wireless ad-hoc networks on the number of times. top of Contiki operating system. • Fields: Field consists with 16 bits. It consists of a A. Evaluation platform unique id, result flag and operator. 3 bits are not used in We used two platforms to test and evaluate our system. One field section. is COOJA [9] simulation platform while other is a hardware • Expressions: Expression consists with 32 bits. Every platform. We often used COOJA simulation platform to field had relevant expression. It consists with data develop and test our system, because testing with real sensor which mapped to field id and operator. motes is little bit tricky part in sensor networks and most of the system are platform independent. After successful testingC. Implementation of Serial Forwarder with COOJA simulation platform, we test our system with real We did not implement the serial forwarder. Existing sensor motes as well.TikiriDB [3] 0.2 release there was a serial forwarder which we B. Performance Analysiscan directly plug into our NoSQL database abstraction. So weused that serial forwarder plug-in to sent data packet to the In performance analysis we analyzed the query execution time of TikiriDB [3] database abstraction and our newlynetwork. designed NoSQL database abstraction. We used following Once data packets arrive at the serial forwarder it assigns a queries to evaluate the execution time of both databaseunique query ID to each and every data packet. It also stores abstractions. For TikiriDB database abstraction,the query ID and the client ID mapping in a table which islocated in its memory. After that it sends the query to the • SELECT temp FROM sensors SAMPLE PERIOD 2network with the query ID and ID for the serial forwarder. FOR 10;When data arrives from the sensor network, serial forwarder • SELECT humid FROM sensors SAMPLE PERIOD 2searches the relevant client 10 from its table and sends the FOR 10;relevant data to the base stations. All the implementations ofserial forwarder are done by using C++ language and the For NoSQL database abstraction,serial forwarder COOJA [9] plug-in which was written by • GET temp SET temp 2 FOR 10;using Java language. • GET humid SET humid 2 FOR 10; Routing is another important part in sensor networks. Herewe used inbuilt mesh routing protocol which is in Rime stack We get the execution time of queries by changing thein Contiki [7] operating system for routing. sample period of both SQL and NoSQL queries. Following figure shows the query execution time of TikiriDB database abstraction and NoSQL database abstraction with respect toD. Implementation of RedisDB Plug-in sample periods. The X and Y axis represent sample period We have done the implementation of Redis backend in variation in seconds and response time in millisecondsiterative manner. RedisDB supports different data structures respectively.such as Strings, Hashes, Lists, Sets and Sorted-sets. First wehave implemented our backend data structure using Strings 350000and evaluate the performances of our NoSQL database 300000 250000abstractions. After that we done the implementation using 200000other data structures as well and evaluates them. These 150000 • NoSQLevaluations are mentioned under section v-co According to 100000 .SQLthose evaluations, finally we implemented with Sorted-sets. 50000 o Sorted-set implementation of our NoSQL databaseabstraction basically works with two values called key and 2FOR 2FOR 2FOR 2FOR 2FOR 10 100 1000 10000 100000member. In this implementation we mapped sensing field of aquery as key and sensing values as members. According to Fig. 3: NoSQL against SQL query execution timethese key and member values we can use following NoSQLqueries in our database abstraction. According to the Figure 3, it was observed that for a shorter time periods, both database abstractions show the same • ZADD key score member: Add a member to a Sorted­ performances, but when the time period increases, set, or update its score if it already exists. performances of NoSQL database abstraction get better. That • ZCARD key: Get the number of members in a Sorted­ means execution time of NoSQL query in sensor networks get set. lesser time than execution time of SQL query in sensor • ZCOUNT key min max: Count the members in a networks. Reason for that performance bottleneck in SQL Sorted-set with scores within the given values. database abstraction is, processing time of SQL query. • ZlNCRBY key increment member: Increment the score According to above results we can conclude processing of a member in a Sorted-set. NoSQL queries are much more efficient than processing SQL1sl & 2nd September 20 I I The International Conference on Advances in ICT for Emerging Regions - ICTer20 11
  5. 5. 82 TAM.C. Thantriwatte, and C.I. Keppetiyagamaqueries in sensor networks. This cause saves energy in sensor backend data structure is the suitable approach for NoSQLmotes. database abstraction for wireless ad-hoc networks.C. Runtime Analysis VI. CONCLUSION In section IV-D mentioned that we used different data In this paper we have first reviewed the existing databasestructures as backend of our NoSQL database abstraction. We abstractions in WSN. Then we discussed about the issuestested the backend data structures against the time related to existing database abstractions in wireless ad-hoccomplexities of NoSQL queries. We obtained following networks. Then we discussed the importance of using NoSQLresults. as the underlying database abstraction for ad-hoc networks. • SET query analysis According to the experimental results we conclude that NoSQL queries perform better when using longer sample periods. This shows higher scalability for the networks. TABLE I Secondly we evaluated the query performance with regard to the time complexity of different data structures, and it showed that using Sorted-sets we can achieve best results. O(log(N» VII. FUTURE WORK • GET query analysis This research has evolved from relational database model to NoSQL database model. Therefore query optimization is not good as the relational model. Query optimization related to TABLE II this research is to be done in near future. In addition optimized routing protocols, security layers can also be incorporated to this model. O(log(N» ACKNOWLEDGMENTS From the above tables it can be observed that Sorted-sets The authors would like to express their sincere thanks to theshow the best time complexity. After analysing Sorted-set people in SCORE lab of University of Colombo School offurthermore for different NoSQL query operations, we got the Computing. We would also like to thank the support given byfollowing results. Primal Wijesekara from University of British Columbia, K.C Hewage from UCSC, Nayanagith M. Laxman from UCSC and A.P. Sayakkara from UCSC. TABLE III SORTED-- SET ANALYSIS [10] REFERENCES Query Time Complexity [1] C.Weyer, V.Turau, ALagemann, and J.Nolte, "Programming wireless sensor network s in a self-stabilizing style," Sensor technologies and ZADD o (log(N» Applications, International Coriference on, vol. 0, pp. 610-616, 2009. [2] S.R.Madden, M.J.Franklin, J.M.Helerstein, and W.Hong, "TinyDB: an ZCARD 0(1) acquisitional query processing system for sensor networks," ACM ZCOUNT o (log(N)+M) Transactions on Database Systems, vol. 30, no. 1, pp. 122-173, Mar.2005. [Online]. Available: ZlNCRBY o (log(N» http://portal.acm.orglcitation.cfm?doid=1061318.1061322 [3] N.M.Laxaman, M.D.J.S.GoonathiIIake, and K.D. Zoysa, "TikiriDB: ZlNTERSTORE o (N*K)+O (M*log(M» Shared Wireless Sensor Network Database for Multi-User Data ZRANGE o (log(N)+M) Access," CSSL 2010. [4] Y.Yao, "The cougar approach to in-network query processing in sensor ZRANGEBYSCORE o (log(N)+M) networks," ACM SIGMOD Record, vol. 31, no. 3, p.9, Sep. 2002. ZRANK o (log(N» [5] M.Seeger, "Key-Value stores: a practical overview," Media, pp. 1-21, 2009. ZREM o (log(N» [6] G. Decandia, D. Hastorun, M. Jampani,G. Kakulapati, A Lakshman, A ZREMRANGEBYRAK o (log(N)+M) Pilchin,S. Sivasubramanian, P. Vosshal, and W. Vogels, "Dynamo : Amazon Highly Available Key-value Store," October, pp. 205-220, ZREMRANGEBYSCORE o (log(N)+M) 2007. [7] A Dunkels, B. Gronval, and T. Voigt, "Contiki - a lightweight and ZREVRANGE o (log(N)+M) flexible operating system for tiny networked sensors," 29th Annual ZREVRANGEBYSCORE o (log(N)+M) IEEE International Conference on Local Computer Networks, pp 455- 462. [Online]. Available: ZREVRANK o (log(N» all.jsp?amumber=1367266 _ [8] P. Levis, S. Madden, 1. Polastre, R. Szewczyk, K. Whitehouse, AWoo, ZSCORE 0(1) D. Gay, J. Hill, M.Welsh, E. Brewer et aI., "TinyOS: An operating ZUNIONSTORE O(N) + OeM log(N» system for wireless sensor networks," Ambient Intelligence, vol. 35, 2005. According to table III, we figure out time complexities of [9] F. Osterlind, A Dunkels, J. Eriksson, N. Finne, and T. Voigt, "Cross­ level sensor network simulation with COOJA," Proceedings. 200631stNoSQL queries under Sorted-sets backend data structure gives IEEE Conference on Local Computer Networks, pp. 641-648, Nov.better performances than Strings, Hashes, Lists and Sets. 2006. [Online]. Available: Also the problems came under Strings, Hashes, Lists and 33Sets can be solved using Sorted-sets. According to above [10] Command reference - Redis.; 2011: [Onlinecomparison results, we came up with a conclusion, Sorted-sets accessed: 10 Jun 2011].The International Conference on Advances in ICT for Emerging Regions - ICTer2011 15t & 2nd September 2011