현재 Looker 문서를 보고 있습니다. Looker Studio 문서는 https://support.google.com/looker-studio를 방문하세요.

쿼리 캐싱

Looker는 사용 가능하고 캐싱 정책에서 이 기능을 허용하는 경우 이전 SQL 쿼리의 캐시된 결과를 사용하여 데이터베이스의 로드를 줄이고 성능을 향상시킵니다. 이 페이지에서는 Looker의 기본 캐싱 정책과 Looker 인스턴스에서 캐시된 결과의 기간을 수정하는 데 사용할 수 있는 옵션을 설명합니다.

Looker에서 캐시된 쿼리 사용 방법

SQL 쿼리에 대해 Looker에서 캐싱 메커니즘은 다음과 같이 작동합니다.

Explore, Look 또는 대시보드에서 SQL 쿼리가 실행되면 Looker는 캐시를 확인하여 해당 쿼리에 대해 이미 캐시된 결과가 있는지 확인합니다. 캐시된 결과는 필드, 필터, 파라미터, 행 한도를 포함하여 쿼리의 모든 측면이 동일한 경우에만 사용됩니다.
캐시된 결과가 발견되면 Looker에서 LookML 모델에 정의된 캐싱 정책을 확인하여 캐시된 결과가 만료되었는지 확인합니다. 캐시된 결과가 만료되지 않은 경우 Looker는 쿼리에 캐시된 결과를 사용합니다.
쿼리에 대해 캐시된 결과가 없거나 캐시된 결과가 만료된 경우 Looker가 데이터베이스에 대해 쿼리를 실행합니다. 그러면 새 쿼리 결과가 캐시됩니다.

기본 캐시 보관 정책은 1시간입니다. 다음 섹션인 캐시 보관 정책 수정에서는 이 기간을 단축하거나 연장하는 방법과 캐시 보관 정책을 데이터베이스의 ETL(추출, 변환, 로드) 프로세스와 동기화하는 옵션을 설명합니다.

캐시 보관 정책 수정

LookML Explore 수준 및 LookML 모델 수준에서 캐시 보관 정책을 지정할 수 있습니다.

권장 캐싱 메커니즘은 모델 수준에서 datagroup 파라미터를 사용하는 것입니다. 데이터 그룹을 사용하면 sql_trigger 파라미터를 사용하고 캐시 만료 간격을 max_cache_age 파라미터로 설정하여 모델의 캐시 보관 정책을 데이터베이스의 ETL 일정과 동기화할 수 있습니다. 자세한 내용은 데이터 그룹으로 쿼리 캐시 및 PDT 다시 빌드 섹션을 참조합니다.

더 간단한 방법은 모델 수준 또는 Explore 수준에서 persist_for 파라미터를 대신 사용할 수 있습니다. 이러한 방식으로 persist_for 파라미터를 사용하면 기본 만료 시간 1시간을 재정의하는 캐시 만료 간격을 설정할 수 있습니다. 하지만 persist_for를 사용하는 것은 persist_for로 쿼리 캐싱 섹션에서 설명한 것처럼 몇 가지 이유로 데이터 그룹을 사용하는 것보다 강력하지 않습니다.

Explore 또는 모델에 데이터 그룹 또는 persist_for이 정의되어 있으면 캐싱 정책은 다음과 같이 수정됩니다.

persist_for 간격 또는 데이터 그룹의 max_cache_age 간격 이전: 쿼리가 다시 실행되면 Looker가 캐시에서 데이터를 가져옵니다.
persist_for 간격 또는 데이터 그룹의 max_cache_age 간격이 종료되는 시간: Looker가 캐시에서 데이터를 삭제합니다.
persist_for 간격 또는 데이터 그룹의 max_cache_age 간격이 만료된 후: 쿼리가 다시 실행되면 Looker가 데이터베이스에서 데이터를 직접 가져와 persist_for 또는 max_cache_age 간격을 재설정합니다.

여기서 한 가지 핵심은 persist_for 또는 max_cache_age 간격이 만료되면 캐시에서 데이터가 삭제된다는 것입니다.

캐시가 스토리지 한도에 도달하면 가장 오래 전에 사용된 항목(LRU) 알고리즘을 기준으로 데이터가 삭제되고, persist_for 또는 max_cache_age 간격이 만료된 데이터가 전부 한 번에 삭제된다는 보장은 없습니다.

데이터가 캐시에서 소비하는 시간 최소화

Looker는 항상 쿼리 결과를 캐시에 작성합니다. persist_for 및 max_cache_age 간격이 0으로 설정된 경우에도 캐시된 데이터가 최대 10분 동안 저장될 수 있습니다. 디스크 캐시에 저장되는 모든 고객 데이터는 고급 암호화 표준(AES)으로 암호화됩니다.

데이터가 캐시에 저장되는 시간을 최소화하려면 다음 안내를 따릅니다.

모든 persist_for 파라미터(모델 또는 Explore) 또는 max_cache_age 파라미터(데이터 그룹)에 대해 값을 0 minutes로 설정합니다. persist_for 간격이 만료되거나 데이터가 데이터 그룹에 지정된 max_cache_age 간격에 도달하면 Looker가 캐시를 삭제합니다. (캐시에 저장되는 데이터 양을 최소화하기 위해 PDT의 persist_for 파라미터를 0 minutes로 설정할 필요가 없습니다. PDT는 캐시가 아닌 데이터베이스 자체에 기록됩니다.)
suggest_persist_for 파라미터를 작은 간격으로 설정합니다. suggest_persist_for 값은 Looker가 필터 제안을 캐시에 보관하는 기간을 지정합니다. 필터 추천은 필터링되는 필드의 값 쿼리를 기반으로 합니다. 이러한 쿼리 결과는 캐시에 보관되므로 사용자가 필터 텍스트 필드에 타이핑할 때 Looker가 빠르게 제안을 제공할 수 있습니다. 기본값은 6시간 동안 필터 제안을 캐시하는 것입니다. 데이터가 캐시에 있는 기간을 최소화하려면 suggest_persist_for 값을 5 minutes 정도의 낮은 값으로 설정합니다.

쿼리가 캐시에서 반환되었는지 확인

Explore 창에서는 쿼리를 실행한 후 Run 버튼 옆의 정보를 보고 쿼리가 캐시에서 반환되었는지 여부를 확인할 수 있습니다.

쿼리가 캐시에서 반환되면 "from cache" 텍스트가 표시됩니다. 그렇지 않으면 쿼리를 반환하는 데 걸린 시간이 표시됩니다.

데이터베이스에서 강제로 새 결과 생성

Explore 창에서는 데이터베이스에서 강제로 새 결과를 검색할 수 있습니다. 쿼리를 실행한 후(병합된 결과 쿼리 포함) 작업 살펴보기 톱니바퀴 메뉴에서 캐시 삭제 및 새로고침 옵션을 선택하세요.

데이터 그룹으로 쿼리 캐시 및 PDT 다시 빌드

데이터 그룹을 사용하여 Looker의 캐싱 정책 및 PDT 다시 빌드 일정에 따라 데이터베이스의 ETL(추출, 변환, 로드) 일정을 조정합니다.

새 데이터가 데이터베이스에 추가되는 시간을 기준으로 데이터 그룹을 사용해서 PDT 트리거 다시 빌드를 지정할 수 있습니다. 그런 다음 동일한 데이터 그룹을 Explore 또는 모델에 적용하여 PDT가 다시 빌드될 때 캐시된 결과도 만료되도록 할 수 있습니다.

또는 데이터 그룹을 사용하여 최대 캐시 기간으로부터 PDT 다시 빌드 트리거를 분리할 수 있습니다. 매우 자주 업데이트되는 데이터를 기반으로 하고 더 자주 재빌드되는 PDT에 조인되는 Explore를 사용하는 경우 유용할 수 있습니다. 이 경우 PDT를 다시 빌드하는 것보다 더 자주 쿼리 캐시를 재설정해야 할 수 있습니다.

데이터 그룹 정의

모델 파일 또는 자체 LookML 파일에서 datagroup 파라미터를 사용하여 데이터 그룹을 정의합니다. 프로젝트의 각 Explore 또는 PDT에 대해 서로 다른 캐싱 및 PDT 다시 빌드 정책이 필요하면 여러 데이터 그룹을 정의할 수 있습니다.

datagroup 파라미터에는 다음과 같은 하위 파라미터가 포함될 수 있습니다.

label — 데이터 그룹에 대해 선택적인 라벨을 지정합니다.
description — 데이터 그룹의 목적 및 메커니즘을 설명하는 데 사용할 수 있는 데이터 그룹에 대한 선택적인 설명을 지정합니다.
max_cache_age — 기간을 정의하는 문자열을 지정합니다. 쿼리의 캐시 기간이 이 기간을 초과하면 Looker가 캐시를 무효화합니다. 다음에 쿼리가 실행되면 새로운 결과를 얻기 위해 Looker가 쿼리를 데이터베이스로 전송합니다.
sql_trigger — 하나의 열과 하나의 행을 반환하는 SQL 쿼리를 지정합니다. 쿼리로 반환된 값이 쿼리의 이전 결과와 다르면 데이터 그룹이 트리거된 상태로 전환됩니다.
interval_trigger — 데이터 그룹을 트리거하기 위한 시간 일정을 지정합니다(예: "24 hours").

최소한 데이터 그룹에는 max_cache_age 파라미터, sql_trigger 파라미터 또는 interval_trigger 파라미터가 있어야 합니다.

PDT를 매일 다시 빌드하도록 sql_trigger가 설정된 데이터 그룹의 예시는 다음과 같습니다. 또한 Explore가 하루 한 번 이상 자주 새로고침되는 다른 데이터에 PDT를 가입시키는 경우를 대비해서 max_cache_age는 2시간마다 쿼리 캐시를 지우도록 설정됩니다.

datagroup: customers_datagroup {
  sql_trigger: SELECT DATE(NOW());;
  max_cache_age: "2 hours"
}

데이터 그룹을 정의한 후 이를 Explore 및 PDT에 할당할 수 있습니다.

PDT에 데이터 그룹을 할당하려면 derived_table 파라미터 아래의 datagroup_trigger 파라미터를 사용합니다. 예시는 이 페이지의 데이터 그룹을 사용하여 PDT에 대한 다시 빌드 트리거 지정 섹션을 참조합니다.
Explore에 데이터 그룹을 할당하려면 모델 수준 또는 Explore 수준에서 persist_with 파라미터를 사용합니다. 예시는 이 페이지의 데이터 그룹을 사용하여 Explore에 대한 쿼리 캐시 재설정 지정 섹션을 참조합니다.

데이터 그룹을 사용하여 PDT에 대해 다시 빌드 트리거 지정

데이터 그룹을 사용하여 PDT 다시 빌드 트리거를 정의하려면 sql_trigger 또는 interval_trigger 하위 파라미터를 사용하여 datagroup 파라미터를 만듭니다. 그런 후 PDT의 derived_table 정의에서 datagroup_trigger 하위 파라미터를 사용하여 개별 PDT에 데이터 그룹을 할당합니다. PDT에 datagroup_trigger를 사용하는 경우 파생 테이블에 대해 다른 지속성 전략을 지정할 필요가 없습니다. PDT에 대해 여러 지속성 전략을 지정할 경우 Looker IDE에 경고가 표시되고 datagroup_trigger만 사용됩니다.

다음은 customers_datagroup 데이터 그룹을 사용하는 PDT 정의의 예시입니다. 이 정의는 또한 customer_id 및 first_order_date 모두에 여러 색인을 추가합니다. PDT 정의에 대한 자세한 내용은 Looker의 파생 테이블 문서 페이지를 참조합니다.

view: customer_order_facts {
  derived_table: {
    sql: ... ;;
    datagroup_trigger: customers_datagroup
    indexes: ["customer_id", "first_order_date"]
  }
}

데이터 그룹이 PDT에서 작동하는 방법에 대한 자세한 내용은 Looker의 파생 테이블 문서 페이지를 참조합니다.

데이터 그룹을 사용하여 Explore에 대한 쿼리 캐시 재설정 지정

데이터 그룹이 트리거되면 Looker 재생기가 데이터 그룹을 지속성 전략으로 사용하는 PDT를 다시 빌드합니다. 데이터 그룹의 PDT가 다시 빌드되면 Looker가 데이터 그룹의 다시 빌드된 PDT를 사용하는 Explore에 대해 캐시를 지웁니다. 데이터 그룹에 대해 쿼리 캐시 재설정 일정을 맞춤설정하려면 데이터 그룹 정의에 max_cache_age 파라미터를 추가할 수 있습니다. max_cache_age 파라미터를 사용하면 데이터 그룹의 PDT가 다시 빌드될 때 Looker가 수행하는 자동 쿼리 캐시 재설정 외에도 지정된 일정에 따라 쿼리 캐시를 지울 수 있습니다.

데이터 그룹으로 쿼리 캐싱 정책을 정의하려면 max_cache_age 하위 파라미터와 함께 datagroup 파라미터를 만듭니다.

Explore에서 쿼리 캐시 재설정에 사용할 데이터 그룹을 지정하려면 persist_with 파라미터를 사용합니다.

모델의 모든 Explore에 대해 데이터 그룹을 기본값으로 할당하려면 모델 수준(모델 파일)에서 persist_with 파라미터를 사용합니다.
개별 Explore에 데이터 그룹을 할당하려면 explore 파라미터 아래의 persist_with 파라미터를 사용합니다.

다음 예시는 모델 파일에 정의된 orders_datagroup이라는 데이터 그룹을 보여줍니다. 데이터 그룹에는 ETL이 발생한 시간을 감지하는 데 select max(id) from my_tablename 쿼리를 사용하도록 지정하는 sql_trigger 파라미터가 포함되어 있습니다. 한 동안 ETL이 발생하지 않더라도 데이터 그룹의 max_cache_age에 따라 최대 24시간 동안만 캐시된 데이터가 사용되도록 지정됩니다.

모델의 persist_with 파라미터는 orders_datagroup 캐싱 정책을 가리킵니다. 즉, 이것이 모델에 있는 모든 Explore의 기본 캐싱 정책이 됩니다. 그러나 customer_facts 및 customer_background Explore에 대해 모델의 기본 캐싱 정책을 사용하지 않기 때문에 이러한 두 Explore에 대해 서로 다른 캐싱 정책을 지정하도록 persist_with 파라미터를 추가할 수 있습니다. orders 및 orders_facts Explore는 persist_with 파라미터가 없으므로, 모델의 기본 캐싱 정책인 orders_datagroup을 사용합니다.

datagroup: orders_datagroup {
  sql_trigger: SELECT max(id) FROM my_tablename ;;
  max_cache_age: "24 hours"
}

datagroup: customers_datagroup {
  sql_trigger: SELECT max(id) FROM my_other_tablename ;;
}

persist_with: orders_datagroup

explore: orders { ... }

explore: order_facts { ... }

explore: customer_facts {
  persist_with: customers_datagroup
  ...
}

explore: customer_background {
  persist_with: customers_datagroup
  ...
}

persist_with 및 persist_for 모두 지정된 경우 검증 경고가 표시되고 persist_with가 사용됩니다.

데이터 그룹을 사용하여 예약된 전송 트리거

데이터 그룹은 대시보드 또는 Look 전송을 트리거하는 데도 사용될 수 있습니다. 이 옵션을 사용하면 데이터 그룹이 완료될 때 Looker가 데이터를 전송하므로, 예약된 콘텐츠가 최신 상태입니다.

데이터 그룹에 관리 패널 사용

Looker 관리자 역할이 있으면 관리 패널의 데이터 그룹 페이지를 사용하여 기존 데이터 그룹을 볼 수 있습니다. 각 데이터 그룹의 연결, 모델, 현재 상태를 보고, LookML에 지정된 경우 각 데이터 그룹의 라벨 및 설명을 볼 수 있습니다. 또한 데이터 그룹의 캐시를 재설정하거나, 데이터 그룹을 트리거하거나, 데이터 그룹의 LookML로 이동할 수 있습니다.

`persist_for`를 사용한 쿼리 캐싱

모델 수준 또는 Explore 수준에서 persist_for 파라미터를 사용하여 Looker의 기본 캐시 보관 간격을 1시간으로 수정합니다. 간격을 작게는 0 minutes에서 크게는 8760 hours(1년) 이상으로 설정할 수 있습니다.

persist_for 파라미터를 정의하는 것은 데이터 그룹을 정의하는 것보다 빠르고 간단하지만 덜 강력합니다. 다음과 같은 이유로 persist_for보다 데이터 그룹을 권장합니다.

데이터 그룹은 데이터베이스의 ETL 프로세스와 동기화할 수 있습니다.
여러 모델 및 Explore에서 데이터 그룹을 재사용할 수 있습니다. 즉, 데이터 그룹의 max_cache_age을 업데이트하면 데이터 그룹이 사용되는 각 위치에서 캐싱 정책을 업데이트합니다.
데이터 그룹 페이지에서 데이터 그룹과 연결된 모든 캐시를 삭제할 수 있습니다.