Databases Performance Evaluation for IoT Systems:the Scrovegni Chapel Use Case

Lorenzo Incipini, Alberto Belli, Lorenzo Palma, Roberto Concetti, Paola PierleoniDipartimento di Ingegneria dell’Informazione

Universita Politecnica delle MarcheVia Breccie Bianche 12, 60131 Ancona, Italy

Email: l.incipini@pm.univpm.it, a.belli@univpm.it, l.palma@univpm.it, r.concetti@pm.univpm.it,p.pierleoni@univpm.it,

Abstract—Internet of things devices are used to collect datafrom the physical world, and to present the results in a waywell usable to the end user. Therefore, an accurate choice ofthe most appropriate technology for storing data collected fromthe network is relevant. In this paper we focus the attentionon the selection of the best database management system forcultural heritage applications, in particular referring to the usecase of light monitoring at the Scrovegni Chapel (Padua, Italy),to emphasize the Giotto’s frescoes. For doing so, SQL and No-SQL solutions are compared, and the obtained results are used tofind the best solution for this application. Moreover these resultscan be used as a practical reference for the more appropriateselection of the right database for real use cases.

Index Terms—Internet of Things, Wireless Sensor Network,Database, SQL, NoSQL.

I. INTRODUCTION

Nowadays, Internet of Things (IoT) applications are widelyused for monitoring and control a variety of scenarios, suchas: smart museum [1], physical data gathering from harshenvironments [2], collecting data of industrial activities [3],Ambient Assisted Living (AAL) applications [4], patient’shealth care [5], [6], smart cities [7], etc. An IoT system is com-posed of several sensors, that are small devices with limitedcomputational power and storage capability, used to convertphysical measures into electric signals and then transmittedto the sink node through radio interfaces. The sensing dataare typically stored into a remote database or also locally(into a database embedded into the sink node, see Fig. 1) andmade available to the users via a web or a mobile dedicatedapplication. Fig.1 depicts a typical network architecture ofsuch solution.

remote DB

local DBWireless Sensor

Networkuser

remoteserver

internetsinknode

node #2

node #4 node #k

node #1

node #3

Fig. 1. General architecture of an IoT sensor network.

Fig. 2. Scrovegni Chapel (Padua, Italy): The Last Judgement. Three IoT nodes(circled in yellow) mounted on metal supports: the first on the left-side, thesecond on the left of the door, the third on the right-side.

To realize the IoT architecture for lighting monitoring andcontrolling inside the Scrovegni Chapel [8] (Fig. 2), a databasefor storing the collected data is implemented. Fig 3 showsa snapshot of the web application of the monitoring system,where are depicted the RGB components sensed by one ofthe IoT device inside the Chapel and stored into the sinknode. This special site imposes severe restriction on the sensornodes (number of nodes, positioning, energy supply, etc.),and a specific design for this IoT system was required. Infact for this specific application, the customer has requested aWireless Sensor Network (WSN) composed of 5 sensor nodesand one sink node, that is able to sample the lighting inside theScrovegni Chapel every 5 minutes. The use of radio channel(IEEE 802.15.4) for data communication was necessary in

MIPRO 2019/CTI 507

Fig. 3. Chart snapshot of the web application; RGB components of lightinside Scrovegni Chapel.

order to minimize the wiring and simplify future nodes movingand adding. Moreover the wiring of the sensors and theinstallation of the hardware could damage or jeopardize theconservation of frescoes. The use of a self-configuring routingprotocol, like Routing Protocol for Low power and Lossynetwork (RPL) makes the WSN dynamic and scalable. Thisallows to reduce the interventions of technicians on-site, thusto operate directly from remote. Nevertheless the proper choiceof the best Data Base management Systems (DBMS) solutionfor storing the sensed data represents the key point, in factthis can make the system ready for successive upgrade of thesensor nodes or the IoT network architecture. The purpose ofthis work is to identify general comparative criteria betweenDBMS in order to make the best design choice in complexcontexts such as the Scrovegni Chapel.

A. Related works

Related papers are focused on the comparison of differentNoSQL DMBS through benchmarking tools, as in [9], or theperformance evaluation of SQL versus NoSQL solutions oncloud environment using sensing data [10], and an overviewof the current data storage systems in cloud computing andsurveys of the state-of-art of data processing is discussed in[11]. Similarly to our work, Van Der Veen [12] compares theperformance of a subset different from ours of SQL and No-SQL databases for the sensor network scenario, evaluated overphysical and virtual machines limited to server environments.Meanwhile, Nyati [13] compared the performance betweenMongoDB, running on a cluster of four machines, and MySQLon a single machine. Other database solution for IoT appli-cations are given by a distributed database [14], where eachnode of the network is able to store measurements and transmitsensed data when requested by the user, and a RFID repositorybased on MongoDB for sensor data source [15]. Recentlyare also appearing in literature Time-series DBMS for IoTapplications [16]. This kind of DBMSs are well suited for themanagement of data associated with timestamp information,that are the measurements a WSN sensor node. In [17] areinvestigated the performance of TritanDB Time-series DBMS.

As integration of the previous described literature, ourwork consists in the objective quantification of relational andnon-relational databases performances over embedded devices,using better hardware machines as a reference (see Table II).Especially we are considering an application scenario where

TABLE ICOMPARISON OF SQL AND NOSQL DOCUMENT-ORIENTED TERMINOLOGY

SQL NoSQLdatabase ↔ database

table ↔ collectionrow ↔ document

column ↔ field

data are collected and stored for improving the color renderingof Giotto’s frescoes of the Scrovegni Chapel cultural heritagesite.

The present paper is organized as follows. Section II givesa brief introduction to SQL and No-SQL DBMS and howdata is stored inside these databases. Section III describesthe implemented client-side scripts finalized to interact withthe databases and the different types of queries used toquantify the performance of the examined systems. SectionIV furnishes a brief description of the experimental simulationsetup. Section V provides results of the performed tests withgraphical and table support. Finally, Section VI presents theconclusions concerning the measured performance and thegeneral inferable guidelines for the designer.

II. SQL VERSUS NOSQL

Basically, two kinds of DBMS can be installed into a sinknode, namely relational and non-relational database. In the firstcase, structured data (table) and language (SQL) with Atomic,Consistency, Isolation and Durability (ACID) properties areused, while in the latter a more flexible schema (i.e. key-value, document or column-oriented, Graph DB) and a non-structured language (NoSQL) are used in order to get betterperformances at the cost of ACID. Table I summarizes theprincipal data structures of relational and document-orientedNoSQL databases. For these DBMS, the CAP theorem must beconsidered, which states that only two of the three propertiesof a distributed system (Consistency, Availability and Partitiontolerance) can be provided. In general, the partition toleranceadoption is preferable and then consistency or availability arealternatively chosen.

Relational databases use a rigid structure to store data,allowing a detailed vision of the managed data type. Each tableis a set of homogeneous data, which can be related to othertables by a specific relation (key). In this way, new tables canbe defined allowing relations (join) among data by specificrequests. On the other hand, non-relational databases allowheterogeneous data storage into the same collection, enablinga dynamic expansion of the database’s data nature, accordingto the new requests of an evolving application.

The present paper aims to furnish guidelines for choosingthe proper DBMS that better fitting the specific IoT’s architec-tural constrains. Therefore, we have analyzed the performanceof three different DBMS on three distinct hardware devices,usable to implement a sink node, representing a not exhaustivesubset of different computational and storage capabilities.Moreover for setting up the tests over the three DBMS, wealso have to take into account the amount of data that can be

508 MIPRO 2019/CTI

generated by the WSN. Since the network is composed of 5nodes sampling every 5 minutes, and the data are encapsulatedin the Constrained Application Protocol (CoAP) [18] (up to96 Byte are available for data [19]), the number of messagessent per day is 1440 and per year is 525600, and the respectivedimensions in byte are 138.2 KB and 50.5 MB.

The first analyzed database is MariaDB, representing arelational database exemplum and was choosen because of itsopen source patent and the high compatibility with MySQL.Indeed, the same client can be used to access both to Mariaand MySQL databases (the port, socket and API are equal),moreover the binary files representing the tables are compati-ble. Finally, MongoDB and CouchDB represent non-relationaldatabases, with the appealing characteristic of the open sourcelicense and a widespread use. MongoDB is an open sourcenon-relational database, where data are stored as Binary ScriptObject Notation (BSON) documents, gathered in collections.The BSON object is an extension of the Java SON (JSON),which is a standard data format [20] constituted of “key-value”pairs elements, in an easy to read and write composition byhumans, and be parsed and constructed by machines. A generalrepresentation of a JSON object is:

{key1 : value1, key2 : value2, ..., keyn : valuen}. (1)

Moreover, MongoDB has replication and distribution features,and a rich query language supporting Create, Retrieve, Uploadand Delete (CRUD) operations.

CouchDB is the second non-relational database used in ourtest. Similarly to MongoDB, data are stored like documentsas JSON objects, but a particular feature of this non-relationaldatabase is the ability to perform queries through HTTPrequests. CouchDB also implements a dynamic aggregationmethod, named View, that speed up queries using preparedstatements. Of course there are many other possible NoSQLdatabase solutions (column, key-value, graph, etc.), but for thispaper we choose to evaluate only document oriented family asNoSQL because they are the best choice for small and mediumsize IoT application [12].

In order to compare the performances of relational and non-relational database on different hardware setups, the tests wereconducted on three different devices implementing the sinknode functionalities: a Raspberry board model B, a personalcomputer and a virtual machine running on a server (therespective characteristics are shown in Table II).

The hardware constrains of the sink node of a IoT system(see Fig. 1) depend on a variety of factors such as numberof nodes, sensing area, type and number of sensing data,number of transmission, etc. and, in summary, on the suitable(costs/performance) rate for the specific application (e.g. in[2] an underwater vehicle is used to gathering data from

TABLE IIHARDWARE CHARACTERISTICS

Machine Architecture Max Clock Speed Core RAM OSPersonal Comp. x86 64 3100 MHz 4 8 GB UbuntuVirtual Server x86 64 2660 MHz 4 4 GB Debian

Raspberry armv6l 700 MHz 1 0.5 GB Raspian

underwater sensors). In most of IoT deployments, the sinknode functionalities can be implemented in low-cost embed-ded devices with limited processing and storage capabilities,nevertheless adequate to manage the network and store datalocally. Different deployment strategies can be adopted withthe increase in the network’s dimension. In fact, it is usualto overcome high numerosity of nodes with multiple sinksper network (horizontal scaling), otherwise, the hardwarecapability of the sink node can be potentiated (vertical scaling)to support the increasing network load. Therefore, different ar-chitectural solutions require diversified hardware resources forthe sink node, each of which providing specific performance.Therefore, the need of fast analysis resources, responding toproject specifications, for the combined choice of hardwareand software solutions emerge. The work presented in thispaper has exactly the previous purposes, providing reports ofperformance measured on different hardware platforms withvarious DBMS. Although the tested devices represent onlya limited subset of possible combinations of hardware anddatabase options, our tests provide significant support for thedesign and development of real solutions.

III. CLIENT-SIDE SCRIPTS

The performances of the DBMS under test are evaluatedby running Python scripts measuring the query time neededto write and read sensing data on the database. The Pythonclient libraries (MySQL [21], pymongo [22] and couchdb [23])are used to perform the respective connections to the DBMS.Since an IoT system collecting information from a sensing areais the application scenario, the most interesting functions tobe evaluated are multi-clients write operations, where a singlesensor node writing one data into the database is simulatedby a thread, and bulk reads from the database, to export thestored data into a remote server.

The series of queries to the database, generated by just asmany scripts, are summarized below.• One Client Operations:

– One sensed data is written into the database 10,000times;

– One stored data is read from the database 10,000times;

– A dataset of 100 sensed measures is written into thedatabase 1,000 times;

– A dataset of 100 stored data is read from the database1,000 times.

• Multiple Clients Operations:– One sensed data is written into the database, by 1 to

15 concurrent clients;– One sensed data is read from the database, by 1 to

15 concurrent clients;– A dataset of 100 sensed data is written into the

database, by 1 to 15 concurrent clients;– A dataset of 100 sensed data is read from the

database, by 1 to 15 concurrent clients.In [10], [12] the number of concurrent threads for the multiplewrite operation is 16, and since the WSN deployed inside theScrovegni Chapel have to be composed of 5 sensor nodes, we

MIPRO 2019/CTI 509

connect to db

t1=get time

t2=get time

disconnect

from db

db query

return t2-t1

Fig. 4. Flow chart of the Python script for query latency measurement.

have chosen to use 3 times that number of nodes as upperlimit for the multiple clients operations to test the differentdatabases for this specific WSN case of use.

In Fig. 4 is shown the code flow used to calculate the latencytime of the performed read or write queries on the selecteddatabase. The execution time is thus evaluated as the timerequired (t2 − t1) to receive the ACK from the database afterthe write instruction ending, or the time waited to receive thequeried data from the database. In case of queries executedby concurrent clients, each thread, which represent a singleclient, performs the operations reported in Fig. 4. The valuedt = t2 − t1 is then written on a file for further evaluation.

IV. TEST SETUP

The Python script is saved and ran on each under test device,and connects to the chosen database which is installed on thesame device to avoid network latency. Therefore, sensing dataare stored into the non-relational databases according to theschema in (1), which takes the following form:

{′sensor tag′ :′ sensor1′,′ sensor value′ : 27.0123456789,′sensor time′ : 1526891381.160871}

(2)

where value1 is a string used to identify the specif sensormeasuring data on the network, while value2 and value3 arefloating numbers representing the sensed value and the sensedtime respectively. The same data are stored into the relationaldatabase as a table like that depicted in Table III. The Pythonscript is then used to read and write the described values on thedifferent databases, and save into a file the resulting latencytime measured according to the flow chart of Fig. 4. Moreovereach test is repeated n times and the average latency over then simulations is evaluated.

TABLE IIISENSED DATA ON MARIADB

Column Name Data Type Examplesensor tag var char(10) sensor1

sensor value float 27.0123456789sensor time float 1526891381.160871

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Number of Clients

10-3

10-2

10-1

100

101

Lat

ency

(s)

CouchDB

MongoDB

MariaDB

Fig. 5. Multi clients: latency of single write operations on Raspberry.

V. RESULT AND DISCUSSION

As presented in Section IV, the results related to a singlewrite operation from concurrent clients are shown in Figs. 5,6, 7, and those referred to a bulk read from a single client inFigs. 9, 10, 11.Regarding the results displayed in Figs. 5, 6, and 7, the latencytime of the write operations increases with the number ofconcurrent clients as expected, and the database latency hasabout the same trend for the different testing devices. Thebetter performance is furnished by MariaDB, with an averagelatency time per client of 5 ms, 0.923 ms, 0.28 ms, withreference to the outcomes depicted in Figs. 3, 4, and 5 respec-tively, followed by MongoDB and CouchDB. Nevertheless,CouchDB seems to have only slightly inferior performancewith respect to MongoDB when running over Rapsberry orVitual Machine (see Fig. 3 and Fig. 5). Furthermore, theperformance on the embedded device is lower than that on theother machines, in fact the latency of write operations overthe relational MariaDB in Fig. 5 is about 6.5 times higherthan that in Fig. 6 and is 18 times higher than that in Fig.7. The same considerations can be done for the two NoSQLdatabases, indeed CouchDB on the embedded device is about9 times slower respect to the PC and 8 times slower the virtualmachine, while MongoDB on the embedded device is about40 times slower respect to the PC and 7.5 times the VM.In addition, the databases performance on PC and virtual ma-chine depicted in Fig. 6, 7 can be more effectively comparedevaluating the difference between their latency times. In fact,this comparison shows an almost linear trend for MariaDBand CouchDB, as presented in Fig. 8 where the vertical axisindicates the differences in the latency times.

This trend, which is almost superimposed for the PC andthe VM, shows that the latency gap between the databases(MariaDB and CouchDB) on PC and VM grows linearly andis about the same up to 9 concurrent clients. The trend changesslightly for a number of clients above 9, so the performanceremains almost unchanged as the underlying hardware varies,at least up to the number of competing clients consideredin our simulations. Moreover, the performance of CouchDBon the PC increases and the latency gap reduced accordingly,while on the VM it continues to grow.

510 MIPRO 2019/CTI

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Number of Clients

10-4

10-2

100

Lat

ency

(s)

CouchDB

MongoDB

MariaDB

Fig. 6. Multi clients: latency of single write operations on PC.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Number of Clients

10-4

10-2

100

Lat

ency

(s)

CouchDB

MongoDB

MariaDB

Fig. 7. Multi clients: latency of single write operations on Virtual Machine.

The next group of figures, Fig. 9, 10, 11, represents thelatency time of bulk read operations. Also from these figuresis possible to identify a similar behavior, in fact for all threedevices the average latency time trend is almost constant, andfor these devices is presented the same performance order ofthe databases. The considered non-relational databases demon-strate better performance respect to the relational one, Mari-aDB. Comparing the average latency of the faster database,CouchDB, the outcome for the different devices are: 0.917msfor Fig. 9, 0.032ms for Fig.10, and 0.034ms for Fig. 11,followed by MongoDB and MariaDB. The same behaviordescribed above is also confirmed in this test, the embeddeddevice offers significantly lower performance than PC and VMperformance. In fact, CouchDB is about 28.6 times slower thanthe PC and 27 times respect to the VM, while MongoDB is 33times slower than the PC and 19 times slower than the VM.

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Number of Clients

0

0.1

0.2

0.3

0.4

0.5

0.6

0.7

Lat

ency

gap

(s)

PC

VM

Fig. 8. Latency times difference between CouchDB and MariaDB on PC andVM for multi clients single write operations.

0 100 200 300 400 500 600 700 800 900 1000

Iteration

10-5

10-4

10-3

10-2

Lat

ency

(s)

CouchDB

MongoDB

MariaDB

Fig. 10. Single client: latency of bulk read operations on PC.

The complete characterization of the databases performance isobtained through the execution of a series of tests simulatingthe most frequent operations over a database whose results aresummarized on Table IV and Table V. The best performancesof each devices are highlighted. Table IV collects the averagelatency time of single client operation while Table V shows theaverage latency time per client for the multiple client queries.These outcomes lead to say that the relational database,represented by MariaDB, has the lower write latency time, but,on the other hand, non-relational databases, MongoDB andCouchDB, have the best reading performance. Furthermore,comparing the results for the three devices, the virtual machineand the personal computer have almost the same latency time,while the embedded device has slower query time. In fact it isabout 40 time slower then the PC and 60 times slower then thevirtual machine. These performances of the embedded devicerespect the other two machines were expected, because of thedifferent capacity of the hardware installed.

0 100 200 300 400 500 600 700 800 900 1000

Iteration

10-4

10-3

10-2

10-1

Lat

ency

(s)

CouchDB

MongoDB

MariaDB

Fig. 9. Single client: latency of bulk read operations on Raspberry.

VI. CONCLUSION

This paper compares 3 DBMS running on machines withdifferent hardware characteristic, and the performances of suchdatabases are evaluated in the context of a IoT data storage sce-nario in a site with cultural heritage constrains. Results shownon Section V point out that the relational database MariaDBhas better write speed than the non-relational MongoDB andCouchDB, but the latter offer faster read operations.A good solution for sensor network applications is given by adatabase used to store sensor measurement temporarily, which

MIPRO 2019/CTI 511

TABLE IVSINGLE CLIENT RESULTS

Operation DB Rasp. (ms) P.C. (ms) V.M. (ms)

single writeMongo 57.65 1.8125 0.482Maria 2.493 0.713 0.6285Couch 6.966 47.14 3.900

single readMongo 1.209 0.051 0.071Maria 134.6 13.14 4.242Couch 0.094 0.034 0.004

bulk writeMongo 589.5 1.923 2.725Maria 122.0 4.700 1.414Couch 670.6 85.18 41.67

bulk readMongo 1.326 0.040 0.070Maria 9.900 1.500 0.450Couch 0.917 0.032 0.034

TABLE VMULTIPLE CLIENT RESULTS

Operation DB Rasp. (ms) P.C. (ms) V.M. (ms)

single writeMongo 233.7 5.548 30.97Maria 5.065 0.769 0.281Couch 364.0 41.83 44.56

single readMongo 2.472 0.093 0.070Maria 6.037 1.427 0.361Couch 3.878 0.109 0.051

bulk writeMongo 233.7 11.46 7.352Maria 5.065 170.9 21.66Couch 1092 42.24 47.06

bulk readMongo 24.47 0.08 0.069Maria 6.037 181.7 77.67Couch 3.878 0.098 0.051

allows fast single write operations and fast bulk read to loadthe data to the remote database. The simulations performedhaven’t found a valuable database for both operations, thus thesolution depends on the requirements of the sensor network’stasks. However the chances of use schema-less databases (non-relational) is really attractive to store heterogeneous sensordata, indeed the nature of a IoT application is dynamic and thekind and number of sensor data to store may change during theapplication lifetime, leading to chose NoSQL database solutionfor such applications. In conclusion, the results obtainedsuggest us to use MongoDB as database solution for the IoTapplication developed for the Scrovegni Chapel, and othersheritage sites IoT systems.

For the future works we are planning to test TimeSeries DBon a real use case to evaluate its performances on a WSNapplication.

0 100 200 300 400 500 600 700 800 900 1000

Iteration

10-4

10-3

10-2

Lat

ency

(s)

CouchDB

MongoDB

MariaDB

Fig. 11. Single client: latency of bulk read operations on Virtual Machine.

CONFLICT OF INTERESTS

The author(s) declare(s) that there is no conflict of interestregarding the publication of this paper.

REFERENCES

[1] A. Chianese and F. Piccialli, “Designing a smart museum: When culturalheritage joins iot,” in Next Generation Mobile Apps, Services andTechnologies (NGMAST), 2014 Eighth International Conference on.IEEE, 2014, pp. 300–306.

[2] I. Vasilescu, K. Kotay, D. Rus, M. Dunbabin, and P. Corke, “Datacollection, storage, and retrieval with an underwater sensor network,” inProceedings of the 3rd international conference on Embedded networkedsensor systems. ACM, 2005, pp. 154–165.

[3] L. Da Xu, W. He, and S. Li, “Internet of things in industries: A survey,”IEEE Transactions on industrial informatics, vol. 10, no. 4, pp. 2233–2243, 2014.

[4] L. Palma, L. Pernini, A. Belli, S. Valenti, L. Maurizi, and P. Pierleoni,“Ipv6 wsn solution for integration and interoperation between smarthome and aal systems,” in Sensors Applications Symposium (SAS), 2016IEEE. IEEE, 2016, pp. 1–5.

[5] H. Alemdar and C. Ersoy, “Wireless sensor networks for healthcare: Asurvey,” Computer Networks, vol. 54, no. 15, pp. 2688–2710, 2010.

[6] M. S. D. Gupta, V. Patchava, and V. Menezes, “Healthcare based oniot using raspberry pi,” in Green Computing and Internet of Things(ICGCIoT), 2015 International Conference on. IEEE, 2015, pp. 796–799.

[7] B. M. K. Gandhi and M. K. Rao, “A prototype for iot based car parkingmanagement system for smart cities,” Indian Journal of Science andTechnology, vol. 9, no. 17, 2016.

[8] P. Pierleoni, A. Belli, L. Palma, S. Valenti, S. Raggiunto, L. Incipini, andP. Ceregioli, “The scrovegni chapel moves into the future: an innovativeinternet of things solution brings new light to giotto’s masterpiece,” IEEESensors Journal, 2018.

[9] B. G. Tudorica and C. Bucur, “A comparison between several nosqldatabases with comments and notes,” in Roedunet International Confer-ence (RoEduNet), 2011 10th. IEEE, 2011, pp. 1–5.

[10] T. A. M. Phan, J. K. Nurminen, and M. Di Francesco, “Cloud databasesfor internet-of-things data,” in Internet of Things (iThings), 2014 IEEEInternational Conference on, and Green Computing and Communica-tions (GreenCom), IEEE and Cyber, Physical and Social Computing(CPSCom), IEEE. IEEE, 2014, pp. 117–124.

[11] H. Cai, B. Xu, L. Jiang, and A. V. Vasilakos, “Iot-based big data storagesystems in cloud computing: Perspectives and challenges,” IEEE Internetof Things Journal, vol. 4, no. 1, pp. 75–87, Feb 2017.

[12] J. S. Van der Veen, B. Van der Waaij, and R. J. Meijer, “Sensordata storage performance: Sql or nosql, physical or virtual,” in CloudComputing (CLOUD), 2012 IEEE 5th International Conference on.IEEE, 2012, pp. 431–438.

[13] S. S. Nyati, S. Pawar, and R. Ingle, “Performance evaluation of un-structured nosql data over distributed framework,” in 2013 InternationalConference on Advances in Computing, Communications and Informat-ics (ICACCI), Aug 2013, pp. 1623–1627.

[14] O. Diallo, J. J. Rodrigues, M. Sene, and J. Lloret, “Distributed databasemanagement techniques for wireless sensor networks,” IEEE Transac-tions on Parallel and Distributed Systems, vol. 26, no. 2, pp. 604–620,2015.

[15] Y.-S. Kang, I.-H. Park, J. Rhee, and Y.-H. Lee, “Mongodb-basedrepository design for iot-generated rfid/sensor big data,” IEEE SensorsJournal, vol. 16, no. 2, pp. 485–497, 2016.

[16] S. K. Jensen, T. B. Pedersen, and C. Thomsen, “Time series manage-ment systems: A survey,” IEEE Transactions on Knowledge and DataEngineering, vol. 29, no. 11, pp. 2581–2600, 2017.

[17] E. Siow, T. Tiropanis, X. Wang, and W. Hall, “Tritandb: time-series rapidinternet of things analytics,” arXiv preprint arXiv:1801.07947, 2018.

[18] Z. Shelby, K. Hartke, C. Bormann, and B. Frank, “The constrainedapplication protocol (coap)(rfc 7252), 2014,” 2016.

[19] “Ieee standard for low-rate wireless networks,” IEEE Std 802.15.4-2015(Revision of IEEE Std 802.15.4-2011), pp. 1–709, April 2016.

[20] T. Bray, “The javascript object notation (json) data interchange format,”2014.

[21] “https://dev.mysql.com/doc/connector-python/en/connector-python-introduction.html.”

[22] “https://docs.mongodb.com/getting-started/python/client/.”[23] “https://pythonhosted.org/couchdb/.”

512 MIPRO 2019/CTI