최적화된 쿼리 데이터 패턴

가장 간단하고 빠른 데이터 쿼리 패턴은 다음과 같습니다.

  1. 단일 테이블 또는 보기
  2. 서버에서 필요한 내용으로 사전 필터링됨
  3. 예상 쿼리에 대해 열이 올바르게 색인화되었습니다.

앱을 디자인할 때는 데이터를 빠르게 쿼리하는 방법을 생각해야 합니다. 데이터를 쿼리하는 가장 좋은 방법은 필요한 모든 정보가 포함된 단일 테이블이나 보기를 사용하고 이를 앱에 표시하기 전에 서버에서 필터링하는 것입니다. 또한 데이터를 필터링하거나 정렬하는 데 사용하는 열이 제대로 인덱싱되었는지 확인해야 합니다. 이렇게 하면 앱이 더 빠르고 부드러워집니다.

예를 들어 고객 및 영업 직원 목록을 표시하는 갤러리가 있다고 가정해 보겠습니다. 고객 및 영업 직원 정보를 별도의 테이블에 저장하는 경우 조회를 사용하여 각 고객의 영업 직원 이름을 가져와야 합니다. 이렇게 하면 다른 테이블에 대해 많은 쿼리를 실행해야 하므로 앱 속도가 느려집니다. 더 좋은 방법은 고객과 영업 직원 정보를 하나의 테이블에 결합하는 보기를 만들고 해당 보기를 갤러리의 데이터 원본으로 사용하는 것입니다. 그러면 앱은 필요한 모든 데이터를 가져오기 위해 하나의 쿼리만 실행하면 됩니다.

쿼리 속도와 데이터 정규화 사이에는 절충점이 있습니다. 데이터 정규화는 데이터를 한 번만 저장하고 중복을 방지하는 것을 의미합니다. 이는 데이터를 일관되고 정확하게 유지하는 데 도움이 됩니다. 그러나 쿼리를 더 빠르고 쉽게 만들기 위해 일부 데이터를 복제해야 하는 경우도 있습니다. 앱 디자인과 테이블 구조에서 이 두 가지 목표의 균형을 맞춰야 합니다. 그렇지 않으면 다양한 테이블의 데이터를 필터링하고 조인하기 위해 수많은 작업을 수행해야 하기 때문에 앱이 느리고 지연됩니다.

서버 측 보기 사용

보기는 아마도 이러한 목표의 균형을 맞추는 데 도움이 되는 가장 일반적인 도구일 것입니다. 쿼리를 위한 단일 테이블 구조를 제공하고, 쿼리에 필요한 데이터를 사전 필터링하고, 다른 테이블에 대한 조회 및 조인을 활성화합니다. 보기에 대한 필터, 조회 및 조인은 서버에서 계산되므로 페이로드와 클라이언트 측 계산이 모두 최소화됩니다.

갤러리는 데이터 원본의 많은 레코드를 표시할 수 있습니다. 그러나 때로는 원본과 관련된 다른 데이터 원본의 추가 정보를 표시해야 할 때도 있습니다. 예를 들어, 고객 목록을 표시하는 갤러리가 있고 각 고객에게 할당된 영업 직원의 이름을 표시하려고 합니다. 영업 직원의 이름은 고객 정보와 다른 데이터 원본에 저장됩니다. 영업 직원의 이름을 표시하려면 다른 데이터 원본에서 일치하는 레코드를 찾는 조회 기능을 사용해야 합니다. 그러면 조회 값으로 원본 테이블이 확장됩니다.

그러나 레코드가 많고 조회가 많은 경우 테이블 확장이 매우 느릴 수 있습니다. 갤러리의 각 레코드에 대해 앱은 다른 데이터 원본에 대해 별도의 쿼리를 실행하고 조회 값을 가져와야 합니다. 이는 앱이 각 레코드에 대해 많은 쿼리를 실행해야 할 수 있음을 의미하며, 이는 시간이 오래 걸리고 앱 성능에 영향을 미칠 수 있습니다. 이 안티 패턴은 "N 제곱(n^2)" 또는 "N+1" 문제라고도 합니다.

StartsWith 또는 필터 사용

Power Fx는 데이터를 검색하는 여러 가지 방법을 제공합니다. 일반적으로 In과 같이 전체 테이블을 읽는 표현식 대신 StartsWith 또는 Filter와 같은 인덱스를 활용하는 표현식을 사용합니다. In 연산자는 메모리 내 컬렉션에 적합하거나 외부 데이터 원본 테이블이 매우 작은 경우에 적합합니다.

데이터 복제 고려

데이터가 다른 위치나 형식으로 저장되어 있기 때문에 쿼리에서 데이터에 액세스하는 속도가 느린 경우가 있습니다. 쿼리 속도를 높이려면 느린 데이터를 복사하여 빠르고 쉽게 쿼리할 수 있는 테이블에 로컬로 저장할 수 있습니다. 그러나 이는 로컬 데이터가 원본 데이터의 최신 버전이 아닐 수도 있음을 의미합니다. 그런 다음 다른 프로세스를 실행하여 로컬 데이터를 주기적으로 업데이트합니다. 이 프로세스는 Power Automate 흐름, 플러그인, 저장 프로시저 또는 한 위치에서 다른 위치로 데이터를 이동할 수 있는 기타 방법일 수 있습니다.

로컬 데이터 업데이트의 빈도 요구 사항은 비즈니스 요구 사항에 따라 다릅니다. 앱의 데이터는 얼마나 최신이어야 합니까? 예를 들어 자전거 판매 회사인 Contoso에서 근무한다고 가정해 보겠습니다. 사용 가능한 자전거 목록은 사용자 지정 커넥터의 API를 통해 액세스할 수 있는 제품 데이터베이스에 저장됩니다. 그러나 API 호출이 느리기 때문에 제품 데이터를 복사하여 테이블에 로컬로 저장하기로 결정했다고 가정해 보겠습니다. 그런 다음 테이블을 앱의 다른 관련 데이터와 결합하는 보기를 만듭니다. 또한 매일 실행되고 API의 최신 제품 데이터로 테이블을 업데이트하는 Power Automate 흐름을 생성합니다. 그러면 앱에서 로컬 데이터를 더 빠르게 쿼리할 수 있으며 데이터는 최대 하루만 지난 것입니다.

데이터 복제는 엔터프라이즈급 애플리케이션에서 우수한 성능을 보장하기 위한 일반적인 유형의 기술입니다. Dataverse 플러그인, 저장 프로시저 또는 데이터 이동을 사용하여 쿼리에 최적화된 단일 테이블에 데이터를 복제할 수 있습니다. 핵심 질문은 이 데이터가 얼마나 최신이어야 하는가입니다. 약간의 지연이 허용된다면 이 기술을 사용하여 앱 속도를 높일 수 있습니다.

제안

이 목표를 달성하려면 다음 질문과 제안을 고려하십시오.

  1. 고객이 갤러리나 데이터 그리드에서 데이터 값을 보는 것이 얼마나 중요합니까? 먼저 레코드를 선택한 다음 양식에 데이터를 표시하는 것이 허용됩니까?
  2. 보기가 올바른 형식으로 데이터를 보는 데 필요한 사전 작업을 수행할 수 있나요?
  3. "StartsWith"가 작동하는 "IN" 연산자를 사용하고 있습니까?
  4. 데이터는 얼마나 최신 상태여야 합니까? 기본적으로 단일 테이블에서 쿼리가 작동하도록 하는 데 사용할 수 있는 데이터 복제 전략이 있습니까?