읽기

이 페이지에서는 Bigtable에 보낼 수 있는 읽기 요청의 유형과 성능에 미치는 영향을 설명하고 특정 유형의 쿼리에 대한 몇 가지 권장사항을 제시합니다. 이 페이지를 읽기 전에 Bigtable 개요를 숙지해야 합니다.

개요

Bigtable에 대한 읽기 요청은 요청된 행의 콘텐츠를 키 순서로 다시 스트리밍합니다. 즉, 저장된 순서대로 반환됩니다. 응답을 반환한 모든 쓰기를 읽을 수 있습니다.

테이블이 지원하는 쿼리는 사용 사례에 가장 적합한 읽기 유형을 결정하는 데 도움이 됩니다. Bigtable 읽기 요청은 다음 두 가지 일반 범주로 나뉩니다.

단일 행 읽기
스캔 또는 여러 행 읽기

읽기는 행 수준에서 원자적으로 이루어집니다. 즉, 행에 대한 읽기 요청을 보내면 Bigtable은 전체 행을 반환하고, 요청이 실패하는 경우 아무 행도 반환하지 않습니다. 부분 행은 특별히 요청하지 않는 한 반환되지 않습니다.

API를 직접 호출하는 대신 Cloud Bigtable 클라이언트 라이브러리를 사용하여 테이블에서 데이터를 읽는 것이 좋습니다. 읽기 요청을 보내는 방법을 보여주는 코드 샘플은 여러 언어로 제공됩니다. 모든 읽기 요청은 ReadRows API를 호출합니다.

Data Boost 서버리스 컴퓨팅으로 데이터 읽기

Bigtable Data Boost를 사용하면 일일 애플리케이션 트래픽에 영향을 주지 않고 일괄 읽기 작업 및 쿼리를 실행할 수 있습니다. Data Boost는 핵심 애플리케이션이 클러스터 노드를 컴퓨팅에 사용하는 동안 Bigtable 데이터를 읽는 데 사용할 수 있는 서버리스 컴퓨팅 서비스입니다.

Data Boost는 스캔에 이상적이며 단일 행을 읽을 때는 권장되지 않습니다. 역방향 스캔에는 Data Boost를 사용할 수 없습니다. 자세한 내용과 자격 기준은 Data Boost 개요를 참조하세요.

단일 행 읽기

row key에 따라 단일 행을 요청할 수 있습니다. 포인트 읽기라고도 하는 단일 행 읽기는 Data Boost와 호환되지 않습니다. 다음 변형에 코드 샘플을 사용할 수 있습니다.

스캔

스캔은 Bigtable 데이터를 읽는 가장 일반적인 방법입니다. row key 프리픽스를 지정하거나 시작 및 종료 row key를 지정하여 Bigtable에서 연속된 행 범위 또는 여러 행 범위를 읽을 수 있습니다. 다음 변형에 코드 샘플을 사용할 수 있습니다.

역방향 스캔

역방향 스캔을 사용하면 row key 프리픽스 또는 행 범위를 지정하여 행 범위를 역방향으로 읽을 수 있습니다. row key 프리픽스는 역방향 읽기를 위한 스캔 시작 지점으로 사용됩니다. 행 범위를 지정할 때 끝 row key는 스캔 시작 지점으로 사용됩니다.

역방향 스캔은 다음과 같은 시나리오에 유용할 수 있습니다.

이벤트(행)를 찾은 후 이전 N개의 이벤트를 읽으려고 합니다.
지정된 값 이전의 최고 값을 찾습니다. 이는 타임스탬프를 row key 서픽스로 사용하여 시계열 데이터를 저장할 때 유용할 수 있습니다.

역방향 스캔은 정방향 스캔보다 덜 효율적입니다. 보통은 대부분의 스캔이 정방향으로 진행되도록 row key를 설계합니다. 지연 시간이 짧은 응답 시간을 유지하기 위해 짧은 스캔(예: 행 50개 이하)에 역방향 스캔을 사용합니다.

역방향으로 스캔하려면 ReadRowsRequest 필드 reversed의 값을 true로 설정합니다. 기본값은 false입니다.

역방향 스캔은 다음 클라이언트 라이브러리를 사용할 때 사용할 수 있습니다.

C++ 버전 2.18.0 이상의 Bigtable 클라이언트 라이브러리
Go 버전 1.21.0 이상의 Bigtable 클라이언트 라이브러리
Java 버전 2.24.1 이상의 Bigtable 클라이언트 라이브러리
Java 버전 2.10.0 이상의 Bigtable HBase 클라이언트

역방향 스캔 사용 방법을 보여주는 코드 샘플은 역방향으로 스캔을 참조하세요.

사용 사례

다음 예시에서는 역방향 스캔을 이용해서 한 고객이 비밀번호를 변경한 마지막 시점과 특정 일자의 제품 가격 변동폭을 찾는 방법을 보여줍니다.

비밀번호 재설정

row key에 각각 고객 ID와 날짜가 123ABC#2022-05-02 형식으로 포함되어 있고, 열 중 하나가 비밀번호가 재설정된 시간을 저장하는 password_reset이라고 가정해 보겠습니다. Bigtable은 다음과 같이 자동으로 데이터를 사전순으로 저장합니다. 비밀번호가 재설정되지 않은 행(일)에는 열이 없음에 유의하세요.

`123ABC#2022-02-12,password_reset:03`
`123ABC#2022-04-02,password_reset:11`
`123ABC#2022-04-14`
`123ABC#2022-05-02`
`223ABC#2022-05-22`

고객 123ABC가 비밀번호를 마지막으로 재설정한 시간을 찾으려면 행 한도가 1이고 password_reset 열이 포함된 모든 행에 대해 오늘 날짜 또는 미래의 날짜를 사용해 123ABC#의 범위를 123ABC#<DATE>까지 역방향으로 스캔하면 됩니다.

가격 변경

이 예시의 row key에는 제품, 모델, 타임스탬프 값이 포함되며 열 중 하나에 특정 시간의 제품 및 모델 가격이 포함되어 있습니다.

`productA#model2#1675604471,price:82.63`
`productA#model2#1676219411,price:82.97`
`productA#model2#1677681011,price:83.15`
`productA#model2#1680786011,price:83.99`
`productA#model2#1682452238,price:83.12`

2023년 2월 14일의 가격 변동을 확인하려면 특정 날짜의 row key가 테이블에 존재하지 않더라도 productA#model2#1676376000 row key부터 N개 행에 대한 정방향 스캔을 수행한 후 동일한 시작 행의 동일 개수의 행에 대한 역방향 스캔을 수행합니다. 두 번의 스캔으로 지정된 시간 이전과 이후의 가격을 얻을 수 있습니다.

필터링된 읽기

특정 값이나 부분 행을 포함하는 행만 필요할 경우 읽기 요청에 필터를 사용할 수 있습니다. 필터를 사용하면 원하는 데이터를 선택할 수 있습니다.

또한 필터를 사용하면 테이블이 사용 중인 가비지 컬렉션 정책과 읽기가 일치하도록 할 수 있습니다. 이는 타임스탬프가 적용된 새 셀을 기존 열에 자주 쓰는 경우에 특히 유용합니다. 가비지 컬렉션은 만료된 데이터를 삭제하는 데 최대 1주일이 걸릴 수 있으므로 타임스탬프 범위 필터를 사용하여 데이터를 읽으면 필요 이상으로 많은 데이터를 읽지 않도록 할 수 있습니다.

필터 개요는 사용할 수 있는 필터 유형에 대한 자세한 설명을 제공합니다. 필터 사용은 여러 언어로 예시를 보여줍니다.

승인된 뷰에서 데이터 읽기

승인된 뷰에서 데이터를 읽으려면 다음 중 하나를 사용해야 합니다.

gcloud CLI
Java용 Bigtable 클라이언트

다른 Bigtable 클라이언트 라이브러리는 아직 뷰 액세스를 지원하지 않습니다.

Bigtable Data API의 ReadRows 또는 SampleRowKeys 메서드를 호출하는 모든 메서드가 지원됩니다. 클라이언트를 만들 때 테이블 ID 외에 승인된 뷰 ID를 제공합니다.

읽기 및 성능

필터를 사용하는 읽기는 필터가 없는 읽기보다 느리며, CPU 사용률을 높입니다. 반면 반환되는 데이터의 양을 제한하여 사용하는 네트워크 대역폭의 양을 크게 줄일 수 있습니다. 일반적으로 필터는 지연 시간이 아니라 처리량 효율을 제어하기 위해 사용해야 합니다.

읽기 성능을 최적화하려면 다음 전략을 고려하세요.

행 집합을 최대한 제한합니다. 노드가 스캔해야 하는 행 수를 제한하는 것은 첫 번째 바이트 시간과 전체 쿼리 지연 시간을 개선하는 첫 단계입니다. 행 집합을 제한하지 않으면 Bigtable은 십중팔구 전체 테이블을 스캔해야 합니다. 따라서 가장 일반적인 쿼리가 이러한 방식으로 작동하도록 스키마를 설계하는 것이 좋습니다.
행 집합을 제한한 후에 추가 성능 조정을 수행하려면 기본 필터를 추가해 보세요. 열 집합 또는 반환되는 버전 수를 제한해도 일반적으로 지연 시간은 늘어나지 않으며, Bigtable이 각 행에서 관련 없는 과거 데이터를 더 효율적으로 찾는 데 도움이 될 수도 있습니다.
처음 두 가지 전략 이후에 읽기 성능을 더 세부적으로 조정하려면 복잡한 필터를 사용하는 것이 좋습니다. 이를 시도해 볼 만한 몇 가지 이유는 다음과 같습니다.
- 원하지 않는 데이터가 여전히 많이 반환되고 있습니다.
- 쿼리를 Bigtable로 푸시하여 애플리케이션 코드를 단순화하려고 합니다.
다만 큰 값에서 조건, 인터리브 또는 정규 표현식 일치를 요구하는 필터는 스캔된 데이터 대부분을 통과시키는 경우 피해를 입힐 수 있습니다. 이 피해는 클라이언트 측의 대규모 절감 없는 클러스터의 CPU 사용률 증가라는 형태로 나타납니다.

이러한 전략 외에도 단일 읽기 요청에서 연속되지 않은 다수의 row key 또는 행 범위를 읽지 않도록 합니다. 단일 요청에서 row key 또는 행 범위 수백 개를 요청하면 Bigtable은 테이블을 스캔하고 요청된 행을 순차적으로 읽습니다. 이러한 동시 로드 부족은 전체 지연 시간에 영향을 미치며 핫 노드에 발생하는 읽기는 꼬리 지연 시간을 늘릴 수 있습니다. 요청한 행 범위가 많을수록 읽기를 완료하는 데 시간이 오래 걸립니다. 이 지연 시간을 허용할 수 없으면 대신 각각 행 범위를 적게 가져오는 동시 요청 여러 개를 전송해야 합니다.

일반적으로 단일 요청에서 더 많은 행 범위를 읽으면 처리량이 최적화되지만 지연 시간은 최적화되지 않습니다. 여러 동시 요청에서 행 범위를 적게 읽으면 지연 시간이 최적화되지만 처리량은 최적화되지 않습니다. 지연 시간과 처리량 간의 적절한 균형은 애플리케이션 요구사항에 따라 다르며, 한 요청에서 동시 읽기 요청 수와 행 범위 수를 조정하여 얻을 수 있습니다.

큰 행

Bigtable은 행 크기를 256MB로 제한하지만 실수로 이 최대 크기를 초과할 수 있습니다. 한도보다 커진 행을 읽어야 하는 경우 요청을 페이지로 나누고 cells per row limit 필터와 cells per row offset 필터를 사용할 수 있습니다. 페이지로 나눈 읽기 요청 사이에 행에 대한 쓰기가 도착하면 읽기가 원자적으로 수행되지 않을 수 있습니다.