Projetar seu próprio modelo de dados

Objetivos de aprendizagem

Após concluir esta unidade, você estará apto a:

• Criar um modelo de dados para grandes volumes de dados.
  
• Descrever os três tipos de distorção de dados e como evitá-los.
  
• Ampliar um modelo de dados para incluir objetos externos.
  

Planejar seu modelo de dados

Os dados são um dos elementos principais de qualquer aplicativo. Os usuários criam dados constantemente. O dia todo. Todos os dias. São. Muitos. Dados. De repente, sua organização acumulou milhões de registros, milhares de usuários e muitos gigabytes de armazenamento de dados.

Esses grandes volumes de dados (LDV, “large data volumes”) podem deixar o desempenho lento, o que envolve consultas mais lentas, pesquisas e modos de exibição de lista mais lentos, e atualização mais lenta do sandbox. Para evitar esse problema, basta se planejar com antecedência para acomodar os LDV, desenvolvendo um modelo de dados que comporte expansões desde o princípio.

O essencial sobre a distorção de dados

Para gerenciar grandes volumes de dados visando o melhor desempenho, é crucial desenvolver com cuidado a arquitetura da propriedade dos registros a fim de evitar a distorção de dados. A distorção de dados acontece quando mais de 10.000 registros filho são associados ao mesmo registro pai dentro da organização.

Planeje seu modelo de dados com contas suficientes para que o número de registros filho por registro pai se mantenha abaixo desse limite, e distribua os registros filho novos entre essas contas conforme elas forem criadas. Quando essas estratégias não são usadas, três tipos de distorção de dados podem acontecer e prejudicar o desempenho: distorção de dados de conta, distorção de propriedade e distorção de pesquisa.

Distorção de dados de conta

Alguns objetos do Salesforce, como as contas e as oportunidades, têm relacionamentos especiais de dados que mantêm o acesso aos registros pai e filho em modelos de compartilhamento particular. Ter muitos registros filho associados ao mesmo objeto pai em um desses relacionamentos causa a distorção de dados de conta. Digamos que você tem vários contatos não atribuídos e resolveu colocá-los em uma conta chamada “Não atribuído”. Isso pode causar problemas com o desempenho no compartilhamento e bloqueio de registro.

Bloqueio de registro

Outro exemplo: você está atualizando um grande número de contatos na mesma conta, em vários threads. Para cada atualização, o sistema bloqueia o contato que está sendo alterado e a conta pai dele para manter a integridade no banco de dados. Mesmo que cada bloqueio seja mantido por muito pouco tempo, como todas as atualizações estão tentando bloquear a mesma conta, há um grande risco de que certa atualização dê errado porque a anterior ainda está bloqueando a conta.

Problemas de compartilhamento

Com o compartilhamento, a dinâmica é parecida. Dependendo das suas configurações de compartilhamento, quando você fizer algo aparentemente simples, como mudar o proprietário de uma conta, pode precisar examinar cada um dos registros filho dessa conta e ajustar o compartilhamento deles também. Isso pode envolver recalcular a hierarquia de papéis e as regras de compartilhamento. E, se estivermos lidando com centenas de milhares de registros filho, isso pode ser extremamente demorado.

Distorção de propriedade

Quando um grande número de registros com o mesmo tipo de objeto pertence a um único usuário, esse desequilíbrio causa a distorção de propriedade. Como cada registro precisa ter seu proprietário, desviar todos os registros para um proprietário genérico, como o “Não atribuído” que mencionamos, pode parecer a solução mais natural. Mas isso pode causar problemas de desempenho devido aos cálculos de compartilhamento necessários para gerenciar a visibilidade desses registros.

Quando o proprietário distorcido existe na hierarquia de papéis, operações como exclusões ou atualizações de proprietário precisam remover o compartilhamento do proprietário antigo e todos os usuários pai dentro da hierarquia de papéis, e de todos os usuários que receberam acesso de acordo com as regras de compartilhamento. Por isso, a mudança de propriedade tende a ser uma das alterações transacionais mais desgastantes no sistema.

Em alguns casos, é impossível evitar a distorção de propriedade. Nesses casos, é melhor garantir que o proprietário distorcido não tenha um papel. Assim, você tira o usuário e os registros dele da hierarquia de papéis e das regras de compartilhamento a ela associadas.

Distorção de pesquisa

A distorção de pesquisa acontece quando um número muito grande de registros está associado a um único registro no objeto de pesquisa (o objeto em que você está pesquisando). Como é possível colocar campos de pesquisa em qualquer objeto do Salesforce, a distorção de pesquisa pode criar problemas para qualquer objeto de sua organização.

Se você acabar com uma distorção de pesquisa em uma implementação personalizada de alta complexidade, pode estar causando um problema sem perceber. Considere com cuidado as suas opções para gerenciar a distorção de pesquisa. Assim, você pode prevenir os problemas de bloqueio nos campos de pesquisa, garantindo que sua arquitetura possa ser redimensionada para acompanhar o crescimento da organização.

Por que a distorção de pesquisa é tão ruim? No Salesforce, os campos de pesquisa são essencialmente relacionamentos de chave estrangeira entre objetos. Sempre que um registro é inserido ou atualizado, o Salesforce precisa bloquear os registros de destino que foram selecionados para cada campo de pesquisa. Isso garante que a integridade seja mantida quando os dados forem confirmados no banco de dados.

Em circunstâncias normais, as operações de salvar são executadas com tanta rapidez que você não encontra os bloqueios. Porém, quando o código personalizado e os LDV são simultaneamente acrescentados a um processo automático, pode haver exceções de bloqueio que causem falhas quando você tentar inserir ou atualizar registros.

Como não existem ferramentas específicas para identificar a distorção de pesquisa, encontrar esse tipo de problemas na arquitetura pode ser tão difícil quanto achar uma agulha no palheiro. É importante lembrar que, em determinados padrões de uso, a distorção de pesquisa talvez não crie nenhum problema; por isso, o melhor é procurar com base em padrões que causarão problemas. É preciso avaliar os objetos que têm um grande número de registros e muitas atividades simultâneas de inserção e atualização.

Como usar objetos externos

Outra estratégia para LDV é usar objetos externos. Com eles, não é preciso trazer os dados para o Salesforce. A estratégia de separar os dados por camadas, dividindo os dados em vários objetos e os trazendo conforme a demanda de outro objeto ou armazenamento externo, permite evitar o armazenamento de grandes volumes de dados em sua organização e os problemas de desempenho associados aos LDV.

Os objetos externos são parecidos com os objetos personalizados, mas mapeiam para dados armazenados fora de sua organização do Salesforce, o que permite que os seus usuários e a plataforma Force.com pesquisem e interajam com os dados externos.

Como os objetos externos acessam os dados do registro conforme a demanda, eles sempre refletem o estado atual dos dados externos. Não é preciso gerenciar uma cópia desses dados no Salesforce, então você não desperdiça armazenamento e recursos mantendo os dados em sincronia. Os objetos externos são mais bem aproveitados quando você tem uma grande quantidade de dados que não pode ou não quer armazenar em sua organização do Salesforce e só precisa usar uma pequena quantidade desses dados em qualquer momento.

Uma origem de dados externa especifica como acessar um sistema externo. O Salesforce Connect usa as fontes de dados externas para acessar os dados armazenados fora de sua organização do Salesforce. O Files Connect usa as fontes de dados externas para acessar sistemas de conteúdo de terceiros. As fontes de dados externas estão associadas a objetos externos, que são usados por seus usuários e pela plataforma Force.com para interagir com os dados e conteúdos externos.

Pesquisas de objeto externo

Os objetos externos são compatíveis com os relacionamentos de pesquisa padrão, que usam a ID de registro do Salesforce com 18 caracteres para associar os registros relacionados entre si. Mas os dados que não estão armazenados dentro de sua organização do Salesforce geralmente não contêm essas IDs de registro. Por isso, dois tipos especiais de relacionamento de pesquisa estão disponíveis para os objetos externos: a pesquisa externa e a pesquisa indireta.

A pesquisa externa e a pesquisa indireta comparam os valores de um campo específico do objeto pai com os valores do campo de relacionamento do objeto filho. Quando os valores correspondem, os registros são relacionados entre si.

Use um relacionamento de pesquisa externo quando o pai for um objeto externo. O relacionamento de pesquisa externo associa um objeto padrão filho, personalizado ou externo a um objeto externo pai. Os valores do campo de ID externa padrão no objeto externo pai são comparados aos valores do campo de relacionamento de pesquisa externo. Para um objeto externo filho, os valores do campo de relacionamento de pesquisa externo vêm do Nome da coluna externa especificado.

Use um relacionamento de pesquisa indireto quando os dados externos não contiverem IDs de registro do Salesforce. O relacionamento de pesquisa indireto associa um objeto externo filho a um objeto padrão ou personalizado pai. Ao criar um campo de relacionamento de pesquisa indireto em um objeto externo, você especifica o campo de objeto pai e o campo de objeto filho a corresponderem entre si. Para isso, selecione um campo de ID externa exclusiva personalizado do objeto pai a ser correspondido ao campo de relacionamento de pesquisa indireto do filho, cujos valores são determinados pelo Nome da coluna externa especificado.

Veja abaixo o detalhamento dos tipos de relacionamento disponíveis para os objetos externos:

Agora você já sabe o que considerar (e o que evitar) na hora de arquitetar sua organização para grandes volumes de dados. Você talvez queira trabalhar com um arquiteto dos Serviços estratégicos da Salesforce que ajude a conceber a melhor forma de gerenciar a configuração inicial e o crescimento com o passar do tempo. Na próxima unidade, vamos acrescentar as consultas e as pesquisas de LDV na mistura.

Recursos

• Desenvolvedor do Salesforce: Avoid Account Data Skew for Peak Performance
• Desenvolvedor do Salesforce: Managing Lookup Skew in Salesforce to Avoid Record Lock Exceptions
• Ajuda do Salesforce: Define External Objects
• PDF: Designing Record Access for Enterprise Scale
• Desenvolvedor do Salesforce: Visão geral de objetos e campos do Salesforce/objetos externos