A methodology for no-coding switch across big data solutions

The exponential growth of data generated by an increasingly interconnected and expanding user base poses new challenges in storing, analysing and working with data. NoSQL (which stands for Not Only SQL) systems try to address those challenges by offering solutions focused on scalability, availability and fault tolerance, while at the same time trying to preserve the most of the advantages of traditional relational solutions. The NoSQL landscape is largely heterogeneous, presenting a great variety of features, data models, interrogation languages and each product favouring a combination of the above properties. Choosing the right database from the beginning is therefore a hard task, and not always a choice turns out to be the best one in the long term: it is difficult to forecast the evolution of the needs of a company or IT reality; moreover application requirements may change with time. A database change over the years is therefore a realistic scenario, but it is also a task that requires effort, resources and time; the purpose of this work is to present a general methodology to minimise these factors and allow for a database switch without having to change the code of the applications that rely on that database, that is one of the main concerns when facing data model variations. A database change without changing application code means migrating the existing data and developing a layer that performs live translation of queries. All these tasks are addressed and described by the methodology, whose purpose is to be generally applicable and not restricted to specif ic database types. Software engineering principles and best practices are a fundamental basis on which to develop and test a working middleware that is the final output of the methodology, of which a real world example is provided, together with a description of the implementation of a sample early version of a middleware and its testing process.

La crescita esponenziale della mole di dati generata da una base di utenti sempre più interconnessa e in espansione pone nuove sfide nell'archiviazione, analisi e utilizzo dei suddetti dati. I sistemi NoSQL, cioè Not Only SQL, non solo SQL, cercano di affrontare queste sfide offrendo soluzioni incentrate su scalabilità, disponibilità e tolleranza ai guasti e nello stesso tempo cercando di preservare la maggior parte dei vantaggi delle soluzioni relazionali più tradizionali. Il panorama dei database NoSQL è in gran parte eterogeneo, e presenta una grande varietà di caratteristiche, diversi modelli di dati e linguaggi di interrogazione e ogni prodotto favorisce un personale compromesso tra le tre proprietà sopra elencate. Scegliere il database più appropriato fin dall'inizio è quindi un compito arduo, e non sempre una scelta si rivela la migliore possibile nel lungo periodo: è difficile prevedere l'evoluzione delle esigenze di un'azienda o realtà informatica; in più i requisiti applicativi possono cambiare nel tempo in maniera imprevedibile. Dover cambiare database nel corso degli anni è quindi uno scenario realistico, ma è anche un compito costoso, che richiede risorse e tempo; lo scopo di questo lavoro è presentare una metodologia generale per minimizzare questi fattori e rendere possibile casmbiare database senza dover modificare il codice delle applicazioni che si basano su di esso, cosa che è una delle principali preoccupazioni nel momento in cui si decide di variare il modello dei dati. Cambiare database senza modificare il codice delle applicazioni significa prima migrare i dati esistenti salvati sul vecchio database e poi sviluppare un livello intermedio che esegua la traduzione in tempo reale delle query. La metodologia presentata analizza e affronta tali problemi, con lo scopo di essere applicabile a qualunque scenario senza fare riferimento a specifici tipi di database e produrre un middleware funzionante basandosi sui principi e sulle best practice dell'ingegneria del software. Ottenere un middleware funzionante è lo scopo finale della metodologia. di cui viene quindi fornito un esempio concreto di applicazione, insieme alla descrizione dell'implementazione e del testing della prima versione di un middleware per la traduzione a runtime tra due database key-value.