Methodology For Solving Data Portability In Cloud

Published Date: 02 Nov 2017

Abstarct: Cloud computing has become a new trend in IT industry which greatly helps smaller organizations to more concentrate on their core components rather than on Infrastructural issues. But the main challenge customers are facing in Cloud is vendor-lock-in. Customer applications are Cloud vendor centric due to performance and security reasons. If user want to migrate from one service provider to another then it became almost daunting task especially data portability between cloud providers. Cloud databases provide immediate access high availability and scalability to data stored in cloud to users. Due to this we came up with a Methodology which can port data from relational database to non-relational document oriented database using SQONGO. 

Cloud Computing become a promising and popular technology in computer science field from last few years. All scale enterprises are willing to adapt cloud computing technologies to existing software due to the benefits of cloud. Cloud Computing is nothing but the providing hosted services (software/hardware) using computing resources on demand based through the Internet by service providers and billing the resources based on resources usage. Services provide by cloud are Platform as a Service (PaaS), Software as a Service (SaaS) and Infrastructure as a Service (IaaS) will deploy in various cloud models like Public Private and Hybrid. According to NIST[1] the essential characteristics of Cloud computing is on-demand self-service, broad network access, resource pooling, rapid elasticity or expansion, and measured service. Due to this solitary characteristics various IT enterprises adapting Cloud technologies and developing applications convenient to their environment and providing services to customers especially data management in cloud. For this cloud vendors developing their own data models for data management in cloud. Cloud providers like Microsoft and Google developed Azure and Big data models. But each data management model having their unique purpose and Architecture like Big data for large data analysis and MongoDB for content management and Azure for managing large data in cloud. Based on their requirement cloud vendors are developing their own data management models. But initially there are two different data management models in cloud like SQL (Relational) and NoSQL models.

The acrostic for NoSQL[2] means not quiet against the relational database it means 'Not only SQL'. NoSQL is useful where relational database doesn't process large kind of data, which is having inter relations between elements, NoSQL never use SQL for processing quires. But most of the NoSQL databases are designed well for working in Horizontally scalable and not depend on highly available hardware we can easily scale up and scale down the hardware resources for maintain these databases. NoSQL databases are categorized into 4 four basic types’ key values stores (applications to store its data in key-value pair ex Amazon Dynamo DB[3]), column family stores (Store and process data by column instead of row ex Google Big table[4]), Document oriented database (Data is stored in documents which are addressed by unique keys ex MongoDB[5]) and graph database (Store the data in the form of nodes relations between nodes and properties of the nodes ex Neo4J[6]).

Data portability[7] is where applications data be easily moved and reused between various cloud providers. The essential requirement for Data portability in Cloud is to avoid Vendor lock-in, operational cost reduction and dissatisfaction with existing provider.

A Methodology[12] is usually a guideline system for solving a problem, with specific components such as phases, tasks,  methods, techniques and tools. Methodology doesn't discuss specific mechanism for solving problem instead kind of process applied to achieve the objective.

This paper is organized as follows: Section 2 describes our Literature survey.Section 3 evaluates the Motivation to solve the problem. Section 4 describes the proposed solution and Implementation, Experimental results presented in Section 5. Final Conclusion of this paper in Section 6.

II. Literature survey

Cloud computing interoperability forum(CCIF)[8] came up with a standard of unified cloud interface/Cloud resource broker[9]. The purpose of this cloud resource broker is to act as a common interface for platforms networks and data. This unified cloud interface is to acts like a common API for all the APIs. Enterprise Cloud Orchestration Platform /Orchestration layer[10] in this cloud providers register their services in Cloud Orchestration layer it will select and assign to services based on criteria and requirement. But in both the approaches applications are not directly interact with the resource's APIs but heavily depend on vendor provided storage services. The open cloud computing interface(OCCI)[12] is standardized interfaces for managing cloud infrastructure and compute resources, but implementation wise very few open source private clouds like OpenNebula and EUCALYPTUS only implemented. There are several excellent projects which are working on data portability in cloud using various strategies. Mahdi Negahi Shirazi[6] design patterns to enable data portability between column family databases and graph databases. Zach Hill and Marty Humphrey[13] CSAL which can provides Blob, Table, and Queue abstractions across multiple cloud providers. But all the research is going on portability between NoSQL databases. But very few research papers discussing about the data migration towards NoSQL Cloud storage from relational databases. Now a days each major cloud provider developing their own data storage models for data storage and maintenance like Google Big data(Column oriented database) and Amazon Dynamo db ( Key-value pair). suppose a customer of Google want to shift from Google Bigdata to Amazon S3 storage become difficult task customer itself have to convert whole data from one format to another, to avoid this situation we came up with a methodology based on semi structural model approach which can convert relational database to document oriented database using SQONGO nothing but MySQL to mongo database using SQONGO. This SQONGO acts as a middleware interface between relational database (MySQL) and NoSQL data storage (document oriented data store MongoDB).

III. Motivation

Cloud Computing is the latest IT buzz word for dynamic cloud infrastructure offered by many organizations. One of the main advantage of cloud computing is that it is paid for service basis which reduces the high initial infrastructure investment and maintenance. Due to the advantages of Cloud computing many small scale organizations which are working on demand based are moving towards Cloud for cost reduction high availability and scalability.

But the main challenging issues in Cloud are Regulatory compliance, lack of standards in Portability and interoperability. The lack of standards impose obstacles to recovering the data for cloud customers migrating from one Cloud service provider to another, this will create the vendor lock-in problem in cloud.

Due to the rapid growth of social networking web sites Cloud storage become a emerging trend. Organizations like Facebook, Twitter are coming with new data models for managing their data which create problem to the customers who wants to migrate from one service provider to another(Facebook user wants to migrate his data Twitter vice versa) and the performance benefits of document oriented databases in storing maintaining and updating larger documents especially blog posts and it's comments are motivated us to create a new methodology for data portability between relational data bases to document oriented databases using SQONGO.

IV. Implementation

The implementation of SQONGO is like a plug-in and plug-off model, it's just like running a program in the system. The major implementation issue in SQONGO is converting database tables from MySQL data storage to MongoDB document oriented collections using semi structured model. For converting data from MySQL we consider intermediate format is a json(Java Script Object Notation) to leverage the json format stored the table values along with table schema information using dictionaries.

All Blob and Text storage is handled using binary files. Blob (Binary large object storage) is used for storing large set of Binary data like images and etc, in MySQL. Migrating blob storage from MySQL to semi structured model we used file structural model and GridFS[11] store. For achieving this we have to convert all blob data field to binary files and we have to dump all these binary files into GridFS store. GridFS will divide stored file into parts/chunks and store each chunk into separate document. When we query for a file in GridFS store driver will reassemble the chunks for processing. We can follow same method for storing text data type in MySQL. We used Python GTK for generating Graphical user interface for SQONGO.

V. Experimental results

The implementation of SQONGO was done in UBUNTU 12.04 and programming language used was python 3.0 and databases MySQL 5.0 and MongoDB 1.2.x. Figure 1 represents the GUI of SQONGO.

Figure :GUI of SQONGO

Initial Combo box gives all the existing databases in MySQL server and we have to select the database from drop down menu and table combo box shows existed tables in selected database. We have to select the MySQL table from the list for migration. Database entry in second row for entering the database name of MongoDB and collection entry for entering collection name in Mongo, after filling all the details we have to start the start migrate button event for migrating the given table from MySQL to database to MongoDB collection shown in figure 2.

Figure :Database selection for conversion

Figure3 Indicates the employee table with employee[14] details and working experience etc in MySQL data base.

Figure :Employess Database table

corresponding Collection generated from SQONGO tool was represented in figure 4.

Figure :SQONGO generated data

In document oriented data store data will be stored in document format which is more suitable for programming structures which one makes easier for programming either object oriented or structured. Due to the most scalable nature of document oriented database all the data needed in single document, so no need for joins and multi-object transactions. Document oriented databases provide rich set of quires and map-reduce functions. Due to the increasing distributed nature of applications and storage document oriented database get prominence but these all are not meant for document oriented database is more suitable in cloud environments due to drawbacks which can overcome with relational databases like ACID compliance and data integrity issues.

VI. Conclusion and Future work

One of the vital challenging task in Cloud computing is portability and the standards are yet to be evolved to solve the portability issues in Cloud. We came up with a Methodology using semi structural model which can solve the data portability between relational data base and document oriented database with SQONGO tool. Due to the rich set of functions like handling large data sets and scalability we chosen document oriented data storage. But from our experiments what we observed that is there is no proper replacement for relational data base with document oriented data storage because of ACID properties and integrity issues. But for distributed environment mainly cloud environments maintaining horizontal scalability with document oriented data storage is more flexible and easier compared to relational data storage. In future we want to extend this tool for providing application portability between open source private clouds like OpenStack and eucalyptus using semantic technology based middleware abstraction layer .