Strutturazione dei dati per una coerenza elevata

Datastore offre disponibilità elevata, scalabilità e durabilità la distribuzione dei dati su molte macchine e l'uso la replicazione su un'ampia area geografica. Tuttavia, c'è un compromesso progettazione, ovvero la velocità effettiva di scrittura per ogni gruppo di entità è limitato a circa un commit al secondo ed esistono limitazioni per le query o le transazioni che in più gruppi di entità. In questa pagina vengono descritte le limitazioni e illustra le best practice per strutturare i dati in modo da supportare e la coerenza, soddisfacendo al contempo la velocità effettiva di scrittura dell'applicazione i tuoi requisiti.

Le letture altamente coerenti restituiscono sempre i dati correnti e, se eseguite all'interno di un di transazioni, sembreranno provenire da un'unica istantanea coerente. Tuttavia, Le query devono specificare un filtro predecessore per essere partecipano a una transazione e le transazioni possono riguardare al massimo 25 persone giuridiche gruppi. Le letture coerenti alla fine non hanno queste limitazioni e sono adeguato in molti casi. L'utilizzo di letture coerenti alla fine consente di distribuire i dati tra un numero maggiore di gruppi di entità, in modo da di ottenere una velocità effettiva di scrittura maggiore eseguendo i commit in parallelo gruppi di entità diversi. 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 ultime transazioni. Questo accade perché queste letture non garantiscono che la replica su cui vengono eseguite sia aggiornata. Utilizzano invece qualsiasi dato disponibile su quella replica al momento dell'esecuzione della query. La latenza di replica è quasi sempre inferiore a per alcuni secondi.
  • Una transazione impegnata che ha interessato più entità potrebbe sembrare è stato applicato 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 possono includere entità che non dovevano essere incluse in base ai criteri di filtro ed escludere entità che dovevano essere incluse. Questo può accadere perché gli indici potrebbero essere letti a un più elevata rispetto alla lettura dell'entità stessa.

Per capire come strutturare i dati per una coerenza elevata, confronta due approcci diversi per una semplice applicazione guestbook. Il primo approccio crea una nuova entità principale per ogni entità creata:

protected Entity createGreeting(
    DatastoreService datastore, User user, Date date, String content) {
  // No parent key specified, so Greeting is a root entity.
  Entity greeting = new Entity("Greeting");
  greeting.setProperty("user", user);
  greeting.setProperty("date", date);
  greeting.setProperty("content", content);

  datastore.put(greeting);
  return greeting;
}

Esegue quindi una query sul tipo di entità Greeting per i dieci saluti più recenti.

protected List<Entity> listGreetingEntities(DatastoreService datastore) {
  Query query = new Query("Greeting").addSort("date", Query.SortDirection.DESCENDING);
  return datastore.prepare(query).asList(FetchOptions.Builder.withLimit(10));
}

Tuttavia, poiché stai utilizzando una query non predecessore, la replica utilizzata per eseguire la query in questo schema potrebbe non aver visto il nuovo saluto quando l'esecuzione della query. Ciononostante, quasi tutte le scritture saranno disponibili non predecessori entro pochi secondi dal commit. Per molte applicazioni, in genere è sufficiente una soluzione che fornisca i risultati di una query non principale nel contesto delle modifiche dell'utente corrente per rendere completamente accettabili queste latenze di replica.

Se per la tua applicazione è importante l'elevata coerenza, puoi adottare un approccio alternativo scrivere entità con un percorso predecessore che identifica la stessa entità base tra tutte le entità che devono essere lette in un singolo predecessore a elevata coerenza query:

protected Entity createGreeting(
    DatastoreService datastore, User user, Date date, String content) {
  // String guestbookName = "my guestbook"; -- Set elsewhere (injected to the constructor).
  Key guestbookKey = KeyFactory.createKey("Guestbook", guestbookName);

  // Place greeting in the same entity group as guestbook.
  Entity greeting = new Entity("Greeting", guestbookKey);
  greeting.setProperty("user", user);
  greeting.setProperty("date", date);
  greeting.setProperty("content", content);

  datastore.put(greeting);
  return greeting;
}

Potrai quindi eseguire una query da predecessore a elevata coerenza all'interno del gruppo di entità identificato dall'entità radice comune:

protected List<Entity> listGreetingEntities(DatastoreService datastore) {
  Key guestbookKey = KeyFactory.createKey("Guestbook", guestbookName);
  Query query =
      new Query("Greeting", guestbookKey)
          .setAncestor(guestbookKey)
          .addSort("date", Query.SortDirection.DESCENDING);
  return datastore.prepare(query).asList(FetchOptions.Builder.withLimit(10));
}

Questo approccio garantisce una forte coerenza scrivendo in un singolo gruppo di entità per guestbook, ma limita anche le modifiche al guestbook a non più di una scrittura al secondo (il limite supportato per i gruppi di entità). Se la tua applicazione riscontra un maggiore utilizzo in scrittura, valuta l'uso in altri modi: ad esempio, potresti mettere i post recenti in una memcache con una scadenza e visualizzare un mix di post recenti provenienti da memcache e Datastore, oppure li potresti memorizzare nella cache in un cookie, imposta uno stato nell'URL o qualcosa di completamente diverso. L'obiettivo è trovare una soluzione di memorizzazione nella cache che fornisca i dati dell'utente corrente per il periodo di tempo in cui l'utente pubblica nella tua applicazione. Ricorda che, se usi un comando GET, un predecessore query o qualsiasi operazione all'interno di una transazione, vedrai sempre dati scritti di recente.