Jaki jest cel ustawienia klucza w danych.stolik?

mała aktualizacja: prosimy o zapoznanie się również z nowymi winietami HTML . ten numer podkreśla inne winiety, które planujemy.

Ponownie zaktualizowałem tę odpowiedź (Luty 2016) w świetle nowej funkcji on=, która pozwala ad-hoc dołączać również. Zobacz historię wcześniejszych (nieaktualnych) odpowiedzi.

Co dokładnie robi setkey(DT, a, b)?

Robi dwie rzeczy:

1. zmienia kolejność wierszy danych .tabela DT przez podaną kolumnę (a, b) przez odniesienie , zawsze w rosnącym porządku.
2. oznacza te kolumny jako klucz kolumny, ustawiając atrybut o nazwie sorted na DT.

Zmiana kolejności jest szybka (ze względu na Dane.table's internal radix sorting) oraz memory efficient (przydzielana jest tylko jedna dodatkowa kolumna typu double ).

Kiedy jest wymagane setkey()?

Do grupowania operacje, setkey() nigdy nie było absolutnym wymogiem. Oznacza to, że możemy wykonać cold-by lub adhoc-by.

## "cold" by
require(data.table)
DT <- data.table(x=rep(1:5, each=2), y=1:10)
DT[, mean(y), by=x] # no key is set, order of groups preserved in result

Jednak przed v1.9.6 dołączenie formularza x[i] wymagało key aby było ustawione na x. z nowym argumentem on= z v1.9.6+, nie jest to już prawdą, dlatego ustawienie klawiszy nie jest bezwzględnym wymogiem również tutaj.

## joins using < v1.9.6 
setkey(X, a) # absolutely required
setkey(Y, a) # not absolutely required as long as 'a' is the first column
X[Y]

## joins using v1.9.6+
X[Y, on="a"]
# or if the column names are x_a and y_a respectively
X[Y, on=c("x_a" = "y_a")]

Zauważ, że argument on= może być jawnie podany nawet dla keyed jako cóż.

Jedyną operacją wymagającą bezwzględnego ustawienia key jest funkcja foverlaps(). Ale pracujemy nad kilkoma dodatkowymi funkcjami, które po wykonaniu usuną ten wymóg.

• Jaki jest powód implementacji argumentu on=?

  Jest kilka powodów.

  1. Pozwala to wyraźnie odróżnić operację jako operację obejmującą dwa Dane.tabele . Just Robienie X[Y] również tego nie rozróżnia, chociaż może to być jasne poprzez odpowiednie nazwanie zmiennych.

  2. Pozwala również zrozumieć kolumny, na których join/podzbiór jest wykonywany natychmiast, patrząc na tę linijkę kodu (i nie ma konieczności śledzenia odpowiedniej linii setkey()).

  3. W operacjach, w których kolumny są dodawane lub aktualizowane przez odniesienie, on= operacje są znacznie bardziej wydajne, ponieważ nie potrzebuję wszystkich danych.Zmiana kolejności tabeli tylko w celu dodania / aktualizacji kolumn. Na przykład,

     ## compare 
     setkey(X, a, b) # why physically reorder X to just add/update a column?
     X[Y, col := i.val]
     
     ## to
     X[Y, col := i.val, on=c("a", "b")]
     

     W drugim przypadku nie musieliśmy zmieniać kolejności. To nie jest obliczanie kolejności, która jest czasochłonna, ale fizycznie Zmiana kolejności danych.tabeli w pamięci RAM, a unikając jej, zachowujemy pierwotną kolejność, a także

  4. Nawet w przeciwnym razie, chyba że wykonujesz połączenia powtarzalnie, nie powinna być zauważalna różnica wydajności między keyed and ad-hoc joins.

• Czy jest zaleta keying danych.stolik?

  Keying a data.table fizycznie zmienia kolejność na podstawie tych kolumn w pamięci RAM. Obliczanie kolejności zwykle nie jest czasochłonną częścią, raczej Zmiana kolejności. Jednak gdy już mamy dane sortowane w pamięci RAM, wiersze należące do tej samej grupy są sąsiadujące ze sobą w pamięci RAM i dlatego są bardzo wydajne w pamięci podręcznej. To sortowanie przyspiesza operacje na danych z kluczem.stoły.

  Dlatego ważne jest, aby dowiedzieć się, czy czas spędzony na zmianę kolejności całych danych.tabela jest warta czasu, aby wykonać efektywne łączenie/agregację pamięci podręcznej. Zazwyczaj, o ile nie są wykonywane powtarzające się operacje grupowania / łączenia na tych samych danych Z kluczem.tabela, nie powinno być zauważalna różnica.

W większości przypadków nie powinno być już potrzeby ustawiania kluczy. Zalecamy używanie on= tam, gdzie jest to możliwe, chyba że ustawienie klawisza znacząco poprawi wydajność, którą chcesz wykorzystać.

Pytanie: jak myślisz, jak wyglądałaby wydajność w porównaniu do keyed join, jeśli użyjesz setorder()do zmiany kolejności danych .table and use on=? Jeśli do tej pory, powinieneś być w stanie to rozgryźć :-).