Google - High Replication Datastore

[GrG]

Ho ricevuto ieri la notifica da Google: è stato lanciato l'High Replication Datastore, annunciato mesi fa.

L'annuncio è qui Google App Engine Blog: Announcing the High Replication Datastore for App Engine

E' a consistenza eventuale, ma rimane disponibile durante i down ed è istantaneamente replicato tra diversi datacenter. Rimane disponibile l'altro datastore, definito ora master/slave, che soffre di periodi di readonly e potrebbe portare a perdite temporanee di dati in caso di switch di datacenter (out of sync); i dati rimaasti nel vecchio DC vengono resi disponibili per una reintegrazione manuale dopo il recovery.

Choosing a Datastore (Python) - Google App Engine - Google Code Qui c'è una comparazione.

E' interessante perchè anche Amazon ha lanciato una cosa simile. Il loro SimpleDB rimane sempre e comunque in high replication, senza alternative, ma per salvare tempo cpu hanno lanciato da poco le query a consistenza eventuale.

Ora quindi credo sia un passo avanti Amazon. Offre alta replicazione e consistenza strong.

Che ne dite?

[guest]

Che diavolo solo le query a consistenza eventuale?

[Ste]

Quoto, anche io sono interessato al discorso Giorgio se ci sei batti un colpo

[GrG]

Scusate mi era sfuggita la risposta.

SimpleDB di solito prima di leggere qualcosa si assicura che si siano concluse tutte le scritture in corso su quella tabella o row o quello che è. E che la copia sia sincrona. Insomma, leggi l'ultima versione. Questo ha una latenza X.

Per abbattere la latenza si saltano questi "check". Ovvero io me ne frego delle scritture in corso o della sincronizzazione dei nodi, io prendo e leggo la prima cosa che trovo (sapendo comunque che nel giro di pochi secondi i nodi diventano sincroni).

Questo è disastroso in un ecommerce (che difatti sono gli unici sistemi per cui il modello relazionale a consistenza forte secondo me durerà a vita), perchè si può verificare questa situazione:

- Hai UNA copia di un libro
- La vendi ad A
- B fa una ricerca, un nodo non è sincronizzato e gli risulta ancora disponibile quel libro
- B lo compra
- Ho un libro venduto due volte

Ma per molte altre cose funziona da paura. Se ho un indice di ricerca basato su crawler (che quindi già per come è progettato non è in real-time) posso abbattere la latenza di lettura e i costi di cpu time con query simili. Ok forse non leggo proprio gli ultimi ultimi risultati, ma sono molto molto molto più veloce.

Non ho mai fatto test ma non oso immaginare se Google dovesse aspettare la fine di ogni put per fare una ricerca.

[guest]

E' una normare replica non atomica. La stessa di MySQL per intenderci.

[GrG]

Si. A casa mia la abbiamo sempre chiamasta consistenza eventuale e sia Amazon che Google fanno lo stesso quindi non vedo dove sia il problema.

[guest]

Nessun problema, chi ha mai detto che è un problema?
Non avevo idea di cosa fosse questa consistenza eventuale, visto che nemmeno su google ho trovato nulla.

(il termine inglese quale sarebbe?)

[Ste]

Scusate mi era sfuggita la risposta.

SimpleDB di solito prima di leggere qualcosa si assicura che si siano concluse tutte le scritture in corso su quella tabella o row o quello che è. E che la copia sia sincrona. Insomma, leggi l'ultima versione. Questo ha una latenza X.

Per abbattere la latenza si saltano questi "check". Ovvero io me ne frego delle scritture in corso o della sincronizzazione dei nodi, io prendo e leggo la prima cosa che trovo (sapendo comunque che nel giro di pochi secondi i nodi diventano sincroni).

Questo è disastroso in un ecommerce (che difatti sono gli unici sistemi per cui il modello relazionale a consistenza forte secondo me durerà a vita), perchè si può verificare questa situazione:

- Hai UNA copia di un libro
- La vendi ad A
- B fa una ricerca, un nodo non è sincronizzato e gli risulta ancora disponibile quel libro
- B lo compra
- Ho un libro venduto due volte

Ma per molte altre cose funziona da paura. Se ho un indice di ricerca basato su crawler (che quindi già per come è progettato non è in real-time) posso abbattere la latenza di lettura e i costi di cpu time con query simili. Ok forse non leggo proprio gli ultimi ultimi risultati, ma sono molto molto molto più veloce.

Non ho mai fatto test ma non oso immaginare se Google dovesse aspettare la fine di ogni put per fare una ricerca.

Tutto chiaro grazie, per Google se non sbaglio se ne è parlato da poco con l'introduzione di Caffeine, anche io non conoscevo il termine però

[Antonio]

In poche parole hanno implementato in simpledb quello che potevi già fare con Cassandra

[GrG]

Si ma Cassandra non è SaaS e non paghi un euro al mese per tenerlo su se hai un forum da 100 MB.

Ale, ne parlano ovunque, nei due link di sopra e poi http://bit.ly/g197qo

Si parla di Eventually consistent reads, writes, query, in generale eventually consistent database

Tutto chiaro grazie, per Google se non sbaglio se ne è parlato da poco con l'introduzione di Caffeine, anche io non conoscevo il termine però

Non sono sicuro sia la stessa cosa, Caffeine consente di aggiornare i loro indici in frammenti molto più piccoli di prima senza avviare immani processi mapreduce, quest produce dati più aggiornati ma le query son sempre le stesse, sempre eventualmente consistenti

[Antonio]

Si ma Cassandra non è SaaS e non paghi un euro al mese per tenerlo su se hai un forum da 100 MB.

E dove avrei scritto il contrario?

[Ste]

Si ma Cassandra non è SaaS e non paghi un euro al mese per tenerlo su se hai un forum da 100 MB.

Ale, ne parlano ovunque, nei due link di sopra e poi Amazon SimpleDB

Si parla di Eventually consistent reads, writes, query, in generale eventually consistent database



Non sono sicuro sia la stessa cosa, Caffeine consente di aggiornare i loro indici in frammenti molto più piccoli di prima senza avviare immani processi mapreduce, quest produce dati più aggiornati ma le query son sempre le stesse, sempre eventualmente consistenti

No ok, vero, ne parlavano in questo articolo relativo al cambiamento di Google per Caffeine e ora non ricordo per cosa ma si nominava anche questo approccio. Si conosco il passaggio da map/reduce al nuovo metodo...comunque se riesco a rivangare su instapaper posto tutto

[GrG]

Ste mi hai aperto un mondo. Sono un uomo nuovo. Mi sono illuminato e ho perso 5 anni di vecchiaia. Instapaper: Save interesting web pages for reading later mitico. Mi brillano gli occhi.

Antonio: no era per dire che il paragone non sta va su.

Wow.