select * from update_audit where scopeid=35 and formid=78005 and record_link_id=9897;

miten yllä oleva kysely toimii sisäisesti cassandrassa?

käytännössä kaikki osiota scopeid=35 ja formid=78005 koskevat tiedot palautetaan, minkä jälkeen record_link_id – indeksi suodattaa ne. Se etsii record_link_id merkintä 9897, ja yrittää täsmätä merkintöjä, jotka vastaavat palautettuja rivejä, joissa scopeid=35 ja formid=78005. Osionavainten ja indeksinäppäinten rivien leikkauspiste palautetaan.

kuinka korkean kardinaalisuuden sarakkeen (record_link_id)indeksi vaikuttaa kyselyn suorituskykyyn yllä olevalla kyselyllä?

korkean kardinaaliuden indeksit luovat lähinnä rivin (lähes) jokaiselle päätaulukon merkinnälle. Suorituskyky vaikuttaa, koska Cassandra on suunniteltu suorittamaan peräkkäisiä lukemia kyselyn tuloksia varten. Indeksikysely pakottaa Cassandran lukemaan satunnaisesti. Kuten kardinaalisuus indeksoitu arvo kasvaa, niin tekee aika se vie löytää queried arvo.

koskeeko cassandra kaikkia yllä olevan kyselyn solmuja? Miksi?

Ei. Se saa koskea vain solmua, joka vastaa scopeid=35 ja formid=78005 osiosta. Indeksit samoin tallennetaan paikallisesti, vain merkinnät, jotka ovat voimassa paikallisen solmun.

indeksin luominen korkean kardinaalisuuden sarakkeiden päälle on nopein ja paras tietomalli

ongelma tässä on se, että lähestymistapa ei skaalaudu ja on hidas, jos update_audit on suuri tietojoukko. MVP Richard Low on suuri artikkeli toissijainen indeksit(Sweet Spot Cassandra toissijainen indeksointi), ja erityisesti tästä asiasta:

Jos taulukkosi olisi huomattavasti muistia suurempi, kysely olisi hyvin hidas edes muutaman tuhannen tuloksen palauttamiseen. Mahdollisesti miljoonien käyttäjien palauttaminen olisi tuhoisaa, vaikka se vaikuttaisi tehokkaalta kyselyltä.

käytännössä tämä tarkoittaa, että indeksoinnista on eniten hyötyä kymmenien, ehkä satojen tulosten palauttamisessa. Pidä tämä mielessä, kun harkitset seuraavan kerran toissijaisen indeksin käyttöä.

nyt lähestymistapasi rajoittaa ensin tietyllä osiolla auttaa (koska osiosi pitäisi varmasti mahtua muistiin). Mutta minusta tässä parempi vaihtoehto olisi tehdä record_link_id ryhmittelyavain toissijaiseen indeksiin nojaamisen sijaan.

Edit

miten ottaa indeksi matalan kardinaaliindeksin, kun on miljoonia käyttäjiä mittakaavassa, vaikka annamme ensisijaisen avaimen

se riippuu siitä, kuinka leveitä rivisi ovat. Hankala asia erittäin alhainen kardinaalisuuden indeksit, on, että % rivit palautetaan on yleensä suurempi. Tarkastellaan esimerkiksi leveärivistä users – taulukkoa. Rajoitat kyselyssäsi osionäppäimellä, mutta palautettuja rivejä on vielä 10 000. Jos indeksisi on esimerkiksi gender, kyselysi täytyy suodattaa pois noin puolet noista riveistä, jotka eivät toimi hyvin.

toissijaiset indeksit toimivat yleensä parhaiten (paremman kuvauksen puuttuessa) ”keskellä tietä” – kardinaaleilla. Käyttämällä yllä olevaa esimerkkiä laajasta rivistä users taulukko, indeksin country tai state pitäisi toimia paljon paremmin kuin indeksin gender (olettaen, että useimmat näistä käyttäjistä eivät kaikki asu sama maa tai osavaltio).

Edit 20180913

vastauksesi 1. kysymykseen ”Miten yllä oleva kysely toimii sisäisesti cassandrassa?”, tiedätkö mikä on käyttäytyminen, kun kysely sivutus?

harkitse seuraavaa kaaviota, joka on otettu Java-Ajuridokumentaatiosta (v3.6):

periaatteessa hakeminen aiheuttaa kyselyn hajoamista ja paluun klusteriin tulosten seuraavaa iterointia varten. Olisi vähemmän todennäköistä aikalisä, mutta suorituskyky laskee suhteessa koko tulosjoukon kokoon ja solmujen lukumäärään klusterissa.

TL;DR; mitä enemmän pyydetyt tulokset leviävät useampaan solmuun, sitä kauemmin se kestää.