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

hogyan működik a fenti lekérdezés belsőleg a cassandra-ban?

lényegében a scopeid=35és formid=78005partícióra vonatkozó összes adatot visszaadja, majd a record_link_id index alapján szűri. Meg fogja keresni arecord_link_id bejegyzést a9897 számára, és megpróbálja egyeztetni azokat a bejegyzéseket, amelyek megfelelnek ascopeid=35 ésformid=78005soroknak. A partíciókulcsok és az indexkulcsok sorainak metszéspontja kerül visszaadásra.

mennyire befolyásolja a magas kardinalitású oszlop (record_link_id)index a fenti lekérdezés lekérdezési teljesítményét?

a magas kardinalitású indexek lényegében egy sort hoznak létre a főtábla (majdnem) minden bejegyzéséhez. Teljesítmény befolyásolja, mert Cassandra célja, hogy végre szekvenciális olvasás lekérdezés eredményeit. Az index lekérdezés lényegében arra kényszeríti Cassandrát, hogy véletlenszerű olvasásokat hajtson végre. Az indexelt érték kardinalitása növekszik, így a lekérdezett érték megtalálásához szükséges idő is.

a cassandra megérinti a fenti lekérdezés összes csomópontját? Miért?

nem. Csak a scopeid=35 és formid=78005 partícióért felelős csomópontot kell megérintenie. Az indexek szintén helyben vannak tárolva, csak a helyi csomópontra érvényes bejegyzéseket tartalmaznak.

az index létrehozása magas kardinalitású oszlopokon lesz a leggyorsabb és legjobb adatmodell

a probléma itt az, hogy a megközelítés nem skálázódik, és lassú lesz, ha a update_audit egy nagy adatkészlet. MVP Richard Low van egy nagy cikket a másodlagos indexek (a Sweet Spot Cassandra másodlagos indexelés), különösen ezen a ponton:

ha a táblázat jelentősen nagyobb volt, mint a memória, a lekérdezés nagyon lassú lenne, még csak néhány ezer eredményt is visszaadna. A potenciálisan több millió felhasználó visszatérése katasztrofális lenne, annak ellenére, hogy hatékony lekérdezésnek tűnik.

a gyakorlatban ez azt jelenti, hogy az indexelés a leghasznosabb tíz, talán több száz eredmény visszaadásához. Tartsa ezt szem előtt, amikor legközelebb fontolóra veszi a másodlagos index használatát.

most az a megközelítés, hogy először egy adott partíció korlátozza, segít (mivel a partíciónak minden bizonnyal be kell illeszkednie a memóriába). De úgy érzem, hogy a jobban teljesítő választás itt az lenne, ha arecord_link_id fürtözési kulcsot hoznánk létre, ahelyett, hogy másodlagos indexre támaszkodnánk.

Edit

hogyan működik az index alacsony kardinalitású indexben, ha több millió felhasználó van, akkor is, ha megadjuk az elsődleges kulcsot

Ez attól függ, hogy milyen szélesek a sorok. A rendkívül alacsony kardinalitási indexeknél az a trükkös, hogy a visszaadott sorok % – a általában nagyobb. Vegyünk például egy széles sorúusers táblát. A lekérdezésben a partíciós kulcs korlátozza, de még mindig 10 000 sor van visszaadva. Ha az indexed valami olyasmin van, mint gender, akkor a lekérdezésnek ki kell szűrnie a sorok körülbelül felét, amelyek nem fognak jól teljesíteni.

a másodlagos indexek általában (jobb leírás hiányában) az “út közepe” kardinalitáson működnek a legjobban. A fenti példa segítségével egy széles sorú users táblázat, egy index a country vagy state sokkal jobban kell teljesítenie, mint egy index a gender (feltételezve, hogy a legtöbb felhasználó nem minden él a ország vagy állam).

Edit 20180913

az 1. kérdésre adott válaszához “hogyan fog működni a fenti lekérdezés belsőleg a cassandra-ban?”, tudod, mi a viselkedés, amikor lekérdezés lapozással?

Tekintsük a következő diagramot, a Java illesztőprogram dokumentációjából (v3.6):

alapvetően a lapozás miatt a lekérdezés megszakad, és visszatér a fürtbe a következő iterációhoz. Ez kevésbé valószínű, hogy időtúllépés, de a teljesítmény csökkenő tendenciát mutat, arányos a teljes eredményhalmaz méretével és a fürt csomópontjainak számával.

TL; DR; minél több kért eredmény van elosztva több csomóponton, annál tovább tart.