< Design Considerations & Sharding >
Design your app with these considerations in mind
이러한 고려 사항을 염두에 두고 앱을 디자인
- 이러한 고려 사항을 염두에 두고 Cloud Datastore를 사용하여 애플리케이션을 설계 :
- 네임스페이스 이름, 종류 이름, 속성 이름 및 사용자 지정 키 이름에는 항상 UTF-8 문자를 사용
이러한 이름을 사용하는 비 UTF-8 문자는 Cloud Datastore 기능을 방해할 수 있음
- 종류 이름이나 사용자 지정 키 이름에 슬래시(/) 사용 금지
이러한 이름의 슬래시는 향후 기능을 방해할 수 있음
Use sharding to increase rate of writes
샤딩을 사용하여 쓰기 속도 증가
- 샤딩은 엔티티를 더 작은 조각으로 나눔 :
- Datastore는 항목을 자동으로 분할하여 데이터를 배포함
- Datastore의 단일 항목을 너무 빨리 업데이트하면 안 됨
- 단일 엔티티에 대한 최대 지속 쓰기 속도인 초당 한 번 이상 엔티티를 업데이트할 필요가 없도록 애플리케이션을 설계해야 함
- 짧은 버스트에서는 제한을 초과할 수 있지만 단일 엔티티에 대해 초당 1회 이상 쓰기를 지속하면
대기 시간이 증가하고 경합 오류가 발생할 수 있음
- 엔티티에 대해 높은 비율의 지속적 쓰기를 수행해야 하는 경우
엔티티를 동일한 키를 사용하여 다른 종류의 엔티티로 수동으로 분할하도록 선택할 수 있음
Shard counters to avoid contention with high writes
높은 쓰기와 경합을 피하기 위한 샤드 카운터
- 카운터는 초당 두 번 이상 지속적으로 업데이트해야 할 수 있는 속성의 예 :
- 1초에 권장되는 것보다 빠르게 엔티티를 업데이트하려면 카운터를 샤딩하여 경합을 줄일 수 있음
- 카운터를 n개의 다른 카운터로 나눌 수 있음
- 카운터를 증가시키려면 샤드 중 하나를 무작위로 선택하여 증가시킴
- 총 개수를 알기 위해 모든 카운터 샤드를 읽고 개별 개수를 합산
- 샤드 수를 늘리면 카운터 증가에 대한 처리량이 증가
Use replication to read a portion of the key range
복제를 사용하여 키 범위의 일부 읽기
- 응용 프로그램이 읽기 성능에 의해 제한되는 경우 복제가 응용 프로그램에 더 나은 옵션일 수 있음 :
- Datastore에서 허용하는 것보다 빠른 속도로 키 범위의 일부를 읽어야 하는 경우 복제를 사용할 수 있음
- 이 전략을 사용하면 동일한 엔티티의 N개 복사본을 저장하여 단일 엔티티에서 지원하는 것보다 N배 더 높은 읽기 속도를 허용
- 한 가지 표준 사용 사례는 정적 구성 파일으로 이 경우 애플리케이션에 고정된 수의 구성 개체가 있을 수 있음
- config 1에서 config n까지라고 하는 n개의 구성 복사본을 생성하며 로드할 때
애플리케이션은 1에서 n 사이의 임의의 숫자 r을 선택하고 해당 엔티티를 검색