Como a arquitetura do sistema de pesquisa é afetada pela atualização (Search Server 2010)
Tópico modificado em: 2015-03-09
As informações da tabela a seguir descrevem como os recursos e as funções da arquitetura do sistema de pesquisa serão afetados quando você atualizar do Microsoft Search Server 2008 para o Microsoft Search Server 2010.
Recurso ou função | Recurso ou função do Search Server 2008 | Recurso ou função correspondente do Search Server 2010 |
---|---|---|
Serviço de Pesquisa |
Um SSP (Provedor de Serviços Compartilhados) hospeda um ou mais serviços reutilizáveis centralmente gerenciados. Esses serviços podem ser consumidos por vários aplicativos Web em um farm. Um dos serviços é o Office SharePoint Server Search (OSearch). O serviço OSearch é usado para rastrear repositórios de conteúdo, indexar o conteúdo rastreado e atender a consultas de pesquisa emitidas por usuários finais. Entretanto, um administrador pode querer definir mais de um grupo de configurações de pesquisa para uma configuração de pesquisa em todo o farm. Por exemplo, por motivos de segurança, o administrador pode desejar dedicar um índice de conteúdo para um conjunto de fontes de conteúdo e outro índice de conteúdo para outro conjunto de fontes de conteúdo. Para definir um grupo de configurações adicional para um sistema de pesquisa em todo o farm, o administrador de pesquisa deve configurar o serviço OSearch em um SSP diferente. Se não houver outro SSP no farm que possa ser usado para essa finalidade, o administrador do farm deverá criar um novo SSP. No entanto, cada SSP requer manutenção e pode consumir recursos do sistema além daqueles usados para o serviço OSearch. |
Para cada SSP que existia no farm antes da atualização, o processo de atualização cria automaticamente um aplicativo de serviço de Pesquisa. Durante a atualização, as configurações administrativas do serviço OSearch em um SSP são copiadas para o novo aplicativo de serviço de Pesquisa correspondente. Por exemplo, o novo aplicativo de serviço de Pesquisa contém as fontes de conteúdo, os escopos e as regras de rastreamento do serviço OSearch no SSP correspondente. |
Dependências de configuração do serviço de Pesquisa |
Em um SSP, o administrador de pesquisa configura o serviço OSearch para definir um grupo de configurações (como fontes de conteúdo e escopos) para um sistema de pesquisa em todo o farm. Cada SSP pode conter somente um serviço OSearch. Dessa forma, um SSP pode contribuir com apenas um grupo de configurações para o sistema de pesquisa em todo o farm. |
Cada aplicativo de serviço de Pesquisa contribui com um grupo de configurações (como fontes de conteúdo e escopos) para um sistema de pesquisa em todo o farm. Um aplicativo de serviço de Pesquisa não exige um host como um SSP. Para adicionar um novo grupo de configurações a um sistema de pesquisa em todo o farm, o administrador de pesquisa simplesmente cria e configura um aplicativo de serviço de Pesquisa adicional. |
Bancos de dados |
Para cada SSP, existem dois bancos de dados:
|
Para cada SSP existente antes da atualização, os três bancos de dados a seguir são criados e associados ao aplicativo de serviço de Pesquisa correspondente:
Existe somente um banco de dados de administração de pesquisa por aplicativo de serviço de Pesquisa. Entretanto, após uma atualização, o banco de dados de rastreamento e o banco de dados de propriedades poderão ser dimensionados. |
Rastreamento |
Um servidor de indexação tem um único rastreador. |
Um servidor de rastreamento contém um ou mais componentes de rastreamento que podem rastrear conteúdo independentemente uns dos outros. |
Fazendo consultas |
Um servidor de consulta tem somente um componente para atender a consultas de pesquisa. |
Um servidor de consulta pode hospedar um ou mais componentes de consulta, e cada um atende a consultas de pesquisa. |
Índice de conteúdo |
Cada SSP pode conter somente um serviço OSearch, e há um índice de conteúdo correspondente. |
Para cada SSP que existia antes da atualização, uma partição de índice é criada com um componente de consulta. Uma atualização in-loco copia todo o índice de conteúdo do SSP para a nova partição de índice. Após a atualização, o administrador poderá expandir para várias partições de índice. Cada partição de índice contém uma parte diferente do índice. Por exemplo, em uma topologia com duas partições de índice, cada partição contém metade do índice. Em uma atualização com anexação de banco de dados, o índice de conteúdo antigo não é mantido. Para criar um índice, é necessário executar um rastreamento completo após a atualização. |
Propagação de índice de conteúdo |
O sistema de pesquisa armazena o índice de conteúdo no sistema de arquivos do servidor de indexação. O sistema de pesquisa também propaga uma cópia do índice de conteúdo para o sistema de arquivos de cada servidor de consulta. |
Cada componente de rastreamento propaga o índice de conteúdo para partições de índice nos servidores de consulta. O sistema de pesquisa armazena o índice de conteúdo nos sistemas de arquivos dos servidores de consulta. O servidor de rastreamento não mantém uma cópia do índice de conteúdo. |
Nomenclatura do SSP e do aplicativo de serviço de Pesquisa |
Cada SSP em um farm de servidores tem um nome exclusivo — por exemplo, SharedServices1. |
Cada aplicativo de serviço de Pesquisa criado durante o processo de atualização tem um nome padrão baseado no nome do SSP correspondente do Microsoft Search Server 2008. Por exemplo, se o SSP tiver sido nomeado como SharedServices1, por padrão, o aplicativo de serviço de Pesquisa correspondente será chamado de SharedServices1_Search. No entanto, o administrador pode personalizar esses nomes de banco de dados com um arquivo XML usado no momento da atualização. |