La scelta del database giusto per la tua azienda può essere un compito arduo e dispendioso in termini di tempo, in particolare per i malcapitati.

Mentre si è tentati di implementare un sistema con la mentalità di spuntare semplicemente una casella necessaria, sta diventando sempre più importante che le organizzazioni scelgano un database specializzato per le proprie esigenze.

Con questo in mente, ci siamo seduti con Randal Hoff, VP presso la società di database Faircom, per scoprire cosa deve accadere nel processo decisionale.

TechRadar Pro: come si identifica il database giusto per le esigenze di un'azienda?

Randal Hoff: Il primo passo è capire le esigenze della tua azienda e valutare il volume e il tipo di dati che stai cercando di estrarre, archiviare e analizzare.

Durante questo passaggio, è importante notare se si dispone di origini dati che sono confinate in database e applicazioni legacy. A volte questo tipo di dati è stato sviluppato usando COBOL e altri linguaggi di codifica venerabili, che possono rendere piuttosto difficile il processo di estrazione.

Tuttavia, la comprensione dell'intero ambito dei dati che saranno inclusi nel progetto è un contesto vitale per le decisioni aziendali e deve essere raccolto prima di determinare quale database (o database e piattaforme) è adatto alle proprie esigenze.

TRP: Allo stesso tempo, è anche necessario fare un brainstorming sui bisogni futuri dell'azienda. Come saranno gestite e modificate le architetture di database in base all'evolversi delle esigenze aziendali e alla necessità di mantenerle?

RH: Un fattore critico è garantire il supporto per le API standard, fondamentali per l'integrazione di database e archivi dati con altre applicazioni aziendali.

Sviluppare il supporto per le API, in particolare quando alcuni archivi di dati sono bloccati all'interno di applicazioni legacy che non supportano le moderne API, può essere un compito arduo poiché a volte possono richiedere sforzi di modernizzazione su piattaforme legacy.

Allo stesso tempo, esistono pratiche esistenti che supportano la modernizzazione senza sostituire completamente le applicazioni legacy. Esistono database specializzati nel portare avanti i dati legacy con il minimo sforzo e rischio, come ad esempio c-treeACE di FairCom.

TRP: In quali circostanze è vantaggioso integrare sia SQL che NoSQL?

RH: Ovviamente hai bisogno dello strumento giusto per il lavoro giusto, ma a volte il semplice concetto di guardare al futuro renderà chiaro se NoSQL, SQL o l'integrazione di entrambi è giusto per te.

NoSQL è diventato un'architettura popolare per la gestione di grandi volumi di dati, perché possono essere più efficienti per quanto riguarda la potenza di elaborazione richiesta per gestire file di grandi dimensioni.

Allo stesso tempo, è importante considerare se i dati che verranno archiviati devono supportare la coerenza immediata dei dati. Inoltre, vorrete chiedervi: quanto è fondamentale l'applicazione e il database correlato?

Un problema che alcune aziende affrontano quando lavorano con i big data non strutturati è che molti database NoSQL Open Source non sono compatibili con Atomicity, Consistency, Isolation and Durability (ACID) e non possono supportare la persistenza in tempo reale. Di conseguenza, questa mancanza di conformità ACID può causare dati non sincronizzati e incoerenti.

Inoltre, SQL è in genere il linguaggio go-to per i report di business intelligence e l'analisi approfondita e SQL potrebbe non essere facilmente supportato con implementazioni NoSQL.

Mentre lo scopo iniziale per i dati, strutturati o non strutturati, può richiedere una soluzione NoSQL per le prestazioni, lo stesso set di dati potrebbe essere necessario per analisi più strutturate e report di business intelligence più tardi, che è dove il supporto SQL può essere un buon vantaggio.

Piuttosto che limitare la scelta architettonica del database a un database NoSQL o SQL, un approccio più prudente potrebbe essere quello di considerare i database che supportano un'integrazione NoSQL + SQL, per mantenere le opzioni aperte in futuro.

Distribuire un'architettura di database che pianifica l'integrazione successiva di NoSQL + SQL offre agli ingegneri maggiore flessibilità e controllo, fornendo un modo per estrarre, archiviare e gestire i dati utilizzando il ridotto overhead di NoSQL, ma fornendo la possibilità di aggiungere funzionalità SQL quando necessario.