이 권장사항에는 Looker에 익숙한 교차 기능팀에서 공유한 권장사항이 반영되어 있습니다. 이 유용한 정보는 Looker 고객과 함께한 구현부터 장기적 성공에 이르는 수년간의 경험을 통해 얻은 것입니다. 대부분의 사용자와 상황에 적합하도록 권장사항을 작성했지만 권장사항을 구현할 때는 항상 신중하게 판단하시기 바랍니다.
쿼리 성능 최적화
다음 프런트엔드 및 백엔드 도움말을 사용하여 데이터베이스에 대해 쿼리가 최적으로 빌드되고 실행되도록 할 수 있습니다.
가능하면 many_to_one 조인을 사용하여 Explore를 빌드하세요. 가장 세분화된 수준에서 가장 높은 수준의 세부정보(many_to_one)까지 뷰를 조인하면 일반적으로 쿼리 성능이 가장 뛰어납니다.
가능한 경우 ETL 정책과 동기화되도록 캐싱을 극대화하여 데이터베이스 쿼리 트래픽을 줄입니다. 기본적으로 Looker는 쿼리를 1시간 동안 캐시합니다. persist_with 매개변수를 사용하여 Explore 내에서 데이터 그룹을 적용하여 캐싱 정책을 제어하고 Looker 데이터 새로고침을 ETL 프로세스와 동기화할 수 있습니다. 이렇게 하면 Looker가 백엔드 데이터 파이프라인과 더 긴밀하게 통합되므로 오래된 데이터를 분석할 위험 없이 캐시 사용을 극대화할 수 있습니다. 이름이 지정된 캐싱 정책은 전체 모델 또는 개별 Explore 및 영구 파생 테이블(PDT)에 적용할 수 있습니다.
Looker의 집계 인식 기능을 사용하여 Looker가 가능한 경우 쿼리에 사용할 수 있는 롤업 또는 요약 테이블을 만듭니다(특히 대규모 데이터베이스의 일반적인 쿼리). 집계 인식을 활용하면 전체 대시보드의 성능을 대폭 개선할 수도 있습니다. 자세한 내용은 집계 인식 튜토리얼을 참조하세요.
더 빠른 쿼리를 위해 PDT를 사용하세요. 뷰가 미리 조인되어 런타임 전에 준비되도록 하려면 Explore를 여러 복잡한 조인 또는 성능이 떨어지는 조인으로, 또는 하위 쿼리나 하위 선택이 있는 측정기준을 PDT로 변환합니다.
색인을 선언합니다. 테이블의 톱니바퀴 아이콘을 클릭하고 색인 표시를 선택하면 SQL Runner에서 바로 Looker에서 각 테이블의 색인을 볼 수 있습니다.
색인의 혜택을 받을 수 있는 가장 일반적인 열은 중요한 날짜와 외래 키입니다. 이러한 열에 색인을 추가하면 거의 모든 쿼리의 성능이 향상됩니다. 이는 PDT에도 적용됩니다. indexes, sort keys, distribution와 같은 LookML 매개변수를 적절하게 적용할 수 있습니다.
하드웨어가 부족하거나 대용량 데이터 세트를 처리하는 데 필요한 프로비저닝된 리소스(예: AWS)가 있는 데이터베이스의 메모리, 코어, I/O(입력/출력)를 늘려 쿼리 성능을 높입니다.
Looker 서버 성능 최적화
Looker 서버와 애플리케이션의 성능이 최적화되도록 조치를 취할 수도 있습니다.
개별 대시보드 내의 요소 수를 제한합니다. 각 요소의 설계는 다양한 요인에 따라 메모리 소비에 영향을 미치므로 요소 수를 정의하는 정확한 규칙은 없습니다. 하지만 타일이 25개 이상인 대시보드는 성능 측면에서 문제가 되는 경향이 있습니다.
대시보드 자동 새로고침 기능을 전략적으로 사용합니다. 대시보드에서 자동 새로고침을 사용하는 경우 백그라운드에서 실행되는 ETL 프로세스보다 빨리 새로고침되지 않도록 합니다.
피벗을 전략적으로 사용하고 대시보드 타일과 Look에 피벗을 과도하게 사용하지 마세요. 피벗된 측정기준이 있는 쿼리는 더 많은 메모리를 사용합니다. 피벗되는 측정기준이 많을수록 콘텐츠(Explore, Look 또는 대시보드)가 로드될 때 더 많은 메모리가 사용됩니다.
병합 결과, 커스텀 필드, 테이블 계산과 같은 기능은 가급적 사용하지 마세요.
이 기능은 모델을 설계하는 데 도움이 되는 개념 증명으로 사용됩니다.
LookML에서 자주 사용되는 계산 및 함수를 하드코딩하는 것이 좋습니다. 그러면 데이터베이스에서 처리할 SQL이 생성됩니다.
과도한 계산은 Looker 인스턴스에서 Java 메모리를 놓고 경쟁하여 Looker 인스턴스의 응답 속도가 느려질 수 있습니다.
뷰 파일이 많은 경우 모델에 포함되는 뷰 수를 제한합니다. 단일 모델에 모든 뷰를 포함하면 성능이 느려질 수 있습니다. 프로젝트 내에 뷰가 많은 경우 각 모델에 필요한 뷰 파일만 포함하는 것이 좋습니다. 모델 내에 뷰 그룹을 쉽게 포함할 수 있도록 뷰 파일 이름에 전략적 이름 지정 규칙을 사용하는 것이 좋습니다. 예시는 includes 매개변수 문서에 설명되어 있습니다.
대시보드 타일과 Look 내에서 기본적으로 많은 수의 데이터 포인트를 반환하지 마세요. 수천 개의 데이터 포인트를 반환하는 쿼리는 더 많은 메모리를 사용합니다. 프런트엔드 필터를 대시보드, Look, Explore, 그리고 required filters, conditionally_filter 및 sql_always_where 매개변수가 있는 LookML 수준에 적용하여 최대한 데이터를 제한합니다.
모든 결과 옵션을 꼭 필요한 경우에만 사용하여 쿼리를 다운로드하거나 전송하세요. 일부 쿼리는 매우 크며 처리 시 Looker 서버에 부담을 줄 수 있습니다.
성능 문제의 원인을 파악하는 데 도움이 더 필요한 경우 성능 개요 권장사항 페이지를 참고하세요.
[[["이해하기 쉬움","easyToUnderstand","thumb-up"],["문제가 해결됨","solvedMyProblem","thumb-up"],["기타","otherUp","thumb-up"]],[["이해하기 어려움","hardToUnderstand","thumb-down"],["잘못된 정보 또는 샘플 코드","incorrectInformationOrSampleCode","thumb-down"],["필요한 정보/샘플이 없음","missingTheInformationSamplesINeed","thumb-down"],["번역 문제","translationIssue","thumb-down"],["기타","otherDown","thumb-down"]],["최종 업데이트: 2025-07-31(UTC)"],[],[],null,["# Optimize Looker performance\n\n\u003e *These best practices reflect recommendations shared by a cross-functional team of seasoned Lookers. These insights come from years of experience working with Looker customers from implementation to long-term success. The practices are written to work for most users and situations, but you should use your best judgment when implementing.*\n\nOptimize query performance\n--------------------------\n\n\nYou can ensure that queries are built and executed optimally against your database with the following frontend and backend tips:\n\n- Build Explores using [`many_to_one`](/looker/docs/reference/param-explore-join-relationship#many_to_one_(the_default_value)) joins whenever possible. Joining views from the most granular level to the highest level of detail (`many_to_one`) typically provides the best query performance.\n- Maximize caching to sync with your ETL policies wherever possible to reduce database query traffic. By default, Looker caches queries for one hour. You can control the caching policy and sync Looker data refreshes with your ETL process by applying [datagroups](/looker/docs/caching-and-datagroups) within Explores, using the [`persist_with`](/looker/docs/reference/param-explore-persist-with) parameter. This enables Looker to integrate more closely with the backend data pipeline, so cache usage can be maximized without the risk of analyzing stale data. Named caching policies can be applied to an entire model and/or to individual Explores and [persistent derived tables](/looker/docs/caching-and-datagroups#how_looker_uses_pdts_and_rebuilds_them) (PDTs).\n- Use Looker's [aggregate awareness](/looker/docs/aggregate_awareness) functionality to create roll-ups or summary tables that Looker can use for queries whenever possible, especially for common queries of large databases. You can also leverage aggregate awareness to drastically [improve the performance of entire dashboards](/looker/docs/reference/param-explore-aggregate-table#get_lookml_dashboard). See the [Aggregate awareness tutorial](/looker/docs/best-practices/aggregate-awareness-tutorial) for additional information.\n- Use [PDTs](/looker/docs/derived-tables#persistent_derived_table) for faster queries. Convert Explores with many complex or unperformant joins, or dimensions with subqueries or subselects, into PDTs so that the views are pre-joined and ready prior to runtime.\n- If your [database dialect supports incremental PDTs](/looker/docs/incremental-pdts#supported_database_dialects_for_incremental_pdts), configure [incremental PDTs](/looker/docs/incremental-pdts) to reduce the time Looker spends rebuilding PDT tables.\n- Avoid joining views into Explores on concatenated [primary keys](/looker/docs/reference/param-field-primary-key) that are defined in Looker. Instead, join on the base fields that make up the concatenated primary key from the view. Alternatively, recreate the view as a PDT with the concatenated primary key predefined in the table's SQL definition, rather than in a view's LookML.\n- Leverage the [Explain in SQL Runner tool](/looker/docs/sql-runner-manage-db#examining_an_execution_plan_using_explain) for benchmarking. `EXPLAIN` produces an overview of your database's query execution plan for a given SQL query, letting you detect query components that can be optimized. Learn more in the [How to optimize SQL with `EXPLAIN`](https://community.looker.com/technical-tips-tricks-1021/how-to-optimize-sql-with-explain-30772) Community post.\n- Declare indexes. You can look at the indexes of each table directly in Looker from [SQL Runner](/looker/docs/sql-runner-basics) by clicking the gear icon in a table and then selecting [**Show Indexes**](/looker/docs/sql-runner-manage-db#getting_table_information).\n\n \u003cbr /\u003e\n\n The most common columns that can benefit from indexes are important dates and foreign keys. Adding indexes to these columns will increase performance for almost all queries. This also applies for PDTs. LookML parameters, such as [`indexes`](/looker/docs/reference/param-view-indexes), [`sort keys`](/looker/docs/reference/param-view-sortkeys), and [`distribution`](/looker/docs/reference/param-view-distribution), can be applied appropriately.\n- Increase memory, cores, and I/O (input/output) of databases with insufficient hardware or necessary provisioned resources (such as AWS) for processing large datasets, to increase query performance.\n\nOptimize Looker server performance\n----------------------------------\n\n\nYou can also take measures to ensure that the Looker server and application are performing optimally:\n\n- Limit the number of elements within an individual dashboard. There is no precise rule for defining the number, because the design of each element impacts memory consumption based on a variety of factors; however, dashboards with 25 or more tiles tend to be problematic when it comes to performance.\n- Use the [dashboard auto refresh](/looker/docs/editing-user-defined-dashboards#autorefresh) feature strategically. If a dashboard uses auto refresh, make sure it refreshes no faster than the ETL processes running behind the scenes.\n- Use pivots strategically, and avoid over-using pivots within dashboard tiles and Looks. Queries with pivoted dimensions will consume more memory. The more dimensions that are pivoted, the more memory is consumed when content (an Explore, a Look, or a dashboard) is loaded.\n- Use features, such as [merge results](/looker/docs/merged-results), [custom fields](/looker/docs/custom-fields), and [table calculations](/looker/docs/table-calculations), sparingly. These features are intended to be used as proofs of concept to help design your model. It is best practice to hardcode any frequently used calculations and functions in LookML, which will generate SQL to be processed on your database. Excessive calculations can compete for Java memory on the Looker instance, causing the Looker instance to respond more slowly.\n- Limit the number of views included within a model when a large number of view files are present. Including all views in a single model can slow performance. When a large number of views are present within a project, consider including only the view files needed within each model. Consider using strategic naming conventions for view file names, to enable easy inclusion of groups of views within a model. An example is outlined in the [`includes`](/looker/docs/reference/param-model-include#things_to_know) parameter documentation.\n- Avoid returning a large number of data points by default within dashboard tiles and Looks. Queries that return thousands of data points will consume more memory. Ensure that data is limited wherever possible by applying frontend [filters](/looker/docs/filters-user-defined-dashboards#adding_dashboard_filters) to dashboards, Looks and Explores, and on the LookML level with [`required filters`](/looker/docs/filters-user-defined-dashboards#requiring_a_filter_value), [`conditionally_filter`](/looker/docs/reference/param-explore-conditionally-filter) and [`sql_always_where`](/looker/docs/reference/param-explore-sql-always-where) parameters.\n- Download or deliver queries using the [**All Results**](/looker/docs/downloading#all_results) option sparingly, as some queries can be very large and overwhelm the Looker server when processed.\n\n\nFor more help identifying the source of performance issues, check out the [Performance overview](/looker/docs/best-practices/how-to-optimize-looker-performance) Best Practices page."]]
