Różnica między UPDATE i INSERT w Cassandra?

Question

Jaka jest różnica między UPDATE i INSERT podczas wykonywania CQL przeciwko Cassandra?

Wygląda na to, że nie było różnicy, ale teraz documentation mówi, że INSERT nie obsługuje liczników podczas gdy UPDATE ma.

Czy istnieje "preferowana" metoda użycia? A może są przypadki, w których jeden powinien być używany nad drugim?

Dziękuję bardzo!

Answer 1

Kolumny licznika w Cassandra nie można ustawić na dowolną wartość: można je tylko zwiększać lub zmniejszać o dowolną wartość.

Z tego powodu INSERT nie obsługuje Counter Column, ponieważ nie można "wstawić" wartości do kolumny Counter. Możesz tylko UPDATE je (inkrementować lub dekrementować) o pewną wartość. Oto, jak zaktualizować kolumnę Counter.

UPDATE ... SET name1 = name1 + <value> 

Pytałeś:

Czy istnieje "preferowane" metoda w użyciu? A może są przypadki, w których jeden powinien być używany nad drugim?

Tak. Jeśli wstawiasz wartości do bazy danych, możesz użyć INSERT. Jeśli kolumna nie istnieje, zostanie utworzona dla Ciebie. W przeciwnym razie efekt jest podobny do . INSERT jest przydatny, gdy nie masz wstępnie zaprojektowanego schematu (Dynamic Column Family, tj. Wstaw cokolwiek, w dowolnym momencie). Jeśli projektujesz schemat przed rozdaniem (Static Column Family, podobny do RDMS) i znasz każdą kolumnę, możesz użyć UPDATE.

Answer 2

Istnieje subtelna różnica. Wstawione rekordy za pomocą INSERT pozostaną, jeśli wszystkie nie-kluczowe pola zostaną ustawione na wartość null. Rekordy wstawione za pomocą UPDATE znikają, jeśli dla wszystkich pól innych niż kluczowe zostaną ustawione wartości null.

Spróbuj tego:

CREATE TABLE T (
    pk int, 
    f1 int, 
    PRIMARY KEY (pk) 
); 

INSERT INTO T (pk, f1) VALUES (1, 1); 
UPDATE T SET f1=2 where pk=2; 
SELECT * FROM T; 

Powroty:

pk | f1 
----+---- 
    1 | 1 
    2 | 2 

Teraz aktualizować każdy wiersz ustawienia f1 null.

UPDATE T SET f1 = null WHERE pk = 1; 
UPDATE T SET f1 = null WHERE pk = 2; 
SELECT * FROM T; 

Należy zauważyć, że rząd 1 pozostaje, a wiersz 2 jest usunięty.

pk | f1 
----+------ 
    1 | null 

Jeśli spojrzysz na te, używając Cassandra-cli, zobaczysz inny sposób dodawania wierszy.

Chciałbym się dowiedzieć, czy jest to zgodne z projektem, czy z błędem, i zobacz to zachowanie udokumentowane.

Answer 3

chodzi o subtelnej różnicy podświetlonego przez billbaird (jestem w stanie wypowiedzieć się na tym stanowisku bezpośrednio), gdzie rząd stworzony przez operacji aktualizacji zostanie usunięta, jeśli nie wszystkie pola są puste kluczowe:

To jest spodziewane zachowanie, a nie błąd oparty na raporcie o błędzie pod https://issues.apache.org/jira/browse/CASSANDRA-11805 (który został zamknięty jako "Not A Problem")

Wpadłem na to sam, gdy po raz pierwszy korzystałem z Spring Data. Używałem metody repozytorium save(T entity), ale nie utworzono żadnego wiersza. okazało się, że Spring Data używała UPDATE, ponieważ stwierdziła, że ​​obiekt nie był "nowy" (nie jestem pewien, czy test dla "isNew" ma sens) i zdarzyło mi się, że testowałem z jednostkami, które miały tylko ustawione kluczowe pola .

Dla tego przypadku danych Spring, interfejsy repozytoriów specyficzne dla Cassandry dostarczają metodę insert, która wydaje się konsekwentnie korzystać z INSERT, jeśli zachowanie to jest pożądane (chociaż dokumentacja Spring nie dokumentuje odpowiednio tych szczegółów).

Answer 4

Kolejna subtelna różnica (zaczynam wierzyć, że cql to okropny interfejs dla Kasandry, pełen subtelności i zastrzeżeń ze względu na użycie podobnej składni SQL, ale nieco odmiennej semantyki) jest z ustawianiem TTL na istniejących danych. Dzięki UPDATE nie można zaktualizować TTL kluczy, nawet jeśli nowe rzeczywiste wartości są równe wartościom starszym. Rozwiązaniem jest INSERT w nowym wierszu zamiast, z nowym TTL już ustawione