Oltre i database in-memory
Molte buzzword IT invecchiano male, e per una buona ragione: la maggior parte delle tecnologie che una volta vantavano un vantaggio competitivo viene rapidamente superata da alternative superiori in un decennio o meno. Pertanto, se un vendor software continua a usare una buzzword ben oltre la sua data di scadenza (1), la spiegazione più semplice è che il suo team di R&S non si sia nemmeno reso conto che il mondo è andato avanti.
Aneddoticamente, diversi venture capitalist mi hanno anche detto che erano stanchi di investire in qualsiasi azienda software che avesse più di pochi anni, perché la maggior parte delle aziende non riesce mai a disaccoppiare la propria tecnologia dal panorama tecnologico che le ha definite quando hanno iniziato.
(1) Il mercato tecnologico stesso definisce quando una tecnologia “scade”. Osservando una determinata tecnologia, al massimo si può solo ipotizzare all’incirca per quanto tempo rimarrà ragionevolmente vicina allo stato dell’arte.
I database in-memory una volta erano una buzzword IT, e questo non ha invecchiato bene: qualsiasi azienda software che oggi si presenta come fornitrice di in-memory computing o in-memory sta spingendo sul mercato tecnologie ormai obsolete (2). Tuttavia, non fraintendetemi: sfruttare al meglio la “memoria” - ne parleremo più avanti - non è mai stato così importante; tuttavia, il panorama informatico è ora più complesso di quanto lo fosse in passato.
(2) In teoria, potrebbe essere semplicemente il team marketing a rimanere indietro, mentre il team tecnico ha già fatto un balzo in avanti. Tuttavia, non ho mai incontrato alcuna azienda software che soffrisse di questo problema. Si può tranquillamente presumere che il marketing sia sempre avanti rispetto alla tecnologia.
A fine degli anni ‘90 e all’inizio degli anni 2000, un tipo specifico di memoria volatile, colloquialmente nota come la RAM, era diventato abbastanza accessibile da permettere che dataset sempre più interessanti e di valore potessero essere contenuti in-memory. All’epoca, la maggior parte del software era progettata con l’idea che la RAM fosse così costosa e limitata che adottare complicazioni eccessive, solo per limitare al massimo la pressione sulla RAM, era un approccio valido. Rivisitando semplicemente la maggior parte dei problemi con un approccio fresco e senza vincoli, cioè l’“in-memory” computing, molti software vendors hanno ottenuto enormi miglioramenti in termini di velocità rispetto ai prodotti più vecchi, che si basavano esclusivamente sui dischi rotanti.
Avanziamo al 2018, i database in-memory rappresentano una prospettiva obsoleta, e lo sono da anni ormai. Esistono molti tipi di archiviazione dei dati:
- Cache L1 della CPU
- Cache L2/L3 della CPU
- RAM locale
- RAM locale della GPU
- SSD locale
- HDD locale
- RAM remota
- SSD remota
- HDD remota
- Archiviazione su nastro o ottica
Non sto nemmeno elencando le tecnologie di archiviazione più recenti come Intel Optane, che quasi rappresenta una categoria di dispositivi a sé stante.
I vendor che promuovono il “in-memory” computing lasciano intendere che la loro tecnologia software sia principalmente orientata all’utilizzo di due tipi di memoria: la RAM locale e la RAM remota. Sebbene sfruttare al massimo la RAM, sia locale che remota, sia certamente positivo, ciò comporta anche approcci ingegneristici che sottoutilizzano le alternative.
Ad esempio, negli ultimi due decenni, la cache della CPU è passata da 512KB a oltre 60MB per le CPU di fascia alta. Con una cache così ampia, è ora possibile fare “in-cache computing”, ottenendo accelerazioni significative rispetto al semplice “in-memory computing”. Tuttavia, sfruttare la cache richiede la minimizzazione di molte strutture dati o strategie ancora più intelligenti, ben al di là di ciò che viene considerato necessario o addirittura desiderabile dal punto di vista della RAM.
Tuttavia, limitarsi a dire che la cache della CPU è più veloce della RAM locale perderebbe di vista il punto. Al giorno d’oggi, una buona ingegneria del software implica sfruttare al massimo le rispettive capacità di tutte queste classi di memorizzazione dei dati. Grazie al cloud computing, assemblare un mix ad hoc di risorse informatiche non è mai stato così semplice.
Pertanto, Lokad non offre una tecnologia software “in-memory”, perché ciò ci impedirebbe di sfruttare le altre opzioni attualmente disponibili. Ad esempio, pur potendo noleggiare macchine con fino a 2TB di RAM, ciò sarebbe inutilmente costoso per i nostri clienti. Esistono molti algoritmi che possono essere eseguiti in streaming completo; quindi, elaborare terabyte di dati non richiede terabyte di RAM, e considerando che 1GB di RAM costa circa 1000 volte di più rispetto a 1GB di HDD, non si tratta di un dettaglio di implementazione.
Il nostro obiettivo non è aderire a una visione rigida dell’ingegneria del software, ma mantenere una prospettiva ingegneristica più ampia, che consiste nel fare il massimo con il budget a disposizione. In altre parole, siamo inclini a utilizzare l’elaborazione in-memory ogniqualvolta superi le alternative, ma non oltre.
Poi, poiché le risorse informatiche non sono completamente regolabili on-demand - ad esempio, non è realistico noleggiare una macchina senza cache CPU - in Lokad ci impegniamo a sfruttare al massimo tutte le risorse per le quali si sta pagando, anche se tali risorse non erano state strettamente richieste in origine.
