Strutturazione dei dati per una coerenza elevata

Datastore offre alta disponibilità, scalabilità e durabilità distribuendo i dati su molte macchine e utilizzando la replica sincrona senza master su un'ampia area geografica. Tuttavia, un compromesso di questo design è che la velocità effettiva di scrittura per qualsiasi singolo gruppo di entità è limitata a circa un commit al secondo. Esistono inoltre limitazioni per le query o le transazioni che interessano più gruppi di entità. Questa pagina descrive queste limitazioni in modo più dettagliato e illustra le best practice per strutturare i dati in modo da supportare una elevata coerenza, soddisfacendo al contempo i requisiti di throughput in scrittura dell'applicazione.

Livelli di coerenza

Le query del datastore possono restituire i risultati a due livelli di coerenza:

• Le query molto coerenti garantiscono i risultati più aggiornati, ma potrebbero richiedere più tempo per essere completate o potrebbero non essere supportate in alcuni casi.
• Le query coerenti in modo definitivo in genere vengono eseguite più rapidamente, ma a volte possono restituire risultati non aggiornati.

In una query con coerenza finale, anche gli indici utilizzati per raccogliere i risultati vengono acceduti con coerenza finale. Di conseguenza, a volte queste query possono restituire entità che non corrispondono più ai criteri di query e possono anche omettere entità che corrispondono ai criteri di query. Le query a elevata coerenza sono coerenti dal punto di vista transazionale, il che significa che i risultati si basano su un'unica istantanea coerente dei dati.

Garanzie di coerenza

Le query restituiscono i risultati con diversi livelli di garanzia di coerenza, a seconda della loro natura:

• Le query sugli antenati (quelle eseguite su un gruppo di entità) sono fortemente coerenti per impostazione predefinita, ma possono essere rese eventualmente coerenti impostando il criterio per la lettura di Datastore (descritto di seguito).
• Le query globali (quelle che non vengono eseguite su un gruppo di entità) sono sempre eventualmente coerenti.

In molte applicazioni, è accettabile utilizzare la coerenza finale (ovvero una query globale che abbraccia più gruppi di entità, che a volte può restituire dati leggermente obsoleti) per ottenere una visione ampia di dati non correlati e poi utilizzare la elevata coerenza (una query da predecessore#39;antenato o una ricerca di una singola entità) per visualizzare o modificare un singolo insieme di dati altamente correlati. In queste applicazioni, in genere è un buon approccio inserire dati altamente correlati in gruppi di entità. Un numero maggiore di gruppi di entità aumenta la velocità effettiva, mentre un numero inferiore di gruppi di entità aumenta il volume di entità che possono essere lette in una singola query da predecessore sull'antenato. Un'applicazione deve tenerne conto per determinare il giusto equilibrio tra velocità effettiva e coerenza.

Criterio per la lettura Datastore

Per migliorare le prestazioni, puoi impostare i criteri di lettura di una query in modo che i risultati siano eventualmente coerenti. L'API Datastore consente anche di impostare esplicitamente un criterio di elevata coerenza, ma questa impostazione non ha alcun effetto pratico, poiché le query globali sono sempre eventualmente coerenti indipendentemente dal criterio.

Puoi attivare le letture eventualmente coerenti tramite le opzioni di lettura dell'oggetto query:

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

Considerazioni sulle transazioni e sulla coerenza

I commit del datastore sono transazionali, il che significa che vengono eseguiti nel contesto di una transazione e l'insieme di mutazioni della transazione viene applicato per intero o non viene applicato, oppure non transazionali, il che significa che l'insieme di mutazioni potrebbe non essere applicato per intero o non essere applicato.

Una singola transazione può includere un numero qualsiasi di mutazioni di creazione, aggiornamento o eliminazione. Per mantenere la coerenza dei dati, la transazione assicura che tutte le mutazioni in essa contenute vengano applicate a Datastore come un'unità o, se una delle mutazioni non va a buon fine, che nessuna venga applicata. Inoltre, tutte le letture fortemente coerenti (query sugli antenati o operazioni lookup) eseguite all'interno della stessa transazione si basano su un singolo snapshot coerente dei dati. Le query fortemente coerenti devono specificare un filtro antenato. Le query che partecipano a una transazione sono sempre fortemente coerenti. Le transazioni possono coinvolgere al massimo 25 gruppi di entità. Le letture eventualmente coerenti non presentano queste limitazioni e sono adeguate in molti casi. L'utilizzo delle letture eventualmente coerenti può consentire di distribuire i dati tra un numero maggiore di gruppi di entità, in modo da ottenere un maggiore throughput di scrittura eseguendo i commit in parallelo sui diversi gruppi di entità. Tuttavia, devi comprendere le caratteristiche delle letture eventualmente coerenti per determinare se sono adatte alla tua applicazione:

• I risultati di queste letture potrebbero non riflettere le transazioni più recenti. Questo può accadere perché queste letture non garantiscono che la replica su cui vengono eseguite sia aggiornata. Utilizzano invece i dati disponibili sulla replica al momento dell'esecuzione della query.
• Una transazione impegnata che ha interessato più gruppi di entità potrebbe sembrare essere stata applicata ad alcune entità e non ad altre. Tieni però presente che una transazione non verrà mai visualizzata come applicata parzialmente all'interno di una singola entità.
• I risultati della query potrebbero includere entità che non dovevano essere incluse in base ai criteri di filtro ed escludere entità che dovevano essere incluse. Questo può verificarsi perché la versione dello snapshot utilizzata per leggere gli indici potrebbe essere diversa da quella utilizzata per leggere l'entità.

Strutturare i dati per garantire la coerenza

Per capire come strutturare i dati per una elevata coerenza, confronta due approcci diversi per una semplice applicazione di elenco di attività. Il primo approccio crea ogni entità nel proprio nuovo gruppo di entità (ovvero ogni entità è unentità base):

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

Esegue quindi una query sul tipo di entità Task per le attività non ancora completate con priorità maggiore o uguale a 4, ordinate in ordine decrescente per priorità:

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)

Tuttavia, poiché utilizziamo una query eventualmente coerente (anziché una query da predecessore), i risultati della query potrebbero non contenere la nuova entità. Tuttavia, quasi tutte le scritture saranno disponibili per le query eventualmente coerenti poco dopo un commit. Per molte applicazioni, in genere è sufficiente una soluzione che fornisca i risultati di una query eventualmente coerente nel contesto delle modifiche dell'utente corrente per rendere queste latenze completamente accettabili.

Per ottenere una elevata coerenza, è preferibile creare le entità con un percorso dell'antenato. Il percorso dell'antenato identifica l'entità base comune in cui sono raggruppate le entità create. Questo esempio utilizza un percorso di antenato di tipo TaskList denominato 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

Potrai quindi eseguire una query da predecessore'antenato fortemente coerente all'interno del gruppo di entità identificato dall'entità base comune:

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)

Questo approccio garantisce elevata coerenza scrivendo in un singolo gruppo di entità per elenco di attività, ma limita anche le modifiche all'elenco di attività a non più di una scrittura al secondo (il limite supportato per i gruppi di entità). Se è probabile che la tua applicazione abbia un utilizzo più elevato delle scritture, potresti dover prendere in considerazione l'utilizzo di altri mezzi. Ad esempio, se la tua applicazione è un guestbook che consente agli utenti di pubblicare messaggi in una bacheca pubblica, puoi inserire i messaggi recenti in memcache con una scadenza e mostrare un mix di messaggi recenti da memcache e Datastore oppure puoi memorizzarli nella cache in un cookie, inserire uno stato nell'URL o qualcos'altro. L'obiettivo è trovare una soluzione di memorizzazione nella cache che fornisca i dati per l'utente corrente durante il periodo di tempo in cui l'utente pubblica nella tua applicazione. Ricorda che se esegui un lookup, una query da predecessore (supponendo che il criterio per la lettura non sia impostato su eventualmente coerente) o qualsiasi operazione all'interno di una transazione, vedrai sempre i dati scritti più di recente.

Per altri esempi di utilizzo delle transazioni, vai qui.

Limitazioni dei gruppi di entità sulle transazioni

L'organizzazione dei dati in gruppi di entità può limitare le transazioni che possono essere eseguite:

• Tutti i dati a cui accede una transazione devono essere contenuti in massimo 25 gruppi di entità.
• Se vuoi utilizzare le query all'interno di una transazione, i dati devono essere organizzati in gruppi di entità in modo da poter specificare filtri di antenato che corrispondano ai dati corretti.
• Esiste un limite di velocità effettiva di scrittura di circa una transazione al secondo per un singolo gruppo di entità. Questa limitazione esiste perché Datastore esegue la replica sincrona senza master di ogni gruppo di entità su un'ampia area geografica per garantire elevata affidabilità e tolleranza di errori.

Per ulteriori informazioni su come vengono aggiornate le entità e gli indici, consulta l'articolo Isolamento delle transazioni.