2016-02-17 13 views
5

sto creando il seguente schema:Perché ci vuole così tanto tempo per creare un tavolo?

CREATE TABLE stats_by_site_tracking_hourly (
    d_tally text, -- 2016-02 
    d_date timestamp, -- 2016-02-01 13 
    site_id int, 
    is_new_member int, -- 1/0 
    device text, -- desktop/tablet/mobile/unknown 
    tracking_medium text, 
    tracking_source text, 
    tracking_campaign text, 
    tracking_term text, 
    accepted counter, 
    adjusted_accepted counter, 
    rejected counter, 
    adjusted_rejected counter, 
    error counter, 
    impressions_positive counter, 
    adjusted_impressions_positive counter, 
    impressions_negative counter, 
    adjusted_impressions_negative counter, 
    revenue counter, 
    adjusted_revenue counter, 
    reversals_rejected counter, 
    reversals_revenue counter, 
    PRIMARY KEY ((d_tally), site_id, d_date, is_new_member, device, tracking_medium, tracking_source, tracking_campaign, tracking_term) 
); 

Quando eseguo la dichiarazione, sembra che le prime colonne sono trattati rapidamente tuttavia quando si muove sulle colonne contatore rallenta sempre di più per ogni colonna.

Ho lasciato questa istruzione in esecuzione per 5 minuti e non è ancora stata completata.

Qualcuno può offrire qualche approfondimento su questo comportamento?


This è ciò CQLSH assomiglia come viene creata la tabella, e quando la schermata è stata presa non aveva progredito per 20 minuti o giù di lì.


Ho appena messo il comando di creazione tabella in una riga e ha funzionato all'istante.

CREATE TABLE stats_by_site_tracking_hourly (d_tally text, d_date timestamp, site_id int, is_new_member int, device text, tracking_medium text, tracking_source text, tracking_campaign text, tracking_term text, accepted counter, adjusted_accepted counter, rejected counter, adjusted_rejected counter, error counter, impressions_positive counter, adjusted_impressions_positive counter, impressions_negative counter, adjusted_impressions_negative counter, revenue counter, adjusted_revenue counter, reversals_rejected counter, reversals_revenue counter, PRIMARY KEY ((d_tally), site_id, d_date, is_new_member, device, tracking_medium, tracking_source, tracking_campaign, tracking_term)); 
+0

"sembra che le prime poche colonne vengano elaborate rapidamente, tuttavia quando si sposta sulle colonne contatore rallenta sempre di più per ogni colonna" -> come è stato misurato il progresso della creazione dello schema? – doanduyhai

+0

Quando copio lo schema in cqlsh, incolla una riga alla volta e presumo che la pausa su ogni colonna sia dovuta all'aggiunta della colonna. Questa è un'ipotesi, tuttavia non posso pensare ad alcun altro motivo per il ritardo. Ho aggiunto uno screenshot di cqlsh nella mia domanda. –

+0

"Quando copio lo schema in cqlsh, incolla una riga alla volta e presumo che la pausa su ogni colonna sia dovuta all'aggiunta della colonna" -> Forse perché la connessione SSH è lenta. ** cqlsh ** non invia la query CREATE TABLE a Cassandra finché non ha l'istruzione completa, ** non riga per riga ** – doanduyhai

risposta

4

ho sollevato questo bug qui: here

Questa si è rivelata a causa delle schede nello schema. CQLSH stava tentando di eseguire il completamento automatico ogni volta che si trattava di una scheda.

+0

omg, ho appena colpito lo stesso bug e hai ragione. –

+0

Non pensavo che sarebbe ancora in circolazione! –

2

Ho avuto questo stesso problema su diversi computer e sembra che sia un bug nella shell interattiva cqlsh>. Se si esegue lo script dal vostro terminale eseguirà immediatamente:

> cqlsh -f your_cql_script.cql <hostname> 

Questo viene eseguito immediatamente, non importa ciò che le tabelle di dimensioni e vi farà risparmiare un sacco di tempo.

+0

Ho postato questo come un bug su Datastax e si è rivelato essere cqlsh nell'interpretare le schede e provare a completare automaticamente! +1 per il lavoro intorno però :). –

Problemi correlati