Se le tecnologie di database offrissero prestazioni, flessibilità e sicurezza, la maggior parte dei professionisti sarebbe felice di ottenere due dei tre e potrebbero dover aspettarsi di accettare anche alcuni compromessi. I sistemi ottimizzati per la velocità richiedono una messa a punto manuale, mentre le piattaforme flessibili possono imporre costi quando i primi progetti diventano vincoli. Purtroppo, a volte, la sicurezza è un elemento fondamentale, poiché i DBA fanno affidamento sulle competenze e sulle conoscenze dei team interni per non introdurre modifiche rivoluzionarie.
RavenDBtuttavia, esiste perché il suo fondatore ha visto i costi cumulativi di questi compromessi comuni e i problemi intrinseci che ne derivano. Volevano un sistema di database che non costringesse gli sviluppatori e gli amministratori a scegliere.
Astrarre la complessità
Oren Eini, fondatore e CTO di RavenDB, lavorava come consulente freelance sulle prestazioni dei database quasi vent’anni fa. In un’intervista esclusiva ha raccontato di aver incontrato molti team capaci che “si scavavano in un buco” mentre i sistemi a loro affidati diventavano sempre più complessi. I problemi che gli si presentarono non derivavano dal fatto che gli sviluppatori non possedessero le competenze richieste, ma piuttosto dall’architettura del sistema. I database tendono a guidare i loro sviluppatori verso progetti fragili e puniscono gli sviluppatori per aver seguito quei percorsi, dice. RavenDB era un progetto iniziato come un modo per ridurre l’attrito quando la forza inarrestabile di ciò che è richiesto incontra la montagna di schemi di database.
L’enfasi della piattaforma è posta sulle prestazioni e sull’adattabilità senza (ironicamente) richiedere ad un certo punto i servizi di persone come Oren. Armato di un bagaglio pieno di esperienza e conoscenza, ha formato RavenDB, che è attivo da più di quindici anni, ben prima dell’attuale interesse per lo sviluppo assistito dall’intelligenza artificiale.
La conclusione è che, nel tempo, il database RavenDB si adatta a ciò che interessa all’organizzazione, piuttosto che a ciò che immaginava potesse interessarle quando il database è stato creato per la prima volta. “Quando parlo con gli uomini d’affari”, afferma Eini, “dico loro che mi occupo della complessità della proprietà dei dati”.
Ad esempio, invece di aspettarsi che gli sviluppatori o i DBA anticipino ogni possibile modello di query, RavenDB osserva le query mentre vengono eseguite. Se rileva che una query trarrebbe vantaggio da un indice, ne crea uno in background, con un sovraccarico minimo sull’elaborazione esistente. Ciò contrasta con la maggior parte dei database relazionali, dove lo schema e le strategie di indicizzazione sono impostati dagli sviluppatori iniziali, quindi sono difficili da modificare in seguito, indipendentemente da come un’organizzazione potrebbe essere cambiata.
Oren fa il paragone con il getto delle fondamenta di un edificio prima di decidere dove posizionare le porte e le colonne di sostegno. È un approccio che Potere lavoro, ma quando l’azienda cambia direzione nel corso degli anni, il prezzo da pagare per il rimpianto di quelle decisioni iniziali può essere allarmante.
Parlando prima dell’apparizione dell’azienda al prossimo TechEx globale evento tenutosi a Londra quest’anno (4 e 5 febbraio, Olympia), ha citato l’esempio di un cliente europeo che ha faticato ad espandersi nei mercati statunitensi perché il suo database presupponeva una semplice aliquota IVA che aveva relegato a un unico campo, uno schema non adatto alla complessità delle imposte statali e federali sulle vendite. Partendo da decisioni apparentemente semplici prese in passato (e forse a cui non si è prestata molta attenzione: l’IVA europea è abbastanza standard), il cliente stava accumulando difficoltà finanziarie e debito tecnico per la generazione successiva.
Gran parte dell’attrattiva di RavenDB si manifesta nei dettagli pratici e nelle piccole modifiche che rendono i database più performanti e più facili da gestire. La paginazione, ad esempio, richiede due chiamate al database nella maggior parte dei sistemi (una per recuperare una pagina di risultati, un’altra per contare i record corrispondenti). RavenDB restituisce entrambi in un’unica query. Individualmente, tali ottimizzazioni possono sembrare minori, ma su larga scala si sommano. dice Oren. “Se riduci l’attrito ovunque tu vada, ti ritroverai con un sistema davvero ottimo in cui non devi affrontare l’attrito.”
La rimozione combinata degli attriti migliora le prestazioni e semplifica il lavoro degli sviluppatori. I dati correlati vengono incorporati o inclusi senza le penalità associate alle unioni di tabelle nei database relazionali, quindi le query complesse vengono completate in un unico viaggio di andata e ritorno. Gli ingegneri del software non devono essere specialisti di database. Nel loro mondo, si limitano a formulare query di tipo SQL alle API di RavenDB.
Rispetto ad altri database NoSQL, Raven DB fornisce transazioni ACID complete per impostazione predefinita e una complessità operativa ridotta: molte delle sue funzionalità integrate (pipeline ETL, abbonamenti, ricerca full-text, contatori, serie temporali, ecc.) riducono la necessità di sistemi esterni.
A differenza dei DBA e degli sviluppatori di software che affrontano un sistema di database concorrente e le sue necessarie aggiunte, sia gli sviluppatori che gli amministratori trascorrono meno tempo a sudare sui dettagli con Raven DB. Questa è una buona notizia, anche per coloro che tengono i cordoni della borsa di un’organizzazione.
Ridimensionamento per adattarsi allo scopo
RavenDB è inoltre progettato per essere scalabile, con la stessa facilità con cui gestisce query complesse. Se lo si desidera, può creare cluster multi-nodo, quindi supporta un numero enorme di utenti simultanei. Tali cluster vengono creati da RavenDB senza una lunga configurazione manuale. “Con RavenDB, questo è un normale costo aziendale”, afferma.
Nel febbraio di quest’anno, RavenDB Cloud ha annunciato la versione 7.2 e, essendo il 2026, è necessario menzionare l’intelligenza artificiale. L’Assistente AI di Raven DB è, “in effetti, (…) un DBA virtuale che entra nel tuo database”, afferma. La parola chiave è dentro. È progettato per sviluppatori e amministratori, non per utenti finali, per rispondere alle loro domande sull’indicizzazione, sull’utilizzo dello spazio di archiviazione o sul comportamento del sistema.
L’intelligenza artificiale come strumento professionale
È scettico nel dare alle IA un accesso illimitato a qualsiasi archivio dati. Consentire a un’intelligenza artificiale di agire come un generico guardiano delle informazioni sensibili crea inevitabili rischi per la sicurezza, perché tali sistemi sono difficili da limitare in modo affidabile.
Per il DBA e lo sviluppatore di software, è un’altra storia: l’intelligenza artificiale è uno strumento utile che funge da aiuto, configurando e indirizzando i dati. L’assistente AI di RavenDB eredita le autorizzazioni dell’utente che lo invoca, non avendo un proprio accesso privilegiato. “Tutto ciò che sa sulla tua istanza RavenDB arriva perché, dietro le quinte, accede al tuo sistema con le tue autorizzazioni”, afferma.
La strategia di intelligenza artificiale dell’azienda è quella di fornire agli sviluppatori e agli amministratori funzionalità supponenti: generazione di query, spiegazione degli indici, aiuto nell’esplorazione dello schema e risposta a domande operative, con chiamate limitate dalla convalida e dai privilegi dell’operatore.
I team che sviluppano applicazioni con RavenDB ottengono supporto per la ricerca vettoriale, gli incorporamenti nativi, l’indicizzazione lato server e l’integrazione agnostica con LLM esterni. Ciò, afferma Oren, consente alle organizzazioni di fornire rapidamente utili funzionalità basate sull’intelligenza artificiale nelle loro applicazioni, senza esporre l’azienda a rischi e problemi di conformità.
Sicurezza e rischio
La sicurezza e il rischio costituiscono una di quelle aree in cui RavenDB traccia una linea chiara tra sé e i suoi concorrenti. Abbiamo accennato alla recente vulnerabilità MongoBleed, che ha esposto i dati di istanze MongoDB non autenticate a causa di un’interazione tra compressione e codice di autenticazione. Oren descrive il problema come un errore architetturale causato dalla combinazione di percorsi di codice generici e critici per la sicurezza. “Il motivo per cui questa è una vulnerabilità”, dice, “è specificamente il fatto che stai cercando di mescolare le preoccupazioni”.
RavenDB utilizza un’infrastruttura crittografica consolidata per gestire l’autenticazione prima che venga richiamata qualsiasi logica del database. E anche se un difetto provenisse da altrove, la superficie di attacco sarebbe significativamente più piccola perché gli utenti non autenticati non raggiungono mai i percorsi generali del codice: quella separazione architetturale limita il raggio dell’esplosione.
Sebbene i componenti interni di RavenDB siano altamente tecnici e specializzati, i decisori aziendali possono facilmente rendersi conto che i ritardi causati da modifiche dello schema, ottimizzazione delle prestazioni o cambiamenti dell’infrastruttura avranno un impatto economico significativo. Ma la malleabilità e la velocità di RavenDB eliminano anche quelle che Oren descrive come le conversazioni del tipo “no, non puoi farlo”.
Le organizzazioni che utilizzano RavenDB riducono la loro dipendenza dalle competenze specialistiche, inoltre ottengono la capacità di rispondere alle mutevoli esigenze aziendali molto più rapidamente. “Il ruolo (del database) è quello di apportare reale valore aziendale”, afferma Eini, sostenendo che l’infrastruttura dovrebbe, in contesti operativi, passare in secondo piano. Allo stato attuale, spesso determina la portata delle discussioni strategiche.
Migrazione e avvio
RavenDB utilizza un linguaggio di query familiare simile a SQL e la maggior parte dei team avrà bisogno solo di un giorno al massimo per mettersi al passo. Laddove si manifestano attriti, suggerisce Oren, è spesso dovuto a presupposti riportati da altre piattaforme in merito alla sicurezza e all’elevata disponibilità. Per RavenDB, questi sono integrati nel progetto, quindi non causano un carico di lavoro aggiuntivo che deve essere preso in considerazione.
Nata come risultato dell’esperienza di difficoltà operative da parte dello stesso fondatore dell’azienda, la differenza di RavenDB deriva da decisioni di progettazione accumulate: indicizzazione in background, ottimizzazione basata sulle query, separazione delle questioni di sicurezza e autenticazione e, ultimamente, la necessità di vincoli sugli strumenti di intelligenza artificiale. Nell’uso quotidiano, gli sviluppatori sperimentano meno spigoli vivi e, a lungo termine, i leader aziendali vedono una riduzione dei costi, soprattutto nei periodi di cambiamento. La combinazione è abbastanza convincente da spostare le piattaforme radicate in molti contesti.
Per saperne di più, puoi parlare con i rappresentanti di RavenDB all’indirizzo TechEx globaletenutosi all’Olympia, Londra, il 4 e 5 febbraio. Se quello che hai letto qui ha risvegliato il tuo interesse, vai su il sito web dell’azienda.
(Fonte immagine: “#316 AVZ Database” di Ralf Appelt è concesso in licenza con CC BY-NC-SA 2.0.)
Vuoi saperne di più sull’intelligenza artificiale e sui big data dai leader del settore? Guardare Fiera dell’intelligenza artificiale e dei big data che si svolge ad Amsterdam, in California, e a Londra. L’evento completo è parte di TechEx e co-localizzato con altri importanti eventi tecnologici. Clic Qui per ulteriori informazioni
AI News è alimentato da Media TechForge. Esplora altri prossimi eventi e webinar sulla tecnologia aziendale Qui.
Fonte: www.artificialintelligence-news.com
