Jump to content
Sign in to follow this  
GrG

Google - High Replication Datastore

Recommended Posts

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?

Share this post


Link to post
Share on other sites

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.

Share this post


Link to post
Share on other sites

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?)

Share this post


Link to post
Share on other sites
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ò

Share this post


Link to post
Share on other sites

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

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
Sign in to follow this  

×