Un esempio di scalabilità

Una delle critiche che ultimamente sento fare una un certa parte (tendenziosa IMHO) del mondo dello sviluppo è che i database relazionali non sono in grado di scalare, ed è per questo che Facebook e servizi simili stanno usando ed andando verso soluzioni “NoSQL”, cercando di eliminare l’uso di database relazionali, perchè “non scalano”.

A parte che come ho già detto e dimostrato su un articolo pubblicato su Computer World Italia queste idee balzane derivano da semplice ignoranza in materia, senza voler dare in alcun modo un giudizio negativo in merito, uso la parola ignoranza in modo neutro per identificare una “mancanza di una conoscenza sufficiente” dell’argomento. Oggi arriva una notiza che penso possa essere un buon esempio di come, al contrario, un database (ben) progettato e manutenuto sia in grado di scalare oltre ogni limite “normale”: Hotmail utilizza SQL Server 2008 come database di backend per la memorizzazione e la gestione dei dati ed attualmente la dimensione ha raggiunto i 155 Petabyte.

http://www.ugiss.org/Content/Article/Il-pi%C3%B9-grosso-sistema-al-mondo-basato-su-SQL-Server.aspx

Sarebbe bello che la prossima volta che chiunque sostenga che i db non scalano, si faccia un attimo due conti e si chieda se effettivamente sta progettando sistemi che hanno necessità di gestire più di 2 Petabyte al giorno di crescita per un totale di 155 PetaByte totali. :-)

Per il resto, sarei ben felice di avere una reale proposta alternativa ai db relazionali, ma finche qualcuno non si mette a fondare tale proposta su solide basi matematiche, non credo che si possa avere realmente una possibilità alternativa.

Un’ultima nota di colore: sembra che questa necessità di avere basi matematiche spaventi ai più. Sarà per questo che nell’informatica tantissimi si firmano “Architect” e ben pochi “Engineer”? :). Su, ricordiamoci che nel mondo c’è bisogno di entrambi!

Published venerdì 8 gennaio 2010 13.09 by dmauri

Comments

# re: Un esempio di scalabilità

venerdì 8 gennaio 2010 17.12 by AlessandroD

Credo che a breve prenderanno piede anche le qualifiche di:

- IT Wizard;

- IT Artist

:-D

# re: Un esempio di scalabilità

venerdì 8 gennaio 2010 18.53 by dmauri

ROTFL!!!! :-)

# It’s not about platform, it’s about architecture

domenica 10 gennaio 2010 18.56 by Francesco Quaratino

Dopo quello offerto da Windows Live , un altro esempio di scalabilità di SQL Server, ce lo offre questo

# re: Un esempio di scalabilità

domenica 17 gennaio 2010 10.44 by marcot

Mi spiace, ma anche te sei caduto nell'errore di giudicare senza sapere.

Sei partito da un'implementazione di un sito Microsoft, con tutto il supporto Microsoft, e licenze infinite: hai presente il costo di licenze necessarie per mantenere quei 155 Petabyes?

Poi stiamo parlando di startup che avevano bisogno di una soluzione snella (nel senso delle dipendenze da licenze, system requirements, rapidità di implementazione, ecc.), scalabile e che funzioni..

Friendfeed usa MySQL con motore transazionale InnnoDB, ma con struttura dei dati key-value: serve per le migrazioni, per la gestione e per lo svluppo rapido.

Facebook usa Cassandra, Google e Amazon hanno i loro SimpleDBs.. Tutte le soluzioni di cloud hosting offrono soluzioni di questo tipo: vuou dirmi che sbagliano?

O forse hanno fatto le loro valutazioni per non usare database relazionali che forse con la matematica o con la nostra professionalità non riusciamo a comprendere? ;-)

# re: Un esempio di scalabilità

domenica 17 gennaio 2010 12.29 by dmauri

@Marcot: stiamo parlando di scalabilità, non di costi...che centra il prezzo delle licenze?

Voglio direi che tutti i "player" che forniscono soluzioni non relazioni per la memorizzazione dei dati si sbagliano? Si voglio direi proprio questo. Se ti ricordi di un prodotto chiamato "Tamino", vedrai che potrei proprio aver ragione....

Cmq, io non avevo proprio l'intenzione di parlare costi/benefici, ma semplicemente dimostrare come oggi chi sostiene che un db relazionale non è in grado di scalare dice una cosa falsa (e tendeziosa).

E poi, tieni presente che gestire dimensioni, oggi, maggiori di 100 TB è cmq costoso, qualsiasi sia la tencologia da usare. E quindi, IMHO, tanto vale usare una buona e consolidata, non una la cui funzionalità non sia una semplice esperimento di qualcosa, ma sia basata su radici concrete e solide come, ad esempio, un modello matematico studiabile, analizzabile ed predicibile.

:-)