Projetar listas grandes e maximizar o desempenho da lista (SharePoint Server 2010)

 

Aplica-se a: SharePoint Server 2010

Tópico modificado em: 2016-11-30

Este artigo fornece informações sobre o desempenho de grandes bibliotecas de documento e grandes listas. As recomendações neste artigo são o resultado de uma série de testes de desempenho que foram conduzidos com o Microsoft SharePoint Server 2010. O foco deste artigo é nas características de desempenho de grandes listas e em como diferentes configurações afetam o desempenho de grandes listas no farm. O SharePoint Server 2010 possui várias melhorias que tornam mais fácil criar e usar grandes listas. No entanto, criar e implementar grandes listas exige um planejamento cuidadoso. Você deve considerar vários fatores, como a arquitetura da informação, desempenho, recuperação de desastres e controle. Este artigo abrange informações de arquitetura e recursos que são usados para implementar grandes listas e abrange o efeito que configurações específicas têm sobre o desempenho.

Existem também escolhas principais na criação que você deve fazer que podem afetar o desempenho de grandes listas. Estas incluem permissões, o número de colunas adicionadas a uma lista, o número de colunas de pesquisa nas exibições e as pastas e os índices que são usados para organizar uma lista. Essas decisões afetam o desempenho das listas e esse efeito torna-se muito maior conforme o tamanho de uma lista aumenta. Este artigo explica como as diferentes escolhas na criação afetam o desempenho de grandes listas, para que você possa criar adequadamente uma grande lista que cumpre os requisitos de desempenho enquanto também cumpre os requisitos administrativos e fornece uma boa experiência ao usuário.

Embora este artigo seja específico para o SharePoint Server 2010, as acelerações e limites também se aplicam ao Microsoft SharePoint Foundation. Ele apresenta vários recursos que aumentam muito a experiência do trabalho com grandes listas e estão disponíveis apenas no SharePoint Server 2010. Nenhuma distinção entre o SharePoint Foundation e o SharePoint Server é feita neste artigo.

Neste artigo:

• Compreendendo os métodos de consulta

• Exemplo de cenários com grandes listas

• Grandes listas e o SharePoint Server 2010

• Medições de desempenho e metodologia de teste

• Aceleração e limites

• Outros limites

• Diferenças entre grandes listas e listas regulares

• Criação e implementação de grandes listas

• Conclusão

Compreendendo os métodos de consulta

Existem três métodos principais que podem ser usados para acessar os dados da lista: exibições de lista com navegação de metadados, Web Part de Consulta de Conteúdo e pesquisa. Cada método possui prós, contras e usos particulares para os quais eles são adequados.

Exibição de lista e navegação de metadados

A exibição de lista sempre acessa o banco de dados do Microsoft SQL Server. Isto resulta em um desempenho de consulta mais lento e uma carga maior nos recursos do SQL Server do que os outros métodos. Exibições de lista também renderiza muitos HTMLs, que resulta em um tempo de carregamento da página mais lento do que os outros métodos. As exibições de lista fornecem uma melhor experiência para os usuários configurarem exibições, filtrar dados dinamicamente e realizar ações em documentos, como gerenciar versões e editar propriedades. É possível usar a navegação de metadados para filtrar os resultados da exibição de lista. Você deve usar exibições de lista quando deve ter uma coluna de dados rica e acesso às ações do item da lista. Em cenários de alta leitura e consulta, você deve considerar usar outros métodos de consulta.

Web Part de Consulta de Conteúdo

A Web Part de Consulta de Conteúdo mostra uma exibição de dados configurados estatisticamente que é armazenado em cache usando o Fornecedor de Mapa do Site de Portal para melhor desempenho. A Web Part de Consulta de Conteúdo renderiza menos HTML e é armazenado em cache. O resultado é um tempo de carregamento da página mais rápido e torna mais fácil ter várias consultas em uma página. A Web Part de Consulta de Conteúdo deve ser usada para exibir links para itens da lista relacionados, documentos ou páginas. Embora a Web Part de Consulta de Conteúdo possa também ser configurado como não armazenado em cache, você deve usar esta configuração somente em páginas nas quais os requisitos de resultados são baixos ou em páginas no qual o cache não é útil, como aquelas onde as consultas serão alteradas com base no usuário que acessa a página.

Pesquisar

A Web Part de Pesquisa pode ser usada para descarregar consultas para um sistema que é otimizado para localizar conteúdo (versus as propriedades de edição e visualização de atualizações em tempo real). Ela pode ser configurada para consultas estáticas ou especificadas pelo usuário. A Web Part de Pesquisa possui um bom desempenho, no entanto, os dados são apenas tão atuais quanto o rastreamento mais recente. Isso significa que os resultados são mais antigos do que os resultados das exibições de lista e Web Part de Consulta de Conteúdo.

Exemplo de cenários com grandes listas

Existem alguns cenários de grandes listas comuns e, dependendo do cenário, você realizará diferentes decisões de criação. Por exemplo, em um cenário de grande lista colaborativo, os usuários estão adicionando frequentemente conteúdo e propriedades de atualização. Nesse tipo de cenário, você não deseja que o tamanho da lista cresça para milhões de itens, pois pode ser difícil filtrar o conteúdo por ele ser frequentemente atualizado e alterado. Se você está trabalhando com bibliotecas de documentos não estruturadas, este artigo pode ajudar você a compreender as acelerações e os limites que protegem o desempenho do SQL Server. A seguinte tabela exibe as considerações para cenários de grandes listas.

Cenário	Tamanho da lista	Gerenciamento	Taxa de lidos/atualizados/adicionados	Novo conteúdo	Usuários
Biblioteca de documentos não estruturada	Não lidos	Sem gerenciamento	Altas leituras, adições balanceadas e atualizações	Carregamento manual	Dezenas
Grande lista de colaboração ou biblioteca	Milhares	Proprietários de assuntos informais	Altas leituras, mais atualizações do que adições	Carregamento manual	Centenas
Grande repositório estruturado	Dezenas de milhares	Administradores de conteúdo dedicados	Muito mais leituras, menos adições e significantemente menos atualizações	Envio e carregamento	Dezenas de milhares
Arquivo de grande escala	Milhões	Equipe de administradores de conteúdo	Poucas leituras e atualizações, muitas adições	Envio	Dezenas de milhares

Biblioteca de documentos não estruturada

A biblioteca de documentos não estruturada é geralmente usada por uma equipe ou grupo de trabalho e normalmente possui dezenas de centenas de documentos. Essas bibliotecas podem crescer e se tornarem maiores do que o limite de exibição de lista sem qualquer planejamento, o que afeta as operações como a adição de colunas. Um problema em potencial é que os usuários podem obter exceções do limite de exibição de lista se as exibições crescerem e se tornarem maiores que 5.000 itens. Isto pode ser reduzido monitorando as bibliotecas que estão atingindo o limite de exibição de lista. Um medidor é exibido na página de configurações da biblioteca de uma biblioteca de documentos para indicar que a biblioteca de documentos está atingindo o limite de exibição de lista.

Este cenário geralmente possui dezenas ou até centenas de usuários, mas menos usuários simultâneos. Portanto, o carregamento dentro de uma única biblioteca raramente é um problema. No entanto, existem muitos destes tipos de bibliotecas. Em invés de planejar para suportar instâncias específicas, é mais importante focalizar no suporte da escala dessas bibliotecas.

Grande lista ou biblioteca colaborativa

A grande lista colaborativa abrange de centenas a milhares de itens e é usada como armazenamento para uma grande quantidade de conteúdo ativo. As grandes listas colaborativas incluem soluções de gerenciamento de conhecimento, bibliotecas de engenharia e repositórios colaterais de vendas e marketing. Os usuários adicionam e editam conteúdo ativamente (um grande número de operações de leitura e operações de redação). Você pode colocar estrutura e gerenciamento no local para manter a biblioteca organizada. No entanto, devido a uma grande quantidade de trabalho realizado pelos usuários, podem ocorrer eventos que estão fora do controle dos administradores. Isto pode tornar mais fácil a lista crescer de forma mais rápida do que o esperado ou passar os limites planejados. Esse tipo de repositório pode ter centenas ou milhares de usuários com dezenas ou centenas de usuários simultâneos.

Comparado com um repositório ou arquivo estruturado, uma grande lista colaborativa está mais propensa a mudanças administrativas como a adição ou exclusão de pastas, adição de tipos de conteúdo e colunas ou reorganização de conteúdo. Essas ações podem ser evitadas pelo limite de exibição de lista devido ao tamanho da lista.

Grande repositório estruturado

O grande repositório estruturado varia de milhares a centenas de milhares de itens. O conteúdo é geralmente final e é enviado pelos usuários ou processos do sistema, como os fluxos de trabalho. Os grandes repositórios estruturados são geralmente usados para arquivos de registros de departamento, armazenamento de documentos de alto valor e documentos finais que são exibidos nas páginas da Web. O conteúdo é geralmente estruturado e altamente gerenciado, para que seja mais fácil de controlar o crescimento da lista. Esse cenário pode ter dezenas ou centenas de usuários simultâneos e uma base de milhares de usuários. A porcentagem de leituras é muito maior do que a de redação. No entanto, ainda poderá haver atualizações do conteúdo, e o conteúdo pode ser adicionado e excluído com mais frequência. Um repositório de gerenciamento de conhecimento para uma divisão ou organização é um exemplo de um grande repositório estruturado.

Neste cenário, é importante compreender totalmente as necessidades do usuário e realizar um teste completo antes da solução ser iniciada. Portanto, a solução é totalmente completa e final antes de ser preenchida com uma grande quantidade de conteúdo. Por exemplo, a configuração de hierarquias de navegação de metadados adequados e filtros pode ser necessária para fornecer uma experiência de navegação de conteúdo adequada.

Arquivo em grande escala

Um arquivo em grande escala varia de milhares a milhões de itens, tanto em uma lista única quanto espalhada em várias listas, ou no máximo, em várias coleções de site. Este cenário geralmente possui uma baixa quantidade de leituras e atualizações e é geralmente usado somente para armazenamento a longo prazo para documentos que devem ser retidos para correspondência ou outras razões (por exemplo, os documentos que devem ser retidos por setes anos para cumprir requisitos legais). Alta taxa de transferência do envio e exclusão de documentos é importante neste cenário. A pesquisa é o método principal para recuperar conteúdo.

Grandes listas e o SharePoint Server 2010

Os recursos que ajudaram com grandes listas no Office SharePoint Server 2007 ainda ajudam com o SharePoint Server 2010 e vários deles são melhorados para fornecer melhor desempenho em grande escala. O SharePoint Server 2010 possui vários novos recursos que ajudam a melhorar o desempenho de grandes listas e que permitem os usuários a usar grandes listas com eficácia. Esta seção resumo os recursos novos e aprimorados no SharePoint Server 2010.

Recursos aprimorados

As seguintes seções discutem os recursos do Microsoft Office SharePoint Server 2007 que foram aprimorados no SharePoint Server 2010.

Web Part de Consulta de Conteúdo

Você pode configurar o Web Part de Consulta de Conteúdo para exibir resultados pela filtragem em listas, tipos de conteúdo e colunas. Você pode classificar os resultados e selecionar as colunas que serão exibidas. Fazer isso torna o Web Part de Consulta de Conteúdo ideal para exibição de conteúdo de grandes listas em páginas da Web. O Web Part de Consulta de Conteúdo são geralmente armazenados em cache. Isto permite carregamentos de páginas mais rápidos e menos carregamento do banco de dados. Um uso do Web Part de Consulta de Conteúdo nos cenários de gerenciamento de conhecimento é para usá-lo em páginas de publicação para exibir links de documentos relacionados ao conteúdo da página da Web.

O SharePoint Server 2010 fornece melhorias de desempenho nos seguintes cenários principais:

• Otimizar consultas de lista única para tirar vantagem dos índices com maior eficácia

• Melhorar os algoritmos de atualização e invalidação e as configurações padrões para melhorar a utilização de cache quando os usuários realizam operações de redação

Pesquisar

O SharePoint Server 2010 oferece novas capacidades de pesquisa que incluem uma painel de refinamento do termo de pesquisa e escalabilidade melhorada que possui suporta para a latência de consulta de sub-segundo com 100 milhões de documentos. Há também o Microsoft FAST Search Server 2010 for SharePoint, que pode ser usado para atingir pontos de escala maiores do que a Pesquisa SharePoint Server 2010.

Algumas das novas melhorias de pesquisa que ajudam a localizar conteúdo em grandes listas incluem o suporta para operadores booleanos em consultas de texto livre; melhor suporte ao operador como igual a, menor que e maior que; refinamentos de intervalo; e correspondência de prefixo em palavras-chave e propriedades. Por exemplo, a consulta “share*” encontra resultados que incluem o "SharePoint". A pesquisa também possui sugestões de consulta que fazem recomendações baseadas no que o usuário está digitando em uma consulta. A interface do usuário de pesquisa também é melhorado com paineis para pesquisas relacionadas, melhores apostas, pessoas relacionadas e refinamentos de palavra-chave.

A Pesquisa SharePoint Server 2010 também melhora as capacidades sobre a escala. A Pesquisa SharePoint Server 2010 suporta o escalonamento do índice, rastreamento e servidores de consulta. Outras melhorias incluem índices mais novos, melhor resiliência e maior disponibilidade. O FAST Search Server 2010 for SharePoint inclui todas as capacidades da Pesquisa SharePoint Server 2010 e adiciona escalas para demandas extremas, extração de entidade, classificação de relevância ajustável, melhores apostas visuais, miniaturas e visualizações.

Modelos do site da Central de Documentos e Central de Registros

A Central de Documentos e a Central de Registros são modelos de site do SharePoint Server 2010 que você pode usar para criar repositórios estruturados. O modelo de site da Central de Documentos inclui recursos como o Web Part de Consulta de Conteúdo pré-configurado para devolver resultados relevantes por usuários conectados e uma biblioteca de documento com uma navegação de metadados configurados.

O modelo de site da Central de Registros se parece com o modelo de site da Central de Documentos, mas possui o recurso do organizador de conteúdo habilitado para encaminhar documentos e possui uma biblioteca de registros na qual os itens que são adicionados a ela são registros declarados automaticamente e não podem ser excluídos. O modelo do site da Central de Registros é o modelo de site fora dos padrões que não possui o analisador de documentos habilitado, que preserva a fidelidade do conteúdo enviado. Desabilitar o analisador de documentos afeta o desempenho de determinadas operações, que o torna mais adequado para armazenamento de documentos em grande escala (dezenas de milhões de itens) do que outros modelos de site.

Novos recursos

Esta seção descreve novos recursos no SharePoint Server 2010 que ajudam com o gerenciamento de grandes listas e listas de desempenho.

Organizador de conteúdo

O organizador de conteúdo pode ser usado em qualquer site para encaminhar o conteúdo para uma determinada biblioteca de documentos, pastas ou até outros sites. O organizador de conteúdo pode ser usado para criar pastas automaticamente para o conteúdo baseado em propriedades de metadados. Os usuários podem enviar conteúdo para o organizador de conteúdo de outros sites e não se preocupar sobre onde é armazenado dentro do plano de arquivos. O organizador de conteúdo pode ser usado para balancear o conteúdo em diferentes pastas para manter automaticamente um tamanho máximo de cada pasta. Quando o limite de tamanho especificado é atingido, uma nova subpasta é criada para conter os itens adicionais.

Navegação de metadados

A navegação de metadados é o novo recurso do SharePoint Server 2010 que permite os usuários a filtrar dinamicamente as listas, para que eles possam localizar o que precisam. A navegação de metadados permite os usuários selecionarem opções de filtro e lida o desempenho na pesquisa da forma mais eficaz possível. A navegação de metadados consiste de duas partes. Uma parte é um conjunto de controles de navegação que permite o usuário filtrar uma lista que possui hierarquias de navegação e filtros principais. A segunda parte é um mecanismo para reorganizar e reenvia consultas.

A navegação de metadados possui uma lógica de fallback e nova tentativa para realizar consultas de forma eficaz usando índices. Se uma consulta devolver muitos resultados, a consulta retorna e devolve um subconjunto de resultados para melhor desempenho. Se nenhuma consulta adequada pode ser realizada, o fallback ocorre e os filtros são realizados em um conjunto de resultados limitado. A navegação de metadados cria automaticamente índices. Juntos, a nova tentativa, fallback e gerenciamento de índice tornam a navegação de metadados uma parte muito importante do trabalho efetivo com grandes listas. Existem dois tipos de mecanismos de filtragem: hierarquias de navegação e filtros principais.

As hierarquias de navegação usam um controle em árvore para navegar em hierarquias de pastas, tipos de conteúdo, campos de escolha ou conjuntos de termos de metadados gerenciados. Isto permite os usuários utilizarem um controle de árvore para dinamizar em uma hierarquia de metadados, assim como eles navegam em pastas. Quando os usuários selecionam um item em uma hierarquia para uma coluna de metadados gerenciados, todos os itens que correspondem ao termo especificado ou a qualquer de seus termos filho descendentes são exibidos. Isto é chamado de inclusão descendente e pode ser usado em campos que estão vinculados a um conjunto de termos de metadados gerenciados. Os usuários podem selecionar o item novamente para filtrar apenas aquele determinado termo e não incluir termos filhos descendentes. Todas as consultas de navegação de metadados são recursivas e exibem resultados de todas as pastas na lista.

Os filtros principais podem ser configurados para realizar filtragens adicionais dos resultados dentro da hierarquia. Por exemplo, você pode adicionar a coluna Modificado Por como um filtro principal e digitar um nome de usuário para obter resultados onde Modificado Por corresponde ao usuário inserido. Para obter mais informações, consulte Navegação de metadados e filtragem (https://go.microsoft.com/fwlink/?linkid=219154&clcid=0x416). A figura a seguir exibe um exemplo de hierarquias de navegação de metadados e filtros principais.

Metadados gerenciados

Os metadados gerenciados é um novo conjunto de recursos que adicionam mais informações das capacidades de arquitetura para o SharePoint Server. O recurso de metadados gerenciados inclui um serviço compartilhado chamado serviço de metadados gerenciados. O serviço de metadados gerenciados pode ser usado para armazenar conjuntos de termos que podem ser reutilizados através de uma implementação do SharePoint Server 2010. Alguns dos recursos de metadados gerenciados incluem o seguinte:

• Conjuntos de termos que suportam as hierarquias simples ou profundas

• Tipo de coluna de metadados gerenciados que usa os conjuntos de termos como propriedades disponíveis

• Os conjuntos de termos que podem ser abertos para que qualquer pessoa possa adicionar novos termos ou restritos para que apenas usuários específicos possam gerenciar o conjunto de termos

Ao usar as colunas de metadados gerenciados ou o conjunto de termos para organizar o conteúdo, você pode usar os recursos como o Web Part de Consulta de Conteúdo e navegação metadados para ajudar os usuários a localizarem e descobrirem conteúdo. Os metadados gerenciados também ajuda com consultas de pesquisa regulares, pois adiciona palavras-chave que podem ser usadas para classificar documentos. Os metadados gerenciados podem ser usados no painel de refinamento de pesquisa. A figura a seguir exibe um exemplo de navegação de metadados gerenciados.

Aceleração e limites

O SharePoint Server 2010 introduz vários limites configuráveis para ajudar a manter o desempenho do farm. A nível do aplicativo da Web, existem agora acelerações e limites configuráveis. Eles foram adicionados para que as operações dos usuários individuais ou processos não afetem adversamente o desempenho do farm. Por exemplo, o limite de exibição de lista é um limite que evita que as consultas afetem mais do que um determinado número de itens de lista.

Índices compostos

Os índices são importantes para grandes listas. No SharePoint Server 2010, você pode agora criar índices compostos. Os índices compostos são úteis quando as consultas são geralmente realizadas em duas colunas, pois uma consulta em apenas uma coluna pode não ser seletiva o suficiente. Os índices compostos não são utilizados por exibições. No entanto, eles são utilizados por navegação de metadados. Quando uma condição de aceleração ocorre, a lógica da navegação de metadados pode tentar novamente e usar índices compostos aplicáveis e índices únicos para as condições de filtro escolhidas para localizar resultados completos ou parciais que satisfazem a consulta.

Painel do desenvolvedor

O painel do desenvolvedor exibe informações de diagnóstico detalhadas para cada carregamento de página. Por padrão, o painel está desligado. No entanto, você pode ligá-lo manualmente ou configurar o painel para permanecer ligado durante todo o tempo. Quando o painel do desenvolvedor é ligado, você pode usá-lo para obter informações sobre as consultas do banco de dados, tempos de carregamento e erros. O painel do desenvolvedor torna mais fácil analisar e diagnosticar problemas de desempenho rapidamente. A figura a seguir exibe o painel do desenvolvedor. O recurso de navegação de metadados é visível no painel do desenvolvedor em caso de grandes listas e condições de aceleração onde a lista de índices que é usada para nova tentativa e resultados parciais é exibida na árvore de operação à esquerda e as consultas do SQL Server indexadas diferentemente que tentam aparecer na lista à direita.

O painel do desenvolvedor também é útil para depurar Web Parts personalizadas e consultas. Para obter mais informações sobre como habilitar o painel do desenvolvedor, consulte Blog: Habilitar o Painel do Desenvolvedor usando o Modelo de Objeto/Powershell (https://go.microsoft.com/fwlink/?linkid=219613&clcid=0x416).

Iterador de conteúdo

O API desenvolvedor do iterador de conteúdo simplifica o código de gravação em grandes listas e é especialmente importante com limites de exibição de novas listas. O iterador de conteúdo é um método para recuperar o conteúdo para realizar operações em pequenos conjuntos ao invés de realizar operações em todo conjunto de dados. Isto evita que as operações excedam o limite de exibição de listas.

Armazenamento BLOB remoto

Por padrão, o SharePoint Server 2010 armazena dados do arquivo (Binary Large Object (BLOB)) nos bancos de dados do SQL Server. Uma grande quantidade de banco de dados de conteúdo é geralmente dados BLOB. O Armazenamento BLOB remoto (RBS) permite que estes dados sejam armazenados fora do SQL Server, o que torna possível ter opções de armazenamento mais baratas e reduzir o tamanho do banco de dados de conteúdo. O Armazenamento BLOB Remoto é um conjunto API de biblioteca que é incorporado como um pacote de recursos de complementos para o SQL Server 2008. Um fornecedor de armazenamento BLOB remoto de terceiros é exibido para usar o API de Armazenamento BLOB Remoto.

Medições de desempenho e metodologia de teste

Esta seção inclui uma explicação da metodologia de teste que foi usada para os testes discutidos neste artigo. Os desvios desta metodologia são observados onde os dados são apresentados.

Configuração de hardware e farm

A configuração do farm de teste é especificada nas seguintes figuras e tabela. Dois aspectos da configuração de teste eram significantemente diferentes da maioria das implantações reais. Especificamente:

• A autenticação NTLM foi usada para evitar que o controlador de domínio se torne o afunilamento. Isto resulta em uma pequena melhoria no desempenho.

• O servidor de aplicativos contém uma instância SQL Server que foi usada para o banco de dados de registro. Isto foi realizado para reduzir a carga na instância SQL Server principal porque o nível de registro era muito maior do que as implantações reais.

Nome do computador	Dois servidores da Web	Um servidor do aplicativo	Um servidor do banco de dados
Função	Servidor da Web Front-end	Servidor do aplicativo	Instância do SQL Server
Processador(es)	2px4c com 2,33 GHz	2px4c com 2,33 GHz	4px2c@3.19 GHz
RAM	8 GB	8 GB	32 GB
Sistema operacional	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64	Windows Server 2008 R2 x64
Armazenamento e sua geometria (incluindo a configuração de discos SQL Server)	50 + 18 + 205 GB	50 + 18 + 300 GB	Matriz de disco – 15 discos de 450 GB @ 15 K RPM
Número de NICs	2	2	2
Velocidade NIC	1 gigabit	1 gigabit	1 gigabit
Autenticação	NTLM	NTLM	NTLM
Versão do software	SharePoint Server 2010 (Pré-lançamento)	SharePoint Server 2010 (Pré-lançamento), SQL Server 2008 CTP 3	SQL Server 2008 CTP 3
Número de instâncias do SQL Server	N/A	1	1
Tipo do balanceador de carga	Hardware	N/A	N/A
Configurações do cache de saída
Configurações do cache do objeto
Configurações do cache BLOB
Nível de registro ULS	Médio	Médio	Médio
Uso do local do banco de dados		X
Uso das configurações do banco de dados (que está sendo registrado)
Configurações IRM	Nenhum	Nenhum	Nenhum
Configuração do anti-vírus	Nenhum	Nenhum	Nenhum

Tipo de banco de dados	Número de bancos de dados	Configuração RAID
BD temporário	1	0
BD Configuração	1	0
BD #1 Conteúdo	1	0
BD Perfil	1	0
BD Pesquisa	1	0
BD Taxonomia	1	0

Carregamento de teste

Os testes são conduzidos a um ponto de carregamento optimal, ou zona verde, com uma mistura de operações gerais. Para medir determinadas mudanças, os testes foram conduzidos em cada ponto que uma variável foi alterada. Para encontrar o ponto de carregamento optimal, mais threads foram adicionados para saturar o ambiente enquanto permanecem sob as seguintes métricas:

• Latência de 75° por cento é menor que 1 segundo

• CPU do servidor da Web Front-end é menor que 50 por cento

• CPU do SQL Server é menor que 50 por cento

• CPU do servidor do aplicativo é menor que 50 por cento

• A taxa de falha é menor que 0,01 por cento

Definições de teste

A seguinte tabela define o teste e fornece uma visão geral do processo que foi usado para cada teste.

Nome do teste	Descrição do teste
Carregamento do documento	Carregar um documento. Editar e atualizar as propriedades do documento.
Carregar e Encaminhar Documento	Carregar um documento. Editar e atualizar as propriedades do documento. Encaminhar o documento que corresponde uma regra de encaminhamento.
Download do Documento	Baixar um documento.
Acessar Biblioteca de Documentos	Acessar uma página de exibição de lista da biblioteca de documentos.
Acessar a Página Inicial com o Web Part de Consulta de Conteúdo	Acessar uma página inicial da Central de Documentos que possui três Web Part de Consulta de Conteúdo. O Web Part de Consulta de Conteúdo em Cache devolve 15 documentos com maior classificação. O Web Part de Consulta de Conteúdo em Cache devolve os 15 documentos mais novos. O Web Part de Consulta de Conteúdo não em Cache devolve os 15 itens mais recentes que foram modificados pelo usuário atual.
Consulta Fallback de Metadados Gerenciados	Uma consulta de exibição de lista que devolve mais de 5.000 resultados, filtrados em uma única coluna de metadados gerenciadas por valor.
Consulta Seletiva de Metadados Gerenciados	Uma consulta de exibição de lista que devolve 1.000 resultados, filtrados em uma única coluna de metadados gerenciados por valor.
Consulta Fallback por Tipo de Conteúdo	Uma consulta de exibição de lista que devolve mais de 5.000 resultados, filtrados pelo tipo de conteúdo.
Consulta Seletiva por Tipo de Conteúdo	Uma consulta de exibição de lista que devolve 1.000 resultados, filtrados pelo tipo de conteúdo.

Mistura de teste

A composição de cada mistura de testes variados. Os testes foram conduzidos usando um Sistema de Teste do Visual Studio. Os pontos de dados específicos para cada teste foram preenchidos e a mistura de testes foi realizada por 2 minutos para aquecimento e 10 minutos para a coleta de dados. Os resultados que são apresentados neste artigo são medidos sobre estes 10 minutos. A tabela a seguir exibe a porcentagem de cada solução em uma mistura de teste.

Nome da solução	Porcentagem na mistura
Carregamento do Documento (incluindo as propriedades do documento de edição)	20
Download do Documento	20
Acessar Biblioteca de Documentos	20
Acessar Página Inicial com o Web Parts de Consulta de Conteúdo	10
Consulta Fallback de Metadados Gerenciados (mais de 5.000 resultados)	5
Consulta Seletiva de Metadados Gerenciados (100 resultados)	10
Consulta Fallback de Tipo de Conteúdo (mais de 5.000 resultados)	5
Consulta Seletiva de Tipo de Conteúdo (100 resultados)	10

Aceleração e limites

Os limites evitam que as operações afetem adversamente o desempenho do farm. Estes padrões foram testados e cuidadosamente escolhidos. Para alguns limites, como o limite de exibição de lista, nós recomendamos não alterar o valor. Considere cuidadosamente o efeito da alteração destes limites. Se estes limites evitam que uma operação seja realizada, considere primeiro alterar a operação para ser executada em uma forma indexada mais eficientemente do que alterar o limite para acomodar mal as operações de desempenho. A maioria das acelerações e limites que estão cobertos nesta seção podem ser configurados na Administração Central em Gerenciar Aplicativos da Web e selecionando Configurações Gerais – Aceleração do Recurso na faixa de opções para um determinado aplicativo da Web.

Limite da exibição de lista

O SharePoint Server 2010 suporta bibliotecas de documentos e listas que possuem dezenas de milhões de itens. Você pode criar bibliotecas de documentos muito grandes usando pastas, exibições padrões, hierarquias de sites e navegação de metadados. Para recuperar dados de grandes listas usando as exibições de lista ou as consultas CAML (Collaborative Application Markup Language), os dados devem ser particionados usando pastas, índices ou ambos. Caso contrário, a pesquisa é o único mecanismo que pode ser usado para acessar os dados de forma eficaz. O número de itens que uma única biblioteca de documentos pode suportar varia dependendo de como os documentos e pastas são organizados, o tamanho e tipo de documentos armazenados, o uso da biblioteca de documentos e o número de colunas na biblioteca de documentos.

Por padrão, o limite de exibição de lista evita operações que irão envolver mais de 5.000 itens, como consultas que irão devolver mais de 5.000 itens ou adicionar uma coluna para uma lista que contém mais de 5.000 itens. Embora este seja um padrão configurável, recomendamos que você o mantenha. Se consultas com desempenho ruim são usadas em listas com mais de 5.000 itens, a taxa de transferência geral pode diminuir significantemente quando você aumentar este limite.

Algumas operações, como as consultas não indexadas ou a adição de uma coluna em uma lista, levam tempo e usam recursos que são proporcionais ao número de itens na lista. Em uma pequena lista, isto não importa porque existem tão poucos itens que a operação é rápida. Conforme o tamanho da lista aumenta, estas operações levam mais tempo e usam mais recursos. Ao invés de permitir que estas operações sejam realizadas sem vínculo, o limite de exibição de lista as bloqueiam. Você pode pensar no limite de exibição de lista como uma proteção na estrada que aviso que você deve mudar a consulta e como os dados são acessados ou você deve realizar a operação quando o uso do farm é baixo.

O limite de exibição de lista é o número máximo dos itens da lista ou biblioteca que uma operação do banco de dados, como uma consulta, pode envolver em um momento. Por padrão, é definido para 5.000 itens. Este limite tem um maior efeito em grandes listas porque, pela definição deste limite, uma grande lista é uma lista que possui mais itens do que seu limite. As operações que excedem este limite são aceleradas. Operações, como a criação de um índice em uma lista que está acima deste limite, são evitados porque a operação afeta mais de 5.000 itens. Este limite evita que as consultas tenham uma seletividade (itens que podem ser filtrados com eficiência usando o critério de filtro) de mais de 5.000 itens. Este limite também evita que as consultas filtrem colunas que não estão indexadas. Isto ocorre porque uma consulta que filtra (e em alguns casos classifica) em uma coluna que não está indexada deve realizar a filtragem em todos os itens na lista para recuperar o conjunto de dados correto e irá operar em mais itens do que o limite de exibição de lista. O valor padrão para este limite é baseado no farm e no desempenho da lista e em como o SQL Server gerencia os bloqueios. Recomendamos que este limite não seja alterado.

Para minimizar a contenção do banco de dados, o SQL Server usa um bloqueio a nível de linha como uma estratégia para garantir atualizações precisas sem afetar adversamente os usuários que estão acessando outras linhas. No entanto, se uma operação do banco de dados de leitura ou gravação, como uma consulta, faz com que mais de 5.000 linhas sejam bloqueadas ao mesmo tempo, é mais eficaz para o SQL Server escalar o bloqueio para toda a tabela até que a operação do banco de dados esteja completa. Quando esta escalação de bloqueio ocorre, evita que outros usuários acessem a tabela. Para obter mais informações sobre os bloqueios, consulte Escalonamento de Bloqueios (Motor do Banco de Dados) (https://go.microsoft.com/fwlink/?linkid=219156&clcid=0x416).

O seguinte gráfico exibe a taxa de transferência de uma mistura de consultas em uma grande lista conforme o limite de exibição de lista é ajustado. Esta mistura de consultas contém consultas que devolvem todos os itens na lista, portanto, quando o limite de exibição de lista é aumentado, mais itens são devolvidos. Até alterar o limite do padrão de 5.000 para 10.000 possui um efeito significante no desempenho. Ao invés de aumentar ou diminuir o limite de exibição de lista para melhorar o desempenho, recomendamos que você não mude o limite de exibição de lista padrão e focalize em certificar-se de que as consultas são realizadas corretamente.

As exceções do limite de exibição de lista ocorrem devido a operações realizadas incorretamente. As operações devem ser reconfiguradas. Ao invés de aumentar o limite, você deve considerar porque as operações ineficientes estão sendo realizadas e deve corrigi-las. Em um cenário ruim, você pode mudar temporariamente a configuração Habilitar Aceleração para falso em uma determinada lista para ignorar o limite de exibição de lista. Isto pode ser feito apenas no nível da lista e não para um site. Isto deve ser realizado para permitir o acesso da lista somente até que as mudanças possam ser realizadas para corrigir operações realizadas incorretamente que estão bloqueadas pelo limite de exibição de lista. A configuração Habilitar Aceleração deve ser alterada de volta para verdadeiro assim que possível.

Administradores de farm e administradores do computador local no servidor da Web front-end, onde a consulta se origina, não estão bloqueados pelo limite de exibição de lista. Estes usuários devem navegar cuidadosamente em grandes listas que não estão configuradas corretamente e eles também devem ser cuidadosos ao realizar o teste. Pode parecer que as coisas não funcionem conforme esperado, mas os dados que são devolvidos aos usuários podem ser muito diferente. Para obter uma lista de operações que são evitadas pelo limite de exibição de lista, consulte Operações bloqueadas pelo limite de exibição de lista posteriormente neste artigo.

Da mesma forma, os serviços de timer podem ser executados usando uma conta que não está protegida pelo limite de exibição de lista. Embora isto permita determinados cenários, como a criação adiada de um índice em uma grande lista, geralmente você deve ser especialmente cuidadoso para garantir que o seu código evite a realização de operações de grandes listas.

Limite de exibição de lista

Padrão: 5.000	Existente em 2007: Não	Configurável: Sim
Localização da configuração: Administração Central, por aplicativo da Web

Limite de exibição de lista para auditores e administradores

Padrão: 20.000	Existente em 2007: Não	Configurável: Sim
Localização da configuração: Administração Central, por aplicativo da Web

O limite de exibição de lista para auditores e administradores é o limite de exibição de lista usado para determinadas contas de serviço, como a conta de consulta de pesquisa ou as contas de super gravação ou super leitura em cache do objeto. Por exemplo, o Web Part de Consulta de Conteúdo usa automaticamente este limite para armazenar em cache os resultados de uma grande consulta, salvando assim os recursos do servidor. Você pode usar o código personalizado para solicitar o uso deste limite mais alto se estiver executando como uma conta que é uma política de segurança de super leitura ou super gravação por aplicativo da Web.

Permitir substituição do modelo do objeto

Padrão: Sim	Existente em 2007: Não	Configurável: Sim
Localização configurável: Administração Central, por aplicativo da Web

Permitir a substituição do modelo do objeto especifica se as contas de serviço podem usar o limite de exibição de lista para auditores e administradores. Um administrador farm deve habilitar a substituição do modelo do objeto e especificar programaticamente que uma lista é uma exceção. Os programadores com a permissão adequada pode solicitar programaticamente que sua consulta ou lista use o tamanho de limite de exibição de lista maior para os auditores e administradores tirarem vantagem dela. Alterar este valor para não, o código personalizado que é executado por auditores ou administradores, mesmo se é solicitado uma substituição, estará sujeito ao limite de exibição de lista ao invés do limite maior para auditores e administradores. Recomendamos deixar esta configuração com o valor padrão e configurar apenas o limite de exibição de lista para auditores e administradores se for necessária.

Janela de hora diária

Padrão: Desligado	Existente em 2007: Não	Configurável: Sim
Localização da configuração: Administração Central, por aplicativo Web

Uma janela de hora diária pode ser definida para que as operações possam ser realizadas sem estarem sujeitas ao limite de exibição de lista. A hora pode ser ajustadas em aumentos de 15 minutos, até 24 horas. Uma operação de banco de dados ou consulta iniciada dentro da janela de hora diária continua até a conclusão, mesmo se não acabar dentro da janela de hora especificada. Por padrão, a janela de hora diária não é configurada porque as horas de pico variam muito entre as implantações. Portanto, é decisão do administrador. Recomendamos que uma janela de hora diária seja especificada apenas se houver um quadro de horas razoável onde algumas pessoas estão usando o aplicativo da Web. Isto permite os usuários realizarem operações administrativas para grandes listas, como a criação de um índice, durante os quadros de tempo quando um uso de farm é muito menor.

Permissões únicas

Conforme o número de permissões únicas em uma lista aumenta, o desempenho diminui. Você deve reconsiderar qualquer criação na qual todo ou a maioria do conteúdo em uma grande lista deve ser assegurado com segurança. A diferença da taxa de transferência para operações em uma lista entre 0 e 1.000 permissões únicas está em cerca de 20 por cento. Existe um padrão configurável de 50.000 permissões únicas por lista. No entanto, recomendamos que você considere diminuir este limite para 5.000 permissões únicas e para grandes listas, considere usar uma criação que usa o mínimo de permissões únicas possíveis. Isto ajudará não apenas o desempenho, mas também a gerenciabilidade.

Nós recomendamos o seguinte:

• Minimizar o uso de permissões únicas em itens individuais e simplificar as criações de listas que exigem que a maioria dos itens possuam permissões únicas.

• Se permissões únicas são necessárias, tente defini-las apenas ao nível de lista ou pasta e minimizar o número de itens individuais que precisam de permissões únicas.

• Reconsidere sua criação se cada item exige permissões individuais. Investigue dividir os itens entre várias listas ou organizá-los em pastas e grupos para que o acesso adequado seja garantido sem colocar as permissões únicas em cada item.

Definir permissões refinadas pode afetar o desempenho e também é difícil gerenciar se está definida de forma diferente em vários itens individuais. No entanto, definir permissões refinadas também afeta o desempenho em outras formas. Portanto, há um limite configurável que, por padrão, é 50.000 permissões únicas por lista. Se você tentar declarar permissões únicas após este limite ser atingido, você será bloqueado. Diferente do limite de exibição de lista, este limite se aplica quando criar permissões únicas para um item ao invés de uma consulta por vez.

Sempre que a herança de permissão estiver quebrada para um item, como uma pasta, é contada como uma permissão única em direção a este limite. Cada vez que as heranças de permissões estão quebradas, uma nova ID de objetivo é criada. Cada vez que você consultar uma exibição, você participa da tabela de escopos. Quando uma consulta é realizada, cada lista de controle de acesso (ACL) deve ser analisada e processada. Um grande número de permissões únicas em uma lista irá afetar adversamente o desempenho e não é recomendado. Conforme o número de permissões únicas em uma lista cresce, o desempenho da consulta irá diminuir. Se o limite padrão é de 50.000 permissões únicas, você pode considerar diminuir este limite para 5.000 permissões únicas.

Permissões únicas

Padrão: 50.000	Existente em 2007: Não	Configurável: Sim
Localização da configuração: Administração Central, por aplicativo da Web

Disposição da linha

Quando colunas são adicionadas a uma lista, elas são mapeadas para colunas em uma tabela do banco de dados do SQL Server. Cada linha na tabela do banco de dados suporta um número fixo de cada um dos vários tipos de colunas diferentes. Por exemplo, uma única linha da tabela do banco de dados suporta oito colunas de data e hora e doze colunas de número. Se houverem mais de oito colunas de data e hora, cada item da lista irá usar duas linhas da tabela do banco de dados.

Para pequenas listas, o efeito de desempenho desta disposição da linha é desprezível. No entanto, para uma grande lista isto pode ter um grande efeito. Você pode ir até o limite de qualquer número de colunas antes da disposição de linha ocorrer, mas somente um tipo de coluna deve passar o limite para a disposição de linha ocorrer.

A tabela a seguir exibe o número de colunas por tipos de dados específicos antes da disposição de linha ocorrer.

Tipo de coluna	Número de colunas por linha da tabela
Linha única de texto Ou Escolha e várias linhas de texto	64 32
Data e hora	8
Sim ou não	16
Número e moeda	12
Calculado	8
Número inteiro, pesquisa de valor único, pessoas e grupos, metadados gerenciados	16
Identificador único	1

A disposição de linha causa uma diminuição na taxa de transferência de aproximadamente 35 por cento por linha adicional para a maioria das operações. Para verificar quantas linhas uma lista está usando, você deve analisar o esquema de lista e examinar os tipos de coluna para os campos na lista.

O gráfico a seguir exibe o desempenho de consultas somente leitura como o número das linhas do banco de dados do SQL Server que são usados para um aumento de lista para acomodar mais colunas de metadados gerenciados. Para ir para a segunda linha, 15 colunas de metadados gerenciados foram adicionadas a lista e para ir para a terceira linha, 31 colunas de metadados gerenciados foram adicionadas a esta lista. O teste foi conduzido usando somente consultas que filtraram itens na lista. para cada linha adicional a taxa de transferência diminui 35 por cento.

Limite de tamanho da linha

Padrão: 6	Existente em 2007: Não	Configurável: Sim
Localização da configuração: Somente modelo do objeto, SPWebApplication.MaxListItemRowStorage

O limite do tamanho da linha especifica o número máximo de linhas na tabela que são internas ao banco de dados que é usado par cada item em uma lista. Para acomodar listas amplas que possuem várias colunas, cada item é dispostos em várias linhas da tabela interna, até seis linhas. Por exemplo, se você possui uma lista que tem várias colunas pequenas, uma que contém centenas de colunas Sim/Não, você pode atingir este limite. Neste caso, você não poderá adicionar mais colunas Sim/Não na lista. No entanto, você pode adicionar colunas de outros tipos. Como cada linha adiciona uma sobrecarga, para uma lista maior você deve minimizar o número de colunas do mesmo tipo para evitar a disposição de linhas.

Colunas de pesquisa e exibições de lista

Cada coluna de pesquisa em uma exibição de lista causa uma junção com outra tabela. Cada coluna de pesquisa adicional em uma exibição aumenta a complexidade da navegação de metadados e as consultas da exibição de lista. Além das colunas de pesquisa padrão, as colunas de metadados gerenciados de valor único, metadados gerenciados de valor múltiplo, pessoas e grupo de valor único, pessoas e grupo de valor múltiplo contam como colunas de pesquisa. Adicionar colunas de pesquisa para uma exibição não causa uma diminuição gradual ou linear no desempenho, o desempenho torna-se um pouco estável até oito colunas quando diminui rapidamente.

O seguinte gráfico exibe a mudança na taxa de transferência como o número de colunas de pesquisa em um aumento de exibição. Como você pode ver, a mudança no desempenho de zero para oito é estável, mas em 10 colunas de pesquisa, a taxa de transferência diminui muito. Este teste foi realizado com a lista usando apenas uma linha. Se uma lista está em disposição de linha, o desempenho diminui mais rapidamente.

O seguinte gráfico exibe a utilização de CPU do SQL Server como o número de colunas de pesquisa em um aumento de exibição. Como você pode ver, há uma mudança significante em 10 colunas de pesquisa. Para uma lista que possui um grande número de consultas, com exibições que contêm mais de oito colunas de pesquisa faz com que as consultas usem desproporcionalmente uma grande quantidade de recursos do SQL Server. Recomendamos que você não altere este limite para mais de oito.

Embora esta diminuição no desempenho não seja para o número total de colunas de pesquisa em uma lista, apenas para o número de colunas de pesquisa em uma exibição ou consulta, o SharePoint Workspace não pode sincronizar qualquer lista que possua mais de oito colunas de pesquisa. Isto é independente das colunas serem usadas em uma exibição ou não.

Limite de pesquisa da exibição de lista

Padrão: 8	Existente em 2007: Não	Configurável: Sim
Localização configurável: Administração Central, por aplicativo da Web

Outros limites

Esta seção descreve os limites que não estão cobertos em outro lugar neste artigo.

Índices por lista

Padrão: 20

Existente em 2007: Sim, o limite era 10

Configurável: Não

A tabela anterior exibe o limite dos índices que podem ser criados por lista, incluindo índices compostos e índices que são criados pelo SharePoint Server 2010. Este limite não é configurável.

Exibição da folha de dados e exportar para o Excel

Padrão: 50.000

Existente em 2007: Não

Configurável: Não

A tabela anterior exibe o número máximo de itens que podem ser usados com a exportação para o Microsoft Excel e a exibição da folha de dados. No entanto, a exibição da folha de dados será bloqueada pelo limite de exibição de lista. Portanto, se o seu limite de exibição de lista é de 5.000 itens e você possui entre 5.000 e 50.000 itens em uma exibição de lista, quando você tentar usar uma exibição de folha de dados, você irá obter uma mensagem de exceção da exibição de lista mesmo se o limite de exibição da folha de dados é maior.

SharePoint Workspace

Padrão: 30.000 itens por lista

Existente em 2007: Não

Configurável: Não

O Microsoft SharePoint Workspace possui um limite não configurável que bloqueia a sincronização de uma lista que possui mais de 30.000 itens por lista. Se uma lista contém 30.000 itens, os usuários não podem sincronizar a lista usando o SharePoint Workspace e os itens não podem ser sincronizados por seleção.

Diferenças entre grandes listas e listas regulares

Quando uma lista excede o limite de exibição de lista, algumas operações que podem ter funcionado anteriormente são bloqueadas. A maior preocupação é a exibição de lista padrão, pois este é o que os usuários usam frequentemente para acessar uma lista. As exibições de lista devem ser configuradas para funcionar corretamente para uma grande lista. Por exemplo, um erro ocorre quando você acessa uma lista se a raiz da lista contém mais itens do que o limite de exibição de lista. Se o recurso de navegação de metadados está habilitado, um subconjunto de resultados é exibido ao invés de um erro.

O limite de exibição de lista bloqueia qualquer operação do banco de dados que afeta mais itens do que o limite de exibição de lista; o limite não bloqueia o número de itens devolvidos ou modificados. Por exemplo, se você possui um filtro em uma coluna não indexada que devolve 100 resultados e a lista contém 10.000 itens, a consulta falha pois pode realizar uma pesquisa de todos os 10.000 itens. Se você adiciona um índice para aquela coluna, a operação é limitada a apenas 100 itens e tem sucesso.

Operações em grandes listas podem ser classificadas nos seguintes dois grupos:

• A lista excede o limite de exibição de lista   Algumas operações são evitadas quando o tamanho de toda a lista excede o limite de exibição de lista, mesmo se os itens estão divididos em pastas. Estas operações incluem consultas recursivas, como gerenciar versões marcadas, que operam em todos os itens independente de qual pasta eles estejam. As exibições que devolvem todos os itens sem pastas também são evitadas. Além disso, as operações que afetam toda a lista, como adicionar uma coluna e criar ou excluir índices, são bloqueadas.

• O recipiente excede o limite de exibição de lista   Algumas operações são evitadas porque uma pasta ou a raiz da lista contém mais itens do que o limite de exibição de lista. Por exemplo, se uma lista contém 10.000 itens e uma pasta contém 3.000 itens, você pode renomear ou excluir a pasta. No entanto, se a pasta contém 6.000 itens (excedendo o limite de exibição de lista) você não pode excluir a pasta porque a operação excede o limite de exibição de lista.

Quando uma lista excede o limite de exibição de lista, você deve planejar a configuração correta das exibições e outras opções de navegação. Idealmente, você deve configurar as exibições e outras opções de navegação com antecipação, mas muitas vezes a lista pode crescer além do limite de exibição de lista e exige ação. Algumas operações, como a criação de uma coluna ou a indexação de uma coluna em uma lista que possui muitos itens, irão levar mais tempo. Estas operações são evitadas pelo limite de exibição de lista. No entanto, elas podem ser realizadas durante a janela de tempo diário ou pelos administradores do farm ou computador. Você deve planejar estas operações antes de realizá-las. Se a lista já está muito grande, planeje usar uma janela de tempo diária ou credenciais administrativas para realizar estas operações.

Uma lista pode se tornar tão grande que algumas operações podem exceder o tempo quando estão sendo executadas usando um navegador da Web. Por exemplo, se uma lista contém milhões de documentos, pode levar muito tempo para adicionar uma nova coluna. Para fazer isso, você precisará usar o Windows PowerShell e certificar-se de que está fazendo isto durante as horas fora de pico, pois irá bloquear as operações de outros usuários.

Operações bloqueadas pelo limite de exibição de lista

As seguintes tabelas listam as operações que são bloqueadas pelo limite de exibição de lista.

Operações bloqueadas quando a lista excede o limite de exibição de lista

Operação	Descrição
Adicionar/remover/atualizar uma coluna de lista	Todas as colunas, incluindo pesquisa e colunas calculadas, além de vários tipos de atualizações, como uma alteração de tipo ou uma alteração de singularidade. Algumas atualizações, como a alteração do nome, não são bloqueadas porque elas não afetam todos os itens na lista.
Adicionar/remover/atualizar um tipo de conteúdo de lista	Afeta todos os itens na lista para que seja bloqueado para qualquer lista que possui mais itens do que o limite de exibição de lista.
Criar/remover um índice	Afeta cada item na lista para que seja bloqueado em qualquer lista que possua mais itens do que o limite de exibição de lista.
Gerenciar arquivos que não possuem uma versão marcada	Uma consulta recursiva não indexada que falha para qualquer lista que possui mais itens do que o limite de exibição de lista.
Consultas recursivas não indexadas	Inclui filtros e algumas classificações. Esta operação falha quando o tamanho da lista é maior do que o limite de exibição de lista. Como não há índice, realiza uma pesquisa completa em toda a lista. Além disso, retorna todos os itens e ignora as pastas.
Consulta de lista cruzada	Inclui consultas pelo Web Part de Consulta de Conteúdo e segue a configuração de limite de exibição de lista para auditores e administradores, que por padrão é 20.000 itens. Se a operação envolve mais de 20.000 itens, a consulta falha.
Pesquisar colunas que impõe o comportamento da relação	Você não pode criar colunas de pesquisa que impõe o comportamento da relação quando uma lista que é referenciada contém mais itens do que o limite de exibição de lista.
Excluindo uma lista	Afeta cada item na lista na lista, para que seja bloqueado para qualquer lista que possua mais itens do que o limite de exibição de lista.
Excluindo um site	Se a soma de todos os itens em um site é maior do que o limite de exibição de lista, excluir o site é evitado pois afeta muitos itens.
Salvar a lista como um modelo com dados	Afeta cada item na lista, para que seja bloqueado em qualquer lista que possua mais itens do que o limite de exibição de lista.
Exibindo totais nas exibições de lista	Realiza uma consulta em cada item na lista, para que seja bloqueado em qualquer lista que possua mais itens do que o limite de exibição de lista.
Habilitar/desabilitar os anexos em uma lista	Afeta cada item em uma lista, para que seja bloqueado em qualquer lista que possua mais itens do que o limite de exibição de lista.

Operações bloqueadas onde o recipiente excede o limite de exibição de lista

Operação	Descrição
Excluir/copiar/renomear uma pasta	Falha quando a pasta contém mais itens do que o limite de exibição de lista, pois afeta muitas linhas.
Consultas que filtram colunas não indexadas	Falha quando o recipiente (pasta ou lista) contém mais itens do que o limite de exibição de lista. A operação realiza uma pesquisa completa em toda a pasta porque não há índice.
Definir permissões de segurança refinadas	Falha quando uma lista ou pasta na qual você está tentando definir permissões refinadas contém mais itens do que o limite de exibição de lista, pois afeta muitas linhas. Você ainda pode definir permissões refinadas em itens filhos, como documentos, em uma grande lista, embora não possa definir permissões na própria lista ou em pastas que contêm mais itens do que o limite de exibição de lista.
Abrir com Explorer	Não exibe qualquer item se um recipiente possui mais itens do que o limite de exibição de lista (excluindo itens nas subpastas). Se uma pasta possui 8.000 itens, mas possui uma subpasta com 4.000 itens e somente 4.000 itens na raiz, o Abrir com Explorar irá funcionar. Se a raiz de uma lista contém mais itens do que o limite de exibição de lista. o Abrir com Explorar não exibirá nada. Para usar o Abrir com Explorar, a lista deve ter itens organizados em pastas com quantidades menores do que o limite de exibição de lista na raiz de qualquer recipiente.

Recursos disponíveis que podem não funcionar conforme o esperado

Este seção contém informações sobre os recursos que podem não funcionar como esperado com relação a grandes listas.

Exibição da folha de dados

O botão de exibição da folha de dados que está disponível na guia da faixa de opções da biblioteca de uma biblioteca de documentos não está desativado se a lista cresce acima do limite de exibição de lista. No entanto, se o tamanho da lista excede o limite de exibição de lista, a exibição carrega alguns itens, mas exibe uma mensagem que declara "Você não tem permissão para exibir toda a lista, pois é maior do que o limite de exibição de lista inserido pelo administrador". Você pode desativar a opção de exibição de folha de dados na faixa de opções de configuração da lista. Existe também um limite rígido de 50.000 itens, portanto, esta exibição é bloqueada mesmo se o limite de exibição de lista estiver acima de 50.000 itens.

Planejamento para design e implementação de grandes listas

Antes de você implementar uma grande lista, considere o caso administrativo e requisitos. Os requisitos como o acordo de nível de serviço (SLA), tempo para backup e restauração, tamanho do conteúdo, quantidade de conteúdo (número de itens) e tempos de acesso são importantes para serem considerados. Dependendo do tamanho e da demanda do aplicativo, você deve fazer escolhas importantes em vários níveis, incluindo hardware, armazenamento de conteúdo e arquitetura de informação do SharePoint Server 2010. Um aplicativo grande que possui milhões de itens e centenas de usuários simultâneos podem exigir um hardware autônomo para um projeto específico, embora um repositório de documento com dezenas de usuários simultâneos e dezenas de milhares de documentos podem funcionar bem com um hardware compartilhado existente e uma única biblioteca de documentos em um site existente.

O resultado final do planejamento deve ser uma lista de tipos de coluna (nomes, tipos de dado e uso), índices, estrutura de pastas, uso das páginas e links para navegação, estrutura planejada de permissões, número estimado de itens e tamanho total dos dados. Os detalhes também devem incluir informações sobre os tipos de consultas que serão realizadas e como os dados da lista serão acessados, criados e atualizados.

Após planejar o design e a implementação de uma grande lista, a próxima etapa é projetar e criar um protótipo. Este estágio do planejamento é sobre a criação de uma grande lista, implementando uma prova de conceito e validando que irá funcionar. Neste ponto, pode ser útil preencher um ambiente de teste com uma grande quantidade de conteúdo para validar previsões sobre o acesso dos dados e desempenho. O resultado final do processo de criação deve ser uma prova do conceito da lista destinada, documentação das colunas, tipos de conteúdo, estrutura da pasta, exibições, índices, colunas usadas para navegação de metadados ou outros métodos de recuperação, qualquer taxonomia usada, uso de várias Web Parts e uso de qualquer outro recurso como o organizador de conteúdo.

Estimando o tamanho do conteúdo

Para grandes listas, é importante estimar vários números para realizar um planejamento de capacidade e decisões de design. Existem alguns números importantes que você deve planejar, que incluem:

• Tamanho do banco de dados de conteúdo total

• Tamanhos de arquivo médio e máximo

• Número de versões

• Quantidade de conteúdo – número total de itens em uma lista

Tamanho do banco de dados de conteúdo

O tamanho do banco de dados de conteúdo total é importante para planejar a necessidade de espaço de disco e hardware, além de descobrir a capacidade de suporte para backup, restaurar e um acordo de nível de serviço. O tamanho do banco de dados de conteúdo geral é o mais importante para descobrir a quantidade de tempo de inatividade que é necessário para fazer o backup e restaurar.

O tamanho do banco de dados de conteúdo pode ser estimado calculando o tamanho do documento médio multiplicado pelo número médio de versões por documento multiplicado pelo número esperado de documentos. Adicionar mais 20 por cento para os dados do banco de dados de conteúdo além dos arquivos. Este número é alto porque as versões geralmente aumentam de tamanho com o tempo, portanto, o tamanho do arquivo médio dos documentos marcados é geralmente um número maior do que o tamanho médio do arquivo de todas as versões. Você deve adicionar um armazenamento significante em caso de que a lista cresça além do que você previu, a não ser que você possua mecanismos para controlar com eficácia a quantidade de conteúdo.

Tamanho médio e máximo do arquivo

O tamanho máximo do arquivo é necessário para garantir que a configuração do aplicativo da Web correto seja especificado para os arquivos que podem ser carregados (por padrão 50 MB, o máximo pode ser 2 GB). O tamanho médio do arquivo é usado para ajudar a compreender a taxa na qual o conteúdo pode crescer e para estimar o tamanho total do conteúdo. O tamanho médio do arquivo pode ser estimado avaliando os arquivos nos sistemas que preenchem atualmente a função dos sistemas destinados.

Número médio de versões

Você deve considerar o controle de versão pois pode aumentar muito o tamanho do conteúdo. Existem métodos nos quais você pode limitar as versões. Por exemplo, você pode usar as políticas de retenção do gerenciamento de informações para excluir todas as versões anteriores após uma quantidade de tempo específica ou pode limitar o número de versões a serem salvas. Outros fatores também afetam as versões, por exemplo, se o seu repositório possui todo o conteúdo enviado para ele usando um organizador de conteúdo, pode haver nenhuma versão porque o organizador de conteúdo copia apenas a versão marcada mais atual. Se os documentos em seu repositório são editados ativamente pelos usuários, você pode precisar considerar a co-autoria; cada sessão de co-autoria cria uma versão automaticamente. Considere o uso do repositório e avalie as soluções existentes para estimar o número médio de versões que serão criadas para um documento.

Quantidade de conteúdo

A quantidade de conteúdo é o número total de itens em uma única lista. Para estimar a quantidade de conteúdo, você deve avaliar as fontes existentes de conteúdo e que serão movidas para o novo sistema ou examinar como vários usuários irão usar o sistema e qual o objetivo do sistema. Existem alguns números relacionados, incluindo itens por recipiente e itens por pivô de metadados ou filtro de índice. Estes números também são importantes quando você planeja exibições e navegação de metadados.

Armazenamento BLOB remoto

Listas que possuem grandes requisitos de armazenamento podem iniciar uma decisão fundamental sobre como armazenar os documentos. Por padrão, o SharePoint Server 2010 armazena todos os documentos como BLOBs no banco de dados do SQL Server. O SharePoint Server 2010 e o SQL Server 2008 fornece um API de Armazenamento BLOB Remoto, que permite que os documentos sejam armazenados fora do banco de dados do SQL Server, que reduz o tamanho do banco de dados. A decisão de usar o Armazenamento BLOB Remoto é amplamente decidido pela economia de custo.

O teste atual pela Microsoft mostrou que o Armazenamento BLOB Remoto causa uma diminuição de 5 a 10 por cento na taxa de transferência, nenhuma diferença perceptível na latência. No entanto, o desempenho pode ser diferente dependendo do fornecedor de Armazenamento BLOB Remoto que é usado. Usando o Armazenamento BLOB Remoto, o tamanho do banco de dados de conteúdo é reduzido. No entanto, isto não significa necessariamente que você pode armazenar mais itens em um banco de dados de conteúdo. O desempenho é afetado pela quantidade de itens na lista do banco de dados do SQL Server; mesmo se os BLOBs são removidos, o tamanho da lista não muda. Existem alguns cenários onde o custo benefício pode compensar facilmente as preocupações de desempenho:

• Arquivo, dados não colaborativos

• Armazenamento de BLOBs muito grandes como vídeos e imagens que são atualizadas frequentemente

Usar o Armazenamento BLOB Remoto pode adicionar mais servidores e tecnologias em seu farm e exige a adição de um fornecedor do Armazenador BLOB Remoto. O fornecedor do Armazenador BLOB Remoto pode suportar o armazenamento de BLOBs em um armazenamento mais barato do que o banco de dados do SQL Server. O SQL Server Enterprise é exigido para usar o API de Armazenamento do BLOB Remoto.

O ponto de ultrapassagem onde o Armazenamento BLOB Remoto se torna econômico pode estar no intervalo de terabytes de dados. Você não precisa usar o Armazenamento BLOB Remoto somente porque você possui bancos de dados de conteúdo com tamanhos de terabytes. Você precisará pensar cuidadosamente sobre o backup e a restauração de dados e o acordo a nível de serviço. O Armazenamento BLOB Remoto torna a recuperação de desastres mais difíceis, pois exige que as duas tecnologias estejam sincronizadas. A principal preocupação é o momento que é necessário restaurar o sistema após um desastre e para lidar com o backup e a recuperação de BLOBs. Para obter mais informações, consulte Overview of RBS (SharePoint Server 2010).

Arquitetura de lista

Selecionar a arquitetura adequada para um projeto de grande lista é importante, pois as decisões podem ser difíceis de alterar após terem sido implementadas. Planeje com antecedência e considere o tamanho e quantidade de conteúdo, o uso do repositório, como o conteúdo será adicionado e atualizado e como o conteúdo será acessado. Todas estas coisas podem afetar com o conteúdo é organizado (em uma lista, várias listas ou em vários locais de coleta), qual metadado é usado e como o conteúdo é recuperado. Todas estas decisões são especialmente importantes para uma grande lista, pois com uma quantidade grande de conteúdo é muito mais difícil recriar como um sistema é usado.

Lista única, várias listas ou coleção de vários sites

Quando você cria uma solução de grande lista, é importante considerar se a arquitetura de lista única é adequada. A decisão de colocar o conteúdo em uma única lista deve ser baseada nos requisitos de negócios, como a facilidade de uso para trabalhar e descobrir conteúdo. Em muitos cases, pode ser mais adequado usar várias listas. Criar uma implementação de sucesso com ótima usabilidade de experiência do usuário com as capacidades do SharePoint Server 2010 e recursos disponíveis deve ser sua maior prioridade.

Use uma única lista para tornar fácil os usuário encontrarem e trabalharem no conteúdo, para que eles não precisem decidir onde colocar seu conteúdo ou quais listas eles devem acessar para localizar o que estão procurando. No entanto, conforme a quantidade de conteúdo aumenta, também pode ser mais difícil localizar conteúdo, especialmente usando métodos com as exibições de filtragem ou pastas de navegação. Quando uma lista começa a atingir as centenas de milhares e itens, usar a navegação de metadados pode se tornar difícil. As consultas podem devolver centenas ou milhares de resultados, pois elas não são específicas o suficiente.

Por exemplo, se houver 5.000 termos no domínio de um índice e cada termo possui uma quantidade igual de itens que correspondem ao filtro, a filtragem de um termo irá resultar em 20 resultados com uma lista de 100.000 itens e 200 resultados com uma lista de 1.000.000 de itens. Se o tamanho da lista é muito grande, vários filtros que os usuários selecionarem não devolverão um conjunto de resultado razoável para localizar o que estão procurando. Se um projeto possui vários tipos de conteúdo separados distintamente que os usuários irão geralmente poder diferenças, você deve considerar usar listas múltiplas.

Em pontos de grande escala, como cenário de arquivos em grande escala, pode valer a pena considerar uma arquitetura de coleta de vários locais. O novo recurso do SharePoint Server 2010 permite que as coletas de site sejam agrupadas para carregar documentos de balanço. O recurso de organizador de conteúdo é usado para rotear documentos entre várias coletas de site. A pesquisa deve ser usada para recuperar os documentos. Isto funciona para o armazenamento a longo prazo, pois permite que o conteúdo seja balanceado entre várias coletas de site e escalas para suportar muitos documentos do que uma única lista.

Resumo das recomendações da lista

• Use listas únicas para grandes números de itens quando:

  • Não é lógico colocar itens em listas separadas.

  • Irá fornecer a melhor experiência do usuário.

• Use várias listas para grandes quantidades de itens quando:

  • É lógico agrupar itens em várias listas.

  • Irá fornecer a melhorar experiência do usuário.

  • Não será confuso entre os usuários sobre qual lista usar para adicionar ou localizar conteúdo.

• Usar uma arquitetura de coleta de vários site quando:

  • O repositório exige mais de dezenas de milhões de itens suportados em um único repositório.

  • É lógico agrupar itens em várias coletas de site, por exemplo para particionar dados por ano.

Metadados

Com o SharePoint Server 2010, os tipos de metadados e conteúdo são úteis para criar arquitetura de informação. Novos recursos, como metadados gerenciados, conjuntos de termos e navegação de metadados, tornam os metadados muito úteis e importantes para recuperar conteúdo. Como as operações, como a modificação dos tipos de conteúdo e colunas, são bloqueadas em grandes listas, é especialmente importante planejar com antecedência os requisitos dos metadados. Se você planeja usar a navegação de metadados ou algum outro método de recuperação do conteúdo por metadados, é importante planejar os tipos de conteúdo e as colunas que terão durante a fase de criação.

Na maioria dos cenários de grandes listas, o metadado não é apenas útil, mas também uma exigência para os usuários usarem o sistema. Existem três formas principais que os metadados podem ser aplicados: processos de sistemas embutidos, configurações personalizadas e código e aplicação manual pelos usuários. Para usar as colunas para recuperar conteúdo, a maioria dos itens deve possuir um valor especificado por coluna. Isto torna importante planejar quais colunas serão usadas para navegação e como o metadado será preenchido. A única forma de garantir que o metadado correto é aplicado, é usar os processos embutidos e personalizações. Por exemplo, como cada item possui um tipo de conteúdo, se os tipos de conteúdos são usados para classificar documentos, cada item terá seu metadado, que torna fácil filtrar com base no tipo de conteúdo.

Tipos de conteúdo

categorização mais básica do conteúdo deve ser com tipos de conteúdo. Se você possui metadados para classificar o conteúdo, como tipo de documento ou item, você deve considerar usar esta classificação para os seus tipos de conteúdo. Os tipos de conteúdo permitem definir as colunas que são associadas com um tipo de conteúdo, além de ser associada com fluxos de trabalho e o modelo. Somente um modelo pode ser associado com um tipo de conteúdo e é este modelo que você usa quando criar uma nova instância do tipo de conteúdo usando o menu Novo Documento em uma biblioteca de documentos.

Você pode usar modelos para formatos de arquivo no Microsoft Word, Microsoft PowerPoint e Excel, além de outros produtos. Quando os usuários criam novas instâncias do tipo de conteúdo, o aplicativo do cliente particular é usado para começar a permissão para usar o modelo. Quando o conteúdo é carregado, os usuários podem selecionar dos tipos de conteúdo disponíveis. Os tipos de conteúdo devem ser distintos, específicos e ter um número pequeno o suficiente de tipos de conteúdo por lista, que os usuários não tenham dificuldade para selecionar qual tipo de conteúdo usar.

Como os tipos de conteúdo controlam os metadados que os usuários devem preencher quando criam ou carregam um item, considere as colunas que são necessárias para cumprir os requisitos administrativos e também minimizar a barreira para enviar conteúdo. Escolher um bom conjunto de tipos de conteúdo para classificar o conteúdo ao nível primário ajuda automaticamente com a navegação. Como cada item possui um tipo de conteúdo, há um pivô para filtrar que funcionará para todos os itens

Resumo das recomendações de tipo de conteúdo

• Use tipos de conteúdo como o método mais básico para organizar conteúdo.

• Use os tipos de conteúdo para selecionar as colunas específicas que são necessárias para aquele tipo de conteúdo.

• Os tipos de conteúdo por lista devem ser um pequeno número (não mais que 10) e deve ser distinto o suficiente para que os usuários compreendam facilmente qual tipo de conteúdo devem usar.

• Os tipos de conteúdo fornecem uma coluna embutida para a qual cada item terá um valor que pode ser usado para filtragem e navegação de metadados.

Exemplo de uma grande lista de colaboração e tipos de conteúdo: biblioteca de especificações do produto

Uma biblioteca de especificação do produto é usada pelas equipes de desenvolvimento do produto para armazenar especificações de design, planos de teste e outros itens de desenvolvimento do produto. Neste exemplo, os seguintes seis tipos de conteúdo são usados. Todos os tipos de conteúdo possuem colunas para data inicial do projeto, data final do projeto, orçamento, membros da equipe de design, nome do produto e tipo do produto.

• Especificação do produto – Um arquivo do Word que contém os detalhes do design de um produto. Metadados adicionais incluem o designer e a data de revisão final.

• Especificação de teste – Um arquivo do Word que contém o plano de teste para um produto. Metadados adicionais incluem o testador e o status de conclusão do teste.

• Plano de desenvolvimento – Um arquivo do Word que contém um plano para o desenvolvimento do produto.

• Storyboard – Uma apresentação do PowerPoint que é usada para apresentar as maquetes do design.

• Análise de custo – Uma planilha do Excel que analisa o custo para desenvolver o produto e as potenciais oportunidades de mercado.

• Prazo – Uma planilha do Excel que contém detalhes sobre a programação para o desenvolvimento do produto.

Neste exemplo, os usuários podem filtrar com base no tipo de conteúdo para encontrar uma especificação do produto ou um storyboard do produto. Os modelos personalizados também ajudam a estruturar o trabalho do usuário. O número de colunas e tipos de conteúdo são pequenos o suficiente que os usuários podem selecionar facilmente as opções adequadas para seu trabalho, mas preenchendo os metadados torna mais fácil filtrar e localizar conteúdo.

Colunas

Número de colunas e colunas exigidas

Você pode usar colunas para especificar o tipo de metadados que um item possui e pode marcá-los como ocultos, opcional ou necessário. Use colunas ocultas para tarefas automáticas, como fluxos de trabalho, para que os usuários não possam editá-las. Use colunas exigidas somente quando for absolutamente necessário. Por exemplo, uma propriedade de metadados pode ser necessária para rotear um item para um local adequado ou para navegação. Nestes casos, você não deseja que os usuários deixem o valor vazio. Quanto menos itens os metadados preencherem para uma coluna que é usada como um filtro de navegação, menos útil a navegação é, pois vários itens nunca serão devolvidos por uma consulta.

Conforme o número de colunas de metadados aumenta, torna-se menos provável que os usuários preenchem os metadados devido ao trabalho adicional de descobrir quais colunas aplicar e especificar um valor. Se você usar um grande número de colunas exigidas, a adoção do usuário pode ser difícil porque leva muito tempo para carregar conteúdo. Em um cenário muito aberto e colaborativo, isto pode ser detrimental. Mas o valor do conteúdo e esforço para criar o conteúdo aumenta, tornando-se mais provável que os usuários levem tempo para preencher os campos adequados, especialmente quando esta operação não é frequente.

Durante a fase de criação, você deve considerar quais metadados são necessários para realizar operações exigidas e para recuperar conteúdo, estimar quanto tempo os usuários levarão para preencher os metadados e estimar o efeito nos usuários. Se os usuários não adotam o sistema porque a sobrecarga de criação do conteúdo é muito alta, pode ser difícil reestruturar o sistema posteriormente.

Tipos de campo e únicos contra campos de valor múltiplo

Uma consideração na escolha das colunas é o tipo de coluna e se deve haver valores múltiplos. Consultas em campos de metadados gerenciados são mais eficazes do que consultas em colunas de escolha, portanto, você deve considerar usar os campos de metadados gerenciados ao invés dos campos de escolha. As colunas, como os metadados gerenciados e as pessoas ou grupos, podem suportar vários valores. As consultas em várias colunas de valor não são tão eficazes quanto as consultas em colunas de um valor.

Colunas e tipos de conteúdo são geralmente os componentes centrais para classificar e recuperar conteúdo em uma grande lista. Uma lista de colunas e tipos de conteúdo já deve ter sido preparada no processo de planejamento. O número de colunas e tipos de conteúdo que foram adicionados a uma lista podem afetar o desempenho de forma sutil. O número de colunas de um tipo específico que foi adicionada em uma lista única irá causar a disposição da linha. Para obter mais informações, consulte Disposição de linha neste artigo.

Exemplo de uma grande lista colaborativa e colunas: biblioteca de especificação de produto

Esta seção descreve as colunas que são usadas nestes exemplos, como a seguir:

• As colunas mantidas automaticamente pelo SharePoint Server 2010: ID, Tipo de Conteúdo, Modificado, Criado, Modificado Por, Criado Por, ID do Documento

• Colunas mantidas por personalização:

  • Valores padrões de metadados por pasta para Tipo de Produto e Equipe do Produto (cada Tipo de Produto possui uma pasta e cada pasta Tipo de Produto possui várias pastas Equipe do Produto)

  • Atualização do fluxo de trabalho: Status da Aprovação, Projeto Concluído

• Colunas mantidas pelos usuários: Designer, Testador, Data da Revisão Final

• Colunas que funcionam bem para navegação: Tipo de Conteúdo, Tipo de Produto, Equipe do Produto

• Colunas que são usadas para rastrear status e também funciona bem para navegação: Data de revisão final, status da aprovação, projeto concluído

• Colunas que podem ser úteis para navegação: Designer, Testador, Nome do Produto, Modificado, Modificado Por

Resumo das recomendações da coluna

• Minimizar o número de colunas que estão disponíveis para preencher.

• Selecione cuidadosamente as colunas que serão usadas para processos do sistema e navegação. Considere quais campos serão exibidos e minimizar o número de campos exigidos.

• Campos exigidos devem ser usados quando eles são necessários para navegação, como o uso do Web Part de Consulta de Conteúdo em um determinado campo. Eles também devem ser usados para administração, como a especificação de ações de retenção em um campo de data que os usuários devem especificar.

• Como as consultas em colunas de valor único são mais rápidas do que em colunas de valores múltiplos, tente realizar colunas de valor único a não ser que valores múltiplos sejam necessários.

O número total de colunas particulares em uma lista pode causar a disposição da linha, que reduz o desempenho. Minimize o número de colunas em uma grande lista e evite a disposição de linha, se for possível.

Pastas

Você deve considerar cuidadosamente como organizar o conteúdo nas pastas. Existem três formas principais que você pode usar pastas:

• Organizar conteúdo em pastas logicamente. Por exemplo, organizar contratos em pastas baseados no ano ou mês que o contrato foi assinado ou faturas baseadas na data que a fatura foi criada. Neste cenário, os usuários podem navegar facilmente através da estrutura de pasta ou usar metadados para localizar documentos. Além disso, é fácil encaminhar automaticamente os documentos para a pasta correta. O organizador de conteúdo fornece capacidades que podem ser usadas para limitar a quantidade de itens em uma única pasta, criando subpastas quando os itens são adicionados acima de um determinado limite.

• Organize o conteúdo em pastas para retenção e permissões ou outras funções administrativas. Por exemplo, uma pasta para documentos confidenciais que poucos usuários tem acesso ou retenção baseada no local para documentos que possuem uma programação de retenção diferente baseada na pasta. Neste cenário, a navegação do usuário pode ser mais difícil pois os usuários podem não se importar onde um documento está, enquanto eles tiverem acesso a ele. A navegação de metadados e pesquisa são os métodos dominantes para localizar documentos, ao invés de usar a estrutura de pasta.

• Organizar o conteúdo em pastas para auxiliar a navegação do usuário por tópicos ou categorias. Muitos usuários estão acostumados a navegar com pastas. Para determinados aplicativos, pode ser importante reter uma estrutura de pasta que seja fácil para os usuários navegarem. Neste cenário, os usuários geralmente compreendem a estrutura de pasta e sabem onde procurar e colocar documentos. A navegação de metadados e pesquisa pode ser usado em combinação com este método.

Melhorias no SharePoint Server 2010 fornece mais flexibilidade para usar pastas e menos dependência nas considerações de desempenho. Usando os metadados gerenciados e a navegação de metadados, os usuários podem filtrar facilmente os metadados, ao invés de navegar pelas pastas. Isto permite você organizar o conteúdo para fins administrativos como permissões ou política, ao invés de somente para navegação do usuário. Por exemplo, você pode ter uma pasta de material privado que somente determinados funcionários podem acessar e outra pasta que todos os funcionários podem acessar. Você pode especificar diferentes permissões nas pastas e usar o organizador de conteúdo para mover automaticamente o conteúdo para a pasta adequada, baseado nos metadados. Você ainda pode escolher usar pastas para navegação em combinação com a navegação de metadados.

Com o recurso do organizador de conteúdo, o conteúdo pode ser movido automaticamente para pastas baseado nos tipos de conteúdo e metadados sem os usuários precisarem decidir onde o conteúdo deve ser colocado. Além disso, o organizador de conteúdo pode ser usado para criar automaticamente novas pastas quando uma pasta atingir um limite de itens especificado. Você deve considerar que usar o Abrir com Explorer (WebDAV) não funcionária em grandes listas se os itens não estão organizados em pastas onde não há mais itens do que o limite de exibição de pasta na raiz de qualquer pasta.

As exibições baseadas em pasta e exibições baseadas em metadados são muito parecidas em desempenho. De um ponto de vista lógico e da experiência do usuário, é sensível usar pastas para dividir conteúdo. A navegação de metadados realiza consultas recursivas para que todos os itens sejam devolvidos fora das pastas. Se este é o método principal para recuperar conteúdo, a estrutura da pasta pode não ser importante.

O gráfico a seguir mostra os resultados de um teste que foi conduzido pela utilização de exibições de vários tipos para acessar o mesmo número de itens. Todas as exibições devolveram 1.000 resultados. Este gráfico exibe as solicitações por segundo para estas exibições individualmente, conforme o tamanho da lista aumenta. Os resultados exibem que conforme o tamanho da lista aumenta, o desempenho da pasta e exibições indexadas permanecem relativamente planas, embora as pastas tenham um melhor desempenho em tamanhos de lista menores. Para a maioria das grandes listas, uma combinação de pastas e exibições indexadas são usadas, portanto, diferentes desempenhos não devem ditar se deve usar pastas ou índices para recuperar dados.

Resumo das recomendações de pasta

• Planeje como os itens serão organizados em pastas. Os itens podem ser movidos automaticamente ou manualmente.

• Os recursos como a navegação de metadados torna menos necessário limitar a quantidade de itens nas pastas.

• Use a navegação de metadados em combinação com a navegação de pasta. Portanto, as pastas podem ser usadas para gerenciar a política e retenção ao invés de apenas serem usadas para organizar conteúdo para recuperação.

• Quando fornece a melhor experiência do usuário, considere organizar o conteúdo em pastas para auxiliar a navegação, mesmo em combinação com outras opções de navegação.

• Quando usar o organizador de conteúdo para mover automaticamente os documentos em pastas baseadas em metadados, considere habilitar a opção para criar itens adicionais em subpastas quando um limite específico é atingido.

• Você deve organizar itens nas pastas sem que os itens superem o limite de exibição de lista na raiz de qualquer pasta em particular, se você planeja usar o Abrir para Explorer (WebDAV).

• Para recuperar o conteúdo nas exibições de lista, você deve usar a navegação de metadados e índices se ainda não usa pastas.

Exemplo de uma grande lista colaborativa e pastas: biblioteca de especificação do produto

Na biblioteca de especificação do produto, as pastas são usadas para auxiliar a navegação e para colocar logicamente o conteúdo. Está claro para os usuários qual pasta que eles devem usar para criar uma nova especificação do produto. Existe uma pasta para cada tipo de produto e cada tipo de produto possui várias pastas para cada equipe do produto. Isto cria uma estrutura que parece com a seguinte:

• Downhill Skis – Tipo de produto (Pasta)

  • Racing Skis – Equipe do Produto (Pasta)

    Super Faster Downhill Racer X – Produto (Conjunto de Documentos)

Você pode configurar metadados padrões para cada uma das pastas e é fácil para os usuários da biblioteca localizarem conteúdo usando pastas.

Exemplo de arquivo em grande escala e patas: Central de Registro

O site da Central re Registro é usado para armazenamento a longo prazo de itens que devem ser mantidos para cumprimento legal, mas o conteúdo não pode ser mais modificado ativamente. Neste cenário, os itens são encaminhados automaticamente para duas pastas: restritas e confidenciais. A pasta restrita possui permissões restritas que um pequeno número de pessoas tem acesso e os documentos devem ser mantidos por 10 anos. A pasta confidencial permite maior acesso do que a pasta restrita e os documentos devem ser mantidos por 7 anos. Isto ajuda a diminuir o número de permissões únicas e torna mais fácil gerenciar permissões porque os itens recebem suas permissões da pasta adequada. Todos os itens vão para o site da Central de Registro são encaminhados da raiz, de pastas confidenciais ou restritas baseadas em metadados.

Índices

Há um limite não configurável de 20 índices que podem ser criados por lista, incluindo índices compostos e recursos do SharePoint Server 2010 que classificam colunas por padrão. Adicionar índices para uma lista possui um efeito mínimo no desempenho. No entanto, afeta algumas operações como a adição e atualização. Você deve evitar usar mais índices do que o necessário porque índices não utilizados irão causar um pequeno efeito de desempenho negativo e alguns recursos do SharePoint Server 2010 adicionam índices quando estão habilitados. Por exemplo, o SharePoint Server 2010 exige pelo menos três entradas de índice se você usa os recursos de experiência e eDiscovery. Considere manter pelo menos três entradas de índice disponíveis em caso de precisar criar novos índices posteriormente.

O SharePoint Server 2010 usa seu próprio mecanismo de índice para trabalhar com sua estrutura da tabela do banco de dados. Crie índices no SharePoint Server modificando as configurações desta lista.

Quando planejar índices, considere o seguinte:

• Os índices são necessários para realizar a filtragem das listas acima do limite de exibição de lista.

• Planeje cuidadosamente cada índice simples e composto para criar, pois existe um limite de 20 índices.

• Reserve entradas de índice para os recursos do SharePoint Server 2010 que podem precisar criar colunas como eDiscovery e Retenção da Política de Gerenciamento de Informação.

• Crie índices únicos quando usar um campo único para filtrar com o Web Part de Consulta de Conteúdo, exibições com filtros e quando você estiver usando as hierarquias de navegação de metadados e filtros que são usados com frequência como filtro único.

• Crie índices compostos para consultas que filtram usando duas colunas e devolvem geralmente mais itens do que o limite de exibição de lista individualmente, mas são seletivos juntos.

• Os índices podem afetar negativamente o desempenho de algumas operações, como a adição de um documento ou edição de suas propriedades. Portanto, crie apenas índices quando necessário.

Planeje índices cuidadosamente

As listas possuem um limite rígido de 20 índices e as colunas indexadas são muito importante para grandes listas. Portanto, você deve selecionar os índices únicos e compostos cuidadosamente. Vários recursos usam índices. Por exemplo,o recurso de navegação de metadados indexa automaticamente hierarquias de navegação configuradas e filtros principais. Você deve criar índices em colunas que são importantes para filtragem na navegação e na arquitetura da informação.

Índices criados automaticamente

Os recursos do SharePoint Server podem criar índices que contam contra um limite de índice de lista. A tabela a seguir fornece uma lista de recursos do SharePoint Server 2010 que são comuns em bibliotecas de documentos que adicionam colunas indexadas.

Coluna	Recurso	Uso
Manter & Status do Registro	Gerenciamento de Registros No Local ou Manter & eDiscovery	Esta coluna é adicionada e indexada quando o recurso de coleta de site Gerenciamento de Registros No Local ou o recurso Manter & eDiscovery está habilitado e um item é declarado um Registro ou colocado em espera em uma lista.
Data de Expiração, Tipo de Conteúdo	Política de Gerenciamento de Informação	Estas duas colunas são adicionadas e indexadas quando a retenção está habilitada para a Política de Gerenciamento de Informação em um tipo de conteúdo que é adicionado a lista ou quando uma retenção baseada em local está habilitada em uma lista.

Quando criar índices únicos e compostos

O recurso de navegação de metadados cria automaticamente índices adequados para a hierarquia e as colunas de filtro principais que são selecionadas na página de configurações de navegação de metadados. Os índices únicos são criados para todos os campos da árvore de hierarquia e para alguns dos tipos de filtro principais mais seletivos para que os resultados indexados e resultados parciais possam ser devolvidos quando são usados sozinhos. Índices compostos são criados para todas as combinações suportadas de hierarquias e filtros principias para maximizar a seletividade quando o valor do filtro de árvore e o filtro principal está sendo usado.

Para uma lista onde você pode ter várias colunas que deseja filtrar, você pode precisar gerenciar índices manualmente para evitar atingir o limite do índice. Se combinações particulares das hierarquias de navegação e filtros principais nunca serão usados, considere não criar índices compostos para diminuir o número de índices. Quando você cria estes índices, é importante escolher a indexação única em colunas que são seletivas e podem ser usadas sozinhas na exibição de lista, como o único filtro ou o primeiro filtro que é aplicado antes de escolher outro. Os índices compostos devem ser usados quando dois filtros geralmente são usados com conjunto na navegação de metadados ou consultas personalizadas e quando um índice não é muito seletivo por si só. Crie índices para colunas que são usadas para filtragem com exibições de lista, Web Part e outros métodos de acesso de dados.

Pode haver casos nos quais vários índices não são úteis. Considere uma situação onde você está filtrando em duas colunas, Divisão e Tipo de Conteúdo. Como esta é uma operação E, somente a interseção onde os filtros para Divisão e Tipo de Conteúdo correspondem são devolvidos. Isto significa que quando a consulta é realizada, todos os itens que correspondem ao filtro Divisão são devolvidos primeiros e em seguida estes limites são filtrados pelo Tipo de Conteúdo. Se houverem apenas 10 itens correspondendo uma determinada divisão, você terá um conjunto de dados pequeno o suficiente que um índice no Tipo de Conteúdo não irá importar. Se houverem milhares de itens para corresponder o valor da Divisão, um índice composto deve ser usado.

Índices compostos permitem criar um índice em duas colunas que permite consultas mais eficazes. Os índices compostos devem ser usados ao realizar uma operação E em duas colunas. A navegação de metadados é o único recurso do SharePoint Server externo que usa índices compostos. Quando o recurso de navegação de metadados está habilitado, as lógicas nova tentativa e fallback são usadas mesmo se os controles de navegação de metadados não são configurados para a lista. Os índices compostos não devem ser usados por exibições a não ser que seja uma consulta de navegação de metadados.

Efeito de desempenho do índice

Os índices são obrigados a realizarem consultas em listas que possuem mais itens do que o limite de exibição de lista em um único recipiente e eles podem fornecer uma melhoria de desempenho significante. Embora os índices sejam obrigados a realizar consultas eficazes em grandes listas e podem melhorar muito o desempenho da consulta, eles podem afetar adversamente outras operações porque o índice deve ser mantido. Quando os itens são criados, atualizados e excluídos, qualquer índice que o item participa também deve ser atualizado. O teste foi conduzido com as operações carregar, atualizar e excluir em uma lista que possui 10.000 itens e os resultados exibidos que o efeito entre os índices zero e 20 foi menor que 10 por cento.

Criação de índice

Por padrão, o recurso de navegação de metadados cria automaticamente índices únicos e compostos. Na página de configurações da navegação de metadados, você pode desativar esta opção. O recurso de navegação de metadados cria automaticamente um índice único para cada tipo de coluna suportada e índices compostos para cada combinação suportada de hierarquias de navegação e filtros principais. Os índices compostos não são criados automaticamente para combinações de dois filtros principais, embora você possa criá-los manualmente. A navegação de metadados cria automaticamente índices únicos e compostos para a maioria dos tipos de colunas que suportam índices. Índices únicos não são criados automaticamente para tipos de filtros principais que possuem menos valores e podem não ser seletivos sozinhos. Isto inclui Sim/Não, escolha de valor único ou colunas de tipo de conteúdo, mas os índices são suportados e podem ser criados manualmente.

Colunas suportadas para índices únicos

A tabela a seguir fornece informações sobre os índices que são criados automaticamente pela navegação de metadados. A navegação de metadados cria índices de valor única para todas as colunas que suportam a criação do índice.

Tipo de coluna	Índice criado
Hierarquias de navegação
Metadados gerenciados de valor único	Sim
Metadados gerenciados de valor múltiplo	Não (sistema indexado como valor múltiplo)
ID do Tipo de Conteúdo	Sim
Escolha de valor único	Sim
Pasta	Não (sistema indexado por pasta)
Filtros principais
Metadados gerenciados de valor único	Sim
Metadados gerenciados de valor múltiplo	Não (sistema indexado como valor múltiplo)
ID do Tipo de Conteúdo	Não (pode ser criado manualmente)
Escolha de valor único	Não (pode ser criado manualmente)
Escolha de valor múltiplo	Não (não suportado como índice)
Número	Sim
Data	Sim
Sim/Não	Não (pode ser criado manualmente)
Moeda	Sim
Usuário (valor único)	Sim
Usuário (valor múltiplo)*	Não (sistema indexado como valor múltiplo)
Todas as marcações	Não (sistema indexado como valor múltiplo. Filtro especial em todos os valores de metadados gerenciados no item)

Índices compostos que são criados automaticamente

Com o recurso de navegação de metadados, os usuários podem selecionar uma hierarquia de navegação e um filtro principal juntos. O recurso de navegação de metadados cria automaticamente índices compostos para todas as combinações suportadas das hierarquias de navegação e filtros principais. A tabela a seguir exibe as combinações que são suportadas.

Hierarquias de navegação	Metadados gerenciados de valor único	Metadados gerenciados de valor múltiplo	ID do Tipo de Conteúdo	Escolha única	Pasta
Filtros principais
Metadados gerenciados de valor único	Sim	Não	Sim	Não	Não
Metadados gerenciados de valor múltiplo	Não	Não	Não	Não	Não
ID do Tipo de Conteúdo	Sim	Não	Não	Não	Não
Escolha de valor único	Não	Não	Não	Não	Não
Escolha de valor múltiplo	Não	Não	Não	Não	Não
Número	Sim	Não	Sim	Não	Não
Data	Sim	Não	Sim	Não	Não
Usuário (único)	Sim	Não	Sim	Não	Não
Todas as marcações	Não	Não	Não	Não	Não
Sim/Não	Sim	Não	Sim	Não	Não
Moeda	Sim	Não	Sim	Não	Não
Usuário (valor múltiplo)	Não	Não	Não	Não	Não

Seletividade de metadados

A seletividade de metadados aumenta em importância conforme o tamanho da lista aumenta. As recomendações a seguir ainda se aplicam a qualquer tamanho de lista. No entanto, elas podem não ser tão importantes para listas menores.

Seletividade é a quantidade de itens que devem ser considerados para devolver resultados para uma consulta. Existem dois aspectos para isso: seletividade atual (o número total de resultados que correspondem uma condição de pesquisa da consulta) e seletividade de aceleração (o número de resultados que precisam ser considerados após aplicar as condições utilizadas para colunas indexadas). A seletividade atual é a primeira consideração quando você considerar a experiência do usuário. A aceleração é a primeira consideração quando você está considerando o efeito para a instância do SQL Server.

Para usar com eficácia a navegação de metadados e outros mecanismos de filtragem de lista, o metadado que é usado para filtrar deve ser seletivo. Por padrão, as exibições de lista mostram 30 itens para que os usuários possam pesquisar os resultados rapidamente para encontrar o que estão procurando. Se as consultas devolvem mais de 30 resultados, os usuários devem usar a paginação para localizar os resultados. Se você está usando um Web Part de Consulta de Conteúdo, 10 a 15 é um número comum de resultados. Se existem mais resultados do que estes, os resultados adicionais não são exibidos. Quando você possui centenas de resultados para uma consulta, torna-se difícil localizar o que você está procurando. A seletividade também é importante para evitar operações que excedem o limite de exibição de lista, que, no caso da navegação de metadados, resulta em fallback e nem todos os resultados são devolvidos.

Organizador de conteúdo e balanceamento automático

O organizador de conteúdo pode ser um componente central para a organização de conteúdo em um repositório de documentos. Os repositórios que usam o organizador de conteúdo possuem uma experiência de envio onde os usuários podem carregar um documento nele quando estiver em um estado final. Alguns exemplos de cenários que o organizador de conteúdo pode ser usado para incluir o seguinte:

• Rotear automaticamente documentos baseado nos metadados entre sites e dentro dos sites.

• O roteamento de documentos e a criação de novas pastas automaticamente, como patas baseadas em dia, mês e ano.

• Balancear automaticamente o número de itens nas pastas.

Acesso de dados e recuperação

O objetivo principal para a maioria das grandes listas é armazenar conteúdo para que possa ser recuperado. É importante planejar como os usuários irão recuperar o conteúdo porque possui um efeito maior no desempenho de uma grande lista e no sucesso da implementação da grande lista. Vários recursos incluindo pesquisa, navegação de metadados, Web Parts de Consulta de Conteúdo e exibições podem ser usados para ajudar os usuários a recuperarem conteúdo. As soluções personalizadas, como o Web Parts personalizados que consultam dados, também são geralmente usados. Planeje com antecipação para como o site da Web será organizado. Você pode usar uma página inicial central, como a página inicial do site da Central de Documentos, para acumular conteúdo e fornecer pontos de entrada na grande lista. Você também pode usar páginas de publicação para criar um site da Web onde vários tópicos são cobertos em cada página e o Web Parts é usado para obter documentos ou itens relacionados da grande lista. As considerações para acesso de dados e recuperação incluem o seguinte:

• Qualquer combinação de pesquisa, Web Parts de Consulta de Conteúdo, navegação de metadados, exibições de lista e Web Parts personalizados podem ser usada.

• Planeje com antecedência como o conteúdo será recuperado e quais colunas serão usadas para filtrar e classificar.

• Planeje o modelo básico da página. Considere se todo o trabalho é realizado na biblioteca de documento, se há uma página inicial ou um modelo de várias páginas que é vinculado ao conteúdo relacionado.

Métodos de acesso de dados

Existem três recursos do SharePoint Server 2010 principais que podem ser usados para consultar e filtrar dados da lista com configuração simples: exibição de lista e navegação de metadados, Web Part de Consulta de Conteúdo e pesquisa. Existem opções adicionais para usar o código personalizado para consultar uma lista; estas opções não são descritas neste artigo.

• As exibições permitem você configurar as colunas que são exibidas. Existe uma variedade de métodos de exibição para os dados da lista. As exibições podem ser configuradas para filtrar e classificar resultados baseados nas colunas.

  • A navegação de metadados é um controle de filtragem para as exibições de lista do SharePoint Server 2010. Quando a navegação de metadados é configurada, você pode selecionar hierarquias de metadados e filtros principais para filtrar dinamicamente os resultados que são mostrados em uma exibição de lista.

• O Web Part de Consulta de Conteúdo exibe dados das listas do SharePoint Server 2010. As consultas podem ser configuradas para devolver resultados de uma ou várias listas. Por padrão, o Web Part de Consulta de Conteúdo é armazenado em cache. No entanto, pode não ser armazenado em cache.

• As caixas de pesquisa ou Web Parts de Resultados da Pesquisa podem ser usados para devolver os resultados da pesquisa. Você pode diminuir estes resultados para uma determinada lista e realizar uma pesquisa guiada usando os controles de refinamento de metadados da pesquisa.

A tabela a seguir lista os métodos de consulta e como eles são usados.

Método de consulta	Uso
Exibição de lista & Navegação de metadados	A exibição de lista sempre acessa o banco de dados back-end do SQL Server, que resulta nas consultas com maior impacto de desempenho e causa uma maior carga de SQL Server. Use estas exibições de lista para fornecer mais opções para interagir com documentos (propriedades de check-in, check-out, edição) e acesso em tempo real aos dados.
Web Part de Consulta de Conteúdo	O Web Part de Consulta de Conteúdo usa o provedor do mapa do site para armazenar em cache consultas e renderizam a menor quantidade de HTML, que resulta em uma consulta e tempos de renderização mais rápidos. Use o Web Part de Consulta de Conteúdo para navegação dinâmica e para realizar várias consultas em uma única página.
Web Part de Consulta de Conteúdo Não Armazenado em Cache	Para fornecer acesso em tempo real aos dados, o Web Part de Consulta de Conteúdo pode consultar diretamente o banco de dados. Use esta configuração quando a consulta não pode ser armazenada em cache, quando as atualizações em tempo real são necessárias e para páginas que são acessadas menos de uma vez por hora, pois o cache nunca será preenchido. O carregamento inicial de um Web Part de Consulta de Conteúdo armazenado em cache possui uma sobrecarga adicional.
Pesquisa	Use as consultas de pesquisa para descarregar leituras de uma infraestrutura do servidor que é mais fácil de dimensionar e que é otimizada para o desempenho de leitura. As consultas de pesquisa podem ser configuradas para usar consultas estáticas ou pode permitir os usuários especificar consultas de pesquisa.

Web Part de Consulta de Conteúdo

A tabela a seguir exibe vários prós e contras de usar o Web Part de Consulta de Conteúdo.

Prós	Contras
Ótimo como um componente de navegação, por exemplo um link para documentos relacionados ou páginas. Configuração simples para exibir diferentes colunas. Vários Web Parts de Consulta de Conteúdo podem ser usados facilmente em uma página. Tempo de renderização mais rápido comparado para as exibições de lista e pesquisa. Armazenado em cache por padrão, reduzindo a carga do SQL Server.	Apenas um número limitado de propriedades pode ser exibido. Os links para ir diretamente apenas aos itens como documento, página ou o próprio item da lista. Você não pode realizar ações da lista.

O Web Part de Consulta de Conteúdo é usado para recuperar conteúdo das listas. Pode ser usado para páginas, documentos e itens da lista. Por padrão, o Web Part de Consulta de Conteúdo é armazenado em cache, que fornece melhor desempenho e menor efeito nos recursos do SQL Server. A configuração do cache padrão é de 30 minutos. Portanto, os dados permanecem atuais. No entanto, isto também significa que o Web Part de Consulta de Conteúdo usa mais recursos do SQL Server do que as consultas de pesquisa. Como o Web Part de Consulta de Conteúdo renderiza a menor quantidade de HTML, eles são mais rápidos na renderização de página e vários Web Part de Consulta de Conteúdo podem ser configurados em uma única página. O Web Part de Consulta de Conteúdo Armazenado em Cache fornece um rápido acesso de dados conforme o tamanho da lista aumenta. O Web Part de Consulta de Conteúdo Não Armazenado em Cache possui uma latência que é quase a mesma que a consulta de exibição de lista similar.

O Web Part de Consulta de Conteúdo deve ser usado como um componente de navegação e para fornecer acumulações de conteúdo nas páginas. Por exemplo, você pode usar páginas para fornecer visões gerais do conteúdo que está localizado em uma biblioteca de documentos e usar o Web Part de Consulta de Conteúdo para devolver as páginas e documentos relacionados. Alguns outros exemplos incluem os itens modificados pelo usuário atual, itens mais novos e itens classificados mais altos. O Web Part de Consulta de Conteúdo pode ser usado em cenários de alta leitura onde a maioria dos usuários não precisa realizar ações na lista como check-in, check-out ou gerenciar versões. A figura a seguir é um Web Part de Consulta de Conteúdo que exibe os documentos classificados mais alto.

O Web Part de Consulta de Conteúdo pode ser usado para acessar o conteúdo sem entrar em uma exibição de lista. Os usuários podem ter uma pequena quantidade de conteúdo que acessam frequentemente ou itens que desejam rastrear. No modelo do site da Central de Documentos, três Web Parts de Consulta de Conteúdo são usados por padrão: um devolve itens modificados pelo usuário conectado, outro para os documentos com maior classificação e um terceiro para os documentos mais recentes. Combinados, todos os três Web Parts de Consulta de Conteúdo fornecem uma página inicial que oferece conteúdo que um usuário pode acessar frequentemente ou estar mais interessado. Isto suporta a descoberta de novo conteúdo e acesso rápido dos documentos que são usados frequentemente. Outro exemplo é criar uma lista de favoritos para que os usuários possam marcar o conteúdo para rastrear e usar um Web Part de Consulta de Conteúdo para devolver a lista de favoritos para que os usuários possam acessar rapidamente o conteúdo que usam frequentemente sem acessar a lista.

Quando você usa um Web Part de Consulta de Conteúdo com uma grande lista, existem algumas coisas importantes a considerar para que ele devolva corretamente os resultados e não seja bloqueado pelo limite de exibição de lista. Os itens devem ser filtrados para uma quantidade menor do que o limite de exibição de lista usando uma coluna indexada. Nós não recomendamos que você use as consultas de lista cruzada quando uma das listas é uma grande lista. Se o número total de itens considerados na consulta de lista cruzada é maior do que o limite de exibição de lista para auditores e administradores (20.000 por padrão), a operação é bloqueada.

Resumo das recomendações do Web Part de Consulta de Conteúdo

• Use o Web Part de Consulta de Conteúdo para devolver os itens que os usuários acessam frequentemente, estejam interessados ou que pode ajudar os usuários a descobrir conteúdo.

• Quando você está usando um Web Part de Consulta de Conteúdo em uma grande lista, você deve filtrar itens para que a consulta não exceda o limite de exibição de lista.

• Você deve usar somente colunas com índices para filtragem.

• Não use o Web Part de Consulta de Conteúdo para consultar várias listas se a quantidade total de itens considerados é maior do que o limite de exibição de lista para auditores e administradores (20.000 por padrão).

• Use o armazenamento em cache para tempos de carregamento mais rápidos em menos carga do SQL Server.

Web Parts de Pesquisa

A tabela a seguir exibe vários prós e contras do Web Part de Pesquisa.

Prós

Contras

Consultas de descarregamento de computadores que estão executando o SQL Server para pesquisar servidores que são mais fáceis de dimensionar. A consulta de pesquisa e servidores de índice são mais dimensionáveis e com melhor desempenho do que consultar diretamente o SQL Server. Os resultados são baseados na pesquisa de texto completo dos documentos ao invés de somente os metadados. Os resumos do texto fornecem mais informações sobre os resultados do que o Web Parts de Consulta de Conteúdo.

Os resultados são menos atuais e estão apenas atualizados conforme o rastreamento mais recente. Os resultados não exibe valores da coluna. Não é possível realizar ações da lista.

As consultas de pesquisa dimensionam melhor do que acessar os recursos do SQL Server porque a pesquisa é otimizada para cenários de alta leitura e é mais fácil dimensionar para índices de várias pesquisas e servidores de consulta do que dimensionar instâncias do SQL Server. Você pode usar o Web Part de Pesquisa pré-configurado, caixas de pesquisa ou uma combinação para ajudar os usuários a recuperar conteúdo. As consultas de pesquisa fornecem um método de descarregamento de consultas para pesquisar índices, reduzindo a carga do SQL Server. As consultas de pesquisa também são menos afetadas pelo tamanho da lista comparado ao Web Part de Consulta de Conteúdo ou as consultas de exibição de lista.

Você pode usar a pesquisa em qualquer cenário para exibir resultados das consultas pré-configuradas ou especificadas pelo usuário. A pesquisa fornece o melhor desempenho em pontos de alta dimensionabilidade. A pesquisa não deve ser usada se as ações da lista devem ser realizadas em itens ou se os dados devem ser exibidos em tempo real, pois os resultados são tão atuais quanto o rastreamento mais recente. A tabela a seguir exibe três Web Parts de Pesquisa que podem ser usados.

Web Part de Pesquisa	Descrição
Web Part de Resultados Principais	Resultados completos com paginação e o Web Part com maior quantidade de recursos. Pode realizar consultas do sistema ou especificadas pelo usuário.
Web Part de Resultados Federados	Um pequeno conjunto de resultados que possui um link opcional para acessar os resultados completos.
Web Part de Caixa de Pesquisa	Um Web Part que é usado para levar a entrada do usuário para uma consulta.

Exibições de lista

A tabela a seguir exibe vários prós e contras de usar exibições de lista.

Prós	Contras
As ações da exibição de lista como check-in, check-out e editar propriedades podem ser usadas para interagir com os documentos. Fácil de personalizar exibições e exibir colunas diferentes. Experiência altamente interativa para filtragem dinâmica e classificação de resultados em tempo real.	Maior impacto negativo no desempenho para latência e taxa de transferência. Tempo de renderização mais lento A melhor experiência do usuário é com apenas um Web Part de Exibição de Lista por página.

As exibições de lista e navegação de metadados podem suportar a recuperação de conteúdo em grandes bibliotecas de documentos que usam pastas e índices ou ambos. Uma consulta com uma exibição de lista é realizada em tempo real e consulta o banco de dados do SQL Server diretamente. Isto fornece os resultados mais recentes. No entanto, tem maior efeito no desempenho. A taxa de transferência geral irá diminuir e a latência ira´aumentar com listas de grande tamanho. As exibições de lista rederizam a maioria do conteúdo para uma página carregar. Portanto, o tempo de renderização da página é muitas vezes maior com a exibição de lista.

Você deve usar a navegação de metadados e exibições de lista quando precisa realizar ações em itens da exibição de lista. As exibições de lista podem ser o método primário para trabalhar com uma lista em cenários de baixa leitura. Nos cenários que possuem várias operações de leitura, você pode precisar considerar outros métodos de consulta como o método primário para acessar os dados de lista.

Configuração de exibição

Resumo das recomendações de configuração da exibição

• Selecione cuidadosamente as colunas que são usadas em exibições. Ter mais colunas significa mais dados para renderizar, o que aumenta o tempo de carregamento da página. Há uma troca entre o tempo de carregamento da página e a melhor experiência do usuário.

• Minimize a quantidade de colunas de pesquisa, como os metadados gerenciados e pessoas e grupos nas exibições, pois isto irá causar junções com outras tabelas do banco de dados e aumentará a carga do banco de dados.

• Não use totais para as colunas.

• Se as exibições não são filtradas usando colunas indexadas, selecione a opção para exibir itens em pastas e certifique-se de que as pastas individuais não possuem mais itens do que o limite de exibição de lista.

• As exibições devem ser filtradas em colunas indexadas para reduzir o número de itens que são devolvidos, para que o número seja menor do que o limite de exibição de lista (especialmente se não há subpastas ou pastas que contêm mais itens do que o limite de exibição de lista).

• Habilitar o recurso de navegação de metadados para devolver os resultados mais recentes das consultas que, de outra forma, seriam evitados pelo limite de exibição de lista. Por padrão, isto está habilitado em quase todos os sites.

• Se você está usando as exibições filtradas em combinação com a navegação de metadados, considere usar exibições por local para criar exibições não filtradas para dinamização da navegação de metadados para que todos os resultados sejam devolvidos.

Número de colunas e colunas de pesquisa

As exibições são o método mais comum usado para acessar dados da lista. As exibições devem ser selecionados cuidadosamente para otimizar como os usuários podem encontrar conteúdo e cumprir os requisitos de desempenho. Para uma grande lista, tenha atenção especial sobre como as exibições são configuradas. Recomendamos apenas exibições padrões e exibições personalizadas. As exibições de Folha de dados, Gantt e Calendário não são recomendadas com listas que excedem o limite de exibição de lista, pois elas podem ser bloqueadas pelo limite de exibição de lista. As exibições devem possuir o menor número de colunas possível, mas tenha cuidado especial com o número de colunas de pesquisa (metadados gerenciados, pessoas e grupos e tipos de pesquisa), pois a pesquisa realiza junções de outras tabelas, o que afeta o desempenho.

Filtragem de coluna e totais

o novo limite de exibição de lista no SharePoint Server 2010 apresenta uma grande mudança em como as exibições devem ser usadas com grandes listas. Os usuários irão obter erros se as exibições tentam devolver mais resultados do que o limite de exibição de lista. Usar os totais em uma grande lista sempre será bloqueado pelo limite de exibição de lista. Portanto, não os use. O número de itens que devem ser digitalizados é o importante, não necessariamente o número de linhas que é devolvido. Se uma exibição possui um filtro onde a coluna Cor = “Vermelho” e a cor não é uma coluna indexada, pode ser evitada. Mesmo se houverem apenas 100 itens que correspondam esta consulta, se houverem 10.000 itens na lista, a consulta deve pesquisar os 10.000 itens. Neste caso, os usuários obtêm os erros quando eles tentam acessar a exibição. Para resolver este problema, você pode usar pastas, filtros e indexação e navegação de metadados.

Pastas

Se uma lista é organizada para que nenhuma pasta contenha mais itens do que o limite de exibição de lista, você pode selecionar a opção para exibir itens nas pastas. Exibir todos os itens fora das pastas deve ser evitado, a não ser que você possua os mecanismos para filtrar os resultados para uma quantidade menor do que o limite de exibição de lista.

Indexação

Em um exemplo anterior, realizar uma consulta na coluna Cor falhou porque não estava indexada. Para resolver este problema, a coluna Cor pode ser indexada e as consultas irão funcionar se os valores são distintos o suficiente. Se houverem apenas 100 itens vermelhos, isto irá funcionar. No entanto, se existem mais itens que correspondem do que o limite de exibição de lista mesmo com a indexação, ainda será bloqueado. Por padrão, o campo de ID, estrutura de pasta e pesquisa de valores múltiplos são indexados no sistema. Qualquer nova coluna que é criada e usada para filtragem deve possuir índices que são criados manualmente.

Exemplo de exibições

Itens alterados recentemente

A exibição de Itens Alterados Recentemente é usada para mostrar os itens alterados mais recentemente. Pode ser usado para a exibição padrão quando os usuários acessam frequentemente o conteúdo de uma variedade de fontes que foram modificados recentemente. É fácil configurar esta exibição porque usa os metadados do sistema que estão sempre definidos para cada item. Para uma grande lista, você deve definir o limite de itens para uma quantidade abaixo do limite de exibição de lista ou filtrar os resultados para uma quantidade menor do que o limite de exibição de lista. Para criar esta exibição, você deve indexar o campo modificado e classificar na ordem descendente. Especifique um filtro para a coluna Modificado e use a fórmula [Hoje-x], onde x é o número de dias que vale os dados a serem exibidos. Selecione a opção, maior que ou igual. A fórmula [Hoje-x], deve devolver uma quantidade de itens menor que o limite de exibição de lista.

Meus Itens

A exibição Meus Itens pode ser usada em repositórios onde os usuários acessam frequentemente seus próprios documentos. Esta exibição é fácil de configurar porque usa os metadados do sistema que estão sempre definidos para cada item. Nesta exibição, você filtra pelas colunas Modificado Por ou Criado Por em ambas as colunas. Para criar esta exibição nos filtros, selecione a coluna Modificado Por, defina o valor para [ME] e defina um segundo filtro com OU na coluna Criado Por com o valor também definido pelo [ME]. A coluna Criado Por deve ser usada além da coluna Modificado Por quando vários usuários editam os mesmos documentos. Modificado Por não é uma coluna de múltiplos usuários. Portanto, esta exibição não necessariamente exibe todos os documentos que um usuário modificou. Neste exemplo, ambas as colunas devem ser indexadas porque a operação é uma operação OU.

Conclusão

O SharePoint Server 2010 fornece recursos novos e aprimorados que melhoram a experiência do usuário e desempenho de trabalho com grandes listas. As acelerações e os limites protegem o desempenho do farm de outros usuários e evita que as operações consumam uma quantidade desproporcionalmente grande de recursos do SQL Server. As melhorias de metadados e navegação de metadados fornecem uma experiência melhor para recuperar dados da lista e as exibições de lista, pesquisa e o Web Part de Consulta de Conteúdo podem ser configurados para trabalhar com grandes listas. O planejamento cuidadoso ainda é exigido para criar a solução correta para suas necessidades. No entanto, grandes listas podem ser desenvolvidas rapidamente com a configuração de soluções externas que foram projetadas para funcionar com bom desempenho.

See Also

Other Resources

Central de Recursos: Gerenciamento de Capacidade do SharePoint Server 2010