Questo articolo, di tal Jordan Tigani, getta una luce oscura sul futuro dei big data.
E’ scritto dal CEO di un’azienda che sviluppa un nuovo database OLAP (Online analytical processing) chiamato Duckdb, che e’ open source ed e’ “embedded”, nel senso che si ispira molto al modo di funzionare di SQLite.
L’articolo sottolinea come uno degli argomenti piu’ forti dietro la commercializzazione di sistemi BigData (come BigQuery, MongoDB ecc) e cioe’ l’enorme flusso di dati che avrebbe investito alcune aziende, rappresentando sia una opportunita’ che una sfida, non si e’ verificato nonostante queste profezie siano vecchie di dieci anni.
A questo si aggiunga che anni fa il CEO di MongoDB osservava, con una buona dose di onesta’ intellettuale, che la maggior parte dei loro clienti non avevano cosi’ tanti dati da giustificare l’uso di… MongoDB
Il medesimo articolo di Tigani, nota che l’adozione di MySQL/PostgreSQL non e’ scemata in favore di database NoSQL, e non si puo’ dire che l’offerta su questo fronte sia carente, o che la tecnologia non sia matura.
MySQL e’ dannatamente veloce, e l’ho visto usato spesso in contesti NoSQL senza particolari problemi (lo stesso Facebook inizio’ nella sua infanzia con uno “sharding” di server MySQL per gestire il suo database). E MySql si porta dietro tutta la plasticita’ di poter fare aggregazioni, report ecc in SQL..
Infine l’aticolo sostiene che la dimensione tra il business e i dati sottesi cresca con una regola precisa:
Customer data sizes followed a power-law distribution. The largest customer had double the storage of the next largest customer, the next largest customer had half of that, etc. So while there were customers with hundreds of petabytes of data, the sizes trailed off very quickly. There were many thousands of customers who paid less than $10 a month for storage, which is half a terabyte. Among customers who were using the service heavily, the median data storage size was much less than 100 GB.
E qui casca l’asino, perche’ un Database di dati storici mediamente di 100 GB puo’ essere gestito con un database relazionale, soprattutto se i dati storici sono gia’ aggregati in qualche modo: tutta la storia di de-normalizzare i dati per renderli digeribili da un database NoSQL, e dover continuamente fare manutenzione per fare nuovi report, diventa improvvisamente meno accattivante.
Inoltre:
- MySQL spesso e’ un concorrente di soluzioni NoSQL, poiche’ e’ veloce se si rinunciano alle transazioni
- PostgreSQL con storage “custom” ad alta velocita’ e’ una soluzione venduta dai cloud provider, e rivaleggia tranquillamente con le soluzioni Oracle, per le soluzioni meno mission-critical.
- Database SQL estremamente affilati come SQLite, anche senza supporto a scritture parallele, possono tranquillamente gestire siti mediamente complessi, come leggiamo in questo inciso, sul sito si sqlite:
- WebsitesSQLite works great as the database engine for most low to medium traffic websites […] Generally speaking, any site that gets fewer than 100K hits/day should work fine with SQLite. The 100K hits/day figure is a conservative estimate, not a hard upper bound. SQLite has been demonstrated to work with 10 times that amount of traffic.The SQLite website (https://www.sqlite.org/) uses SQLite itself, of course, and as of this writing (2015) it handles about 400K to 500K HTTP requests per day, about 15-20% of which are dynamic pages touching the database. Dynamic content uses about 200 SQL statements per webpage. This setup runs on a single VM that shares a physical server with 23 others and yet still keeps the load average below 0.1 most of the time.See also: Hacker New discussion from 2022-12-13.
Premesso cio’, duckdb cerca di posizionarsi come un “SQLite OLAP”, coprendo l’altra meta’ del cielo con un database embedded, column-based e quindi molto veloce nel processare i dati in modo colonnare.
Se a questo sia aggiunge che ormai anche computer portatili arrivano tranquillamente ad una dozzina di core logici senza problemi, si capisce che il destino di alcuni servizi BigData-as-service appare segnato.
E i Data Lake?
Kafka, e varianti occupano un segmento leggermente diverso: sono sistemi che risultano utili nel processare in parallelo grandi quantita’ di dati real-time, per es provenienti da una miriade di sistemi mobile.
Certo se poi tali dati sono scarsamente acceduti, anche il data lake risulta meno rilevante…
E voi, cosa ne pensate? Lasciate sotto un commento sulla vostra esperienza