ein Beispiel für die folgende Auswahl in CQL Gegeben:Ist die IN-Beziehung in Cassandra für Abfragen schlecht?
SELECT * FROM tickets WHERE ID IN (1,2,3,4)
Gegeben ID eine Partition Schlüssel ist, wird in Beziehung mit besser als mehr Abfragen zu tun oder gibt es keinen Unterschied?
Ich erinnerte mich, dass jemand diese Frage in der Cassandra Benutzer-Mailingliste eine kurze Weile zurück beantwortet hatte, aber ich kann die genaue Nachricht gerade nicht finden. Ironischerweise hat Cassandra Evangelist Rebecca Mills gerade einen Artikel gepostet, der dieses Problem anspricht (Things you should be doing when using Cassandra drivers ... Punkte # 13 und # 22). Aber die Antwort ist "Ja", dass in einigen Fällen mehrere parallele Abfragen schneller wären als die Verwendung einer IN. Der zugrunde liegende Grund kann in der DataStax SELECT documentation gefunden werden.
wenn sie nicht in
verwenden, um ... Mit IN Leistung beeinträchtigen können, weil in der Regel viele Knoten abgefragt werden müssen. In einem einzelnen, lokalen Rechenzentrumscluster mit 30 Knoten, einem Replikationsfaktor von 3 und einer Konsistenzstufe von LOCAL_QUORUM, geht eine einzelne Schlüsselabfrage an zwei Knoten , aber wenn die Abfrage die Bedingung IN verwendet, Die Anzahl der Knoten , die abgefragt werden, ist höchstwahrscheinlich sogar höher, bis zu 20 Knoten, abhängig von , wobei die Schlüssel in den Token-Bereich fallen.
Also basierend darauf scheint es, dass dies mehr ein Problem wird, wenn Ihr Cluster größer wird.
Daher wäre der beste Weg, um dieses Problem zu lösen (und nicht IN überhaupt zu verwenden), Ihr Datenmodell für diese Abfrage zu überdenken. Ohne zu viel über Ihr Schema zu wissen, gibt es vielleicht Attribute (Spaltenwerte), die von Ticket-IDs 1, 2, 3 und 4 gemeinsam genutzt werden. Vielleicht etwas wie Ebene oder Gruppe (wenn Tickets für einen bestimmten Veranstaltungsort sind) oder vielleicht sogar ein Ereignis (id), stattdessen.
Grundsätzlich, während die Verwendung einer eindeutigen, hohen Kardinalität Kennung zur Partitionierung Ihrer Daten klingt wie eine gute Idee, es macht es tatsächlich schwieriger, Ihre Daten (in Cassandra) später abzufragen. Wenn Sie eine andere Spalte zur Partitionierung Ihrer Daten erstellen könnten, würde Ihnen das in diesem Fall sicherlich helfen. Unabhängig davon ist das Erstellen einer neuen, spezifischen Spaltenfamilie (Tabelle) zur Behandlung von Abfragen für diese Zeilen ein besserer Ansatz als die Verwendung von IN oder mehrere Abfragen.
Ja, es ist besser, einzeln abzufragen als mit IN in Cassandra.
Für diese Abfrage muss der Koordinator die Daten von 4 verschiedenen Partitionen abrufen und wenn jede Partition sehr groß ist, werden die Daten in JVM gefüllt, was zu Problemen führen kann.
Stattdessen Abfragen der Daten mit mehreren Abfragen ist besser, da jede Abfrage individuell ist und nicht auf andere Partitionen Daten warten müssen, um es zurück an den Benutzer senden.
Was ist mit 'löschen' Abfrage? Ich habe zur Zeit eine Abfrage 'DELETE FROM xyz WHERE pkey IN (1,2,3,4)'. Ist der Operator IN für DELETE besser als SELECT? – pinkpanther
@pinkpanther Es kommt darauf an, wenn Sie sich darum sorgen, dass der Löschvorgang gut abläuft. Wenn Sie mehrere Knoten haben, würde ich denken, dass Sie die gleichen Leistungsprobleme haben würden. Aber wenn Sie nur eine einmalige Wartung löschen, würde ich mich nicht darum kümmern. – Aaron
Die Empfehlung, Datensätze unter einem Partitionsschlüssel mit höherer Kardinalität zu konsolidieren, kann für die IN-Abfrage optimiert werden. Sie müssen jedoch die Partitionsgröße berücksichtigen. Der Sweet Spot ist ungefähr 100 MB groß. Wenn Ihre Partitionen dann viel größer werden, sollten Sie über eine andere Möglichkeit nachdenken, sie aufzuteilen. Da das Datenmodell in Cassandra der größte Leistungsindikator ist, schlage ich vor, den Kurs [Datenmodellierung] (https://academy.datastax.com/courses/ds220-data-modeling) von DataStax Academy zu nehmen. –