Perché l’upgrade del database è il vero bottone di avvio per l’AI

Nel prossimo anno la maggior parte delle grandi imprese non investirà principalmente in GPU, ma in un nuovo database. Oracle AI Database 26ai è il rilascio a supporto a lungo termine verso cui Oracle sta orientando la base installata di 19c. Questa versione integra la ricerca vettoriale nello stesso motore che gestisce le transazioni, trasformando il blocco array e il fabric SAN in infrastruttura AI.

Il cuore di 26ai è un tipo di dato VECTOR nativo, funzioni SQL per la ricerca vettoriale, esecuzione in‑database di modelli ONNX e la capacità SELECT AI per query in linguaggio naturale. Con più di 300 nuove funzionalità, un DBA può generare embedding, archiviarli accanto alle righe che descrivono e lanciare ricerche di similarità nello stesso contesto transazionale, eliminando la necessità di un archivio vettoriale separato, pipeline di sincronizzazione o copie duplicate di dati regolamentati.

Il contesto di mercato e la spinta verso database vettoriali integrati

IBM cita IDC: “I database vettoriali integrati sono la piattaforma preferita per memorizzare e interrogare embedding, poiché le organizzazioni cercano ambienti unificati e governati per l’AI agente.”

Il ranking DB‑Engines di ottobre 2026 mostra i primi quattro motori relazionali e multimodello — Oracle, MySQL, Microsoft SQL Server e PostgreSQL — tutti con supporto a tipi vettoriali o estensioni come pgvector. IBM ha iniziato la validazione con Oracle per la sua leadership di mercato, ma gli argomenti di storage si applicano anche agli altri sistemi.

Motivi per mantenere lo storage a blocchi on‑prem

    • I dati sensibili (cartelle cliniche, sinistri, ordini, trade) non possono lasciare l’ambiente di produzione.
    • Duplicare i dati su una piattaforma AI dedicata comporta costi doppi e perdita di governance.
    • Conservare il retrieval all’interno del database elimina questi problemi.

Architettura di test: IBM FlashSystem e Broadcom Fibre Channel

IBM Storage e Broadcom hanno creato un ambiente di validazione basato su Oracle AI Database 26ai, IBM FlashSystem 9000 series e fabric Brocade Gen 8 con HBA Emulex 64G Secure. L’obiettivo era rispondere a domande chiave:

    • Impatto sulla latenza transazionale quando il carico vettoriale coesiste.
    • Effetto della velocità del fabric sul throughput della ricerca vettoriale.
    • Capacità occupata dagli embedding.
    • Efficacia della rilevazione ransomware su volumi di backup RMAN.
    • Requisiti per aggiungere un host al SAN senza ticket di zoning.

Non si afferma che tutti i carichi AI debbano stare su storage a blocchi; file e object storage rimangono fondamentali per documenti, immagini, video, dataset di training e checkpoint di modelli. Nel caso sanitario mostrato, le immagini X‑ray rimangono in object storage, mentre solo gli embedding e i metadati dei casi sono memorizzati in Oracle.

Caratteristiche dei tre tier di workload

Tier relazionale: milioni di I/O casuali da 4 KB a 16 KB al secondo, lookup di righe in microsecondi, alta concorrenza di scritture (redo, undo, checkpoint) e latenza di coda prevedibile.

Tier di backup (RMAN): flusso sequenziale che richiede capacità di headroom per completare entro la finestra di backup senza disturbare il tier primario.

Tier vettoriale: più complesso da caratterizzare. Le tabelle di embedding possono sembrare un carico a banda intensiva, ma IBM ha osservato che ogni salto nell’indice è una lettura casuale di circa 4 KB, rendendo il percorso IOPS‑bound e sensibile alla latenza. I burst di banda avvengono durante la costruzione dell’indice o la re‑embedding di grandi corpora, dove la capacità del fabric (32 G vs 64 G) diventa il collo di bottiglia.

Dettagli dell’ambiente di laboratorio

L’array FlashSystem 9000 series utilizza 24 FlashCore Modules, IBM Storage Virtualize 9.1.3 e 64 G Fibre Channel verso due switch Brocade Gen 8 G820. Il server host è un Intel Xeon 6767P a doppio socket con due HBA Emulex LPe38102 64 G. Oracle AI Database 26ai gira su ASM senza GPU nel percorso di storage; IBM Storage Insights monitora l’array.

Per i test di benchmark è stato usato VectorDBBench su dataset BioASQ 1M. Un secondo server, Supermicro 821GE‑TNHR con due Xeon Platinum 8470 e otto GPU NVIDIA H100 80 GB, ha eseguito l’applicazione sanitaria, ONNX embedding, Ollama con Llama 3 e NVIDIA cuVS, collegati tramite switch Broadcom Tomahawk 5 e NIC 400 GbE Thor 2.

Risultati: impatto del carico vettoriale sulle transazioni OLTP

IBM ha configurato 30 volumi: 15 per tabelle OLTP (ORCL16‑ORCL30) con Swingbench Order Entry a 192 utenti, e 15 per tabelle vettoriali (ORCL31‑ORCL45) con generatore sintetico a 200 thread che esegue query top‑k 500. Con solo OLTP, ogni volume OLTP mostrava 20 500 ops/s.

Quando il generatore vettoriale è stato avviato, i volumi vettoriali hanno raggiunto circa 73 000 ops/s ciascuno, mentre i volumi OLTP sono scesi a 13 000 ops/s, una diminuzione del 37 % senza alcuna modifica al carico transazionale. Poiché entrambi i percorsi usano letture casuali da 4 KB, competono per le stesse code dell’array.

Applicando un limite di 45 000 IOPS per volume vettoriale mediante mkthrottle, si è osservato che i volumi OLTP hanno ripreso a circa 18 500 ops/s, dimostrando l’efficacia dell’I/O QoS a livello di volume.

Altri test di capacità e sicurezza

La capacità occupata dagli embedding è stata misurata in circa 2,3 TB per 1 M di vettori a 768 dimensioni, evidenziando una densità di 2,3 KB per embedding. IBM Storage Virtualize ha fornito funzioni di AutoZoning, ransomware detection su volumi RMAN e Policy‑Based HA, tutte operative su tutti i modelli della famiglia FlashSystem (5300, 5600, 7300, 7600, 9500, 9600).

L’aggiunta di un nuovo host al SAN è stata eseguita senza ticket di zoning grazie al meccanismo AutoZoning, riducendo i tempi di provisioning da giorni a minuti.

Conclusioni e implicazioni per il futuro

Il test dimostra che un unico array a blocchi può supportare carichi misti OLTP, backup e ricerca vettoriale con adeguata configurazione QoS. La chiave è riconoscere la natura IOPS‑bound della ricerca vettoriale quando gli embedding sono indicizzati e gestiti all’interno del database, e non trattarli come semplici flussi sequenziali a larga banda.

Le organizzazioni che desiderano mantenere la governance dei dati sensibili possono così consolidare le proprie infrastrutture, riducendo costi di duplicazione e semplificando la gestione della conformità. Parallelamente, continuano a sfruttare file e object storage per i dati non strutturati, creando un ecosistema di storage ibrido ottimizzato per le esigenze AI di oggi e di domani.