Diploma Thesis Santiago GÃ³mez SÃ¡ez - IAAS

More documents

Recommendations

Info

2. Fundamentals 2.10.1. Key-value Databases In a key-value datastore elements are uniquely identified by an id, which the data store does not take into account its type, and are simply stored as a Binary Large Object (BLOB) . A user can get the value for the key, put a value for the key, or delete a key from the data store [SF12]. Its storage model can be compared to a map/dictionary [Str]. Products offering this data storage model in a Cloud infrastructure are Amazon DynamoDB [Amaa], Google Cloud Storage [Gooc], Amazon SimpleDB [Amae] , Amazon S3 [Amad], etc. In this diploma thesis we mainly focus on the following key-value data stores: DynamoDB, and Google Cloud Storage. Amazon DynamoDB’s data model includes the following concepts: tables, items, and attributes [Amaa]. The attributes are a key-value, where the value is binary data. Attributes are stored in items, and these are stored in tables. Items stored in a table can be retrieved by referencing its unique id. The number of attributes is not limited by Amazon, but each item must have a maximum size of 64 KB. Accessing stored data in this data store can be mainly done in two ways: using the functionalities provided by the AWS SDK, or using the Cloud storage RESTful API. Google Cloud Storage’s data model includes the following concepts: buckets and objects [Gooc]. Buckets contain on or more objects. The objects are identified within a bucket with its unique id. Users can perform I/O operations on both buckets and objects. For this purpose, Google Cloud storage provides RESTful API. In this diploma thesis we use an ESB for accessing transparently tenant’s databases migrated to the Cloud. Servicemix-mt provides multi-tenant HTTP support [Sá12]. Therefore, we reuse and extend the multi-tenant HTTP BC in order to provide dynamic routing between the different data stores. 2.10.2. Document Databases Document databases can be considered as a next step in improving the key-value storage model. In this storage model, documents are stored in the value part of the key-value store, making the value content examinable [SF12]. Documents with different schemas are supported in the same collection, and can be referenced by the collection’s key or by the document’s attributes. One of the main difference in the attributes specification regarding RDBMS is that in document stores document’s attributes cannot be null. When there is an attribute without value, the attribute does not exist in the document’s schema. Products implementing this data storage model are Apache CouchDB, MongoDB, etc. [Thea] [10G]. Mongo DB defines two storage structures: collections and documents [10G]. A specific database contains one or more collections identified by its unique id. A specific collection stores one or more documents. Collections and documents stored in a database can be accessed, inserted and modified using the RESTful API supported by the database system. 24
2.11. JBIMulti2 Apache CouchDB defines two storage structures: databases and documents. Data stored in CouchDB are JavaScript Object Notation (JSON) documents. The main difference between this two described databases is that MongoDB implements a two step access to the documents: database, collection, and document. Apache CouchDB provides a RESTful API for I/O operations. This databases are not offered by Cloud providers like Amazon or Google, but as a software which can be deployed in user instances, e.g. Amazon EC2 AMI [Amab]. 2.10.3. Column-family Stores One of the most known Column-family data stores is Cassandra. Column-family data stores store data in column families (groups of related columns which are often accessed together) as rows that have many columns associated with a row key [SF12]. This approach allows to store and process data by column instead of by row, providing a higher performance when accessing large amount of data, e.g. allowing the application to access common accessed information in less time. Cassandra has as its smallest unit of storage the column, which consists of a timestamp and a name-value pair where the name acts as a key [SF12]. As in the relational model, a set of columns form up a row, which is identified by a key. A column family is a collection of similar rows. The main difference with the relational model is that each of the rows must not have the same columns, allowing the designer and the application consuming large amounts of data to customize the columns in each row, and the rows in each column family. Cassandra is not shipped with a RESTful API for I/O operations. However, there are several open-source services layers for Cassandra, e.g. Virgil [Thed]. 2.11. JBIMulti2 A multi-tenant management system must fulfill several requirements, such as data and performance isolation between tenants and users, authentication, specification of different user roles, resources usage monitoring, etc. In a JBI environment, endpoint and routing configurations files are packed in SUs, and the latter in SAs for deployment. However, there is a lack of user-specific data during deployment. Muhler solves this problem in JBIMulti2 by injecting tenant context in the SA packages, making them tenant-aware [Muh12]. The architecture of the JBIMulti2 system is represented in Figure 2.7. We can distinguish two main parts in the system: business logic and resources. JBIMulti2 uses three registries for storing configuration and management data. When a tenant (or a tenant user) is registered, an unique identification number is given to them and stored in the Tenant Registry. Both Tenant Registry and Service Registry are designed for storing data of more than one deployed application. The former for storing tenant information and the latter for providing a dynamic service discovery functionality between the different applications accessed through the ESB. 25
Page 1: Institute of Architecture of Applic
Page 5 and 6: Contents 1. Introduction 1 1.1. Pro
Page 7 and 8: Contents 7.3.3. Evaluation Analysis
Page 9 and 10: List of Figures 1.1. Migration Scen
Page 11 and 12: List of Tables 4.1. Description of
Page 13: List of Listings 5.1. Tenant-aware
Page 16 and 17: 1. Introduction and multi-protocol
Page 18 and 19: 1. Introduction Definitions List of
Page 20 and 21: 1. Introduction • Implementation,
Page 22 and 23: 2. Fundamentals usage of it. PaaS p
Page 24 and 25: 2. Fundamentals 2.2.1. Enterprise S
Page 26 and 27: 2. Fundamentals through the network
Page 28 and 29: Management Framework Component Fram
Page 30 and 31: 2. Fundamentals corresponding works
Page 32 and 33: 2. Fundamentals the tenant level, b
Page 34 and 35: 2. Fundamentals 2.9. Structured Que
Page 36 and 37: 2. Fundamentals 2.9.2. PostgreSQL D
Page 40 and 41: 2. Fundamentals User Interface Web
Page 42 and 43: 28 2. Fundamentals
Page 44 and 45: 3. Related Works and balancing the
Page 46 and 47: 3. Related Works store may contain
Page 48 and 49: 3. Related Works In the second plac
Page 50 and 51: 4. Concept and Specification VM0 or
Page 52 and 53: 4. Concept and Specification then f
Page 54 and 55: 4. Concept and Specification 4.3. D
Page 56 and 57: 4. Concept and Specification 4.6. U
Page 58 and 59: 4. Concept and Specification Name G
Page 60 and 61: 4. Concept and Specification Name G
Page 62 and 63: 4. Concept and Specification 4.8.3.
Page 64 and 65: 5. Design stores have two main stor
Page 66 and 67: 5. Design userId serviceName XMLNam
Page 68 and 69: 5. Design received in the vendor’
Page 70 and 71: 5. Design JBI SA into an OSGi conta
Page 72 and 73: 5. Design Apache Camel provides a s
Page 74 and 75: 5. Design External Application Lege
Page 76 and 77: 5. Design External Application Exte
Page 78 and 79: 6. Implementation the bundle activa
Page 80 and 81: 6. Implementation each of the queri
Page 82 and 83: 6. Implementation multi-tenancy awa
Page 84 and 85: 6. Implementation The HTTP endpoint
Page 86 and 87: 6. Implementation stored. Both auth
Page 88 and 89:
74 6. Implementation
Page 90 and 91:
7. Validation and Evaluation We mus
Page 92 and 93:
7. Validation and Evaluation When t
Page 94 and 95:
7. Validation and Evaluation in the
Page 96 and 97:
1. Introduction 1. Introduction 7.
Page 98 and 99:
7. Validation and Evaluation proble
Page 100 and 101:
7. Validation and Evaluation access
Page 102 and 103:
8. Outcome and Future Work The func
Page 104 and 105:
90 8. Outcome and Future Work
Page 106 and 107:
Appendix A. Components A.2. CDASMix
Page 108 and 109:
94 Appendix A. Components
Page 110 and 111:
Appendix B. Messages 20 - target da
Page 112 and 113:
Appendix B. Messages 110 111 - OK r
Page 114 and 115:
Appendix B. Messages 1 interface: l
Page 116 and 117:
102 Appendix B. Messages
Page 118 and 119:
Bibliography [CC06] F. Chong and G.
Page 120 and 121:
Bibliography [SAS + 12] [SBK + 12]
Page 122 and 123:
Acknowledgement I am heartily thank
show all

Diploma Thesis Santiago GÃ³mez SÃ¡ez - IAAS

Create successful ePaper yourself

Delete template?

Save as template?