< Replication, Query Types, Transactions, and Handling Errors >
Things to remember when designing your application’s operations
애플리케이션 작업을 설계할 때 기억해야 할 사항
- 애플리케이션에 대한 작업을 설계할 때 기억해야 할 몇 가지 사항 :
- 단일 작업을 사용하는 대신 읽기, 쓰기 및 삭제에 일괄 작업을 사용
- 일괄 작업을 사용하면 단일 작업과 동일한 오버헤드로 여러 개체에 대해 여러 작업을 수행할 수 있음
- 트랜잭션이 실패하면 트랜잭션을 롤백
- 롤백을 설정하면 트랜잭션에서 동일한 리소스의 동시 요청에 대한 재시도 대기 시간이 최소화
- 롤백 중에 예외가 발생하면 롤백 작업을 다시 시도할 필요가 없음
- 가능한 경우 비동기식 호출을 사용하여 대기 시간 영향을 최소화
- 예를 들어, 응답을 렌더링하기 전에 두 개 이상의 개별 조회 또는 쿼리가 필요한 애플리케이션이 있는 경우
요청을 비동기적으로 수행하여 병렬로 수행할 수 있도록 하는 것이 더 빠름
Use query types based on your needs
필요에 따라 쿼리 유형 사용
- 쿼리 결과에서 키에만 액세스해야 하는 경우 키 전용 쿼리를 사용
- 엔티티의 특정 속성에만 액세스해야 하거나 쿼리 필터에 포함된 속성에만 액세스해야 하는 경우 프로젝션 쿼리를 사용
- 키 전용 쿼리와 프로젝션 쿼리는 전체 엔티티를 검색하는 것보다 짧은 대기 시간과 비용으로 결과를 반환하며
프로젝트에 대해 청구가 활성화된 경우 무료인 소규모 작업으로 분류
청구가 활성화되지 않은 프로젝트의 소규모 작업에 대한 무료 할당량도 있음 - 데이터가 강력한 계층 구조이고 상위-하위 관계를 포함하는 경우 상위 쿼리를 사용하여 주어진 엔티티의 모든 하위를 쉽게 반환
- 상위 쿼리는 이전 버전의 Datastore에서 강력한 일관성을 가진 유일한 쿼리 유형이었지만
이제는 모든 쿼리가 Datastore 모드의 Firestore와 강력하게 일관성이 있음 - 엔티티 쿼리를 사용하여 엔티티 종류, 0개 이상의 필터 및 0개 이상의 정렬 순서를 검색할 수 있음
- 엔티티는 값이 비교 작업에 의해 지정된 필터에 지정된 값과 비교되는 지정된 이름의 속성을 가지고 있는 경우 필터를 충족
이 예에서는 완료되지 않은 것 (not done) 으로 표시된 작업 엔티티를 반환
Improve your query latency by using cursors instead of offsets
오프셋 대신 커서를 사용하여 쿼리 지연 시간 개선
- 일반적으로 쿼리에서 오프셋을 사용하는 것을 피하고 대신 커서를 사용 :
- 오프셋을 사용하면 건너뛴 엔티티가 애플리케이션에 반환되는 것을 방지할 수 있지만 엔티티는 여전히 내부적으로 검색 가능
- 건너뛴 엔티티는 쿼리의 지연 시간에 영향을 미치며,
엔티티를 검색하는 데 필요한 읽기 작업에 대한 요금이 애플리케이션에 청구
- 커서는 여전히 일괄 쿼리를 검색하지만 오프셋에서 볼 수 있는 대기 시간과 비용을 발생시키지 않음
Numeric IDs as keys
숫자 ID를 키로 사용
- 숫자 ID를 사용하는 키의 경우 ID에 음수를 사용하지 말아야 함
음수는 정렬을 방해할 수 있습니다. - ID에 값 0을 사용하면 자동으로 할당된 ID가 생성
생성한 엔티티에 고유한 숫자 ID를 수동으로 할당하려면 애플리케이션이 assignIds() 메서드를 사용하여 ID 블록을 얻음
이렇게 하면 Datastore가 수동 숫자 ID 중 하나를 다른 항목에 할당하는 것을 방지할 수 있음 - 생성한 엔티티에 고유한 수동 숫자 ID 또는 사용자 지정 이름을 할당하는 경우
1, 2, 3 또는 Product1, Product2, Product3과 같이 단조 증가하는 값을 사용하지 말아야 함
순차적인 번호 지정은 Datastore 지연 시간에 영향을 미치는 핫스팟으로 이어질 수 있음 - assignIds() 메서드는 잘 분산된 숫자 ID 시퀀스를 생성하므로 핫스팟을 방지하는 데 사용
Transaction design considerations
트랜잭션 설계 고려 사항
- 트랜잭션은 하나 이상의 항목에 대한 Datastore 작업 집합 :
- 원자성으로 보장되므로 트랜잭션의 모든 작업이 적용되거나 적용되지 않음
- 최대 트랜잭션 시간은 270초이지만 60초 동안 활동이 없으면 Datastore에서 트랜잭션을 종료
- 동일한 항목에 대해 너무 많은 동시 수정이 시도되거나 트랜잭션이 리소스 제한을 초과하거나
Datastore 데이터베이스에 내부 오류가 발생하면 트랜잭션이 실패할 수 있음
- 애플리케이션이 트랜잭션을 커밋할 때 예외를 수신하는 경우 항상 트랜잭션이 실패했다는 의미는 아니며
트랜잭션이 커밋되어 결국 성공적으로 적용되는 경우 오류를 수신할 수 있음
- 가능하면 Datastore 트랜잭션을 멱등성으로 만들어 트랜잭션을 반복해도 최종 결과가 동일
멱등 연산은 동일한 입력 매개변수로 두 번 이상 호출되는 경우 추가 효과가 없는 연산
Design your application to handle errors
오류를 처리하도록 애플리케이션 설계
- Datastore 요청이 성공하면 API는 응답 본문에 요청된 데이터와 함께 200 OK 상태 코드를 반환
- 실패는 실패를 일으킨 오류에 대한 보다 구체적인 정보와 함께 4xx 또는 5xx 상태 코드를 반환
- 표준 오류 코드의 값을 검사하여 오류를 분류
(online) 04_Best Practices for Using Cloud Datastore.pdf
1.35MB
