쿼리 쿼리

Looker는 이전 SQL 쿼리가 사용 가능하거나 캐싱 정책에 따라 이 함수가 허용되는 경우 캐시된 결과를 사용하여 데이터베이스 부하를 줄이고 성능을 개선합니다. 이 페이지에서는 Looker의 기본 캐싱 정책과 Looker 인스턴스에서 캐시된 결과의 기간을 수정하는 데 사용할 수 있는 옵션을 설명합니다.

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

SQL 쿼리의 경우 Looker의 캐싱 메커니즘은 다음과 같습니다.

  1. 탐색, Look 또는 대시보드에서 SQL 쿼리가 실행되면 Looker가 캐시를 확인하여 해당 쿼리에 대해 이미 캐시된 결과가 있는지 확인합니다. 필드, 필터, 매개변수, 행 한도를 포함하여 쿼리의 모든 측면이 동일한 경우에만 캐시된 결과가 사용됩니다.

  2. 캐시된 결과가 발견되면 Looker는 LookML 모델에 정의된 캐싱 정책을 확인하여 캐시된 결과가 만료되었는지 확인합니다. 캐시된 결과가 만료되지 않은 경우 Looker에서 쿼리에 대해 캐시된 결과를 사용합니다.

  3. 쿼리에 대해 캐시된 결과가 없거나 캐시된 결과가 만료된 경우 Looker에서 데이터베이스에 대한 쿼리를 실행합니다. 그러면 새 쿼리 결과가 캐시됩니다.

컨텍스트 주석은 캐싱에 영향을 주지 않습니다. 주석은 캐시 항목 일치를 위해 쿼리의 일부로 저장되지 않습니다.

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

캐시 보관 정책 수정

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

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

더 간단한 접근 방식을 사용하려면 대신 모델 수준 또는 탐색 수준에서 persist_for 매개변수를 사용할 수 있습니다. 이러한 방식으로 persist_for 매개변수를 사용하면 기본 만료 시간 1시간을 재정의하는 캐시 만료 간격을 설정할 수 있습니다. 그러나 persist_for를 사용하면 몇 가지 이유로 데이터 그룹을 사용하는 것보다 덜 강력합니다. 자세한 내용은 Sustain_for로 쿼리 캐싱 섹션을 참고하세요.

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

캐시에서 쿼리 반환 여부 확인

쿼리를 실행한 후 오른쪽 상단을 보면 탐색 창에서 캐시에서 쿼리가 반환되었는지 확인할 수 있습니다.

쿼리가 캐시에서 반환된 경우에는 '캐시에서'가 표시됩니다. 그렇지 않으면 쿼리를 반환하는 데 걸린 시간이 표시됩니다.

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

Explore 창에서는 데이터베이스에서 강제로 새 결과를 검색할 수 있습니다. 병합된 결과 쿼리를 포함하여 쿼리를 실행한 다음 화면 오른쪽 상단에 있는 탐색 작업 톱니바퀴 메뉴에서 캐시 지우기 및 새로고침 옵션을 선택합니다.

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

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

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

또는 데이터 그룹을 사용하여 최대 캐시 기간으로부터 PDT 다시 빌드 트리거를 분리할 수 있습니다. 이는 매우 자주 업데이트되는 데이터를 기반으로 하고 재빌드가 적은 PDT에 결합된 탐색이 있는 경우 유용할 수 있습니다. 이 경우 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에 대해 다시 빌드 트리거 지정

데이터 그룹을 사용하여 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가 다른 PDT에 종속되는 연쇄 PDT가 있으면 호환되지 않는 데이터 그룹 캐싱 정책을 지정하지 않도록 주의하세요.

연결 매개변수를 지정하기 위한 사용자 속성이 있는 연결의 경우, 다음 중 하나를 수행해야 하면 PDT 재정의 필드를 사용하여 개별 연결을 만들어야 합니다.
• 모델에 PDT를 사용합니다.
• 데이터 그룹을 사용하여 PDT 다시 빌드 트리거를 정의합니다.
PDT 재정의가 없어도 max_cache_age가 있는 데이터 그룹을 사용하여 Explore에 대해 캐싱 정책을 정의할 수 있습니다.

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

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

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

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

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가 사용됩니다.

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

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

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

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

persist_for를 사용한 쿼리 캐싱

모델 수준 또는 탐색 수준에서 persist_for 매개변수를 사용하여 Looker의 기본 캐시 보관 간격인 1시간을 수정합니다. 간격은 0 minutes부터 8760 hours (1년) 이상까지 설정할 수 있습니다.

persist_for 매개변수를 정의하는 것은 데이터 그룹을 정의하는 것보다 빠르고 간단하지만 덜 강력할 수 있습니다. 다음과 같은 이유로 persist_for보다 데이터 그룹을 사용하는 것이 좋습니다.

  • 데이터 그룹은 데이터베이스의 ETL 프로세스와 동기화할 수 있습니다.
  • 여러 모델과 탐색에서 데이터 그룹을 재사용할 수 있습니다. 즉, 데이터 그룹의 max_cache_age를 업데이트할 수 있으며 데이터 그룹이 사용되는 모든 위치에서 캐싱 정책이 업데이트됩니다.
  • 데이터 그룹 페이지에서 데이터 그룹과 연결된 모든 캐시를 지울 수 있습니다.