Perché addottare un database NoSQL

Una carrellata delle caratteristiche principali dei DB NoSQL per spazzare via lo scetticismo

In ambito tecnologio le rivoluzioni sono inevitabili. E’ impensabile credere di poter continuare a lavorare per sempre come abbiamo fatto fino ad adesso. Il cambiamento è parte del mestiere dell’informatico e va accolto a braccia aperte, senza preconcetti. Tuttavia bisogna sempre essere attenti a investire nella tecnologia giusta; perché il cambiamento deve essere in meglio.

Nella mia esperienza ho avuto che fare con due tipologie di persone opposte :

  1. “entusiasti”: quelli che si buttano incondizionatamente su tutto quello che è nuovo e dichiarano il resto come obsoleto prima ancora di aver approfondito con esperienze reali dove si sono buttati.
  2. “conservatori”: quelli che il cambiamento proprio non lo vedono di buon occhio. Non vogliono uscire dalla propria zona di comfort e rinunciano alle opportunità innovative per continuare a lavorare nello stesso modo.

I due esempi sono sicuramente degli estremi, ma ci sono persone molto polarizzate verso l’una o l’altra fazione. Come sempre l’approccio migliore è quello di buon senso che sta nel mezzo. Per poter decidere è importante conoscere le tecnologie che si vogliono adottare almeno quanto basta per capire come funzioneranno in un caso d’uso reale. Proiettare un qualcosa che non conosciamo in un progetto reale non è semplice, ma con un po’ di fantasia e tanta esperienza è possibile prevenire gli errori più grossolani. L’approccio “trial on the job” è una cattiva abitudine che porta spesso a dover finire i progetti come sono stati iniziati  e quando ti accorgi a metà lavoro che stai facendo le cose al contrario non è semplice portare a termine il progetto (mica avrete intenzione di raccontare al committente che avete sbagliato tutto?).

Questo stesso principio si applica anche al mondo NoSQL. Avendo studiato le tecnologie NoSQL possiamo valutarne i pro e i contro e valutarne l’impatto per i progetti che dobbiamo realizzare. Il problema non è quello di iniziare a cambiare le proprie abitudini e rinunciare alle nostre certezze (relazioni, transazioni, schema, SQL, …) ma piuttosto capire cosa serve nel nostro progetto.

Studiare, capire, impiegare: la natura del progresso tecnlogico richiede di essere pronti al cambiamento.

Perché dovrei preferire un db NoSQL?

Come già detto in altri articoli, i database NoSQL non sono dei sostituti dei database tradizionali. Come gli altri memorizzano dati, e in molte applicazioni possono raggiungere gli stessi risultati, ma stiamo parlando di cose diverse. Nella maggior parte dei casi la soluzione ottimale e far lavorare le due tecnologie insieme per prendere i vantaggi di entrambe. Di sicuro quando c’è di mezzo una di queste situazioni, NoSQL è molto utile:

  • progetto che ha bisogno di scalare, in termini di utenti e funzionalità
  • tanti dati, ma proprio tanti…
  • quando non ci sono ( e probabilmente non ci saranno) report o la parte analitica sui dati è poca cosa
  • quando l’applicativo ha una necessità verticale soddisfatta da un RDBMS (es. cache con Redis)

Quanto guadagno in termini di performance impiegando database NoSQL?

Dipende dal caso specifico è difficile dare un’indicazione universale. Da un lato abbiamo i vantaggi legati alle prestazioni del sistema NoSQL, dall’altro i limiti introdotti dalla mancanza di JOIN che impattano molto in dataset limitati. Una stima realistica, ma da prendere come indicativa, è che il passaggio a NoSQL porti un incremento di performance da un fattore 10 a 100. Questo però non è facilmente comparabile in termini di esperienza finale perché impiegando sistemi di cache o altri accorgimenti applicativi si riesce a mitigare la lentezza del backend verso l’utilizzatore finale (cache, network delay, page rendering).

Per chiarire con un esempio immaginiamo una pagina web che legge dati e li stampa a video Assumiamo che questa pagina impieghi 500ms per effettuare una query su un sistema tradizionale e 50ms su un NoSQL. L’incremento di performance a livello di dati è significativo, ottenendo una diminuzione dei tempi del 90% circa. Per l’utente finale come cambia l’esperienza? Ipotiziamo 200ms come tempo di rendering e 1s per il download della pagina sul browser a casusa di una cattiva connessione. Il tempo complessivo passa da 1700ms a 1250ms, con un vantaggio di soli 450ms su 1700 (-26%). Questo esempio ci fa capire come i miglioramenti di performance a livello di db non si ripercuotano in percentuale uguale sull’utente. Inoltre, inserendo un meccanismo di cache, potremmo migliorare le performance senza cambiare database. Questo ci conferma che l’applicativo può compensare la lentezza del backend. L’importante è non pensare di risolvere i problemi di design applicativo cambiando base dati.

I sistemi NoSQL sono abbastanza maturi per essere usati in produzione?

Si, i sistemi NoSQL sono pronti per essere usati. Ovviamente ci sono tanti vendor e tante soluzioni, quindi la risposta vale solo per le soluzioni di mercato principali, meglio se hanno un vendor alle spalle che garantisce continuità negli aggiornamenti e bugfix. Non tutti i progetti richiedono il NoSQL tra i loro requisiti e in pochi necessitano di performance straordinarie. Il mercato del SaaS e alcune applicazioni aziendali critiche sì, ma nell’esperienza quotidiana la dimensione delle tabelle è spesso limitata ( è difficile trovare tante tabelle sopra 100K di righe in un db) e il bisogno di consistenza e relazioni preponderante.  La domanda corretta, quindi, non è tanto se il NoSQL è pronto per andare in produzione, ma piuttosto se la vostra applicazione è pronta per il NoSQL

I sistemi SQL sono obsoleti?

No. I sistemi NoSQL sono semplicemente sistemi alternativi. Quando l’uomo ha inventato l’aeroplano, ha smesso di utilizzare l’automobile? No, semplicemente sceglie il mezzo di trasporto più opportuno sulla base del tragitto che deve compiere. Allo stesso modo l’architetto software sceglierà il back end più funzionale per l’applicativo che sta progettando. ì

Il mercato è pronto per i sistemi NoSQL?

Sì e no. Mentre in molti ambiti è già una tecnologia assodata, in ambito aziendale il cambiamento è spesso visto con diffidenza dal management. Non solo per lo scetticismo verso quello che non si conosce ma anche per dover formare le risorse e rivoluzionare il processo di sviluppo.

 

Quale è la soluzione migliore?

Non esistono formule matematiche che vi dicano cosa fare. “Dipende” è l’unica risposta che funziona sempre.  Dipende dal progetto, da come evolverà, da chi ci dovrà lavorare, ma soprattutto dall’architetto e dalla sua capacità di valutazione.

danielefontani

Actually CTO in Sintra Consulting s.r.l, I'm senior developer and architect specialized on portals, intranets, and others business applications. Particularly interested in Agile developing and open source projects, I worked on some of this as project manager and developer. My experience include: Frameworks \Technlogies: .NET Framework (C# & VB), ASP.NET, Java, php, Spring Client languages: XML, HTML, CSS, JavaScript, Angular.js,Angular. jQuery Platforms: Sharepoint,Liferay, Drupal Databases: MSSQL, ORACLE, MYSQL, Postgres

Lascia un commento