읽기
이 페이지에서는 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를 제공합니다.
연속 구체화된 뷰에서 데이터 읽기
SQL 또는 ReadRows
Data API 호출을 사용하여 연속 구체화된 뷰에서 데이터를 읽을 수 있습니다. 연속 구체화된 뷰는 읽기 전용입니다. 구체화된 뷰의 데이터는 이를 정의하는 쿼리를 기반으로 입력됩니다.
SQL
SQL을 사용하여 연속 구체화된 뷰에서 데이터를 읽으려면 Bigtable Studio 쿼리 편집기 또는 SQL 쿼리를 지원하는 클라이언트 라이브러리 중 하나를 사용하면 됩니다.
SQL은 쿼리 결과를 유형이 지정된 열로 자동 노출하므로 쿼리에서 인코딩을 처리할 필요가 없습니다.
연속 구체화된 뷰를 만들면 Bigtable에서 뷰의 구조화된 행 키를 정의하는 테이블의 행 키 스키마를 자동으로 만듭니다. SQL로 구조화된 행 키를 쿼리하는 방법에 대한 자세한 내용은 구조화된 행 키 쿼리를 참고하세요.
Data API
Bigtable용 클라이언트 라이브러리 중 하나에서 ReadRows
호출을 사용하여 연속 구체화된 뷰에서 읽으려면 뷰를 정의하는 데 사용된 SQL 쿼리를 검토해야 합니다. ReadRows
을 사용하여 읽을 뷰에 권장되는 정의된 _key
열이 뷰에 있는지, _timestamp
열이 있는지 확인합니다.
또한 각 열의 유형을 알고 애플리케이션 코드에서 열 데이터를 디코딩해야 합니다.
연속 구체화된 뷰의 집계된 값은 뷰 정의의 열 출력 유형에 따라 다음 표에 설명된 인코딩을 사용하여 저장됩니다.
유형 | 인코딩 |
---|---|
BOOL | 1바이트 값, 1 = true, 0 = false |
BYTES | 인코딩 없음 |
INT64 (또는 INT, SMALLINT, INTEGER, BIGINT, TINYINT, BYTEINT) | 64비트 big-endian |
FLOAT64 | 64비트 IEEE 754(NaN 및 +/-inf 제외) |
문자열 | UTF-8 |
시간/타임스탬프 | Unix epoch 이후의 마이크로초 수를 나타내는 64비트 정수 (GoogleSQL과 일관됨) |
뷰의 각 열 유형을 아는 것 외에도 column family와 column qualifier를 알아야 합니다. 기본 column family는 default
이고 column qualifier는 정의 쿼리에 지정된 별칭입니다. 예를 들어 다음 쿼리로 정의된 연속 구체화된 뷰를 살펴보세요.
SELECT
_key,
SUM(clicks) AS sum_clicks
FROM
mytable
GROUP BY
sum_clicks
ReadRows
로 뷰를 쿼리할 때 column family default
및 column qualifier sum_clicks
를 제공합니다.
읽기 및 성능
필터를 사용하는 읽기는 필터가 없는 읽기보다 느리며, CPU 사용률을 높입니다. 반면 반환되는 데이터의 양을 제한하여 사용하는 네트워크 대역폭의 양을 크게 줄일 수 있습니다. 일반적으로 필터는 지연 시간이 아니라 처리량 효율을 제어하기 위해 사용해야 합니다.
읽기 성능을 최적화하려면 다음 전략을 고려하세요.
행 집합을 최대한 제한합니다. 노드가 스캔해야 하는 행 수를 제한하는 것은 첫 번째 바이트 시간과 전체 쿼리 지연 시간을 개선하는 첫 단계입니다. 행 집합을 제한하지 않으면 Bigtable은 십중팔구 전체 테이블을 스캔해야 합니다. 따라서 가장 일반적인 쿼리가 이러한 방식으로 작동하도록 스키마를 설계하는 것이 좋습니다.
행 집합을 제한한 후에 추가 성능 조정을 수행하려면 기본 필터를 추가해 보세요. 열 집합 또는 반환되는 버전 수를 제한해도 일반적으로 지연 시간은 늘어나지 않으며, Bigtable이 각 행에서 관련 없는 과거 데이터를 더 효율적으로 찾는 데 도움이 될 수도 있습니다.
처음 두 가지 전략 이후에 읽기 성능을 더 세부적으로 조정하려면 복잡한 필터를 사용하는 것이 좋습니다. 이를 시도해 볼 만한 몇 가지 이유는 다음과 같습니다.
- 원하지 않는 데이터가 여전히 많이 반환되고 있습니다.
- 쿼리를 Bigtable로 푸시하여 애플리케이션 코드를 단순화하려고 합니다.
다만 큰 값에서 조건, 인터리브 또는 정규 표현식 일치를 요구하는 필터는 스캔된 데이터 대부분을 통과시키는 경우 피해를 입힐 수 있습니다. 이 피해는 클라이언트 측의 대규모 절감 없는 클러스터의 CPU 사용률 증가라는 형태로 나타납니다.
이러한 전략 외에도 단일 읽기 요청에서 연속되지 않은 다수의 row key 또는 행 범위를 읽지 않도록 합니다. 단일 요청에서 row key 또는 행 범위 수백 개를 요청하면 Bigtable은 테이블을 스캔하고 요청된 행을 순차적으로 읽습니다. 이러한 동시 로드 부족은 전체 지연 시간에 영향을 미치며 핫 노드에 발생하는 읽기는 꼬리 지연 시간을 늘릴 수 있습니다. 요청한 행 범위가 많을수록 읽기를 완료하는 데 시간이 오래 걸립니다. 이 지연 시간을 허용할 수 없으면 대신 각각 행 범위를 적게 가져오는 동시 요청 여러 개를 전송해야 합니다.
일반적으로 단일 요청에서 더 많은 행 범위를 읽으면 처리량이 최적화되지만 지연 시간은 최적화되지 않습니다. 여러 동시 요청에서 행 범위를 적게 읽으면 지연 시간이 최적화되지만 처리량은 최적화되지 않습니다. 지연 시간과 처리량 간의 적절한 균형은 애플리케이션 요구사항에 따라 다르며, 한 요청에서 동시 읽기 요청 수와 행 범위 수를 조정하여 얻을 수 있습니다.
큰 행
Bigtable은 대규모 행에 적용되는 다음 제한을 적용합니다.
행의 최대 크기는 256MB입니다. 한도보다 커진 행을 읽어야 하는 경우 요청을 페이지로 나누고
cells per row limit
필터와cells per row offset
필터를 사용할 수 있습니다. 페이지로 나눈 읽기 요청 사이에 행에 대한 쓰기가 도착하면 읽기가 원자적으로 수행되지 않을 수 있습니다.ReadRows
API 호출의 최대 크기는 512KB입니다. 한도를 초과하면 Bigtable에서INVALID_ARGUMENT
오류를 반환합니다.
다음 단계
- 집계 셀을 사용하여 카운터 구현하기
- 필터 개요 읽어보기
- 필터 사용 방법을 보여주는 코드 샘플 살펴보기
- Bigtable에 보낼 수 있는 쓰기 요청 유형에 대해 읽어보기
- Bigtable 에뮬레이터 사용하기