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

hvordan spørringen ovenfor vil fungere internt i cassandra?

I Hovedsak vil alle data for partisjonscopeid=35 ogformid=78005 returneres, og deretter filtreres avrecord_link_id – indeksen. Det vil se etterrecord_link_id oppføring for 9897, og forsøke å matche opp oppføringer som samsvarer med radene returnert der scopeid=35 og formid=78005. Krysset mellom radene for partisjonstastene og indeksnøklene vil bli returnert.

hvor høy kardinalitetskolonne (record_link_id)indeks vil påvirke spørringsytelsen for spørringen ovenfor?

high-cardinality indekser skaper i hovedsak en rad for (nesten) hver oppføring i hovedtabellen. Ytelsen påvirkes, Fordi Cassandra er utformet for å utføre sekvensiell leser for spørringsresultater. En indeks spør hovedsak tvinger Cassandra å utføre tilfeldig leser. Som kardinalitet av indeksert verdi øker, så gjør tiden det tar å finne spørres verdien.

vil cassandra berøre alle noder for spørringen ovenfor? HVORFOR?

Nei. Den skal bare berøre en node som er ansvarlig forscopeid=35 ogformid=78005 partisjonen. Indekser også lagres lokalt, bare inneholde oppføringer som er gyldige for den lokale noden.

å lage indeks over kolonner med høy kardinalitet vil være den raskeste og beste datamodellen

problemet her er at tilnærmingen ikke skaleres, og vil være treg hvis update_audit er et stort datasett. Mvp Richard Low har en flott artikkel om sekundære indekser(Det Søte Stedet For Cassandra Sekundær Indeksering), og spesielt på dette punktet:

hvis tabellen var betydelig større enn minnet, ville en spørring være veldig treg selv å returnere bare noen få tusen resultater. Retur potensielt millioner av brukere ville være katastrofalt, selv om det synes å være en effektiv spørring.i praksis betyr dette at indeksering er mest nyttig for å returnere tiere, kanskje hundrevis av resultater. Ha dette i bakhodet når du neste vurdere å bruke en sekundær indeks.

nå vil din tilnærming til først å begrense av en bestemt partisjon hjelpe (som partisjonen din sikkert skal passe inn i minnet). Men jeg føler at det bedre utførende valget her ville være å lage record_link_id en klyngnøkkel, i stedet for å stole på en sekundær indeks.

Edit

hvordan har indeks på lav kardinalitet indeks når det er millioner av brukere skala selv når vi gir primærnøkkelen

Det vil avhenge av hvor brede radene dine er. Den vanskelige tingen om ekstremt lave kardinalitetsindekser, er at % av rader som returneres, vanligvis er storre. For eksempel, vurder en bred rad users tabell. Du begrenser ved partisjonsnøkkelen i spørringen, men det er fortsatt 10 000 rader returnert. Hvis indeksen din er på noe som gender, må spørringen filtrere ut omtrent halvparten av disse radene, noe som ikke vil fungere bra.Sekundære indekser har en tendens til å fungere best på (i mangel av en bedre beskrivelse) «midt på veien» kardinalitet. Ved å bruke eksemplet ovenfor på en bred rad users tabell, bør en indeks på country eller state skal utføre mye bedre enn en indeks på gender (forutsatt at de fleste av disse brukerne ikke alle bor i samme land eller stat).

Edit 20180913

for ditt svar på 1. spørsmål » Hvordan spørringen ovenfor vil fungere internt i cassandra ?», vet du hva som er oppførselen når spørring med paginering?

Vurder følgende diagram, hentet fra Java-Driverdokumentasjonen (v3.6):

I Utgangspunktet vil personsøking føre til at spørringen bryter seg opp og går tilbake til klyngen for neste iterasjon av resultater. Det ville være mindre sannsynlig å timeout, men ytelsen vil trend nedover, proporsjonal med størrelsen på det totale resultatsettet og antall noder i klyngen.

TL;DR; jo mer forespurte resultater spredt over flere noder, jo lengre vil det ta.