Wie im Bild gezeigt Abfragen mit exakten Zeitstempel(2013-08-01 15:02:56) nicht die Rückgabe eines Ergebnis wenn eine Zeile mit diesem Zeitstempel vorhanden ist, aber es gibt Ergebnisse, die mit dieser Zeile abgefragt, wenn für
timestamps > '2013-08-01 15:02:56'
Ist das normale Verhalten in Kassandra?
Ja, das ist das erwartete Verhalten.
Laut der Kassandra-docs und hier hier, cassandra ist die Speicherung von Zeitstempeln als "Millisekunden, die seit dem standard-base-Zeit bekannt als die Epoche".
Wenn Sie legen Sie Ihre Daten, fügen Sie einen Millisekunden-Wert mit der höheren Auflösung als Ihre "2013-08-01 15:02:56" (Millisekunden-Wert "nun" vs-nur Sekunden und 0 Millisekunden). Eine EQ-operator wird nie passen, es sei denn, Ihre eingefügten Zeitstempel 0 Millisekunden.
Diese arbeiten
So, wenn Sie die Abfrage durch cqlsh Ihrem datetime-übersetzt wird in eine ganze Zahl (Millisekunden), die nur Verschieden von dem Wert, den Sie eingefügt ursprünglich. Ihre eingefügte Wert wird einige Millisekunden NACH "2013-08-01 15:02:56". Abfrage nach GENAU "2013-08-01 15:02:56" (und die 0-Millisekunden). Mit einer GT oder LT-operator match, eine EQ-Betreiber nicht.
Hoffe, das hilft!
Wie omnibear sagte, ich glaube, dein problem ist, dass der timestamp gespeichert wird mit Millisekunden - >0.
Sehen, starten Sie die nächste Abfrage:
Dann überprüfen Sie die letzten zahlen, die die Anzahl von Millisekunden.
Wenn die letzten zahlen sind >0 (was ich erwarte), dann erklärt dies, warum Ihr = Behauptung ist falsch.
So haben Sie zwei Möglichkeiten:
...geben Sie mir die Ereignisse nach dem 15:02:56 Uhr, aber vor 15:02:57:
Habe ich vor kurzem auch vor dem gleichen problem, und dies ist, wie ich es lösen.
Berechnen long-Wert mit
blobAsBigint(timestampAsBlob(timestamps))
und dann verwenden Sie es in Ihrer where-Klausel mit'='
Betreiber.