Esta página foi traduzida pela API Cloud Translation.

Estruturar dados para uma consistência forte

O Datastore oferece alta disponibilidade, escalabilidade e durabilidade através da distribuição de dados por várias máquinas e da utilização da replicação síncrona sem mestre numa vasta área geográfica. No entanto, uma desvantagem neste design é que o débito de gravação para qualquer grupo de entidades está limitado a cerca de uma confirmação por segundo. Também existem limitações nas consultas ou transações que abrangem vários grupos de entidades. Esta página descreve estas limitações mais detalhadamente e aborda as práticas recomendadas para estruturar os seus dados de forma a suportar uma forte consistência, ao mesmo tempo que cumpre os requisitos de débito de gravação da sua aplicação.

Níveis de consistência

As consultas da Datastore podem fornecer os respetivos resultados em qualquer um dos dois níveis de consistência:

As consultas fortemente consistentes garantem os resultados mais atualizados, mas podem demorar mais tempo a serem concluídas ou podem não ser suportadas em determinados casos.
As consultas eventualmente consistentes são geralmente executadas mais rapidamente, mas podem, ocasionalmente, devolver resultados desatualizados.

Numa consulta eventualmente consistente, os índices usados para recolher os resultados também são acedidos com consistência eventual. Consequentemente, estas consultas podem, por vezes, devolver entidades que já não correspondem aos critérios da consulta e também podem omitir entidades que correspondem aos critérios da consulta. As consultas fortemente consistentes são transacionalmente consistentes, o que significa que os resultados se baseiam num único instantâneo consistente dos dados.

Garantias de consistência

As consultas devolvem os respetivos resultados com diferentes níveis de garantia de consistência, consoante a natureza da consulta:

As consultas de antepassados (as que são executadas em relação a um grupo de entidades) são fortemente consistentes por predefinição, mas podem ser tornadas eventualmente consistentes definindo a política de leitura do Datastore (abordada abaixo).
As consultas globais (as que não são executadas em relação a um grupo de entidades) são sempre eventualmente consistentes.

Em muitas aplicações, é aceitável usar a consistência eventual (ou seja, uma consulta global que abranja vários grupos de entidades, que, por vezes, pode devolver dados ligeiramente desatualizados) quando obtém uma vista geral de dados não relacionados e, em seguida, usar a consistência forte (uma consulta de antepassados ou uma pesquisa de uma única entidade) quando visualiza ou edita um único conjunto de dados altamente relacionados. Em tais aplicações, é normalmente uma boa abordagem colocar dados altamente relacionados em grupos de entidades. Um número mais elevado de grupos de entidades aumenta o débito, enquanto um número mais baixo de grupos de entidades aumenta o volume de entidades que podem ser lidas numa única consulta de antepassados. Uma aplicação tem de ter isto em conta para determinar o equilíbrio certo entre o débito e a consistência.

Política de leitura da base de dados

Para melhorar o desempenho, pode definir a política de leitura de uma consulta para que os resultados sejam eventualmente consistentes. (A API Datastore também lhe permite definir explicitamente uma política de consistência forte, mas esta definição não tem efeito prático, uma vez que as consultas globais são sempre eventualmente consistentes, independentemente da política.)

Pode ativar leituras eventualmente consistentes através das opções de leitura do objeto de consulta:

C#

Para saber como instalar e usar a biblioteca cliente do Cloud Datastore, consulte as bibliotecas cliente do Cloud Datastore. Para mais informações, consulte a documentação de referência da API C# Cloud Datastore.

Para se autenticar no Cloud Datastore, configure as Credenciais padrão da aplicação. Para mais informações, consulte o artigo Configure a autenticação para um ambiente de desenvolvimento local.

Query query = new Query("Task")
{
    Filter = Filter.HasAncestor(_db.CreateKeyFactory("TaskList")
        .CreateKey(keyName))
};
var results = _db.RunQuery(query,
    ReadOptions.Types.ReadConsistency.Eventual);

Go

ancestor := datastore.NameKey("TaskList", "default", nil)
query := datastore.NewQuery("Task").Ancestor(ancestor).EventualConsistency()

Java

Query<Entity> query =
    Query.newEntityQueryBuilder()
        .setKind("Task")
        .setFilter(
            PropertyFilter.hasAncestor(
                datastore.newKeyFactory().setKind("TaskList").newKey("default")))
        .build();
datastore.run(query, ReadOption.eventualConsistency());

Node.js

const ancestorKey = datastore.key(['TaskList', 'default']);
const query = datastore.createQuery('Task').hasAncestor(ancestorKey);

query.run({consistency: 'eventual'});

PHP

$query = $datastore->query()
    ->kind('Task')
    ->hasAncestor($datastore->key('TaskList', 'default'));
$result = $datastore->runQuery($query, ['readConsistency' => 'EVENTUAL']);

Python

from google.cloud import datastore

# For help authenticating your client, visit
# https://cloud.google.com/docs/authentication/getting-started
client = datastore.Client()

query = client.query(kind="Task")
query.fetch(eventual=True)

Ruby

# task_list_name = "default"
ancestor_key = datastore.key "TaskList", task_list_name

query = datastore.query("Task")
                 .ancestor(ancestor_key)

tasks = datastore.run query, consistency: :eventual

Transações e considerações de consistência

As confirmações do Datastore são transacionais, o que significa que ocorrem no contexto de uma transação e o conjunto de mutações da transação é aplicado na totalidade ou não é aplicado, ou não transacionais, o que significa que o conjunto de mutações pode não ser aplicado na totalidade ou não ser aplicado.

Uma única transação pode incluir qualquer número de mutações de criação, atualização ou eliminação. Para manter a consistência dos dados, a transação garante que todas as mutações que contém são aplicadas ao Datastore como uma unidade ou, se alguma das mutações falhar, que nenhuma delas é aplicada. Além disso, todas as leituras fortemente consistentes (consultas de antecessores ou operações lookup) realizadas na mesma transação baseiam-se numa única imagem consistente dos dados. As consultas fortemente consistentes têm de especificar um filtro de antepassados. As consultas que participam numa transação são sempre fortemente consistentes. As transações podem envolver, no máximo, 25 grupos de entidades. As leituras eventualmente consistentes não têm essas limitações e são adequadas em muitos casos. A utilização de leituras eventualmente consistentes pode permitir-lhe distribuir os seus dados por um número maior de grupos de entidades, o que lhe permite obter um maior débito de gravação executando confirmações em paralelo nos diferentes grupos de entidades. No entanto, tem de compreender as características das leituras eventualmente consistentes para determinar se são adequadas para a sua aplicação:

Os resultados destas leituras podem não refletir as transações mais recentes. Isto pode ocorrer porque estas leituras não garantem que a réplica na qual estão a ser executadas está atualizada. Em alternativa, usam os dados disponíveis nessa réplica no momento da execução da consulta.
Uma transação comprometida que abrangeu vários grupos de entidades pode parecer ter sido aplicada a algumas das entidades e não a outras. No entanto, tenha em atenção que uma transação nunca vai parecer ter sido aplicada parcialmente numa única entidade.
Os resultados da consulta podem incluir entidades que não deveriam ter sido incluídas de acordo com os critérios de filtro e podem excluir entidades que deveriam ter sido incluídas. Isto pode ocorrer porque a versão da imagem instantânea usada para ler os índices pode diferir da versão da imagem instantânea usada para ler a entidade.

Estruturar os dados para garantir a consistência

Para compreender como estruturar os seus dados para uma forte consistência, compare duas abordagens diferentes para uma aplicação de lista de tarefas simples. A primeira abordagem cria cada entidade no seu próprio novo grupo de entidades (ou seja, cada entidade é uma entidade raiz):

C#

Entity task = new Entity()
{
    Key = _db.CreateKeyFactory("Task").CreateKey("sampleTask"),
    ["category"] = "Personal",
    ["done"] = false,
    ["priority"] = 4,
    ["description"] = "Learn Cloud Datastore"
};

Go

type Task struct {
	Category        string
	Done            bool
	Priority        float64
	Description     string `datastore:",noindex"`
	PercentComplete float64
	Created         time.Time
}
task := &Task{
	Category:        "Personal",
	Done:            false,
	Priority:        4,
	Description:     "Learn Cloud Datastore",
	PercentComplete: 10.0,
	Created:         time.Now(),
}

Java

Key taskKey = datastore.newKeyFactory().setKind("Task").newKey("sampleTask");
Entity task =
    Entity.newBuilder(taskKey)
        .set("category", "Personal")
        .set("done", false)
        .set("priority", 4)
        .set("description", "Learn Cloud Datastore")
        .build();

Node.js

const task = {
  category: 'Personal',
  done: false,
  priority: 4,
  description: 'Learn Cloud Datastore',
};

PHP

$task = $datastore->entity('Task', [
    'category' => 'Personal',
    'done' => false,
    'priority' => 4,
    'description' => 'Learn Cloud Datastore'
]);

Python

from google.cloud import datastore

# For help authenticating your client, visit
# https://cloud.google.com/docs/authentication/getting-started
client = datastore.Client()

task = datastore.Entity(client.key("Task"))
task.update(
    {
        "category": "Personal",
        "done": False,
        "priority": 4,
        "description": "Learn Cloud Datastore",
    }
)

Ruby

task = datastore.entity "Task" do |t|
  t["category"] = "Personal"
  t["done"] = false
  t["priority"] = 4
  t["description"] = "Learn Cloud Datastore"
end

Em seguida, consulta o tipo de entidade Task para as tarefas que ainda não foram concluídas com prioridades iguais ou superiores a 4, ordenadas por ordem decrescente de prioridade:

C#

Query query = new Query("Task")
{
    Filter = Filter.And(Filter.Equal("done", false),
        Filter.GreaterThanOrEqual("priority", 4)),
    Order = { { "priority", PropertyOrder.Types.Direction.Descending } }
};

Go

query := datastore.NewQuery("Task").
	FilterField("Done", "=", false).
	FilterField("Priority", ">=", 4).
	Order("-Priority")

Java

Query<Entity> query =
    Query.newEntityQueryBuilder()
        .setKind("Task")
        .setFilter(
            CompositeFilter.and(
                PropertyFilter.eq("done", false), PropertyFilter.ge("priority", 4)))
        .setOrderBy(OrderBy.desc("priority"))
        .build();

Node.js

const query = datastore
  .createQuery('Task')
  .filter(
    and([
      new PropertyFilter('done', '=', false),
      new PropertyFilter('priority', '>=', 4),
    ]),
  )
  .order('priority', {
    descending: true,
  });

PHP

$query = $datastore->query()
    ->kind('Task')
    ->filter('done', '=', false)
    ->filter('priority', '>=', 4)
    ->order('priority', Query::ORDER_DESCENDING);

Python

from google.cloud import datastore

# For help authenticating your client, visit
# https://cloud.google.com/docs/authentication/getting-started
client = datastore.Client()

query = client.query(kind="Task")
query.add_filter(filter=datastore.query.PropertyFilter("done", "=", False))
query.add_filter(filter=datastore.query.PropertyFilter("priority", ">=", 4))
query.order = ["-priority"]

Ruby

query = datastore.query("Task")
                 .where("done", "=", false)
                 .where("priority", ">=", 4)
                 .order("priority", :desc)

No entanto, como estamos a usar uma consulta eventualmente consistente (em vez de uma consulta de antepassados), os resultados da consulta podem não conter a nova entidade. No entanto, quase todas as escritas estarão disponíveis para consultas eventualmente consistentes pouco depois de uma confirmação. Para muitas aplicações, uma solução que forneça os resultados de uma consulta eventualmente consistente no contexto das alterações do utilizador atual é geralmente suficiente para tornar essas latências totalmente aceitáveis.

Para alcançar uma consistência forte, uma melhor abordagem é criar as entidades com um caminho de antepassado. O caminho de antepassados identifica a entidade raiz comum na qual as entidades criadas estão agrupadas. Este exemplo usa um caminho de antepassado do tipo TaskList denominado default:

C#

Key taskListKey = _db.CreateKeyFactory("TaskList").CreateKey(TestUtil.RandomName());
Key taskKey = new KeyFactory(taskListKey, "Task").CreateKey("sampleTask");
Entity task = new Entity()
{
    Key = taskKey,
    ["category"] = "Personal",
    ["done"] = false,
    ["priority"] = 4,
    ["description"] = "Learn Cloud Datastore"
};

Go

parentKey := datastore.NameKey("TaskList", "default", nil)
key := datastore.IncompleteKey("Task", parentKey)

task := Task{
	Category:    "Personal",
	Done:        false,
	Priority:    4,
	Description: "Learn Cloud Datastore",
}

// A complete key is assigned to the entity when it is Put.
var err error
key, err = client.Put(ctx, key, &task)

Java

Key taskKey =
    datastore
        .newKeyFactory()
        .addAncestors(PathElement.of("TaskList", "default"))
        .setKind("Task")
        .newKey("sampleTask");
Entity task =
    Entity.newBuilder(taskKey)
        .set("category", "Personal")
        .set("done", false)
        .set("priority", 4)
        .set("description", "Learn Cloud Datastore")
        .build();

Node.js

const taskKey = datastore.key([
  'TaskList',
  'default',
  'Task',
  'sampleTask',
]);

const task = {
  key: taskKey,
  data: {
    category: 'Personal',
    done: false,
    priority: 4,
    description: 'Learn Cloud Datastore',
  },
};

PHP

$parentKey = $datastore->key('TaskList', 'default');
$key = $datastore->key('Task')->ancestorKey($parentKey);
$task = $datastore->entity(
    $key,
    [
        'Category' => 'Personal',
        'Done' => false,
        'Priority' => 4,
        'Description' => 'Learn Cloud Datastore'
    ]
);

Python

from google.cloud import datastore

# For help authenticating your client, visit
# https://cloud.google.com/docs/authentication/getting-started
client = datastore.Client()

key_with_parent = client.key("TaskList", "default", "Task", "sampleTask")

task = datastore.Entity(key=key_with_parent)

task.update(
    {
        "category": "Personal",
        "done": False,
        "priority": 4,
        "description": "Learn Cloud Datastore",
    }
)

Ruby

# task_list_name = "default"
# task_name = "sampleTask"
task_key = datastore.key [["TaskList", task_list_name], ["Task", task_name]]

task = datastore.entity task_key do |t|
  t["category"] = "Personal"
  t["done"] = false
  t["priority"] = 4
  t["description"] = "Learn Cloud Datastore"
end

Em seguida, pode executar uma consulta de antepassados fortemente consistente no grupo de entidades identificado pela entidade raiz comum:

C#

Query query = new Query("Task")
{
    Filter = Filter.HasAncestor(_db.CreateKeyFactory("TaskList")
        .CreateKey(keyName))
};

Go

ancestor := datastore.NameKey("TaskList", "default", nil)
query := datastore.NewQuery("Task").Ancestor(ancestor)

Java

Query<Entity> query =
    Query.newEntityQueryBuilder()
        .setKind("Task")
        .setFilter(
            PropertyFilter.hasAncestor(
                datastore.newKeyFactory().setKind("TaskList").newKey("default")))
        .build();

Node.js

const ancestorKey = datastore.key(['TaskList', 'default']);

const query = datastore.createQuery('Task').hasAncestor(ancestorKey);

PHP

$ancestorKey = $datastore->key('TaskList', 'default');
$query = $datastore->query()
    ->kind('Task')
    ->hasAncestor($ancestorKey);

Python

from google.cloud import datastore

# For help authenticating your client, visit
# https://cloud.google.com/docs/authentication/getting-started
client = datastore.Client()

# Query filters are omitted in this example as any ancestor queries with a
# non-key filter require a composite index.
ancestor = client.key("TaskList", "default")
query = client.query(kind="Task", ancestor=ancestor)

Ruby

# task_list_name = "default"
ancestor_key = datastore.key "TaskList", task_list_name

query = datastore.query("Task")
                 .ancestor(ancestor_key)

Esta abordagem alcança uma forte consistência escrevendo num único grupo de entidades por lista de tarefas, mas também limita as alterações à lista de tarefas a não mais de 1 escrita por segundo (o limite suportado para grupos de entidades). Se a sua aplicação tiver provavelmente uma utilização de escrita mais intensa, pode ter de considerar usar outros meios. Por exemplo, se a sua aplicação for um livro de visitas que permite aos utilizadores publicar mensagens num fórum público, pode colocar publicações recentes na memcache com uma data de validade e apresentar uma combinação de publicações recentes da memcache e do Datastore, ou pode colocá-las em cache num cookie, colocar algum estado no URL ou algo completamente diferente. O objetivo é encontrar uma solução de colocação em cache que forneça os dados do utilizador atual durante o período em que o utilizador está a publicar na sua aplicação. Lembre-se de que, se fizer uma lookup, uma consulta de antepassados (partindo do princípio de que a política de leitura não está definida como eventualmente consistente) ou qualquer operação numa transação, verá sempre os dados escritos mais recentemente.

Para ver exemplos adicionais de como usar transações, aceda aqui.

Limitações do grupo de entidades nas transações

A organização dos dados em grupos de entidades pode limitar as transações que podem ser realizadas:

Todos os dados acedidos por uma transação têm de estar contidos num máximo de 25 grupos de entidades.
Se quiser usar consultas numa transação, os seus dados têm de estar organizados em grupos de entidades de forma que possa especificar filtros de antecessores que correspondam aos dados certos.
Existe um limite de débito de gravação de cerca de uma transação por segundo para um único grupo de entidades. Esta limitação existe porque o Datastore executa a replicação síncrona sem mestre de cada grupo de entidades numa vasta área geográfica para oferecer elevada fiabilidade e tolerância a falhas.

Para mais informações sobre como as entidades e os índices são atualizados, consulte o artigo Isolamento de transações.

Estruturar dados para uma consistência forte Mantenha tudo organizado com as coleções Salve e categorize o conteúdo com base nas suas preferências.

Níveis de consistência

Garantias de consistência

Política de leitura da base de dados

C#

Go

Java

Node.js

PHP

Python

Ruby

Transações e considerações de consistência

Estruturar os dados para garantir a consistência

C#

Go

Java

Node.js

PHP

Python

Ruby

C#

Go

Java

Node.js

PHP

Python

Ruby

C#

Go

Java

Node.js

PHP

Python

Ruby

C#

Go

Java

Node.js

PHP

Python

Ruby

Limitações do grupo de entidades nas transações

Estruturar dados para uma consistência forte