XPath 쿼리를 최적화하는 다양한 방법
XPath 쿼리를 작성할 때 주의해야 할 몇 가지 사항이 있습니다. 가장 쉽게 적용할 수 있는 최적화는 변수를 객체가 아닌 associations과 비교하는 것입니다. 예를 들어 AdventureWorks 직원들이 애플리케이션에 웹 상점을 추가해 달라고 요청한다고 가정해 보겠습니다. 이를 위해서는 계정 개요 페이지에 사용자 정보를 표시하기 위해 현재 사용자를 기준으로 고객 정보를 검색해야 합니다.
이를 위한 XPath는 다음과 같습니다:
[Sales.Customer_Account/Administration.Account/id = $currentUser]이 XPath 표현식은 account 개체를 검색하기 때문에 최적이 아닙니다. account 개체를 검사할 필요 없이 개체가 존재한다는 사실만 알면 됩니다. 엔티티와 id 속성을 제거하면 이 표현식을 더 효율적으로 작성할 수 있습니다:
[Sales.Customer_Account = $currentUser]이렇게 하면 애플리케이션을 더 효율적이고 빠르게 만들 수 있습니다.
최적화할 수 있는 또 다른 예는 이전 모듈의 마지막 예제입니다. not() 함수를 사용하여 연결이 존재하는지 확인했습니다. 멘딕스가 생성하는 기본 쿼리는 관련 엔티티에 대한 하위 쿼리의 모든 데이터를 검색하지만 "같음" 및 "같지 않음"과 같은 비교 연산자는 검색하지 않습니다. 따라서 가능하면 마이크로플로우를 위해 not() 함수의 사용을 피하는 것이 좋습니다. 아래에서 이에 대한 예를 볼 수 있습니다. 마이크로플로우의 첫 번째 검색은 not() 함수를 사용합니다. 두 번째 마이크로플로우에서는 두 개의 검색과 하나의 목록 연산을 사용하여 정확히 동일한 결과를 얻습니다. 두 번의 검색과 목록 연산은 일반적으로 not() 함수보다 더 빠르게 수행됩니다.
and 와 or 의 사용도 마찬가지입니다. 목록 작업 활동을 사용하여 마이크로 플로우로 대체할 수 있습니다. 또는 연산은 Union으로 대체할 수 있습니다. 및는 교집합으로 대체할 수 있습니다.
시간이 오래 걸리는 XPath 쿼리에 대해 취할 수 있는 또 다른 접근 방식은 인덱스를 적용하는 것입니다. 이렇게 하면 Mendix가 데이터베이스를 더 빠르게 검색할 수 있지만 데이터베이스 변경 속도가 느려집니다. 인덱스가 적용되는 데이터가 변경되는 데이터보다 더 자주 검색되는지 확인하세요. 또한 선택하려는 속성이 될 올바른 속성에 인덱스를 설정하는 것도 중요합니다.
마지막으로, 도메인 모델에서 긴 XPath 표현식을 추가적인 직접 연결로 대체하여 Mendix가 5~10개의 엔티티를 거치지 않고 하나의 연결만 사용할 수 있도록 하는 것도 좋은 방법입니다. 단, 이 연결을 유지 관리해야 한다는 의미입니다. 또한 도메인 모델이 더 복잡해집니다. 따라서 성능 분석 결과 교체하려는 XPath가 앱의 일상적인 성능에 상당한 영향을 미치는 것으로 나타난 경우에만 이 접근 방식을 사용하는 것이 좋습니다.
모든 최적화의 경우 가장 중요한 것은 성능 문제가 발생했을 때 최적화해야 한다는 것입니다. 애플리케이션을 만들 때는 항상 성능과 유지보수성 사이에서 아슬아슬한 줄타기를 해야 합니다. 성능은 좋지만 복잡성을 희생하지 않는 로직을 만드는 것이 항상 좋은 생각입니다.
인덱스 올바르게 적용하기
인덱스를 선제적으로 적용할 수도 있지만 일반적으로는 권장하지 않습니다. 인덱스로 인해 데이터 삽입 비용이 더 많이 들기 때문입니다. 따라서 인덱스 추가를 시작하기 전에 애플리케이션이 어떻게 사용될지 파악하는 것이 중요합니다. 검색 가능한 고객 이름과 같이 속성에 인덱스가 필요한 것이 분명한 경우도 있습니다. 주소의 우편번호 필드처럼 인덱스를 사용해야 하는지 여부를 결정하기 어려운 경우도 있습니다. 따라서 속성에 인덱스를 적용하기 전에 애플리케이션의 성능을 분석하는 것이 가장 좋습니다.
그러나 어떤 경우에는 속성에 인덱스를 추가해야 한다는 것을 미리 알고 있는 경우도 있습니다. 이러한 속성의 좋은 예로 고객의 이름을 들 수 있습니다. 이는 일반적으로 사람들이 검색하고자 하는 정보입니다. 또한 AdventureWorks가 고객을 위해 캡처하는 정보는 정기적으로 변경되지 않는 정보입니다. 따라서 인덱스를 추가할 수 있는 속성의 이상적인 후보입니다.
FirstName, MiddleName, LastName에 Index 추가하기
애플리케이션에 Index를 추가하여 AdventureWorks 직원들을 도와드리겠습니다.
1. Person 모듈에서 도메인 모델을 열고 Person엔티티를 두 번 클릭합니다.
2. Index탭으로 전환하고 FirstName, MiddleName, LastName에 대한 Index를 추가합니다.
3. Sales 폴더의 Sales 모듈에 Customer_Overview라는 이름으로 새 페이지를 추가합니다. Sales_Layout 레이아웃과 목록 기본 템플릿을 사용합니다.
4. 레이아웃 그리드의 왼쪽 열에 AccountNumber 를 추가하고 오른쪽에 Title, FirstName, MiddleName, LastName 및 Suffix를 Person관계에서 추가하여 아래 디자인과 일치시켜 모든 이름 필드를 가져옵니다.
5. 검색 가능한 네 가지 속성을 검색 필드에 추가합니다.
6. Sales의 메뉴에 새 페이지를 추가합니다.
7. 로컬에서 실행하여 검색을 시도합니다.
앱에 멋진 기능이 추가되었습니다! AdventureWorks 직원들은 이 기능 추가에 매우 만족하고 있습니다. 이제 어떤 다른 최적화 옵션이 있는지 살펴볼 차례입니다. 이름 관련 속성에 대한 인덱스를 사용하면 이제 검색 속도가 더 빨라집니다. 올바른 이름을 찾기 위해 모든 이름을 일일이 살펴볼 필요 없이 인덱스가 올바른 행으로 바로 이동할 수 있도록 도와줍니다.
대규모 XPath 표현식 찾기
Mendix는 성능에 영향을 미칠 수 있는 XPath 표현식을 찾을 수 있는 검색 기능을 제공합니다. 이 메뉴는 편집 → 고급 찾기...에서 찾을 수 있으며, 키보드 단축키 Ctl-Shift-F를 사용하여 액세스할 수도 있습니다. 이 검색 기능은 or 연산자와 not 함수에 중점을 둡니다.
2. 이러한 XPath 쿼리를 찾으면 이를 분석하여 더 효율적인 변형으로 대체할 수 있습니다.
찾기를 클릭하고 결과를 확인합니다.
보시다시피 앱스토어 모듈에 있는 쿼리를 포함하여 프로젝트의 모든 쿼리를 찾습니다. 또한 이전에 생성한 not() 함수가 포함된 하나의 XPath 쿼리도 찾았습니다.
앱의 XPath
이제 이 기능을 사용해 보고 애플리케이션에 얼마나 많은 XPath 표현식이 숨어 있는지 확인해 보세요.
1. Edit → Find Advanced를 클릭하고 두 확인란을 모두 선택합니다.
2. find를 클릭하고 결과를 확인합니다.
보시다시피 앱스토어 모듈에 있는 쿼리를 포함하여 프로젝트의 모든 쿼리를 찾습니다. 또한 이전에 생성한 not() 함수가 포함된 하나의 XPath 쿼리도 찾았습니다.
XPath의 대안으로서의 OQL
XPath는 시각적 개발을 지원하므로 매우 강력합니다. 하지만 때로는 더 강력한 기능이 필요할 때가 있습니다. 바로 이때 OQL이 등장합니다. SQL과 더 비슷하며 여러 엔티티의 정보를 하나의 새로운 엔티티로 결합할 수 있습니다. 이는 리포팅에 매우 유용합니다. 전체 기능 목록은 Mendix OQL 문서에서 확인할 수 있습니다.
OQL은 대시보드형 애플리케이션을 만들 때 특히 유용할 수 있는데, 집계는 OQL에서 할 수 있기 때문입니다. 이렇게 하면 수행해야 하는 데이터베이스 검색 횟수를 크게 줄일 수 있습니다.
