posts - 463, comments - 1515, trackbacks - 139
<< 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 12.22 |

Feedback

Gravatar

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

Perché non si può mai fare a meno di essere d'accordo con te?
29/12/2006 12.27 | David
Gravatar

# 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 12.45 | Davide Mauri
Gravatar

# 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 14.56 | Raffaele Rialdi
Gravatar

# 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 15.20 | Gian Maria
Gravatar

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

Bel PDF e bel case study, ma decisamente è un ambiente non "normale". Quanti siti sono come ebay? La loro decisione è condivisibilissima dato che nasce da un decennio di esperienza e riscritture/miglioramenti. Non va però usata come bandiera per dare addosso ai DB che fanno il loro sporco lavoro nelle situazioni in cui devono farlo. Poi concordo perfettamente con le considerazioni fatte nel PDF. Se devi andare veloce lasciar fare tutto al DB senza "determinismo" può essere una spina nel fianco (forse è per questo che Mysql non aveva nessuna feature relazionale all'inizio?).
29/12/2006 20.11 | Lawrence Oluyede
Gravatar

# 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 20.29 | Raffaele Rialdi
Gravatar

# 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 20.57 | Lawrence Oluyede
Gravatar

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

Ancora con questa storia!!????

Ogni problema va affrontato col giusto strumento!

Se si deve sviluppare una applicazione c/s per tre utenti e il ciclo di vita stimato e' di 10 anni che senso ha mettere mano a qualcosa di diverso dal c/s ? E' sempre meglio usare un db e integrare la b.l. all'interno e fare delle gui per accedere. In fondo se leggi la storia di ebay vedrai che la prima versione e' nata nell stanza da pranzo e certo non si sono messi a fare il pari e disp
30/12/2006 8.23 | mar
Gravatar

# 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.
30/12/2006 23.48 | Raffaele Rialdi
Gravatar

# Architetture d'oggi, DB e normalizzazione

Architetture d'oggi, DB e normalizzazione
08/10/2007 12.10 | Web Log di Raffaele Rialdi
Gravatar

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

Dico la mia dal mio piccolo. Ritengo che il buon compromesso, come segnala anche Davide Mauri, sia proprio la mera conoscenza di entrambi gli strumenti. Non critico Ebay (non ne ho le competenze) ma buttare nel cestino La Normalizzazione dei Db, l' uso di SP performanti, mi sembra eccessivo se andiamo al di fuori dell' esempio che tu citi.
IMHO mettere in paragone un ORM che la Normalizzazione del DB e quanto ne consegue mi sembra eccessivo, pero' forse stiamo andando in contro alla 'rivalutazione' degli strumenti ... Se fosse come dici tu Raf (e per certi casi lo è) a cosa servirebbe avere un DBA su un progetto Enterprise, a nulla, tanto abbiamo l' ORM che ci 'normalizza' secondo la sua logica i dati e il loro accesso ... No non sono daccordo.
08/10/2007 15.22 | Raffaeu
Gravatar

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

Raffaeu, a me sembra che di fondo ci sia una gran paura di andare su una strada che è meno conosciuta... una sorta di paura dell'ignoto.
Nessuno vuole togliere il valore che il DB ha, nessuno vuole togliere il ruolo al DBA. Sto semplicemente dicendo che il ruolo è cambiato parecchio.
Se esiste una base dati da qualche parte, il ruolo del DBA non cesserà mai di esistere. La manutenzione dei dati, monitorare le performance, il backup, e tante altre cose saranno sempre necessarie.

Il punto fondamentale è che i *requisiti* del cliente sulle applicazioni sono cambiate. Questo provoca a profonde trasformazioni nella architettura dell'applicazione. Ma le modifiche non si possono limitare allo strato applicativo. Questi cambiamenti hanno investito in modo trasversale ogni livello, data server compreso.
Quindi? Quindi nuove architetture (peraltro già sperimentate ed attuate fin dall'epoca COM/DCOM) e nuovo modo di impostare *anche* la progettazione del DB e del suo accesso.
08/10/2007 15.55 | Raffaele Rialdi
Gravatar

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

Beh ti rispondo dicendoti: Non ti sembra di stravolgere tutto rivalutando l' architettura del software partendo proprio dal Db? Ok sarà anche cosi', grazie anche al lavoro che stanno facendo ORM come Nhibernate, ma caspita la mia è proprio paura ... mi sembra enorme come salto nel vuoto. Io personalmente senza normalizzazione e SP non avrei le conoscenze per replicare lo stesso via DDD ... ;-)
08/10/2007 22.25 | raffaeu
Gravatar

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

In che senso? OOP dice chiaramente che devi creare un modello che emula una realtà. È di lì che devi partire se vuoi che la tua applicazione funzioni decenemente. Mappare le tue entity su un DB è una faccenda molto secondaria.
Puoi trovare ottimi strumenti di lavoro come nHibernate che ti aiutano a scrivere meno codice manuale ma la sostanza non cambia.

Capisco la paura ma quella si supera proprio studiando senza dare per scontato che ci siano paletti inamovibili. Abbi dubbi ...
09/10/2007 1.09 | Raffaele Rialdi
Gravatar

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

E va bene, esula dalle mie ideologie ma oggi mi degnero' (anche su consiglio di Nilsson il quale mi ha scritto ieri, non ci credo ancora ...) di valutare un ORM. Fino ad oggi mi sono sempre scritto tutto (magari spendendo due mesi solo per un DAL decente) ...
Io oso Raf ma a questo punto faro' aumentare mostruosamente i Post su GUISA ;-)
Concordo sul discorso di emulare la realtà, che spesso differisce dal Db. Come convinciamo Davide di cio'? ;-)
09/10/2007 10.16 | Raffaeu
Gravatar

# 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 12.53 | Raffaele Rialdi

Post Comment

Title  
Name  
Email
Url
Comment   
Please add 8 and 7 and type the answer here:

Powered by:

Copyright © Raffaele Rialdi