비동기 보조 색인 만들기

연속 구체화된 뷰를 테이블의 비동기 보조 색인으로 사용할 수 있습니다.

이 페이지를 읽기 전에 연속 구체화된 뷰를 숙지하세요.

Bigtable 테이블의 데이터는 일반적으로 row key로 색인이 생성됩니다. 하지만 소스 테이블에서 연속 구체화된 뷰를 만들어 비동기 보조 색인으로 사용할 수 있습니다. 이렇게 하면 구체화된 뷰를 쿼리하여 다양한 쿼리 조회 패턴을 사용하여 동일한 데이터를 검색할 수 있습니다.

비동기 보조 색인은 소스 테이블의 열 하위 집합과 소스 테이블의 행 키와 다른 행 키를 포함하는 연속 구체화된 뷰입니다. 이러한 행 키는 애플리케이션이 다양한 쿼리 조회 패턴을 기반으로 동일한 데이터를 검색할 수 있도록 하는 다음 변환을 기반으로 할 수 있습니다.

  • 소스 테이블 내의 속성(예: 열 한정자, 열 값, 소스 행 키의 일부)
  • row key의 재포맷입니다.
  • 행 키를 속성과 결합하는 변환입니다.

Bigtable은 eventual consistency를 갖는 방식으로 소스 테이블과 비동기 보조 색인을 자동으로 동기화합니다.

비동기 보조 색인을 사용해야 하는 경우

애플리케이션은 다양한 조회 패턴이나 속성을 사용하여 동일한 데이터를 쿼리해야 하는 경우가 많습니다. 예를 들어 이메일 주소나 전화번호로 사용자 정보를 가져오는 애플리케이션을 생각해 보세요. 두 쿼리 패턴에서 동일한 수준의 성능을 원할 수 있습니다. 이메일 주소를 Bigtable 행 키로 만들고 전화번호를 열에 저장하면 전체 테이블 스캔이 필요하므로 전화번호 조회 성능이 느려집니다.

전화번호로 조회할 때 쿼리 성능을 개선하려면 SQL 문으로 연속 구체화된 뷰를 만들면 됩니다. SQL 문은 Bigtable에 다른 행 키로 데이터를 재구성하는 방법을 알려줍니다. 연속 구체화된 뷰는 쿼리할 수 있는 테이블처럼 작동합니다. 그런 다음 뷰를 비동기 보조 색인으로 사용합니다. 이를 통해 애플리케이션이 동일한 데이터에 액세스할 수 있는 또 다른 경로가 제공됩니다. 각 경로에서는 서로 다른 행 키를 사용하므로 각 쿼리에 대해 대체 경로를 선택할 수 있습니다. 쿼리에 가장 적합한 경로를 선택하려면 각 테이블의 행 키 구조와 각 테이블에 저장된 데이터를 이해해야 합니다.

연속 구체화된 뷰를 비동기 보조 색인으로 사용하면 다음 사용 사례에서 쿼리 성능을 개선할 수 있습니다.

  • 데이터 키 재설정: 소스 테이블의 행 키와 다른 키를 사용하여 데이터를 쿼리해야 하는 경우 대체 키를 사용하여 연속 구체화된 뷰를 만든 다음 해당 뷰에 대해 쿼리할 수 있습니다.
  • 데이터 필터링: 소스 테이블을 필터링하고 비동기 보조 색인에 특정 데이터 행만 채우려면 뷰를 정의하는 SQL 쿼리에 WHERE 절을 제공합니다.
  • 속성 키: 열 한정자나 값과 같은 키가 아닌 속성을 기반으로 데이터를 쿼리해야 하는 경우 ORDER BY 절에 포함할 수 있습니다.

비동기 보조 색인 정보

Bigtable에서 연속 구체화된 뷰를 비동기 보조 색인으로 사용하려면 다음 요구사항을 고려하세요.

  • 새 비동기 보조 색인의 행 키에는 소스 테이블의 행 키가 포함되어야 합니다. 그래야 소스 테이블의 행과 연속 구체화된 뷰의 비동기 보조 색인의 행 간에 일대일 매핑이 이루어집니다.
  • 비동기 보조 색인은 소스 테이블과 스키마나 속성이 동일하지 않아도 됩니다. SQL 쿼리의 SELECT 부분에서는 테이블에서 필요한 열과 적용할 데이터의 SQL 변환을 지정해야 합니다.
  • 비동기 보조 색인은 쿼리 패턴에 필요한 데이터만 복사하면 됩니다. 소스 테이블에 모든 소스 데이터를 제공하지 않아도 됩니다.
  • Bigtable에서 선택한 row key는 기본 정렬 순서를 제공합니다.

비동기 보조 색인을 쿼리하려면 다음 요구사항을 고려하세요.

  • ORDER BY 절의 모든 열은 SELECT 절에도 포함되어야 합니다.
  • 비동기 보조 색인을 정의하면 애플리케이션에서 소스 테이블을 쿼리할지 비동기 보조 색인을 나타내는 구체화된 뷰를 쿼리할지 선택할 수 있어야 합니다.
  • 애플리케이션은 소스 테이블과 지속적으로 동기화되는 색인에 직접 쓰지 않습니다. 항상 소스 테이블에 쓰기
  • 비동기 보조 색인은 최종 일관성을 갖습니다. 데이터는 먼저 소스 테이블에 작성된 후 비동기 보조 색인 형식으로 변환됩니다.
  • 커버링 인덱스를 만드는 것이 좋습니다. 자세한 내용은 이 문서의 커버링 인덱스 섹션을 참고하세요.
  • ORDER BY 절에는 소스 테이블의 수정되지 않은 행 키가 포함되어야 하며 모든 데이터는 오름차순으로 정렬되어야 합니다. 소스 테이블의 행 키는 항상 구체화된 뷰에 투영되지만 다른 속성과 결합될 수 있습니다.
  • ORDER BY 절의 열은 비동기 보조 색인의 구조화된 행 키의 일부가 됩니다. 선택된 다른 모든 열은 비동기 보조 색인의 비키 열 값이 됩니다. ORDER BY 절의 값을 특정 Bigtable용 GoogleSQL 데이터 유형으로 변환하면 비동기 보조 색인의 구조화된 행 키에 데이터 유형이 유지됩니다.

커버링 색인

커버링 인덱스에는 쿼리에 필요한 모든 열이 포함됩니다. 커버링 색인을 쿼리하면 Bigtable은 소스 테이블에 액세스하지 않고도 색인에서 필요한 모든 데이터를 직접 가져올 수 있습니다. 이 방법은 디스크 읽기 수를 최소화하므로 최적의 성능을 위해 권장됩니다. 커버링 인덱스를 만들려면 SELECT 문이 쿼리에 필요한 모든 열을 지정해야 합니다.

커버링되지 않은 색인을 만들려면 색인을 쿼리한 다음 결과를 사용하여 소스 테이블에서 필요한 추가 열을 조회합니다.

비동기 보조 색인 정의

비동기 보조 색인은 비동기 보조 색인을 정의하는 SQL 쿼리를 사용하여 연속 구체화된 뷰를 만들어 만듭니다.

다음 예에서 SQL 쿼리는 사용자 상호작용 데이터를 쿼리할 수 있는 비동기 보조 색인을 만듭니다. ORDER BY 절에서는 사용자의 전화번호, 사용자 ID, 이메일 주소를 조합하여 비동기 보조 색인의 구조화된 행 키를 정의합니다. 또한 activity column family에 interactions라는 이름을 할당합니다.

SELECT
  user['phone'] AS phone,
  CAST(user['id'] AS INT64) AS user_id,
  _key AS email,
  activity AS interactions
FROM CLICKS_TABLE
ORDER BY 1, 2, 3;

다음 표에서는 소스 테이블의 동일한 행 뷰를 해당 비동기 보조 색인과 비교하여 색인이 생성되는 방식을 설명합니다.

소스 테이블 행 비동기 보조 색인 행
행 키:
_key: user1@example.com



속성:
user: {id: "123", phone: "555-123-4567"}
activity: {action: "CLICKED_PRODUCT_A"}		 구조화된 행 키:
phone: 555-123-4567
user_id: 123
email: user1@example.com

속성:
interactions: {action: "CLICKED_PRODUCT_A"}
행 키:
_key: user2@example.com



속성:
user: {id: "456", phone: "555-987-6543"}
activity: {action: "VIEWED_PRODUCT_B"}		 구조화된 행 키:
phone: 555-987-6543
user_id: 456
email: user2@example.com

속성:
interactions: {action: "VIEWED_PRODUCT_B"}
행 키:
_key: user3@example.com



속성:
user: {id: "1000", phone: "555-111-2222"}
activity: {action: "ADDED_TO_CART_PRODUCT_C"}		 구조화된 행 키:
phone: 555-111-2222
user_id: 1000
email: user3@example.com

속성:
interactions: {action: "ADDED_TO_CART_PRODUCT_C"}

제한사항

  • 비동기 보조 색인 키인 출력 키를 읽으려면 SQL 쿼리만 사용할 수 있습니다.

다음 단계