50/50 inserti e seleziona. Creare due tabelle o una tabella

Question

Ora le strutture delle tabelle proposte sono: -

data_table
->impressions
->clicks
->ctr

o

data_table_1
->ctr

data_table_2
->impressions
->clicks

Quali query vengono eseguite? Ci sono circa 500 aggiornamenti al secondo per le impressioni. V'è di circa 1 aggiornamento per i clic ogni secondo. Ci sono circa 500 aggiornamenti al secondo per il ctr.

Ora la mia domanda ordina i dati utilizzando il ctr. Il CTR è la percentuale di clic che viene elaborato dal ctr = clicks/impressions. Ora ho capito che se non c'è un update Clicca il CTR non ha bisogno di aggiornamento, come tutte le impressioni per articoli vengono aumentati, che sta diminuendo il ctr nello stesso rapporto, quindi a meno che ci sia un clic il CTR non ha bisogno di essere aggiornati.

Al momento la query di aggiornamento è come "impressioni UPDATE data_table SET = impressioni + 1, CTR = clic / impressioni in cui qualcosa = qualcosa

Ciò significa che anche 2 campi vengono aggiornati contemporaneamente solo 1 query viene eseguita.

Ora il collo di bottiglia è che questi 500 gli aggiornamenti su questo causando rallentamento su seleziona su questo tavolo. Ci sono circa 20 seleziona per secondo. Così ho pensato di separare i tavoli. Il nuovo stile di tabella propone che gli aggiornamenti avvengono su un tavolo separato e le seleziona avvengono su un tavolo separato. La tabella dei dati che contiene le impressioni viene aggiornato molto frequentemente in modo da avere gli aggiornamenti per le impressioni eseguite su di essa in realtà accelera le prestazioni in questa tabella. Ciò significa che le seleziona sul data_table_2 sarà troppo veloce e il CTR può essere aggiornato ogni volta che qualcuno fa un clic.

Quindi, volevo solo sapere se devo usare la nuova struttura della tabella o no. Quali sono le possibilita? Pro e contro di mie proposte!

Answer 1

Forse questa non è una risposta diretta alla sua domanda, ma penso che sia importante da notare.

Penso che si dovrebbe considerare l'utilizzo di database NoSQL come Redis, MemcacheDB, MongDB, CouchDB. DBMS Relatational non sono adatti per questo tipo di utilizzo. Ad esempio, ogni volta che si aggiorna qualsiasi colonna (UPDATE data_table SET impressions = impressions + 1) le cache vengono cancellati, e il DB deve colpire il disco.

Altri pensano che si può considerare sta usando Memcache e alla rinfusa che i dati su disco dopo un certo periodo di tempo.

Ad esempio, se si può permettere di perdere alcuni impresions (ricordiamo che memcache non persiste dati) si possono fare le impresions ++ in memcache e aggiornare i dati nel DB ogni 5 minuti. Sarebbe ridurre in modo significativo il carico.

Spero che ti aiuta.

Modifica :

Memorizzazione CTR è una buona idea, si chiama "Denormalizzazione", e può funzionare nella vostra applicazione, se si tratta di un valore richiesto di frequente.

Answer 2

Innanzitutto, assumo la tabella è ben indicizzato così il predicato something = something risulterà rapidamente nella riga corrispondente, giusto?

Inoltre supponendo che il collo di bottiglia è il disco-throughput a causa della elevata velocità di aggiornamento, quello di non memorizzare il valore ctr a tutti, in quanto può essere facilmente calcolato al volo? Dal momento che ti sembra di essere limitato da l'aggiornamento, solo aggiornando un campo deve circa la metà l'impatto di dover scrivere i dati sul disco. Dato tale scenario, in cui la CPU è probabilmente relativamente inattivo, il calcolo click / impressioni per ogni risultato dovrebbe essere un non-problema. Il vostro approccio potrebbe pagare (sempre assumendo che del disco è il fattore limitante, che assumere è e può essere trovato con facilità, cercando in utilizzo della CPU), allora il vostro approccio darà notevoli benefici, se e solo se le tabelle o su due dischi diversi.

Se la CPU risulta essere il fattore limitante, allora è probabilmente perché il predicato something = something è abbastanza complicato per valutare, nel qual caso semplificando questa dovrebbe essere la principale preoccupazione, e non dividere le tabelle.