Questa pagina è stata tradotta dall'API Cloud Translation.

Strutturazione dei dati per una coerenza elevata

Datastore offre elevata disponibilità, scalabilità e durabilità distribuendo i dati su più macchine e utilizzando la replica sincrona senza master su un'ampia area geografica. Tuttavia, un compromesso in questa progettazione è che la velocità effettiva di scrittura per qualsiasi singolo gruppo di entità è limitata a circa un commit al secondo. Esistono anche limitazioni alle query o alle 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 velocità effettiva di scrittura dell'applicazione.

Livelli di coerenza

Le query Datastore possono fornire i risultati a uno dei due livelli di coerenza:

Le query fortemente coerenti garantiscono i risultati più aggiornati, ma potrebbero richiedere più tempo per essere completate o non essere supportate in alcuni casi.
Le query eventualmente coerenti� vengono eseguite in genere più rapidamente, ma a volte potrebbero restituire risultati obsoleti.

In una query con coerenza finale, anche gli indici utilizzati per raccogliere i risultati vengono accessi con coerenza finale. Di conseguenza, queste query a volte potrebbero restituire entità che non corrispondono più ai criteri della query e potrebbero anche omettere entità che corrispondono ai criteri della 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 natura della query:

Le query predecessore (quelle eseguite su un gruppo di entità) sono fortemente coerenti per impostazione predefinita, ma possono essere rese coerenti alla fine impostando il criterio per la lettura Datastore (illustrato di seguito).
Le query globali (quelle che non vengono eseguite su un gruppo di entità) sono sempre coerenti nel tempo.

In molte applicazioni, è accettabile utilizzare la coerenza finale (ad es. una query globale che interessa più gruppi di entità, che a volte può restituire dati leggermente obsoleti) quando si ottiene una visione generale di dati non correlati e quindi utilizzare la elevata coerenza (una query da predecessore o una ricerca di una singola entità) quando si visualizza o modifica un singolo insieme di dati altamente correlati. In queste applicazioni, in genere è un buon approccio inserire i dati strettamente correlati nei 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. Un'applicazione deve tenerne conto per determinare il giusto equilibrio tra velocità effettiva e coerenza.

Criterio per la lettura di Datastore

Per migliorare il rendimento, puoi impostare il criterio di lettura di una query in modo che i risultati siano coerenti nel tempo. L'API Datastore consente anche di impostare esplicitamente una policy di elevata coerenza, ma questa impostazione non ha alcun effetto pratico, poiché le query globali sono sempre coerenti alla fine, indipendentemente dalla policy.

Puoi abilitare le letture alla fine coerenti tramite le opzioni di lettura dell'oggetto query:

C#

Per scoprire come installare e utilizzare la libreria client per Cloud Datastore, consulta Librerie client di Cloud Datastore. Per saperne di più, consulta la documentazione di riferimento dell'API Cloud Datastore C#.

Per eseguire l'autenticazione in Cloud Datastore, configura le Credenziali predefinite dell'applicazione. Per ulteriori informazioni, consulta Configura l'autenticazione per un ambiente di sviluppo locale.

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

Transazioni e considerazioni sulla coerenza

I commit di Datastore sono transazionali, il che significa che avvengono nel contesto di una transazione e l'insieme di mutazioni della transazione viene applicato interamente o non viene applicato affatto, oppure non transazionali, il che significa che l'insieme di mutazioni potrebbe non essere applicato interamente o non essere applicato affatto.

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

I risultati di queste letture potrebbero non riflettere le transazioni più recenti. Ciò può verificarsi perché queste letture non garantiscono che la replica su cui vengono eseguite sia aggiornata. Utilizzano invece i dati disponibili nella replica al momento dell'esecuzione della query.
Una transazione di cui è stato eseguito il commit che ha interessato più gruppi di entità potrebbe sembrare applicata ad alcune entità e non ad altre. Tieni presente, tuttavia, 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 avrebbero dovuto essere incluse in base ai criteri di filtro e potrebbero escludere entità che avrebbero dovuto essere incluse. Ciò 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 la coerenza

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

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

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 di priorità:

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)

Tuttavia, poiché utilizziamo una query coerente alla fine (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 con coerenza finale poco dopo un commit. Per molte applicazioni, una soluzione che fornisce i risultati di una query coerente nel contesto delle modifiche dell'utente corrente sarà in genere sufficiente a rendere queste latenze completamente accettabili.

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

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

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)

Questo approccio garantisce una elevata coerenza scrivendo in un singolo gruppo di entità per ogni 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 la tua applicazione probabilmente incontrerà un utilizzo di scrittura più intenso, 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 su una bacheca pubblica, potresti inserire i post recenti in memcache con una scadenza e visualizzare un mix di post recenti da memcache e Datastore oppure potresti memorizzarli nella cache in un cookie, inserire uno stato nell'URL o fare 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 contenuti nella tua applicazione. Ricorda che se esegui una lookup, una query da predecessore (supponendo che la criterio per la lettura non sia impostata su coerenza finale) o qualsiasi operazione all'interno di una transazione, vedrai sempre i dati scritti più di recente.

Per altri esempi di come utilizzare le transazioni, vai qui.

Limitazioni dei gruppi di entità per le 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 al massimo 25 gruppi di entità.
Se vuoi utilizzare le query all'interno di una transazione, i tuoi dati devono essere organizzati in gruppi di entità in modo da poter specificare i filtri predecessore che corrispondono 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 agli errori.

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

Strutturazione dei dati per una coerenza elevata Mantieni tutto organizzato con le raccolte Salva e classifica i contenuti in base alle tue preferenze.

Livelli di coerenza

Garanzie di coerenza

Criterio per la lettura di Datastore

C#

Go

Java

Node.js

PHP

Python

Ruby

Transazioni e considerazioni sulla coerenza

Strutturare i dati per la coerenza

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

Limitazioni dei gruppi di entità per le transazioni

Strutturazione dei dati per una coerenza elevata