{"id":708,"date":"2021-05-07T08:51:00","date_gmt":"2021-05-07T06:51:00","guid":{"rendered":"https:\/\/brentasoft.com\/blog\/sql-vs-nosql-guida-2021\/"},"modified":"2021-05-07T08:51:00","modified_gmt":"2021-05-07T06:51:00","slug":"sql-vs-nosql-guida-2021","status":"publish","type":"post","link":"https:\/\/brentasoft.com\/blog\/sql-vs-nosql-guida-2021\/","title":{"rendered":"SQL vs NoSQL: come scegliere nel 2021"},"content":{"rendered":"<p>Quando si progetta una nuova applicazione, una delle decisioni architetturali pi\u00f9 importanti riguarda la scelta del database. <strong>SQL vs NoSQL<\/strong> \u00e8 un dibattito che dura da circa vent&#8217;anni e che, nel 2021, \u00e8 pi\u00f9 attuale che mai: i dati sono cresciuti in volume, variet\u00e0 e velocit\u00e0, e le architetture moderne richiedono spesso pi\u00f9 di un motore di persistenza.<\/p>\n<p>In questa guida vediamo le differenze concrete tra database relazionali e NoSQL, le quattro categorie di NoSQL, le propriet\u00e0 ACID e BASE, e soprattutto <em>quando conviene scegliere<\/em> l&#8217;uno o l&#8217;altro. L&#8217;obiettivo \u00e8 darti un quadro pratico per la prossima decisione tecnologica, senza dogmi e senza hype.<\/p>\n<h2>1. SQL vs NoSQL: il dibattito che dura da 20 anni<\/h2>\n<p>I database relazionali nascono negli anni Settanta con il modello di Edgar F. Codd e dominano l&#8217;IT enterprise per oltre trent&#8217;anni: Oracle, IBM DB2, Microsoft SQL Server, MySQL e PostgreSQL sono cresciuti insieme ai gestionali, agli ERP e ai portali web. Tutto si modellava in tabelle con chiavi primarie e foreign key, e SQL era <em>l&#8217;unico<\/em> linguaggio di interrogazione dei dati.<\/p>\n<p>Il termine &#8220;NoSQL&#8221; appare nel 2009 in un meetup di San Francisco organizzato da Johan Oskarsson. La spinta arriva dai grandi player del web (Google con Bigtable, Amazon con Dynamo, Facebook con Cassandra) che si trovano a gestire petabyte di dati distribuiti su migliaia di nodi: lo schema rigido del relazionale e i lock distribuiti diventano colli di bottiglia. Nascono cos\u00ec database progettati per <strong>scalare orizzontalmente<\/strong>, sacrificando alcune garanzie del modello relazionale.<\/p>\n<p>Nel 2021 la dicotomia &#8220;SQL contro NoSQL&#8221; \u00e8 ormai superata. Le aziende moderne usano <strong>entrambi i modelli<\/strong>: SQL per dati transazionali strutturati, NoSQL per cataloghi, sessioni, log, dati geospaziali e analitici. Il punto non \u00e8 &#8220;qual \u00e8 meglio&#8221; ma &#8220;qual \u00e8 il giusto per <em>questo<\/em> caso d&#8217;uso&#8221;.<\/p>\n<figure class=\"wp-block-image size-large\"><img fetchpriority=\"high\" decoding=\"async\" width=\"1880\" height=\"1253\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/sviluppatore-database-codice.jpg\" alt=\"Sviluppatore scrive query database al computer\" class=\"wp-image-710\" srcset=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/sviluppatore-database-codice.jpg 1880w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/sviluppatore-database-codice-300x200.jpg 300w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/sviluppatore-database-codice-1024x682.jpg 1024w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/sviluppatore-database-codice-768x512.jpg 768w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/sviluppatore-database-codice-1536x1024.jpg 1536w\" sizes=\"(max-width: 1880px) 100vw, 1880px\" \/><figcaption>Modellare i dati: il primo passo per scegliere tra SQL e NoSQL<\/figcaption><\/figure>\n<h2>2. Database relazionali (SQL): caratteristiche e quando funzionano<\/h2>\n<p>Un database relazionale organizza i dati in <strong>tabelle<\/strong> composte da righe e colonne. Ogni tabella ha uno <em>schema<\/em> definito a priori (quali colonne, quali tipi, quali vincoli) e le tabelle sono collegate tra loro tramite <strong>chiavi esterne<\/strong>. Il linguaggio standard per interrogarle \u00e8 SQL (Structured Query Language).<\/p>\n<p>I motori SQL leader nel 2021 sono:<\/p>\n<ul>\n<li><strong>MySQL 8<\/strong>: il pi\u00f9 diffuso al mondo, usato da WordPress, Magento, milioni di applicazioni PHP. Open source, controllato da Oracle.<\/li>\n<li><strong>PostgreSQL 13<\/strong>: il &#8220;relazionale plus&#8221; \u2014 supporta JSON nativo, full-text search, geospaziale (PostGIS), array, tipi custom. Oggi spesso preferito a MySQL nei nuovi progetti.<\/li>\n<li><strong>MariaDB 10.5<\/strong>: fork di MySQL nato dopo l&#8217;acquisizione da parte di Oracle, mantenuto dai creatori originali.<\/li>\n<li><strong>Microsoft SQL Server 2019<\/strong>: il riferimento in ambienti Windows enterprise, integrato con .NET e l&#8217;ecosistema Microsoft.<\/li>\n<li><strong>Oracle Database 19c<\/strong>: ancora dominante in banche, telco e grandi enterprise per i carichi pi\u00f9 critici.<\/li>\n<\/ul>\n<p>I database relazionali brillano quando i dati sono <strong>strutturati e relazionati<\/strong>: anagrafiche clienti, ordini, fatture, contabilit\u00e0, magazzino. La forza \u00e8 la <em>coerenza transazionale<\/em>: o tutta la transazione va a buon fine, o nessuna parte. Un bonifico bancario, un movimento contabile, una conferma d&#8217;ordine non possono mai trovarsi in stato intermedio.<\/p>\n<h2>3. Database NoSQL: le 4 categorie principali<\/h2>\n<p>&#8220;NoSQL&#8221; \u00e8 un&#8217;etichetta ombrello che raccoglie tecnologie molto diverse tra loro. La classificazione classica individua <strong>quattro categorie<\/strong>, ciascuna ottimizzata per un pattern di accesso ai dati specifico:<\/p>\n<ol>\n<li><strong>Document database<\/strong>: archiviano documenti JSON\/BSON con struttura flessibile. Esempi: MongoDB, CouchDB, RavenDB.<\/li>\n<li><strong>Key-value store<\/strong>: tabelle hash distribuite, semplici e velocissime. Esempi: Redis, Memcached, Amazon DynamoDB, Riak.<\/li>\n<li><strong>Column store<\/strong> (o wide-column): tabelle con colonne dinamiche, ottimizzate per scritture massive. Esempi: Apache Cassandra, HBase, ScyllaDB.<\/li>\n<li><strong>Graph database<\/strong>: nodi e archi con propriet\u00e0, ottimizzati per query relazionali profonde. Esempi: Neo4j, ArangoDB, Amazon Neptune.<\/li>\n<\/ol>\n<p>A queste si aggiungono i <em>search engine<\/em> come <strong>Elasticsearch 7<\/strong> (tecnicamente document-oriented ma ottimizzato per ricerca full-text) e i <em>time-series database<\/em> come InfluxDB, ottimizzati per metriche e telemetria. Nel 2021, secondo il <a href=\"https:\/\/db-engines.com\/\" target=\"_blank\" rel=\"noopener\">DB-Engines Ranking<\/a>, MongoDB \u00e8 il NoSQL pi\u00f9 popolare seguito da Redis, Elasticsearch e Cassandra.<\/p>\n<h2>4. Document database (MongoDB, CouchDB)<\/h2>\n<p>I document database memorizzano i dati come <strong>documenti BSON o JSON<\/strong>, ciascuno con una struttura potenzialmente diversa. Niente schema rigido, niente tabelle, niente JOIN: un documento pu\u00f2 contenere array, oggetti annidati, valori opzionali.<\/p>\n<p><strong>MongoDB 4.4<\/strong> \u00e8 il leader incontrastato di questa categoria. Tipico esempio: un catalogo prodotti e-commerce dove ogni articolo ha attributi diversi (un divano ha dimensioni e tessuto, uno smartphone ha CPU e RAM). In SQL servirebbero tante tabelle figlie o una tabella EAV ingombrante; in MongoDB ogni prodotto \u00e8 un documento autocontenuto.<\/p>\n<pre><code>{\n  \"_id\": ObjectId(\"60a...\"),\n  \"sku\": \"DIV-001\",\n  \"nome\": \"Divano Milano 3 posti\",\n  \"prezzo\": 899.00,\n  \"categoria\": \"Soggiorno\",\n  \"attributi\": {\n    \"tessuto\": \"tessuto sfoderabile\",\n    \"colori\": [\"beige\", \"grigio\", \"blu\"],\n    \"dimensioni\": { \"lunghezza\": 220, \"profondita\": 95 }\n  }\n}<\/code><\/pre>\n<p>MongoDB scala orizzontalmente con lo <em>sharding<\/em> e dalla versione 4.0 supporta transazioni multi-documento (anche se a un costo prestazionale). \u00c8 particolarmente adatto a CMS headless, cataloghi prodotti, profili utente con campi variabili, applicazioni mobile-first. Lo abbiamo usato in diversi progetti di <a href=\"https:\/\/brentasoft.com\/soluzioni\/web-app-pwa.php\">web app e PWA<\/a> dove i dati lato client sono naturalmente JSON.<\/p>\n<p>CouchDB, sviluppato da Apache, \u00e8 meno diffuso ma ha un punto di forza unico: la replica multi-master con risoluzione conflitti, ottima per applicazioni offline-first che si sincronizzano quando tornano online.<\/p>\n<h2>5. Key-value store (Redis, DynamoDB)<\/h2>\n<p>Il modello key-value \u00e8 il pi\u00f9 semplice: una mappa hash distribuita dove ogni chiave punta a un valore. Niente query complesse, niente JOIN, ma <strong>letture e scritture in microsecondi<\/strong>.<\/p>\n<p><strong>Redis 6<\/strong> \u00e8 probabilmente il database pi\u00f9 amato dai developer: tiene tutti i dati in RAM (con persistenza opzionale su disco) e supporta strutture dati avanzate oltre alle stringhe \u2014 liste, set, hash, sorted set, stream, bitmap. Casi d&#8217;uso classici:<\/p>\n<ul>\n<li><strong>Cache applicativa<\/strong>: alleggerire il carico sul DB principale memorizzando i risultati delle query pi\u00f9 frequenti.<\/li>\n<li><strong>Sessioni utente<\/strong>: storage rapido per i token di login, soprattutto in architetture stateless.<\/li>\n<li><strong>Code di lavoro<\/strong>: con Redis Streams o Pub\/Sub si implementano message broker leggeri.<\/li>\n<li><strong>Rate limiting<\/strong>: contatori atomici per limitare le chiamate API per utente\/minuto.<\/li>\n<li><strong>Leaderboard e ranking<\/strong>: i sorted set sono perfetti per classifiche real-time.<\/li>\n<\/ul>\n<p><strong>Amazon DynamoDB<\/strong> \u00e8 il key-value (pi\u00f9 precisamente key-value\/document) gestito di AWS: pensato per applicazioni con miliardi di record che richiedono latenze di pochi millisecondi a qualsiasi scala. Il prezzo si paga in flessibilit\u00e0 delle query: bisogna progettare le chiavi di partizione con attenzione, perch\u00e9 modificarle dopo \u00e8 doloroso.<\/p>\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" width=\"1880\" height=\"1255\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/database-server-rack.jpg\" alt=\"Rack di server con luci blu in data center NoSQL\" class=\"wp-image-711\" srcset=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/database-server-rack.jpg 1880w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/database-server-rack-300x200.jpg 300w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/database-server-rack-1024x684.jpg 1024w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/database-server-rack-768x513.jpg 768w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/database-server-rack-1536x1025.jpg 1536w\" sizes=\"(max-width: 1880px) 100vw, 1880px\" \/><figcaption>I database NoSQL distribuiti sono progettati per scalare orizzontalmente<\/figcaption><\/figure>\n<h2>6. Column store (Cassandra, HBase)<\/h2>\n<p>I column store invertono la prospettiva: invece di memorizzare le righe in modo contiguo, memorizzano le <strong>colonne<\/strong>. Ogni &#8220;riga&#8221; (in realt\u00e0 una <em>partizione<\/em>) pu\u00f2 avere colonne diverse, e le colonne sono il vero &#8220;elemento atomico&#8221; di archiviazione.<\/p>\n<p><strong>Apache Cassandra 4<\/strong> nasce in Facebook e oggi \u00e8 gestita dalla Apache Software Foundation. La sua architettura \u00e8 <em>masterless<\/em>: non esiste un nodo primario, tutti i nodi sono equivalenti, e il cluster sopravvive alla caduta di interi datacenter. \u00c8 progettato per <strong>scritture massive<\/strong> e disponibilit\u00e0 elevatissima.<\/p>\n<p>Casi d&#8217;uso tipici:<\/p>\n<ul>\n<li><strong>Log e telemetria<\/strong>: miliardi di eventi al giorno scritti senza saturare il sistema.<\/li>\n<li><strong>Time series IoT<\/strong>: misurazioni da sensori distribuiti che devono essere accumulate rapidamente.<\/li>\n<li><strong>Dati di tracking<\/strong>: clickstream, eventi di gioco, telemetria di app mobile.<\/li>\n<li><strong>Sistemi di messaggistica<\/strong>: WhatsApp, Discord e Netflix usano Cassandra in produzione.<\/li>\n<\/ul>\n<p>HBase \u00e8 la versione &#8220;Hadoop-native&#8221; del modello column store, modellata sul Bigtable di Google. \u00c8 la scelta tipica quando si lavora gi\u00e0 nell&#8217;ecosistema Hadoop\/HDFS per analitica big data.<\/p>\n<h2>7. Graph database (Neo4j, ArangoDB)<\/h2>\n<p>I graph database modellano i dati come un vero e proprio <strong>grafo<\/strong>: nodi (entit\u00e0) collegati da archi (relazioni), entrambi con propriet\u00e0. Sono la risposta giusta quando le <em>relazioni<\/em> tra entit\u00e0 sono importanti tanto quanto le entit\u00e0 stesse.<\/p>\n<p>Provate a fare una query del tipo &#8220;trovami tutti gli amici degli amici dei miei amici che lavorano in aziende dove ho lavorato anch&#8217;io&#8221; su un database SQL: servono JOIN multipli, ricorsione, performance pessime. In <strong>Neo4j<\/strong> con il linguaggio Cypher \u00e8 una query di poche righe che si esegue in millisecondi anche su grafi di milioni di nodi.<\/p>\n<p>Casi d&#8217;uso classici per i graph database:<\/p>\n<ul>\n<li><strong>Social network<\/strong>: amici, follower, gruppi, mention.<\/li>\n<li><strong>Sistemi di raccomandazione<\/strong>: &#8220;chi ha comprato X ha comprato anche Y&#8221; attraversando connessioni multi-hop.<\/li>\n<li><strong>Antifrode<\/strong>: identificare reti sospette di transazioni e identit\u00e0 collegate.<\/li>\n<li><strong>Gestione della conoscenza<\/strong>: ontologie, knowledge graph, dipendenze tra concetti.<\/li>\n<li><strong>Catena di approvvigionamento<\/strong>: tracciare componenti e fornitori a pi\u00f9 livelli di profondit\u00e0.<\/li>\n<\/ul>\n<p>ArangoDB \u00e8 interessante perch\u00e9 \u00e8 multi-modello: supporta documenti, key-value e grafo nello stesso motore, riducendo la complessit\u00e0 di gestire pi\u00f9 database.<\/p>\n<h2>8. ACID vs BASE: le propriet\u00e0 dei database<\/h2>\n<p>Una delle distinzioni pi\u00f9 importanti tra SQL e NoSQL riguarda le garanzie sulle transazioni. I database relazionali rispettano tradizionalmente le propriet\u00e0 <strong>ACID<\/strong>:<\/p>\n<ul>\n<li><strong>Atomicity<\/strong>: la transazione \u00e8 &#8220;tutto o niente&#8221;.<\/li>\n<li><strong>Consistency<\/strong>: dopo la transazione il database \u00e8 in uno stato valido (vincoli rispettati).<\/li>\n<li><strong>Isolation<\/strong>: transazioni concorrenti non si vedono tra loro.<\/li>\n<li><strong>Durability<\/strong>: una volta committato, il dato non si perde anche in caso di crash.<\/li>\n<\/ul>\n<p>Molti NoSQL, soprattutto quelli distribuiti, adottano invece il modello <strong>BASE<\/strong>:<\/p>\n<ul>\n<li><strong>Basically Available<\/strong>: il sistema risponde sempre, anche se con dati non aggiornati.<\/li>\n<li><strong>Soft state<\/strong>: lo stato del sistema pu\u00f2 cambiare nel tempo senza input esterni (riconciliazione).<\/li>\n<li><strong>Eventual consistency<\/strong>: dopo un certo tempo, tutti i nodi convergono allo stesso valore.<\/li>\n<\/ul>\n<p>Il motivo di questa rinuncia \u00e8 il <strong>teorema CAP<\/strong> di Eric Brewer: in un sistema distribuito non si possono garantire contemporaneamente Consistency, Availability e Partition tolerance. Bisogna sceglierne due. I database SQL classici scelgono CA (rinunciano alla scalabilit\u00e0 orizzontale), molti NoSQL scelgono AP (preferendo la disponibilit\u00e0 alla coerenza immediata).<\/p>\n<p>Nel 2021 questa distinzione \u00e8 meno netta: PostgreSQL ha cluster con replica logica, MongoDB supporta transazioni ACID, Cassandra ha &#8220;linearizable&#8221; su singola partizione. Ma il <em>baricentro<\/em> di ogni motore resta diverso, e va capito prima di scegliere.<\/p>\n<p>Un esempio concreto del trade-off: in un sistema di prenotazione voli volete <strong>consistency stretta<\/strong> \u2014 non potete vendere lo stesso posto due volte, anche se questo significa che a volte un utente vede uno spinner di caricamento. In un social network, invece, preferite l&#8217;<strong>availability<\/strong> \u2014 \u00e8 meglio mostrare un feed leggermente vecchio che un errore &#8220;servizio non disponibile&#8221;. Capire dove si colloca il vostro caso d&#8217;uso su questo asse \u00e8 il primo passo della decisione architetturale.<\/p>\n<p>Vale anche la pena ricordare che i moderni motori SQL come PostgreSQL hanno introdotto livelli di isolamento configurabili (Read Committed, Repeatable Read, Serializable) e tipi di replica diversi (sincrona, asincrona, logica). Anche all&#8217;interno di &#8220;ACID&#8221; ci sono molte sfumature, e capire i parametri di tuning del proprio database \u00e8 spesso pi\u00f9 importante della scelta del database stesso.<\/p>\n<h2>9. Quando scegliere SQL (i casi tipici)<\/h2>\n<p>Optate per un database relazionale quando si verifica una o pi\u00f9 di queste condizioni:<\/p>\n<ol>\n<li><strong>I dati sono strutturati e stabili nel tempo<\/strong>. Un&#8217;anagrafica clienti, un piano dei conti, un magazzino con SKU codificati: lo schema cambia poco e quando cambia \u00e8 un evento gestito.<\/li>\n<li><strong>Le relazioni sono molte e importanti<\/strong>. Un ERP gestisce ordini collegati a clienti, righe d&#8217;ordine a prodotti, prodotti a fornitori, movimenti contabili a partite IVA. SQL \u00e8 nato per questo.<\/li>\n<li><strong>Servono transazioni multi-tabella ACID<\/strong>. Una vendita aggiorna magazzino, partitario, registro IVA, contabilit\u00e0: o tutto o niente.<\/li>\n<li><strong>I report aggregati sono frequenti<\/strong>. SUM, GROUP BY, JOIN su milioni di righe sono il pane quotidiano di SQL e dei suoi indici.<\/li>\n<li><strong>Il volume non \u00e8 &#8220;web scale&#8221;<\/strong>. Sotto le decine di TB e qualche migliaio di transazioni al secondo, un PostgreSQL ben configurato basta e avanza.<\/li>\n<li><strong>Il team conosce SQL<\/strong>. \u00c8 un linguaggio diffusissimo, e l&#8217;ecosistema di tool (ORM, BI, backup, monitoring) \u00e8 maturo da decenni.<\/li>\n<\/ol>\n<p>I tipici <a href=\"https:\/\/brentasoft.com\/soluzioni\/gestionali-personalizzati.php\">gestionali personalizzati<\/a> per PMI italiane \u2014 gestione produzione, magazzino, fatturazione, presenze \u2014 vengono ancora oggi quasi sempre costruiti su MySQL o PostgreSQL, con ottime ragioni.<\/p>\n<h2>10. Quando scegliere NoSQL (i casi tipici)<\/h2>\n<p>Considerate un NoSQL quando una o pi\u00f9 di queste condizioni sono vere:<\/p>\n<ol>\n<li><strong>Schema variabile o evolutivo<\/strong>. Cataloghi prodotti con attributi diversi, profili utente con campi che cambiano spesso, dati provenienti da fonti eterogenee.<\/li>\n<li><strong>Volumi enormi e crescita rapida<\/strong>. Log, eventi, telemetria IoT, clickstream: parliamo di miliardi di righe scritte al giorno.<\/li>\n<li><strong>Latenza minima richiesta<\/strong>. Cache di sessione, leaderboard di gioco, autocomplete di ricerca: serve risposta in pochi millisecondi.<\/li>\n<li><strong>Distribuzione geografica<\/strong>. Un servizio mondiale che deve essere veloce su pi\u00f9 continenti scala meglio con DynamoDB, Cassandra o Cosmos DB.<\/li>\n<li><strong>Modello del dominio nativamente JSON<\/strong>. API REST, frontend React, app mobile lavorano in JSON: passare da JSON a tabelle e viceversa \u00e8 puro overhead.<\/li>\n<li><strong>Pattern di accesso &#8220;uno a molti&#8221; semplici<\/strong>. Recuperare il profilo dell&#8217;utente X, le ultime 50 notifiche, il carrello attivo: chiamate dirette per chiave, senza JOIN complessi.<\/li>\n<\/ol>\n<p>Un&#8217;applicazione che gestisce contenuti generati dagli utenti, che si integra via <a href=\"https:\/\/brentasoft.com\/soluzioni\/integrazione-api.php\">integrazione API<\/a> con servizi esterni e che deve scalare in cloud nasce spesso con un mix di Postgres + MongoDB + Redis. Le moderne <a href=\"https:\/\/brentasoft.com\/soluzioni\/software-cloud.php\">soluzioni cloud<\/a> rendono questo mix gestibile senza dover amministrare server.<\/p>\n<figure class=\"wp-block-image size-large\"><img decoding=\"async\" width=\"1880\" height=\"1255\" src=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/analisi-dati-database.jpg\" alt=\"Monitor con grafici di analisi dati e database\" class=\"wp-image-713\" srcset=\"https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/analisi-dati-database.jpg 1880w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/analisi-dati-database-300x200.jpg 300w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/analisi-dati-database-1024x684.jpg 1024w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/analisi-dati-database-768x513.jpg 768w, https:\/\/brentasoft.com\/blog\/wp-content\/uploads\/2021\/05\/analisi-dati-database-1536x1025.jpg 1536w\" sizes=\"(max-width: 1880px) 100vw, 1880px\" \/><figcaption>Analisi e reportistica: SQL eccelle nelle aggregazioni, NoSQL nei volumi<\/figcaption><\/figure>\n<h2>11. Architetture polyglot persistence (uso ibrido)<\/h2>\n<p>Il termine <strong>polyglot persistence<\/strong> \u00e8 stato coniato da Martin Fowler nel 2011 e descrive un&#8217;architettura dove ogni microservizio (o ogni tipo di dato) usa il database pi\u00f9 adatto al proprio scopo. Nel 2021 \u00e8 la norma nelle architetture moderne.<\/p>\n<p>Esempio concreto di un&#8217;app e-commerce:<\/p>\n<ul>\n<li><strong>PostgreSQL<\/strong> per ordini, fatture, anagrafica clienti, contabilit\u00e0: serve ACID e relazioni forti.<\/li>\n<li><strong>MongoDB<\/strong> per il catalogo prodotti con attributi variabili e contenuti CMS.<\/li>\n<li><strong>Redis<\/strong> per il carrello attivo, le sessioni utente, il rate limiting delle API.<\/li>\n<li><strong>Elasticsearch<\/strong> per la ricerca prodotti full-text con filtri faccettati.<\/li>\n<li><strong>Neo4j<\/strong> per il motore di raccomandazione &#8220;chi ha comprato X ha comprato Y&#8221;.<\/li>\n<li><strong>InfluxDB<\/strong> per le metriche di business (ordini\/ora, conversioni, latenze).<\/li>\n<\/ul>\n<p>Sembra complicato \u2014 e in parte lo \u00e8 \u2014 ma ognuno di questi motori risolve un problema specifico molto meglio degli altri. Le architetture <a href=\"https:\/\/brentasoft.com\/blog\/microservizi-vs-monolite-guida-2021\/\">a microservizi<\/a> rendono questa separazione naturale: ogni servizio \u00e8 proprietario del suo database, e l&#8217;integrazione passa attraverso API o eventi.<\/p>\n<p>Nei progetti di <a href=\"https:\/\/brentasoft.com\/blog\/sviluppo-software-custom-pmi-quando-conviene\/\">sviluppo software custom per PMI<\/a> il polyglot persistence va dosato con attenzione: per una piccola realt\u00e0 avere sei motori di database in produzione significa sei sistemi di backup, monitoring, aggiornamento, formazione del team. Spesso PostgreSQL + Redis \u00e8 gi\u00e0 un ottimo &#8220;polyglot light&#8221; che copre il 90% dei casi.<\/p>\n<p>Una euristica pragmatica che usiamo nei nostri progetti:<\/p>\n<ul>\n<li><strong>Fase 0-1 (MVP)<\/strong>: un solo database. Quasi sempre PostgreSQL, perch\u00e9 copre relazionale, JSON, full-text, geospaziale. Aggiungere complessit\u00e0 quando non serve \u00e8 il modo migliore per non arrivare in produzione.<\/li>\n<li><strong>Fase 2 (crescita)<\/strong>: aggiungete Redis quando le query iniziano a saturare il DB principale e vi servono sessioni o cache. \u00c8 un&#8217;aggiunta a basso rischio.<\/li>\n<li><strong>Fase 3 (scala)<\/strong>: introducete il database giusto quando avete un problema misurato. Elasticsearch quando la ricerca SQL non basta, MongoDB quando avete dati con schema realmente variabile, una time-series db quando le metriche pesano sul DB transazionale.<\/li>\n<\/ul>\n<p>L&#8217;errore opposto, cio\u00e8 non introdurre mai NoSQL &#8220;perch\u00e9 tanto SQL basta&#8221;, \u00e8 altrettanto comune. Un team che usa MySQL come cache di sessione, come coda di lavoro e come motore di ricerca full-text sta portando un cacciavite per piantare chiodi. Riconoscere il momento in cui il polyglot diventa necessario \u00e8 una skill chiave del CTO.<\/p>\n<h3>Costi infrastrutturali a confronto<\/h3>\n<p>Spesso la scelta \u00e8 anche economica. Considerando un carico medio di una PMI nel 2021 (qualche milione di record, qualche centinaio di transazioni al secondo), i costi mensili indicativi sono:<\/p>\n<ul>\n<li><strong>PostgreSQL self-hosted<\/strong> su VPS 4 vCPU 16 GB: ~50-80 \u20ac\/mese.<\/li>\n<li><strong>MySQL su AWS RDS<\/strong> db.t3.medium con backup: ~80-120 \u20ac\/mese.<\/li>\n<li><strong>MongoDB Atlas<\/strong> M10: ~60 \u20ac\/mese.<\/li>\n<li><strong>Redis Cloud<\/strong> 250 MB: gratuito o ~5 \u20ac\/mese; cluster reali da ~50 \u20ac\/mese.<\/li>\n<li><strong>Elasticsearch Service<\/strong>: parte da ~95 \u20ac\/mese.<\/li>\n<\/ul>\n<p>Aggiungere un secondo motore raddoppia i costi infrastrutturali e moltiplica la complessit\u00e0 operativa. Va fatto solo se la complessit\u00e0 ripagata \u00e8 proporzionale.<\/p>\n<p>Per approfondire ulteriormente, la voce dedicata su <a href=\"https:\/\/it.wikipedia.org\/wiki\/NoSQL\" target=\"_blank\" rel=\"noopener\">Wikipedia (NoSQL)<\/a> offre un buon riepilogo storico e tassonomico delle famiglie di database non-relazionali.<\/p>\n<h2>12. Domande frequenti (FAQ)<\/h2>\n<p><strong>NoSQL significa &#8220;no SQL&#8221; o &#8220;not only SQL&#8221;?<\/strong><br \/>\nOriginariamente &#8220;no SQL&#8221; (rifiuto del modello relazionale), poi rebrandizzato in &#8220;not only SQL&#8221; per indicare la coesistenza con i relazionali. Oggi molti NoSQL hanno un dialetto SQL-like (CQL di Cassandra, N1QL di Couchbase).<\/p>\n<p><strong>MongoDB sostituisce MySQL?<\/strong><br \/>\nNo. Sono progettati per scopi diversi. MongoDB brilla con dati semi-strutturati e schema flessibile; MySQL con dati transazionali strutturati. Spesso convivono nello stesso progetto.<\/p>\n<p><strong>Posso fare JOIN in MongoDB?<\/strong><br \/>\nDalla 3.2 esiste l&#8217;operatore <code>$lookup<\/code> in aggregazione, ma \u00e8 meno performante dei JOIN SQL. La filosofia MongoDB \u00e8 &#8220;modella i tuoi dati per come li interroghi&#8221;, quindi spesso si denormalizza embeddando documenti.<\/p>\n<p><strong>Quanto costa un database NoSQL gestito?<\/strong><br \/>\nMongoDB Atlas parte da ~9 $\/mese per cluster condiviso, AWS DynamoDB ha un free tier di 25 GB e modello pay-per-request, Redis Cloud parte gratuito fino a 30 MB. Per produzioni serie pianificate qualche centinaio di euro al mese minimo.<\/p>\n<p><strong>I database NoSQL sono &#8220;schema-less&#8221;?<\/strong><br \/>\nTecnicamente s\u00ec, ma in pratica uno schema c&#8217;\u00e8 sempre \u2014 \u00e8 solo gestito a livello applicativo invece che dal motore. Con MongoDB si usa spesso uno strato come Mongoose (Node.js) per validare la struttura.<\/p>\n<p><strong>Conviene migrare da SQL a NoSQL?<\/strong><br \/>\nSolo se ci sono problemi concreti che SQL non risolve (volume, schema rigido, latenza, distribuzione globale). Migrare per &#8220;modernit\u00e0&#8221; senza un caso d&#8217;uso reale \u00e8 spesso un boomerang.<\/p>\n<div style=\"background:#f5f7fa;border-left:4px solid #0066cc;padding:20px;margin:30px 0;border-radius:4px;\">\n<h3 style=\"margin-top:0;\">Stai progettando un&#8217;applicazione e devi scegliere il database?<\/h3>\n<p>Brentasoft sviluppa applicazioni custom per PMI italiane usando database SQL (MySQL, PostgreSQL) e NoSQL (MongoDB, Redis), in architetture monolitiche o polyglot.<\/p>\n<p style=\"margin-bottom:0;\"><a href=\"https:\/\/brentasoft.com\/erp-brenta.php\" style=\"display:inline-block;background:#0066cc;color:#fff;padding:12px 24px;border-radius:4px;text-decoration:none;font-weight:600;\">Scopri ERP Brenta &rarr;<\/a><\/p>\n<\/div>\n","protected":false},"excerpt":{"rendered":"<p>SQL vs NoSQL: scopri come scegliere il database giusto nel 2021. Guida pratica per CTO PMI a relazionali, MongoDB, Redis e architetture polyglot.<\/p>\n","protected":false},"author":2,"featured_media":709,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_seopress_robots_primary_cat":"","_seopress_titles_title":"SQL vs NoSQL: come scegliere nel 2021","_seopress_titles_desc":"SQL vs NoSQL nel 2021: guida pratica per CTO PMI italiane. Database relazionale vs NoSQL, MongoDB vs MySQL, ACID vs BASE, polyglot persistence.","_seopress_robots_index":"","footnotes":""},"categories":[9],"tags":[296,415,411,412,410,413,414,179],"class_list":["post-708","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-guide-e-tutorial","tag-architettura-software","tag-database","tag-mongodb","tag-mysql","tag-nosql","tag-postgresql","tag-redis","tag-sql"],"_links":{"self":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/708","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/comments?post=708"}],"version-history":[{"count":0,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/posts\/708\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media\/709"}],"wp:attachment":[{"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/media?parent=708"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/categories?post=708"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/brentasoft.com\/blog\/wp-json\/wp\/v2\/tags?post=708"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}