Estructurar datos para una coherencia inmediata

Datastore ofrece alta disponibilidad, escalabilidad y durabilidad distribuyendo los datos en muchas máquinas y usando la replicación síncrona sin maestro en una amplia zona geográfica. Sin embargo, una desventaja de este diseño es que el rendimiento de escritura de cualquier grupo de entidades se limita a aproximadamente una confirmación por segundo. También hay limitaciones en las consultas o transacciones que abarcan varios grupos de entidades. En esta página se describen estas limitaciones con más detalle y se explican las prácticas recomendadas para estructurar los datos de forma que se mantenga una coherencia sólida y, al mismo tiempo, se cumplan los requisitos de rendimiento de escritura de la aplicación.

Niveles de coherencia

Las consultas de Datastore pueden ofrecer sus resultados en dos niveles de coherencia:

• Las consultas fuertemente coherentes garantizan los resultados más actualizados, pero pueden tardar más en completarse o no admitirse en determinados casos.
• Las consultas con coherencia final suelen ejecutarse más rápido, pero en ocasiones pueden devolver resultados obsoletos.

En una consulta de coherencia final, los índices utilizados para recoger los resultados también se acceden con coherencia final. Por lo tanto, es posible que estas consultas devuelvan entidades que ya no coincidan con los criterios de la consulta y que omitan entidades que sí coincidan con ellos. Las consultas de coherencia inmediata son coherentes desde el punto de vista transaccional, lo que significa que los resultados se basan en una sola captura coherente de los datos.

Garantías de coherencia

Las consultas devuelven sus resultados con diferentes niveles de garantía de coherencia, según la naturaleza de la consulta:

• Las consultas de ancestros (las que se ejecutan en un grupo de entidades) son coherentes de forma predeterminada, pero se pueden hacer coherentes con el tiempo si se define la política de lectura de Datastore (que se explica más abajo).
• Las consultas globales (las que no se ejecutan en un grupo de entidades) siempre tienen una coherencia final.

En muchas aplicaciones, se puede usar la coherencia final (es decir, una consulta global que abarca varios grupos de entidades y que, en ocasiones, puede devolver datos ligeramente obsoletos) para obtener una visión general de datos no relacionados y, a continuación, usar la coherencia fuerte (una consulta de ancestro o una búsqueda de una sola entidad) para ver o editar un solo conjunto de datos muy relacionados. En estas aplicaciones, suele ser una buena práctica colocar los datos muy relacionados en grupos de entidades. Si hay más grupos de entidades, aumenta el rendimiento, mientras que, si hay menos, aumenta el volumen de entidades que se pueden leer en una sola consulta de ancestro. Una aplicación debe tenerlo en cuenta para determinar el equilibrio adecuado entre el rendimiento y la coherencia.

Política de lectura de Datastore

Para mejorar el rendimiento, puedes definir la política de lectura de una consulta para que los resultados sean coherentes en última instancia. La API Datastore también te permite definir explícitamente una política de coherencia fuerte, pero este ajuste no tiene ningún efecto práctico, ya que las consultas globales siempre tienen una coherencia eventual, independientemente de la política.

Puedes habilitar las lecturas de coherencia final mediante las opciones de lectura del objeto de consulta:

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

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

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

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

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

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

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)

# 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

Transacciones y consideraciones sobre la coherencia

Las confirmaciones de Datastore son transaccionales, lo que significa que se producen en el contexto de una transacción y que se aplican todas las mutaciones de la transacción o no se aplica ninguna. También pueden ser no transaccionales, lo que significa que es posible que no se apliquen todas las mutaciones o que no se aplique ninguna.

Una sola transacción puede incluir cualquier número de mutaciones de creación, actualización o eliminación. Para mantener la coherencia de los datos, la transacción asegura que todas las mutaciones que contiene se apliquen a Datastore como una unidad o, si falla alguna de las mutaciones, que no se aplique ninguna. Además, todas las lecturas con coherencia fuerte (consultas de ancestros u operaciones lookup) que se realizan en la misma transacción se basan en una única instantánea coherente de los datos. Las consultas con coherencia fuerte deben especificar un filtro de ancestro. Las consultas que participan en una transacción siempre tienen una coherencia sólida. Las transacciones pueden incluir un máximo de 25 grupos de entidades. Las lecturas de coherencia final no tienen esas limitaciones y son adecuadas en muchos casos. Si usas lecturas de coherencia final, podrás distribuir tus datos entre un mayor número de grupos de entidades, lo que te permitirá obtener un mayor rendimiento de escritura ejecutando confirmaciones en paralelo en los diferentes grupos de entidades. Sin embargo, debes conocer las características de las lecturas con coherencia final para determinar si son adecuadas para tu aplicación:

• Los resultados de estas lecturas pueden no reflejar las últimas transacciones. Esto puede ocurrir porque estas lecturas no aseguran que la réplica en la que se ejecutan esté actualizada. En su lugar, usan los datos que estén disponibles en esa réplica en el momento de ejecutar la consulta.
• Una transacción confirmada que abarcaba varios grupos de entidades puede parecer que se ha aplicado a algunas entidades y no a otras. Sin embargo, ten en cuenta que nunca se mostrará que una transacción se ha aplicado parcialmente en una sola entidad.
• Los resultados de la consulta pueden incluir entidades que no deberían haberse incluido según los criterios de filtro y pueden excluir entidades que sí deberían haberse incluido. Esto puede ocurrir porque la versión de la captura utilizada para leer los índices puede ser diferente de la versión de la captura utilizada para leer la entidad.

Estructurar los datos para que sean coherentes

Para saber cómo estructurar tus datos de forma que tengan una coherencia sólida, compara dos enfoques diferentes para una aplicación de lista de tareas sencilla. Con el primer método, cada entidad se crea en su propio grupo de entidades (es decir, cada entidad es una entidad raíz):

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

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(),
}

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();

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

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

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",
    }
)

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

A continuación, consulta el tipo de entidad Task para las tareas que aún no se han completado con prioridades iguales o superiores a 4, ordenadas de forma descendente por prioridad:

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

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

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

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

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

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"]

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

Sin embargo, como estamos usando una consulta de coherencia final (en lugar de una consulta de ancestro), es posible que los resultados de la consulta no contengan la nueva entidad. Sin embargo, casi todas las escrituras estarán disponibles para las consultas de coherencia final poco después de una confirmación. En muchas aplicaciones, una solución que proporcione los resultados de una consulta de coherencia final en el contexto de los cambios del usuario actual suele ser suficiente para que estas latencias sean completamente aceptables.

Para conseguir una coherencia sólida, es mejor crear las entidades con una ruta de ancestro. La ruta de ancestro identifica la entidad raíz común en la que se agrupan las entidades creadas. En este ejemplo se usa una ruta de ancestro de tipo TaskList llamada default:

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"
};

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)

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();

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

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

$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'
    ]
);

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",
    }
)

# 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

Después, podrás realizar una consulta de ancestro con coherencia fuerte en el grupo de entidades identificado por la entidad raíz común:

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

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

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

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

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

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

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)

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

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

Con este enfoque se consigue una gran coherencia escribiendo en un solo grupo de entidades por lista de tareas, pero también se limita el número de cambios que se pueden hacer en la lista de tareas a una escritura por segundo (el límite admitido para los grupos de entidades). Si es probable que tu aplicación tenga un uso de escritura más intenso, puede que tengas que usar otros medios. Por ejemplo, si tu aplicación es un libro de visitas que permite a los usuarios publicar mensajes en un tablón de anuncios público, puedes colocar las publicaciones recientes en memcache con una fecha de vencimiento y mostrar una combinación de publicaciones recientes de memcache y Datastore, o puedes almacenarlas en caché en una cookie, poner algún estado en la URL o hacer otra cosa. El objetivo es encontrar una solución de almacenamiento en caché que proporcione los datos del usuario actual durante el periodo en el que el usuario publique contenido en tu aplicación. Recuerda que, si realizas una lookup, una consulta de ancestro (siempre que la política de lectura no esté definida como de consistencia final) o cualquier operación dentro de una transacción, siempre verás los datos escritos más recientemente.

Para ver más ejemplos de cómo usar las transacciones, consulta este artículo.

Limitaciones de los grupos de entidades en las transacciones

La organización de los datos en grupos de entidades puede limitar las transacciones que se pueden realizar:

• Todos los datos a los que accede una transacción deben estar incluidos en un máximo de 25 grupos de entidades.
• Si quieres usar consultas en una transacción, tus datos deben organizarse en grupos de entidades de forma que puedas especificar filtros de ancestros que coincidan con los datos correctos.
• El límite de rendimiento de escritura es de aproximadamente una transacción por segundo para un solo grupo de entidades. Esta limitación se debe a que Datastore realiza una replicación síncrona sin maestro de cada grupo de entidades en una zona geográfica amplia para ofrecer una alta fiabilidad y tolerancia a fallos.

Para obtener más información sobre cómo se actualizan las entidades y los índices, consulta el artículo Aislamiento de transacciones.