Ich bin neu in Cassandra. Ich habe ein Problem in CQL IN query , wenn Tabelle hat SET-Typ Spalte funktioniert es.
Aber wenn ich tags set oben hinzufüge, gibt es einen Fehler
%Vor%code = 2200 [Ungültige Abfrage] message="Die Spalte" test_id "kann nicht durch eingeschränkt werden IN Beziehung als eine Sammlung wird durch die Abfrage "
" ausgewählt
Ich bin nicht sicher, warum diese Einschränkung besonders für Sammlungen gelten sollte. Aber in Ihrem Fall können Sie dieses Problem umgehen, indem Sie test_id als Teil Ihres Partitionsschlüssels verwenden:
PRIMARY KEY((test_date,test_id))
Damit können Sie IN-Abfragen ausführen, solange Sie den ersten Teil des zusammengesetzten Schlüssels (test_date) angeben.
Ich bin neu in Cassandra. Ich habe ein Problem in %code% , wenn Tabelle hat SET-Typ Spalte funktioniert es.
%Vor%Aber wenn ich tags set oben hinzufüge, gibt es einen Fehler
%Vor%code = 2200 [Ungültige Abfrage] message="Die Spalte" test_id "kann nicht durch eingeschränkt werden IN Beziehung als eine Sammlung wird durch die Abfrage "
" ausgewählt
Ich denke, Sie sehen diesen Fehler aufgrund des zugrunde liegenden Speichermodells von Cassandra. Wenn ich Ihre %code% -Tabelle in CQLSH abfrage (mit meinen eigenen Testdaten), sehe ich Folgendes:
%Vor%Diese Ansicht gibt eine irreführende Interpretation darüber, wie die Daten tatsächlich gespeichert werden. So sieht es aus, wenn ich die gleiche Tabelle innerhalb von cassandra-cli abfrage:
%Vor%Dies legt nahe, dass Sammlungs (set) -Werte als zusätzliche Spaltenschlüssel gespeichert werden. Eine Einschränkung bei der Verwendung der Beziehung %code% besteht darin, dass sie mit dem letzten Schlüssel (Partitionierung oder Clustering) eines Primärschlüssels arbeiten muss. Ich nehme an, dass dies eine Einschränkung ist, die darauf beruht, wie Cassandra die Sammlungsdaten "unter der Haube" speichert.
Und nur eine Warnung, aber die Verwendung von %code% für Abfragen auf Produktionsebene wird nicht empfohlen. Einige sind sogar so weit gegangen, es auf die Liste der Cassandra-Anti-Patterns zu setzen. Meine Antwort auf diese Frage ( Ist IN Beziehung in Cassandra schlecht für Abfragen? ) erklärt warum %code% Abfragen nicht optimal sind.
BEARBEITEN
Nur um zu sehen, habe ich Ihr Schema mit einer Liste anstatt einer Menge ausprobiert, um zu sehen, ob das irgendeinen Unterschied machte. Es immer noch nicht funktioniert, sondern aus dem cassandra-cli es erschien eine zusätzliche UUID-Kennung zu dem Schlüssel hinzuzufügen, und den tatsächlichen Wert als Spaltenwert gespeichert. Was sich von der Behandlung eines Sets unterscheidet, muss sein, wie Sets auf eindeutige Werte beschränkt sind.
Sie können eine materialisierte Ansicht mit test_id als Teil des Partitionierungsausdrucks verwenden, um Ihre Anforderung zu erfüllen, wenn das Ändern der PK in Ihrer Basistabelle keine Option ist:
%Vor%Verwenden Sie dann die materialisierte Ansicht anstelle der Basistabelle in Ihrer Abfrage:
%Vor% Ich denke, Sie sehen diesen Fehler aufgrund des zugrunde liegenden Speichermodells von Cassandra. Wenn ich Ihre test1 -Tabelle in CQLSH abfrage (mit meinen eigenen Testdaten), sehe ich Folgendes:
Diese Ansicht gibt eine irreführende Interpretation darüber, wie die Daten tatsächlich gespeichert werden. So sieht es aus, wenn ich die gleiche Tabelle innerhalb von cassandra-cli abfrage:
%Vor% Dies legt nahe, dass Sammlungs (set) -Werte als zusätzliche Spaltenschlüssel gespeichert werden. Eine Einschränkung bei der Verwendung der Beziehung IN besteht darin, dass sie mit dem letzten Schlüssel (Partitionierung oder Clustering) eines Primärschlüssels arbeiten muss. Ich nehme an, dass dies eine Einschränkung ist, die darauf beruht, wie Cassandra die Sammlungsdaten "unter der Haube" speichert.
Und nur eine Warnung, aber die Verwendung von IN für Abfragen auf Produktionsebene wird nicht empfohlen. Einige sind sogar so weit gegangen, es auf die Liste der Cassandra-Anti-Patterns zu setzen. Meine Antwort auf diese Frage ( Ist IN Beziehung in Cassandra schlecht für Abfragen? ) erklärt warum IN Abfragen nicht optimal sind.
BEARBEITEN
Nur um zu sehen, habe ich Ihr Schema mit einer Liste anstatt einer Menge ausprobiert, um zu sehen, ob das irgendeinen Unterschied machte. Es immer noch nicht funktioniert, sondern aus dem cassandra-cli es erschien eine zusätzliche UUID-Kennung zu dem Schlüssel hinzuzufügen, und den tatsächlichen Wert als Spaltenwert gespeichert. Was sich von der Behandlung eines Sets unterscheidet, muss sein, wie Sets auf eindeutige Werte beschränkt sind.
Sie können eine materialisierte Ansicht mit test_id als Teil des Partitionierungsausdrucks verwenden, um Ihre Anforderung zu erfüllen, wenn das Ändern der PK in Ihrer Basistabelle keine Option ist:
%Vor%Verwenden Sie dann die materialisierte Ansicht anstelle der Basistabelle in Ihrer Abfrage:
%Vor%