Slate의 인덱스와 데이터 구성

앱 성능은 데이터셋 구성과 인덱스에 영향을 받습니다. 새 Slate 앱은 가능한 경우 객체 집합과 액션 같은 온톨로지 기능을 사용합니다. 아래는 Postgres와 기존 Phonograph 경로를 다루는 기준입니다.

반복 계산의 위치

브라우저의 복잡한 JavaScript 집계나 지표 계산은 먼저 질의에서 처리할 수 있는지 검토합니다. 같은 SUM이나 DISTINCT 계산을 페이지를 열 때마다 반복한다면 파생 데이터셋에서 미리 계산하는 것도 고려합니다.

Foundry의 분산 저장과 계산을 활용하여 반복 요청과 사용자 브라우저의 작업을 줄이는 방식입니다. 데이터 갱신 주기와 필요한 최신성을 함께 고려하여 계산 위치를 정합니다.

Postgate는 Postgres 또는 RDS를 감싸 Foundry 데이터셋에 PostgreSQL 질의로 읽기 전용 접근을 제공합니다. 이 경로의 질의 특성은 Spark/HDFS가 아니라 관계형 데이터베이스와 Postgres의 실행 계약을 따릅니다.

EXPLAIN과 EXPLAIN ANALYZE로 실제 계획과 병목을 확인합니다. 후자는 질의를 실행하므로 사용 범위를 확인해야 합니다. 구체적인 계획 해석과 인덱스 후보 조회는 Postgres 질의 성능에 설명합니다.

공유하는 SQL은 Query partial과 함수로 묶어 중복을 줄입니다. 지나친 분할보다 읽기 쉬운 구조를 유지합니다.

Phonograph는 Elasticsearch 계열의 검색과 집계 문법 및 생성, 조회, 수정, 삭제를 제공하는 기존 편집 저장소입니다. 새 워크플로에 도입하는 경로가 아니므로 Legacy 쓰기 계약의 동기화와 일관성 범위를 따릅니다.