1
보조 인덱스와 함께 Interleave 옵션을 사용하는 경우에도 여전히 저장 절을 사용하면 도움이됩니까? 그것이 큰 도움이 될 가능성이 적습니다 비록Cloud Spanner에서 INTERLEAVE 보조 인덱스에 STORING 절을 사용하면 어떤 이점이 있습니까?
https://cloud.google.com/spanner/docs/secondary-indexes
A
답변
1
예는, 여전히 이점이 될 수 있습니다
하는의 당신이 테이블 Singers-> Albums-> 노래를 인터리브 있다고 가정 해 봅시다, 당신은 인덱스를 가지고 :
CREATE INDEX SongsBySingerSongName ON Songs(SingerId, SongName),
INTERLEAVE IN Singers
는의도 Songs 노래의 길이를 저장하는 FLOAT64 열, LengthInSeconds을 가지고 있다고 가정하자.
- 이 가수의 모든 노래를 조회 할
SongsBySingerSongName사용 : 당신이 "T"로 시작 미만 사분 긴했다SingerId(123)에 대한 모든 노래를 검색하고 싶다면, 귀하의 질의에 의해 실행될 수 있습니다 123 은 "T"로 시작합니다.
- 이 노래의 경우 길이가 필터링하려면
Songs에서 으로 다시 연결하십시오.LengthInSeconds모두Songs및SongsBySingerSongName이후
가 Singers 테이블에 인터리빙, 우리는 우리의 데이터는 모두가 모든 단계에서 다시는 조인 의미 동일한 시스템에 상주 즉, 같은 split에 있어야 알고 (2) 끔찍한 비용이 들지는 않습니다. 그러나 로컬 백 조인은 여전히 데이터를 검색하는 데 비용이 발생하므로 STORING 절을 사용하여 단계 (2)를 저장하면 쿼리 대기 시간과 전체 비용이 줄어들 수 있습니다. 워크로드의 벤치마킹을 수행하여 여분의 저장 절이 순 이점을 제공하는지 확인하고자 할 것입니다.
일반적으로 인덱스에있는 열 (키 열 또는 '저장'열)을 참조하는 필터가 쿼리에있는 경우 기본 테이블에 대한 다시 조인을 수행하기 전에 필터를 평가할 수 있습니다. 필터가 일치하지 않으면 백 - 조인을 피할 수 있습니다. 필터가 인덱스에없는 열을 참조하는 경우 필터가 참조하는 열 값을 얻으려면 먼저 뒤쪽 조인을 수행해야합니다.