L'accesso ai dati è cambiato da un pezzo ma gli increduli non se ne sono accorti

<< Generazione bruciata | Home | Sete di handle e le applicazioni che non si aprono più >>

L'accesso ai dati è cambiato da un pezzo ma gli increduli non se ne sono accorti

Purtroppo sui newsgroup ancora troppo spesso vedo persone che impostano la propria applicazione usando architetture client-server quando già negli anni '90 la programmazione Windows si spostava verso il multi-tier con COM, DCOM e poco più tardi con COM+.
Oggi il Framework.NET e Java sono i due protagonisti delle applicazioni distribuite e al di là dell'oceano le applicazioni n-tier ci sono e funzionano bene. Qui abbiamo vissuto una sorta di buco nero e lo stesso David Chappel era rimasto allibito durante la conferenza su SOA a Milano di fronte alla grossa quantità di mani alzate alla domanda su chi sviluppasse oggi client-server.

L'architettura di eBay che ho letto grazie al post di Janky non fa che darmi tutta una serie di ennesime conferme a quanto si sa da un bel pezzo e ho spesso ripetuto nel mio blog, durante i workshop e in tante altre occasioni.

eBay usa una architettura SOA e su più livelli.
eBay mantiene l'application tier completamente stateless (stato tenuto in cookie o su DB)
eBay mantiene in cache quanto più è possibile evitando roundtrip sul DB
eBay ha strutturato il DB in funzione della scalabilità (e non viceversa)
eBay si è sviluppata un ORM a proprio uso e consumo
eBay ha splittato l'applicazione in aree funzionali differenti in modo da usare DB differenti minimizzando le dipendenze tra DB
eBay non usa stored procedure ma fa uso di prepared statement (i nostri command con i parameters)
eBay usa i trigger solo per creare i valori di default
eBay non usa l'integrità referenziale del DB ma ha spostato i controlli sul lato applicativo
eBay ha spostato sul lato applicativo anche le join e il sorting per alleggerire il DB
eBay ha minimizzato l'uso di transazioni e non fa uso di transazioni distribuite
eBay fa uso di concorrenza ottimistica per gli aggiornamenti ("avoid deadlocks" + "update concurrency")

Inoltre non credo possano far uso di impersonation nè usare la sicurezza del database sugli utenti (con 212'000'000 utenti, la vedo molto dura).

E se tutto ciò funziona (e non avevo dubbi) per un sistema da 2000 TB che lancia 26 miliardi di statement SQL al giorno...

Ovviamente questo non significa che tutte le applicazioni vadano strutturate in questo modo o che non sia mai il caso di usare stored procedure o ancora che sia sbagliato fare transazioni distribuite. Il punto centrale che sorge dall'architettura di eBay è che hanno ottenuto la massima scalabilità in quel modo e che perciò tante credenze popolari vanno sfatate e messe seriamente in discussione durante la stesura dell'architettura.

Print | posted on venerdì 29 dicembre 2006 14:22 |

Feedback

# re: L'accesso ai dati è cambiato da un pezzo ma gli increduli non se ne sono accorti

Non faccio nessun commento, ricordo solo a tutti i lettori che i DB sono motori di inferenza logica che garantiscono la correttezza dei dati e la loro coerenza dei dati poggiandosi su solide base matematiche. NON sono solamente sistemi di storage.

Poi è bene che ognuno faccia le proprie scelte architetturali in funzione delle proprie esigenze, ma è importante che tali scelte partano da una conoscenza profonda dei pro e dei contro di ciò che si sta facendo.

Ogni sviluppatore ed architetto oltre a conoscere molto bene il modello OO devrebbe conoscere altrettanto bene il modello relazionale, in modo da scegliere con senno.

29/12/2006 14:45 | Davide Mauri

# re: L'accesso ai dati è cambiato da un pezzo ma gli increduli non se ne sono accorti

A seguito dei molti contatti in privato mi preme chiarire alcuni punti:
- mi sembra evidente che eBay non sta usando i DB solo come storage
- non credo si possa dubitare che eBay sappia cosa sia e come funzioni il modello relazionale
- non credo che si possa criticare le scelte di un team come quello di eBay visto e considerato che è un case study di enorme successo
- ho già chiarito che non considero mai le architetture universali ma ogni scelta deve essere valutata di caso in caso senza timori reverenziali per le "credenze popolari" sui db
- il caso eBay è una limpida dimostrazione che le loro scelte pagano e sono le più valide, considerato che vengono da esperienze di tipo client-server che hanno abbandonato verificandone gli aspetti negativi

Detto questo giusto per chiarezza, il mio post fa solo una mera fotografia di quello che è un caso reale, funzionante e di enorme successo. Ciascuno poi faccia le proprie scelte.

29/12/2006 16:56 | Raffaele Rialdi

# re: L'accesso ai dati è cambiato da un pezzo ma gli increduli non se ne sono accorti

Ritengo che questo esempio sia il chiaro manifesto di come per risolvere un problema esistano indubbiamente diverse soluzioni e sopratutto non esiste a priori la soluzione ottima. Fare le join lato applicativo ad esempio a primo impatto mi sembrerebbe una soluzione folle, ma evidentemente per raggiungere quel livello di servizio (210.000.000 utenti e 24/7 avaliability) spostare tutto su application server in modo da scalare orizzontalmente è la soluzione vincente.

Gian Maria.

29/12/2006 17:20 | Gian Maria

# re: L'accesso ai dati è cambiato da un pezzo ma gli increduli non se ne sono accorti

Lawrence la questione non è di prendere eBay come simbolo di architettura ideale, e mi sembrava di averlo chiarito da subito.
La questione è piuttosto che si può vivere senza sp, senza integrità referenziale, usare gli ORM, etc. etc. Questa soluzione non solo non compromette l'architettura ma è l'unica soluzione quando le performance e la scalabilità sono il problema numero 1.
In sostanza sto dicendo che non è eresia applicare una o più di quelle soluzioni e che farlo paga fortemente. Ma questo non significa neppure che vada fatto sempre.
Infine dico ancora che eBay non ha inventato nulla, che sono cose che ho letto e discusso già da anni ma che il caso eBay è importante perché dimostra che anche in un sistema così complesso il tutto regge alla grandissima.

29/12/2006 22:29 | Raffaele Rialdi

# re: L'accesso ai dati è cambiato da un pezzo ma gli increduli non se ne sono accorti

Sono stato frainteso, non era una critica a quello che dicevi. Era un avvertimento ai lettori :-)

29/12/2006 22:57 | Lawrence Oluyede

# re: L'accesso ai dati è cambiato da un pezzo ma gli increduli non se ne sono accorti

Mar, se non ti piace l'argomento, ne estraiamo uno a sorte alla settimana ... :-))

Ad ogni modo non sono affatto daccordo con il tuo ragionamento.
Il discorso è partito tanto tempo fa dal fatto che, considerando l'intero ciclo di vita di un software, lo sviluppatore ha certamente vita più facile a scrivere una applicazione multitier rispetto a un client-server. Questa è cosa scontata e consolidata tanto da suscitare stupore in David Chappel per chi fa ancora uso di C-S, come ho scritto nel post.
La strutturazione multitier porta ad usare tutta una serie di cambi di strategia imposti anche dalla necessità di essere disconnessi vista la natura delle reti odierne.

Come oggi non ci si scandalizza più per un accesso disconnesso (ma quando lo dicevo nel '98 la gente mi dava del pazzo), oggi diciamo che la security a livello applicativo con la CAS porta a vantaggi immensi oppure che in tanti casi le stored procedure sono solo un impiccio ed è un bene evitarle.

C'è però qualcuno che crede che le pratiche architetturali usate nel caso eBay siano controproducenti per performance. Bene, il succo di questo post è per portare un caso reale che dimostri che non solo non è vero ma in casi estremi sono anche l'unica soluzione possibile.

Gli altri vantaggi sono evidenti, consolidati, già usati all'epoca COM/DCOM, in evoluzione e miglioramento grazie a SOA e talmente diffusi da essere discutibili solo per i dettagli ma non nella sostanza.

31/12/2006 01:48 | Raffaele Rialdi

# re: L'accesso ai dati è cambiato da un pezzo ma gli increduli non se ne sono accorti

LOL! Dai facciamo tanti post su GUISA da provocare un DoS :)

Prendiamo anche un altro punto di vista. Considera il fatto che gli strumenti del Framework sono totalmente OOP. Se non usi quegli strumenti per lo scopo per cui sono stati creati, è come usare una lavastoviglie per lavare un piagiama.

09/10/2007 15:53 | Raffaele Rialdi

Comments have been closed on this topic.

Web Log di Raffaele Rialdi

My Links

News

Archives

Post Categories

Image Galleries

Blogs

Links