BigTable è lento o sono stupido?

Question

Fondamentalmente ho il classico modello da molti a molti. Un utente, un premio e una mappatura tabella "molti a molti" tra utenti e premi.

Ogni utente ha un ordine di 400 premi e ogni premio viene assegnato a circa 1/2 degli utenti.

Voglio ripetere tutti i premi dell'utente e riassumere i loro punti. In SQL sarebbe un join di tabella tra i molti-a-molti e quindi camminare attraverso ciascuna delle righe. Su una macchina decente con un'istanza MySQL, 400 righe non dovrebbero essere un grosso problema.

Sul motore dell'app vedo circa 10 secondi per fare la somma. La maggior parte del tempo viene speso nel datastore di Google. Ecco le prime righe di cProfile

 
    ncalls tottime percall cumtime percall filename:lineno(function) 
     462 6.291 0.014 6.868 0.015 {google3.apphosting.runtime._apphosting_runtime___python__apiproxy.Wait} 
     913 0.148 0.000 1.437 0.002 datastore.py:524(_FromPb) 
    8212 0.130 0.000 0.502 0.000 datastore_types.py:1345(FromPropertyPb) 
     462 0.120 0.000 0.458 0.001 {google3.net.proto._net_proto___parse__python.MergeFromString} 

Il mio modello di dati è errato? Sto facendo le occhiate sbagliate? È una lacuna che devo affrontare con il caching e il bulkupdating (che sarebbe un vero rompicoglioni).

Answer 1

potrebbe essere un po 'di entrambi ;-)

Se stai facendo 400 query sul tavolo Awards, uno per ogni risultato restituito per una query sulla tabella di mapping, quindi mi aspetto che per essere doloroso . Il limite di 1000 risultati sulle query esiste perché BigTable ritiene che restituire 1000 risultati sia al limite della sua capacità di operare in un tempo ragionevole. In base all'architettura, mi aspetto che le 400 query siano molto più lente della query che restituisce 400 risultati (400 log N vs. (log M) + 400).

La buona notizia è che su GAE, la memcaching di una singola tabella contenente tutti i premi ei relativi valori dei punti è piuttosto semplice (beh, sembrava piuttosto semplice quando guardo i documenti memcache qualche istante prima. necessario per farlo ancora).

Inoltre, se non lo sapevi, for result in query.fetch(1000) è molto più veloce di for result in query e sei limitato a 1000 risultati in entrambi i modi. I vantaggi di quest'ultimo sono (1) potrebbe essere più veloce se si esegue il salvataggio in anticipo e (2) se Google aumenta il limite oltre 1000, ottiene il vantaggio senza un cambio di codice.

Potresti anche avere problemi quando elimini un utente (o un premio). Ho trovato in una prova che potevo eliminare 300 oggetti entro il limite di tempo. Questi oggetti erano più complessi degli oggetti di mappatura, con 3 proprietà e 5 indici (compresi quelli impliciti), mentre la tabella di mappatura probabilmente ha solo 2 proprietà e 2 indici (impliciti). [Modifica: ho appena realizzato che ho fatto questo test prima di sapere che db.delete() può fare una lista, che è probabilmente molto più veloce].

BigTable non fa necessariamente le cose che i database relazionali sono progettati per fare bene. Invece, distribuisce bene i dati attraverso molti nodi. Ma quasi tutti i siti web funzionano bene con un collo di bottiglia su un singolo server db, e quindi non hanno strettamente bisogno della cosa che fa BigTable.

Un'altra cosa: se si eseguono 400 query di datastore su una singola richiesta http, si scoprirà che si colpisce la quota fissa del datastore ben prima di raggiungere la quota fissa della richiesta.Ovviamente se ti trovi bene all'interno di quote o se prima stai colpendo qualcos'altro, questo potrebbe non essere pertinente per la tua app. Ma il rapporto tra le due quote è qualcosa come 8: 1, e prendo questo come un suggerimento su ciò che Google si aspetta che il mio modello di dati sia simile.

Answer 2

Google BigTable eseguito su Google Distributed File System.

I dati sono distribuiti. Forse 400 righe mysql hanno ancora meglio, ma per dati più grandi google BigTable potrebbe essere più veloce.

Penso che questo sia il motivo per cui ci incoraggiano ad usare memcache per renderlo più veloce.

Answer 3

Il mio modello di dati è errato? Sto facendo le ricerche errate?

Sì e sì, ho paura.

Per quanto riguarda il modello di dati, il modo migliore per gestirlo è archiviare la somma rispetto al record Utente e aggiornarla quando un utente ottiene/perde un premio. Non ha davvero senso contare il loro punteggio ogni volta che la maggior parte delle volte rimane invariato. Se si rende l'entità "Utente" di tipo un'entità figlio di "Utente", è possibile aggiornare il punteggio e inserire o eliminare la voce UserAward in una singola transazione atomica, assicurando che il conteggio sia sempre accurato.

onebyone indica che è possibile memorizzare la tabella dei premi. Questa è una buona idea, ma data la quantità limitata di dati, uno ancora migliore è quello di memorizzarlo nella memoria locale. I membri globali persistono tra le richieste HTTP e, poiché presumo che non si aggiorni spesso la tabella dei premi, non è necessario preoccuparsi di invalidare la cache. Basta caricarlo sulla prima richiesta (o persino inserirlo hardcode nella sorgente). Se modifichi l'elenco dei premi, l'implementazione di un nuovo aggiornamento minore reimposterà tutte le istanze, causandone il ricaricamento.

Per le ricerche, tenere presente che un costo notevole delle operazioni di datastore è il tempo di andata e ritorno. Un'operazione get(), che ricerca uno o più record per ID (puoi batch!) Richiede circa 20-40 ms. Una query, tuttavia, richiede circa 160-200 ms. Quindi, il potere della denormalizzazione.

Answer 4

Un importante idioma del motore di app è che lo storage è economico ma il tempo non è mai in eccedenza. Sembra che il modo migliore per fare molte più relazioni nel motore di app sia semplicemente archiviare le informazioni su entrambi i lati. Ad esempio, un utente ha un elenco di premi e ogni premio ha un elenco di utenti. Per cercare tutti i riconoscimenti di un utente, devi semplicemente interrogare la tabella dei premi per un determinato utente.

Questa idea è ben dimostrato qui: Building Scalable Complex Apps

Answer 5

Anche Lei parla di BigTable, penso che si sta implementando un database relazionale SQL sulla nube.

La tua modella va bene, è il modo giusto di fare qualcosa del genere. Non vedo una buona ragione per de-normalizzare gli aggregati sulla tabella degli utenti.

Hai creato indici per unire rapidamente i tavoli. È piuttosto semplice Potrebbe essere necessario disporre di indici BTree per tutti i campi che prevedono l'unione delle tabelle. Non c'è bisogno di indicizzare il campo di aggregazione (che si prende la SUM di). Fondamentalmente entrambe le chiavi esterne della tabella N: N dovrebbero essere indicizzate. Se quelle chiavi esterne si riferiscono alla chiave primaria di altri due tavoli, è sufficiente andare.

Sopra l'ordine di 100 righe, un semplice indice BTree su chiavi esterne può avere un aumento decente e notevole del throughput.

Sto eseguendo un database su CloudSQL in cui alcune tabelle di bordo contengono oltre 2 milioni di record. Solo dopo i 2,5 milioni di record sto considerando un po 'di de-normalizzazione, e anche alcuni indici extra, e ancora aggregando per la SUM. In caso contrario, farei aggiornamenti non necessari al campo SUM ogni volta che vengono aggiunti nuovi record.

Solo quando la tabella superava 1 milione di record, dovevamo considerare l'utilizzo di una replica di lettura.E cioè quando potevamo distinguere tra processi che leggono solo alcune tabelle e non scrivono.

Se si utilizza Django, fare attenzione quando si implementa LIMIT in base alla relativa documentazione; perché è molto fuorviante. Quando si [: 100] (giunzione) su un set di record, non è ciò che si aspetta dall'SQL effettivamente inviato al server SQL. Ho avuto un momento molto difficile capirlo. Django non è una buona opzione quando pianifichi di fare qualcosa che genererà generosamente su larga scala. Ma nell'ordine di 1000 record, andrebbe bene.