Le 7 principali considerazioni da fare quando si valuta un database NoSQL
1) Introduzione
2) Modello di dati
3) Modello di interrogazione
4) Coerenza e Modello transazionale
5) API
6) Piattaforma dati
7) Dati mobili
8) Considerazioni Finali
In alcuni casi nello sviluppo di web applications il passaggio ad un sistema ibrido con parte dell’applicazione su database SQL ed un’altra su database NoSql diventa fondamentale. Vuoi per velocizzare le ricerche full-text, vuoi per mantenere una serie di dati disponibili in modo da interrogarli con grande rapidità ed in tutta un’al tra serie di casi. Conoscere quali sono le caratteristiche di database NoSQL diventa allora fondamentale. Non è secondario tenere presente su quale framework è sviluppata l’applicazione che usufruirà della ricerca, ad esempio Laravel fornisce nativamente degli strumenti utili all’integrazione di alcuni servizi.
Introduzione
La più grande sfida che le organizzazioni devono affrontare è lavorare con i dati:
- Le richieste di maggiore produttività e tempi di commercializzazione più rapidi sono frenate da rigidi modelli di dati relazionali che non corrispondono al codice moderno e impongono complessi interdipendenze tra i team di ingegneri.
- Le organizzazioni non sono in grado di lavorare con, ed estrarre informazioni da, massicci aumenti del dati nuovi e in rapida evoluzione strutturati, semi-strutturati e polimorfici generati dalle applicazioni di oggi.
- I database legacy monolitici e fragili inibiscono il passaggio all’ingrosso ai sistemi distribuiti e il cloud computing che offre la resilienza e la scalabilità di cui le aziende hanno bisogno, rendendolo più difficile per soddisfare i nuovi requisiti normativi per la privacy dei dati.
- I carichi di lavoro transazionali, analitici, di ricerca e mobili precedentemente separati stanno convergendo per creare applicazioni avanzate e customer experience ricche e basate sui dati.
- Tuttavia, ogni carico di lavoro tradizionalmente è stato alimentato dal proprio database, creando silos di dati duplicati cuciti insieme a fragili pipeline ETL accessibili da diverse API per sviluppatori.
Per affrontare queste limitazioni, sono state introdotte diverse alternative non tabulari ai database relazionali la considerazione imposta. Generalmente indicati come database NoSQL, questi sistemi scartano molto fondamento che ha reso i database relazionali così utili per generazioni di applicazioni: espressivo linguaggio di query, indici secondari e coerenza assoluta. I database NoSQL condividono diverse chiavi caratteristiche, tra cui un modello di dati più flessibile, una maggiore scalabilità e prestazioni superiori.
Sebbene il termine NoSQL sia spesso utilizzato come categoria ombrello per tutti i database non tabulari, è troppo vago e mal definito per essere un utile descrittore del modello di dati sottostante. Principalmente, esso trascura i compromessi che i database NoSQL fanno per ottenere flessibilità, scalabilità e prestazioni.
Per aiutare i responsabili delle decisioni tecnologiche a navigare nel dominio complesso e in rapida evoluzione di NoSQL e database non tabulari, in questo articolo abbiamo evidenziato le principali differenze tra loro. Esploriamo anche considerazioni critiche basate su sette dimensioni che definiscono questi sistemi: i dati modello; modello di interrogazione; consistenza e modello transazionale; API; dati mobili; piattaforma dati; e supporto commerciale, forza della comunità e libertà dal lock-in.
Modello di dati
Il modo principale in cui i database non tabulari differiscono dai database relazionali è il modello di dati. Sebbene esistano dozzine di database non tabulari, generalmente rientrano in tre categorie:
database di documenti, database di grafici e database di valori-chiave o archivi a colonne larghe.
Modello di documento
Mentre i database relazionali memorizzano i dati in righe e colonne, i database di documenti memorizzano i dati nei documenti utilizzando JavaScript Object Notation (JSON), un formato di interscambio di dati basato su testo popolare tra gli sviluppatori. I documenti forniscono un modo intuitivo e naturale per modellare i dati che è strettamente allineato con la programmazione orientata agli oggetti: ogni documento è effettivamente un oggetto che corrisponde agli oggetti con cui gli sviluppatori lavorano nel codice. I documenti contengono uno o più campi, e ogni campo contiene un valore digitato come una stringa, una data, un binario, un valore decimale o un array.
Piuttosto che distribuire un record su più colonne e tabelle collegate a foreign chiavi, ogni record viene archiviato insieme ai dati associati (ovvero correlati) in un singolo record gerarchico chiamato documento. Questo modello accelera la produttività degli sviluppatori, semplifica l’accesso ai dati e, in molti casi, elimina la necessità di costose operazioni di join e livelli di astrazione complessi come
la mappatura relazionale degli oggetti (ORM).
Lo schema di un database relazionale è definito da tabelle; in un database di documenti, la nozione di uno schema è dinamico: ogni documento può contenere diversi campi. Questa flessibilità può essere particolarmente utile per la modellazione di dati in cui le strutture possono cambiare tra ogni record, ad es. dati polimorfici. Inoltre, semplifica l’evoluzione di un’applicazione durante il suo ciclo di vita, ad esempio aggiungendo nuovi campi. Inoltre, alcuni database di documenti forniscono l’espressività delle query che gli sviluppatori si aspettano dai database relazionali. In particolare, i dati possono essere interrogatisulla base di qualsiasi combinazione di campi in un documento, con ricchi indici secondari che forniscono efficienti percorsi di accesso per supportare quasi tutti i modelli di query. Alcuni database di documenti offrono anche l’ opzione per imporre uno schema sui documenti.
APPLICAZIONI: I database di documenti sono utili per un’ampia varietà di applicazioni dovute alla flessibilità del modello di dati, alla capacità di eseguire query su qualsiasi campo e
la mappatura naturale del modello di dati del documento agli oggetti nei moderni linguaggi di programmazione.
ESEMPI: MongoDB, Azure CosmosDB, Apache CouchDB, Algolia
Modello grafico
I database a grafo utilizzano strutture a grafo con nodi, spigoli e proprietà per rappresentare i dati. In sostanza, i dati sono modellati come una rete di relazioni tra elementi specifici. Sebbene il
il modello grafico può essere controintuitivo, può essere utile per una specifica classe di query. Il suo fascino principale è che semplifica la modellazione e la navigazione delle relazioni tra le entità in un’applicazione.
APPLICAZIONI: I database a grafo sono utili nei casi in cui lo è l’attraversamento delle relazioni core dell’applicazione, come la navigazione delle connessioni ai social network, topologie di rete o supply chain.
ESEMPI: Neo4j, Amazon Nettuno
Database di valori-chiave e Modelli a colonna larga
Dal punto di vista del modello di dati, i database chiave-valore sono il tipo più elementare di non banche dati tabular. Ogni elemento nel database viene memorizzato come nome di attributo o chiave, insieme al suo valore. Il valore, tuttavia, è completamente opaco per il sistema: i dati possono essere interrogati solo dalla chiave. Questo modello può essere utile per rappresentare dati polimorfici e non strutturati, perché il database non impone uno schema impostato su coppie chiave-valore.
Gli spazi a colonne larghe, o gli spazi a famiglie di colonne, utilizzano un ordinamento sparso, distribuito e con una mappa multidimensionale per memorizzare i dati. Ogni record può variare nel numero di colonne memorizzate. Le colonne possono essere raggruppati in famiglie di colonne o distribuiti su più famiglie. I dati vengono recuperati da chiave primaria per famiglia di colonne.
APPLICAZIONI I database chiave-valore e gli archivi a colonne larghe sono utili per a set specializzato di applicazioni che eseguono query sui dati utilizzando un singolo valore chiave. Il fascino di questi sistemi è la loro performance e scalabilità, che può essere altamente ottimizzata grazie alla semplicità del modelli di accesso ai dati e opacità dei dati stessi.
ESEMPI Redis, Amazon DynamoDB (valore-chiave); Apache HBase, Apache Cassandra (colonna larga)
Modello di interrogazione
Ogni applicazione ha i propri requisiti di query. In alcuni casi, potrebbe essere un modello di query di base appropriato, in cui l’applicazione accede ai record in base solo a una chiave primaria. Per la maggior parte delle applicazioni, tuttavia, è importante avere la possibilità di eseguire query in base a diversi valori in ogni record. Ad esempio, un’applicazione che memorizza i dati sui clienti potrebbe dover eseguire una query per nome del cliente, nome dell’azienda, dimensioni, valore delle vendite, codice postale, stato o aggregazioni di più valori.
È anche comune che le applicazioni aggiornino i record, inclusi uno o più singoli campi. A soddisfare questi requisiti, il database deve essere in grado di eseguire query basate su indici secondari. In questi casi, un database di documenti spesso sarà la soluzione più appropriata.
Banca dati dei documenti
I database di documenti generalmente forniscono la possibilità di interrogare e aggiornare qualsiasi campo all’interno di un documento, anche se le capacità in questo dominio variano. Alcuni prodotti, come MongoDB, forniscono un ricco set di opzioni di indicizzazione per ottimizzare un’ampia varietà di query e per automatizzare la gestione dei dati, incluso testo, geospaziale, composto, sparse, jolly, tempo di vita (TTL), indici univoci e altri.
Inoltre, alcuni di questi prodotti consentono analisi in tempo reale rispetto ai dati in atto senza doverlo replicare su un’applicazione di analisi dedicata o su un motore di ricerca. MongoDB, ad esempio, fornisce un framework di aggregazione per gli sviluppatori per creare pipeline di elaborazione per l’analisi dei dati e trasformazioni tramite ricerca sfaccettata, join e unioni; elaborazione geospaziale; viste materializzate; e attraversamenti di grafi. Fornisce inoltre funzionalità di visualizzazione native con i grafici MongoDB con connettori per Apache Spark e strumenti BI. Per aggiornare i dati, MongoDB fornisce espressive metodi di aggiornamento che consentono agli sviluppatori di eseguire manipolazioni complesse rispetto alla corrispondenza degli elementi di un documento, inclusi elementi incorporati in array nidificati, tutto in un unica operazione di aggiornamento transazionale. C’è anche MongoDB Atlas Search, che consente la ricerca full-text funzionalità sul top dei tuoi dati nel cloud.
Database grafico
I database a grafo forniscono ricchi modelli di query in cui è possibile creare relazioni semplici e complesse, interrogazioni per fare inferenze dirette e indirette sui dati nel sistema. Sebbene
l’analisi delle relazioni tenda ad essere efficiente, altri tipi di analisi sono meno ottimali. Di conseguenza, i database grafici raramente vengono utilizzati per applicazioni operative generiche. Piuttosto, sono spesso accoppiati con documenti o database relazionali per far emergere strutture dati e query specifiche del grafico.
Per i casi d’uso che coinvolgono più tecnologie di archiviazione, esiste un’opzione per utilizzare “multimodello” database in cui different modelli di dati e tipi di query sono disponibili all’interno di un’unica piattaforma. Ad esempio, MongoDB offre la fase di aggregazione $graphLookup per l’elaborazione del grafico nativamente all’interno del database. $graphLookup consente attraversamenti efficienti tra grafici, alberi e dati gerarchici per scoprire schemi e far emergere connessioni precedentemente non identificate.
Database di valori-chiave e Modelli a colonna larga
I database chiave-valore e gli archivi a colonne larghe offrono la possibilità di recuperare e aggiornare i dati basati solo su una gamma di chiavi singola o limitata. Per interrogare altri valori, gli utenti sono incoraggiati ar costruire e mantenere i propri indici. Alcuni prodotti forniscono un supporto limitato per indici secondari, ma con diversi avvertimenti. Per eseguire un aggiornamento in questi sistemi, possono essere necessari più round trip — prima per trovare il record, poi per aggiornarlo, e poi per aggiornare l’indice.
L’indice, pertanto, potrebbe non essere coerente con i dati di base, che possono quindi restituire dati obsoleti o cancellati, aumentando drasticamente la complessità dell’applicazione e diminuendo la precisione dei risultati delle query. In questi sistemi, l’aggiornamento può essere implementato come una riscrittura completa dell’intero record al client, indipendentemente dal fatto che sia cambiato un singolo attributo o l’intero record.
Coerenza e Modello transazionale
La maggior parte dei sistemi non tabulari conserva più copie dei dati per scopi di disponibilità e scalabilità. Questi database possono imporre garanzie diverse sulla coerenza dei dati tra le copie. I database non tabulari tendono a essere classificati come fortemente coerenti o alla fine coerenti. Con un sistema fortemente coerente, le scritture dell’applicazione sono immediatamente visibili in seguito alle interrogazioni. Con un sistema coerente alla fine, la visibilità delle scritture dipende dalla replica dei dati che sta servendo la query. Ad esempio, quando si riflettono i livelli di inventario per i prodotti in un catalogo prodotti, con un sistema coerente ogni query vedrà l’inventario corrente man mano che viene aggiornato dall’applicazione, mentre con un sistema coerente alla fine, i livelli di inventario potrebbero non essere accurati per una query in un dato momento, ma alla fine diventeranno accurati man mano che i dati vengono replicati su tutti i nodi del cluster di database.
Per questo motivo, il codice dell’applicazione tende ad essere in qualche modo diverso per i sistemi coerenti – piuttosto che aggiornare l’inventario prendendo l’inventario corrente e
sottraendo uno, ad esempio, gli sviluppatori sono incoraggiati a emettere query idempotenti che in modo esplicito impostino il livello di inventario. Gli sviluppatori devono anche creare una logica di controllo aggiuntiva nelle loro app per gestire dati potenzialmente obsoleti o cancellati. La maggior parte dei sistemi non tabulari offre garanzie di atomicità a livello di record individuale. L’ atomicità è una delle quattro proprietà di transazione che costituiscono le transazioni ACID. Le quattro proprietà in una transazione ACID sono:
- Atomicità
- Consistenza
- Isolamento
- Durabilità
Lo scopo delle transazioni ACID è garantire la validità dei dati nonostante errori, interruzioni di corrente e altri contrattempi. L’atomicità è una garanzia che le operazioni del database sono indivisibili o irriducibili in modo tale che o tutte le operazioni sono state completate o nessuna è stata completata. Perché questi database possono combinare file correlati di dati che altrimenti verrebbero modellati su tabelle padre-figlio separate in uno schema tabulare, le operazioni atomiche a record singolo forniscono una semantica di transazione che soddisfa le esigenze di integrità dei dati di la maggior parte delle applicazioni.
È importante notare che alcuni sviluppatori e amministratori di database sono stati condizionati da 40 anni di modellazione dei dati relazionali per presumere che le transazioni multirecord siano un requisito per qualsiasi database, indipendentemente dal modello di dati sottostante. Alcuni sono preoccupati che sebbene le transazioni multidocumento non sono necessarie per le loro app oggi, potrebbero esserlo in futuro. E per alcuni carichi di lavoro, è necessario il supporto per le transazioni ACID su più record. MongoDB ha aggiunto il supporto per le transazioni ACID multidocumento nel 2018 in modo che gli sviluppatori potessero farlo affrontare una gamma più ampia di casi d’uso con la familiarità di come le transazioni vengono gestite in relazione a banche dati. Attraverso l’isolamento dello snapshot, le transazioni forniscono una visione coerente dei dati e applicano l’ esecuzione tutto o niente. MongoDB è relativamente unico nell’offrire le garanzie transazionali di database relazionali tradizionali, con la flessibilità e la scalabilità che derivano dai database non tabulari.
Sistemi coerenti
Le applicazioni possono avere requisiti diversi per la coerenza dei dati. Per molte applicazioni, è imperativo che i dati siano sempre coerenti. Perché i team di sviluppo hanno lavorato sottoun modello di coerenza con i database relazionali per decenni, questo approccio è più naturale e familiare. In altri casi, l’eventuale coerenza è un compromesso accettabile per la flessibilità che consente
la disponibilità del sistema.
I database di documenti e grafici possono essere coerenti o eventualmente coerenti. MongoDB fornisce consistenza sintonizzabile. Per impostazione predefinita, i dati sono coerenti: tutte le scritture e le letture accedono alla copia primaria dei dati. Come opzione, è possibile emettere query di lettura su copie secondarie in cui potrebbero trovarsi i dati eventualmente consistente se l’operazione di scrittura non è stata ancora sincronizzata con la copia secondaria; la scelta della coerenza viene effettuata a livello di query.ling.
Sistemi finalmente coerenti
Con i sistemi finalmente coerenti, c’è un periodo di tempo durante il quale le copie dei dati non sono sincronizzate. Ciò può essere accettabile per le applicazioni di sola lettura e gli archivi dati che non cambiano spesso, come archivi storici o casi d’uso ad alta intensità di scrittura in cui il database sta acquisendo informazioni, come i registri, che verranno lette in un momento successivo, spesso dopo che sono state spostate un altro sistema che offre funzionalità di query più ricche. In genere, database chiave-valore e colonne larghe i negozi sono considerati alla fine coerenti.
I sistemi finalmente coerenti devono essere in grado di accogliere gli aggiornamenti in conflitto nei singoli record. Poiché le scritture possono essere applicate a qualsiasi copia dei dati, è possibile e non raro che le scritture siano in conflitto tra loro quando lo stesso attributo viene aggiornato su nodi diversi. Alcuni sistemi utilizzano orologi vettoriali per determinare l’ordine degli eventi e garantire che l’operazione più recente prevale in caso di conflitto. Tuttavia, è possibile che sia già stato eseguito il commit del valore precedente all’applicazione. Altri sistemi mantengono tutti i valori contrastanti e spingono la responsabilità della risoluzione conflitti all’utente. Per questi motivi, gli inserti tendono a funzionare bene in caso di coerenza finale
sistemi, ma gli aggiornamenti e le eliminazioni possono comportare compromessi che complicano notevolmente l’applicazione.
API
Non esiste uno standard per l’interfacciamento con i sistemi non tabulari. Ogni sistema presenta diverso design e funzionalità agli sviluppatori di applicazioni. La maturità dell’API può influenzare il tempo e costo necessario per lo sviluppo e la manutenzione dell’applicazione e del database.
Driver idiomatici
I linguaggi di programmazione forniscono diversi paradigmi per lavorare con dati e servizi. I driver idiomatici sono creati da team di sviluppo che sono esperti in una determinata lingua e sanno come i programmatori preferiscono lavorare all’interno di una lingua. Questo approccio può anche fornire efficienze per accedere ed elaborare i dati sfruttando funzionalità specifiche in un linguaggio di programmazione.
Poiché i driver idiomatici sono più facili da imparare e utilizzare per gli sviluppatori, riducono l’onboarding tempo necessario ai team per iniziare a lavorare con un database. Ad esempio, i driver idiomatici forniscono interfacce dirette per impostare e ottenere documenti o campi all’interno di documenti. Con altri tipi di interfacce, potrebbe essere necessario recuperare e analizzare interi documenti e passare a specifici valori per impostare o ottenere un campo.
MongoDB supporta driver idiomatici in più di una dozzina di lingue tra cui Java, .NET, Ruby, Node.js, Python, PHP per lo sviluppo con Laravel, C, C++, C#, JavaScript, Go, Rust e Scala. Dozzine di altri drivers sono
supportati dalla comunità degli sviluppatori.
API RESTful
Alcuni sistemi forniscono interfacce RESTful (Representational State Transfer). Questo approccio ha il fascino di semplicità e familiarità, ma si basa sulle latenze intrinseche associate a HTTP. Esso sposta anche l’onere di costruire un’interfaccia per gli sviluppatori. Si noti che è probabile che questa interfaccia puo’ essere incoerente con altre interfacce di programmazione. Vedi il nostro articolo sull’ integrazione di API di terze parti
API simili a SQL
Alcuni database non relazionali hanno tentato di aggiungere un livello di accesso simile a SQL al database in la speranza che ciò riduca la curva di apprendimento per sviluppatori e amministratori di database già esperti in SQL. è importante valutare queste implementazioni prima che inizi uno sviluppo serio. Considera quanto segue:
- La maggior parte di queste implementazioni non è all’altezza rispetto alla potenza e all’espressività di SQL
e richiederà che gli utenti SQL imparino un dialetto della lingua con funzionalità limitate. - Gli strumenti BI, reporting ed ETL basati su SQL non saranno compatibili con un’applicazione personalizzata
Implementazione SQL. - Sebbene parte della sintassi possa essere familiare agli sviluppatori SQL, la modellazione dei dati non lo sarà
essere. Il tentativo di imporre un modello relazionale su qualsiasi database non tabulare avrà effetti negativi
conseguenze per le prestazioni e la manutenzione delle applicazioni.
Visualizzazione e reportistica
Molte aziende eseguono la visualizzazione, l’analisi e il reporting dei dati utilizzando piattaforme BI basate su SQL che non si integrano nativamente con tecnologie non tabulari. Per risolvere questo problema, le organizzazioni si rivolgono a un’interfaccia Open Database Connectivity, o driver ODBC, per fornire connettività standard del settore tra i loro database non tabulari e strumenti di analisi di terze parti.
Ad esempio, MongoDB Connector for BI consente ad analisti, data scientist e utenti aziendali di visualizzare semi-strutturati e dati non strutturati gestiti in MongoDB insieme ai dati tradizionali dai loro database SQL utilizzando i più diffusi strumenti di BI. MongoDB Charts consente agli utenti di creare e condividere visualizzazioni dei propri Dati MongoDB in tempo reale, senza la necessità di spostare i dati in altri sistemi o sfruttare strumenti di terze parti. Poiché Charts comprende in modo nativo il modello di documento MongoDB, gli utenti possono creare grafici da dati che variano in forma o contengono documenti nidificati e matrici senza bisogno di prima mappare i dati in una struttura piatta e tabulare.
Dati mobili
Le prestazioni delle applicazioni mobili sono importanti tanto quanto le prestazioni delle applicazioni basate su architetture server. Ma le app mobili introducono l’ulteriore sfida di non essere sempre connesse al network. Gli sviluppatori di applicazioni mobili hanno bisogno di una soluzione per conservare tutte le app dei loro clienti sincronizzate con il database di back-end, indipendentemente da dove si trovino nel mondo e dal tipo di rete di connessione che hanno. La soluzione deve anche scalare facilmente e rapidamente man mano che più utenti scaricano un’app e per supportare l’avanguardia delle tecnologie di sviluppo mobile man mano che si evolvono.
I Database NoSQL, sono progettati per scalare su richiesta sfruttando meno costosi hardware di base o infrastruttura cloud: sono ideali per le esigenze aggiuntive poste
dal back-end e dalle applicazioni mobili che si sincronizzano con esso.
Flessibilità dello schema
I database relazionali limitano lo sviluppo a causa dei loro schemi fissi. Perché le nuove funzionalità sono sempre aggiunto nelle app mobili, apportando modifiche ai database relazionali per nuove situazioni le relazioni diventano sempre più dispendiose in termini di tempo. Anche le applicazioni mobili presentano un maggiore utilizzo per i casi casi che i database relazionali sono progettati per gestire, inclusi il tipo di dispositivo, il sistema operativo, firmware e posizione. Per i database NoSQL, aggiunta di funzionalità o aggiornamento di oggetti di cui tenere conto nuovi casi d’uso è semplicemente una questione di inserire nuove righe di codice.
Anche i database NoSQL sono ideali per la gestione degli aggiornamenti frequenti delle applicazioni che costituiscono una parte continua del ciclo di vita di sviluppo delle app. Non è necessario rivedere la logica solo per correggere un bug. E apportare modifiche in una parte del file è improbabile che il database influisca su altre parti dell’applicazione.
MongoDB Realm è un database mobile che consente ai clienti di archiviare dati su telefoni cellulari o sui dispositivi all’edge. Il suo modello di dati è simile a MongoDB in quanto consente agli sviluppatori mobili di farlo memorizzare oggetti simili a dati nel loro codice. Il Realm Mobile Database funziona anche su più piattaforme, che significa che gli utenti non devono fare affidamento su una tecnologia per Android e un’altra per iOS
Sincronizzazione edge-to-cloud
MongoDB Realm Sync consente ai clienti di mantenere i dati sincronizzati tra i dispositivi mobili e il database back-end, nonostante la connettività intermittente. Tutte le modifiche ai dati vengono memorizzate in una cronologia unificata e vengono uniti automaticamente tramite timestamp e trasformazione operativa. Questo edge-to-cloud ,il servizio di sincronizzazione, viene fornito con la risoluzione dei conflitti integrata e risolve uno dei più difficili ostacoli alla creazione di grandi esperienze mobili. I dati alla fine sono sempre coerenti e l’affidabilità è garantita. Quando gli utenti finali non dispongono di una connessione, possono comunque utilizzare le proprie app perché hanno i loro dati archiviati localmente nel Realm Mobile Database. Quando la loro connessione
viene ristabilita, i loro dati sul dispositivo locale vengono aggiornati con gli aggiornamenti dal back-end database nel cloud e viceversa.
Piattaforma dati
I database relazionali hanno una storia lunga e di successo nell’esecuzione con software proprietario e hardware come parte di un ecosistema locale di applicazioni, server ed endpoint. Ma attualmente l’infrastruttura è passata al cloud. I carichi di lavoro del server sono ampiamente distribuiti su più cloud architetture che espandono continuamente i confini della rete ben oltre i confini tradizionali degli ambienti locali. I carichi di lavoro ampiamente distribuiti pongono requisiti elevati sui database che devono svolgere il proprio ruolo di unica fonte di verità, dove la verità si misura in microsecondi.
La semplicità dei database NoSQL li rende più adatti alla velocità e al volume delle moderne transazioni di dati. E la loro portabilità consente alle organizzazioni di trasformare il tradizionale sistema centralizzato di repository di dati in una piattaforma dati altamente flessibile e reattiva in grado di distribuire i carichi di lavoro più vicino a dove le applicazioni ne hanno bisogno.
Man mano che le normative sulla privacy dei dati si espandono per includere i requisiti di sovranità dei dati e l’applicazione locale i server richiedono che i dati più rilevanti siano vicini per garantire letture e scritture a bassa latenza, le organizzazioni hanno bisogno di un maggiore controllo su dove distribuiscono i propri dati. MongoDB Atlas è un database completamente cloud gestitosul cloud che offre alle organizzazioni questo livello di controllo su dove distribuiscono i propri dati, sia a fini normativi che prestazionali.
I dati e l’ Innovation recurring tax (DIRT)
Lavorare con i dati è una parte fondamentale della creazione e dell’evoluzione delle applicazioni. Sebbene gli sviluppatori stiano trovando sempre nuovi modi per creare applicazioni, la maggior parte continua a utilizzare gli stessi dati sottostanti ,infrastrutture in uso da decenni. I database relazionali legacy possono inibire l’innovazione dovuta alla natura rigida delle strutture tabulari, che tendono a scontrarsi con i dati moderni e i tipi di dati degli oggetti con cui gli sviluppatori sono abituati a lavorare . Ciò rende più difficile la sperimentazione e l’iterazione delle applicazioni.
Ci riferiamo a questo come Data and Innovation Recurring Tax (DIRT) e può portare a una frammentazione dell’ esperienza dello sviluppatore, sforzi significativi di integrazione dei dati e duplicazione dei dati non necessaria.
Il superset di tutti i modelli di dati
Il modo per eliminare DIRT è utilizzare una piattaforma di dati applicativi che consente di semplificare e accelerare il modo in cui si creano applicazioni con i dati. MongoDB Atlas è flessibile e utilizza datidi tipo oggetto, che corrispondono al modo in cui gli sviluppatori pensano e codificano. Questo lo rende una piattaforma ideale su cui costruire.
I documenti sono un superset di altri modelli di dati, quindi non c’è bisogno di NoSQL di nicchia aggiuntivo ad altre banche dati. Con Atlas, puoi utilizzare un’unica interfaccia unificata per lavorare con qualsiasi dato generato da applicazioni moderne.
Atlas consente la ricerca full-text completamente integrata, eliminando la necessità di un motore di ricerca separato. Il datastore locale flessibile offre una perfetta sincronizzazione edge-to-cloud per dispositivi mobili e IoT. Puoi eseguire analisi sul posto e in tempo reale con l’isolamento del carico di lavoro e la visualizzazione nativa dei dati. Puoi eseguire anche query federate su database operativi o transazionali e storage di oggetti cloud. E consente la distribuzione globale dei dati per la sovranità dei dati e un accesso più rapido ai dati perché risiede più vicino a dove viene utilizzato.
Considerazioni Finali
Un database è un investimento importante. Una volta che un’applicazione è stata creata su un determinato database, è costoso, impegnativo e rischioso migrarlo in un altro database. Le aziende di solito investono in a un numero limitato di tecnologie di base in modo che possano sviluppare competenze, integrazioni e best practice che può essere ammortizzato in molti progetti. I database non tabulari sono ancora relativamente emergenti come tecnologia. Sebbene ci siano molte nuove opzioni sul mercato, solo un sottoinsieme di tecnologie resisteranno alla prova del tempo.
Supporto commerciale
Considerare l’integrità del fornitore o del prodotto durante la valutazione di un database. È importante non solo che il prodotto continui ad esistere, ma anche che si evolva e aggiunga nuove funzionalità secondo le esigenze che utenti dettano. Avere un’organizzazione di supporto forte ed esperta in grado di fornire servizi globalmente è un’altra considerazione rilevante.
Forza della comunità
Ci sono vantaggi significativi nell’avere una forte comunità attorno a una tecnologia, in particolare per le banche dati. Un database con una forte comunità di utenti rende più facile trovare e assumere sviluppatori che hanno familiarità con il prodotto. Semplifica la ricerca di best practice, documentazione e codice, che riducono tutti i rischi nei nuovi progetti. Aiuta anche le organizzazioni a conservare i dati tecnici chiave e talento. Infine, una comunità forte incoraggia altri fornitori di tecnologia a sviluppare integrazioni e partecipare all’ecosistema
Libertà dal blocco
Molte organizzazioni sono state scottate dal lock-in del database e da pratiche commerciali abusive. L ‘uso di software open source e hardware di base ha fornito una via di fuga per molti, ma
le organizzazioni temono anche che, passando al cloud, potrebbero finire per scambiare una forma di lock-in per un altro.
È importante valutare la licenza e la disponibilità di qualsiasi nuovo importante investimento software. Anche fondamentale è avere la flessibilità di eseguire il database ovunque sia necessario, sia che provenga da a laptop dello sviluppatore nella fase iniziale di adozione, sulla tua infrastruttura mentre entri in produzione, o nel cloud in base a un modello di consumo di database come servizio.
MongoDB Atlas è un database multi-cloud distribuito a livello globale che consente di distribuire i dati in tutto AWS, Google Cloud e Microsoft Azure in più di 80 regioni. Inoltre, puoi creare un file
cluster multi-cloud per abilitare le applicazioni che utilizzano due o più cloud contemporaneamente. Atlas include anche Atlas Search, che è profondamente integrato con l’aggregazione MongoDB
framework e costruito su Apache Lucene, la libreria standard del settore per la ricerca full-text. MongoDB Realm ti consente di fornire le migliori applicazioni mobili con un database mobile intuitivo, sincronizzati con MongoDB Atlas e beneficia della risoluzione dei conflitti integrata. Con Atlas Data Lake, tu può interrogare e analizzare i dati presenti su Amazon S3 e sui tuoi clienti Atlas. MongoDB offre inoltre agli sviluppatori e ai team DevOps la libertà di scaricare ed eseguire il database sulla proprio propria infrastruttura. Ovunque tu scelga di eseguire MongoDB, utilizza la stessa base di codice, API e strumenti di gestione.