S+S o SaaS che sia, attenti alle performance del DB!

scoriani — Fri, 18 Jul 2008 18:16:26 GMT

Ok, siamo una società che sviluppa software per qualche genere di utilizzo, abbiamo capito che oltre ad offrire la versione "installata" fisicamente sui server dei clienti potremmo aprire nuove prospettive commerciali alla nostra azienda offrendo anche l'alternativa del servizio "hosted" direttamente da noi o da altri partner, ad un costo (mensile per utente? per transazione?) sostenibile anche da realtà che in precedenza non avrebbero potuto permetterselo, almeno per quanto riguarda le funzionalità "top" della gamma. Abbiamo iniziato a progettare ("to design", dall'inglese.. :)) la nostra soluzione e dopo esserci letti tutti i libri possibili su Domain Driven Design, Pattern e anti-Pattern, O/RM come la salvezza del mondo civilizzato (just kidding...), dobbiamo iniziare a lavorare... ehm... a pensare a come strutturare i dati gestiti dal nostro sistema. Siamo dunque in un mondo "multi-tenant" visto che dovremo gestire le informazioni dei nostri clienti garantendo il miglior rapporto possibile tra isolamento e prestazioni (perchè sappiamo bene che tutto ha un costo, vero? soprattutto quando parliamo di gestione dati..). Abbiamo quindi una serie di possibilità, oggi ulteriormente estese dalle tecnologie di virtualizzazione, che vanno dal dedicare un singolo DB server fisico per cliente, uno virtualizzato (dimensionando correttamente il rapporto fisico/virtuale, ovviamente), sfruttare le capacità multi-instanza di SQL Server e dedicare una istanza per cliente, ridurre ad un database per cliente, oppure arrivare ad un unico database partizionandolo logicamente per garantire l'isolamento necessario. Ognuna di queste alternativa ha pregi e difetti, difficile trovare LA soluzione, a seconda di quali sono i requisiti tecnici ed economici del progetto. Ovviamente l'ultima soluzione è quella potenzialmente più scalabile a parità di hw, ma è anche quella che richiede un approccio più complesso in fase di progettazione ("to design", sempre in inglese...). E che succede se vogliamo dare agli utenti finali la possibilità di personalizzarsi lo schema del database aggiungendo qualche campo custom? Quale applicazione realizzata dai nostri ISV "nostrani" non lo fa? Le cose si complicano ancora di più...

I colleghi Eugenio Pace e Gianpaolo Carraro ed il loro team nello sviluppo della ormai famosa applicazione LitwareHR hanno analizzato in dettaglio le performance delle diverse alternative legate all'utilizzo di un database condiviso e alle relative tecniche principali per realizzare uno schema "dinamico". Quello che ne è uscito è una interessantissima guida al testing di questa tipologia di soluzioni che permette a chiunque abbia dubbi in questo ambito di provare sul campo la bontà delle diverse scelte nei diversi ambiti della gestione dati.

I risultati non sono stupefacenti, uno schema tradizionale, senza il ricorso a tecniche quali i "campi dinamici" o l'XML, è di gran lunga la soluzione più scalabile, anche se i requisiti a volte potrebbero spingere verso scelte diverse. L'XML è buon ultimo anche se in alcuni ambiti non mi sentirei di sconsigliarlo per partito preso. Suggerisco comunque una lettura attenta, visto che gli spunti interessanti sono molti.

Evangelism 2.0: riflessioni sul business del software da un punto di vista privilegiato! : Data Access

S+S o SaaS che sia, attenti alle performance del DB!