Otimize o Armazenamento de Sincronização no Atlas
Nesta página
O Atlas Device Sync usa espaço no Atlas cluster sincronizado do seu aplicativo para armazenar metadados para sincronização. Isso inclui um histórico de alterações em cada banco de banco de dados sincronizado. O Atlas App Services minimiza esta utilização de espaço no seu Atlas cluster. A minimização de metadados é necessária para reduzir o tempo e os dados necessários para sincronização.
História
O backend do App Services mantém um histórico de alterações nos dados subjacentes de cada Realm, semelhante aooplog do MongoDB . O App Services usa esse histórico para sincronizar dados entre o backend e os clientes. O App Services armazena o histórico em seu cluster Atlas sincronizado.
Cortar
Quando você define o tempo máximo offline do cliente em um aplicativo, a redução exclui as alterações mais antigas do que o tempo máximo offline do cliente .
Tempo máximo offline do cliente
Usado no corte, o tempo máximo offline do cliente controla o limite de idade do histórico. Isso altera indiretamente quanto tempo um cliente pode permanecer offline entre as sessões de sincronização com o backend. Os clientes que não sincronizam por mais do que o número de dias especificado podem sofrer um reinício do cliente na próxima vez que se conectarem ao backend.
Definir o tempo máximo offline do cliente para um valor mais baixo diminuirá a quantidade de histórico exigida pela sincronização. A otimização resultante reduz o uso de armazenamento no cluster do Atlas sincronizado.
Novos aplicativos habilitam automaticamente o tempo máximo offline do cliente com um valor padrão de 30 dias.
Aviso
O tempo máximo offline do cliente causa alterações permanentes no histórico
O tempo máximo offline do cliente permite cortar o histórico mais antigo. Isso altera permanentemente o histórico afetado e pode causar redefinições de cliente no futuro.
Conceitos chave
A sincronização deve sempre convergir para o mesmo estado final em todos os clientes. Para fazer a convergência durante uma sincronização, os clientes exigem o histórico completo de alterações, começando imediatamente após a última sincronização. Quando um cliente não sincroniza por um longo período de tempo, o corte pode alterar o histórico de formas a impedir a convergência do cliente. Como a sincronização depende de todos os clientes convergindo para um resultado comum, esse cliente não pode sincronizar.
Como resultado, o cliente deve concluir um reinício do cliente antes de retomar a sincronização. Em um cenário de reinício do cliente, o cliente exclui a cópia local do cliente de um Realm e baixa o estado atual desse Realm do backend. Em seguida, a sincronização é retomada usando a nova cópia do Realm.
O tempo máximo offline do cliente controla quanto tempo seu backend espera antes de aplicar o corte. Após o número especificado de dias sem sincronização, os clientes podem sofrer um reinício do cliente na próxima vez que se conectarem ao backend.
Os aplicativos que não especificam o tempo máximo offline do cliente nunca aplicam a redução. Isso significa que os clientes podem se conectar após qualquer período offline -- semanas, meses ou até anos -- e sincronizar as alterações. Com o passar do tempo, os domínios editados com frequência acumulam muitas alterações. Com um grande conjunto de alterações, a sincronização requer mais tempo e uso de dados.
O tempo máximo offline do cliente não influencia imediatamente o reinício do cliente
A redução causa mudanças permanentes e irreversíveis no histórico. Como resultado, aumentar o tempo máximo offline do cliente não altera imediatamente o tempo antes de os clientes sofrerem um reinício do cliente. O histórico existente já foi alterado pelo corte, exigindo um reinício do cliente. O novo histórico precisa de tempo para acumular até o novo tempo máximo offline do cliente.
A redução do tempo máximo offline do cliente não altera imediatamente o período de tempo antes de o cliente sofrer um reinício do cliente. As redefinições de clientes começam a ocorrer mais cedo, uma vez que o tarefa de redução agendado regularmente aplica a redução ao histórico recém-qualificado.
Definir o Tempo Máximo Offline do Cliente
Na interface do usuário do App Services, clique em menu Device Sync na barra lateral. A aba Dashboard é exibida por padrão.
Clique na aba Configuration.
Role para baixo até a seção Advanced Configuration (optional) e clique no menu suspenso para expandir a seção.
![Seção Configuração avançada na UI do App Services]()
Na seção Client Max Offline Time , especifique um número de dias para o tempo máximo offline do cliente do seu aplicativo. O valor padrão é 30 dias. O valor mínimo é 1.
Clique no botão Save Changes na parte inferior da tela quando estiver pronto para salvar.
Na janela de confirmação, clique no botão Save Changes novamente para confirmar as alterações.
Faça pull de uma cópia local da versão mais recente do seu aplicativo com o seguinte comando pull:
Puxeappservices pull --remote="<Your App ID>" Você pode configurar o número de dias para o tempo máximo offline do cliente do seu aplicativo com a propriedade
client_max_offline_daysno arquivosync/config.jsondo seu aplicativo:``sync/config.json``{ "client_max_offline_days": 42, } Implemente a configuração de aplicação atualizada com o seguinte comando push:
Empurrarappservices push --remote="<Your App ID>"
Otimização do desempenho e do armazenamento ao usar a Flexible Sync
Para a configuração do Flexible Sync, a quantidade de espaço de armazenamento do Atlas utilizada é diretamente proporcional ao número de campos de query que você configurou. Os campo de query usam armazenamento no cluster do Atlas. Quanto mais campos de query você configurar, mais armazenamento usará no cluster de backup.
Se você tiver um grande número de coleções em um aplicativo, talvez seja necessário usar o mesmo nome de campo de query em várias coleções. Combine isso com permissões para um controle mais granular sobre quem pode acessar quais coleções.
Exemplo
Seu aplicativo pode conter 20 ou 30 collection, mas você deseja minimizar o número de campo de query. Você pode reutilizar campo de query globais entre collection para sincronizar objeto de todas as collection. Por exemplo, owner_id pode ser um campo que você deseja fazer query em múltiplas collection.
Alternativamente, você pode ter owner_id em múltiplas collections, mas só precisa fazer query nele em uma collection. Neste caso, você pode tornar owner_id um campo de query da collection. Isso significa que a sincronização só precisa manter metadados sobre esse campo para uma collection, em vez de armazenar metadados para todas as collection em que você não está consultando esse campo.
Finalmente, para aplicativos onde os dispositivos desejam executar uma query de uma faceta específica dos dados, como owner_id == user.id, você pode querer designar o campo como um campo de query indexado. Os campos de query indexados fornecem um desempenho mais eficiente para aplicativos em que o cliente só precisa sincronizar um pequeno subconjunto de seus dados - um grupo de armazenamentos ou um único usuário, por exemplo.
Você pode ter um campo de query indexado por aplicativo. Um campo de query indexado é um campo de query global que deve estar presente e usar o mesmo tipo de dados elegível em cada collection que você sincroniza.
Para obter mais informações, consulte Escopos de campos de query e campos de query indexados.
Para obter o melhor desempenho, abra um Realm sincronizado com uma query ampla. Em seguida, adicione mais query refinadas para expor conjuntos de dados direcionados na aplicação cliente. Cortar conjunto de trabalho de uma query ampla fornece melhor desempenho do que abrir vários domínios sincronizados usando query mais granulares.
Ao configurar campos de query, considere as queries amplas que você usa para o Sync e selecione menos campos que suportem essas queries amplas.
Exemplo
Em um aplicativo de lista de tarefas, prefira queries amplas, como assignee == currentUser ou projectName == selectedProject para uma query de sincronização. Isso fornece alguns campos amplos contra os quais sincronizar documentos. No cliente, você pode refinar ainda mais sua query para coisas como tarefas de uma determinada prioridade ou status de conclusão para dividir um conjunto de trabalho.
Resumo
O Realm Mobile Sync usa espaço no cluster do Atlas sincronizado para armazenar o histórico de alterações.
A redução reduz o uso de espaço para Flexible Sync, mas pode causar reinício do cliente para clientes que não se conectaram ao backend em mais do que o tempo máximo offline do cliente (em dias).
Adicionar campos de query adicionais a uma configuração de Flexible Sync aumentará o armazenamento consumido em um cluster do Atlas. O uso de query amplas e a seleção de menos campo compatíveis com query amplas diminuem o armazenamento consumido.