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

hoe zal de bovenstaande query intern werken in cassandra?

in wezen zullen alle gegevens voor de partitie scopeid=35 en formid=78005 worden geretourneerd en vervolgens worden gefilterd door de record_link_id index. Het zal zoeken naar derecord_link_id entry voor9897, en proberen om items te matchen die overeenkomen met de rijen die worden geretourneerd waarscopeid=35 enformid=78005. De kruising van de rijen voor de partitiesleutels en de indexsleutels zal worden geretourneerd.

hoe High-cardinality column (record_link_id)index zal de query prestaties voor de bovenstaande query beïnvloeden?

high-cardinaliteitsindexen maken in wezen een rij voor (bijna) elk item in de hoofdtabel. De prestaties worden beïnvloed, omdat Cassandra is ontworpen om sequentiële reads voor query resultaten uit te voeren. Een index query dwingt Cassandra om willekeurige reads uit te voeren. Naarmate de kardinaliteit van uw geïndexeerde waarde toeneemt, neemt ook de tijd die nodig is om de opgevraagde waarde te vinden toe.

zal cassandra alle knopen voor de bovenstaande query aanraken? Waarom?

No. Het mag alleen een knooppunt aanraken dat verantwoordelijk is voor de scopeid=35 en formid=78005 partitie. Indexen worden ook lokaal opgeslagen, bevatten alleen items die geldig zijn voor het lokale knooppunt.

het aanmaken van index over kolommen met een hoge cardinaliteit zal het snelste en beste datamodel zijn

het probleem hier is dat de aanpak niet schaalt en traag zal zijn als update_audit een grote dataset is. MVP Richard Low heeft een geweldig artikel over secundaire indexen( de Sweet Spot voor Cassandra secundaire indexering), en vooral op dit punt:

als uw tabel aanzienlijk groter was dan geheugen, zou een query erg traag zijn, zelfs om slechts een paar duizend resultaten terug te geven. Het terugkeren van potentieel miljoenen gebruikers zou rampzalig zijn, hoewel het een efficiënte query lijkt te zijn.

in de praktijk betekent dit dat indexeren het nuttigst is voor het retourneren van tientallen, misschien honderden resultaten. Houd dit in gedachten wanneer u vervolgens overweegt een secundaire index te gebruiken.

nu zal uw aanpak van het eerst beperken door een specifieke partitie helpen (omdat uw partitie zeker in het geheugen moet passen). Maar ik denk dat de beter presterende keuze hier zou zijn om record_link_id een clustering sleutel te maken, in plaats van te vertrouwen op een secundaire index.

Edit

Hoe werkt het hebben van index op lage kardinaliteit index wanneer er miljoenen gebruikers schaal zelfs wanneer we de primaire sleutel

Het zal afhangen van hoe breed uw rijen zijn. Het lastige aan extreem lage kardinaliteitsindexen is dat het % van de geretourneerde rijen meestal groter is. Overweeg bijvoorbeeld een brede rij users tabel. U beperkt door de partitiesleutel in uw query, maar er zijn nog steeds 10.000 rijen geretourneerd. Als uw index op iets als gender staat, moet uw zoekopdracht ongeveer de helft van die rijen filteren, die niet goed presteren.

secundaire indexen werken meestal het beste op (bij gebrek aan een betere beschrijving) “middle of the road” kardinaliteit. Gebruikmakend van het bovenstaande voorbeeld van een brede rij users tabel, zou een index op country of state veel beter moeten presteren dan een index op gender (aangenomen dat de meeste van deze gebruikers niet allemaal in hetzelfde land of dezelfde staat wonen).

Edit 20180913

voor uw antwoord op de eerste vraag ” Hoe zal de bovenstaande query intern werken in cassandra?”, Weet je wat het gedrag is bij het zoeken met paginering?

overweeg het volgende diagram, ontleend aan de Java Driver documentatie (v3.6):

in principe zal paging ervoor zorgen dat de query zichzelf opsplitst en terugkeert naar het cluster voor de volgende iteratie van de resultaten. Het is minder waarschijnlijk dat er een time-out komt, maar de prestaties zullen naar beneden gaan, evenredig met de grootte van de totale resultaatset en het aantal knooppunten in het cluster.

TL;DR; hoe meer gevraagde resultaten verspreid over meer knooppunten, hoe langer het zal duren.