2012-11-19 14 views
8

Sono in procinto di migrare un'applicazione da Master/Slave a HRD. Mi piacerebbe sentire alcuni commenti di chi ha già attraversato la migrazione.In pratica, qual è l'eventuale "consistenza finale" in HRD?

  1. ho provato un semplice esempio di inviare solo una nuova entità, senza antenato e reindirizzamento a una pagina per elencare tutte le entità da quel modello. L'ho provato diverse volte ed è stato sempre coerente. Loro metto 500 proprietà indicizzate e di nuovo, sempre coerenti ...

  2. Ero anche preoccupato per alcune affermazioni di un limite di 1 put() per gruppo di entità al secondo. Ho messo() 30 entità con lo stesso antenato (stessa richiesta HTTP ma put() una per una) e sostanzialmente non c'era differenza dal mettere 30 entità senza antenato. (Sto usando NDB, potrebbe essere facendo una sorta di ottimizzazione?)

ho provato questo con un app vuoto senza alcun traffico e mi chiedo quanto un vero e proprio traffico inciderebbe sulla "coerenza eventuale".

Sono consapevole di poter testare "coerenza finale" sullo sviluppo locale. La mia domanda è:

Ho davvero bisogno di ristrutturare la mia app per gestire la coerenza finale?

Oppure sarebbe accettabile lasciarlo così com'è perché la coerenza finale è effettivamente coerente nella pratica per il 99%?

+0

Come hai elencato tutte le entità sotto 1.? –

+1

Cosa fa la tua applicazione? Ci sarebbero effetti visibili, negativi se le tue scritture fossero alla fine coerenti? –

+0

ndb può eseguire il billing automatico del tuo put, vedere https://code.google.com/p/appengine-ndb-experiment/source/browse/ndb/context.py#703 – proppy

risposta

1

Se si dispone di una piccola app, i dati probabilmente si trovano nella stessa parte dello stesso disco e si dispone di un'istanza. Probabilmente non noterai la coerenza finale. Man mano che la tua app cresce, te ne accorgi di più. Di solito ci vogliono millisecondi per raggiungere la coerenza, ma ho visto casi in cui ci vuole un'ora o più.

In genere, le query sono quelle in cui si nota maggiormente. Un modo per ridurre l'impatto è interrogare solo con le chiavi e quindi usare ndb.get_multi() per caricare le entità.Il recupero delle entità tramite chiavi garantisce di ottenere l'ultima versione di tale entità. Tuttavia, non garantisce che l'elenco delle chiavi sia fortemente coerente. Quindi potresti ottenere entità che non corrispondono alle condizioni della query, quindi fai un loop tra le entità e salta quelle che non corrispondono.

Da quanto ho notato, il dolore di un'eventuale coerenza aumenta gradualmente man mano che la tua app cresce. A un certo punto devi prenderlo sul serio e aggiornare le aree critiche del tuo codice per gestirlo.

0

Qual è il caso peggiore se si ottengono risultati incoerenti?

  • Un utente visualizza informazioni non importanti non aggiornate? Probabilmente va bene.

  • Calcolerai qualcosa di importante, come il prezzo di qualcosa? O il numero di articoli in magazzino in un negozio? In tal caso, vorrai evitare quella casualità.

Dall'osservazione solo, sembra che i risultati alla fine coerenti appaiono più come il set di dati diventa più grande, ho il sospetto come i dati è suddiviso su più compresse.

Inoltre, se stai leggendo le tue entità con richieste get() per chiave/id, sarà sempre coerente. Assicurati di eseguire una query per ottenere risultati coerenti alla fine.

0

La velocità di replica dipenderà principalmente dal carico di lavoro del server. In genere su un sistema scaricato il ritardo di replica sarà di millisecondi.

Ma l'idea di "alla fine coerente" è che è necessario scrivere la tua app in modo da non fare affidamento su ciò; qualsiasi ritardo di replica deve essere consentito entro i limiti dell'applicazione.

Problemi correlati