나는 인덱스에 넣으려는 단조롭게 증가하는 필드를 가진 테이블을 가지고 있습니다. 그러나 모범 사례 인 guide은 단조롭게 증가하는 데이터를 인터리브되지 않은 인덱스에 넣지 말라고 말합니다. 인터리브 된 인덱스에 데이터를 넣으려고하면 부모 테이블에 인덱스를 인터리브 할 수 없습니다.테이블에서 단조롭게 증가하는 데이터를 인덱싱하는 방법은 무엇입니까?
즉, Cloud Spanner를이 MySQL 스키마와 동등하게 원합니다.
CREATE TABLE `my_table` (
'id' bigint(20) unsigned NOT NULL,
'monotonically_increasing' int(10) unsigned DEFAULT '0',
PRIMARY KEY ('id'),
KEY 'index_name' ('monotonically_increasing')
)
단조롭게 증가/감소하는 값을 쓰는 속도에 따라 달라집니다. 당신이 < 500 행을 작성하는 경우
난 당신이 핫스팟 것이다 (그리고 데이터에 따라 다름) 전에 처리 할 수있는 두 번째 스패너 서버 당 쓰기의 정확한 범위를 모르겠지만 초당 당신은이 패턴으로 괜찮을 것입니다. 쓰기 부하가 단일 Spanner 서버가 자체적으로 편안하게 처리 할 수있는 것보다 높으면 문제가됩니다.
당신의 쓰기 속도 (예를 들어 당신의 시스템/사이트 인기와 확장) 큰, 또는 상대적으로 억제 할 경우
, 당신은 대안을보고해야합니다. 이러한 대안은 사용자가 취하려고하는 트레이드 오프를 해결하기 위해 정확한 사용 사례에 달려 있습니다.일반적인 접근 방법 중 하나는 수동으로 인덱스를 분할하는 것입니다. 예를 들어 최대 쓰기로드가 초 당 1740 인서 트가 될 것이라고 가정 해 봅시다. 이전부터 서버 당 약 500 건의 쓰기를 사용하여 4 대의 Spanner 서버 (각 초당 435 건씩)에 대해이 부하를 분산 할 수 있다면 핫스팟을 피할 수 있습니다.
Cloud Spanner에서 INT64 유형을 사용하면 최대 값 9,223,372,036854775808을 허용합니다. 샤드에 대한 한 가지 방법은 각 값에 random(0,3)*1,000,000,000,000,000,000을 추가하는 것입니다. 그러면 인덱스 키 범위가 4 개의 Spanner 서버에서 제공 할 수있는 4 개의 범위로 분할됩니다. 아래 측면에서는 x,000,000,000,000,000,000을 마스킹 한 후 클라이언트 측에서 4 개의 쿼리를 수행하고 결과를 병합해야합니다.
참고 : 인터리브는 한 테이블의 데이터/인덱스가 다른 테이블의 날짜로 인터리브 된 경우입니다. 하나의 표만 인터리빙 할 수 없습니다.