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

jak bude výše uvedený dotaz interně fungovat v Cassandře?

v Podstatě, všechna data na oddílu scopeid=35formid=78005 budou vráceny, a poté se filtruje pomocí record_link_id index. To bude vypadat pro record_link_id položka 9897, a pokusit se match-up položky, které odpovídají řádky, které jsou vráceny, kde scopeid=35formid=78005. Průsečík řádků pro klíče oddílů a klíče indexu bude vrácen.

jak vysoký index sloupce (record_link_id)ovlivní výkon dotazu pro výše uvedený dotaz?

indexy vysoké kardinality v podstatě vytvářejí řádek pro (téměř) každou položku v hlavní tabulce. Výkon je ovlivněn, protože Cassandra je navržena tak, aby prováděla sekvenční čtení výsledků dotazu. Indexový dotaz v podstatě nutí Cassandru provádět náhodné čtení. Jak se zvyšuje kardinálnost indexované hodnoty, zvyšuje se i čas potřebný k nalezení dotazované hodnoty.

dotkne se cassandra všech uzlů pro výše uvedený dotaz? Proč?

ne. Měl by se dotknout pouze uzlu, který je zodpovědný za oddíl scopeid=35 a formid=78005. Indexy jsou také uloženy lokálně, obsahují pouze položky, které jsou platné pro místní uzel.

vytvoření indexu nad vysokou mohutnost sloupce bude nejrychlejší a nejlepší data model

problém je, že přístup není měřítko, a bude pomalé, pokud update_audit je velký dataset. MVP Richard Low má skvělý článek o sekundárních indexech( Sweet Spot pro Cassandra Secondary Indexing), a zejména v tomto bodě:

Pokud váš stůl byl výrazně větší než paměť, dotaz by byl velmi pomalý i vrátit jen pár tisíc výsledků. Návrat potenciálně milionů uživatelů by byl katastrofální, i když by se zdálo, že je to efektivní dotaz.

v praxi to znamená, že indexování je nejužitečnější pro vrácení desítek, možná stovek výsledků. Mějte to na paměti při dalším zvažování použití sekundárního indexu.

Nyní, váš přístup první omezení konkrétní oddíl, pomůže (jako svou oblast by měla rozhodně vejít do paměti). Ale mám pocit, že lepší volbou by bylo vytvořit record_link_id shlukovací klíč, místo spoléhání se na sekundární index.

Edit

Jak může mít index na nízkých mohutnost indexu, když tam jsou miliony uživatelů, rozsahu, i když jsme poskytovat primární klíč

To bude záviset na tom, jak široký vaše řádky jsou. Ošemetná věc o extrémně nízkých indexech kardinality je, že % vrácených řádků je obvykle větší. Zvažte například tabulku s širokým řádkem users. V dotazu omezíte klíč oddílů, ale stále je vráceno 10 000 řádků. Pokud je váš index na něčem jako gender, váš dotaz bude muset odfiltrovat asi polovinu těchto řádků, což nebude fungovat dobře.

Sekundární indexy mají tendenci pracovat nejlépe na (pro nedostatek lepšího popisu) „uprostřed silnice“ mohutnost. Pomocí výše uvedeném příkladu široký-řádek users tabulka, index na country nebo state by měl hrát mnohem lépe než index na gender (za předpokladu, že většina z těch uživatelů, ne všichni žijí ve stejné zemi nebo na stejném stavu).

Edit 20180913

pro vaši odpověď na 1. otázku “ jak bude výše uvedený dotaz interně fungovat v Cassandře?“, víte, jaké je chování při dotazu s stránkováním?

Zvažte následující schéma, převzaté z Java dokumentaci Ovladače (v3.6):

v Podstatě, stránkování způsobí, že dotaz zlomit sám, a vrátit se do klastru pro další iteraci výsledky. Bylo by méně pravděpodobné, že časový limit, ale výkon bude trend směrem dolů, úměrný velikosti celkového výsledku a počtu uzlů v clusteru.

TL; DR; čím více požadovaných výsledků se rozloží na více uzlů, tím déle to bude trvat.