Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

색인 및 지역 파티셔닝

Spanner는 쿼리 성능을 개선하기 위해 여러 유형의 색인을 제공합니다. 스키마 및 쿼리 패턴에 적합한 색인 유형을 선택하는 것은 특히 지리적 파티셔닝을 사용하는 데이터베이스의 경우 매우 중요합니다. 이 페이지에서는 다양한 색인 유형의 이점과 지역 파티셔닝을 사용하여 Spanner 색인을 선택하고 사용하는 권장사항을 설명합니다.

색인 유형

Spanner는 전역, 로컬, 원격 색인을 지원합니다. 각 유형은 성능 특성과 사용 사례가 다릅니다. 지리적 파티셔닝 데이터베이스의 경우 이러한 색인 유형을 이해하는 것이 중요합니다. 적절한 인덱스를 선택하면 데이터베이스 스키마와 쿼리를 최적화할 수 있으며, 이는 지역 파티셔닝된 데이터베이스의 지연 시간을 크게 개선할 수 있습니다. 지역 파티셔닝을 사용하지 않는 데이터베이스의 경우 이러한 인덱스 유형은 모두 기본 배치에 저장되고 성능 특성이 유사하므로 이해하는 것이 덜 중요합니다.

전역 색인

전역 색인은 Spanner의 기본 색인 유형입니다. 색인 데이터는 테이블의 데이터와 동일한 위치에 있지 않을 수 있는 기본 파티션에 저장됩니다. 지리적 파티션 테이블에 전역 색인을 만들면 색인이 생성된 열과 관련된 쓰기의 쓰기 지연 시간이 크게 늘어날 수 있습니다. 특히 색인의 기본 파티션 쓰기 쿼럼이 쓰기 대상 테이블 행의 쓰기 쿼럼과 멀리 떨어져 있는 경우에 그렇습니다. 읽기 임대 리전 또는 비활성 읽기와 함께 가까운 읽기 전용 복제본을 사용하여 전역 색인의 읽기 지연 시간을 완화할 수 있습니다.

전역 색인에는 다음과 같은 특징이 있습니다.

이러한 색인은 그렇지 않으면 전체 테이블 스캔이 필요한 쿼리의 속도를 높이고 위치와 관계없이 모든 테이블 행에서 고유성을 적용합니다.
데이터베이스 전체에서 고유한 값이 필요한 열에 적합합니다.
색인화된 열을 기준으로 필터링하거나 정렬하는 쿼리의 속도를 높입니다.

다음은 전역 고유 색인의 예입니다.

CREATE UNIQUE INDEX idx_customer_email ON customer(email);

로컬 색인

로컬 색인은 색인이 생성된 테이블의 상위 계층 구조에서 인터리브 처리됩니다. 기본 키 열 이름과 유형은 색인이 생성된 테이블과 일치해야 합니다.

로컬 색인의 특징은 다음과 같습니다.

색인 데이터는 색인이 생성된 데이터와 동일한 파티션에 저장됩니다. 쓰기 지연 시간은 기본 배치 쓰기 쿼럼이 아닌 특정 배치의 쓰기 쿼럼에 따라 달라집니다.
인덱스와 테이블 데이터가 모두 동일한 배치에 있으므로 특정 키 접두사를 타겟팅하는 쿼리의 지연 시간이 가장 짧습니다.

로컬 색인을 만들려면 상위 테이블에서 색인을 인터리브 처리하세요. UNIQUE 로컬 색인을 사용하는 경우 고유성은 전체 테이블이 아닌 특정 상위 행 내에서만 적용됩니다.

다음은 상위 테이블 locations에 인터리브 처리된 테이블 customer에 로컬 색인을 만드는 예입니다.

GoogleSQL

-- Create locations placement table
CREATE TABLE locations (
  location STRING(MAX) NOT NULL PLACEMENT KEY,
) PRIMARY KEY(location);

-- Create customer table interleaved in the locations table
CREATE TABLE customer (
  location STRING(MAX) NOT NULL,
  customerId  INT64 NOT NULL,
  email STRING(MAX),
  webcookie STRING(64),
) PRIMARY KEY(location, customerId), INTERLEAVE IN PARENT locations;

-- Create a local index on the interleaved customer table
CREATE INDEX idx_customer_email_local ON customer(location, email),
INTERLEAVE IN locations;

PostgreSQL

-- Create locations placement table
CREATE TABLE locations (
  location varchar NOT NULL PLACEMENT KEY PRIMARY KEY
);

-- Create customer table interleaved in the locations table
CREATE TABLE customer (
  location varchar NOT NULL,
  customerId  BIGINT NOT NULL,
  email varchar(1024),
  webcookie varchar(64),
  PRIMARY KEY(location, customerId)
) INTERLEAVE IN PARENT locations;

-- Create a local index on the interleaved customer table
CREATE INDEX idx_customer_email_local ON customer(location, email)
INTERLEAVE IN locations;

읽기-쓰기 트랜잭션에서 데이터를 쿼리할 때는 쿼리에서 색인이 생성된 테이블의 기본 키 접두사를 지정해야 합니다. 그렇지 않으면 쿼리에 전체 테이블 스캔이 필요할 수 있습니다. 예를 들면 다음과 같습니다.

GoogleSQL

-- The location (the index key prefix) must be specified
SELECT *
FROM customer
WHERE location= @location AND email= @email;

PostgreSQL

-- The location (the index key prefix) must be specified
SELECT *
FROM customer
WHERE location= @location AND email= @email;

위치를 지정하지 않아도 되는 최적화에 대한 자세한 내용은 로컬 또는 원격 색인과 함께 전역 고유 색인 사용을 참고하세요.

배치 테이블이 항목 기반이고 특정 항목 또는 하위 항목 내에서 데이터를 색싱하려는 경우에도 로컬 색인이 유용합니다. 예를 들면 다음과 같습니다.

GoogleSQL

-- Create entity based customer placement table
CREATE TABLE customer (
  customerId INT64 NOT NULL,
  email STRING(MAX),
  webcookie STRING(64),
  location STRING(MAX) NOT NULL PLACEMENT KEY
) PRIMARY KEY(customerId);

-- Create customerOrders child table
CREATE TABLE customerOrders (
  customerId INT64 NOT NULL,
  orderId INT64 NOT NULL,
  orderName STRING(MAX) NOT NULL
) PRIMARY KEY(customerId, orderId), INTERLEAVE IN PARENT customer;

-- Create a local index on the interleaved child table
CREATE INDEX idx_order_local ON customerOrders(customerId, orderName),
INTERLEAVE IN customer;

PostgreSQL

-- Create entity based customer placement table
CREATE TABLE customer (
  customerId BIGINT NOT NULL PRIMARY KEY,
  email varchar(1024),
  webcookie varchar(64),
  location varchar NOT NULL PLACEMENT KEY
);

-- Create customerOrders child table
CREATE TABLE customerOrders (
  customerId BIGINT NOT NULL,
  orderId BIGINT NOT NULL,
  orderName varchar(1024) NOT NULL,
  PRIMARY KEY(customerId, orderId)
) INTERLEAVE IN PARENT customer;

-- Create a local index on the interleaved child table
CREATE INDEX idx_order_local ON customerOrders(customerId, orderName)
INTERLEAVE IN customer;

원격 색인

원격 색인은 색인이 생성된 테이블의 인터리브 계층 구조에서 상위 항목이 아닌 테이블 아래에 색인 데이터를 인터리브합니다. 기본 키 유형은 해당 색인 열의 유형과 일치해야 하지만 이름은 다를 수 있습니다.

지리적 파티셔닝을 사용하면 자동으로 관리되는 루트 배치 테이블 아래에만 원격 색인을 인터리브할 수 있습니다. 이 테이블에는 데이터베이스의 각 게재위치에 대한 행이 하나씩 포함됩니다.

원격 색인에는 다음과 같은 특징이 있습니다.

특히 테이블의 기본 키에 배치 키가 접두사로 지정되어 있지 않지만 배치 키에 따라 색인의 파티션을 지리적으로 공동 배치하려는 경우에 유용합니다.
인터리브 처리된 하위 테이블의 열이 아닌 배치 테이블의 열에만 색인을 생성할 수 있습니다.

지역 파티셔닝과 함께 원격 색인을 사용하려면 ALTER DATABASE DDL 문에서 auto_managed_root_placement_table_name 옵션을 설정하여 루트 배치 테이블을 만듭니다.

ALTER DATABASE DDL 문을 사용하여 루트 배치 테이블을 만듭니다.
GoogleSQL
```
ALTER DATABASE DATABASE_NAME SET OPTIONS
  (auto_managed_root_placement_table_name="TABLE_NAME");
```
다음을 바꿉니다.
- DATABASE_NAME: 데이터베이스 이름입니다.
- TABLE_NAME: 만들 테이블의 이름입니다. root_placement_table 이름을 사용하는 것이 좋습니다.
예를 들어 다음 명령어는 root_placement_table이라는 테이블을 만듭니다.
```
ALTER DATABASE example_db SET OPTIONS
  (auto_managed_root_placement_table_name='root_placement_table');
```
루트 배치 테이블을 만들면 Spanner에서 내부 테이블을 만들고 배치를 만들거나 삭제할 때 행을 자동으로 삽입하고 삭제합니다. 다음은 Spanner에서 생성한 시스템 정의 배치 테이블의 예시입니다. 예시 테이블 이름은 root_placement_table로 설정되어 있습니다. (이 예시를 실행하지 마세요.)
```
// Automatically generated after you run the previous example.
// Don't put this in your schema explicitly.
CREATE TABLE root_placement_table (
location STRING(MAX) NOT NULL PLACEMENT KEY
) PRIMARY KEY(location);
```
PostgreSQL
```
ALTER DATABASE DATABASE_NAME SET
  spanner.auto_managed_root_placement_table_name='TABLE_NAME';
```
다음을 바꿉니다.
- DATABASE_NAME: 데이터베이스 이름입니다.
- TABLE_NAME: 만들 테이블의 이름입니다.
예를 들어 인터리브 루트로 사용되는 root_placement_table 테이블을 만들려면 다음을 실행합니다.
```
ALTER DATABASE example_db SET
  spanner.auto_managed_root_placement_table_name='root_placement_table';
```
루트 배치 테이블을 만들면 Spanner에서 내부 테이블을 만들고 배치를 만들거나 삭제할 때 행을 자동으로 삽입하고 삭제합니다. 다음은 Spanner에서 생성한 시스템 정의 배치 테이블의 예시입니다. 예시 테이블 이름은 root_placement_table로 설정되어 있습니다. (이 예시를 실행하지 마세요.)
```
// Automatically generated after you run the previous example.
// Don't put this in your schema explicitly.
CREATE TABLE root_placement_table (
  location varchar NOT NULL PLACEMENT KEY,
  PRIMARY KEY (location)
);
```

자동으로 관리되는 root_placement_table 테이블 아래에 인터리브된 원격 색인을 만듭니다.

GoogleSQL

-- Create a customer table with a primary key that is not the location
CREATE TABLE customer (
  customerId INT64 NOT NULL ,
  email STRING(MAX),
  webcookie STRING(64),
  location STRING(MAX) NOT NULL PLACEMENT KEY,
) PRIMARY KEY(customerId);

-- Create a remote index on the customer table
CREATE INDEX idx_customer_email_remote ON customer(location, email),
INTERLEAVE IN root_placement_table;

PostgreSQL

-- Create a customer table with a primary key that is not the location
CREATE TABLE customer (
  customerId BIGINT NOT NULL PRIMARY KEY,
  email varchar(1024),
  webcookie varchar(64),
  location varchar NOT NULL PLACEMENT KEY
);

-- Creates a remote index on the customer table
CREATE INDEX idx_customer_email_remote ON customer(location, email)
INTERLEAVE IN root_placement_table;

읽기-쓰기 트랜잭션에서 데이터를 쿼리할 때는 전체 테이블 스캔이 필요하지 않도록 쿼리 조건자에 색인의 키 접두사를 지정하세요. 예를 들면 다음과 같습니다.
GoogleSQL
```
-- Specify the location (the index key prefix) in query
SELECT *
FROM customer
WHERE location= @location AND email= @email;
```
위치를 지정하지 않아도 되는 최적화에 대한 자세한 내용은 로컬 또는 원격 색인이 있는 전역 고유 색인 섹션을 참고하세요.
PostgreSQL
```
-- Specify the location (the index key prefix) in query
SELECT *
FROM customer
WHERE location= @location AND email= @email;
```
위치를 지정하지 않아도 되는 최적화에 관한 자세한 내용은 로컬 또는 원격 색인이 있는 전역 고유 색인 섹션을 참고하세요.

전역 고유 색인 최적화

전역 고유 색인을 사용하는 경우 Spanner는 다음 사용 사례에서 휴리스틱 기반 최적화를 통해 쿼리 지연 시간 개선을 트리거할 수 있습니다.

로컬 또는 원격 색인과 함께 전역 고유 색인을 사용하는 경우
부분 기본 키와 함께 전역 고유 색인을 사용하는 경우

다음 섹션에서는 각 사용 사례에서 Spanner가 최적화를 적용하는 방법을 설명합니다.

로컬 또는 원격 색인이 있는 전역 고유 색인

로컬 쿼리 지연 시간을 개선하기 위해 Spanner는 전역 고유 색인이 로컬 또는 원격 색인과 결합될 때 휴리스틱 기반 최적화를 시작할 수 있습니다.

이 최적화는 지리적 파티션 데이터의 위치가 지정되지 않은 경우에도 클라이언트가 있는 위치와 배치가 동일하다고 추측하고 전역 색인의 기본 파티션을 우회하거나 필터링된 전체 테이블 검색의 필요성을 없애 지역 내 쿼리의 지연 시간을 최소화합니다. 이러한 접근 방식은 클라이언트가 주로 자체 리전 내에 저장된 데이터에 액세스하는 경우에 특히 유용합니다.

영역 내 쿼리 지연 시간이 기본 관심사이고 쓰기 지연 시간의 약간의 증가는 허용할 수 있는 경우 다양한 인덱스 유형을 혼합하여 사용하는 것이 좋습니다. 다양한 색인 유형을 결합하면 쿼리에서 위치를 지정하지 않아도 리전 내 쿼리의 성능이 개선됩니다.

이 최적화를 사용하려면 전역 고유 색인과 동일한 열에 해당하는 로컬 또는 원격 색인을 만들어야 합니다. 색인 생성된 데이터는 전역적으로 고유해야 합니다. 다음 조건이 충족되면 Spanner가 쿼리에 이 최적화를 적용합니다.

기본 키 접두사를 모르고 데이터 위치를 지정하지 않습니다.
요청이 로컬 또는 원격 색인 샤드를 포함하는 데이터 배치 기본 리전과 동일한 리전에서 시작됩니다.

Spanner는 다음과 같은 방식으로 최적화를 적용합니다.

최적화가 트리거되고 행이 로컬 배치에서 발견되면 전역 고유 색인이 제공되므로 Spanner가 다른 위치를 검색할 필요가 없습니다. 질문에 리전 내 지연 시간이 있습니다.
초기 위치 검색에서 행이 반환되지 않는 경우: 이는 리전 내 쿼리가 아님을 나타냅니다. Spanner가 전역 색인을 사용하도록 대체됩니다.

다음 예시에서는 전역 고유 색인과 로컬 색인을 만듭니다.

GoogleSQL

CREATE UNIQUE INDEX idx_customer_email ON customer(email);
CREATE INDEX idx_customer_email_local ON customer(location, email), INTERLEAVE IN locations;

PostgreSQL

CREATE UNIQUE INDEX idx_customer_email ON customer(email);
CREATE INDEX idx_customer_email_local ON customer(location, email) INTERLEAVE IN locations;

다음 예시에서는 전역 고유 색인과 원격 색인을 만듭니다.

GoogleSQL

CREATE UNIQUE INDEX idx_customer_email ON customer(email);
CREATE INDEX idx_customer_email_remote ON customer(location, email), INTERLEAVE IN root_placement_table;

PostgreSQL

CREATE UNIQUE INDEX idx_customer_email ON customer(email);
CREATE INDEX idx_customer_email_remote ON customer(location, email) INTERLEAVE IN root_placement_table;

이전 예시 색인을 기반으로 다음 예시 쿼리에는 리전 내 지연 시간이 있습니다.

GoogleSQL

SELECT *
FROM customer
WHERE email= @email;

PostgreSQL

SELECT *
FROM customer
WHERE email= @email;

부분 기본 키의 전역 고유 색인

부분 기본 키에 전역 고유 색인을 사용하는 경우 Spanner는 로컬 또는 원격 색인과 함께 전역 고유 색인 사용에 자세히 설명된 것과 유사한 최적화를 적용할 수 있습니다.

다음 예시에서는 상위 테이블 locations에 인터리브된 customer를 만든 다음 customerId 열에 전역 고유 색인을 만듭니다.

GoogleSQL

-- Create locations placement table
CREATE TABLE locations (
location STRING(MAX) NOT NULL PLACEMENT KEY,
) PRIMARY KEY(location);

-- Create customer table interleaved in the locations table
CREATE TABLE customer (
  location STRING(MAX) NOT NULL,
  customerId  INT64 NOT NULL,
  email STRING(MAX),
  webcookie STRING(64),
) PRIMARY KEY(location, customerId), INTERLEAVE IN PARENT locations;

-- Create global unique index on customerId column
CREATE UNIQUE INDEX idx_customer_customerid ON customer(customerId);

PostgreSQL

-- Create locations placement table
CREATE TABLE locations (
  location varchar NOT NULL PLACEMENT KEY PRIMARY KEY
);

-- Create customer table interleaved in the locations table
CREATE TABLE customer (
  location varchar NOT NULL,
  customerId  BIGINT NOT NULL,
  email varchar(1024),
  webcookie varchar(64),
  PRIMARY KEY(location, customerId)
) INTERLEAVE IN PARENT locations;

-- Create global unique index on customerId column
CREATE UNIQUE INDEX idx_customer_customerid ON customer(customerId);

최적화는 다음과 같은 쿼리에 적용됩니다.

GoogleSQL

SELECT * FROM customer WHERE customerId= @customerId;

PostgreSQL

SELECT * FROM customer WHERE customerId= @customerId;

전역 고유 색인을 만들지 않으면 이 쿼리에 전체 테이블 검색이 필요할 수 있습니다. 전역 고유 색인을 사용하지 않는 경우 쿼리 지연 시간을 줄이려면 쿼리에 위치 필터를 추가해야 합니다.

GoogleSQL

SELECT * FROM customer WHERE location = @location AND customerId= @customerId;

PostgreSQL

SELECT * FROM customer WHERE location = @location AND customerId= @customerId;

최적의 지연 시간을 위한 색인 유형 선택에 관한 일반 가이드라인

선택한 색인 유형은 쿼리 지연 시간에 직접적인 영향을 미칩니다. 테이블 데이터와 관련된 색인 데이터의 위치는 지리적 파티션 워크로드의 성능에 영향을 미치는 주요 요인입니다.

이 섹션에서는 전역, 로컬, 원격 색인 중에서 선택하는 방법을 설명합니다.

전역 인덱스를 선택해야 하는 경우

워크로드에서 연결된 읽기 및 쓰기 지연 시간을 허용할 수 있거나 색인이 생성된 열에 강제된 전역 고유성이 필요한 경우 전역 색인을 사용합니다.

전역 인덱스를 선택할 때 다음 사항을 고려하세요.

클라이언트와 기본 쓰기 쿼럼의 리더 간 거리와 쿼럼의 기본 지연 시간이 쓰기 지연 시간 증가를 결정합니다. 이 효과는 색인이 생성된 열이 포함된 작업(예: 행 삽입 또는 색인이 생성된 열 업데이트)으로만 제한됩니다.
읽기 전용 복제본을 추가하거나 읽기 임대를 사용하면 읽기 지연 시간 증가를 완화할 수 있습니다.
- 지리적으로 가까운 곳에 읽기 전용 복제본을 추가하면 비활성 읽기 지연 시간을 줄일 수 있습니다.
- 읽기 전용 복제본을 추가하고 읽기 임대 리전을 사용하면 강력한 읽기 지연 시간을 줄일 수 있습니다. 읽기 임대 리전을 사용하지 않고 읽기 전용 복제본을 추가하면 강력한 읽기 지연 시간은 줄어들지 않지만 읽기 처리량은 늘어날 수 있습니다.
- Spanner는 항상 리더에서 비관적 트랜잭션 읽기를 제공합니다. 기본 배치에 복제본을 추가해도 기본 배치에 있는 데이터의 비관적 트랜잭션 읽기에는 도움이 되지 않습니다.
키와 저장 값을 포함한 전역 색인은 배치 수준 데이터 상주를 제공하지 않는 기본 배치에 배치됩니다. 자세한 내용은 Spanner 데이터 상주 개요를 참고하세요.

로컬 및 원격 색인을 선택해야 하는 경우

로컬 및 원격 색인을 선택할 때 다음 사항을 고려하세요.

로컬 및 원격 색인은 배치 로컬 읽기 및 쓰기 성능을 제공하지만 고유 색인 열의 전역 고유성 및 정렬 속성을 희생합니다. 대신 로컬 및 원격 색인은 인터리브 처리된 상위 행 내에서 색인이 지정된 열의 순서와 고유성을 제공합니다.
로컬 또는 원격 색인을 사용하는 경우 Spanner에서 로컬 배치 위치를 추측할 수 있는 전역 고유 색인이 있는 경우를 제외하고 쿼리 조건자에 배치 위치를 포함해야 합니다. 그렇지 않으면 쿼리 계획과 성능이 결정적이지 않습니다. Spanner는 쿼리 통계를 기반으로 배치 위치 전반에서 색인을 스캔하거나 분산 및 수집하여 지연 시간을 늘릴 수 있습니다.

로컬 또는 원격 색인과 함께 전역 고유 색인을 선택해야 하는 경우

전역 고유 색인과 로컬 또는 원격 색인을 함께 선택할 때는 다음 사항을 고려하세요.

특정 게재위치 위치를 알 수 없는 경우 전역 고유 색인과 로컬 또는 원격 색인을 조합하여 사용합니다. 이 방법은 대부분의 쿼리가 요청된 데이터의 배치와 동일한 리전에 지리적으로 위치한 서비스에서 시작되는 경우에 적합합니다.
전역 색인을 쓸 때 쓰기 지연 시간은 추가 기본 쓰기 쿼럼 지연 시간이 적용됩니다.
휴리스틱 기반 최적화를 사용하면 쿼리가 로컬 색인 샤드에 의해 처리되며 대부분의 경우 리전 내 지연 시간이 표시됩니다.

특정 스키마 설계를 위한 색인 선택에 관한 자세한 가이드라인

최적의 색인 전략은 테이블의 기본 키 구조와 애플리케이션의 쿼리 패턴에 따라 달라집니다. 이 섹션에서는 세 가지 일반적인 스키마 설계에 적합한 색인 유형을 선택하는 방법을 안내합니다.

엔티티를 기본 키로 사용하는 스키마
위치를 기본 키로 사용하는 스키마
위치 관련 값을 기본 키로 사용하는 스키마

스키마 설계: 엔티티를 기본 키로 사용

스키마에서 항목을 기본 키로 사용하는 경우 쿼리에 위치가 지정되는지 여부에 따라 색인 생성 전략을 선택합니다.

customerID와 같은 항목이 기본 키이고 location와 같은 별도의 비키 열이 배치 키인 경우 쿼리 패턴에 따라 배치 테이블의 색인 생성 전략을 결정합니다. (삽입 지연 시간이 엔티티에 문제가 되는 경우 엔티티를 배치 테이블의 기본 키로 사용하지 마세요.)

customerID와 같은 특정 항목 아래에 데이터를 색인으로 만들려면 로컬 색인을 사용하세요. 데이터는 항목 내에서 색인이 생성되고 정렬되지만 항목 간에는 그렇지 않습니다. 예를 들어 각 고객의 주문을 날짜별로 색인화하려면 customerID ID 아래에 인터리브된 로컬 색인을 만들면 됩니다.

위치를 항상 쿼리에서 알 수 있는 경우 다음 전략 중 하나를 사용하세요.

쿼리에서 위치를 일관되게 알 수 있고 전역 고유성을 적용할 필요가 없는 경우 원격 색인을 사용하세요. 이러한 인덱스는 읽기 및 쓰기 작업 모두에 리전 내 지연 시간을 제공합니다.

원격 색인은 배치 테이블의 색인 열만 지원하며 인터리브 처리된 테이블의 열은 지원하지 않습니다. 원격 색인은 루트 배치 테이블 아래에 인터리브되어야 합니다. 원격 색인은 게재위치의 모든 배치 행에 걸쳐 데이터를 색인화합니다.

위치를 항상 알 수 없는 쿼리의 경우 다음 전략 중 하나를 사용하세요.

색인이 지정된 열이 전역적으로 고유한 경우 고유성을 적용하는 전역 고유 색인을 만듭니다.

지연 시간이 짧은 강력한 읽기를 달성하려면 전역 고유 색인 외에 원격 색인을 만드세요.

이 조합을 사용하면 쓰기에 리전 간 지연 시간이 발생할 수 있지만, 지정된 위치 (WHERE location= @location 사용)가 있는 쿼리는 원격 색인을 사용하여 리전 내 지연 시간의 이점을 누릴 수 있습니다. 위치가 지정되지 않은 쿼리의 경우 Spanner는 먼저 로컬에서 검색하여 휴리스틱 기반 최적화를 사용합니다. 데이터를 찾을 수 없으면 전역 색인으로 대체됩니다.

읽기 임대 리전을 사용하고 데이터와 동일한 리전에 기본 파티션의 읽기 전용 복제본이 있는 경우 읽기 임대 리전에서 이미 전역 색인의 읽기에 대해 강력한 읽기 지연 시간을 낮게 제공하므로 원격 색인이 필요하지 않습니다.
쿼리에서 위치를 지정하지 않고 색인이 생성된 열이 전역적으로 고유하지 않은 경우 전역 (고유하지 않은) 색인만 만듭니다. Spanner가 로컬 배치에서 데이터를 찾더라도 다른 배치에 일치하는 데이터가 있는지 확인할 수 없으므로 이 경우 로컬 또는 원격 색인을 추가해도 읽기 지연 시간이 개선되지 않습니다.

스키마 설계: 위치를 기본 키로 사용

location 열이 기본 키와 배치 키 역할을 모두 하는 경우 교차 지연 시간 문제와 쿼리에서 항상 위치를 지정하는지 여부에 따라 색인이 선택됩니다.

리전 간 지연 시간이 문제가 되지 않거나 전역 고유성이 필요한 경우 전역 인덱스를 사용합니다.
리전 간 지연 시간이 우려되고 쿼리에 항상 위치가 포함되며 Spanner에서 전역 고유성을 적용할 필요가 없는 경우 로컬 색스만 사용하세요. 이렇게 하면 읽기 및 쓰기 모두에 로컬 지연 시간이 보장됩니다.

리전 간 쿼리 지연 시간이 우려되고 리전 간 쓰기 지연 시간은 허용되며 위치를 항상 알 수 없는 경우 다음 전략이 적용됩니다.

조건	권장사항
전역적으로 고유한 부분 기본 키로 쿼리	고유성을 적용하는 고유한 전역 색인을 만듭니다. 기본 키가 유사한 기능을 수행하므로 로컬 색인이 필요하지 않습니다. 휴리스틱 기반 최적화가 적용됩니다. 먼저 Spanner는 글로벌 색인으로 대체하기 전에 로컬 위치에서 전체 기본 키를 확인합니다. 예를 보려면 부분 기본 키의 전역 고유 색인을 참고하세요.
키가 아닌 전역 고유 열로 쿼리	고유성을 적용하는 고유한 전역 색인을 만듭니다. 리전 내 지연 시간의 경우 다음 시나리오가 가능합니다. 전역 색인과 동일한 열에 로컬 색인을 만듭니다. 휴리스틱 기반 최적화가 적용됩니다. 전역 및 로컬 색인을 결합하면 리전 내 강력한 쿼리 및 오래된 쿼리의 지연 시간이 짧아지며, 쓰기 및 교차 리전 쿼리 및 쓰기에는 교차 리전 지연 시간이 적용됩니다. 데이터와 동일한 리전에 기본 파티션의 읽기-쓰기 또는 읽기 전용 복제본이 있는 경우 다음을 충족해야 합니다. 비활성 읽기에만 리전 내 지연 시간이 필요하고 강력한 읽기에는 필요하지 않은 경우 로컬 색인이 필요하지 않습니다. 로컬 복제본은 리전 내 지연 시간을 제공합니다. 강력한 읽기를 위해 리전 내 지연 시간이 필요한 경우 전역 색인과 동일한 열에 로컬 색인을 만들거나 읽기 임대 리전을 사용할 수 있습니다. 읽기 임대 리전은 쓰기 지연 시간이 증가하는 대신 강력한 읽기 지연 시간을 줄입니다.
색인 생성 열이 전역적으로 고유하지 않음	전역 색인만 만듭니다. Spanner가 모든 위치를 확인해야 할 수 있으므로 로컬 색인은 읽기 지연 시간을 개선하지 않습니다.

조건

권장사항

전역적으로 고유한 부분 기본 키로 쿼리

고유성을 적용하는 고유한 전역 색인을 만듭니다. 기본 키가 유사한 기능을 수행하므로 로컬 색인이 필요하지 않습니다. 휴리스틱 기반 최적화가 적용됩니다. 먼저 Spanner는 글로벌 색인으로 대체하기 전에 로컬 위치에서 전체 기본 키를 확인합니다.

예를 보려면 부분 기본 키의 전역 고유 색인을 참고하세요.

키가 아닌 전역 고유 열로 쿼리

고유성을 적용하는 고유한 전역 색인을 만듭니다.

리전 내 지연 시간의 경우 다음 시나리오가 가능합니다.

전역 색인과 동일한 열에 로컬 색인을 만듭니다. 휴리스틱 기반 최적화가 적용됩니다. 전역 및 로컬 색인을 결합하면 리전 내 강력한 쿼리 및 오래된 쿼리의 지연 시간이 짧아지며, 쓰기 및 교차 리전 쿼리 및 쓰기에는 교차 리전 지연 시간이 적용됩니다.
데이터와 동일한 리전에 기본 파티션의 읽기-쓰기 또는 읽기 전용 복제본이 있는 경우 다음을 충족해야 합니다.
- 비활성 읽기에만 리전 내 지연 시간이 필요하고 강력한 읽기에는 필요하지 않은 경우 로컬 색인이 필요하지 않습니다. 로컬 복제본은 리전 내 지연 시간을 제공합니다.
- 강력한 읽기를 위해 리전 내 지연 시간이 필요한 경우 전역 색인과 동일한 열에 로컬 색인을 만들거나 읽기 임대 리전을 사용할 수 있습니다. 읽기 임대 리전은 쓰기 지연 시간이 증가하는 대신 강력한 읽기 지연 시간을 줄입니다.

색인 생성 열이 전역적으로 고유하지 않음

전역 색인만 만듭니다. Spanner가 모든 위치를 확인해야 할 수 있으므로 로컬 색인은 읽기 지연 시간을 개선하지 않습니다.

이 세 가지 시나리오가 사용 사례에 적용되지 않는 경우 애플리케이션 단순성을 희생하거나 위치를 일관되게 제공하여 지연 시간을 작성해야 할 수 있습니다.

테이블의 기본 키가 위치 관련 값을 기반으로 하지만 배치 키 열이 아닌 경우 (예: 국가보다 배치가 적은 경우 country를 기본 키로 사용) 전역 색인 또는 로컬 색인 (country 열 아래에 인터리브됨)을 사용할 수 있습니다. 하지만 이러한 유형의 배치 테이블 아래에 인터리브된 테이블에는 원격 색인이 지원되지 않습니다.

이 시나리오에서는 휴리스틱 기반 최적화가 로컬 색인에 지원되지 않습니다. 따라서 쿼리에서 기본 키 접두사를 명시적으로 지정한 경우에만 로컬 지연 시간을 달성할 수 있습니다.

색인 및 지역 파티셔닝 컬렉션을 사용해 정리하기 내 환경설정을 기준으로 콘텐츠를 저장하고 분류하세요.

색인 유형

전역 색인

로컬 색인

GoogleSQL

PostgreSQL

GoogleSQL

PostgreSQL

GoogleSQL

PostgreSQL

원격 색인

GoogleSQL

PostgreSQL

GoogleSQL

PostgreSQL

GoogleSQL

PostgreSQL

전역 고유 색인 최적화

로컬 또는 원격 색인이 있는 전역 고유 색인

GoogleSQL

PostgreSQL

GoogleSQL

PostgreSQL

GoogleSQL

PostgreSQL

부분 기본 키의 전역 고유 색인

GoogleSQL

PostgreSQL

GoogleSQL

PostgreSQL

GoogleSQL

PostgreSQL

최적의 지연 시간을 위한 색인 유형 선택에 관한 일반 가이드라인

전역 인덱스를 선택해야 하는 경우

로컬 및 원격 색인을 선택해야 하는 경우

로컬 또는 원격 색인과 함께 전역 고유 색인을 선택해야 하는 경우

특정 스키마 설계를 위한 색인 선택에 관한 자세한 가이드라인

스키마 설계: 엔티티를 기본 키로 사용

스키마 설계: 위치를 기본 키로 사용

스키마 설계: 위치 관련 값을 기본 키로 사용

색인 및 지역 파티셔닝