Sincronização baseada em partição

Partição

Uma partição é uma coleção de objetos que compartilham o mesmo valor-chave de partição.

Um Atlas cluster MongoDB consiste em vários servidores remotos. Esses servidores fornecem o armazenamento para seus dados sincronizados. O Atlas cluster armazena documentos em coleções. Cada coleção MongoDB mapeia para um tipo de objeto de Realm diferente. Cada documento em uma coleção representa um objeto específico do Realm.

Um domínio sincronizado é um arquivo local em um dispositivo. Um domínio sincronizado pode conter alguns ou todos os objetos relevantes para o usuário final. Um aplicativo cliente pode usar mais de um domínio sincronizado para acessar todos os objetos que o aplicativo precisa.

As partições vinculam objetos no banco de dados do Realm a documentos no MongoDB. Quando você inicializa um arquivo de Realm sincronizado, um de seus parâmetros é um valor da partição. Sua aplicativo cliente cria objetos no realm sincronizado. Quando esses objetos são sincronizados, o valor da partição se torna um campo nos documentos do MongoDB. O valor deste campo determina quais documentos do MongoDB o cliente pode acessar.

Em alto nível:

• Uma partição mapeia para um subconjunto dos documentos em um cluster sincronizado.

• Todos os documentos em uma partição têm as mesmas permissões de leitura/escrita para um determinado usuário.

• Atlas App Services mapeia cada partição para um arquivo .realm sincronizado individualmente.

• Cada objeto em um domínio sincronizado tem um documento correspondente na partição.

As partições moldam os dados em um Atlas cluster. Cada forma representa um tipo de objeto. As partições são determinadas pelo color de cada forma: vermelho, verde ou azul.

Chave de partição

Uma chave de partição é um campo nomeado que você especifica ao configurar o Atlas Device Sync. A sincronização de dispositivos usa essa chave para determinar qual partição contém um determinado documento.

Dependendo do modelo de dados e da complexidade do aplicativo, sua chave de partição pode ser:

• Uma propriedade que já existe em cada documento e que logicamente particiona os dados. Por exemplo, considere um aplicativo onde cada documento é privado para um usuário específico. Você pode armazenar o valor de ID do usuário em um campo owner_id e, em seguida, usá-lo como chave de partição.

• Uma propriedade sintética que você cria para dados de partição (por exemplo, _partition). Você pode usar isso quando seu aplicativo não inclui uma chave de partição natural.

Você pode tornar a chave de partição obrigatória ou opcional em seus objetos. O App Services mapeia qualquer objeto que não inclua uma chave de partição para uma partição padrão - partição nula.

Considere o seguinte ao escolher uma chave de partição:

• As chaves de partição devem ser um destes tipos: String, ObjectID, Long ou UUID.

• Os clientes do App Services nunca devem modificar o valor da partição diretamente. Você não pode usar nenhum campo que os clientes possam modificar como chave de partição.

• As chaves de partição usam o mesmo nome de campo em todos os documentos sincronizados. A chave de partição não deve colidir com nenhum nome de campo no modelo de qualquer objeto.

{
  "title": "note",
  "bsonType": "object",
  "required": [
    "_id",
    "_partition",
    "owner_id",
    "text"
  ],
  "properties": {
    "_id": { "bsonType": "objectId" },
    "_partition": { "bsonType": "string" },
    "owner_id": { "bsonType": "string" },
    "text": { "bsonType": "string" }
  }
}
{
  "title": "notebook",
  "bsonType": "object",
  "required": [
    "_id",
    "_partition",
    "owner_id",
    "notes"
  ],
  "properties": {
    "_id": { "bsonType": "objectId" },
    "_partition": { "bsonType": "string" },
    "owner_id": { "bsonType": "string" },
    "notes": {
      "bsonType": "array",
      "items": { "bsonType": "objectId" }
    }
  }
}

Valor da partição

Um valor de partição é um valor do campo chave de partição para um determinado documento. Documentos com o mesmo valor de partição pertencem à mesma partição. Eles sincronizam com o mesmo arquivo de Realm e compartilham permissões de acesso aos dados no nível do usuário.

O valor de uma partição é o identificador para seu domínio sincronizado correspondente. Você especifica o valor da partição quando a abre como um domínio sincronizado no cliente. Se você alterar um valor de partição no Atlas, o App Services interpretará a alteração como duas operações:

• Uma exclusão da partição antiga.

• Uma inserção na nova partição.

Antes de começar

Você precisará do seguinte para ativar a sincronização baseada em partição:

• Um aplicativo do App Services. Para saber como criar um aplicativo, consulte Criar um Aplicativo.

• Uma fonte de dados do Atlas vinculada. Para saber como adicionar uma fonte de dados, consulte Vincular uma fonte de dados.

Procedimento

App Services UI

CLI de serviços de aplicativos

Admin API

1

Navegue até a tela de configuração de sincronização

Para definir as regras do Device Sync e ativar o Device Sync para seu aplicação, navegue até a tela de configuração do Device Sync através do menu de navegação esquerdo.

Observação

As Regras de Sincronização Não Podem ser Alteradas

Você define as regras do Device Sync ao mesmo tempo em que habilita o Device Sync. Depois que o Device Sync estiver habilitado, você não poderá alterar as regras do Device Sync do seu aplicativo, a menos que encerre o Device Sync e o reative com novas regras.

2

Selecione detalhes de desenvolvimento

Você pode habilitar o Device Sync para um único cluster vinculado em seu aplicativo. Determine qual cluster você deseja usar e selecione-o no menu suspenso Select a Cluster To Sync.

3

Escolher uma chave de partição

A chave de partição do Device Sync é um campo em cada documento sincronizado que mapeia cada documento para um realm do lado do cliente. As regras do Device Sync se aplicam ao nível da partição, portanto, é particularmente importante considerar seu modelo de dados e padrões de acesso. Para ver mais informações sobre chaves de partição e como escolher uma, consulte Partições.

Observação

A chave de partição pode ser obrigatória ou opcional. Se o campo da chave de partição for opcional, todos os documentos do MongoDB que excluam a chave de partição ou tenham um valor nulo para a chave de partição serão enviados para a partição nula. Se o campo da chave de partição for obrigatório, o Device Sync ignorará todos os documentos do MongoDB que não tenham um valor válido para a chave de partição. Recomendamos uma chave de partição obrigatória, a menos que você queira sincronizar dados pré-existentes com valores de partição inválidos ou ausentes de uma coleção do MongoDB.

4

Definir permissões de leitura e escrita

A seção Define Permissions permite que você defina expressões JSON que os Serviços de Aplicativo avaliam dinamicamente para determinar as permissões de leitura e escrita de um usuário para os dados em uma determinada partição.

As expressões de regra do Device Sync têm acesso a %%user, que é resolvida para o usuário que abriu a região, e %%partition, que resolve para o valor da chave de partição da região. Você também pode usar operadores, incluindo %function, para lidar com casos mais complexos. Para obter exemplos, consulte Permissões baseadas em funções.

Após determinar como decidir as permissões de leitura e escrita de um usuário para uma determinada partição, defina as expressões JSON correspondentes nas entradas Read e Write.

5

Verifique os comportamentos de configuração avançada padrão

Expanda a seção Advanced Configuration.

Aplicativos de Serviços de Aplicativos fornecem recursos avançados de otimização que são habilitados por padrão:

• Tempo máximo offline do cliente

• Recuperação do cliente

Se quiser alterar o período de tempo que um cliente pode ficar offline, você pode fazer isso na seção Advanced Configuration .

6

Ativar sincronização

Agora que você configurou as regras para seu cluster sincronizado, tudo o que resta fazer é ativar a sincronização de dispositivos para aplicativos clientes. Clique em Enable Sync, anote todas as recomendações que aparecerem e confirme sua escolha.

1

Autenticar um usuário do MongoDB Atlas

Use sua chave de API Admin do MongoDB Atlas para fazer login na CLI:

appservices login --api-key="<my api key>" --private-api-key="<my private api key>"

2

Obtenha a versão mais recente da sua aplicação

Obtenha uma cópia local dos arquivos de configuração do seu aplicativo. Para obter a versão mais recente do seu aplicativo, execute o seguinte comando:

appservices pull --remote="<Your App ID>"

Você também pode exportar uma cópia dos arquivos de configuração do aplicativo da interface do usuário ou com a API Admin. Para saber como, consulte Exporte um aplicativo.

3

Adicionar uma configuração de sincronização

Você pode habilitar a sincronização para um único cluster vinculado em seu aplicativo.

O aplicativo App Services tem um diretório sync onde você pode encontrar o arquivo de configuração de sincronização. Se você ainda não tiver ativado o Sync, esse diretório estará vazio.

Adicione um config.json semelhante a:

{
  "type": "partition",
  "state": <"enabled" | "disabled">,
  "development_mode_enabled": <Boolean>,
  "service_name": "<Data Source Name>",
  "database_name": "<Database Name>",
  "partition": {
    "key": "<Partition Key Field Name>",
    "type": "<Partition Key Type>",
    "permissions": {
      "read": { <Expression> },
      "write": { <Expression> }
    }
  },
  "client_max_offline_days": <Number>,
  "is_recovery_mode_disabled": <Boolean>
}

4

Escolher uma chave de partição

A chave de partição de sincronização é um campo em cada documento sincronizado que mapeia cada documento para um realm do lado do cliente. As regras de sincronização se aplicam ao nível da partição, portanto, é particularmente importante considerar seu modelo de dados e padrões de acesso. Para ver mais informações sobre chaves de partição e como escolher uma, consulte Partições.

Observação

A chave da partição pode ser obrigatória ou opcional. Se o campo da chave da partição for opcional, todos os documentos do MongoDB que excluam a chave da partição ou tenham um valor nulo para a chave da partição serão enviados para a partição nula. Se o campo da chave da partição for obrigatório, o Device Sync ignorará todos os documentos do MongoDB que não tenham um valor válido para a chave da partição. Recomendamos uma chave da partição obrigatória, a menos que você queira sincronizar dados pré-existentes com valores de partição inválidos ou ausentes de uma coleção do MongoDB .

Depois de decidir qual campo usar, atualize sync.partition com o nome do campo da chave da partição no campo key e o tipo de chave da partição no campo type , semelhante a:

{
  ...
  "partition": {
    "key": "owner_id",
    "type": "string",
    "permissions": {
      "read": {},
      "write": {}
    }
  }
  ...
}

5

Definir permissões de leitura e escrita

O App Services permite definir expressões JSON que avalia dinamicamente sempre que um usuário abre um Realm para determinar se o usuário tem permissões de leitura ou gravação para dados na partição.

As expressões de regra de sincronização têm acesso a %%user, que é resolvida para o usuário que abriu o Realm, e %%partition, que resolve para o valor da chave da partição do Realm. Você também pode usar operadores, incluindo %function, para lidar com casos mais complexos. Para obter exemplos, consulte Permissões de sincronização.

Depois de determinar como decidir as permissões de leitura e escrita de um usuário para uma determinada partição, defina as expressões JSON correspondentes nos campos read e write do partition.permissions, semelhantes a:

{
  ...
  "partition": {
    "key": "owner_id",
    "type": "string",
    "permissions": {
      "read": {
        "$or": [
          { "%%user.id": "%%partition" },
          { "%%user.custom_data.shared": "%%partition" }
        ]
      },
      "write": {
        "%%user.id": "%%partition"
      }
    }
  }
  ...
}

6

Especificar valores para otimização de sincronização

A Sincronização fornece recursos que permitem otimizar o desempenho da sincronização e melhorar o processo de recuperação de dados no cliente. Esses recursos são representados por configurações adicionais:

• client_max_offline_days

• is_recovery_mode_disabled

Você pode definir um valor numérico para client_max_offline_days. Quando você ativa a sincronização por meio da interface do usuário do App Services, o valor padrão é 30, que representa 30 dias.

Para obter mais informações, consulte: Tempo máximo offline do cliente.

O Modo de Recuperação permite que a Sincronização tente recuperar dados que ainda não foram sincronizados quando ocorre uma reinício do cliente . Quando você ativa a sincronização por meio da interface do usuário do App Services, o modo de recuperação é ativado por padrão. Recomendamos ativar o Modo de recuperação para o tratamento automático de reinício do cliente . Se você desativou o modo de recuperação e deseja reativá-lo, defina is_recovery_mode_disabled como false.

Para obter mais informações, consulte: Recuperar alterações não sincronizadas.

{
  "type": "partition",
  "state": "enabled",
  "development_mode_enabled": true,
  "service_name": "mongodb-atlas",
  "database_name": "my-test-database",
  "partition": {
    ...
  },
  "client_max_offline_days": 30,
  "is_recovery_mode_disabled": false
}

7

Implemente a configuração de sincronização

Agora que você definiu a configuração de sincronização, incluindo as permissões de leitura e escrita, você pode distribuir suas alterações para começar a sincronizar dados e aplicar regras de sincronização.

Para implementar suas alterações, importe a configuração do aplicativo para o App Services App:

appservices push --remote="<Your App ID>"

1

Selecione um cluster para sincronizar

Você pode habilitar a sincronização para um único cluster vinculado em seu aplicativo.

Você precisará do arquivo de configuração de serviço do cluster para configurar a sincronização. Você pode encontrar o arquivo de configuração listando todos os serviços por meio da API de administrador:

curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/services \
  -X GET \
  -h 'Authorization: Bearer <Valid Access Token>'

Identifique o serviço cuja configuração você precisa atualizar para habilitar a sincronização. Se você aceitou os nomes padrão ao configurar seu aplicativo, este deverá ser um serviço cujo name seja mongodb-atlas e type seja mongodb-atlas. Você precisa _id deste serviço.

Agora você pode obter o arquivo de configuração para este serviço:

curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/services/{MongoDB_Service_ID}/config \
  -X GET \
  -h 'Authorization: Bearer <Valid Access Token>'

Após obter a configuração, adicione o objeto sync com a seguinte configuração de modelo:

{
  ...
  "sync": {
    "type": "partition",
    "state": "enabled",
    "development_mode_enabled": <Boolean>,
    "database_name": "<Database Name>",
    "partition": {
      "key": "<Partition Key Field Name>",
      "type": "<Partition Key Type>",
      "permissions": {
        "read": { <Expression> },
        "write": { <Expression> }
      }
    },
    "client_max_offline_days": <Number>,
    "is_recovery_mode_disabled": <Boolean>
  }
  ...
}

2

Escolher uma chave de partição

A chave de partição de sincronização é um campo em cada documento sincronizado que mapeia cada documento para um realm do lado do cliente. As regras de sincronização se aplicam ao nível da partição, portanto, é particularmente importante considerar seu modelo de dados e padrões de acesso. Para ver mais informações sobre chaves de partição e como escolher uma, consulte Partições.

Você pode obter uma lista de todas as chaves de partição válidas e seus tipos correspondentes por meio da API de administrador:

curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/sync/data?service_id=<MongoDB Service ID> \
  -X GET \
  -h 'Authorization: Bearer <Valid Access Token>'

Observação

A chave da partição pode ser obrigatória ou opcional. Se o campo da chave da partição for opcional, todos os documentos do MongoDB que excluam a chave da partição ou tenham um valor nulo para a chave da partição serão enviados para a partição nula. Se o campo da chave da partição for obrigatório, o Device Sync ignorará todos os documentos do MongoDB que não tenham um valor válido para a chave da partição. Recomendamos uma chave da partição obrigatória, a menos que você queira sincronizar dados pré-existentes com valores de partição inválidos ou ausentes de uma coleção do MongoDB .

Depois de decidir qual campo usar, atualize sync.partition com o nome do campo da chave da partição no campo key e o tipo de chave da partição no campo type .

{
  ...
  "sync": {
    "type": "partition",
    "state": "enabled",
    "development_mode_enabled": <Boolean>,
    "database_name": "<Database Name>",
    "partition": {
      "key": "owner_id",
      "type": "string",
      "permissions": {
        "read": { <Expression> },
        "write": { <Expression> }
      }
    },
    "client_max_offline_days": <Number>,
    "is_recovery_mode_disabled": <Boolean>
  }
  ...
}

3

Definir permissões de leitura e escrita

O App Services permite definir expressões JSON que avalia dinamicamente sempre que um usuário abre um Realm para determinar se o usuário tem permissões de leitura ou gravação para dados na partição.

As expressões de regra de sincronização têm acesso a %%user, que é resolvida para o usuário que abriu o Realm, e %%partition, que resolve para o valor da chave da partição do Realm. Você também pode usar operadores, incluindo %function, para lidar com casos mais complexos. Para obter exemplos, consulte Permissões de sincronização.

Após determinar como decidir as permissões de leitura e escrita de um usuário para uma determinada partição, defina as expressões JSON correspondentes nos campos read e write do sync.partition.permissions.

{
  ...
  "sync": {
    "type": "partition",
    "state": "enabled",
    "development_mode_enabled": <Boolean>,
    "database_name": "<Database Name>",
    "partition": {
      "key": "owner_id",
      "type": "string",
      "permissions": {
        "read": {
          "$or": [
            { "%%user.id": "%%partition" },
            { "%%user.custom_data.shared": "%%partition" }
          ]
        },
        "write": {
          "%%user.id": "%%partition"
        }
      }
    },
    "client_max_offline_days": <Number>,
    "is_recovery_mode_disabled": <Boolean>
  }
  ...
}

4

Especificar valores para otimização de sincronização

A Sincronização fornece recursos que permitem otimizar o desempenho da sincronização e melhorar o processo de recuperação de dados do cliente . Esses recursos são representados por configurações adicionais:

• client_max_offline_days

• is_recovery_mode_disabled

Você pode definir um valor numérico para client_max_offline_days. Quando você ativa a sincronização por meio da interface do usuário do App Services, o valor padrão é 30, que representa 30 dias.

Para obter mais informações, consulte: Tempo máximo offline do cliente.

O Modo de Recuperação permite que a Sincronização tente recuperar dados não sincronizados quando ocorre uma reinício do cliente . Quando você ativa a sincronização por meio da interface do usuário do App Services, o modo de recuperação é ativado por padrão. Recomendamos ativar o Modo de recuperação para o tratamento automático de reinício do cliente . Para ativar o Modo de Recuperação, defina is_recovery_mode_disabled como false.

Para obter mais informações, consulte: Recuperar alterações não sincronizadas.

{
  ...
  "sync": {
    "type": "partition",
    "state": "enabled",
    "development_mode_enabled": true,
    "database_name": "my-test-database",
    "partition": {
      ...
    },
    "client_max_offline_days": 30,
    "is_recovery_mode_disabled": false
  }
  ...
}

5

Implemente a configuração de sincronização

Agora que você definiu a configuração de sincronização, incluindo as permissões de leitura e escrita, você pode distribuir suas alterações para começar a sincronizar dados e aplicar regras de sincronização.

Para implementar suas alterações, envie uma solicitação de API de administração que atualize a configuração do cluster com sua configuração de sincronização:

curl https://services.cloud.mongodb.com/api/admin/v3.0/groups/{GROUP_ID}/apps/{APP_ID}/services/{MongoDB_Service_ID}/config \
  -X PATCH \
  -h 'Authorization: Bearer <Valid Access Token>' \
  -d @/sync/config.json

Comportamento da Sincronização baseada em partição

As regras de sincronização aplicam-se a partições específicas e são acopladas ao modelo de dados da sua aplicação pela chave de partição. Considere o seguinte comportamento ao projetar seus esquemas para garantir que você tenha granularidade de acesso aos dados apropriada e não vaze informações confidenciais acidentalmente.

• As regras de sincronização se aplicam dinamicamente com base no usuário. Um usuário pode ter acesso total de leitura e escrita a uma partição, enquanto outro usuário tem apenas permissões de leitura ou não consegue acessar totalmente a partição. Você controla essas permissões definindo expressões JSON.

• As regras de sincronização se aplicam igualmente a todos os objetos em uma partição. Se um usuário tiver permissão de leitura ou gravação para uma determinada partição, ele poderá ler ou modificar todos os campos sincronizados de qualquer objeto na partição.

• As permissões de gravação exigem permissões de leitura, portanto, um usuário com acesso de gravação a uma partição também tem acesso de leitura, independentemente das regras de permissão de leitura definidas.

Permissões de sincronização baseadas em partições

O App Services impõe permissões de leitura e gravação dinâmicas e específicas do usuário para proteger os dados em cada partição. Você define permissões com expressões de regra JSON que controlam se um determinado usuário leu ou gravou acesso aos dados em uma determinada partição. Os Serviços de apps avaliam as permissões de um usuário sempre que abrem um domínio sincronizado.

Conceitos chave

Estratégias de permissão

Você pode estruturar suas expressões de permissão de leitura e gravação como um conjunto de estratégias de permissão que se aplicam à sua estratégia de partição. As estratégias a seguir descrevem abordagens comuns que você pode adotar para definir permissões de leitura, gravação e sincronização para seu aplicativo.

true

false

{ "%%true": true }

{ "%%partition": "PUBLIC" }

{
  "%%partition": {
    "$in": [
      "PUBLIC (NA)",
      "PUBLIC (EMEA)",
      "PUBLIC (APAC)"
    ]
  }
}

{ "%%user.id": "5f4863e4d49bd2191ff1e623" }

{
  "%%user.id": {
    "$in": [
      "5f4863e4d49bd2191ff1e623",
      "5f48640dd49bd2191ff1e624",
      "5f486417d49bd2191ff1e625"
    ]
  }
}

{ "%%user.custom_data.readPartitions" : "%%partition" }

{ "%%user.data.writePartitions" : "%%partition" }

{
  "%%true": {
    "%function": {
      "name": "canReadPartition",
      "arguments": ["%%partition"]
    }
  }
}

// canReadPartition
exports = async (partition) => {
  const cluster = context.services.get("mongodb-atlas");
  const permissions = cluster
    .db("myApp")
    .collection("permissions");
  const { canRead } = await permissions.findOne({ partition });
  return canRead.includes(context.user.id);
}

Migrar regras de sincronização baseada em partição para as regras do App Services

Se você migrar seu aplicativo de Partition-Based Sync para o Flexible Sync, suas regras de acesso a dados também precisarão ser migradas.

Algumas estratégias de Sincronização baseada em partição não podem ser convertidas diretamente em regras do App Services. Talvez seja necessário migrar manualmente as permissões que incluem:

• %function operador.

  Regras de função não são compatíveis com a Flexible Sync e não podem ser migradas.

• %%partition expansão.

  As regras de App Services não têm uma expansão equivalente para %%partition, portanto, não podem ser migradas.

• %or, %not, %nor, %and expansões.

  Essas permissões podem funcionar, mas há nuances suficientes para que você as teste para garantir o comportamento esperado. Testar novas permissões não funcionará no aplicativo que você está migrando. Você precisará de um novo aplicativo para testar as permissões migradas manualmente.

Consulte a lista de expansões compatíveis com Sincronização flexível para todas as expansões suportadas.

Você também deve verificar o Guia de permissões do Device Sync para obter mais informações sobre como trabalhar com permissões.

Estratégia de firehose

Uma estratégia de partição firehose agrupa todos os documentos em uma única partição. Com essa estrutura, todos os usuários sincronizam todos os dados do seu aplicativo em seus dispositivos. Essa abordagem é funcionalmente uma decisão de não fazer a partição de dados. Isso funciona para aplicativos básicos ou pequenos conjuntos de dados públicos.

• Segurança de dados. Todos os dados são públicos para clientes com um domínio que usa a partição. Se um usuário tiver acesso de leitura ou escrita à partição, ele poderá ler ou escrever qualquer documento.

• Capacidade de armazenamento. Cada usuário sincroniza todos os documentos na partição. Todos os dados devem estar dentro da sua limitação de armazenamento mais restritiva. Use essa estratégia somente quando os conjuntos de dados forem pequenos e não aumentarem rapidamente.

Uma maneira de criar uma firehose é definir a chave de partição como um campo opcional. Não inclua um valor para este campo em nenhum documento. O App Services mapeia qualquer documento que não inclua um valor de partição para a partição nula.

Você também pode definir um valor de partição estática. Isso ocorre quando o valor da partição não muda com base no usuário ou nos dados. Por exemplo, regiões em todos os clientes poderiam usar o valor de partição "MyPartitionValue".

collection games: [
  { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... }
  { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... }
  { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... }
  { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... }
  { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... }
  { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... }
]
collection teams: [
  { name: "Brook Ridge Miners" }
  { name: "Southside Rockets" }
  { name: "Uptown Bombers" }
]

realm null: [
  Game { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... }
  Game { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... }
  Game { teams: ["Brook Ridge Miners", "Southside Rockets"], score: { ... }, date: ... }
  Game { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... }
  Game { teams: ["Brook Ridge Miners", "Uptown Bombers"], score: { ... }, date: ... }
  Game { teams: ["Southside Rockets", "Uptown Bombers"], score: { ... }, date: ... }
  Team { name: "Brook Ridge Miners" }
  Team { name: "Southside Rockets" }
  Team { name: "Uptown Bombers" }
]

Estratégia de usuário

Uma estratégia de partição de usuário agrupa documentos privados para cada usuário. Esses documentos vão para uma partição específica desse usuário. Isso funciona quando cada documento tem um proprietário e ninguém mais precisa dos dados. Um nome de usuário ou ID que identifica o proprietário cria uma chave de partição natural.

• Segurança de dados. Os dados em uma partição de usuário são específicos para um determinado usuário. Podem conter informações privadas do usuário. Cada usuário sincroniza apenas sua própria partição. Outros usuários não podem acessar documentos na partição.

• Capacidade de armazenamento. Cada usuário sincroniza apenas dados de sua própria partição. Seus dados devem atender às restrições de armazenamento do dispositivo. Use esta estratégia somente quando cada usuário tiver uma quantidade gerenciável de dados.

collection playlists: [
  { name: "Work", owner_id: "dog_enthusiast_95", song_ids: [ ... ] }
  { name: "Party", owner_id: "cat_enthusiast_92", song_ids: [ ... ] }
  { name: "Soup Tunes", owner_id: "dog_enthusiast_95", song_ids: [ ... ] }
  { name: "Disco Anthems", owner_id: "PUBLIC", song_ids: [ ... ] }
  { name: "Deep Focus", owner_id: "PUBLIC", song_ids: [ ... ] }
]
collection ratings: [
  { owner_id: "dog_enthusiast_95", song_id: 3, rating: -1 }
  { owner_id: "cat_enthusiast_92", song_id: 1, rating: 1 }
  { owner_id: "dog_enthusiast_95", song_id: 1, rating: 1 }
]

realm dog_enthusiast_95: [
  Playlist { name: "Work", owner_id: "dog_enthusiast_95", song_ids: [ ... ] }
  Playlist { name: "Soup Tunes", owner_id: "dog_enthusiast_95", song_ids: [ ... ] }
  Rating { owner_id: "dog_enthusiast_95", song_id: 3, rating: -1 }
  Rating { owner_id: "dog_enthusiast_95", song_id: 1, rating: 1 }
]
realm cat_enthusiast_92: [
  Playlist { name: "Party", owner_id: "cat_enthusiast_92", song_ids: [ ... ] }
  Rating { owner_id: "cat_enthusiast_92", song_id: 1, rating: 1 }
]
realm PUBLIC: [
  Playlist { name: "Disco Anthems", owner_id: "PUBLIC", song_ids: [ ... ] }
  Playlist { name: "Deep Focus", owner_id: "PUBLIC", song_ids: [ ... ] }
]

Estratégia de equipe

Uma estratégia de partição de equipe agrupa documentos privados compartilhados por uma equipe de usuários. Uma equipe pode incluir funcionários de uma loja ou membros de uma banda. Cada equipe tem uma partição específica para esse grupo. Todos os usuários da equipe compartilham acesso e propriedade dos documentos da equipe.

• Segurança de dados. Os dados em uma partição de equipe são específicos da equipe. Eles podem conter dados restritos à equipe, mas não a um membro dela. Cada usuário sincroniza partições com as equipes às quais pertence. Os usuários que não pertencem a uma equipe não podem acessar documentos na partição dela.

• Capacidade de armazenamento: cada usuário só sincroniza dados de suas próprias equipes. Os dados das equipes de um usuário devem se ajustar às restrições de armazenamento do dispositivo. Use essa estratégia quando os usuários pertencerem a um número gerenciável de equipes. Se os usuários pertencem a muitas equipes, os realms combinados podem conter muitos dados. Talvez seja necessário limitar o número de partições da equipe sincronizadas por vez.

collection projects: [
  { name: "CLI", owner_id: "cli-team", task_ids: [ ... ] }
  { name: "API", owner_id: "api-team", task_ids: [ ... ] }
]
collection tasks: [
  { status: "complete", owner_id: "api-team", text: "Import dependencies" }
  { status: "inProgress", owner_id: "api-team", text: "Create app MVP" }
  { status: "inProgress", owner_id: "api-team", text: "Investigate off-by-one issue" }
  { status: "todo", owner_id: "api-team", text: "Write tests" }
  { status: "inProgress", owner_id: "cli-team", text: "Create command specifications" }
  { status: "todo", owner_id: "cli-team", text: "Choose a CLI framework" }
]

realm cli-team: [
  Project { name: "CLI", owner_id: "cli-team", task_ids: [ ... ] }
  Task { status: "inProgress", owner_id: "cli-team", text: "Create command specifications" }
  Task { status: "todo", owner_id: "cli-team", text: "Choose a CLI framework" }
]
realm api-team: [
  Project { name: "API", owner_id: "api-team", task_ids: [ ... ] }
  Task { status: "complete", owner_id: "api-team", text: "Import dependencies" }
  Task { status: "inProgress", owner_id: "api-team", text: "Create app MVP" }
  Task { status: "inProgress", owner_id: "api-team", text: "Investigate off-by-one issue" }
  Task { status: "todo", owner_id: "api-team", text: "Write tests" }
]

Estratégia de canal

Uma estratégia de partição de canal agrupa documentos de um tópico ou domínio comum. Cada tópico ou domínio tem sua própria partição. Os usuários podem optar por acessar ou assinar canais específicos. Um nome ou ID pode identificar esses canais em uma lista pública.

• Segurança de dados. Os dados em uma partição de canal são específicos de um tópico ou área. Os usuários podem optar por acessar esses canais. Você pode limitar o acesso de um usuário a um subconjunto de canais. Você pode impedir que os usuários acessem os canais completamente. Quando o usuário tem permissão de leitura ou escrita para um canal, ele pode acessar qualquer documento na partição.

• Capacidade de armazenamento. Os usuários podem optar por sincronizar dados de qualquer canal permitido. Todos os dados dos canais de um usuário devem se ajustar às restrições de armazenamento do dispositivo. Use essa estratégia para dividir conjuntos de dados públicos ou semiprivados. Essa estratégia divide conjuntos de dados que não se encaixam nas restrições de armazenamento.

collection chatrooms: [
  { topic: "cats", description: "A place to talk about cats" }
  { topic: "sports", description: "We like sports and we don't care who knows" }
]
collection messages: [
  { topic: "cats", text: "Check out this cute pic of my cat!", timestamp: 1625772933383 }
  { topic: "cats", text: "Can anybody recommend a good cat food brand?", timestamp: 1625772953383 }
  { topic: "sports", text: "Did you catch the game last night?", timestamp: 1625772965383 }
  { topic: "sports", text: "Yeah what a comeback! Incredible!", timestamp: 1625772970383 }
  { topic: "sports", text: "I can't believe how they scored that goal.", timestamp: 1625773000383 }
]

realm cats: [
  Chatroom { topic: "cats", description: "A place to talk about cats" }
  Message { topic: "cats", text: "Check out this cute pic of my cat!", timestamp: 1625772933383 }
  Message { topic: "cats", text: "Can anybody recommend a good cat food brand?", timestamp: 1625772953383 }
]
realm sports: [
  Chatroom { topic: "sports", description: "We like sports and we don't care who knows" }
  Message { topic: "sports", text: "Did you catch the game last night?", timestamp: 1625772965383 }
  Message { topic: "sports", text: "Yeah what a comeback! Incredible!", timestamp: 1625772970383 }
  Message { topic: "sports", text: "I can't believe how they scored that goal.", timestamp: 1625773000383 }
]

Estratégia de região

Uma estratégia de partição de região agrupa documentos relacionados a um local ou região. Cada partição contém documentos específicos para essas áreas.

• Segurança de dados. Os dados são específicos para uma determinada área geográfica. Você pode limitar o acesso de um usuário à região atual. Como alternativa, conceda acesso aos dados região por região.

• Capacidade de armazenamento. As necessidades de armazenamento variam dependendo do tamanho e dos padrões de uso da região. Os usuários só podem sincronizar dados em sua própria região. Os dados de qualquer região devem caber nas restrições de armazenamento de um dispositivo. Se os usuários sincronizarem várias regiões, partição em subregiões menores. Isso ajuda a evitar a sincronização de dados desnecessários.

collection restaurants: [
  { city: "New York, NY", name: "Joe's Pizza", menu: [ ... ] }
  { city: "New York, NY", name: "Han Dynasty", menu: [ ... ] }
  { city: "New York, NY", name: "Harlem Taste", menu: [ ... ] }
  { city: "Chicago, IL", name: "Lou Malnati's", menu: [ ... ] }
  { city: "Chicago, IL", name: "Al's Beef", menu: [ ... ] }
  { city: "Chicago, IL", name: "Nando's", menu: [ ... ] }
]

realm New York, NY: [
 { city: "New York, NY", name: "Joe's Pizza", menu: [ ... ] }
 { city: "New York, NY", name: "Han Dynasty", menu: [ ... ] }
 { city: "New York, NY", name: "Harlem Taste", menu: [ ... ] }
]
realm Chicago, IL: [
 { city: "Chicago, IL", name: "Lou Malnati's", menu: [ ... ] }
 { city: "Chicago, IL", name: "Al's Beef", menu: [ ... ]  }
 { city: "Chicago, IL", name: "Nando's", menu: [ ... ]  }
]

Estratégia de bucket

Uma estratégia de partição de bucket agrupa documentos por intervalo. Quando os documentos variam ao longo de uma dimensão, uma partição contém um subintervalo. Considere intervalos de blocos baseados em tempo. Os gatilhos movem documentos para novas partições quando eles estão fora do intervalo de armazenamento.

• Segurança de dados. Limite os usuários a ler ou gravar somente intervalos específicos. Os dados podem fluir entre blocos. Considere acessar permissões para um documento em todos os possíveis blocos.

• Capacidade de armazenamento. As necessidades de armazenamento variam de acordo com o tamanho e os padrões de uso de cada bucket. Considere quais blocos os usuários precisam acessar. Limite o tamanho dos compartimentos para que se ajustem às restrições de armazenamento de um dispositivo. Se os usuários sincronizarem muitos compartimentos, divida-os em compartimentos menores. Isso ajuda a evitar a sincronização de dados desnecessários.

collection readings: [
  { bucket: "0s<t<=60s", timestamp: 1625773000383 , data: { ... } }
  { bucket: "0s<t<=60s", timestamp: 1625772970383 , data: { ... } }
  { bucket: "0s<t<=60s", timestamp: 1625772965383 , data: { ... } }
  { bucket: "60s<t<=300s", timestamp: 1625772953383 , data: { ... } }
  { bucket: "60s<t<=300s", timestamp: 1625772933383 , data: { ... } }
]

realm 0s<t<=60s: [
  Reading { bucket: "0s<t<=60s", timestamp: 1625773000383 , data: { ... } }
  Reading { bucket: "0s<t<=60s", timestamp: 1625772970383 , data: { ... } }
  Reading { bucket: "0s<t<=60s", timestamp: 1625772965383 , data: { ... } }
]
realm 60s<t<=300s: [
  Reading { bucket: "60s<t<=300s", timestamp: 1625772953383 , data: { ... } }
  Reading { bucket: "60s<t<=300s", timestamp: 1625772933383 , data: { ... } }
]