SQL 권장사항

쿼리 실행 계획에 설명된 대로 SQL 컴파일러는 SQL 문을 쿼리 실행 계획으로 변환하며, 이 실행 계획은 쿼리 결과를 가져오는 데 사용됩니다. 이 페이지는 Spanner가 효율적인 실행 계획을 찾을 수 있도록 SQL 문을 구성하는 권장사항을 설명합니다.

이 페이지에 나온 SQL 문 예시에서는 다음과 같은 샘플 스키마를 사용합니다.

GoogleSQL

CREATE TABLE Singers (
 SingerId   INT64 NOT NULL,
 FirstName  STRING(1024),
 LastName   STRING(1024),
 SingerInfo BYTES(MAX),
 BirthDate  DATE
) PRIMARY KEY (SingerId);

CREATE TABLE Albums (
 SingerId     INT64 NOT NULL,
 AlbumId      INT64 NOT NULL,
 AlbumTitle   STRING(MAX),
 ReleaseDate  DATE
) PRIMARY KEY (SingerId, AlbumId),
INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

전체 SQL 참조는 문 문법, 함수 및 연산자, 어휘 구조 및 문법을 참조하세요.

PostgreSQL

CREATE TABLE Singers (
 SingerId   BIGINT PRIMARY KEY,
 FirstName  VARCHAR(1024),
 LastName   VARCHAR(1024),
 SingerInfo BYTEA,
 BirthDate  TIMESTAMPTZ
);

CREATE TABLE Albums (
 SingerId        BIGINT NOT NULL,
 AlbumId         BIGINT NOT NULL,
 AlbumTitle      VARCHAR(1024),
 ReleaseDate     DATE,
 PRIMARY KEY(SingerId, AlbumId),
 FOREIGN KEY (SingerId) REFERENCES Singers(SingerId)
) INTERLEAVE IN PARENT Singers ON DELETE CASCADE;

자세한 내용은 Spanner의 PostgreSQL 언어를 참조하세요.

쿼리 매개변수 사용

Spanner는 사용자 입력을 사용해서 쿼리를 생성할 때 성능을 늘리고 SQL 삽입을 방지하는 데 도움이 되는 쿼리 매개변수를 지원합니다. 임의의 표현식 대신 쿼리 매개변수를 사용할 수 있지만 식별자, 열 이름, 테이블 이름, 기타 쿼리 부분을 대신할 수는 없습니다.

매개변수는 리터럴 값이 필요한 모든 위치에 나타날 수 있습니다. 동일한 매개변수 이름은 단일 SQL 문에서 두 번 이상 사용될 수 있습니다.

요약하면 쿼리 매개변수는 다음과 같이 쿼리 실행을 지원합니다.

• 사전 최적화 계획: Spanner에서 실행 계획을 보다 간편하게 캐시할 수 있으므로 매개변수를 사용하는 쿼리를 각 호출에서 보다 빨리 실행할 수 있습니다.
• 간소화된 쿼리 작성: 쿼리 매개변수에 문자열 값 제공 시 이 문자열 값을 이스케이프할 필요가 없습니다. 또한 쿼리 매개변수는 문법 오류의 위험을 줄입니다.
• 보안: 쿼리 매개변수를 사용하면 다양한 SQL 삽입 공격으로부터 사용자가 보호되므로 쿼리가 보다 안전해집니다. 이는 특히 사용자 입력으로 작성된 쿼리의 경우에 중요합니다.

Spanner에서 쿼리를 실행하는 방법 이해

참고: Spanner 스튜디오(이전에는 Google Cloud 콘솔에서 쿼리 라벨이 지정됨)는 단일 편집기에서 SQL, DML, DDL 작업을 지원합니다. 자세한 내용은 Google Cloud 콘솔을 사용하여 데이터 관리를 참조하세요.

Spanner를 사용하면 검색할 데이터를 지정하는 선언적 SQL 문법을 사용하여 데이터베이스를 쿼리할 수 있습니다. Spanner가 결과를 가져오는 방법을 보려면 쿼리의 실행 계획을 조사하세요. 쿼리 실행 계획은 쿼리의 각 단계와 관련된 연산 비용을 표시합니다. 이러한 비용을 통해 쿼리 성능 문제를 디버깅하고 쿼리를 최적화할 수 있습니다. 자세한 내용은 쿼리 실행 계획을 참조하세요.

Google Cloud 콘솔 또는 클라이언트 라이브러리를 통해 쿼리 실행 계획을 검색할 수 있습니다.

Google Cloud 콘솔을 사용하여 특정 쿼리의 쿼리 실행 계획을 가져오려면 다음 단계를 따르세요.

1. Spanner 인스턴스 페이지를 엽니다.

   Spanner 인스턴스로 이동

2. Spanner 인스턴스의 이름과 쿼리할 데이터베이스를 선택합니다.

3. 왼쪽 탐색 패널에서 Spanner 스튜디오를 클릭합니다.

4. 텍스트 필드에 쿼리를 입력한 후 쿼리 실행을 클릭합니다.

5. 설명을 클릭합니다.
   Google Cloud 콘솔에 쿼리의 시각적 실행 계획이 표시됩니다.

   

시각적 계획을 이해하고 이를 사용하여 쿼리를 디버깅하는 방법에 대한 자세한 내용은 쿼리 계획 시각화 도구를 사용하여 쿼리 미세 조정을 참조하세요.

또한 이전 쿼리 계획의 샘플을 보고 시간 경과에 따른 특정 쿼리의 쿼리 성능을 비교할 수 있습니다. 자세한 내용은 샘플링된 쿼리 계획을 참조하세요.

보조 색인 사용

다른 관계형 데이터베이스와 마찬가지로 Spanner는 SQL 문법이나 Spanner의 읽기 인터페이스를 사용하여 데이터를 검색하는 데 사용할 수 있는 보조 색인을 제공합니다. 색인에서 데이터를 가져오는 보다 일반적인 방법은 Spanner 스튜디오를 사용하는 것입니다. SQL 쿼리에서 보조 색인을 사용하면 Spanner에서 결과를 얻는 방법을 지정할 수 있습니다. 보조 색인을 지정하면 쿼리 실행 속도가 빨라질 수 있습니다.

예를 들어 특정 성을 가진 모든 가수의 ID를 가져오려 한다고 가정해보겠습니다. 이러한 SQL 쿼리를 작성하는 한 가지 방법은 다음과 같습니다.

SELECT s.SingerId
FROM Singers AS s
WHERE s.LastName = 'Smith';

이 쿼리는 예상한 결과를 반환하지만 결과를 반환하는 데 시간이 오래 걸릴 수 있습니다. 소요 시간은 Singers 테이블의 행 수와 조건자 WHERE s.LastName = 'Smith'를 만족하는 행 수에 따라 달라집니다. 읽을 LastName 열을 포함하는 보조 색인이 없으면 조건자와 일치하는 행을 찾기 위해 쿼리 계획이 전체 Singers 테이블을 읽게 됩니다. 전체 테이블 읽기를 전체 테이블 스캔이라고 부릅니다. 테이블에 해당 성을 가진 Singers의 비율이 낮다면 전체 테이블 스캔 사용 시 결과를 얻는 데 많은 비용이 들어갑니다.

성 열에 보조 색인을 정의하여 이 쿼리의 성능을 향상시킬 수 있습니다.

CREATE INDEX SingersByLastName ON Singers (LastName);

보조 색인 SingersByLastName에는 색인이 생성된 테이블 열 LastName과 기본 키 열 SingerId가 포함되어 있으므로, Spanner는 전체 Singers 테이블을 스캔하는 대신 훨씬 더 작은 색인 테이블에서 모든 데이터를 가져올 수 있습니다.

이 시나리오에서는 쿼리를 실행할 때 Spanner에서 보조 색인 SingersByLastName을 자동으로 사용합니다(데이터베이스 생성 후 3일이 경과한 경우 새 데이터베이스에 대한 참고사항 참조). 하지만 FROM 절에 색인 지시문을 지정하여 Spanner에 이 색인 사용을 명시적으로 지시하는 것이 가장 좋은 방법입니다.

GoogleSQL

SELECT s.SingerId
FROM Singers@{FORCE_INDEX=SingersByLastName} AS s
WHERE s.LastName = 'Smith';

PostgreSQL

 SELECT s.SingerId
FROM Singers /*@ FORCE_INDEX=SingersByLastName */ AS s
WHERE s.LastName = 'Smith';

이제 가수의 ID와 이름도 가져오려고 한다고 가정해 보겠습니다. FirstName 열이 색인에 포함되어 있지 않더라도 이전과 동일하게 색인 지시문을 지정해야 합니다.

GoogleSQL

SELECT s.SingerId, s.FirstName
FROM Singers@{FORCE_INDEX=SingersByLastName} AS s
WHERE s.LastName = 'Smith';

PostgreSQL

SELECT s.SingerId, s.FirstName
FROM Singers /*@ FORCE_INDEX=SingersByLastName */ AS s
WHERE s.LastName = 'Smith';

쿼리 계획 실행 시 Spanner가 전체 테이블 스캔을 수행할 필요가 없으므로, 여전히 색인 사용을 통한 성능상의 이점을 얻을 수 있습니다. 대신, SingersByLastName 색인에서 조건자를 충족하는 행의 하위 집합을 선택한 후 기본 테이블 Singers에서 찾기를 수행하여 행의 하위 집합에 대한 이름만 가져옵니다.

Spanner가 기본 테이블에서 행을 전혀 가져오지 않도록 하려면 FirstName 열의 사본을 색인 자체에 저장하면 됩니다.

GoogleSQL

CREATE INDEX SingersByLastName ON Singers (LastName) STORING (FirstName);

PostgreSQL

CREATE INDEX SingersByLastName ON Singers (LastName) INCLUDE (FirstName);

이와 같이 STORING 절(GoogleSQL 언어의 경우) 또는 INCLUDE 절(PostgreSQL 언어의 경우)을 사용하면 추가 스토리지가 필요하지만 다음과 같은 이점이 있습니다.

• 색인을 사용하고 STORING 또는 INCLUDE 절에 저장된 열을 선택하는 SQL 쿼리는 기본 테이블에 추가 조인을 할 필요가 없습니다.
• 색인을 사용하는 읽기 호출은 STORING 또는 INCLUDE절에 저장된 열을 읽을 수 있습니다.

이전의 예시에서는 보조 색인을 사용하여 쿼리의 WHERE 절에 의해 선택된 행을 신속하게 식별할 수 있는 경우, 보조 색인으로 쿼리 속도를 높일 수 있는 방법을 보여줍니다.

보조 색인이 성능 이점을 제공할 수 있는 또 다른 상황은 정렬된 결과를 반환하는 특정 쿼리의 경우입니다. 예를 들어 모든 앨범 제목과 앨범 출시 날짜를 가져오고 출시 날짜 기준 오름차순 그리고 앨범 제목 기준 내림차순으로 표시한다고 가정해 보세요. 다음과 같은 SQL 쿼리를 작성할 수 있습니다.

SELECT a.AlbumTitle, a.ReleaseDate
FROM Albums AS a
ORDER BY a.ReleaseDate, a.AlbumTitle DESC;

보조 색인이 없으면 이 쿼리는 실행 계획에서 비싼 정렬 단계를 거쳐야 할 수 있습니다. 이 보조 색인을 정의하여 쿼리 실행 속도를 높일 수 있습니다.

CREATE INDEX AlbumsByReleaseDateTitleDesc on Albums (ReleaseDate, AlbumTitle DESC);

그런 다음 보조 색인을 사용하도록 쿼리를 다시 작성합니다.

GoogleSQL

SELECT a.AlbumTitle, a.ReleaseDate
FROM Albums@{FORCE_INDEX=AlbumsByReleaseDateTitleDesc} AS a
ORDER BY a.ReleaseDate, a.AlbumTitle DESC;

PostgreSQL

SELECT a.AlbumTitle, a.ReleaseDate
FROM Albums /*@ FORCE_INDEX=AlbumsByReleaseDateTitleDesc */ AS s
ORDER BY a.ReleaseDate, a.AlbumTitle DESC;

이 쿼리와 색인 정의는 다음 기준을 모두 충족합니다.

• 정렬 단계를 삭제하려면 ORDER BY 절에 있는 열 목록이 색인 키 목록의 프리픽스인지 확인합니다.
• 누락된 열을 가져오기 위해 기본 테이블에서 다시 조인하는 것을 방지하려면 쿼리에 사용되는 테이블의 모든 열이 색인에 포함되어 있는지 확인합니다.

보조 색인을 사용하면 일반 쿼리 속도가 빨라질 수 있지만 일반적으로 보조 색인을 추가할 때마다 각 커밋에 추가 노드가 관여되기 때문에 보조 색인 추가로 인해 커밋 작업의 지연 시간이 증가할 수 있습니다. 대부분의 워크로드에서 보조 색인이 몇 개 있는 정도는 문제되지 않습니다. 그러나 읽기 또는 쓰기 지연 시간에 더 신경을 써야 하는지, 그리고 워크로드에 가장 중요한 작업이 무엇인지 고려해야 합니다. 워크로드를 벤치마킹하여 예상대로 수행되는지 확인합니다.

보조 색인에 대한 자세한 참고 자료는 보조 색인을 참조하세요.

스캔 최적화

특정 Spanner 쿼리는 데이터를 스캔할 때 보다 일반적인 행 중심 처리 방법이 아닌 일괄 중심 처리 메서드를 사용하는 이점이 있을 수 있습니다. 일괄 처리로 스캔을 처리하는 것이 대량의 데이터 볼륨을 모두 한 번에 처리하는 것보다 효율적이며, 쿼리의 CPU 사용률과 지연 시간을 낮출 수 있습니다.

Spanner 스캔 작업은 항상 행 중심 모드에서 실행을 시작합니다. 이 시간 동안 Spanner는 여러 런타임 측정항목을 수집합니다. 그런 후 Spanner가 이러한 측정항목의 결과에 따라 일련의 휴리스틱을 적용하여 최적의 스캔 모드를 결정합니다. 해당되는 경우 Spanner는 일괄 중심 처리 모드로 전환하여 스캔 처리량 및 성능을 향상시킵니다.

일반적인 사용 사례

다음 특성의 쿼리는 일반적으로 배치 지향 처리를 사용하는 것이 좋습니다.

• 가끔 업데이트되는 데이터에 대한 대규모 스캔
• 고정 너비 열의 조건자를 사용하는 스캔
• 대규모 탐색 수로 스캔 (탐색은 색인을 사용하여 레코드를 검색함)

성능 이점이 없는 사용 사례

배치 지향 처리가 모든 쿼리에 도움이 되지는 않습니다. 행 중심 스캔 처리 시 다음 쿼리 유형의 성능이 더 뛰어납니다.

• 포인트 조회 쿼리: 행 하나만 가져오는 쿼리
• 소규모 스캔 쿼리: 대규모 탐색 수가 있지 않으면 일부 행만 스캔하는 테이블 스캔
• LIMIT를 사용하는 쿼리
• 변동률이 높은 데이터를 읽는 쿼리: 자주 업데이트되는 읽은 데이터의 10% 이상에서 수행되는 쿼리
• 큰 값이 포함된 행이 있는 쿼리: 큰 값을 포함하는 행은 단일 열에 32,000 바이트보다 큰 값이 포함된 행입니다(압축 전).

쿼리에 사용된 스캔 방법 확인

쿼리가 일괄 처리, 행 중심 처리를 사용하는지 또는 두 스캔 방법이 자동으로 전환되는지 확인하려면 다음 안내를 따르세요.

1. Google Cloud 콘솔에서 Spanner 인스턴스 페이지로 이동합니다.

   인스턴스 페이지로 이동

2. 조사하려는 쿼리가 있는 인스턴스 이름을 클릭합니다.

3. 데이터베이스 테이블 아래에서 조사하려는 쿼리가 있는 데이터베이스를 클릭합니다.

4. 탐색 메뉴에서 Spanner 스튜디오를 클릭합니다.

5. 새 SQL 편집기 탭 또는 새 탭을 클릭하여 새 탭을 엽니다.

6. 쿼리 편집기가 나타나면 쿼리를 작성합니다.

7. 실행을 클릭합니다.

   Spanner가 쿼리를 실행하고 결과를 표시합니다.

8. 쿼리 편집기 아래에서 설명 탭을 클릭합니다.

   Spanner가 쿼리 계획 실행 계획 시각화 도구를 표시합니다. 그래프의 각 카드는 반복자를 나타냅니다.

9. 테이블 스캔 반복자 카드를 클릭하여 정보 패널을 엽니다.

   정보 패널에는 선택한 스캔에 대한 컨텍스트 정보가 표시됩니다. 스캔 방법이 이 카드에 표시됩니다. 자동은 Spanner가 스캔 방법을 결정합니다. 다른 가능한 값으로는 일괄 처리 처리를 위한 벡터화 및 행 중심 처리를 위한 스칼라가 있습니다.

   

쿼리에 사용된 스캔 방법을 적용하는 방법

쿼리 성능을 최적화하기 위해 Spanner는 쿼리에 대해 최적의 스캔 방법을 선택합니다. 이 기본 스캔 방법을 사용하는 것이 좋습니다. 하지만 특정 유형의 스캔 방법을 적용해야 할 수도 있습니다.

일괄 중심 스캔을 시행하는 방법

테이블 수준 및 문 수준에서 일괄 중심 스캔을 적용할 수 있습니다.

테이블 수준에서 일괄 중심 스캔 메서드를 적용하려면 쿼리에 테이블 힌트를 사용합니다.

GoogleSQL

  SELECT ...
  FROM (t1@{SCAN_METHOD=BATCH} JOIN t2 ON ...)
  WHERE ...

PostgreSQL

  SELECT ...
  FROM (t1/*@ scan_method=batch */ JOIN t2 on ...)
  WHERE ...

문 수준에서 배치 지향 스캔 방법을 적용하려면 쿼리에 문 힌트를 사용합니다.

GoogleSQL

  @{SCAN_METHOD=BATCH}
  SELECT ...
  FROM ...
  WHERE ...

PostgreSQL

  /*@ scan_method=batch */
  SELECT ...
  FROM ...
  WHERE ...

자동 스캔을 사용 중지하고 행 중심 스캔을 시행하는 방법

Spanner에서 설정한 자동 스캔 방법을 사용 중지하지 않는 것이 좋지만 지연 시간을 진단하는 것과 같은 문제 해결을 위해 이를 사용 중지하고 행 중심 스캔 방법을 사용할 수도 있습니다.

자동 스캔 방법을 사용 중지하고 테이블 수준에서 행 처리를 적용하려면 쿼리에 테이블 힌트를 사용하세요.

GoogleSQL

  SELECT ...
  FROM (t1@{SCAN_METHOD=ROW} JOIN t2 ON ...)
  WHERE ...

PostgreSQL

  SELECT ...
  FROM (t1/*@ scan_method=row */ JOIN t2 on ...)
  WHERE ...

자동 스캔 메서드를 사용 중지하고 문 수준에서 행 처리를 적용하려면 쿼리에 문 힌트를 사용하세요.

GoogleSQL

  @{SCAN_METHOD=ROW}
  SELECT ...
  FROM ...
  WHERE ...

PostgreSQL

  /*@ scan_method=row */
  SELECT ...
  FROM ...
  WHERE ...

범위 키 조회 최적화

SQL 쿼리의 일반적인 용도는 알려진 키 목록을 기반으로 Spanner에서 여러 행을 읽기 위함입니다.

다음 권장사항은 키 범위에 따라 데이터를 가져올 때 효율적인 쿼리를 작성하는 데 도움이 됩니다.

• 키 목록이 희소하고 인접하지 않은 경우 쿼리 매개변수와 UNNEST를 사용하여 쿼리를 구성합니다.

  예를 들어 키 목록이 {1, 5, 1000}이라면 다음과 같이 쿼리를 작성합니다.

  GoogleSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key IN UNNEST (@KeyList)

  PostgreSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key IN UNNEST ($1)

  참고:

  • 배열 UNNEST 연산자는 입력 배열을 요소 행으로 평면화합니다.

  • 쿼리 매개변수(GoogleSQL의 경우 @KeyList, PostgreSQL의 경우 $1)를 사용하면 이전 권장사항의 설명과 같이 쿼리 속도를 높일 수 있습니다.

• 키 목록이 인접해 있고 범위 내에 있으면 WHERE 절에서 키 범위의 하한과 상한 한도를 지정합니다.

  예를 들어 키 목록이 {1,2,3,4,5}면 쿼리를 다음과 같이 작성합니다.

  GoogleSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key BETWEEN @min AND @max

  참고: 여기서 @min 및 @max는 각각 값 1과 5에 바인딩된 쿼리 매개변수입니다.

  PostgreSQL

  SELECT *
  FROM Table AS t
  WHERE t.Key BETWEEN $1 AND $2

  참고: 여기서 $1 및 $2는 각각 값 1과 5에 바인딩된 쿼리 매개변수입니다.

  이 쿼리는 키 범위의 키가 인접한 경우에만 더 효율적입니다. 즉, 키 목록이 {1, 5, 1000}인 경우 결과 쿼리가 1부터 1,000 사이의 모든 값을 스캔하므로 이전 쿼리와 같이 상한 및 하한 한도를 지정하면 안 됩니다.

조인 최적화

조인 작업은 쿼리가 스캔해야 하는 행 수를 크게 늘려 쿼리가 더 느려질 수 있으므로 비용이 많이 들 수 있습니다. 다른 관계형 데이터베이스에서 조인 쿼리를 최적화하기 위해 사용하는 익숙한 기술 외에도 Spanner SQL 사용 시 보다 효율적인 JOIN에 유용한 몇 가지 권장사항이 있습니다.

• 가능하다면 인터리빙된 테이블 내의 데이터를 기본 키로 조인합니다. 예를 들면 다음과 같습니다.

  SELECT s.FirstName, a.ReleaseDate
  FROM Singers AS s JOIN Albums AS a ON s.SingerId = a.SingerId;

  스키마 및 데이터 모델에서 논의한 것처럼 인터리브 처리된 테이블 Albums의 행은 Singers에서 상위 행과 동일한 분할에 물리적으로 저장됩니다. 따라서 네트워크를 통해 많은 양의 데이터를 보내지 않고도 조인을 로컬에서 완료할 수 있습니다.

• 조인 순서를 강제로 적용하려면 조인 지시문을 사용합니다. 예를 들면 다음과 같습니다.

  GoogleSQL

  SELECT *
  FROM Singers AS s JOIN@{FORCE_JOIN_ORDER=TRUE} Albums AS a
  ON s.SingerId = a.Singerid
  WHERE s.LastName LIKE '%x%' AND a.AlbumTitle LIKE '%love%';

  PostgreSQL

  SELECT *
  FROM Singers AS s JOIN/*@ FORCE_JOIN_ORDER=TRUE */ Albums AS a
  ON s.SingerId = a.Singerid
  WHERE s.LastName LIKE '%x%' AND a.AlbumTitle LIKE '%love%';

  조인 지시문 FORCE_JOIN_ORDER는 Spanner가 쿼리에 지정된 조인 순서(즉, Albums JOIN Singers가 아니라 Singers JOIN Albums)를 사용하도록 합니다. 반환되는 결과는 Spanner에서 선택한 순서와 관계없이 동일합니다. 하지만 쿼리 계획에서 Spanner가 조인 순서를 변경하고 더 큰 중간 결과와 같은 원치 않은 결과를 발생시켰거나 행을 찾을 기회를 놓쳤다는 것을 알게 된 경우, 이 조인 지시문을 사용할 수 있습니다.

• 조인 지시문을 사용하여 조인 구현을 선택합니다. SQL을 사용하여 여러 테이블을 쿼리하면 Spanner는 쿼리 효율을 높일 수 있는 조인 메서드를 자동으로 사용합니다. 그러나 Google은 다른 조인 알고리즘으로 테스트할 것을 권장합니다. 적합한 조인 알고리즘을 선택하면 지연 시간이나 메모리 소비 또는 둘 다 향상될 수 있습니다. 이 쿼리에서는 JOIN_METHOD 힌트와 함께 JOIN 지시문을 사용하여 HASH JOIN을 선택하는 문법을 보여줍니다.

  GoogleSQL

  SELECT *
  FROM Singers s JOIN@{JOIN_METHOD=HASH_JOIN} Albums AS a
  ON a.SingerId = a.SingerId

  PostgreSQL

  SELECT *
  FROM Singers s JOIN/*@ JOIN_METHOD=HASH_JOIN */ Albums AS a
  ON a.SingerId = a.SingerId

• HASH JOIN 또는 APPLY JOIN을 사용 중이고 JOIN의 한쪽에 매우 까다로운 WHERE 절이 있는 경우 조인의 FROM 절에 가장 적은 수의 행을 생성하는 테이블을 첫 번째 테이블로 배치합니다. 이 구조는 HASH JOIN에서 현재까지 Spanner가 항상 왼쪽 측면의 테이블을 빌드로 선택하고 오른쪽 측면의 테이블을 프로브로 선택하기 때문에 도움이 됩니다. 마찬가지로 APPLY JOIN의 경우 Spanner는 왼쪽 테이블을 바깥쪽으로 선택하고 오른쪽 테이블을 안쪽으로 선택합니다. 해시 조인 및 적용 조인과 같은 조인 유형에 대해 자세히 알아보세요.

• 워크로드에 중요한 쿼리의 경우 보다 일관된 성능을 위해 SQL 문에서 가장 효과적인 조인 메서드와 조인 순서를 지정합니다.

읽기-쓰기 트랜잭션 내에서 큰 읽기 방지

읽기-쓰기 트랜잭션은 0개 이상의 읽기 또는 SQL 쿼리의 시퀀스를 허용하며 커밋할 호출 전에 일련의 변형을 포함할 수 있습니다. 데이터 일관성이 유지되도록 Spanner는 테이블과 색인에서 행을 읽고 쓸 때 잠금을 획득합니다. 잠금에 대한 자세한 내용은 읽기 및 쓰기 수명을 참조하세요.

Spanner에서 잠금이 작동하는 방식으로 인해 많은 수의 행(예: SELECT * FROM Singers)을 읽는 읽기 또는 SQL 쿼리를 수행하면 트랜잭션이 커밋 또는 취소될 때까지 읽은 행에 다른 트랜잭션이 쓰기를 수행할 수 없습니다.

또한 트랜잭션이 많은 수의 행을 처리하므로 훨씬 작은 행 범위를 읽는 트랜잭션(예: SELECT LastName FROM Singers WHERE SingerId = 7)보다 시간이 더 오래 걸릴 수 있어, 문제가 더욱 악화되고 시스템 처리량이 줄어듭니다.

따라서 낮은 쓰기 처리량을 수용하려는 경우가 아니라면 트랜잭션에서 대량의 읽기(예: 전체 테이블 스캔 또는 대량 조인 작업)를 가능한 한 방지합니다.

경우에 따라 다음 패턴을 사용하면 더 나은 결과를 얻을 수 있습니다.

1. 읽기 전용 트랜잭션 내에서 대량 읽기를 수행합니다. 읽기 전용 트랜잭션은 잠금을 사용하지 않기 때문에 더 높은 집계 처리량을 허용합니다.
2. (선택사항) 방금 읽은 데이터에 필요한 모든 처리를 수행합니다.
3. 읽기-쓰기 트랜잭션을 시작합니다.
4. 1단계에서 읽기 전용 트랜잭션을 수행한 이후 중요 행의 값이 변경되지 않았는지 확인합니다.
   • 행이 변경됐다면 트랜잭션을 롤백하고 1단계부터 다시 시작합니다.
   • 문제점이 없으면 변형을 커밋합니다.

읽기-쓰기 트랜잭션에서 대규모 읽기를 방지하기 위한 한 가지 방법은 쿼리로 생성되는 실행 계획을 살펴보는 것입니다.

ORDER BY를 사용하여 SQL 결과 순서 보장

SELECT 쿼리 결과에 대해 특정 순서가 필요할 것으로 예상되는 경우 ORDER BY 절을 명시적으로 포함합니다. 예를 들어 모든 가수를 기본 키 순서로 나열하려면 다음 쿼리를 사용합니다.

SELECT * FROM Singers
ORDER BY SingerId;

Spanner는 ORDER BY 절이 쿼리에 있는 경우에만 결과 순서를 보장합니다. 즉, ORDER BY가 없는 다음 쿼리를 고려하세요.

SELECT * FROM Singers;

Spanner는 이 쿼리 결과가 기본 키 순서라고 보장하지 않습니다. 또한 결과 순서는 언제든지 변경될 수 있으며 호출마다 일관성이 보장되지는 않습니다. 쿼리에 ORDER BY 절이 있고 Spanner가 필요한 순서를 제공하는 색인을 사용하는 경우에는 Spanner가 데이터를 명시적으로 정렬하지 않습니다. 따라서 이 절을 포함하여 발생하는 성능 영향은 걱정할 필요가 없습니다. 쿼리 계획을 보고 실행에 명시적 정렬 작업을 포함할지 여부를 확인할 수 있습니다.

LIKE 대신 STARTS_WITH 사용

Spanner는 매개변수화된 LIKE 패턴을 실행 시간 전까지 평가하지 않기 때문에 모든 행을 읽고 LIKE 표현식과 비교하여 일치하지 않는 행을 필터링해야 합니다.

LIKE 패턴의 형식이 foo%이고(예: 고정 문자열로 시작하고 단일 와일드 카드 비율로 종료) 열의 색인이 생성되는 경우 LIKE 대신에 STARTS_WITH를 사용하세요. 이 옵션을 사용하면 Spanner가 쿼리 실행 계획을 더 효과적으로 최적화할 수 있습니다.

다음은 권장하지 않습니다.

GoogleSQL

SELECT a.AlbumTitle FROM Albums a
WHERE a.AlbumTitle LIKE @like_clause;

참고: 이 예시에서는 @like_clause가 'Love%'에 바인딩된다고 가정합니다.

PostgreSQL

SELECT a.AlbumTitle FROM Albums a
WHERE a.AlbumTitle LIKE $1;

참고: 이 예시에서는 $2가 'Love%'에 바인딩된다고 가정합니다.

권장:

GoogleSQL

SELECT a.AlbumTitle FROM Albums a
WHERE STARTS_WITH(a.AlbumTitle, @prefix);

참고: 이 예시에서는 @prefix가 'Love'에 바인딩된다고 가정합니다. 이 쿼리는 이전 쿼리보다 훨씬 더 효율적입니다. Albums.AlbumTitle에 정의된 색인이 있을 경우 더 빠르게 실행됩니다.

PostgreSQL

SELECT a.AlbumTitle FROM Albums a
WHERE STARTS_WITH(a.AlbumTitle, $2);

참고: 이 예시에서는 $1이 'Love'에 바인딩된다고 가정합니다. 이 쿼리는 이전 쿼리보다 훨씬 더 효율적입니다. Albums.AlbumTitle에 정의된 색인이 있을 경우 더 빠르게 실행됩니다.

커밋 타임스탬프 사용

애플리케이션이 특정 시간 이후에 작성된 데이터를 쿼리해야 하는 경우 관련 테이블에 커밋 타임스탬프 열을 추가합니다. 커밋 타임스탬프를 사용 설정하면 WHERE 절이 특정 시간보다 최근에 작성된 행으로 결과를 제한하는 쿼리의 I/O를 줄일 수 있는 Spanner 최적화가 사용 설정됩니다.

GoogleSQL 언어 데이터베이스 또는 PostgreSQL 언어 데이터베이스를 사용하여 이 최적화에 대해 자세히 알아봅니다.