stocați vizitatori unici într-o bază de date distribuită

Am astfel de date de structură ( vizitatori web )

List(p1,p1,p1,p2,p3,p3,p4,p4,p5...)

un vizitator poate vizita de 1 --> de multe ori

volume de date: aproximativ 100 milioane / zi

Ce zici de sau ce db pot stoca vizitatori unici pentru acces rapid (aproape în timp real) așa

2014-11-15 | p1 | p2 | p3 | ...| pn

Încerc să rezolv folosind Cassandra folosind tabelul ca acesta:

CREATE TABLE uniqueVisitor (
  key text,
  p text,
  PRIMARY KEY (key, data)
)

Cred că acest model de magazin nu funcționează foarte bine deoarece:

Din cauza partiționării datelor din acest tabel , toate datele unei chei vor fi stocate pe un singur server (cu factor de replicare =1 ) == > prea multe solicitări de scriere pot elimina serverul stocat această cheie.

Vă rog să-mi sugerați o soluție (model de stocare)


database cassandra bigdata real-time-data
person tnk_peka    schedule 01.12.2014    source sursă
comment
Aș dori să te ajut, dar nu sunt sigur că ți-am înțeles bine întrebarea. În tabelul uniqueVisitor, ce doriți să stocați în câmpul cheie: dată, referință la pagina web sau altceva? În mod similar, ce este p: este numele vizitatorului sau altceva?   -  person Pradyumn    schedule 01.12.2014
comment
multumesc pentru ajutor! Am nevoie de stocare numai userId!! Cheia este un șir simplu de dată: exemplu „2014-12-01”   -  person tnk_peka    schedule 01.12.2014

Răspunsuri (2)


arrow_upward
3
arrow_downward

Puteți folosi un set, deoarece elimină duplicatele (și nu are o ordine specifică în el). De exemplu,

CREATE TABLE uniqueVisitor (
  dt text,
  users set<text>,
  PRIMARY KEY (dt)
);

Ai dreptate, datele pentru o singură zi nu ar fi distribuite; va fi pe un singur nod (și replicile). Înregistrările cu date diferite, desigur, vor fi distribuite. Deci, acesta este un potențial hotspot de scriere. Acestea fiind spuse, cred că hotspot-ul de scriere ar putea să nu conteze prea mult în acest caz, deoarece este o singură înregistrare (deși gigantică) care este modificată. Fiecare vizită a utilizatorului nu va avea ca rezultat I/O pe disc, deoarece modificările vor fi mai întâi făcute în memorie, în memtables și numai atunci când memtables sunt spălate pe disc, acestea vor fi scrise într-un SSTable. Datele din mai multe SSTable vor fi compactate periodic, ceea ce poate avea un anumit cost de performanță, deși îmi imaginez că nu v-ar distruge aplicația.

În Cassandra 2.1, este, de asemenea, posibil să se creeze indecși pe tipurile de colecții precum SET-uri.

Sper că acest lucru vă ajută.

person Pradyumn    schedule 02.12.2014
comment
tks pradyumn! Voi lua în considerare să folosesc Set în tabelul meu! - person tnk_peka; 02.12.2014
comment
Aveți grijă la limita de dimensiune de 64K pentru colecții. - person ashic; 02.12.2014

arrow_upward
1
arrow_downward

Este destul de obișnuit, atunci când aveți de-a face cu fluxuri de date cu volum mare, să sacrificeți o anumită precizie pentru eficiență. Există câțiva algoritmi pentru a estima numărul de unici având în vedere un flux de date de volum mare. Ele necesită mult mai puțin spațiu decât simpla stocare a fiecărui unic, necesită mult mai puțină procesare (se poate face în memorie chiar și pe un singur nod - sau câteva noduri) și oferă rezultate cu o precizie de cel puțin 50% (și mult mai mult dacă face mai multă muncă). Aruncă o privire la algoritmul Flajolet-Martin și (mai bine) algoritmul Alon-Matias-Szegedy (AMS). Puteți găsi scurte descrieri aici: http://www.st.ewi.tudelft.nl/~hauff/BDP-Lectures/3_streams.pdf și analiză detaliată în Prof. Ullman et. cartea lui al. care este disponibilă gratuit aici: http://mmds.org/ . Cred că capitolul 4 acoperă destul de frumos procesarea fluxului.

person ashic    schedule 02.12.2014