지속형 쿼리 결과 사용하기¶
쿼리가 실행되면 일정 기간 동안 쿼리 결과가 지속됩니다(즉, 캐시됨). 이 기간이 경과하면 시스템에서 결과가 제거됩니다.
Snowflake는 변경 사항이 없는 경우 결과가 재생성되는 것을 방지하기 위해 지속형 쿼리 결과를 사용합니다(즉, 《검색 최적화》) 또한, 지속형 쿼리 결과를 사용하여 결과의 사후 처리(예: 기존 계산 결과 위에 새 쿼리 레이어링)를 수행하는 것도 가능합니다.
모든 규모의 지속형 쿼리 결과에서 캐시 상태는 24시간 후에 만료됩니다.
대규모 지속형 쿼리 결과(100KB 이상의 크기)에 액세스하는 데 사용되는 보안 토큰이 6시간 후에 만료됩니다. 쿼리 결과가 캐시 상태에 있는 동안에는 쿼리 결과에 액세스하는 데 사용할 새 토큰을 검색할 수 있습니다. 규모가 작은 지속형 쿼리 결과에서는 액세스 토큰을 사용하지 않습니다.
참고
Spark용 Snowflake 커넥터(《Spark 커넥터》)에 제공되는 토큰은 지속형 쿼리 결과의 규모와 관계없이 24시간 후에 만료됩니다. Spark 커넥터는 일부 사용 사례에서 시간 제한을 피하기 위해 더 긴 캐시 만료 시간을 활용합니다.
이 항목의 내용:
검색 최적화¶
사용자가 이미 실행된 쿼리를 반복하고 쿼리의 마지막 실행 이후에 테이블의 데이터가 변경되지 않은 경우, 쿼리 결과는 동일합니다. Snowflake는 쿼리를 다시 실행하는 대신 이전에 반환된 결과와 동일한 결과를 반환합니다. 이를 통해 Snowflake가 쿼리를 실행하지 않고 캐시에서 직접 해당 결과를 검색하므로 쿼리 시간을 상당히 단축시킬 수 있습니다.
일반적으로 쿼리 결과는 다음의 모든 조건이 충족되면 재사용됩니다.
새 쿼리가 이전에 실행된 쿼리와 정확하게 일치합니다. 소문자/대문자 또는 테이블 별칭 사용을 포함한 구문의 차이로 인해 캐시를 100% 재사용하지 못하게 됩니다. 예를 들어 다음 쿼리를 연속적으로 실행해 보십시오.
SELECT DISTINCT(severity) FROM weather_events; SELECT DISTINCT(severity) FROM weather_events; SELECT DISTINCT(severity) FROM weather_events we; select distinct(severity) from weather_events;
첫 번째 쿼리가 캐시를 채우면 동일한 두 번째 쿼리는 100% 캐시 재사용의 이점을 누립니다. 그러나 세 번째 쿼리와 네 번째 쿼리는 캐시 재사용을 트리거하지 않는데, 이는 단지 세 번째 쿼리가 테이블 별칭을 도입하고 네 번째 쿼리가 소문자 키워드를 사용하기 때문입니다.
쿼리에는 동일한 쿼리를 연속적으로 실행할 때 서로 다른 결과를 반환하는 재사용 불가 함수가 포함되지 않습니다. UUID_STRING, RANDOM, RANDSTR 은 재사용 불가 함수의 좋은 예입니다.
이 쿼리에는 외부 함수 가 포함되지 않습니다.
쿼리 결과에 영향을 주는 테이블 데이터가 변경되지 않았습니다.
이전 쿼리에 대한 지속형 결과를 아직 사용할 수 있습니다.
캐시된 결과에 액세스하는 역할에 필수 권한이 있습니다.
쿼리가 SELECT 쿼리인 경우 쿼리를 실행하는 역할에는 캐시된 쿼리에서 사용된 모든 테이블에 대한 필수 액세스 권한이 있어야 합니다.
쿼리가 SHOW 쿼리인 경우 쿼리를 실행하는 역할은 캐시된 결과를 생성한 역할과 같아야 합니다.
결과 생성 방법에 영향을 주는 모든 구성 옵션이 변경되지 않았습니다.
테이블의 다른 데이터가 변경되어 테이블의 마이크로 파티션이 변경(예: 재클러스터링되거나 통합됨)되지 않았습니다.
참고
이러한 모든 조건을 충족한다고 해서 Snowflake에서 쿼리 결과를 재사용하는 것이 보장되지 않습니다.
기본적으로, 결과 재사용은 활성화되지만 USE_CACHED_RESULT 세션 매개 변수를 사용하여 계정, 사용자 및 세션 수준에서 재정의할 수 있습니다.
참고
쿼리에서 지속형 결과가 재사용될 때마다, Snowflake는 해당 결과에 대한 24시간 보존 기간을 재설정하며, 쿼리가 처음으로 실행된 날짜 및 시간으로부터 최대 31일까지 재설정하는 것이 가능합니다. 31일이 경과하면 결과가 제거되며, 다음 쿼리가 제출될 때 새 결과가 생성되어 유지됩니다.
쿼리 결과 후처리¶
일부 경우, 이미 실행한 쿼리의 결과에 대한 추가적인 처리가 필요할 수 있습니다. 예:
복잡한 쿼리를 단계별로 생성하는 중이고 이전 쿼리 위에 새 레이어를 추가하며 부분 결과를 처음부터 다시 계산하지 않고 새 쿼리를 실행하려는 경우를 생각해 보겠습니다.
이전 쿼리는 SHOW <오브젝트>, DESCRIBE <오브젝트> 또는 CALL 문이었으며, 재사용하기 쉽지 않은 형식으로 결과를 반환합니다.
예를 들어, SQL 문 내에서 함수를 호출하는 방식으로 복잡한 SQL 문에서는 저장 프로시저를 호출할 수 없으므로, 저장 프로시저의 출력을 처리할 수 있는 유일한 방법은 저장된 쿼리 결과에 대한 후처리를 수행하는 것입니다.
후처리는 RESULT_SCAN 테이블 함수를 사용하여 수행할 수 있습니다. 이 함수는 이전 쿼리의 결과를 《테이블》로 반환하며 새 쿼리는 테이블 형식 데이터에서 실행할 수 있습니다.
예¶
SHOW TABLES 명령의 결과를 처리한 후 결과에서 다음 열과 행을 추출합니다.
schema_name,table_name및rows열.비어 있는 테이블의 행.
SHOW TABLES; +-----+-------------------------------+-------------+-------+-------+------+ | Row | created_on | name | ... | ... | rows | +-----+-------------------------------+-------------+-------+-------+------+ | 1 | 2018-07-02 09:43:49.971 -0700 | employees | ... | ... | 2405 | +-----+-------------------------------+-------------+-------+-------+------+ | 2 | 2018-07-02 09:43:52.483 -0700 | dependents | ... | ... | 5280 | +-----+-------------------------------+-------------+-------+-------+------+ | 3 | 2018-07-03 11:43:52.483 -0700 | injuries | ... | ... | 0 | +-----+-------------------------------+-------------+-------+-------+------+ | 4 | 2018-07-03 11:43:52.483 -0700 | claims | ... | ... | 0 | +-----+-------------------------------+-------------+-------+-------+------+ | ... | | ... | +-----+-------------------------------+-------------+-------+-------+------+ -- Show the tables that are empty. SELECT "schema_name", "name" as "table_name", "rows" FROM table(RESULT_SCAN(LAST_QUERY_ID())) WHERE "rows" = 0; +-----+-------------+-------------+------+ | Row | schema_name | name | rows | +-----+-------------+-------------+------+ | 1 | PUBLIC | injuries | 0 | +-----+-------------+-------------+------+ | 2 | PUBLIC | claims | 0 | +-----+-------------+-------------+------+ | ... | | ... | +-----+-------------+-------------+------+
추가 예시는 RESULT_SCAN 에서 제공됩니다.