Progettazione di elenchi di grandi dimensioni e ottimizzazione delle prestazioni degli elenchi (SharePoint Server 2010)

 

Si applica a: SharePoint Server 2010

Ultima modifica dell'argomento: 2016-11-30

In questo articolo vengono fornite informazioni sulle prestazioni di raccolte documenti e di elenchi di grandi dimensioni. I suggerimenti riportati nell'articolo sono il risultato di una serie di test delle prestazioni eseguiti con Microsoft SharePoint Server 2010. Nell'articolo vengono esaminati principalmente le caratteristiche delle prestazioni di elenchi di grandi dimensioni e l'effetto prodotto da configurazioni diverse sulle prestazioni di elenchi di grandi dimensioni e della farm. I diversi miglioramenti apportati a SharePoint Server 2010 consentono di creare e utilizzare agevolmente elenchi di grandi dimensioni. Per la creazione e l'implementazione di elenchi di grandi dimensioni è ancora necessaria tuttavia una pianificazione accurata. È necessario tenere conto di diversi fattori, ad esempio l'architettura delle informazioni, le prestazioni, il ripristino di emergenza e la governance. In questo articolo vengono illustrate l'architettura delle informazioni e le funzionalità utilizzate per implementare elenchi di grandi dimensioni e viene esaminato l'effetto prodotto da configurazioni specifiche sulle prestazioni.

Anche alcune scelte di progettazione chiave che devono essere effettuate possono avere effetto sulle prestazioni di elenchi di grandi dimensioni, ad esempio le autorizzazioni, il numero di colonne aggiunte a un elenco, il numero di colonne di ricerca nelle visualizzazioni, nonché le cartelle e gli indici utilizzati per organizzare un elenco. Queste decisioni hanno effetto sulle prestazioni degli elenchi e la portata dell'effetto prodotto aumenta con l'aumento delle dimensioni di un elenco. In questo articolo viene illustrato l'effetto prodotto da diverse scelte di progettazione sulle prestazioni di elenchi di grandi dimensioni. In questo modo è possibile progettare correttamente un elenco di grandi dimensioni in grado di soddisfare i requisiti di prestazioni oltre ai requisiti aziendali e di garantire un'esperienza utente soddisfacente.

Benché questo articolo sia specifico di SharePoint Server 2010, le limitazioni e i valori di soglia si applicano anche a Microsoft SharePoint Foundation. Nell'articolo vengono illustrate diverse funzionalità che consentono di migliorare in modo significativo l'utilizzo di elenchi di grandi dimensioni. Queste funzionalità sono disponibili solo in SharePoint Server 2010. Non viene effettuata alcune distinzione tra SharePoint Foundation e SharePoint Server nell'articolo.

Contenuto dell'articolo:

• Informazioni sui metodi di query

• Scenari di esempio di elenchi di grandi dimensioni

• Elenchi di grandi dimensioni e SharePoint Server 2010

• Misurazioni delle prestazioni e metodologia di testing

• Limitazioni e valori di soglia

• Altri limiti

• Differenze tra elenchi di grandi dimensioni ed elenchi normali

• Pianificazione della struttura e dell'implementazione di un elenco di grandi dimensioni

• Conclusioni

Informazioni sui metodi di query

Sono disponibili tre metodi principali per l'accesso ai dati di elenco: visualizzazioni elenco con spostamento basato su metadati, web part Query contenuto e ricerca. Ogni metodo presenta vantaggi, svantaggi e utilizzi particolari.

Visualizzazione elenco e spostamento basato su metadati

Le visualizzazioni elenco accedono sempre al database di Microsoft SQL Server. Ne consegue un rallentamento delle prestazioni delle query e un aumento del carico sulle risorse di SQL Server rispetto agli altri metodi. Le visualizzazioni elenco inoltre eseguono il rendering della quantità massima di HTML, con un conseguente rallentamento dei tempi di caricamento delle pagine rispetto agli altri metodi. Non offrono un'esperienza utente ottimale per la configurazione delle visualizzazioni, il filtro dinamico dei dati e l'esecuzione di azioni sui documenti, ad esempio la gestione delle versioni e la modifica delle proprietà. È possibile utilizzare lo spostamento basato su metadati per filtrare i risultati delle visualizzazioni elenco. È consigliabile utilizzare le visualizzazioni elenco se si desidera ottenere dati formattati in colonna e accedere ad azioni per voci di elenco. In scenari di intense operazioni di lettura e query è consigliabile valutare la possibilità di utilizzare altri metodi di query.

Web part Query contenuto

La web part Query contenuto consente di ottenere una visualizzazione configurata staticamente di dati memorizzati nella cache tramite il provider della mappa del sito portale per garantire prestazioni ottimali. La web part esegue il rendering della quantità minima di HTML e viene memorizzata nella cache. I tempi di caricamento delle pagine pertanto sono più rapidi ed è più semplice eseguire più query su una pagina. È consigliabile utilizzare la web part Query contenuto per mostrare collegamenti a voci di elenco, documenti o pagine correlate. Benché questa web part possa essere configurata anche in modo da non essere memorizzata nella cache, è consigliabile utilizzare questa configurazione solo per pagine con requisiti di velocità effettiva ridotti o per pagine per cui la cache non si rivela utile, ad esempio le pagine in cui le query cambiano in base all'utente che esegue l'accesso.

Ricerca

Le web part per la ricerca possono essere utilizzate per la ripartizione del carico di lavoro delle query in un sistema ottimizzato per la ricerca di contenuto, in contrapposizione alla modifica delle proprietà e alla visualizzazione degli aggiornamenti in tempo reale. Le web part per la ricerca possono essere configurate per utilizzare query statiche o specifiche dell'utente. Queste web part garantiscono prestazioni ottimali, tuttavia i dati sono aggiornati all'ultima ricerca per indicizzazione. I risultati pertanto sono meno recenti rispetto a quelli ottenuti con le visualizzazioni elenco e le web part Query contenuto.

Scenari di esempio di elenchi di grandi dimensioni

Esistono alcuni scenari comuni di grandi dimensioni in base ai quali è possibile effettuare scelte di progettazione diverse. In uno scenario di elenco di grandi dimensioni di collaborazione ad esempio gli utenti aggiungono frequentemente contenuto e aggiornano spesso le proprietà. In questo tipo di scenario non si desidera in genere che la dimensione dell'elenco aumenti fino a raggiungere milioni di voci, perché sarebbe difficile filtrare il contenuto e perché il contenuto viene aggiornato e modificato frequentemente. Se si utilizzano raccolte documenti non strutturate, questo articolo consente di acquisire familiarità con le limitazioni e i valori di soglia che proteggono le prestazioni di SQL Server. Nella tabella seguente vengono riportate alcune considerazioni relative a scenari di elenchi di grandi dimensioni.

Scenario	Dimensione dell'elenco	Gestione	Rapporto operazioni di lettura/aggiornamento/aggiunta	Nuovo contenuto	Utenti
Raccolta documenti non strutturata	Centinaia	Nessun responsabile	Numerose operazioni di lettura, bilanciamento tra operazioni di aggiunta e aggiornamento	Caricamento manuale	Decine
Elenco o raccolta di collaborazione di grandi dimensioni	Migliaia	Proprietari oggetti informali	Numerose operazioni di lettura, più operazioni di aggiornamento che di aggiunta	Caricamento manuale	Centinaia
Archivio strutturato di grandi dimensioni	Decine di migliaia	Amministratore del contenuto dedicato	Numero elevato di operazioni di lettura, ridotto numero di operazioni di aggiunta e numero ancora più ridotto di operazioni di aggiornamento	Invio e caricamento	Decine di migliaia
Archivio su larga scala	Milioni	Team di amministratori del contenuto	Numero ridotto di operazioni di lettura e aggiornamento, numero elevato di operazioni di aggiunta	Invio	Decine di migliaia

Raccolta documenti non strutturata

La raccolta documenti non strutturata viene utilizzata spesso per un team o un gruppo di lavoro e in genere include decine di centinaia di documenti. Queste raccolte possono aumentare fino a raggiungere dimensioni significativamente superiori alla soglia della visualizzazione elenco senza alcuna pianificazione, con conseguenti effetti sulle operazioni, ad esempio l'aggiunta di colonne. Un possibile problema è rappresentato dalla possibilità che gli utenti visualizzino eccezioni di soglia della visualizzazione elenco se le visualizzazioni aumentano fino a includere oltre 5.000 elementi. È possibile ridurre questo rischio monitorando le raccolte che si avvicinano alla soglia della visualizzazione elenco. Nella pagina delle impostazioni delle raccolte viene visualizzato un indicatore per segnalare che la raccolta documenti sta raggiungendo la soglia della visualizzazione elenco.

Questo scenario in genere include decine o addirittura centinaia di utenti, ma pochi utenti simultanei. Il caricamento all'interno di una singola raccolta pertanto costituisce raramente un problema. È possibile tuttavia che siano presenti molte raccolte di questo tipo. Anziché pianificare il supporto per istanze specifiche, è più importante concentrarsi sul supporto della scalabilità di queste raccolte.

Elenco o raccolta di collaborazione di grandi dimensioni

L'elenco di collaborazione di grandi dimensioni include da centinaia a migliaia di elementi e viene utilizzato come spazio di archiviazione per una quantità elevata di contenuto attivo. Questi tipi di elenchi in genere includono soluzioni di gestione delle informazioni, librerie tecniche e archivi di materiale di marketing e vendite. Gli utenti aggiungono e modificano attivamente il contenuto (numero elevato di operazioni di lettura e di scrittura). È possibile applicare una struttura e attività di gestione per mantenere la raccolta organizzata. Poiché tuttavia gli utenti eseguono numerose operazioni, è possibile che si verifichino eventi che sfuggono al controllo degli amministratori. È estremamente probabile pertanto che l'elenco aumenti più velocemente del previsto o superi i limiti per cui è stato pianificato. Questo tipo di archivio può includere centinaia o migliaia di utenti con decine o addirittura centinaia di utenti simultanei.

In confronto a un archivio strutturato, un elenco di collaborazione di grandi dimensioni è maggiormente soggetto a modifiche amministrative, ad esempio l'aggiunta e l'eliminazione di cartelle, l'aggiunta di tipi di contenuto e di colonne o la riorganizzazione del contenuto. Queste azioni possono essere bloccate dalla soglia della visualizzazione elenco a causa della dimensione dell'elenco.

Archivio strutturato di grandi dimensioni

L'archivio strutturato di grandi dimensioni include da migliaia a centinaia di migliaia di elementi. Il contenuto in genere è definito e viene inviato da utenti o processi di sistema, ad esempio flussi di lavoro. Questi tipi di archivi vengono utilizzati generalmente per archivi di record di reparto, per l'archiviazione di documenti importanti e per documenti finali che vengono visualizzati in pagine Web. Il contenuto in genere è strutturato e con gestione avanzata, in modo da facilitare il controllo dell'aumento della dimensione dell'elenco. Questo scenario può prevedere decine o centinaia di utenti simultanei e una base di utenti dell'ordine delle migliaia. La percentuale delle operazioni di lettura è significativamente superiore alle operazioni di scrittura. È possibile tuttavia che si verifichino alcune operazioni di aggiornamento del contenuto, così come di aggiunta ed eliminazione di contenuto. Un archivio di gestione delle informazioni per una divisione o un'organizzazione è un esempio di archivio strutturato di grandi dimensioni.

In questo scenario è importante conoscere in modo dettagliato le esigenze degli utenti ed eseguire test completi prima di rendere operativa la soluzione. La soluzione pertanto è praticamente completa e definitiva prima dell'inserimento di una quantità elevata di contenuto. Potrebbe essere necessario ad esempio configurare gerarchie appropriate di spostamento basato su metadati e di filtri per garantire funzionalità di esplorazione del contenuto appropriate.

Archivio su larga scala

Un archivio su larga scala include da migliaia a milioni di elementi, contenuti in un unico elenco o distribuiti in più elenchi oppure, in casi estremi, in più raccolte siti. Questo scenario in genere prevede un numero ridotto di operazioni di lettura e aggiornamento e viene utilizzato solo come spazio di archiviazione a lungo termine per documenti che devono essere conservati per conformità o per altri motivi, ad esempio documenti che devono essere conservati per 7 anni per soddisfare requisiti legali. In questo scenario è importante una velocità effettiva elevata dell'invio e dell'eliminazione dei documenti. Il metodo principale utilizzato per recuperare il contenuto è la ricerca.

Elenchi di grandi dimensioni e SharePoint Server 2010

Le funzionalità che si sono rivelate utili con gli elenchi di grandi dimensioni in Office SharePoint Server 2007 sono utili anche con SharePoint Server 2010 e molte di esse sono state migliorate per ottimizzare le prestazioni su larga scala. In SharePoint Server 2010 inoltre sono disponibili molte nuove funzionalità che consentono di migliorare le prestazioni di elenchi di grandi dimensioni e agli utenti di utilizzare elenchi di grandi dimensioni in modo efficace. In questa sezione vengono riepilogate le funzionalità nuove e migliorate disponibili in SharePoint Server 2010.

Funzionalità migliorate

Nelle sezioni seguenti vengono illustrate le funzionalità di Microsoft Office SharePoint Server 2007 che sono state migliorate in SharePoint Server 2010.

Web part Query contenuto

È possibile configurare la web part Query contenuto in modo da visualizzare i risultati filtrandoli in base agli elenchi, ai tipi di contenuto e alle colonne. È possibile ordinare i risultati e selezionare le colonne da visualizzare. Grazie a queste caratteristiche, la web part Query contenuto è la soluzione ideale per visualizzare il contenuto di elenchi di grandi dimensioni nelle pagine Web. Le web part Query contenuto in genere sono memorizzate nella cache, in modo da garantire un più rapido caricamento delle pagine e un minor carico sul database. Queste web part vengono utilizzate negli scenari di gestione delle informazioni nelle pagine di pubblicazione per visualizzare collegamenti a documenti correlati al contenuto della pagina Web.

In SharePoint Server 2010 sono stati apportati miglioramenti delle prestazioni negli scenari chiave seguenti:

• Ottimizzazione di query di tipo elenco singolo per un utilizzo più efficiente degli indici

• Miglioramento degli algoritmi di aggiornamento e invalidamento e delle impostazioni predefinite per ottimizzare l'utilizzo della cache quando gli utenti eseguono operazioni di scrittura

Ricerca

In SharePoint Server 2010 sono disponibili nuove funzionalità di ricerca che includono un riquadro di perfezionamento dei termini di ricerca e una maggiore scalabilità, che supporta una latenza di query inferiore al secondo con 100 milioni di documenti. È inoltre possibile utilizzare Microsoft FAST Search Server 2010 for SharePoint per estendersi su scala maggiore rispetto al servizio di ricerca di SharePoint Server 2010.

Alcuni dei nuovi miglioramenti apportati alla ricerca che consentono di trovare il contenuto desiderato in elenchi di grandi dimensioni includono il supporto degli operatori booleani in query free-text, un maggiore supporto di operatori quali uguale a, minore di e maggiore di, perfezionamenti degli intervalli e corrispondenza dei prefissi nelle parole chiave e nelle proprietà. Con la query "share*" ad esempio vengono restituiti risultati che includono "SharePoint". Nel servizio di ricerca sono disponibili inoltre suggerimenti di query che propongono indicazioni in base a quanto viene digitato dall'utente in una query. L'interfaccia utente di ricerca è stata inoltre migliorata con riquadri per le ricerche correlate, gli elementi di maggiore rilevanza, le persone correlate e perfezionamenti di parole chiave.

Nel servizio di ricerca di SharePoint Server 2010 sono state migliorate inoltre le funzionalità di scalabilità. Il servizio di ricerca di SharePoint Server 2010 supporta la scalabilità orizzontale dei server di indicizzazione, di ricerca per indicizzazione e di query. Altri miglioramenti includono indici più aggiornati, una migliore resilienza e una maggiore disponibilità. FAST Search Server 2010 for SharePoint include tutte le funzionalità del servizio di ricerca di SharePoint Server 2010 e aggiunge la scalabilità per richieste elevate, estrazione delle entità, classificazione per pertinenza ottimizzabile, elementi visivi di maggiore rilevanza, miniature e anteprime.

Modelli di sito Centro documenti e Centro record

Centro documenti e Centro record sono modelli di sito di SharePoint Server 2010 che possono essere utilizzati per creare archivi strutturati. Il modello Centro documenti include funzionalità quali web part Query contenuto preconfigurate per la restituzione di risultati pertinenti da parte di utenti che hanno eseguito l'accesso e una raccolta documenti con lo spostamento basato su metadati configurato.

Il modello di sito Centro record è simile a Centro documenti, con la differenza che la funzionalità Content Organizer è abilitata per la distribuzione dei documenti ed è supportata una raccolta record i cui elementi aggiunti vengono automaticamente dichiarati come record e non possono essere eliminati. Centro record è l'unico modello di sito predefinito in cui non è abilitato il parser di documenti, in modo da preservare la fedeltà del contenuto inviato. La disabilitazione del parser dei documenti ha effetto sulle prestazioni di alcune operazioni, rendendo questo modello di sito più appropriato per l'archiviazione di documenti su larga scala (decine di milioni di elementi) rispetto ad altri modelli di sito.

Nuove funzionalità

In questa sezione vengono descritte nuove funzionalità di SharePoint Server 2010 che consentono di gestire elenchi di grandi dimensioni e le prestazioni degli elenchi.

Content Organizer

La funzionalità Content Organizer può essere utilizzata in qualsiasi sito per distribuire il contenuto in raccolte documenti o cartelle specifiche oppure addirittura in altri siti. È possibile utilizzare Content Organizer per creare automaticamente cartelle per contenuto basato su proprietà di metadati. Gli utenti possono inviare contenuto a Content Organizer da altri siti senza preoccuparsi della posizione in cui viene archiviato nel piano file. La funzionalità Content Organizer può essere utilizzata per bilanciare il contenuto in cartelle diverse in modo da rispettare automaticamente una dimensione massima per ogni cartella. Quando viene raggiunto il limite di dimensione specificato, viene creata una nuova sottocartella per contenere gli elementi aggiuntivi.

Spostamento basato su metadati

Lo spostamento basato su metadati è una nuova funzionalità di SharePoint Server 2010 che consente agli utenti di filtrare gli elenchi in modo dinamico per trovare le informazioni desiderate. Questa funzionalità consente agli utenti di selezionare opzioni di filtro e gestisce l'esecuzione delle query con la maggiore efficienza possibile. Lo spostamento basato su metadati è costituito da due parti. Una parte è rappresentata da un insieme di controlli di spostamento che consentono a un utente di filtrare un elenco con gerarchie di spostamento e filtri chiave. La seconda parte è rappresentata da un meccanismo per la ridisposizione e la riesecuzione di query.

Lo spostamento basato su metadati è dotato di una logica per l'esecuzione di nuovi tentativi e di fallback che tenta di eseguire query in modo efficiente utilizzando gli indici. Se una query restituisce troppi risultati, per garantire prestazioni ottimali viene eseguito il fallback e viene restituito un sottoinsieme dei risultati. Se non è possibile eseguire una query appropriata, si verifica il fallback e i filtri vengono applicati su un insieme limitato di risultati. Lo spostamento basato su metadati crea automaticamente gli indici. La gestione dei nuovi tentativi, del fallback e degli indici conferisce allo spostamento basato su metadati un ruolo importante per l'utilizzo efficiente di elenchi di grandi dimensioni. Sono disponibili due tipi di meccanismi di filtro: le gerarchie di spostamento e i filtri chiave.

Le gerarchie di spostamento si basano su un controllo albero per l'esplorazione delle gerarchie di cartelle, dei tipi di contenuto, dei campi di opzioni o dei set di termini di metadati gestiti. In questo modo gli utenti possono utilizzare un controllo albero per eseguire il pivot della gerarchia di metadati nello stesso modo in cui esplorano le cartelle. Quando gli utenti selezionano un elemento in una gerarchia per una colonna di metadati gestiti, vengono visualizzati tutti gli elementi che corrispondono al termine specificato o a uno dei relativi termini figlio discendenti. Questa operazione è denominata inclusione dei discendenti e può essere utilizzata nei campi collegati a un set di termini di metadati gestiti. Gli utenti possono selezionare di nuovo l'elemento per filtrare solo in base al termine specifico senza includere i termini figlio discendenti. Tutte le query di spostamento basato su metadati sono ricorsive e visualizzano risultati da tutte le altre cartelle dell'elenco.

I filtri chiave possono essere configurati per filtrare ulteriormente i risultati nella gerarchia. È ad esempio possibile aggiungere la colonna Modificato da come filtro chiave e quindi digitare un nome utente per ottenere risultati in cui il valore di Modificato da corrisponde al nome utente immesso. Per ulteriori informazioni, vedere Spostamento basato su metadati e applicazioni di filtri (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=219154&clcid=0x410) (le informazioni potrebbero essere in lingua inglese). Nella figura seguente viene illustrato un esempio di gerarchie di spostamento basato su metadati e di filtri chiave.

Metadati gestiti

I metadati gestiti rappresentano un nuovo insieme di funzionalità aggiuntivo per l'architettura delle informazioni di SharePoint Server. Queste funzionalità includono un servizio condiviso denominato servizio metadati gestiti. Questo servizio può essere utilizzato per archiviare set di termini che possono essere riutilizzati in una distribuzione di SharePoint Server 2010. Vengono elencate di seguito alcune caratteristiche delle funzionalità di metadati gestiti:

• Set di termini che supportano gerarchie semplici o con numerosi livelli

• Tipo di colonna di metadati gestiti in cui vengono utilizzati i set di termini come proprietà disponibili

• Set di termini che possono essere aperti, in modo che chiunque possa aggiungere nuovi termini, oppure con restrizioni, in modo che solo utenti specifici possano gestire il set di termini

Utilizzando le colonne di metadati gestiti e i set di termini per organizzare il contenuto, è possibile usufruire di funzionalità quali la web part Query contenuto e lo spostamento basato su metadati per consentire agli utenti di trovare e individuare il contenuto. I metadati gestiti si rivelano utili inoltre con le query di ricerca normali, poiché aggiungono parole chiave che possono essere utilizzate per la classificazione di documenti. I metadati gestiti possono essere utilizzati nel riquadro di perfezionamento della ricerca. Nella figura seguente viene illustrato un esempio di spostamento basato su metadati gestiti.

Limitazioni e valori di soglia

In SharePoint Server 2010 sono stati introdotti diversi limiti configurabili per le prestazioni della farm. Sono ora disponibili a livello delle applicazioni Web limitazioni e valori di soglia configurabili, che sono stati aggiunti in modo che le operazioni eseguite da singoli utenti o processi non abbiano effetti negativi sulle prestazioni. La soglia della visualizzazione elenco ad esempio è un limite che impedisce l'esecuzione di query che hanno effetto su un determinato numero di voci di elenco.

Indici composti

Gli indici sono importanti per gli elenchi di grandi dimensioni. In SharePoint Server 2010 è ora possibile creare indici composti, che si rivelano utili quando le query vengono eseguite comunemente su due colonne, poiché una query su una colonna potrebbe non essere sufficientemente selettiva. Gli indici composti non vengono utilizzati dalle visualizzazioni, mentre vengono utilizzati dallo spostamento basato su metadati. Quando si verifica una condizione di limitazione, la logica dello spostamento basato su metadati può ripetere l'operazione e utilizzare indici composti e indici singoli applicabili per le condizioni di filtro scelte per trovare risultati completi o parziali che soddisfino la query.

Dashboard di sviluppo

Nel dashboard di sviluppo vengono visualizzate informazioni diagnostiche dettagliate per il caricamento di ogni pagina. Per impostazione predefinita, il dashboard è disattivato. È comunque possibile attivarlo manualmente oppure configurarlo in modo che sia sempre attivo. Quando il dashboard di sviluppo è attivo, è possibile utilizzarlo per ottenere informazioni sulle query su database, i tempi di caricamento e gli errori. Il dashboard di sviluppo semplifica e velocizza l'analisi e la diagnosi di problemi di prestazioni. Nella figura seguente viene mostrato il dashboard di sviluppo. La funzionalità spostamento basato su metadati è visibile nel dashboard di sviluppo in caso di elenchi di grandi dimensioni e di condizioni di limitazione dove l'elenco di indici utilizzato per i nuovi tentativi e i risultati parziali viene visualizzato nell'albero delle operazioni a sinistra e le diverse query di SQL Server indicizzate di cui viene tentata l'esecuzione vengono visualizzate nell'elenco a destra.

Il dashboard di sviluppo si rivela utile anche per il debug di web part e query personalizzate. Per ulteriori informazioni su come abilitare il dashboard di sviluppo, vedere Blog: Attivare il dashboard di sviluppo utilizzando il modello a oggetti / Powershell (le informazioni potrebbero essere in lingua inglese) (https://go.microsoft.com/fwlink/?linkid=219613&clcid=0x410) (le informazioni potrebbero essere in lingua inglese).

Iteratore di contenuto

L'API di sviluppo iteratore di contenuto semplifica la scrittura di codice per elenchi di grandi dimensioni ed è particolarmente importante con il nuovo limite di soglia della visualizzazione elenco. L'iteratore di contenuto è un metodo che consente di recuperare il contenuto per eseguire operazioni su di esso in piccoli insiemi anziché utilizzare l'intero set di dati. In questo modo si evita che le operazioni possano superare la soglia della visualizzazione elenco.

Archiviazione BLOB remoti

Per impostazione predefinita, in SharePoint Server 2010 i dati di file BLOB (Binary Large Object, oggetti binari di grandi dimensioni) vengono archiviati in database di SQL Server. Una larga parte di un database del contenuto è costituita comunemente da dati BLOB. Archiviazione BLOB remoti consente di archiviare questi dati all'esterno di SQL Server, in modo da utilizzare opzioni di archiviazione meno onerose e ridurre le dimensioni dei database del contenuto. Archiviazione BLOB remoti è un set di API di libreria incorporato come Feature Pack aggiuntivo per SQL Server 2008. Per utilizzare l'API Archiviazione BLOB remoti è necessario un provider di Archiviazione BLOB remoti di terze parti.

Misurazioni delle prestazioni e metodologia di testing

In questa sezione è una inclusa una descrizione della metodologia di testing utilizzata per i test illustrati nell'articolo. Eventuali deviazioni da questa metodologia vengono segnalate insieme ai dati.

Configurazione di hardware e farm

Nella tabella e nelle figure seguenti viene specificata la configurazione della farm di testing. Due aspetti della configurazione di testing si discostano in modo significativo dalla maggior parte delle distribuzioni reali, ovvero:

• È stata utilizzata l'autenticazione NTLM per evitare che il controller di dominio si trasformasse in un collo di bottiglia. Questa scelta ha determinato un lieve miglioramento delle prestazioni.

• Nel server applicazioni è stata inclusa un'istanza di SQL Server per il database di registrazione. In questo modo è stato possibile ridurre il carico sull'istanza principale di SQL Server, poiché il livello di registrazione era significativamente superiore rispetto a quello di una distribuzione reale.

Nome computer	Due server Web	Un server applicazioni	Un server di database
Ruolo	Server Web front-end	Server applicazioni	Istanza di SQL Server
Processori	2px4c a 2,33 GHz	2px4c a 2,33 GHz	4px2c a 3,19 GHz
RAM	8 GB	8 GB	32 GB
Sistema operativo	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64
Archiviazione e geometria (inclusa la configurazione dei dischi di SQL Server)	50 + 18 + 205 GB	50 + 18 + 300 GB	Array di dischi - 15 dischi da 450 GB a 15 K RPM
Numero di schede di interfaccia di rete (NIC)	2	2	2
Velocità schede di interfaccia di rete	1 gigabit	1 gigabit	1 gigabit
Autenticazione	NTLM	NTLM	NTLM
Versione software	SharePoint Server 2010 (versione non definitiva)	SharePoint Server 2010 (versione non definitiva) SQL Server 2008 CTP 3	SQL Server 2008 CTP 3
Numero di istanze di SQL Server	N/D	1	1
Tipo di servizio di bilanciamento del carico	Hardware	N/D	N/D
Impostazioni cache di output
Impostazioni cache oggetti
Impostazioni cache BLOB
Livello di registrazione ULS	Medio	Medio	Medio
Posizione del database servizio di utilizzo		X
Impostazioni del database servizio di utilizzo (elementi registrati)
Impostazioni IRM	Nessuna	Nessuna	Nessuna
Impostazione antivirus	Nessuna	Nessuna	Nessuna

Tipo di database	Numero di database	Configurazione RAID
Database temporaneo	1	0
Database di configurazione	1	0
Database del contenuto n. 1	1	0
Database dei profili	1	0
Database di ricerca	1	0
Database della tassonomia	1	0

Carico del test

Sono stati eseguiti test con un punto di carico ottimale, o area grigia, con una combinazione di operazioni. Per misurare modifiche specifiche, sono stati eseguiti test in ogni punto in cui è stata modificata una variabile. Per trovare il punto di carico ottimale, sono stati aggiunti ulteriori thread per saturare l'ambiente mantenendolo comunque sempre al di sotto delle metriche seguenti:

• Latenza inferiore al secondo al 75° percentile

• Utilizzo della CPU del server Web front-end inferiore al 50%

• Utilizzo della CPU di SQL Server inferiore al 50%

• Utilizzo della CPU del server applicazioni inferiore al 50%

• Frequenza degli errori inferiore allo 0,01%

Definizioni di test

Nella tabella seguente vengono fornite una definizione dei test e una panoramica del processo utilizzato per ogni test.

Nome test	Descrizione test
Caricamento documento	Caricare un documento. Modificare e aggiornare le proprietà del documento.
Caricamento e distribuzione documento	Caricare un documento. Modificare e aggiornare le proprietà del documento. Distribuire il documento in base a una regola di distribuzione.
Download documento	Scaricare un documento.
Accesso raccolta documenti	Accedere a una pagina visualizzazione elenco raccolta documenti.
Accesso home page con web part Query contenuto	Accedere alla home page di un sito Centro documenti contenente tre web part Query contenuto. La web part Query contenuto memorizzata nella cache restituisce 15 documenti con valutazioni più elevate. La web part Query contenuto memorizzata nella cache restituisce i 15 documenti più recenti. La web part Query contenuto non memorizzata nella cache restituisce i 15 elementi più recenti modificati dall'utente corrente.
Query di fallback di metadati gestiti	Query visualizzazione elenco che restituisce più di 5.000 risultati, filtrando in base a una colonna di metadati gestiti a valore singolo.
Query selettiva di metadati gestiti	Query visualizzazione elenco che restituisce 1.000 risultati, filtrando in base a una colonna di metadati gestiti a valore singolo.
Query di fallback di tipo di contenuto	Query visualizzazione elenco che restituisce più di 5.000 risultati, filtrando in base al tipo di contenuto.
Query selettiva di tipo di contenuto	Query visualizzazione elenco che restituisce 1.000 risultati, filtrando in base al tipo di contenuto.

Combinazione di test

È stata utilizzata una composizione di combinazione di test variabile. I test sono stati effettuati utilizzando un sistema Visual Studio Test. Sono stati inseriti dati per coordinate specifiche per ogni test e quindi la combinazione di test è stata eseguita per 2 minuti di riscaldamento e 10 minuti di raccolta dati. I risultati presentati nell'articolo sono calcolati sulla media di questi 10 minuti. Nella tabella seguente viene mostrata la percentuale di ogni soluzione in una combinazione di test.

Nome soluzione	Percentuale nella combinazione
Caricamento documento (inclusa la modifica delle proprietà del documento)	20
Download documento	20
Accesso raccolta documenti	20
Accesso home page con web part Query contenuto	10
Query di fallback di metadati gestiti (più di 5.000 risultati)	5
Query selettiva di metadati gestiti (100 risultati)	10
Query di fallback di tipo di contenuto (più di 5.000 risultati)	5
Query selettiva di tipo di contenuto (100 risultati)	10

Limitazioni e valori di soglia

I limiti consentono di bloccare operazioni che producono effetti negativi sulle prestazioni della farm. Questi valori predefiniti sono stati testati e selezionati accuratamente. Per alcuni limiti, ad esempio la soglia della visualizzazione elenco, è consigliabile non apportare modifiche. Valutare attentamente l'effetto prodotto dalla modifica di questi limiti. Se questi limiti impediscono l'esecuzione di un'operazione, valutare innanzitutto la possibilità di modificare l'operazione per l'esecuzione in una modalità con indicizzazione più efficiente anziché modificare il limite per adattarlo a operazioni con prestazioni insufficienti. La maggior parte delle limitazioni e dei valori di soglia indicati in questa sezione può essere configurata in Amministrazione centrale accedendo a Gestisci applicazioni Web e selezionando Impostazioni generali - Limitazione risorse sulla barra multifunzione di un'applicazione Web specifica.

Soglia della visualizzazione elenco

SharePoint Server 2010 supporta raccolte documenti ed elenchi contenenti decine di milioni di elementi. È possibile creare raccolte documenti di dimensioni elevate utilizzando cartelle, visualizzazioni standard, gerarchie di siti e lo spostamento basato su metadati. Per recuperare i dati da elenchi di grandi dimensioni utilizzando visualizzazioni elenco o query CAML (Collaborative Application Markup Language), è necessario suddividere i dati utilizzando cartelle, indici o entrambe le soluzioni. Altrimenti, l'unico meccanismo utilizzabile per accedere in modo efficiente ai dati è la ricerca. Il numero di elementi supportati in una singola raccolta documenti dipende dal modo in cui sono organizzati i documenti e le cartelle, dalle dimensioni e dai tipi di documenti archiviati, dall'utilizzo della raccolta documenti e dal numero di colonne presenti nella raccolta documenti.

Per impostazione predefinita, la soglia della visualizzazione elenco impedisce l'esecuzione di operazioni con più di 5.000 elementi, ad esempio l'esecuzione di query che restituiscono più di 5.000 risultati oppure l'aggiunta di una colonna a un elenco contenente più di 5.000 elementi. Benché questo valore predefinito sia configurabile, è consigliabile lasciarlo invariato. Se vengono utilizzate query con prestazioni ridotte per elenchi con più di 5.000 elementi, è possibile che la velocità effettiva totale diminuisca in modo significativo se si aumenta questo limite.

Alcune operazioni, ad esempio l'esecuzione di query non indicizzate o l'aggiunta di una colonna a un elenco, richiedono tempo e risorse in proporzione al numero di elementi contenuti nell'elenco. Nel caso di un elenco di piccole dimensioni, questo requisito non riveste alcuna importanza poiché il numero di elementi è talmente ridotto che l'operazione viene eseguita rapidamente. Man mano che le dimensioni dell'elenco aumentano, le operazioni richiedono più tempo e più risorse. Anziché eseguire queste operazioni senza limitazioni, con la soglia della visualizzazione elenco è possibile impedirne l'esecuzione. La soglia della visualizzazione elenco può essere considerata come il guard rail di un'autostrada che indica quando è opportuno modificare la query e come viene eseguito l'accesso ai dati oppure che è consigliabile eseguire l'operazione nei momenti di utilizzo ridotto della farm.

Per soglia della visualizzazione elenco si intende il numero massimo di elementi di una raccolta o di un elenco su cui è possibile eseguire contemporaneamente un'operazione di database, ad esempio una query. Per impostazione predefinita, questo valore è impostato su 5.000 elementi. Questo limite ha un effetto maggiore su elenchi di grandi dimensioni poiché, per la definizione di questa soglia, un elenco di grandi dimensioni è un elenco che include più elementi di quelli indicati dal limite. Le operazioni che superano questa soglia vengono limitate. Operazioni come la creazione di un indice in un elenco che supera questo limite sono bloccate poiché hanno effetto su più di 5.000 elementi. Questo limite impedisce l'esecuzione di query con una selettività (elementi che possono essere filtrati correttamente utilizzando i criteri di filtro) di oltre 5.000 elementi. Questo limite impedisce inoltre l'esecuzione di query che applicano filtri in base alle colonne non indicizzate. Una query che filtra e in alcuni casi ordina in base a una colonna non indicizzata deve eseguire infatti il filtro su tutti gli elementi dell'elenco per recuperare il set di dati corretto e agirà pertanto su più elementi di quelli previsti dalla soglia della visualizzazione elenco. Il valore predefinito di questo limite è basato sulle prestazioni della farm e dell'elenco e sul modo in cui SQL Server gestisce i blocchi. È consigliabile lasciare invariata questa impostazione.

Per ridurre al minimo il rischio di conflitti tra database, in SQL Server viene utilizzato il blocco a livello di riga come strategia per garantire aggiornamenti accurati senza influire negativamente sugli utenti che accedono ad altre righe. Se tuttavia un'operazione di database di lettura o scrittura, ad esempio una query, blocca più di 5.000 righe contemporaneamente, è più efficiente per SQL Server eseguire l'escalation del blocco nell'intera tabella fino al completamento dell'operazione di database. Quando si verifica questa escalation del blocco, non è possibile per gli altri utenti accedere alla tabella. Per ulteriori informazioni sui blocchi, vedere Escalation blocchi (Motore di database) (https://go.microsoft.com/fwlink/?linkid=219156&clcid=0x410).

Nel grafico seguente viene mostrata la velocità effettiva di una combinazione di query in un elenco di grandi dimensioni con lo modifica della soglia della visualizzazione elenco. Questa combinazione di query include query che restituiscono tutti gli elementi dell'elenco e pertanto, con l'aumento del valore di soglia della visualizzazione elenco, vengono restituiti più elementi. Anche la modifica del limite predefinito da 5.000 a 10.000 produce un effetto significativo sulle prestazioni. Anziché aumentare o ridurre la soglia della visualizzazione elenco per migliorare le prestazioni, è consigliabile non modificare il valore di soglia predefinito e verificare piuttosto che le query vengano eseguite correttamente.

Le eccezioni di soglia della visualizzazione elenco si verificano per prestazioni delle operazioni insufficienti. È consigliabile riconfigurare le operazioni. Anziché aumentare il limite, valutare perché vengono eseguite operazioni non efficienti e quindi correggerle. In uno scenario meno favorevole è possibile modificare temporaneamente l'opzione EnableThrottling impostandola su false in modo che un elenco specifico ignori la soglia della visualizzazione elenco. Questa operazione può essere eseguita solo a livello di elenco e non per un sito. È consigliabile eseguirla per consentire l'accesso all'elenco solo finché non vengono apportate modifiche per correggere operazioni con prestazioni insufficienti bloccate dalla soglia della visualizzazione elenco L'opzione EnableThrottling deve essere reimpostata su true il prima possibile.

Gli amministratori delle farm e dei computer locali nel server Web front-end da cui origina una query non sono bloccati dalla soglia della visualizzazione elenco. Questi utenti devono procedere con cautela quando accedono a elenchi di grandi dimensioni non configurati correttamente e quando eseguono il testing. Potrebbe sembrare apparentemente che tutto funzioni come previsto, ma i dati che vengono restituiti agli utenti possono essere molto diversi. Per un elenco delle operazioni bloccate dalla soglia della visualizzazione elenco, vedere Operazioni bloccate dalla soglia della visualizzazione elenco più avanti in questo articolo.

Analogamente, i servizi timer possono essere eseguiti utilizzando un account non protetto dalla soglia della visualizzazione elenco. Benché in questo modo vengano abilitati alcuni scenari, ad esempio la creazione rinviata di un indice in un elenco di grandi dimensioni, è consigliabile in genere prestare particolare attenzione e verificare che il codice eviti di eseguire operazioni su elenchi di grandi dimensioni.

Soglia visualizzazione elenco

Impostazione predefinita: 5.000	Disponibile nella versione 2007: no	Configurabile: sì
Percorso di configurazione: Amministrazione centrale, per ogni applicazione Web

Soglia visualizzazione elenco per controllori e amministratori

Impostazione predefinita: 20.000	Disponibile nella versione 2007: no	Configurabile: sì
Percorso di configurazione: Amministrazione centrale, per ogni applicazione Web

La soglia della visualizzazione elenco per controlli e amministratori viene utilizzata per alcuni account di servizio, ad esempio l'account delle query di ricerca oppure gli account lettore con privilegi avanzati e autore con privilegi avanzati della cache oggetti. La web part Query contenuto ad esempio utilizza automaticamente questo limite per memorizzare nella cache i risultati di una query di grandi dimensioni, evitando così di utilizzare le risorse del server. È possibile utilizzare codice personalizzato per richiedere l'utilizzo di questo limite superiore con un account lettore o autore con privilegi avanzati in base al criterio di sicurezza dell'applicazione Web.

Ignora modello a oggetti

Impostazione predefinita: Sì	Disponibile nella versione 2007: no	Configurabile: sì
Percorso di configurazione: Amministrazione centrale, per ogni applicazione Web

Consentendo di ignorare il modello a oggetti, si specifica se gli account di servizio possono utilizzare la soglia della visualizzazione elenco per i controllori e gli amministratori. Un amministratore di farm deve abilitare l'impostazione per ignorare il modello a oggetti e deve indicare a livello di programmazione che un elenco rappresenta un'eccezione. I programmatori con autorizzazioni appropriate possono quindi richiedere a livello di programmazione che nella query o nell'elenco venga utilizzata la dimensione di soglia della visualizzazione elenco maggiore per i controllori e gli amministratori. Modificando il valore e impostandolo su no, il codice personalizzato eseguito dai controllori o dagli amministratori sarà soggetto alla soglia della visualizzazione elenco anziché al limite più alto previsto per i controlli e gli amministratori, anche se richiede un override. È consigliabile lasciare invariata l'impostazione predefinita di questa opzione e configurare la soglia della visualizzazione elenco solo per i controllori e gli amministratori, se necessario.

Periodo di tempo durante la giornata per query con numerosi elementi

Impostazione predefinita: disattivata	Disponibile nella versione 2007: no	Configurabile: sì
Percorso di configurazione: Amministrazione centrale, per ogni applicazione Web

È possibile impostare un periodo di tempo per l'esecuzione di operazioni senza essere soggetti ai vincoli della soglia della visualizzazione elenco. L'intervallo di tempo può essere definito con incrementi di 15 minuti fino a 24 ore. Un'operazione di database o una query avviata entro il periodo di tempo specificato continua fino al completamento, anche se supera il periodo di tempo indicato. Per impostazione predefinita, questo intervallo di tempo non è configurato, poiché le fasce orarie non di punta variano in modo significativo a seconda delle distribuzioni. La decisione pertanto spetta all'amministratore. È consigliabile specificare questo periodo di tempo solo se è disponibile un intervallo di tempo ragionevole in cui l'applicazione Web viene utilizzata da pochi utenti. In questo modo è possibile eseguire operazioni amministrative su elenchi di grandi dimensioni, ad esempio creare un indice, nelle fasce orarie in cui l'utilizzo della farm è meno intenso.

Autorizzazioni univoche

Con l'aumento del numero di autorizzazioni univoche in un elenco, si verifica una costante riduzione delle prestazioni. È consigliabile rivedere strutture in cui tutto o la maggior parte del contenuto di un elenco di grandi dimensioni deve essere protetto in modo univoco. La differenza di velocità effettiva per le operazioni eseguite su un elenco con un numero di autorizzazioni univoche compreso tra 0 e 1.000 è di circa il 20%. È prevista un'impostazione predefinita configurabile di 50.000 autorizzazioni univoche per elenco. È consigliabile tuttavia valutare la possibilità di ridurre questo limite a 5.000 autorizzazioni univoche e, per gli elenchi di grandi dimensioni, di utilizzare una struttura con il minor numero possibile di autorizzazioni univoche. In questo modo si otterranno vantaggi sia a livello di prestazioni che di gestibilità.

È consigliabile attenersi alle indicazioni seguenti:

• Ridurre l'utilizzo di autorizzazioni univoche per singoli elementi e semplificare le strutture degli elenchi che richiedono per la maggior parte degli elementi autorizzazioni univoche.

• Se sono necessarie autorizzazioni univoche, provare a impostarle solo a livello di elenco o di cartella e ridurre il numero di singoli elementi che richiedono autorizzazioni univoche.

• Rivedere la struttura se ogni elemento richiede autorizzazioni singole. Valutare la possibilità di dividere gli elementi tra più elenchi oppure organizzare gli elementi in cartelle e gruppi in modo da poter concedere l'accesso appropriato senza applicare autorizzazioni univoche per ogni elemento.

L'impostazione di autorizzazioni specifiche può influire sulle prestazioni ed è inoltre difficile da gestire se definita in modo diverso per più elementi singoli. L'impostazione di autorizzazioni specifiche per un elenco o una cartella che supera la soglia della visualizzazione elenco verrà bloccata perché devono essere aggiornati troppi elementi singoli. Questo tipo di impostazione tuttavia influisce sulle prestazioni anche in altri modi. È previsto pertanto un limite configurabile che per impostazione predefinita è di 50.000 autorizzazioni univoche per elenco. Se si tenta di dichiarare autorizzazioni univoche dopo che è stato raggiunto questo limite, l'operazione verrà bloccata. Diversamente dalla soglia della visualizzazione elenco, questo limite si applica quando si creano autorizzazioni univoche per un elemento anziché in fase di esecuzione di query.

Ogni volta che viene interrotta l'ereditarietà delle autorizzazioni per un elemento, ad esempio una cartella, viene conteggiata un'autorizzazione univoca che va ad aggiungersi al numero di autorizzazioni che devono rientrare nel valore limite. Con ogni interruzione dell'ereditarietà delle autorizzazioni, viene creato un nuovo ID di ambito. A ogni esecuzione di query su una visualizzazione, viene eseguito un join con la tabella degli ambiti. Quando successivamente viene eseguita una query, deve essere analizzato ed elaborato ogni elenco di controllo di accesso univoco (ACL). Non è consigliabile utilizzare un numero elevato di autorizzazioni univoche in un elenco, poiché influisce negativamente sulle prestazioni. Con l'aumento del numero di autorizzazioni univoche in un elenco, le prestazioni delle query subiscono effetti negativi. Anche se il limite predefinito è di 50.000 autorizzazioni univoche, valutare la possibilità di ridurre questo limite a 5.000 autorizzazioni univoche.

Autorizzazioni univoche

Impostazione predefinita: 50.000	Disponibile nella versione 2007: no	Configurabile: sì
Percorso di configurazione: Amministrazione centrale, per ogni applicazione Web

Ritorno a capo automatico delle righe

Quando vengono aggiunte colonne a un elenco, viene eseguito il mapping con le colonne di una tabella di database di SQL Server. Ogni riga della tabella di database supporta un numero fisso di colonne per ognuno dei diversi tipi di colonna. Una singola riga di tabella di database ad esempio supporta 8 colonne di data e ora e dodici colonne numeriche. Se sono presenti più di 8 colonne di data e ora, ogni voce di elenco utilizzerà due righe della tabella di database.

Per elenchi di dimensioni ridotte, l'effetto prodotto dal ritorno a capo automatico delle righe è trascurabile. Per un elenco di grandi dimensioni invece l'effetto può essere significativo. È possibile raggiungere il limite per un numero qualsiasi di colonne perché si attivi il ritorno a capo automatico delle righe, ma è sufficiente che venga superato il limite per un solo tipo di colonna perché si attivi questo processo.

Nella tabella seguente viene mostrato il numero di colonne per tipi di dati specifici oltre il quale viene eseguito il ritorno a capo automatico delle righe.

Tipo di colonna	Numero di colonne per riga di tabella
Una riga di testo Oppure Selezione e più righe di testo	64 32
Data e ora	8
Sì o no	16
Numerica e valuta	12
Calcolata	8
Integer, ricerca valore singolo, utenti e gruppi, metadati gestiti	16
Identificatore univoco	1

Il ritorno a capo automatico delle righe determina una riduzione della velocità effettiva del 35% circa per ogni riga aggiuntiva per la maggior parte delle operazioni. Per controllare il numero di righe utilizzato da un elenco, è necessario analizzare lo schema dell'elenco ed esaminare i tipi di colonne per i campi dell'elenco.

Nel grafico seguente vengono illustrate le prestazioni di query di sola lettura quando il numero delle righe di database di SQL Server utilizzate per un elenco aumenta per accettare ulteriori colonne di metadati gestiti. Per passare alla seconda riga sono state aggiunte all'elenco 15 colonne di metadati gestiti, mentre per passare alla terza riga ne sono state aggiunte 31. Il testing è stato eseguito utilizzando solo query che hanno applicato il filtro in base agli elementi dell'elenco. Per ogni riga aggiuntiva, la velocità effettiva diminuisce del 35%.

Limite di dimensione delle righe

Impostazione predefinita: 6	Disponibile nella versione 2007: no	Configurabile: sì
Percorso di configurazione: solo modello a oggetti, SPWebApplication.MaxListItemRowStorage

Il limite di dimensione delle righe specifica il numero massimo di righe di tabella interne al database utilizzate per ogni elemento di un elenco. Per elenchi con numerose colonne, ogni elemento può andare a capo su diverse righe di tabella interne, fino a un massimo di 6 righe. Nel caso ad esempio di un elenco con numerose colonne di piccole dimensioni, ovvero un elenco contenente centinaia di colonne Sì/No, è possibile che venga raggiunto il limite. In questo caso, non sarebbe possibile aggiungere ulteriori colonne Sì/No all'elenco. Sarebbe invece possibile aggiungere colonne di altri tipi. Poiché ogni riga aggiuntiva comporta un aumento del carico, per un elenco di grandi dimensioni sarebbe opportuno ridurre il numero di colonne degli stessi tipi per evitare il ritorno a capo automatico delle righe.

Colonne di ricerca e visualizzazioni elenco

Ogni colonna di ricerca di una visualizzazione elenco causa un join con un'altra tabella. Ogni colonna di ricerca aggiuntiva in una visualizzazione comporta un aumento della complessità dello spostamento basato su metadati e delle query di visualizzazione elenco. Oltre alle colonne di ricerca standard, vengono considerate come colonne di ricerca anche le colonne di metadati gestiti a valore singolo e multivalore e le colonne di utenti e gruppi a valore singolo e multivalore. L'aggiunta di colonne di ricerca a una visualizzazione non comporta una diminuzione graduale o lineare delle prestazioni, piuttosto le prestazioni restano stabili fino a oltre otto colonne e quindi peggiorano rapidamente.

Nel grafico seguente viene mostrato come cambia la velocità effettiva man mano che aumenta il numero di colonne di ricerca in una visualizzazione. Come è possibile osservare, le prestazioni da zero a otto sono piuttosto stabili, mentre peggiorano in modo significativo in corrispondenza di 10 colonne di ricerca. Questo test è stato effettuato con l'elenco utilizzando una sola riga. Se in un elenco viene eseguito il ritorno a capo automatico delle righe, le prestazioni peggiorano più rapidamente.

Nel grafico seguente viene mostrato l'utilizzo della CPU di SQL Server man mano che aumenta il numero di colonne di ricerca in una visualizzazione. Come è possibile osservare, si verifica un cambiamento significativo in corrispondenza di 10 colonne di ricerca. Per un elenco con un numero elevato di query, la presenza di visualizzazioni contenenti più di otto colonne di ricerca comporta per le query l'utilizzo di una quantità esageratamente elevata di risorse di SQL Server. È consigliabile lasciare invariato questo limite a otto colonne.

Benché questo peggioramento delle prestazioni non sia per il numero totale di colonne di ricerca contenute in un elenco, ma solo per il numero di colonne di ricerca incluse in una visualizzazione o in una query, non è possibile sincronizzare in SharePoint Workspace un elenco con più di otto colonne di ricerca. Questo limite si applica indipendentemente dal fatto che le colonne vengano utilizzate o meno in una visualizzazione.

Soglia ricerca visualizzazione elenco

Impostazione predefinita: 8	Disponibile nella versione 2007: no	Configurabile: sì
Percorso di configurazione: Amministrazione centrale, per ogni applicazione Web

Altri limiti

In questa sezione vengono illustrati altri limiti non descritti in altre sezioni dell'articolo.

Indici per elenco

Impostazione predefinita: 20

Disponibile nella versione 2007: sì, con un limite di 10

Configurabile: No

Nella tabella precedente viene illustrato il limite di indici che è possibile creare per elenco, inclusi indici composti e indici creati da SharePoint Server 2010. Questo limite non è configurabile.

Visualizzazione Foglio dati ed esportazione in Excel

Impostazione predefinita: 50.000

Disponibile nella versione 2007: no

Configurabile: No

Nella tabella precedente viene mostrato il numero massimo di elementi che è possibile utilizzare con l'esportazione in Microsoft Excel e la visualizzazione Foglio dati. La visualizzazione Foglio dati tuttavia verrà bloccata dalla soglia della visualizzazione elenco. Se pertanto la soglia della visualizzazione elenco è impostata su 5.000 elementi e sono inclusi tra 5.000 e 50.000 elementi in una visualizzazione elenco, quando si tenta di utilizzare la visualizzazione Foglio dati viene generata un'eccezione di visualizzazione elenco anche se il limite della visualizzazione Foglio dati è superiore.

SharePoint Workspace

Impostazione predefinita: 30.000 elementi per elenco

Disponibile nella versione 2007: no

Configurabile: No

In Microsoft SharePoint Workspace è presente un limite non configurabile che blocca la sincronizzazione di un elenco contenente più di 30.000 elementi per elenco. Se un elenco include 30.000 elementi, gli utenti non potranno sincronizzarlo utilizzando SharePoint Workspace e gli elementi non potranno essere sincronizzati in modo selettivo.

Differenze tra elenchi di grandi dimensioni ed elenchi normali

Se in un elenco viene superato il valore di soglia della visualizzazione elenco, alcune operazioni che era possibile eseguire precedentemente vengono bloccate. Il problema principale è rappresentato dalla visualizzazione elenco predefinita, poiché è l'elemento utilizzato con maggiore frequenza dagli utenti per accedere a un elenco. Le visualizzazioni elenco devono essere configurate in modo da funzionare correttamente per un elenco di grandi dimensioni. Si verifica ad esempio un errore quando si accede a un elenco se la radice dell'elenco include più elementi di quelli previsti dalla soglia della visualizzazione elenco. Se è abilitata la funzionalità spostamento basato su metadati, verrà visualizzato un sottoinsieme dei risultati anziché un errore.

La soglia della visualizzazione elenco blocca qualsiasi operazione di database eseguita su più elementi di quelli previsti dal valore di soglia. Il valore di soglia non blocca solo il numero di elementi restituiti o modificati. Se ad esempio è applicato un filtro a una colonna non indicizzata che restituisce 100 risultati e nell'elenco sono contenuti 10.000 elementi, la query avrà esito negativo perché deve eseguire un'analisi dei 10.000 elementi completi. Se si aggiunge un indice alla colonna, l'operazione verrà limitata solo a 100 elementi e avrà esito positivo.

Le operazioni eseguite su elenchi di grandi dimensioni possono essere classificate nei due gruppi seguenti:

• L'elenco supera la soglia della visualizzazione elenco   Alcune operazioni vengono bloccate se la dimensione dell'intero elenco supera la soglia della visualizzazione elenco, anche se gli elementi sono divisi in cartelle. Tra queste operazioni sono incluse le query ricorsive, ad esempio la gestione delle versioni estratte, che agiscono su tutti gli elementi indipendentemente dalla cartella in cui sono contenuti. Vengono bloccate anche le visualizzazioni che restituiscono tutti gli elementi senza cartelle, nonché le operazioni che interessano l'intero elenco, ad esempio l'aggiunta di una colonna e la creazione o l'eliminazione di indici.

• Il contenitore supera la soglia della visualizzazione elenco   Alcune operazioni vengono bloccate perché una cartella o la radice dell'elenco include più elementi della soglia della visualizzazione elenco. Se ad esempio un elenco include 10.000 elementi e una cartella ne include 3.000, è possibile rinominare o eliminare la cartella. Se tuttavia la cartella include 6.000 elementi, superando così la soglia della visualizzazione elenco, non sarà possibile eliminarla perché l'operazione supera la soglia della visualizzazione elenco.

Quando un elenco supera la soglia della visualizzazione elenco, è necessario pianificare una corretta configurazione delle visualizzazioni e delle altre opzioni di spostamento. In teoria, sarebbe opportuno procedere in tal senso in anticipo, ma spesso gli elenchi aumentano oltre la soglia della visualizzazione elenco e richiedono un intervento. Alcune operazioni, ad esempio la creazione di un colonna o l'indicizzazione di una colonna di un elenco con molti elementi, richiederanno molto tempo. Queste operazioni sono bloccate dalla soglia della visualizzazione elenco. Possono essere eseguite tuttavia nel periodo di tempo durante la giornata specificato oppure da amministratori di farm o di computer. È consigliabile pianificare queste operazioni prima di eseguirle. Se la dimensione dell'elenco è già troppo estesa, pianificare l'utilizzo di un periodo di tempo durante la giornata o di credenziali amministrative per l'esecuzione di queste operazioni.

È possibile che le dimensioni di un elenco si estendano a tal punto da comportare il timeout di alcune operazioni eseguite tramite un Web browser. Se ad esempio un elenco include milioni di documenti, l'aggiunta di una colonna potrebbe richiedere troppo tempo. Per eseguire questa operazione, sarebbe necessario utilizzare Windows PowerShell e operare inoltre in fasce orarie non di punta poiché questo sistema blocca le operazioni di tutti gli altri utenti.

Operazioni bloccate dalla soglia della visualizzazione elenco

Nelle tabelle seguenti vengono elencate le operazioni bloccate dalla soglia della visualizzazione elenco.

Operazioni bloccate nel caso di un elenco che supera la soglia della visualizzazione elenco

Operazione	Descrizione
Aggiunta/rimozione/aggiornamento di una colonna di elenco	Tutte le colonne, incluse le colonne di ricerca e calcolate, oltre a molti tipi di aggiornamenti, ad esempio una modifica di tipo o di univocità. Alcuni aggiornamenti, ad esempio la modifica del nome, non sono bloccati perché non hanno effetto su tutti gli elementi dell'elenco.
Aggiunta/rimozione/aggiornamento di un tipo di contenuto dell'elenco	Ha effetto su tutti gli elementi dell'elenco e pertanto è bloccata per tutti gli elenchi con un numero di elementi superiore alla soglia della visualizzazione elenco.
Creazione/rimozione di un indice	Ha effetto su tutti gli elementi dell'elenco e pertanto è bloccata per tutti gli elenchi con un numero di elementi superiore alla soglia della visualizzazione elenco.
Gestione di file senza versione archiviata	Query ricorsiva non indicizzata che ha esito negativo per tutti gli elenchi con un numero di elementi superiore alla soglia della visualizzazione elenco.
Query ricorsive non indicizzate	Include le operazioni di filtro e alcune operazioni di ordinamento. Ha esito negativo se le dimensioni dell'elenco sono superiori alla soglia della visualizzazione elenco. Poiché non è presente alcun indice, viene eseguita un'analisi completa dell'intero elenco. Questa operazione inoltre restituisce tutti gli elementi e ignora le cartelle.
Query tra elenchi	Include query da parte della web part Query contenuto e applica l'impostazione della soglia della visualizzazione elenco per i controlli e gli amministratori, che per impostazione predefinita è di 20.000 elementi. Se l'operazione prevede più di 20.000 elementi, la query ha esito negativo.
Colonne di ricerca che applicano il comportamento di relazione	Non è possibile creare colonne di ricerca che applicano il comportamento di relazione se nell'elenco di riferimento è contenuto un numero di elementi superiore alla soglia della visualizzazione elenco.
Eliminazione di un elenco	Ha effetto su tutti gli elementi dell'elenco e pertanto è bloccata per tutti gli elenchi con un numero di elementi superiore alla soglia della visualizzazione elenco.
Eliminazione di un sito	Se la somma di tutti gli elementi di un sito è superiore alla soglia della visualizzazione elenco, l'operazione di eliminazione del sito è bloccata perché interessa troppi elementi.
Salvataggio di un elemento come modello con dati	Ha effetto su tutti gli elementi dell'elenco e pertanto è bloccata per tutti gli elenchi con un numero di elementi superiore alla soglia della visualizzazione elenco.
Visualizzazione dei totali nelle visualizzazioni elenco	Esegue una query su tutti gli elementi dell'elenco e pertanto è bloccata per tutti gli elenchi con un numero di elementi superiore alla soglia della visualizzazione elenco.
Abilitazione/disabilitazione degli allegati in un elenco	Ha effetto su tutti gli elementi dell'elenco e pertanto è bloccata per tutti gli elenchi con un numero di elementi superiore alla soglia della visualizzazione elenco.

Operazioni bloccate nel caso di un contenitore che supera la soglia della visualizzazione elenco

Operazione	Descrizione
Eliminazione/copia/ridenominazione di una cartella	Ha esito negativo se la cartella include un numero di elementi superiore alla soglia della visualizzazione elenco perché interessa troppe righe.
Query che applicano un filtro in base a colonne non indicizzate	Ha esito negativo se il contenitore (cartella o elenco) include un numero di elementi superiore alla soglia della visualizzazione elenco. Viene eseguita un'analisi completa dell'intera cartella perché non è presente alcun indice.
Impostazione di autorizzazioni di sicurezza specifiche	Ha esito negativo se l'elenco o la cartella per cui si tenta di impostare autorizzazioni specifiche include un numero di elementi superiore alla soglia della visualizzazione elenco poiché interessa troppe righe. È comunque possibile impostare autorizzazioni specifiche per gli elementi figlio di un elenco di grandi dimensioni, ad esempio i documenti, pur non essendo possibile impostare le autorizzazioni per l'elenco stesso o per le cartelle che includono un numero di elementi superiore alla soglia della visualizzazione elenco.
Utilizzo dell'opzione Apri con Esplora risorse	Non viene visualizzato alcun elemento se un contenitore include un numero di elementi superiore alla soglia della visualizzazione elenco (esclusi gli elementi contenuti nelle sottocartelle). Se una cartella con 8.000 elementi include una sottocartella con 4.000 elementi e solo 4.000 elementi nella radice, l'opzione Apri con Esplora risorse funzionerà correttamente. Se invece la radice di un elenco include un numero di elementi superiore alla soglia della visualizzazione elenco, l'opzione non consentirà di visualizzare alcun elemento. Per utilizzare Apri con Esplora risorse, è necessario che l'elenco includa elementi organizzati in cartelle in quantità inferiori alla soglia della visualizzazione elenco nella radice di qualsiasi contenitore.

Funzionalità disponibili che possono produrre risultati imprevisti

In questa sezione sono contenute informazioni sulle funzionalità che possono produrre risultati imprevisti con elenchi di grandi dimensioni.

Visualizzazione Foglio dati

Il pulsante Visualizzazione Foglio dati disponibile nella scheda della barra multifunzione di una raccolta documenti non è disabilitato se le dimensioni dell'elenco aumentano fino a superare la soglia della visualizzazione elenco. In questo caso però la visualizzazione carica solo alcuni elementi e visualizza un messaggio "Non si dispone dell'autorizzazione per visualizzare l'intero elenco, in quanto supera la soglia di visualizzazione applicata dall'amministratore". È possibile disabilitare l'opzione della visualizzazione Foglio dati della barra multifunzione nelle impostazioni dell'elenco. Poiché è previsto inoltre un limite rigido di 50.000 elementi, questa visualizzazione è bloccata anche se la soglia della visualizzazione elenco è superiore a 50.000 elementi.

Pianificazione della struttura e dell'implementazione di un elenco di grandi dimensioni

Prima di implementare un elenco di grandi dimensioni, esaminare i requisiti e il business case. Tra i requisiti importanti di cui tenere conto sono inclusi il contratto di servizio, il tempo per il backup e il ripristino, le dimensioni del contenuto, la quantità di contenuto (numero di elementi) e i tempi di accesso. A seconda delle dimensioni e da requisiti dell'applicazione, è necessario effettuare scelte importanti a diversi livelli, tra cui l'hardware, l'archiviazione di contenuto e l'architettura delle informazioni di SharePoint Server 2010. Un'applicazione di grandi dimensioni con milioni di elementi e centinaia di utenti simultanei può richiedere hardware autonomo per il progetto specifico, benché un archivio documenti con decine di utenti simultanei e decine di migliaia di documenti possa funzionare correttamente con hardware condiviso esistente e una singola raccolta documenti in un sito esistente.

Il risultato finale della pianificazione dovrebbe includere un elenco di tipi di colonne (nomi, tipi di dati e utilizzo), gli indici, la struttura di cartelle, l'utilizzo delle pagine e i collegamenti per lo spostamento, la struttura pianificata delle autorizzazioni, il numero stimato di elementi e le dimensioni totali dei dati. I dettagli dovrebbero includere inoltre informazioni sui tipi di query che verranno eseguite e sul modo in cui verranno aperti, creati e aggiornati i dati dell'elenco.

Dopo aver pianificato la struttura e l'implementazione di un elenco di grandi dimensioni, il passaggio successivo consiste nel progettare e creare un prototipo. Questa fase della pianificazione prevede la progettazione dell'elenco di grandi dimensioni, l'implementazione di un modello di prova e la convalida del funzionamento. In questa fase potrebbe essere utile inserire in un ambiente di testing una quantità elevata di contenuto per convalidare i presupposti per l'accesso ai dati e le prestazioni. Il risultato finale del processo di progettazione dovrebbe includere un modello di prova dell'elenco desiderato e una documentazione delle colonne, dei tipi di contenuto, della struttura di cartelle, delle visualizzazioni, degli indici, delle colonne utilizzate per lo spostamento basato su metadati o altri metodi di recupero, delle eventuali tassonomie utilizzate, dell'utilizzo di diverse web part, nonché dell'utilizzo di altre funzionalità come Content Organizer.

Stima delle dimensioni del contenuto

Per gli elenchi di grandi dimensioni è importante calcolare diverse stime numeriche per la pianificazione della capacità e la scelta della struttura. È opportuno eseguire la pianificazione di alcune stime numeriche importanti, tra cui:

• Dimensioni totali del database del contenuto

• Dimensioni medie e massime dei file

• Numero di versioni

• Quantità di contenuto - numero totale di elementi in un elenco

Dimensioni del database del contenuto

Le dimensioni totali del database del contenuto sono importanti per la pianificazione dello spazio su disco necessario e dell'hardware oltre che per il calcolo del supporto per il backup, il ripristino e un contratto di servizio. Le dimensioni totali del database del contenuto costituiscono il fattore più importante per determinare il tempo di inattività necessario per il backup e il ripristino.

Le dimensioni del database del contenuto possono essere stimate calcolando la dimensione media dei documenti moltiplicata per il numero medio di di versioni per documento moltiplicato per il numero previsto di documenti. Aggiungere un ulteriore 20% per i dati del database del contenuto oltre ai file. Questo numero è elevato poiché le dimensioni delle versioni in genere aumentano nel tempo e pertanto le dimensioni medie dei file dei documenti archiviati sono generalmente superiori rispetto alle dimensioni medie dei file di tutte le versioni. È consigliabile aggiungere un buffer significativo qualora le dimensioni dell'elenco aumentino oltre il previsto, a meno che non si disponga di meccanismi per controllare in modo efficiente la quantità di contenuto.

Dimensioni medie e massime dei file

È necessario definire la dimensione massima dei file in modo che venga specificata l'impostazione dell'applicazione Web corretta per i file che è possibile caricare (per impostazione predefinita 50 MB, il massimo può essere 2 GB). La dimensione media dei file viene utilizzata per conoscere il tasso di crescita del contenuto e per stimare le dimensioni totali del contenuto. La dimensione media dei file può essere calcolata valutando i file nei sistemi che attualmente svolgono il ruolo del sistema previsto.

Numero medio di versioni

È necessario tenere conto del controllo delle versioni, poiché può determinare un aumento significativo delle dimensioni del contenuto. Sono disponibili diversi metodi per limitare le versioni. È ad esempio possibile utilizzare criteri di conservazione di gestione delle informazioni per eliminare tutte le versioni precedenti a un intervallo di tempo specifico oppure limitare il numero di versioni da salvare. Esistono altri fattori che hanno effetto sulle versioni. Se ad esempio per l'invio di tutto il contenuto all'archivio viene utilizzato Content Organizer, potrebbe non esistere alcuna versione poiché Content Organizer copia solo l'ultima versione archiviata. Se i documenti inclusi nell'archivio vengono modificati in modo attivo dagli utenti, potrebbe essere necessario prendere in considerazione la creazione condivisa. Ogni sessione di creazione condivisa infatti crea automaticamente una versione. Valutare l'utilizzo dell'archivio e le soluzioni esistenti per stimare il numero medio di versioni che verranno create per un documento.

Quantità di contenuto

Per quantità di contenuto si intende il numero totale di elementi in un singolo elenco. Per stimare la quantità di contenuto, è consigliabile calcolare le origini di contenuto esistenti e i dati che verranno spostati nel nuovo sistema oppure esaminare quanti utenti utilizzeranno il sistema e lo scopo del sistema. Esistono anche altri fattori numerici correlati, inclusi gli elementi per contenitore e gli elementi per pivot di metadati o filtro di indice. Questi valori numerici sono importanti anche per la pianificazione delle visualizzazioni e dello spostamento basato su metadati.

Archiviazione BLOB remoti

Per gli elenchi con requisiti di spazio di archiviazione elevati è necessario effettuare una scelta fondamentale per la modalità di archiviazione dei documenti. Per impostazione predefinita, SharePoint Server 2010 archivia tutti i documenti come oggetti BLOB nel database di SQL Server. In SharePoint Server 2010 e SQL Server 2008 è disponibile un'API Archiviazione BLOB remoti che consente di archiviare i documenti all'esterno del database di SQL Server, in modo da ridurne le dimensioni. La scelta di utilizzare Archiviazione BLOB remoti dipende in larga misura dalla possibilità di risparmiare sui costi.

Dai test correnti eseguiti da Microsoft risulta che l'utilizzo di Archiviazione BLOB remoti comporta una riduzione del 5-10% della velocità effettiva e, per i file di grandi dimensioni, nessuna differenza significativa di latenza. Le prestazioni tuttavia possono variare a seconda del provider di Archiviazione BLOB remoti specifico utilizzato. L'utilizzo di Archiviazione BLOB remoti determina una riduzione delle dimensioni del database del contenuto. Questo tuttavia non significa necessariamente che sia possibile archiviare più elementi in un database del contenuto. Le prestazioni sono condizionate dalla quantità di elementi contenuti negli elenchi nel database di SQL Server. Anche se vengono rimossi gli oggetti BLOB, le dimensioni degli elenchi restano invariate. Esistono alcuni scenari in cui il risparmio sui costi è più importante dell'effetto sulle prestazioni:

• Archivio, dati non di collaborazione

• Archiviazione di oggetti BLOB di grandi dimensioni, ad esempio video e immagini aggiornati poco frequentemente

L'utilizzo di Archiviazione BLOB remoti può comportare l'aggiunta di ulteriori server e tecnologia alla farm e richiedere un provider di Archiviazione BLOB remoti. Questo provider può supportare l'archiviazione di oggetti BLOB in spazi di archiviazione meno costosi all'esterno del database di SQL Server. Per utilizzare l'API Archiviazione BLOB remoti è necessario SQL Server Enterprise.

Il punto a partire dal quale Archiviazione BLOB remoti diventa vantaggioso dal punto di vista dei costi può essere valutato nell'ordine di terabyte di dati. Non è necessario utilizzare Archiviazione BLOB remoti solo perché si dispone di database del contenuto di dimensioni che rientrano nell'ordine dei terabyte. È opportuno valutare attentamente i requisiti di backup e ripristino e dei contratti di servizio. Con Archiviazione BLOB remoti, il ripristino di emergenza risulta più difficile perché è necessario sincronizzare due tecnologie. Il problema principale è rappresentato dal tempo necessario per ripristinare il sistema dopo una situazione di emergenza e per gestire gli oggetti BLOB di backup e ripristino. Per ulteriori informazioni, vedere Overview of RBS (SharePoint Server 2010).

Architettura degli elenchi

La scelta dell'architettura appropriata per un progetto di elenchi di grandi dimensioni è importante poiché può essere difficile apportare modifiche dopo l'implementazione. Pianificare in anticipo e tenere conto delle dimensioni e delle quantità di contenuto, dell'utilizzo dell'archivio, delle modalità di aggiunta e aggiornamento del contenuto, nonché del modo in cui si accederà ai dati. Tutti questi aspetti possono influire sull'organizzazione del contenuto (in un elenco, in più elenchi o addirittura in più raccolte siti), sui metadati utilizzati e sulla modalità di recupero del contenuto. Tutte queste decisioni rivestono particolare importanza per gli elenchi di grandi dimensioni, poiché con una quantità elevata di contenuto diventa ancora più difficile ridefinire l'utilizzo di un sistema.

Elenco singolo, più elenchi o più raccolte siti

Quando si progetta una soluzione di elenchi di grandi dimensioni, è importante valutare se è appropriato utilizzare un'architettura con un singolo elenco. La scelta di inserire il contenuto in un singolo elenco deve basarsi sui requisiti aziendali, ad esempio la facilità di utilizzo e di individuazione del contenuto. In molti casi potrebbe essere più opportuno utilizzare più di un elenco. È prioritario creare un'implementazione appropriata con usabilità ed esperienza utente avanzate con le funzionalità di SharePoint Server 2010 e le risorse disponibili.

Utilizzare un elenco singolo per semplificare l'individuazione e l'utilizzo di contenuto da parte degli utenti in modo che non debbano decidere dove inserire il contenuto o quale elenco aprire per trovare i dati desiderati. Con l'aumento della quantità di contenuto, potrebbe inoltre essere più difficile trovare i dati desiderati, soprattutto utilizzando metodi come l'applicazione di filtri alle visualizzazioni o l'esplorazione di cartelle. Quando la quantità di contenuto di un elenco si avvicina all'ordine delle centinaia di migliaia di elementi, l'utilizzo dello spostamento basato su metadati può complicarsi ed è possibile che le query restituiscano centinaia o migliaia di risultati perché non sono sufficientemente specifiche.

Se ad esempio nel dominio di un indice sono contenuti più di 5.000 termini e per ogni termine esistono altrettanti elementi che soddisfano il criterio di filtro, applicando un filtro in base a un termine verranno restituiti 20 risultati con un elenco di 100.000 elementi e 200 risultati con un elenco di 1.000.000 di elementi. Se le dimensioni dell'elenco sono eccessive, molti filtri selezionati dagli utenti non restituiranno un set di risultati accettabile per consentire agli utenti di trovare i dati desiderati. Se in un progetto sono presenti più tipi di contenuto separato facilmente distinguibile, è consigliabile prendere in considerazione la possibilità di utilizzare più elenchi.

In uno scenario di archivio su larga scala potrebbe essere opportuno valutare l'opportunità di utilizzare un'architettura con più raccolte siti. Una nuova funzionalità di SharePoint Server 2010 consente di raggruppare le raccolte siti per bilanciare il carico dei documenti. La funzionalità Content Organizer viene utilizzata per distribuire documenti tra più raccolte siti. Per recuperare i documenti è necessario utilizzare il servizio di ricerca. Questa soluzione è ideale per l'archiviazione a lungo termine, poiché consente di bilanciare il contenuto tra più raccolte siti ed è scalabile in modo da supportare molti più documenti rispetto a un elenco singolo.

Riepilogo dei consigli relativi agli elenchi

• Utilizzare elenchi singoli per un numero elevato di elementi nei casi seguenti:

  • Non è logico inserire gli elementi in elenchi separati.

  • Questa soluzione garantisce un'esperienza utente ottimale.

• Utilizzare più elenchi per una quantità elevata di elementi nei casi seguenti:

  • È logico raggruppare gli elementi in più elenchi.

  • Questa soluzione garantisce un'esperienza utente ottimale.

  • Non esiste il rischio che gli utenti confondano gli elenchi da utilizzare per aggiungere o ricercare il contenuto.

• Utilizzare un'architettura con più raccolte siti nei casi seguenti:

  • Deve essere supportata la presenza di decine di milioni di elementi in ogni singolo archivio.

  • È logico raggruppare gli elementi in più raccolte siti, ad esempio per suddividere i dati per anno.

Metadati

Con SharePoint Server 2010, i metadati e i tipi di contenuto si rivelano utili per la creazione dell'architettura delle informazioni. Nuove funzionalità quali i metadati gestiti, lo spostamento basato su metadati e i set di termini si basano sui metadati per recuperare il contenuto. Poiché le operazioni come la modifica dei tipi di contenuto e delle colonne sono bloccate negli elenchi di grandi dimensioni, è particolarmente importante pianificare in anticipo i requisiti per i metadati. Se si prevede di utilizzare lo spostamento basato su metadati o qualsiasi altro metodo per recuperare il contenuto in base ai metadati, è importante pianificare i tipi di contenuto e le relative colonne durante la fase di progettazione.

Nella maggior parte degli scenari con elenchi di grandi dimensioni i metadati non solo solo utili, ma rappresentano anche un requisito per l'utilizzo del sistema da parte degli utenti. I metadati possono essere applicati in tre modi principali: incorporati nei processi del sistema, incorporati nel codice e in configurazioni personalizzati e applicati manualmente dagli utenti. Per utilizzare le colonne per recuperare il contenuto, la maggior parte degli elementi deve includere una valore specificato per la colonna. È per questo motivo che è importante pianificare quali colonne verranno utilizzate per lo spostamento e come verranno specificati i metadati. L'unico modo per garantire che vengano applicati i metadati corretti consiste nell'utilizzare processi predefiniti e personalizzazioni. Poiché ad esempio ogni elemento è associato a un tipo di contenuto, se vengono utilizzati i tipi di contenuto per classificare i documenti, ogni elemento sarà associato a questi metadati e in questo modo sarà possibile applicare filtri in base al tipo di contenuto.

Tipi di contenuto

La suddivisione più semplice del contenuto in categorie viene effettuata con i tipi di contenuto. Se si dispone di metadati per la classificazione del contenuto, ad esempio tipo di documento o di elemento, valutare la possibilità di utilizzare questa classificazione per i tipi di contenuto. I tipi di contenuto consentono di definire le colonne associate a un tipo di contenuto, oltre all'associazione ai flussi di lavoro e al modello. È possibile associare un solo modello a un tipo di contenuto e tale modello verrà utilizzato per la creazione di una nuova istanza del tipo di contenuto dal menu Nuovo documento disponibile in una raccolta documenti.

È possibile utilizzare i modelli per i formati di file in Microsoft Word, Microsoft PowerPoint ed Excel, oltre ad altri prodotti. Quando gli utenti creano nuove istanze del tipo di contenuto, viene utilizzata l'applicazione client specifica per iniziare la creazione e la modifica tramite il modello. Quando viene caricato il contenuto, gli utenti possono effettuare una selezione dai tipi di contenuto disponibili. I tipi di contenuto devono essere distinti e specifici e devono essere presenti in numero limitato per ogni elenco, in modo che gli utenti non abbiano difficoltà a selezionare il tipo di contenuto da utilizzare.

Poiché i metadati che devono essere specificati dagli utenti al momento della creazione o del caricamento di un elemento dipendono dai tipi di contenuto, valutare quali colonne sono necessarie per soddisfare i requisiti aziendali e ridurre inoltre gli ostacoli per l'invio del contenuto. La selezione di un set appropriato di tipi di contenuto per la classificazione del contenuto già al livello principale facilita automaticamente lo spostamento. Poiché ogni elemento è associato a un tipo di contenuto, esiste un pivot per filtrare valido per ogni elemento.

Riepilogo dei consigli relativi ai tipi di contenuto

• Utilizzare i tipi di contenuto come metodo base per l'organizzazione del contenuto.

• Utilizzare i tipi di contenuto per selezionare le colonne specifiche necessarie per il tipo di contenuto.

• I tipi di contenuto per ogni elenco devono essere in numero limitato (non più di 10) e devono distinguersi in modo da facilitare agli utenti l'individuazione del tipo di contenuto da utilizzare.

• Nei tipi di contenuto è disponibile una colonna predefinita per cui ogni elemento dispone di un valore da utilizzare per i filtri e per lo spostamento basato su metadati.

Esempio di un elenco di collaborazione di grandi dimensioni e di tipi di contenuto: raccolta di specifiche di prodotto

I team di sviluppo dei prodotti utilizzano le raccolte di specifiche di prodotto per archiviare specifiche di progettazione, piani di test e altri elementi di sviluppo di un prodotto. In questo esempio vengono utilizzati i sei tipi di contenuto seguenti. In tutti i tipi di contenuto sono incluse colonne per la data di inizio del progetto, la data di fine del progetto, il budget, i membri del team di progettazione, il nome del prodotto e il tipo di prodotto.

• Specifica del prodotto - Un file di Word contenente i dettagli della progettazione di un prodotto. Tra i metadati aggiuntivi sono inclusi il progettista e la data di revisione finale.

• Specifica dei test - Un file di Word contenente il piano di test di un prodotto. Tra i metadati aggiuntivi sono inclusi il tester e lo stato di completamento dei test.

• Piano di sviluppo - Un file di Word contenente il piano per lo sviluppo del prodotto.

• Storyboard - Una presentazione di PowerPoint utilizzata per presentare i modelli della progettazione.

• Analisi dei costi - Un foglio di calcolo di Excel in cui vengono analizzati i costi per lo sviluppo del prodotto e le potenziali opportunità di mercato.

• Sequenza temporale - Un foglio di calcolo di Excel contenente i dettagli relativi alla pianificazione per lo sviluppo del prodotto.

In questo esempio gli utenti possono applicare un filtro in base al tipo di contenuto per trovare una specifica o uno storyboard del prodotto. I modelli personalizzati consentono inoltre di strutturare il lavoro dell'utente. Il numero di colonne e di tipi di contenuto è sufficientemente ridotto da consentire agli utenti di selezionare facilmente le opzioni appropriate per le proprie attività, ma specificando i metadati è facile applicare filtri e trovare il contenuto desiderato.

Colonne

Numero di colonne e colonne obbligatorie

È possibile utilizzare le colonne per specificare il tipo di metadati di un elemento e contrassegnarle come nascoste, facoltative oppure obbligatorie. Utilizzare le colonne nascoste per le attività automatizzate, ad esempio i flussi di lavoro, in modo che gli utenti non possano modificarle. Utilizzare le colonne obbligatorie solo se assolutamente necessario. Una proprietà di metadati può essere necessaria ad esempio per la distribuzione di un elemento nella posizione appropriata o per lo spostamento. In questi casi, non si desidera che gli utenti lascino il campo vuoto. Meno sono gli elementi con metadati inseriti per una colonna utilizzata come filtro di spostamento, meno utile sarà lo spostamento poiché non verranno mai restituiti molti elementi da una query.

Con l'aumento del numero di colonne di metadati, è sempre meno probabile che gli utenti specifichino i metadati a causa dell'impegno aggiuntivo richiesto per individuare le colonne da applicare e quindi specificare un valore. Se si utilizza un numero maggiore di colonne obbligatorie, è meno probabile che gli utenti utilizzino questo sistema poiché viene richiesto troppo tempo per il caricamento del contenuto. In uno scenario di collaborazione aperto questo fattore può rivelarsi controproducente. Ma nel caso di contenuto importante la cui creazione ha richiesto un notevole impegno è più probabile che gli utenti dedichino tempo per completare i campi appropriati, soprattutto se questa operazione non viene richiesta frequentemente.

Durante la fase di progettazione, individuare i metadati necessari per eseguire le operazioni richieste e per recuperare il contenuto, calcolare il tempo richiesto agli utenti per specificare i metadati e valutare l'effetto prodotto sugli utenti. Se gli utenti non adottano il sistema a causa del sovraccarico aggiuntivo per la creazione del contenuto, potrebbe essere difficile ristrutturare il sistema in un secondo momento.

Tipi di campi e confronto tra campi a valore singolo e multivalore

Per la scelta delle colonne è necessario tenere conto del tipo di colonna e dell'eventuale presenza di uno o più valori. Le query eseguite su campi di metadati gestiti sono più efficienti di quelle eseguite su colonne di tipo Scelta ed è pertanto opportuno considerare l'eventualità di utilizzare campi di metadati gestiti anziché campi di opzioni. Le colonne, ad esempio di metadati gestiti oppure di utenti o gruppi, possono supportare più valori. Le query eseguite su colonne multivalore non sono efficienti come le query eseguite su colonne a valore singolo.

Le colonne e i tipi di contenuto costituiscono in genere i componenti centrali per la classificazione e il recupero di contenuto in un elenco di grandi dimensioni. È necessario aver già preparato un elenco di colonne e di tipi di contenuto durante il processo di pianificazione. Il numero di colonne e di tipi di contenuto aggiunti a un elenco può avere effetto sulle prestazioni in modi non evidenti. Il numero di colonne di un tipo specifico che vengono aggiunte a un singolo elenco determinerà il ritorno a capo automatico delle righe. Per ulteriori informazioni, vedere Ritorno a capo automatico delle righe più indietro in questo articolo.

Esempio di un elenco di collaborazione di grandi dimensioni e di colonne: raccolta di specifiche di prodotto

In questa sezione vengono descritte le colonne utilizzate nell'esempio:

• Colonne gestite automaticamente da SharePoint Server 2010: ID, tipo di contenuto, data modifica, data/ora creazione, modificato da, autore, ID documento

• Colonne gestite dalle personalizzazioni:

  • Valori predefiniti di metadati per cartella per tipo di prodotto e team di prodotto (per ogni tipo di prodotto esiste una cartella e per ogni cartella di tipo di prodotto sono presenti più cartelle di team di prodotto)

  • Aggiornamento dei flussi di lavoro: stato approvazione, progetto completato

• Colonne gestite dagli utenti: progettista, tester, data di revisione finale

• Colonne utili per lo spostamento: tipo di contenuto, tipo di prodotto, team di prodotto

• Colonne utilizzate per monitorare lo stato e utili anche per lo spostamento: data di revisione finale, stato approvazione, progetto completato

• Colonne che possono essere utili per lo spostamento: progettista, tester, nome prodotto, data modifica, modificato da

Riepilogo dei consigli relativi alle colonne

• Ridurre al minimo il numero di colonne disponibili per l'inserimento di dati.

• Selezionare accuratamente le colonne che verranno utilizzate per i processi di sistema e lo spostamento. Valutare quali campi saranno obbligatori e configurare come obbligatori il minor numero possibile di campi.

• È consigliabile utilizzare i campi obbligatori per lo spostamento, ad esempio utilizzare le web part Query contenuto per un campo specifico. Utilizzare questo tipo di campi anche per l'amministrazione, ad esempio per indicare in un campo data azioni di conservazione che devono essere specificate dagli utenti.

• Poiché le query eseguite su colonne a valore singolo sono più rapide di quelle eseguite su colonne multivalore, tentare di configurare le colonne con valori singoli a meno che non siano necessari più valori.

Il numero totale di colonne specifiche in un elenco può determinare il ritorno a capo automatico delle righe, con conseguente rallentamento delle prestazioni. Ridurre al minimo il numero di colonne in un elenco di grandi dimensioni ed evitare il ritorno a capo automatico delle righe, se possibile.

Cartelle

Valutare attentamente come organizzare il contenuto nelle cartelle. Le cartelle possono essere utilizzate in tre modi principali:

• Organizzare il contenuto nelle cartelle in modo logico. Organizzare ad esempio i contratti in cartelle in base all'anno o al mese della firma del contratto oppure le fatture in base alla data di creazione della fattura. In questo scenario gli utenti possono facilmente spostarsi nella struttura di cartelle o utilizzare i metadati per trovare i documenti. I documenti inoltre vengono facilmente distribuiti nella cartella corretta. In Content Organizer sono disponibili funzionalità che consentono di limitare la quantità di elementi per ogni singola cartella creando sottocartelle quando vengono aggiunti elementi che superano un limite specificato.

• Organizzare il contenuto in cartelle per la conservazione e le autorizzazioni o per altre funzioni amministrative, ad esempio una cartella per documenti riservati a cui hanno accesso pochi utenti oppure la conservazione basata sul percorso, in modo che i documenti abbiano una pianificazione di conservazione diversa a seconda della cartella in cui sono contenuti. In questo scenario lo spostamento degli utenti potrebbe essere più difficile poiché è possibile che agli utenti non interessi dove è contenuto un documento purché possano accedervi. Lo spostamento basato su metadati e la ricerca sono i metodi principali per trovare i documenti, rispetto all'utilizzo della struttura di cartelle.

• Organizzare il contenuto in cartelle per consentire agli utenti di spostarsi in base agli argomenti o alle categorie. Molti utenti sono abituati a spostarsi utilizzando le cartelle. Per determinate applicazioni potrebbe essere importante mantenere una struttura di cartelle che consenta agli utenti di spostarsi facilmente. In questo scenario gli utenti in genere capiscono la struttura di cartelle e dove cercare e inserire i documenti. Lo spostamento basato su metadati e la ricerca possono essere utilizzati in combinazione con questo metodo.

I miglioramenti apportati a SharePoint Server 2010 consentono di usufruire di una maggiore flessibilità nell'utilizzo delle cartelle e di una minore dipendenza dalle considerazioni sulle prestazioni. Utilizzando i metadati gestiti e lo spostamento basato su metadati, gli utenti possono applicare facilmente filtri in base ai metadati, anziché spostarsi utilizzando le cartelle. In questo modo è possibile organizzare il contenuto per scopi amministrativi, ad esempio autorizzazioni o criteri, anziché solo per lo spostamento degli utenti. È ad esempio possibile disporre di una cartella di materiale classificato a cui hanno accesso solo alcuni dipendenti e di un'altra cartella accessibile a tutti i dipendenti. È possibile specificare autorizzazioni diverse per le cartelle e quindi utilizzare Content Organizer per spostare automaticamente il contenuto nella cartella appropriata in base ai metadati. È comunque sempre possibile scegliere di utilizzare le cartelle per lo spostamento in combinazione con lo spostamento basato su metadati.

Con la funzionalità Content Organizer il contenuto può essere spostato automaticamente nelle cartelle in base ai tipi di contenuto e ai metadati senza che gli utenti debbano decidere dove inserirlo. È inoltre possibile utilizzare Content Organizer per creare automaticamente nuove cartelle dopo che una cartella ha raggiunto un limite specificato per il numero di elementi. Tenere conto che l'utilizzo di Apri con Esplora risorse (WebDAV) non funzionerà per gli elenchi di grandi dimensioni se gli elementi non sono organizzati in cartelle con un numero di elementi inferiore alla soglia della visualizzazione elenco nella radice di una cartella.

Le prestazioni delle visualizzazioni basate su cartelle e delle visualizzazioni basate su metadati sono molto simili. Dal punto di vista logico e dell'esperienza utente, è utile utilizzare le cartelle per dividere il contenuto. Lo spostamento basato su metadati esegue query ricorsive in modo che vengano restituiti tutti gli elementi al di fuori delle cartelle. Se questo è il metodo principale utilizzato per il recupero del contenuto, la struttura di cartelle potrebbe non essere importante.

Nel grafico seguente vengono illustrati i risultati di un test eseguito utilizzando visualizzazioni di diversi tipi per accedere allo stesso numero di elementi. Tutte le visualizzazioni hanno restituito 1.000 risultati. Nel grafico vengono mostrate le richieste al secondo delle singole visualizzazioni con l'aumento delle dimensioni dell'elenco. Dal test risulta che con l'aumento delle dimensioni dell'elenco le prestazioni delle visualizzazioni cartella e indicizzate restano praticamente invariate, benché le cartelle garantiscano prestazioni migliori con dimensioni di elenchi inferiori. Per elenchi di dimensioni maggiori, viene utilizzata una combinazione di cartelle e di visualizzazioni indicizzate in modo che non siano le differenze di prestazioni a determinare se utilizzare le cartelle o gli indici per recuperare i dati.

Riepilogo dei consigli relativi alle cartelle

• Pianificare il modo in cui verranno organizzati gli elementi nelle cartelle. Gli elementi possono essere spostati automaticamente o manualmente.

• Se si utilizzano funzionalità come lo spostamento basato su metadati, è meno necessario limitare la quantità di elementi nelle cartelle.

• Utilizzare lo spostamento basato su metadati insieme allo spostamento basato su cartelle. Le cartelle possono essere utilizzate pertanto per gestire i criteri e la conservazione anziché solo per organizzare il contenuto per il recupero.

• Prendere in considerazione la possibilità di organizzare il contenuto in cartelle per semplificare lo spostamento, anche insieme ad altre opzioni di spostamento, se questa soluzione garantisce un'esperienza utente ottimale.

• Quando si utilizza Content Organizer per spostare automaticamente i documenti in cartelle in base ai metadati, valutare la possibilità di abilitare l'opzione per la creazione di elementi aggiuntivi in sottocartelle qualora venga raggiunto un limite specifico.

• Se si prevede di utilizzare Apri con Esplora risorse (WebDAV), è necessario organizzare gli elementi in cartelle con un numero di elementi inferiore alla soglia della visualizzazione elenco nella radice di una cartella specifica.

• Per recuperare il contenuto in visualizzazioni elenco, è necessario utilizzare lo spostamento basato su metadati e gli indici se non si utilizzano le cartelle.

Esempio di un elenco di collaborazione di grandi dimensioni e di cartelle: raccolta di specifiche di prodotto

Nella raccolta di specifiche di prodotto le cartelle vengono utilizzate per semplificare lo spostamento e per inserire il contenuto in modo logico. È evidente per gli utenti quale cartella devono utilizzare per creare una nuova specifica di prodotto. Esiste una cartella per ogni tipo di prodotto e ogni tipo di prodotto include più cartelle per ogni team di prodotto. Ogni team di prodotto dispone di un set di documenti per ogni prodotto in fase di progettazione e i documenti specifici di un prodotto vengono archiviati nel set di documenti. In questo modo viene creata una struttura simile alla seguente:

• Sci alpino - Tipo di prodotto (cartella)

  • Sci da competizione - Team prodotto (cartella)

    Discese super rapide X - Prodotto (set di documenti)

È possibile configurare valori predefiniti di metadati per ognuna delle cartelle in modo da semplificare per gli utenti della raccolta l'individuazione del contenuto tramite le cartelle.

Esempio di un archivio su larga scala e di cartelle: Centro record

Il sito Centro record viene utilizzato per l'archiviazione a lungo termine di elementi che devono essere conservati per conformità a requisiti legali, ma il cui contenuto non viene più modificato attivamente. In questo scenario gli elementi vengono automaticamente distribuiti in due cartelle: con restrizioni e riservata. La cartella con restrizioni è associata ad autorizzazioni restrittive, che consentono l'accesso a un numero limitato di utenti, e include documenti che devono essere conservati per 10 anni. La cartella riservata consente un accesso meno limitato rispetto alla cartella con restrizioni e include documenti che devono essere conservati per 7 anni. In questo modo è possibile ridurre il numero di autorizzazioni univoche e semplificare la gestione delle autorizzazioni poiché gli elementi sono associati alle autorizzazioni in base alla cartella appropriata. La distribuzione degli elementi del Centro record nelle cartelle radice, riservata o con restrizioni viene eseguita in base ai metadati.

Indici

È previsto un limite non configurabile di 20 indici per elenco, inclusi indici composti e funzionalità di SharePoint Server 2010 che indicizzano le colonne per impostazione predefinita. L'aggiunta di indici a un elenco produce un effetto minimo sulle prestazioni, ma influisce su alcune operazioni, ad esempio l'aggiunta e l'aggiornamento. È consigliabile evitare di utilizzare più indici del necessario, poiché gli indici non utilizzati avranno un leggero effetto negativo sulle prestazioni e alcune funzionalità di SharePoint Server 2010 aggiungono indici quando sono attivate. SharePoint Server 2010 ad esempio richiede almeno tre posizioni di indice se si utilizzano le funzionalità di scadenza e di eDiscovery. Lasciare almeno tre posizioni di indice disponibili qualora sia necessario creare nuovi indici in un secondo momento.

In SharePoint Server 2010 viene applicato un meccanismo di indicizzazione specifico per utilizzare la struttura delle tabelle di database. Creare indici in SharePoint Server modificando le impostazioni per l'elenco.

Quando si effettua la pianificazione degli indici, tenere conto di quanto segue:

• Gli indici sono necessari per applicare filtri per elenchi che superano la soglia della visualizzazione elenco.

• Pianificare accuratamente gli indici semplici e composti da creare poiché è previsto un limite di 20 indici.

• Riservare posizioni di indice per le funzionalità di SharePoint Server 2010 che potrebbero creare colonne, ad esempio eDiscovery e la conservazione in base ai criteri di gestione delle informazioni.

• Creare indici singoli se si utilizza un unico campo per filtrare con le web part Query contenuto, se si utilizzano visualizzazioni con filtri e se sono presenti gerarchie e filtri di spostamento basato su metadati spesso utilizzati come singolo filtro.

• Creare indici composti per query che applicano filtri in base a due colonne e in genere restituiscono singolarmente un numero di elementi superiore alla soglia della visualizzazione elenco, ma insieme sono selettivi.

• Gli indici possono influire negativamente sulle prestazioni di alcune operazioni, ad esempio l'aggiunta di un documento o la modifica delle relative proprietà. È consigliabile pertanto creare gli indici solo se necessario.

Pianificare accuratamente gli indici

Per gli elenchi è previsto un limite rigido di 20 indici e le colonne indicizzate rappresentano un elemento molto importante per un elenco di grandi dimensioni. La selezione di indici singoli o composti pertanto deve essere effettuata con estrema cautela. Gli indici vengono utilizzati da diverse funzionalità. La funzionalità spostamento basato su metadati ad esempio indicizza automaticamente in base ai filtri chiave e alle gerarchie di spostamento basato su metadati. È consigliabile creare indici nelle colonne importanti per i filtri nell'architettura delle informazioni e di spostamento.

Indici creati automaticamente

Le funzionalità di SharePoint Server creano indici che vengono conteggiati per il calcolo de limite degli elenchi degli indici. Nella tabella seguente vengono elencate le funzionalità di SharePoint Server 2010 utilizzate comunemente nelle raccolte documenti e che aggiungono colonne indicizzate.

Colonna	Funzionalità	Utilizzo
Stato esenzione e Stato record	Gestione Record in posizione oppure Esenzione ed eDiscovery	Questa colonna viene aggiunta e indicizzata quando viene abilitata la funzionalità delle raccolte siti Gestione Record in posizione oppure la funzionalità Esenzione ed eDiscovery e un elemento viene dichiarato come record o impostato come in esenzione in un elenco.
Data di scadenza, Tipo di contenuto	Criteri gestione informazioni	Queste due colonne vengono aggiunte e indicizzate quando viene abilitata la conservazione per Criteri gestione informazioni in un tipo di contenuto aggiunto all'elenco oppure quando viene abilitata in un elenco la conservazione basata sulla posizione.

Quando creare indici singoli e composti

La funzionalità spostamento basato su metadati crea automaticamente indici appropriati per le colonne gerarchiche e di filtri chiave selezionate nella pagina delle impostazioni dello spostamento basato su metadati. Gli indici singoli vengono creati per tutti i campi degli alberi di gerarchie e per alcuni dei tipi di filtri chiave più selettivi, in modo che possano essere restituiti risultati indicizzati e risultati parziali quando utilizzati singolarmente. Gli indici composti vengono creati per tutte le combinazioni supportate di gerarchie e di filtri chiave per ottimizzare la selettività quando vengono utilizzati sia un filtro albero che un valore di filtro chiave.

Per un elenco contenente molte colonne utilizzabili per applicare filtri, potrebbe essere necessario gestire gli indici manualmente per evitare di raggiungere il limite per gli indici. Se alcune combinazioni di gerarchie di spostamento e filtri chiave non verranno mai utilizzate, valutare la possibilità di non creare indici composti in modo da ridurre il numero di indici. Quando si creano questi indici, è importante scegliere l'indicizzazione singola per le colonne selettive che possono essere utilizzate in modo indipendente nella visualizzazione elenco, come unico filtro o come primo filtro applicato prima di sceglierne un altro. Gli indici composti devono essere utilizzati quando in genere vengono utilizzati insieme due filtri nello spostamento basato su metadati o in query personalizzate e quando un solo indice non è sufficientemente selettivo. Creare indici per le colonne utilizzate per applicare filtri con visualizzazioni elenco, web part e altri metodi di accesso ai dati.

In alcuni casi è possibile che l'utilizzo di più indici non sia utile. Si consideri una situazione in cui si applica un filtro in base a due colonne, Divisione e Tipo di contenuto. Poiché questa è un'operazione AND, viene restituita solo l'intersezione in corrispondenza della quale vengono soddisfatti i criteri dei filtri per Divisione e Tipo di contenuto. Quando viene eseguita la query, vengono restituiti pertanto per primi tutti gli elementi che corrispondono al filtro Divisione e quindi gli elementi filtrati in base a Tipo di contenuto. Se solo 10 elementi corrispondono a una divisione specifica, il set di dati sarà sufficientemente ridotto da rendere ininfluente un indice in Tipo di contenuto. Se invece sono presenti migliaia di elementi che corrispondono al valore di Divisione, è consigliabile utilizzare un indice composto.

Gli indici composti consentono di creare un indice in due colonne per l'esecuzione di query più efficienti. È consigliabile utilizzare gli indici composti quando si esegue un'operazione AND su due colonne. Lo spostamento basato su metadati è l'unica funzionalità di SharePoint Server incorporata in cui vengono utilizzati gli indici composti. Quando è abilitata la funzionalità spostamento basato su metadati, viene utilizzata la logica dei nuovi tentativi e di fallback anche se per l'elenco non sono configurati controlli di spostamento basato su metadati. Gli indici composti non vengono utilizzati dalle visualizzazioni, a meno che non si tratti di una query di spostamento basato su metadati.

Effetto degli indici sulle prestazioni

Gli indici consentono di eseguire query su elenchi con un numero di elementi superiore alla soglia della visualizzazione elenco in un singolo contenitore e possono garantire un miglioramento significativo delle prestazioni. Benché gli indici siano necessari per eseguire query efficienti su elenchi di grandi dimensioni e possano migliorare in modo significativo le prestazioni, possono anche produrre un effetto negativo su altre operazioni perché richiedono attività di manutenzione. Quando vengono creati, aggiornati ed eliminati indici, devono essere aggiornati anche gli indici a cui partecipa l'elemento. Il testing è stato eseguito con operazioni di caricamento, aggiornamento ed eliminazione in un elenco con 10.000 elementi ed è risultato che l'effetto prodotto da un numero di indici compreso tra 0 e 20 è stato inferiore del 10%.

Creazione di indici

Per impostazione predefinita, la funzionalità spostamento basato su metadati crea automaticamente indici singoli e composti. Questa opzione può essere disabilitata dalla pagina delle impostazioni dello spostamento basato su metadati. Questa funzionalità crea automaticamente un indice singolo per ogni tipo di colonna supportato e indici composti per ogni combinazione supportata di filtri chiave e gerarchie di spostamento. Non vengono creati automaticamente indici composti per combinazioni di due filtri chiave, anche se è possibile crearli manualmente. Lo spostamento basato su metadati crea automaticamente indici singoli e composti per la maggior parte dei tipi di colonne che supportano gli indici. Non vengono creati automaticamente indici singoli per tipi di filtri chiave che includono un numero di valore inferiore e potrebbero non essere selettivi se utilizzati individualmente. Rientrano in questa categoria le colonne Sì/No, le colonne di tipo Scelta a valore singolo o le colonne tipo di contenuto, ma gli indici sono comunque supportati e possono essere creati manualmente.

Colonne supportate per indici singoli

Nella tabella seguente vengono fornite informazioni sugli indici creati automaticamente dallo spostamento basato su metadati. Questa funzionalità crea indici a valore singolo per tutte le colonne che supportano la creazione di un indice.

Tipo di colonna	Creazione indice
Gerarchie di spostamento
Metadati gestiti a valore singolo	Sì
Metadati gestiti multivalore	No (sistema indicizzato come multivalore)
ID tipo di contenuto	Sì
Scelta a valore singolo	Sì
Cartella	No (sistema indicizzato per cartella)
Filtri chiave
Metadati gestiti a valore singolo	Sì
Metadati gestiti multivalore	No (sistema indicizzato come multivalore)
ID tipo di contenuto	No (può essere creato manualmente)
Scelta a valore singolo	No (può essere creato manualmente)
Scelta multivalore	No (non supportato come indicizzato)
Numero	Sì
Data	Sì
Sì / No	No (può essere creato manualmente)
Valuta	Sì
Utente (valore singolo)	Sì
Utente (multivalore)*	No (sistema indicizzato come multivalore)
Tutti i tag	No (sistema indicizzato come multivalore; filtro speciale su tutti i valori di metadati gestiti nell'elemento)

Indici composti creati automaticamente

Con la funzionalità spostamento basato su metadati, gli utenti possono selezionare una combinazione di filtro chiave e struttura di spostamento. Questa funzionalità crea automaticamente gli indici composti per tutte le combinazioni supportate di filtri chiave e gerarchie di spostamento. Nella tabella seguente vengono elencate le combinazioni supportate.

Gerarchie di spostamento	Metadati gestiti a valore singolo	Metadati gestiti multivalore	ID tipo di contenuto	Scelta singola	Cartella
Filtri chiave
Metadati gestiti a valore singolo	Sì	No	Sì	No	No
Metadati gestiti multivalore	No	No	No	No	No
ID tipo di contenuto	Sì	No	No	No	No
Scelta a valore singolo	No	No	No	No	No
Scelta multivalore	No	No	No	No	No
Numero	Sì	No	Sì	No	No
Data	Sì	No	Sì	No	No
Utente (singolo)	Sì	No	Sì	No	No
Tutti i tag	No	No	No	No	No
Sì / No	Sì	No	Sì	No	No
Valuta	Sì	No	Sì	No	No
Utente (multivalore)	No	No	No	No	No

Selettività dei metadati

L'importanza della selettività dei metadati aumenta con l'aumento delle dimensioni dell'elenco. Le indicazioni seguenti si applicano a qualsiasi dimensione di elenco, ma potrebbero non essere altrettanto importanti per elenchi di piccole dimensioni.

Per selettività si intende la quantità di elementi di cui tenere conto per la restituzione dei risultati di una query. È necessario distinguere tra selettività effettiva, ovvero il numero totale di risultati che soddisfano la condizione di ricerca di una query, e selettività di limitazione, ovvero il numero di risultati da prendere in considerazione dopo l'applicazione di condizioni che si applicano alle colonne indicizzate. La selettività effettiva è l'aspetto principale da prendere in considerazione per l'esperienza utente, mentre la selettività di limitazione è l'aspetto principale da prendere in considerazione per l'effetto sull'istanza di SQL Server.

Per utilizzare in modo efficiente lo spostamento basato su metadati e altri meccanismi di filtro degli elenchi, è necessario che i metadati utilizzati per filtrare siano selettivi. Per impostazione predefinita, nelle visualizzazioni elenco vengono elencati 30 elementi, in modo che gli utenti possano analizzare i risultati rapidamente per individuare i dati desiderati. Se le query restituiscono più di 30 risultati, gli utenti devono utilizzare la suddivisione in pagine per trovare i risultati desiderati. Se si utilizza una web part Query contenuto, il numero di risultati in genere è compreso tra 10 e 15. I risultati in eccesso non vengono visualizzati. Se una query restituisce centinaia di risultati, è difficile individuare i dati desiderati. La selettività è importante inoltre per evitare che vengano eseguite operazioni che superano la soglia della visualizzazione elenco, che nel caso dello spostamento basato su metadati determina il fallback e la restituzione di risultati parziali.

Content Organizer e bilanciamento automatico

Il componente Content Organizer può svolgere un ruolo fondamentale per l'organizzazione del contenuto in un archivio documenti. Per gli archivi in cui viene utilizzato Content Organizer è disponibile un'interfaccia di invio che consente agli utenti di caricare un documento con stato finale. Vengono elencati di seguito alcuni esempi di scenari in cui è possibile utilizzare Content Organizer:

• Distribuzione automatica di documenti basati su metadati tra siti diversi e all'interno di siti.

• Distribuzione automatica di documenti e creazione automatica di nuove cartelle, ad esempio cartelle basate sul giorno, il mese e l'anno.

• Bilanciamento automatico del numero di elementi nelle cartelle.

Accesso e recupero dei dati

Lo scopo principale della maggior parte degli elenchi di grandi dimensioni è l'archiviazione di contenuto in modo che possa essere recuperato. È importante pianificare il modo in cui gli utenti recupereranno il contenuto, poiché sarà il fattore che produrrà l'effetto maggiore sulle prestazioni di un elenco di grandi dimensioni e sull'esito dell'implementazione di elenchi di grandi dimensioni. Per consentire agli utenti di recuperare il contenuto, è possibile utilizzare diverse funzionalità, tra cui la ricerca, lo spostamento basato su metadati, le web part Query contenuto e le visualizzazioni. Vengono utilizzate in genere anche soluzioni personalizzate, ad esempio web part personalizzate che eseguono query sui dati. Pianificare in anticipo il modo in cui sarà organizzato il sito Web. È possibile utilizzare una pagina di destinazione centrale, ad esempio la home page del sito Centro documenti, per offrire il riepilogo del contenuto e fornire punti di ingresso nell'elenco di grandi dimensioni. È inoltre possibile utilizzare pagine di pubblicazione per creare un sito Web in cui vengono trattati diversi argomenti in ogni pagina e quindi vengono utilizzate web part per estrarre documenti o elementi correlati dall'elenco di grandi dimensioni. Vengono riportate di seguito alcune considerazioni sull'accesso e il recupero di dati:

• È possibile utilizzare una combinazione qualsiasi di ricerca, web part Query contenuto, spostamento basato su metadati, visualizzazioni elenco e web part personalizzate.

• Pianificare in anticipo come verrà recuperato il contenuto e quali colonne verranno utilizzate per i filtri e l'ordinamento.

• Pianificare il modello della pagina di base. Valutare se tutto il lavoro verrà eseguito nella raccolta documenti o se deve esistere una pagina di destinazione o un modello a più pagine per il collegamento con il contenuto correlato.

Metodi di accesso ai dati

È possibile utilizzare tre funzionalità di SharePoint Server 2010 principali per eseguire query e filtri su dati di elenchi con una configurazione semplice: visualizzazione elenco e spostamento basato su metadati, web part Query contenuto e ricerca. Le altre opzioni disponibili per l'utilizzo di codice personalizzato per eseguire query su un elenco non sono descritte in questo articolo.

• Le visualizzazioni consentono di configurare le colonne che vengono visualizzate. Sono disponibili diversi metodi di visualizzazione per i dati di elenco. Le visualizzazioni possono essere configurate per filtrare e ordinare i risultati in base alle colonne.

  • Lo spostamento basato su metadati è un controllo di filtro per le visualizzazioni elenco di SharePoint Server 2010. Quando viene configurato lo spostamento basato su metadati, è possibile selezionare le gerarchie di metadati e i filtri chiave per filtrare in modo dinamico i risultati riportati in una visualizzazione elenco.

• La web part Query contenuto consente di visualizzare i dati di elenchi di SharePoint Server 2010. È possibile configurare query per restituire risultati da uno o più elenchi. Per impostazione predefinita, la web part Query contenuto è memorizzata nella cache, ma può anche non essere memorizzata nella cache.

• Possono essere utilizzate caselle di ricerca o web part Risultati di ricerca per restituire i risultati di ricerca. È possibile limitare questi risultati a un elenco specifico ed eseguire una ricerca guidata utilizzando i controlli di perfezionamento basati su metadati di ricerca.

Nella tabella seguente vengono elencati i metodi di query e il relativo utilizzo.

Metodo di query	Utilizzo
Visualizzazione elenco e spostamento basato su metadati	Le visualizzazioni elenco accedono sempre al database back-end di SQL Server, generando query il cui effetto sulle prestazioni e il cui carico su SQL Server risultano essere tra i più significativi. Utilizzare le visualizzazioni elenco per offrire un numero maggiore di opzioni per l'interazione con i documenti (proprietà di modifica, archiviazione, estrazione) e l'accesso ai dati in tempo reale.
Web part Query contenuto	Le web part Query contenuto utilizzano il provider della mappa del sito portale per memorizzare le query nella cache ed eseguono il rendering della quantità minima di HTML, determinando in questo modo tempi di query e di rendering più rapidi. Utilizzare le web part Query contenuto per lo spostamento dinamico e per l'esecuzione di più query in una singola pagina.
Web part Query contenuto non memorizzata nella cache	Per garantire l'accesso ai dati in tempo reale, la web part Query contenuto può eseguire query direttamente sul database. Utilizzare questa configurazione se la query non può essere memorizzata nella cache, se sono necessari aggiornamenti in tempo reale e per le pagine a cui si accede meno di una volta all'ora, in modo che non vengano mai inseriti dati nella cache. Il carico iniziale di una web part Query contenuto memorizzata nella cache comporta un ulteriore sovraccarico.
Ricerca	Utilizzare le query di ricerca per la ripartizione del carico di lavoro delle letture in un'infrastruttura di server più facilmente scalabile e ottimizzata per le prestazioni di lettura. È possibile configurare le query di ricerca per l'utilizzo di query statiche oppure consentire agli utenti di specificare query di ricerca.

Web part Query contenuto

Nella tabella seguente vengono elencati i vantaggi e gli svantaggi derivanti dall'utilizzo delle web part Query contenuto.

Vantaggi

Svantaggi

Ideale come componente per lo spostamento, ad esempio come collegamento a documenti o pagine correlate. Configurazione semplice per la visualizzazione di colonne diverse. Possibilità di utilizzare più web part Query contenuto in una stessa pagina. Tempo di rendering più rapido rispetto alle visualizzazioni elenco e alla ricerca. Memorizzazione nella cache per impostazione predefinita, con riduzione del carico su SQL Server.

Possibilità di visualizzare solo un numero limitato di proprietà. Collegamenti diretti solo con elementi come il documento, la pagina o la voce di elenco stessa. Impossibilità di eseguire azioni elenco.

La web part Query contenuto viene utilizzata per recuperare il contenuto dagli elenchi. Può essere utilizzata per le pagine, i documenti e le voci di elenco. Per impostazione predefinita, le web part Query contenuto vengono memorizzate nella cache, in modo da offrire prestazioni migliori e produrre un effetto ridotto sulle risorse di SQL Server. Poiché l'impostazione della cache predefinita è di 30 minuti, i dati sono sempre abbastanza aggiornati. In questo modo tuttavia la web part Query contenuto utilizza più risorse di SQL Server rispetto alle query di ricerca. Poiché le web part Query contenuto eseguono il rendering della quantità minima di HTML, sono più rapide per il rendering delle pagine ed è possibile configurarne più di una in una singola pagina. Le web part Query contenuto memorizzate nella cache offrono un rapido accesso ai dati anche se aumentano le dimensioni degli elenchi. Le web part Query contenuto non memorizzate nella cache offrono una latenza quasi analoga a quella di una query di visualizzazione elenco simile.

È consigliabile utilizzare le web part Query contenuto come componente di spostamento e per fornire il riepilogo del contenuto nelle pagine. È ad esempio possibile utilizzare pagine per offrire panoramiche di contenuto presente in una raccolta documenti e quindi utilizzare le web part Query contenuto per restituire pagine e documenti correlati. Altri esempi includono gli elementi modificati dall'utente corrente, gli elementi più recenti e gli elementi con valutazioni elevate. La web part Query contenuto può essere utilizzata in scenari con molte operazioni di lettura in cui la maggior parte degli utenti non esegue operazioni di elenco come l'archiviazione, l'estrazione o la gestione delle versioni. La figura riportata di seguito rappresenta una web part Query contenuto che visualizza documenti con valutazioni elevate.

La web part Query contenuto può essere utilizzata per accedere al contenuto senza aprire una visualizzazione elenco. È possibile che gli utenti accedano frequentemente solo a una quantità limitata di contenuto o desiderino tenere traccia di un numero ridotto di elementi. Per impostazione predefinita, nel modello di sito Centro documenti vengono utilizzate tre web part Query contenuto: una che restituisce gli elementi modificati dall'utente che ha eseguito l'accesso, un'altra per i documenti con valutazioni elevate e una terza per i documenti più recenti. Queste tre web part Query contenuto combinate forniscono una pagina di destinazione in cui è presente contenuto a cui un utente accede frequentemente o è maggiormente interessato. In questo modo è possibile individuare nuovo contenuto e accedere rapidamente a documenti utilizzati frequentemente. Un altro esempio è rappresentato dalla creazione di un elenco di preferiti in modo che gli utenti possano contrassegnare il contenuto di cui tenere traccia e quindi utilizzare una web part Query contenuto per restituire l'elenco di preferiti e accedere rapidamente al contenuto utilizzato frequentemente senza accedere all'elenco stesso.

Quando si utilizza una web part Query contenuto con un elenco di grandi dimensioni, è necessario tenere conto di alcuni aspetti importanti in modo che restituisca correttamente i risultati e non venga bloccata dalla soglia della visualizzazione elenco. Gli elementi devono essere filtrati con una colonna indicizzata fino a ottenere una quantità inferiore alla soglia della visualizzazione elenco. Non è consigliabile utilizzare query tra elenchi se uno degli elenchi è di grandi dimensioni. Se il numero totale di elementi considerati nella query tra elenchi supera la soglia della visualizzazione elenco per controlli e amministratori (per impostazione predefinita 20.000), l'operazione viene bloccata.

Riepilogo dei consigli relativi alle web part Query contenuto

• Utilizzare le web part Query contenuto per restituire elementi a cui gli utenti accedono frequentemente, a cui sono interessati o che possono essere utili per individuare il contenuto.

• Se si utilizza una web part Query contenuto su un elenco di grandi dimensioni, è consigliabile filtrare gli elementi in modo che la query non superi la soglia della visualizzazione elenco.

• Per filtrare, utilizzare solo colonne con indici.

• Non utilizzare la web part Query contenuto per eseguire query su più elenchi se la quantità di elementi considerati è superiore alla soglia della visualizzazione elenco per controllori e amministratori (per impostazione predefinita 20.000).

• Utilizzare la memorizzazione nella cache per tempi di caricamento più rapidi e un carico inferiore su SQL Server.

Web part di ricerca

Nella tabella seguente vengono elencati i vantaggi e gli svantaggi derivanti dall'utilizzo delle web part di ricerca.

Vantaggi

Svantaggi

Ripartizione del carico di lavoro delle query da computer che eseguono SQL Server a server di ricerca più facilmente scalabili. I server di query e di indice di ricerca sono più scalabili e offrono prestazioni migliori rispetto all'esecuzione di query dirette su SQL Server. I risultati sono basati sulla ricerca full-text di documenti anziché solo su metadati. Riepiloghi di testo offrono maggiori informazioni sui risultati rispetto alle web part Query contenuto.

I risultati sono meno recenti e risalgono all'ultima ricerca per indicizzazione. Nei risultati non vengono visualizzati i valori delle colonne. Impossibilità di eseguire azioni elenco.

Le query di ricerca garantiscono una scalabilità migliore rispetto all'accesso diretto alle risorse di SQL Server, poiché la ricerca è ottimizzata per scenari con intense attività di lettura ed è più semplice implementare la scalabilità orizzontale su più server di query e di indice di ricerca anziché implementare la scalabilità delle istanze di SQL Server. È possibile utilizzare web part di ricerca preconfigurate, caselle di ricerca o una combinazione di queste soluzioni per consentire agli utenti di recuperare il contenuto. Le query di ricerca consentono di ripartire il carico delle query negli indici di ricerca, riducendo il carico su SQL Server. Questo tipo di query è inoltre meno soggetto all'effetto prodotto dalle dimensioni degli elenchi rispetto alle web part Query contenuto o alle visualizzazioni elenco.

È possibile utilizzare la ricerca in qualsiasi scenario per visualizzare i risultati di query preconfigurate o specificate dall'utente. La ricerca offre le prestazioni migliori su larga scala. Non è consigliabile utilizzarla se devono essere eseguite azioni elenco su elementi o se i dati devono essere visualizzati in tempo reale, poiché i risultati risalgono all'ultima ricerca per indicizzazione. Nella tabella seguente vengono elencate le tre web part di ricerca che possono essere utilizzate.

Web part di ricerca	Descrizione
Web part Risultati di ricerca	Risultati completi con suddivisione in pagine. Questa web part è la più completa a livello di funzionalità. Può basarsi su query di sistema o specificate dall'utente.
Web part Risultati federati	Set limitato di risultati con un collegamento facoltativo per l'accesso ai risultati completi.
Web part Casella di ricerca	Web part che si basa sull'input dell'utente per una query.

Visualizzazioni elenco

Nella tabella seguente vengono elencati i vantaggi e gli svantaggi derivanti dall'utilizzo delle visualizzazioni elenco.

Vantaggi	Svantaggi
È possibile utilizzare azioni di visualizzazione elenco come l'archiviazione, l'estrazione e la modifica delle proprietà per interagire con i documenti. Facilità di personalizzazione delle visualizzazioni e di abilitazione di diverse colonne da visualizzare. Esperienza interattiva per l'applicazione di filtri dinamici e l'ordinamento dei risultati in tempo reale.	Massimo impatto negativo sulle prestazioni per latenza e velocità effettiva. Tempo di rendering più lento. L'esperienza utente migliore si ottiene con una sola web part Visualizzazione elenco per pagina.

Le visualizzazioni elenco e lo spostamento basato su metadati possono supportare il recupero di contenuto in raccolte documenti di grandi dimensioni in cui vengono utilizzate cartelle o indici oppure entrambe le soluzioni. Le query con una visualizzazione elenco vengono eseguite in tempo reale e direttamente sul database di SQL Server. In questo modo si ottengono i risultati più aggiornati. Questo metodo tuttavia è quello che produce l'effetto più significativo sulle prestazioni. La velocità effettiva totale diminuirà e la latenza delle operazioni aumenterà con elenchi di grandi dimensioni. Le visualizzazioni elenco inoltre eseguono il rendering della quantità di contenuto massima che può essere supportata da una pagina e pertanto il tempo di rendering delle pagine è spesso più lento con una visualizzazione elenco.

È consigliabile utilizzare lo spostamento basato su metadati e le visualizzazioni elenco se si desidera poter eseguire azioni visualizzazione elenco sugli elementi. Le visualizzazioni elenco possono costituire il metodo di utilizzo principale di un elenco in scenari con ridotte attività di lettura. In scenari in cui vengono eseguite numerose attività di lettura è consigliabile valutare altri metodi di query come metodo principale per accedere ai dati di elenco.

Configurazione delle visualizzazioni

Riepilogo dei consigli relativi alla configurazione delle visualizzazioni

• Selezionare accuratamente le colonne utilizzate nelle visualizzazioni. Maggiore è il numero di colonne, maggiore sarà la quantità di dati di cui eseguire il rendering, con un conseguente rallentamento dei tempi di caricamento delle pagine. È possibile trovare un compromesso tra tempi di caricamento delle pagine ed esperienza utente ottimale.

• Ridurre al minimo il numero di colonne di ricerca, ad esempio metadati gestiti e utenti e gruppi nelle visualizzazioni, poiché queste colonne determinano l'esecuzione di join con altre tabelle di database e comportano un aumento del carico sul database.

• Non utilizzare totali per le colonne.

• Se le visualizzazioni non vengono filtrate utilizzando colonne indicizzate, selezionare l'opzione di visualizzazione degli elementi nelle cartelle e accertarsi che le singole cartelle non includano un numero di elementi superiore alla soglia della visualizzazione elenco.

• Le visualizzazioni devono essere filtrate in base alle colonne indicizzate per ridurre il numero di elementi che vengono restituiti, in modo che il numero sia inferiore alla soglia della visualizzazione elenco (soprattutto se non sono presenti sottocartelle o se le cartelle includono un numero di elementi superiore alla soglia della visualizzazione elenco).

• Abilitare la funzionalità spostamento basato su metadati per restituire i risultati più recenti per le query, che altrimenti verrebbero bloccate dalla soglia della visualizzazione elenco. Per impostazione predefinita, questa funzionalità è abilitata in quasi tutti i siti.

• Se si utilizzano visualizzazioni filtrate in combinazione con lo spostamento basato su metadati, valutare la possibilità di utilizzare le visualizzazioni per posizione per creare visualizzazioni non filtrate per i pivot di spostamento basato su metadati in modo che vengano restituiti tutti i risultati.

Numero di colonne e colonne di ricerca

Il metodo più comune utilizzato per l'accesso ai dati di elenco è rappresentato dalle visualizzazioni. È consigliabile pertanto selezionare accuratamente le visualizzazioni per ottimizzare la ricerca di contenuto da parte degli utenti e soddisfare i requisiti per le prestazioni. Nel caso di un elenco di grandi dimensioni, prestare particolare attenzione alla configurazione delle visualizzazioni. È consigliabile utilizzare solo visualizzazioni standard e personalizzate. Non è opportuno utilizzare visualizzazioni Foglio dati, Gantt e Calendario con elenchi che superano la soglia della visualizzazione elenco, poiché possono essere bloccate da tale soglia. Le visualizzazioni dovrebbero includere il minor numero possibile di colonne. È consigliabile inoltre procedere con estrema cautela con il numero di colonne di ricerca (metadati gestiti, utenti e gruppi e tipi di ricerca), poiché le ricerche eseguono join con altre tabelle con effetti negativi sulle prestazioni.

Applicazione di filtri alle colonne e totali

Per la nuova soglia della visualizzazione elenco in SharePoint Server 2010 è stata apportata una modifica importante relativa all'utilizzo delle visualizzazioni con elenchi di grandi dimensioni. Gli utenti visualizzeranno errori se le visualizzazioni tentano di restituire un numero di risultati superiore alla soglia della visualizzazione elenco. Evitare di utilizzare i totali in un elenco di grandi dimensioni, poiché verranno sempre bloccati dalla soglia della visualizzazione elenco. Il fattore importante di cui tenere conto è il numero di elementi da analizzare e non necessariamente il numero di righe restituite. Se una visualizzazione include un filtro in cui la colonna Colore deve essere uguale a "Rosso" e Colore non è una colonna indicizzata, è possibile che venga bloccata. Anche se i criteri della query vengono soddisfatti da appena 100 elementi, se nell'elenco sono inclusi 10.000 elementi la query li dovrà analizzare tutti. In questo caso, gli utenti ottengono errori quando tentano di accedere alla visualizzazione. Per risolvere il problema, è possibile utilizzare cartelle, filtri e indici, nonché lo spostamento basato su metadati.

Cartelle

Se un elenco è organizzato in modo che nessuna cartella includa un numero di elementi superiore alla soglia della visualizzazione elenco, è possibile selezionare l'opzione di visualizzazione degli elementi nelle cartelle. È consigliabile evitare di visualizzare tutti gli elementi all'esterno di cartelle, a meno che non si disponga di meccanismi per filtrare i risultati in modo da ottenere un numero di elementi inferiore alla soglia della visualizzazione elenco.

Indicizzazione

In un esempio precedente l'esecuzione di una query in base alla colonna Colore ha avuto esito negativo perché la colonna non era indicizzata. Per risolvere questo problema, è possibile indicizzare la colonna Colore. Le query quindi avranno esito positivo se i valori sono sufficientemente distinti. Se sono presenti solo 100 elementi rossi, l'operazione avrà esito positivo. Se invece il numero di elementi che soddisfano i criteri della query è superiore alla soglia della visualizzazione elenco, la visualizzazione verrà comunque bloccata, indipendentemente dall'indicizzazione. Per impostazione predefinita, il campo ID, la struttura di cartelle e le ricerche multivalore sono indicizzati nel sistema. Le nuove colonne create e utilizzate per i filtri devono includere indici creati manualmente.

Visualizzazioni di esempio

Elementi modificati recentemente

La visualizzazione elementi modificati recentemente viene utilizzata per visualizzare gli elementi che sono stati modificati più di recente. Può essere utilizzata come visualizzazione predefinita quando gli utenti accedono frequentemente a contenuto di origini diverse che sono state modificate recentemente. È facile configurare questa visualizzazione poiché utilizza i metadati di sistema, che vengono impostati sempre per ogni elemento. Per un elenco di grandi dimensioni, è necessario impostare il limite di elementi su un valore inferiore alla soglia della visualizzazione elenco oppure filtrare i risultati in modo da ottenere un numero di elementi inferiore alla soglia della visualizzazione elenco. Per creare questa visualizzazione, è necessario indicizzare il campo modificato e ordinare la visualizzazione con una sequenza decrescente. Specificare un filtro per la colonna Data modifica e utilizzare la formula [Oggi-x], dove x indica i dati del numero di giorni da visualizzare. Selezionare l'opzione maggiore di o uguale a. La formula, [Oggi-x] dovrebbe restituire un numero di elementi inferiore alla soglia della visualizzazione elenco.

Elementi personali

La visualizzazione Elementi personali può essere utilizzata negli archivi in cui gli utenti accedono frequentemente ai propri documenti. È facile configurare questa visualizzazione poiché utilizza i metadati di sistema, che vengono impostati sempre per ogni elemento. In questa visualizzazione viene applicato un filtro in base alle colonne Modificato da o Autore oppure in base a entrambe le colonne. Per creare questa visualizzazione nei filtri, selezionare la colonna Modificato da, impostare il valore su [Utente] e quindi impostare un secondo filtro con OR nella colonna Autore con valore [Utente]. La colonna Autore deve essere utilizzata insieme alla colonna Modificato da se più utenti modificano gli stessi documenti. Modificato da non è una colonna multiutente. Questa visualizzazione pertanto non mostrerà necessariamente tutti i documenti modificati da un utente. In questo esempio entrambe le colonne devono essere indicizzate poiché l'operazione è di tipo OR.

Conclusioni

In SharePoint Server 2010 sono disponibili sia funzionalità nuove che migliorate che consentono di ottimizzare l'esperienza utente e le prestazioni per l'utilizzo di elenchi di grandi dimensioni. Limitazioni e valori di soglia proteggono le prestazioni della farm per altri utenti e impediscono alle operazioni di utilizzare una quantità eccessiva di risorse di SQL Server. I miglioramenti apportati ai metadati e lo spostamento basato su metadati consentono di recuperare in modo ancora più efficiente i dati di elenco, mentre le web part Query contenuto, la ricerca e le visualizzazioni elenco possono essere configurate per l'utilizzo con elenchi di grandi dimensioni. È sempre necessario eseguire una pianificazione accurata per la creazione di soluzioni adatte alle proprie esigenze. È comunque possibile sviluppare rapidamente elenchi di grandi dimensioni configurando soluzioni predefinite progettate per offrire prestazioni ottimali.

See Also

Other Resources

Centro risorse: Gestione della capacità in SharePoint Server 2010