HENRI TERHO USING NOSQL DATABASE SOLUTIONS IN MOBILE ... Terho.pdf · Keywords: mobile, android, noSQL, couchDB, eHealth In the coming future, the healthcare system will face severe

HENRI TERHOUSING NOSQL DATABASE SOLUTIONS IN MOBILE HEALTHCARE APPLICATIONSBachelor of Science Thesis

Examiner: Associate Professor Heikki Huttunen, Supervisor: Ste-fan Baggström

II

ABSTRACT

TAMPERE UNIVERSITY OF TECHNOLOGYDegree Programme in BiotechnologyTERHO, HENRI: Using noSQL database solutions in mobile healthcare applicationsBachelor of Science Thesis, 19 pagesDecember 2012Major: Computational Systems BiologyExaminer: Associate Professor Heikki HuttunenSupervisor: Stefan BaggströmKeywords: mobile, android, noSQL, couchDB, eHealth

In the coming future, the healthcare system will face severe problems with recruiting enough workforce to handle the growing need for healthcare services. To solve this dilemma, improving the efficiency of the healthcare system is necessary.

Modern mobile technologies offer an excellent platform to achieve boosts in healthcare services, by enabling the healthcare system to move from just treating the patient to a more pre-emptive stance. Also these mobile devices can be used for telemedicine or remote monitoring to remove most of the burden of automatable tasks from healthcare personnel.

To implement these solutions effectively, the technological solutions chosen to create the software that runs these services effects quality and feature set of the core application. In this thesis, we investigate a new database solution combined of two parts CouchDB and TouchDB that follow the noSQL paradigm. We then compare this to a more traditional SQL solution in the context of mobile healthcare systems. These systems typically comprise of the client application running on the mobile device and a central server that collects data.

The features of the newer CouchDB solution are more suited to the mobile environment by offering efficient synchronization routines that support offline functionality. This enables easier integration of mobile handsets with variable connection quality to the server structure. CouchDB is scalable to both handset and server side, functioning efficiently with small and large data sets. Also the usage of common programming language javascript as the query language, there is no need to convert database calls between different languages, improving application security. We find that one problem that the user has to be mindful of in the couchDB implementations is that the size of the database grows faster than an traditional SQL database and it has to be taken into account when developing applications.

III

PREFACE

This thesis is about my work in the project FELIX Research group at the department of Biomedical engineering. I want to thank Stefan Baggström for supervising my work and Heikki Huttunen for his role as the examiner. Also I want to thank Teemu Terho for proofreading the work and Jäger MSc for his support in this endeavour.

Henri TerhoTampere 2.12.2012

IV

CONTENTS

1 Introduction..............................................................................................................12 Mobile healthcare ecosystem...................................................................................3

2.1 Mobile healthcare systems...........................................................................32.2 Operating environment.................................................................................6

3 Mhealth service requirements..................................................................................73.1 Availability...................................................................................................73.2 Offline functionality.....................................................................................73.3 Synchronization & Concurrency..................................................................83.4 Scalability ....................................................................................................83.5 Privacy & Security.......................................................................................83.6 Speed............................................................................................................8

4 Database solution...................................................................................................104.1 SQL............................................................................................................10

4.1.1 General structure.............................................................................104.1.2 Data access......................................................................................114.1.3 Concurrency model.........................................................................114.1.4 Synchronization..............................................................................12

4.2 NoSQL........................................................................................................124.2.1 General structure.............................................................................134.2.2 Data access.....................................................................................144.2.3 Concurrency model.........................................................................154.2.4 Synchronization..............................................................................15

5 Discussion..............................................................................................................17References.......................................................................................................................19

V

ABBREVIATIONS AND NOTATION

mHealth The practice of medicine and public health, supported by mobile devices.

eHealth Healthcare practice supported by electronic processes and communication.

noSQL Database paradigm that describes databases that have moved away form the relational mapping SQL paradigm.

mySQL A relational database

Sqlite A lightweight version of the standard mySQL database, with smaller feature set

touchDB A database done according to noSQL paradigms.

couchDB A mobile version of touchDB built on top of Sqlite.

TCP/IP stack The software on a computer that handles the lowest levels of network connectivity.

SQL injection An intrusion attack that can be made against SQL using web pages that is done by injecting SQL commands into inputs

JSON Javascript object notation, a way to encode java arrays and maps into strings

REST Style of software architecture for distributed systems such as the World Wide Web. REST has emerged as a predominant Web service design model.

HTTPS A widely used communications protocol for secure communication over a computer network.

SSH Secure Shell is a cryptographic network protocol for secure data communication

1 INTRODUCTION 1

1 INTRODUCTION

In Finland the modern system will face a resource crisis. The mean age of the Finnish populace is shifting rapidly to the direction of the elderly. Healthcare of the elderly re-quires more resources from the healthcare system[1] and this combined with the fact that the total workforce in the Finnish healthcare system is also suffering from a short-age of nurses and doctors creates a case of increasing workload for the healthcare work-ers in the field.[2] Solutions for this problem are being developed under the acronyms eHealth or mHealth.

The term eHealth is defined as healthcare supported by electronic processes and communication. The term mHealth means healthcare supported by mobile devices. With the advent of new more powerful smart phones and the growth of mobile internet ac-cess, these two terms are converging to the same solutions. The goal of improving the efficiency of healthcare work and to provide better care for the patient and at the same time reducing the workload of both the patient and doctor from menial tasks such as data logging, motoring and reminders. [3][4]

The requirements of a system that can be used as an efficient platform for mHealth services are quite extensive, because of the usability and reachability require-ments for such systems. When deployed to a mobile device, the system has to be able to handle all the different caveats of the changing environments the phone might be in. The system cannot guarantee continuous server reachability by using only the mobile net-work, the system also has to work where the coverage of cellular data networks is spo-radic. In data logging type mHealth applications there is a need to store this data to a lo-cal storage and sync to the server when the cellular network is available. Also in some use cases, critical information has to be conveyed fast across the system to guarantee patient safety.[4]

An example of a simple, but demanding application is a food diary type applica-tion, where the user takes photos of everything he/she eats and this is then sent to the server, where it is accessible and commentable by a coach or a doctor. The proof of concept system is realistic and there are similar systems in use right now in commercial and healthcare applications.[4][5] This system requires that the system is usable when-ever the user eats something independent of cell phone network status. The system must also scale for the situation that the doctor has multiple patients in his care so that the ef-ficiency improvement goals of mHealth systems are realized truthfully.

This thesis investigates the way noSQL databases can be efficiently used to de-ploy mHealth services with the necessary level of functionality for the user. And how to

1 INTRODUCTION 2

provide an easy to implement database solution to produce adequate offline/online sync-ing functionality for mobile devices and to show that noSQL1 databases fit nicely into the now popular lean work flows of software companies. With the end goal of facilitat-ing fast development of the mHealth sector and to enable better healthcare services for the populace.

NoSQL database solution is compared to the more classic SQL database solu-tions and their feature sets compared. The SQL solutions used in this thesis as a compar-ison is the open source MySQL2 database and the SQlite database, meant for mobile de-vices. MySQL is a proven and widely used SQL database solution[6] and the SQlite3 database is a small footprint embedded database solution, which offers most of the SQL functions found in heavier relational database solutions. As mobile devices generally don't have enough power to run the full blown SQL software, SQlite version is usually used in the mobile environment. The android mobile operating system uses SQlite as its default database solution[7].

NoSQL solution used in this thesis is couchDB and its mobile equivalent touchDB4. They provide strong replication features that can be used to synchronize dif-ferent databases easily. Also the schema-less structure of couchDB facilitates fast devel-opment cycles and provides for a way to store nearly all application data in the database and changes made to the database do not require a complete database overhaul. The mo-bile equivalent, touchDB, also provides automatic handling of the syncing with the server whenever the data network is available and removes the burden of writing effi-cient synchronization and network connection code for the application. Also as an addi-tional bonus, the security of the system is improved when the database query language is the same language that is used in the application, lessening the risk of SQL injection type attacks. [8]

1 http://couchdb.apache.org/2 http://www.mysql.com/3 http://www.sqlite.org/4 https://github.com/couchbaselabs/TouchDB-Android

2 MOBILE HEALTHCARE ECOSYSTEM 3

2 MOBILE HEALTHCARE ECOSYSTEM

2.1 Mobile healthcare systems

Nowadays the healthcare sector is moving away from just treating to a more proactive stance on the healthcare problems, active inhibition of health problems that may arise. One way this is done is by increasing the tracking of patients with aging related and chronic conditions. Previously this required multiple trips to the doctors office, but now tracking can be done over the phone or through a mobile application, eHealth applica-tions. Another way these applications are used to treat chronic conditions and for exam-ple obesity, is through behavioral change. The way the applications track or make you track your own behavior makes you change your eating behavior towards a healthier perspective. A third critical way that was found is that the usage of these application also increases patient compliance with their medicine, which is a major problem in many fields [4].

Currently the main drive to develop these applications is not from the healthcare sector or the government, but from the IT-industry and start ups. The environment where mobile internet access is common and smart phones on every hand created a pos-sibility to expand the mobile market into the health industry. In the same way e-com-merce revolutionized the commerce industry, it is hoped the effect of mobile systems to the health industry is even greater, leading to more value produced, ie. Healthier people. This has caused the governments to slowly wake up to integrate their systems with the many solutions that the open source and start up community has already created, noting that the systems developed by governments are old and revision is bogged down by po-litical will. [4][9]

The actual functions of eHealth systems are myriad and there are many types of applications being developed. These can be broadly divided into a couple of categories described in chart 1.


Storing and tracking Applications that store and track information recorded by/from the patient, including weight, heart rhythm, food habits etc.

Telemedicine Applications that allow a remote connection to a healthcare specialist, not limited to voice, but can also use text messages, pictures

Reminding and patient compliance Applications that remind the patient to take his medicine or go take a jog in a proactive way, driving behavioral change

Health informatics Applications that allow the patient access to general health information of his personal health records

Prescription management Allows healthcare personnel to remotely manage the prescriptions of the patient, also reducing hospital visits

Chart 1: Different categories of eHealth systems

The different forms the eHealth application can take can be seen from the differ-ent application in the chart 1 , but one idea is core to all these systems: Information gathering and management. Either the application functions as an easier way to access information, be it in a way of a healthcare specialist, or a database of healthy foods for diabetics, or to track different statistics of the patient, producing more information about his state.

The additional information collected by these applications from the patients make the decision making process of the doctor much easier, as he has access to more data, 88% of doctors wanted the patients to track their health at home to make the data they base their decisions on as broad as possible[4, p. 13]. Also when the patient does the tracking by themselves at home, they reduce the amount of time spent on the doctors visit, as the doctors don't have to spend valuable time doing tasks that could be auto-mated or done through mobile health. This Could also significantly boost the effective-ness of the healthcare system in the coming healthcare crisis, as one doctor could use his time more efficiently on patient care, not data gathering.[4][1]

The theme of making the healthcare system more efficient through eHealth is pervasive throughout all the different applications. The behavioral change and health in-formation access take the proactive stance, trying to reduce the number of hospital visits required by making sure the patients don't fall into chronic disease loop, where only the symptoms are treated by the healthcare system and the behavior of the uninformed pa-


tient causes him to be readmitted on a short notice back to the healthcare system. These try to influence the behavior of the patient by more information or by reminders and tracking of his own weight for example. It has been shown that just by tracking your weight and becoming more informed about it through eHealth systems, you can lose weight. [4][10]

The other way is to make enough patient data to improve the quality of health-care treatment to make sure the treatment given to the patient is the right one. Usually doctors have to do decisions based on limited data sets, but by providing them with the wide data sets that are possible to collect with eHealth systems, they can make more data based choices in treatment and also improve the efficiency, when less time ca be spent on data gathering when visiting the clinic. [4]

The telemedicine side tries to make the healthcare services more accessible and also retroactive by helping patients and doctors get in touch with each other. Not all problems require a full visit to the clinic, a short text message could suffice, for example when the doctor notices from the data that the dosage of a certain drug should be changed, he could inform the patient with just a simple text message. [4]

The odd man out is patient adherence and Prescription management. This is not a new way to improve on the healthcare system, but more to make sure the treatment is actually taken in time if at all, making sure the treatment is prescribed is taken and not left out or forgotten. This had the effect of improving treatment effectiveness greatly and also as a side effect, that might push eHealth forward, increasing the usage of medicines, creating an incentive for drug companies to push eHealth and logging for-ward [4].

This analysis makes the eHealth solutions seem to be a silver bullet to the healthcare systems current efficiency problems, but the main problems with the system come not from the efficiency side, but from the human side. People are not yet willing to use mobile technology to improve their health. 51% of people in the HRI consumer survey, 2010 [4] said that they would not buy mobile health technology. And also, the segment that woulds buy mobile health systems are usually already more interested about their own health and typically healthier, than the segment that is not interested in their own health. This remains a problem that is inherent with all new technology.

One barrier to entry, are also the tight legal regulations concerning patient data security. The eHealth solutions have to be secure enough that they do not breach patient privacy. 41% of specialists cited this as their primary concern with eHealth systems.[4]. The solutions brought forth in this paper both bring forth adequate ways to build this se-curity around patient data.


2.2 Operating environment

In the previous chapter we explored the operating environment of the eHealth systems from a societal point of view. This chapter starts to take us deeper into the technical side of the equation. The eHealth systems are commonly operated in countries that have a well developed mobile network that allows for a large coverage of the country. For the purposes of this thesis we limit our scope to Finland. The cellphone infrastructure in Finland is well developed and smart phones are commonplace. This creates an environ-ment, where the deployment of eHealth systems is feasible, however understanding of the platform is critical to understand the type of infrastructure required to create work-ing and secure eHealth applications that can be used to create mobile health and well-ness solutions.

In Finland the country is mostly covered by 3G networks of the major telecom providers and the Finns are already proficient with using cellphones. But as the cover-age is not full and the data capable 3G networks are not capable of reaching into every spot and for example into the insides of some buildings, the eHealth application have to be constructed to handle offline status.

The security of the data link to the server has to also be safe and secured. The 3G network in itself is secured with a cryptographic algorithm , making the interception of the wireless data between the phone and the link mast difficult, the IP packages them-selves that are sent between the phone and the server are not by default secure, so a dif-ferent kind of encryption for example HTTPS or SSH type of secure connection over the internet to the server has to be used to make sure customer data is not misused by a third party. There are multiple standards that have been created to address the level of security needed by health information processing applications [11].

3 MHEALTH SERVICE REQUIREMENTS 7

3 MHEALTH SERVICE REQUIREMENTS

The more abstract requirements of the eHealth services boil down all the way to the database solution level, creating different requirements that the database solution has to be able to fulfill. Based on the discussion in previous chapter we have identified the usual key need for databases and talk through them in this chapter. These are then used to evaluate the two competing solutions being presented: MySQL with SQlite and CouchDB. For the purposes of this thesis, both solutions offer a server side database ac-cessible through the internet and a local database that is synchronized with the server to provide offline functionality.

3.1 Availability

Availability and reachability are terms that are used to represent the idea of how well the database is available to the customer. Usually what is wanted is that the database is always reachable for the customer and no extra downtime is wanted. In mHealth sys-tems that continuously store data, for example an EKG meter, the downtime of the stor-age solution means lost data, during which anything could happen. Also if the system is used to trigger an emergency response from an heart attack or similar, the loss of con-nectivity during such an event could be fatal.

Because of this the availability of the data solution ranks high in our evaluation. Of course availability is also affected by the connection between the device and the database, but in this thesis, we omit this from analysis, as it is a different system from the databases.

3.2 Offline functionality

In the mobile context discussed in chapter 2.2 , we cannot always assume that we will have a connection to the internet, so the database has to be able to provide an adequate version of itself that runs on the mobile while in offline mode. Also the synchronization of this database has to be easy to the main server database to make sure the client and server data remain the same, so that no discrepancies form.


3.3 Synchronization & Concurrency

As discussed, the synchronization with the server side is important to allow offline and online modes to work harmoniously. Synchronization with the local storage and server database should be easily possible, providing a way to cache the locally stored informa-tion ready to be sent to the master server when the connection resumes. The system should also be able to handle sudden drops of connectivity, even in the middle of syn-chronization information being just sent to the server.

Also the synchronization and concurrency models must be such that multiple clients can access the server database at the same time. Also for security reasons we do not want to copy the whole database to the users phone, but just his personally needed information, so partial synchronization should also be available for the application.

3.4 Scalability

The database solution should be able to work in both environments on the server side and the mobile device side. On the server side it serves multiple mobile devices, and in the mobile device, where just 1 client is being served his information. Providing fast ac-cess in both the cases of only little data available and in the case of a large server data set is a necessity for the database.

3.5 Privacy & Security

Privacy and security principles in systems containing the personal data of individuals is governed by many laws in nearly all the countries. These safety features must be imple-mented on the system. Usually these systems are built on top of the database and do not directly interact with the database. The security required by the database is that the com-munications channels used by the database must be encrypted. In both our databases, this is achieved either through SSH or HTTPS communications, so no comparison be-tween feature sets need to be done. [6][8]

3.6 Speed

The speed of the database solutions in a mobile healthcare system is usually not the bot-tleneck in response time. Usually the database response time scales with the size of the database. This is already limited by the memory offered by the mobile devices and in


the case of the database being stored in the cloud, the ping times of a typical mobile data connection are already measured on hundreds of milliseconds, so the database speed should not be an issue.

4 DATABASE SOLUTION 10

4 DATABASE SOLUTION

4.1 SQL

The SQL solution in this thesis is MySQL, the most popular SQL solution in use[6]. In combination with this we use the mobile lightweight version of SQL in the mobile de-vice, called SQlite, which is offered natively by the android operating system in use.[7] Both of these solutions are coded in C.

4.1.1 General structure

SQL stands for structured query language, and it is used to manage data in a relational database. In a relational database, the data is stored in sets of tuples, that have the same attributes, and these tuples are organized into tables. An SQL database typically contains multiple tables, which have a some kind of relation with each other, and being linked in the data, hence the name relational database. For example in the image 1, we have a small relational database, consisting of three different tables, linked to each other by their keys. The way SQL stores information also requires, that the format of these tables and the relation between them is known before the database is fed any data, this struc-ture is called the database schema. The database also stores information in different data types, for example integer and string, so this information is also contained in the schema. In SQlite , only a limited set of data types, NULL, INTEGER, REAL, TEXT and BLOB are supported, as opposed to MySQL which supports a larger set of data types.

The typical structure of an SQL table is shown in illustration 1. The Data is for-matted as an SQL table in plain text, using SQL own syntax. It is shown as a table struc-ture that prints the parameters of the requested table from the database. The table is the typical structure of data that SQL uses.


Item name In storage Is Edible---------------------- ---------- ---------Banana 4 trueApple 1 truePencil 2 falseBook 1 false

Illustration 1. A typical SQL table output

4.1.2 Data access

The access to these tables is handled by relations, which are conveyed to the database system by using the SQL query language. The data is accessed by forming queries that map a certain part of the tables in question and this part is then returned to the client. SQL uses its own control language to do this, so conversion between pro-gramming languages data types has to be typically done.

SELECT itemName AS Name, inStorage AS In storage,

isEdible AS Is Edible FROM Storage GROUP BY isEdible;

Illustration 2. A sample SQL query

A typical SQL query is seen in the illustration 2. The query fetches the rows itemName, inStorage and isEdible from the Storage table and changes the names of the parameters into a more human readable form. It also organizes them according to isEdi-ble. This query results in a table seen in Illustration 1, if the database contains the same kind of data organized into the Storage table in the database. SQL queries in their basic form use the select operator and from operator to get data from the database and format it according to multiple other operands. Many set operations are also available[12]

4.1.3 Concurrency model

MySQL adheres to the ACID principles in database design, A stands for atomicity and means that each transaction is an all or nothing event if the event succeeds, all is committed, if something fails, the whole statement fails. The database also guarantees that this is true even in the case of power failures, errors and crashes. C mean consis-


tency, meaning one transaction transfers the database from a valid state to another, so that all data edited by the transaction must be valid. I stands for isolation, which defines that all statements happen isolated from each other. The final letter D in ACID means that when data in the database is committed it will remain so, until someone else changes it, even in the situation of a power crash or bug.

In SQL, this isn't strictly true and the isolation level of the different database transactions can be changed, the options being READ UNCOMMITTED, READ COM-MITTED, REPEATABLE READ and SERIALIZABLE. Setting these levels allows the user to tailor the behavior of the database to his liking. [12] These settings allow for the database to lock the values during writes so that no one can access them, or that the old data is served to the reader while a write is ongoing.

4.1.4 Synchronization

In SQL there is a tool for database synchronization, that enables one way synchroniza-tion between servers, called MySQL DUMP, which basically copies the raw data from database to database. This allows the user to create a copy of the database on another machine to protect against hardware failure. This can also be used to set up two way synchronization between two databases, by dumping data back and forth. For a web configuration however, there is no direct support for multiple databases being synchro-nized in a two way setup. Also the DUMP always copies the whole database, not allow-ing for partial copies or synchronizations, where for example the user data of only 1 user is synchronized to the mobile device. Also there is no logging on the database level to see when the data changed and from what device, making the web topology of data-base synchronization quite difficult to set up. It could be done by programming a sepa-rate program to handle the synchronization on top of the database, but this then becomes something that is not a database feature.[12][13]

4.2 NoSQL

CouchDB is a quite new database solution first surfacing in 2005, written in Erlang. The database was developed to embrace new web technologies head on, storing data in JSON format and using javascript directly as its query language. CouchDB is usually described as an NoSQL language, meaning that does not use the relational database model. CouchDB and its mobile counterpart TouchDB use the same code base, but TouchDB has all the UI components removed for smaller footprint on the mobile de-vice. CouchDB is open-source under the Apache license 2.0 . [8]


4.2.1 General structure

CouchDB is document type database, meaning that it does not store single values, but documents that are nearly analogous to real life documents, that consist of key/value pairs that all have their own id and revision number. These are stored in the database in the JSON format, allowing easy import of them into the web environment. So the data-base stores purely strings, into which all data is formatted. Also the atomic component of the database is the document, so no partial updates on documents, updating only one value are possible. The document is a JSON string which Is a collection of values grouped together.

{ "_id" : "bc2a41170621c326ec68382f846d5764", "_rev" : "2612672603", "item" : "apple", "prices" : {

"Fresh Mart" : 1.59, "Price Max" : 5.99, "Apples Express" : 0.79 } }

Illustration 3. A sample couchDB JSON document [8]

The basic structure of a single couchDB document is shown in illustration 3. The document is a sample from the couchDB manual. It contains the information stored in the document by the user and two filed _id and _rev to store a unique document id that is used as a key in the B+tree and revision number for versioning. The JSON string is formatted for better human readability.

The data in the database is actually stored in the database as B+Trees, that offer a very fast lookup time for data, typically under 10ms even for extremely large datasets. CouchDB basically is a b+tree manager, providing an HTTP access layer and a REST API for them. A b+tree is illustrated in picture 1, showing how the keys 1-7 map to data under them.


CouchDB has no SQL like schema, that requires the data format to be known be-fore the data is saved to the database, instead it just saves all data as documents into the database with their own id and after this the data can be accessed more efficiently by constructing Map/Reduce functions that provide a powerful way of organizing the docu-ments into views by their content. This layering provides separation between the actual data and the way it is handled in views, providing a powerful tool to map the data by use case, eliminating the limitations that come from the way that SQL stores its infor-mation already formatted to specific tables and lists. The same data can be organized by using views to suit the requirement exactly and extra data can be removed, thus making the database usage more clear. [8]

4.2.2 Data access

function(doc) { if(doc.date && doc.title) { emit(doc.date, doc.title); } }

Illustration 4. A sample couchDB map function [8]

In CouchDB data is accessed using javascript as the query language. Usually the access is done by the REST api provided by the database. This allows the user to access docu-ments directly by their document ID. This is the most primitive way to access data.

The most powerful feature of CouchDB is the way it constructs views of the data, by using map/reduce functions. These functions allow the database to map its con-tents into predetermined views. MapReduce functions are derived from map and reduce combinators of functional programming languages. Map takes a sequence of values as input and applies a function to every value. Reduce then takes the elements from these

Picture 1. B+tree structure illustrated [8]


and usually computes a binary operation, for example addition to the results of the map functions. Using map Reduce functions you can easily produce lists from the data. For example all documents of a certain type, ordered by date. Map functions are run paral-lel, so they can be run fast on a large grid, even for large data sets.[14]

In illustration 4, there is an example of a map function. When constructing a view, this function is run for every document in the database. This particular map function takes every document and if they contain a date and title filed, the date and title of that document is emitted to form a part of the view. In this way data can be collated from many documents into a single view. This is also outputted in JSON so it is still compati-ble with web.

4.2.3 Concurrency model

CouchDB uses a multi version concurrency control schema, that allows concurrent reads to always happen by storing an old version of data during updates. This means that when a write happens, the old data is marked old and the new data is added to the database with a newer revision number. This allows reads to always happen, but at the cost of some failed writes, as when you update a document on the database, you must supply the revision of the document you're trying to update to be allowed to run the up-date. This also leaves conflict resolution to the user. When two synchronized databases are in conflict, couchDB leaves both versions on the database and throws a conflict. It can then resolve this conflict by rules set by the user, for example always prefer server 1 over server 2. Then the version from server 1 becomes the newest version and the ver-sion from server 2 becomes an old version.[8]

4.2.4 Synchronization

The most powerful feature of CouchDB is its automatic two-way synchronization rou-tine with built in support for offline/online functionality, allowing two servers to sync

Picture 2. couchDB concurrency model [8]


when there is a connection and working independently, when there isn't. For the pro-grammer, the synchronization is set up as easily as telling the IP address of the server that you want to sync with and all the other features are abstracted under the hood.

Also a powerful part of this tool are the filtered synchronizations, allowing you to only synchronize wanted data between two servers. This allows you to set up a server structure, that as all the data stored on the master server and all the mobile clients syn-chronize with this database. They all synchronize fully with the common files for the program, but then synchronize only the user data of wanted users, in this case only the user data of the user of the mobile device. This allows you to build secure applications, where users only see their own data, while at the same time using the powerful synchro-nization tools of the CouchDB.[8]

5 DISCUSSION 17

5 DISCUSSION

On the previous chapter, we went through the two different database solutions and their own paradigms. Also their fitment to the role of a database in mobile eHealth was exam-ined. SQL is an older database solution that has become an industry standard and the first database that people usually turn to because of its proven background. [6] CouchDB is a more modern platform developed recently and when it was designed the designs took into account the more recent developments in the use of mobile internet and the shift of accessing the internet through wired connections into access through mobile networks. [4] And as such it has incorporated into its design many features that were though to be out of scope of database solutions such as handling connectivity is-sues that were traditionally left to be solved by other means. CouchDB has added means of handling packet loss and connectivity directly into the database program, a feature the old databases also incorporated, but deemed to be not a critical part of the database stack.

The inclusion of these synchronization and offline handling properties into the solution makes CouchDB and based solutions easier to deploy in the mobile context as the programmer doesn't have to spend time implementing his own synchronization rou-tines that handle the unstable nature of mobile internet connections properly. The most lowest level of the connection handling is of course handled by the TCP /IP stack in both solutions, but the case of interrupted database synchronization, that for example copy the whole database, has to be handled by the programmer in an efficient way. CouchDB's integrated solution removes this.

Also as many applications in mobile devices are done with web technologies, us-ing integrated webviews to render the user interfaces from HTML and using javascript to manipulate it, the choice of javascript as the database query language makes interac-tion with the database easy as data does not have to be converted between languages, also improving security, by removing the possibility for standard SQL injection attacks.

There are however some costs that come associated with this. The multi version concurrency control in CouchDB causes the database to use up more space the longer it is used, if no compression routines are run regularly. Compression removes older ver-sions from the database, but has to be run by a separate process.

Also the way that the document is the atomic component might cause problems, as partial updates to large documents require the user to first download the whole docu-ment from the database, edit the changed part and commit the whole document back to the database. This might cause extra data traffic from the server, but can be avoided by

5 DISCUSSION 18

designing the document structures in such a way that all documents that are updated regularly are small.

All in all, the CouchDB and noSQL framework provides a fast and solid way to pro-duce eHealth systems using modern technologies for smart phones, making the tradi-tionally difficult synchronization and offline handling a breeze. This will help in the de-velopment of eHealth application which generally need data synchronization between a server and a client and the server typically has many users whose data has to be kept separate.

19

REFERENCES

[1] Tilastokeskus, ”Väestoennuste 2009-2060”, Available: http://www.stat.fi/til/vaenn/2009/vaenn_2009_2009-09-30_tie_001_fi.html

[2] J. Teperi, M. Porter, L. Vuorenkoski and J. Baron, ”The Finnish Health Care System: A Value-Based Perspective”, Sitra Reports 82, 2009

[3] J. Mitchell , ”Increasing the cost effectiveness of telemedicine by embracing e-health” , Journal of Telemedicine and Telecare 6: 19-19 , 2000

[4] Pricewaterhousecoopers Health Research Institute, ”Healthcare unwired, New business models delivering are everywhere”, Available: http://download.pwc.com/ie/pubs/2010_healthcare_unwired_new_business_models_delivering_care_anywhere_nov.pdf

[5] Massive Health, ”How we eat: analyzing ½ a million meals”, Available: http://blog.massivehealth.com/post/21377192742/how-we-eat-analyzing-half-a-million-meals

[6] Oracle, ”Top 10 Reasons to Choose MySQL for Web-based Applications”, Available: http://www.mysql.com/why-mysql/white-papers/

[7] Google, ”Android developer reference” , Available: http://developer.android.com/reference/packages.html

[8] J. C. Anderson , J. Lehmandt and N. Slater, ”CouchDB: The definitive Guide”, Available: http://guide.couchdb.org/index.html

[9] European Commission, ”eHealth Benchmarking III ” SMART 2009/0022

[10] B. C. Gold, S. Burke, S. Pintauro , P. Buzzell , J. Harvey-Berino , ”Weight Loss on the web: A pilot Study Comparing Structured Behavioural intent to a Commercial Program” , Obesity, 15: 155 , 2007

[11] J. Korhonen, “Introduction to 3G Mobile Communications”, 2003

[12] Oracle, “MySQL 5.5 Reference Manual” , Available: http://dev.mysql.com/doc/refman/5.5/en/

[13] HowtoForge, “How To set up Database Replication In MySQL” , Available: http://www.howtoforge.com/mysql_database_replication

[14] J. Dean and S. Ghemawat “MapReduce: Simplified Data Processing on Large Clusters”, Available: http://static.googleusercontent.com/external_content/untrusted_dlcp/research.google.com/en//archive/mapreduce-osdi04.pdf

Documents

HENRI TERHO USING NOSQL DATABASE SOLUTIONS IN MOBILE ... Terho.pdf · Keywords: mobile, android, noSQL, couchDB, eHealth In the coming future, the healthcare system will face severe