Non mi stanco mai di ripetere che prima di creare qualsiasi cosa su SharePoint (site collection, web, library, lista…) è indispensabile analizzare e progettare “la struttura dei contenitori”.
Questo argomento rientra nel grande tema dell’Architettura dell’Informazione, e deve fare i conti con le limitazioni del prodotto. In particolare quando si parla di Software boundaries.
Si tratta di temi fondamentali in fase di progettazione e capacity planning.
Mi capita troppo spesso di incontrare architettura mal (o per niente) progettate presso i clienti che incontro, dove interi sistemi documentali sono realizzati in un’unica Site collection o –ancora peggio (ma giuro che è vero)- in un’unica Document library!
Desidero riprendere su questo post un paio di “grandi classici”.
Mai solo una Site collection…
Disporre di una sola Site collection significa far nascere il sistema con un limite di scalabilità sullo storage (e sulle performance). Una solo Site collection significa poter disporre di un massimo di un solo Content DB…
Le best practices di Microsoft suggeriscono di non oltrepassare i 200 GB nella crescita del singolo Content DB (anche se personalmente, per ragioni di migliore gestibilità, tendo a suggerire valori molto al di sotto).
Una sola Site collection == Un solo Content DB == Crescita massima 200 GB.
Nelle tante decine di infrastrutture SharePoint analizzate posso dirvi che il limite dei 200 GB l’ho visto più volte superare (ne ho trovati cresciuti fino a 500 GB!), e SharePoint “respirava ancora”… ma questo non significa poter ignorare le buone pratiche.
Non far crescere fuori controllo le liste/library
Una lista o library dispone di un limite fisico di crescita di 30 milioni di elementi. Tuttavia è ben noto il tema del List Threshold, che impone la progettazione dei contenitori e l’organizzazione dei contenuti tenendo conto che SharePoint non gradisce effettuare query su grosse quantità di elementi.
Il valore di default del List Threshold limita ai primi 5.000 items l’esecuzione delle query degli utenti (20.000 items per gli amministratori).
Rimando chi non avesse ancora afferrato il problema alla lettura dell’articolo di Claudio Brotto.
E’ troppo comodo, oltre che sbagliato, intervenire a posteriori sui settings dei Lists Threshold per “risolvere il problema” (nei giorni scorsi ho trovato una Web Application con impostato il valore a 10,5 milioni!).
Il problema non è il fatto che la lista contiene più di 5.000 oggetti, ma il vero problema è che qualcuno non l’ha progettata bene!
Se si prevede una crescita del numero degli oggetti… mai pensare a una sola lista/library, ragionare con logiche di frazionamento degli scopes in folder (magari utilizzando i nativi meccanismi di Autofoldering), ed infine pensare anche alle logiche archiviazione/storicizzazione: i contenuti non sempre ha senso conservarli tutta la vita.
E su SharePoint Online?
Se qualche sviluppatore o sistemista poco attento può anche cercare di riuscire ad eludere parte dei vizi di progettazione, intervenendo con modifiche delle impostazioni della Farm, su SharePoint Online… ci sono poche speranze.
Sapete bene che sull’ambiente Office 365 le nostre Site Collection convivono su un’infrastruttura SharePoint condivisa con altri clienti (tenant). Di conseguenza molte delle impostazioni che su una Farm On-premises sono definibili intervenendo sui server o agendo sulle impostazioni delle Web Application… possiamo scordarcele.
I 5.000 items come limite di list threshold ad esempio? E’ quello, punto e basta.
Non fraintendetemi, non intendo con questo dire che è meglio non usare SharePoint Online… voglio semplicemente dire che avendo a che fare con Office 365 è ancora più importante conoscere i limiti del prodotto e progettare bene.
A proposito, ecco il link ai limiti di SharePoint Online (pagina che ogni tanto viene aggiornata da Microsoft, come è avvenuto nei mesi scorsi innalzando alcuni valori).