Cassandra - kwerenda na klucze klasterowe

Question

Właśnie zaczynam od Cassandry i próbowałem stworzyć tabele z różnymi kluczami partycjonowania i klastrowania, aby zobaczyć, jak mogą być inaczej sprawdzane.

Utworzono tabelę z kluczem podstawowym formularza - (a), b, c gdzie a jest kluczem partycji, a b, c kluczem klastrowania.

Podczas odpytywania zauważyłem, że następujące zapytanie:

select * from tablename where b=val; 

wyniki:

Nie można wykonać tej kwerendy, jak mogłoby się wiązać filtrowanie danych, a tym samym może mieć nieprzewidywalne wydajność. Jeśli chcesz wykonać to zapytanie mimo nieprzewidywalności wydajności, należy pozwalać na filtrowanie

i za pomocą „Zezwalaj Filtering” dostaje mi, co chcę (choć słyszałem jego złe dla wydajności).

Ale kiedy uruchomić następujące zapytanie:

select * from tablename where c=val; 

mówi:

PRIMARY KEY kolumnie "c" nie może być ograniczone (poprzedniego kolumnie "B" nie zostało ograniczone lub przez niezwiązana z EQ)

W ogóle nie ma opcji "ZEZWALAJ FILTROWANIE".

MOJE PYTANIE JEST - Dlaczego wszystkie klucze do klastrowania nie są traktowane tak samo? kolumna b, która sąsiaduje z klawiszem partycji "a", ma opcję "zezwalaj na filtrowanie", która pozwala na kwerendę na niej, podczas gdy kwerenda na kolumnie "c" nie wydaje się w ogóle możliwa (biorąc pod uwagę sposób, w jaki ta tabela jest ułożona).

ALLOW FILTERING otrzymuje kasandra do skanowania przez wszystkie SSTables i pobierania danych z niego, gdy brakuje klucza partycji, to dlaczego nie możemy zrobić tej samej kolumny c?

Answer 1

Nie chodzi o to, że klucze do klastrowania nie są traktowane tak samo, ponieważ nie można ich pominąć. Dzieje się tak dlatego, że Cassandra używa kluczy klastrowych do określenia porządku sortowania na dysku w obrębie partycji.

Aby dodać do swojego przykładu, załóżmy PRIMARY KEY ((a),b,c,d). Możesz uruchomić zapytanie (z ALLOW FILTERING), podając tylko b lub b i c. Ale nie pozwoliłoby ci określić wartości c i d (pomijając b) lub b i (pomijając c).

Jako węzeł boczny, jeśli naprawdę chcesz mieć możliwość zapytania tylko przez b lub tylko c, powinieneś obsługiwać te zapytania z dodatkowymi tabelami zaprojektowanymi jako takie. POZWÓL FILTROWANIE to pomoc dla zespołu, i nie jest czymś, co powinieneś zrobić w produkcji Cassandra.