Una breve panoramica dei database

Le licenze software sono a dir poco complesse. Non si tratta solo dei diritti di proprietà intellettuale (per questo, suggerisco di consultare "An Introduction to the Law and Economics of Intellectual Property" di Besen & Raskind e Open Source Licensing: Software Freedom and Intellectual Property Law di Rosen), ma in particolare del perché dovresti preoccuparti di una licenza e delle tendenze nel panorama dei database open source con implicazioni per il tuo business.

Siete pronti?

Per prima cosa, parliamo di licenze

Tutte le licenze software contengono regole e regolamenti da rispettare sull'utilizzo della tecnologia. Ciò significa che le licenze del software che adotti possono avere un impatto tangibile sul tuo business. Ignorare o violare queste regole può esporti a rischi legali, perdite finanziarie e, di fatto, rovinare la reputazione della tua azienda. Che si acquisti un software o si adottino tecnologie open source, la licenza limiterà in qualche modo l'utilizzo del codice. Devi quindi essere consapevole di questi vincoli mentre sviluppi il tuo prodotto, al fine di mitigare il rischio legale nel lungo periodo.

Successivamente, tieni presente che le licenze non sono fisse. Di fatto, in questo momento, molte aziende che supportano progetti di database open source stanno modificando le licenze dei loro database per renderle più restrittive. A seconda del tuo caso d'uso, ciò potrebbe significare che, se hai utilizzato un database gratuitamente, ora potresti essere esposto ad azioni legali. Non c'è motivo per spaventarsi, tuttavia bisogna rimanere vigili. Via via che si verificano questi cambiamenti, è importante reagire in modo adeguato. In alcuni casi, una modifica della licenza può richiedere la riprogettazione di un servizio, l'adozione di un database diverso o la sottoscrizione di un accordo commerciale con il fornitore.

Esploriamo un po' di più questo spazio problematico

Chi frequenta Hacker News o TechCrunch non sarà estraneo alla conversazione sui software di database open source e commerciali. In breve, negli ultimi tre anni è scoppiato un dibattito a causa di una confluenza di fattori, come la crescita dei principali fornitori di cloud pubblico e il successo sul mercato, o la sua mancanza, dei fornitori di database orientati all'open source.

Detto questo, il rapporto tra il software libero e il software proprietario non è binario, bensì si tratta di uno spettro:

Nota: la distanza illustrata non è scientifica, la relatività è più importante.

Guardando lo spettro in alto, all'estrema sinistra, ci sono licenze commerciali o proprietarie per software di database come Oracle, IBM Db2 e Microsoft SQL Server. Si tratta di tecnologie potenti e ricche di caratteristiche che alimentano i workload in ogni settore verticale. Quando acquisti questo software da un fornitore o come servizio cloud, paghi di più per avere accesso a quanto segue:

• Supporto a livello di codice

• Un solido ecosistema di strumenti

• Servizi professionali e consulenti

• Visibilità e influenza nella roadmap di quel database

Sulla destra, c'è il software di pubblico dominio. Questo software non è soggetto a copyright, il che significa che può essere modificato, distribuito o venduto senza restrizioni. I progetti all'estrema destra dello spettro sono spesso regolati dagli standard di una terza parte imparziale, come la Apache Software Foundation o The Linux Foundation.

L'Open Source Initiative (OSI) mantiene un elenco generalmente accettato di cosa è e cosa non è una licenza open source. In generale, il software open source è caratterizzato dalla possibilità di "forkare il codice". Questo significa che, se la direzione del progetto (software) è in contrasto con ciò di cui necessiti o che desideri, puoi modificare il codice come meglio credi.

L'uso di una tecnologia open source è particolarmente interessante grazie all'azzeramento dei costi di licenza, alla maggiore trasparenza dello sviluppo e all'innovazione che deriva da una diversità di stakeholder, manutentori e aree problematiche. Rispetto al software commerciale, con il software open source si rinuncia all'influenza sulla roadmap, alle garanzie relative alle correzioni dei bug, alle patch di sicurezza e ai contratti, non c'è alcun blocco da fornitore e la flessibilità aziendale è migliorata. (Come puoi vedere, si tratta di un compromesso che tu e il tuo team dovete valutare attentamente.)

Seguendo il percorso illustrato nel grafico qui sopra da sinistra a destra, ci sono diversi livelli di permissività delle licenze, come Apache 2.0, MPL e GPL 3.0.

Esempi di database mappati alle licenze

• Apache 2.0: Apache Cassandra, Apache CouchDB

• Mozilla Public License: RabbitMQ

• BSD: Redis

• GPL 3.0: Neo4j

• Proprietario: IBM Db2, Microsoft SQL Server

Un po' di storia per il contesto

Alla fine degli anni 2000, la maggior parte dei nascenti fornitori di database stava entrando nel mercato come "open source", al fine di ottenere un facile accesso all'adozione e alla condivisione mentale degli sviluppatori. Potresti conoscere aziende in questo campo, come Mongo Inc., Redis Labs ed Elastic. Queste aziende hanno sviluppato progetti comunitari come MongoDB, Redis ed Elasticsearch, ma hanno cercato di monetizzare tale investimento con versioni Enterprise License, implementazioni cloud gestite o servizi professionali.

Tuttavia, il cambio di paradigma del cloud computing ha reso questo modello di business precario, perché i vendor più importanti possono facilmente fornire queste tecnologie come servizio gestito nativo e di alto livello della piattaforma. Queste offerte vengono fornite con integrazioni convincenti per la sicurezza, la conformità, il monitoraggio e la registrazione sui rispettivi cloud, senza fornire un compenso garantito ai creatori del software.

Negli ultimi anni le aziende hanno rivalutato il loro percorso verso il mercato. Ora li vediamo adottare modelli di licenza che proteggono i loro investimenti di sviluppo. Ad esempio, MongoDB, Redis Labs e Confluent, con diversi gradi di gravità, hanno tutti modificato le licenze di porzioni di codice per impedire ad altre società di eseguirle come servizio senza ottenere un compenso.

"Quindi, Josh, qual è il tuo consiglio?" Ottima domanda.

Ci sono buone ragioni per usare sia database commerciali che open source. La cosa importante è che tu sappia in cosa ti stai cacciando, tu e la tua azienda. Studia bene la licenza prima di creare un'applicazione, per assicurarti che il tuo progetto sia conforme; se invece stai cercando una licenza per un progetto open source, consulta la pagina web "Choose a License" di Github.
Quindi, una considerazione importante è quella delle licenze, perché nessuno vuole finire in tribunale. L'altro riguarda le famiglie di modelli di dati, ma per un motivo diverso. Quando si crea un'applicazione, conoscere i tipi di modello di dati consente di scegliere lo strumento giusto per il lavoro da svolgere.

Ora che hai una certa padronanza delle licenze, parliamo di un’altra considerazione critica nella scelta del tuo database: i modelli di dati.

Quando ho iniziato a lavorare in IBM, avevo bisogno di aggiornarmi velocemente, quindi mi sono rivolto a NoSQL Distilled di Martin Fowler.

Nei suoi scritti, e nel settore in generale, le persone tendono a classificare i database in cinque famiglie di “modelli di dati”: documento, chiave-valore, grafico, relazionale e a colonne larghe. Ecco una rapida panoramica di ciascuno di essi, inclusi casi d’uso ed esempi specifici del database. Questo ti aiuterà a determinare, in base ai tuoi set di dati e alle esigenze aziendali, di quale database necessiti.

1. Documento

In questo caso, i dati vengono modellati in documenti di tipo JSON, anziché in righe e colonne. Questi database, per natura, privilegiano la disponibilità rispetto alla coerenza transazionale. I database di documenti si prestano alla semplicità e alla scalabilità, nonché alla rapida iterazione nello sviluppo.

Casi d’uso aziendali:

• App per dispositivi mobili che richiedono iterazioni rapide

• Registrazione degli eventi, acquisti online, gestione dei contenuti ed elaborazione analitica approfondita

• Cataloghi retail con caratteristiche dei prodotti

Esempi:

• MongoDB

• Apache CouchDB

• Firebase

2. Chiave-valore 

Questo tipo di modello rappresenta il tipo più elementare di database non relazionale, in cui ogni elemento del database è memorizzato come nome di attributo (denominato “chiave”) con il suo valore corrispondente.

Casi d’uso aziendali:

• Data store delle preferenze e dei profili degli utenti

• Consigli sui prodotti in base ai dati di navigazione

• Carrelli degli acquisti

Esempi:

• DynamoDB

• Redis

• etcd

3. Grafico

I dati qui sono modellati come vertici ed edge (valori e connessioni). Analogamente al modo in cui le persone pensano ed elaborano le informazioni, i database a grafi richiamano le relazioni tra unità discrete di dati. Questi database rendono più intuitiva la persistenza, l’esplorazione e la visualizzazione dei dati e delle relazioni.

Casi d’uso aziendali:

• Rilevazione di frodi

• Motori di raccomandazioni in tempo reale

• Master Data Management

• Operazioni di rete e IT

• Gestione di identità e accessi

Esempi:

• Neo4j

• JanusGraph

• AWS Neptune

4. Relazionale 

Il modello relazionale , introdotto da R.F. Codd mentre lavorava per IBM, è il titano del settore. I dati sono memorizzati in tabelle sotto forma di righe e colonne e spesso dispongono di sofisticati motori di query per l’analytics e l’esplorazione. I database relazionali supportano le garanzie transazionali e la conformità ACID (atomicità, consistenza, isolamento e durata), mentre la maggior parte dei database delle altre quattro famiglie sono alla fine coerenti.

Casi d’uso aziendali:

• E-commerce

• Pianificazione delle risorse aziendali

• Gestione delle relazioni con i clienti

Esempi:

• PostgreSQL

• IBM Db2

5. A colonne larghe

Le famiglie di colonne consentono un accesso molto rapido ai dati utilizzando una chiave di riga, il nome della colonna e il timestamp della cella. Lo schema flessibile di questi tipi di database significa che le colonne non devono essere uniformi tra i record ed è possibile aggiungere una colonna a righe specifiche senza doverle aggiungere a ogni singolo record. I data store a colonna larga derivano dal documento BigTable di Google. Questi modelli di dati non devono essere confusi con i modelli di storage orientati alle colonne, che sono più rilevanti per le tecnologie di data warehousing e ai modelli di accesso analitici, grazie alla migliore compressione dei dati su disco e all’uso più efficiente della CPU.

Casi d’uso aziendali:

• Analisi della sicurezza e del mercato azionario

• Analytics clickstream

• IoT e telemetria

Esempi:

• Apache Cassandra

• DataStax Enterprise

• Google Cloud BigTable

Il punto è che ci sono vantaggi e svantaggi per ogni modello di dati primari (e qui abbiamo appena scalfito la superficie). Tuttavia, in caso di dubbio, scegli qualcosa di collaudato e molto diffuso come PostgreSQL. Per ulteriori informazioni sull’archetipo delle famiglie di modelli di dati, leggi il libro NoSQL Distilled di Martin Fowler, in particolare i capitoli 8-11.

Pronto per saperne ancora di più sui database?

Bene! Ho coperto un po’ di terreno qui, ma se non vedi l’ora di saperne di più, ecco alcuni suggerimenti basati sull’investimento di tempo:

• 15 minuti: “How to Choose a Database” di Ben Anderson

• 15 minuti: “SQL vs. NoSQL Databases: What’s the Difference?” di Ben Anderson e Brad Nicholson

• Tre ore: l’analisi di Jepsen sulla sicurezza dei sistemi distribuiti

• Una settimana: Designing Data-Intensive Applications di Martin Kleppman.

Vuoi iniziare a creare? IBM Cloud offre un’ ampia gamma di servizi di database gestiti per aiutare il tuo team ad agire velocemente.