Interoperable data migration between NoSQL columnar databases

With the advent of Web2.0 applications, the amount of user generated content is growing exponentially. Moreover, the increasing number of people using web services, together with more stringent service level expectations, have led to the adoption of approaches able to grant fault tolerance, availability and scalability. Hence, in order to handle very huge amount of data and granting, at the same time, all of the above requirements, NoSQL databases have emerged. The most relevant NoSQL databases combine approaches and solutions, relative to the distributed systems theory, to provide different properties and characteristics. Each of them proposes different data models and architectures. Hence, based on the type of problem that needs to be solved, a certain database may be more suitable than another. Several attempts have been made in order to categorize NoSQL databases, but there is not yet a commonly accepted categorization. This is mainly due to the lack of standards for NoSQL databases. Hence, when developing an application, one should have a clear vision of all NoSQL solutions. Given the number of existing databases, it may be difficult to make the right choice in the first place. Furthermore, new requisites may arise during application development. If the effects of a poor database choice become evident, switching to another database may be problematic in terms of costs and time. This problem is known as vendor lock-in and, in order to mitigate it, this thesis proposes an interoperable migration system for NoSQL databases. In particular, we focus on columnar NoSQL databases and define an orginal metamodel that allows to transfer data among this class of databases. The proposed metamodel is designed in such a way to preserve different levels of consistency, secondary indexes and different data types, during migration. Moreover, we develop an extensible system which allows developers to easily add support for new databases, without requiring any knowledge about the other databases. For this reason, guidelines about the implementation of proper database translators are provided, together with examples of how to support Key-Value databases too.

Con l'avvento delle applicazioni Web2.0, la quantità di contenuti generati dagli utenti sta crescendo esponenzialmente. Inoltre, il maggiore utilizzo di web services, in concomitanza con una migliore aspettativa di livelli di servizio, hanno portato all'adozione di approcci atti a garantire maggiore tolleranza ai guasti, availability e scalabilità. Dunque, per far fronte a moli enormi di dati e garantire, al contempo, i requisiti di cui sopra, si è cominciato a far uso di database NoSQL. I più noti, tra questi, utilizzano tecniche e soluzioni proprie della teoria dei sistemi distribuiti, al fine di fornire caratteristiche e proprietà differenti. Infatti, ognuno di questi si contraddistingue per un data model ed una architettura differente. Dunque, in base al problema da risolvere, un certo database può risultare più adatto di un altro. Diversi tentativi per classificare i vari database NoSQL sono stati fatti, tuttavia non vi è ancora una categorizzazione comunemente accettata. Ciò è dovuto principalmente alla mancanza di uno standard per questi database. Dunque, all'atto dello sviluppo di una applicazione, si dovrebbe avere una chiara visione circa il panorama dei database NoSQL. Ma, dato il numero di essi, può essere difficile fare da subito una scelta corretta. Inoltre, nuovi requisiti potrebbero emergere durante la fase di sviluppo. Quando gli effetti di una scelta errata del database si manifestano, potrebbe essere problematico, in termini di tempi e costi, effettuare un cambiamento. Questo problema è noto come vendor lock-in e, al fine di porvi rimedio, in questo lavoro di tesi si descrive un sistema interoperabile per la migrazione di dati tra database NoSQL. In particolare, ci si concentra sui database a colonne, e si definisce un metamodello originale che permette di migrare dati tra database di questo tipo, ed anche Key-Value. Il metamodello proposto è progettato in modo da preservare diversi livelli di consistenza, indici secondari e tipi di dato. Inoltre, si descrive lo sviluppo di un sistema di migrazione estensibile, che permette agli sviluppatori di supportare nuovi database, senza che questi necessitino di conoscere il funzionamento degli altri.