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:

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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:

  1. Atomicità
  2. Consistenza
  3. Isolamento
  4. 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:

  1. 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.
  2. Gli strumenti BI, reporting ed ETL basati su SQL non saranno compatibili con un’applicazione personalizzata
    Implementazione SQL.
  3. 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.

5 tools di Intelligenza Artificiale che possono semplificare (gratuitamente) la nostra vita

La bolla dell’ intelligenza artificiale (IA, AI o come preferite) si sta ingigantendo sempre di più.
Già ci sono fior di squali che vendono corsi in cui vengono svelate informazioni spacciate come segrete, in realtà gratuitamente accessibili sul web, che dovrebbero renderci ricchi e famosi grazie all’ IA

Ma il nostro mestiere è sviluppare web applications su Laravel o app mobile con Flutter, quindi le informazioni preferiamo renderle disponibili a tutti, senza la pretesa che siano “corsi qualificanti”, anche se riteniamo che le nostre fonti siano sicuramente piu’ qualificate e le informazioni piu’ tecniche e precise di quelle date dai professionisti della divulgazione a pagamento.

Vediamo quindi 5 strumenti offerti gratuitamente da altrettante start-up per applicare la capacità dell’intelligenza artificiale nella nostra attività quotidiana.

1) Creazione di checklist
2) Generazione codice di programmazione
3) Creazione Emails
4) Riassunti concisi di video lunghi
5) Automazione di attività

Per le nostre considerazioni generali relative all’ AI potete fare riferimento a quest’articolo.


L’intelligenza artificiale (AI) non è più solo un concetto futuristico, è ora una realtà che sta cambiando il modo in cui viviamo e lavoriamo. L’integrazione della tecnologia AI nella nostra vita quotidiana ha reso molte attività più efficienti e convenienti.

Dalla pianificazione degli appuntamenti alla gestione delle finanze, esiste uno strumento di intelligenza artificiale per quasi tutto. La parte migliore? Molti di questi strumenti sono completamente gratuiti. In questo post, presenteremo cinque strumenti basati sull’intelligenza artificiale che vi semplificheranno la vita senza spendere una fortuna.

Checklist.gg

Checklist.gg è un sito Web che fornisce una piattaforma semplice e facile da usare per la creazione e la gestione di liste di controllo. Che voi stiate cercando di organizzare le vostre attività lavorative, pianificare una vacanza o tenere traccia dei vostri acquisti di generi alimentari, Checklist.gg è quello che fa per voi.

Programming-Helper.com

Programming-Helper è un sito Web all’avanguardia che utilizza la tecnologia AI per rendere la programmazione più semplice e accessibile a tutti. Con l’esclusiva funzione di generazione del codice basata sull’intelligenza artificiale del sito Web, gli utenti possono semplicemente digitare una descrizione testuale del codice desiderato e l’intelligenza artificiale lo genererà per loro.

Effortless-email.com

Effortless-Email è un sito Web che utilizza la tecnologia AI per tradurre rapidamente i punti elenco in e-mail complete in diverse lingue. Supporta più lingue e il processo di traduzione è rapido e accurato.

Summarizeit.io

Summarizeit.io è un sito Web che aiuta i professionisti impegnati e gli studenti attivi a risparmiare tempo e rimanere informati fornendo riassunti concisi di video lunghi. Il sito Web utilizza la tecnologia AI per analizzare e condensare rapidamente i video in riepiloghi di facile lettura, evidenziando le informazioni più importanti. Che tu stia guardando un discorso TED, un segmento di notizie o un video di formazione, Summarizeit.io semplifica la comprensione rapida dei punti chiave.

Bardeen.ai

Questo sito Web utilizza la tecnologia AI per fornire una piattaforma semplice e intuitiva che semplifica l’automazione di attività come l’immissione di dati, la gestione dei file e altro ancora. Con Bardeen.ai, puoi risparmiare tempo e aumentare l’efficienza automatizzando attività manuali che altrimenti richiederebbero ore per essere completate

Conclusione

Non sappiamo se in realtà l’Intelligenza Artificiale rappresenta una novità, ossia se effettivamente rappresenta un’evoluzione oppure semplicemente un modo diverso per fare cose che facevamo benissimo anche prima. Ma è il tema del momento, e noi siamo sul pezzo.