ElastiCache / SimpleQueue를 사용하는 것과 DynamoDB 내부에 각각 “Cache”및 “Queue”테이블을 갖는 이유에 대해 궁금합니다.
캐시 / 큐 서비스에 대한 네트워크 대기 시간은 많은 성능 향상을 능가 할 것으로 보이며 EC2가 Dynamo를 캐시 / 큐 서비스로 처리하면 동일한 대기 시간과 처리량을 제공 할 것입니다 (Dynamo는 하중).
주로 다이나모 대 다른 서비스의 가격에 관한 것입니까?
누구든지 Dynamo와 ElastiCache / SQS를 비교 한 지연 시간이 있습니까?
추가 누락을 정당화하는 다른 중요한 고려 사항이 있습니까?
감사.
답변
우리는 다른 이유로 DynamoDB와 ElastiCache Redis를 사용하고 있습니다.
DynamoDB :
- 보다 복잡한 작업을 수행 할 수있는 쿼리 언어가 있습니다.
- 외부 인터넷 연결 API를 통해 연결 가능 (다른 지역은 변경이나 자체 인프라 없이도 연결 가능)
- 테이블 또는 행을 기반으로 한 권한이 가능합니다
- 데이터 크기 측면에서 무한대로 확장
- 요청 당 지불-> 낮은 요청 번호는 더 작은 청구서를 의미하고 높은 요청 번호는 더 높은 청구를 의미합니다
- 읽기와 쓰기 비용이 다릅니다
- 데이터는 여러 시설에서 AWS에 의해 중복 저장됩니다
- DynamoDB는 즉시 사용 가능한 고 가용성
- 서비스 자체에서 자동 확장 가능
ElastiCache Redis :
- 간단한 쿼리 언어-복잡한 기능 없음
- 다른 지역에서는 (즉시 사용 가능) 연결할 수 없습니다.
- 항상 메모리 양 (또는 클러스터에있는 모든 기본 인스턴스의 합계)으로 제한됩니다
- 여러 인스턴스를 상쇄하는 것은 애플리케이션 내에서만 가능합니다-Redis는 여기서 아무것도하지 않습니다 (Redis 클러스터는 여기서 도움이되지만 샤딩 로직은 여전히 애플리케이션에서 사용하는 드라이버 / SDK 안에 있습니다)-스케일 인 및 스케일- 현재 다운 타임 없이는 아웃이 불가능합니다
- 로드 또는 요청 수에 관계없이 인스턴스 당 지불합니다.
- 데이터 중복성을 원할 경우 복제를 설정해야합니다 (다른 지역에서는 불가능)
- 고 가용성을 위해 복제본을 사용해야합니다
- 자동 스케일링이 없습니다 (위의 스케일링이없는 부분 참조).
따라서 대부분의 경우 설정은 다음과 같습니다. Redis에서 대량의 요청이있는 단순 캐시는 DynamoDB에 의해 영구적이고 오래 지속되는 스토리지로 지원됩니다. 이를 통해 Redis의 PPU (Pay-per-Instance) 모델을 통해 읽기에 대한 암시 적 할인을받을뿐만 아니라 DynamoDB의 중복성을 활용할 수 있으며 DynamoDB 쿼리 언어를 사용하여 더 복잡한 작업을 수행 할 때 비용을 제한합니다 ( 필요한 경우).
희망이 도움이됩니다!
업데이트 : Amazon DynamoDB Accelerator ( https://aws.amazon.com/de/dynamodb/dax/ ) 발표와 함께 DAX를 그대로 사용하도록 전환했습니다 (결국). DynamoDB와 Redis의 조합. DAX는 AWS에서 완전히 관리하지 않으며 애플리케이션에서 항상 DynamoDB 언어를 사용할 수있는 기회를 제공하지만 Redis와 같은 Write-through 캐시의 이점도 얻을 수 있습니다.
답변
DynamoDB 대신 Elasticache를 사용하는 주된 이유는 속도입니다. 작은 객체에 대해 1ms 미만의 왕복 대기 시간을 얻습니다. 이 박스는 실제로 EC2 시스템에 가깝고 메모리는 디스크, 심지어 SSD보다 훨씬 빠릅니다.
다른 가격 책정 모델을 감안할 때 비용 이점이있을 수도 있지만, 그에 대해서는 자세히 설명하지 않았습니다.
답변
Redis / memcached는 메모리 내 저장소이며 일반적으로 캐시 / 큐 유형 데이터의 경우 DynamoDB보다 빠릅니다. 또한 Dynamo에는없는 만료 키, Redis의 Pub / Sub 등과 같은 편리한 추가 항목이 있습니다.