AWS ElastiCache / SimpleQueue 및 DynamoDB


13

ElastiCache / SimpleQueue를 사용하는 것과 DynamoDB 내부에 각각 "Cache"및 "Queue"테이블을 갖는 이유에 대해 궁금합니다.

캐시 / 큐 서비스에 대한 네트워크 대기 시간은 많은 성능 향상을 능가 할 것으로 보이며 EC2가 Dynamo를 캐시 / 큐 서비스로 처리하면 동일한 대기 시간과 처리량을 제공 할 것입니다 (Dynamo는 하중).

주로 다이나모 대 다른 서비스의 가격에 관한 것입니까?

누구든지 Dynamo와 ElastiCache / SQS를 비교 한 지연 시간이 있습니까?

추가 누락을 정당화하는 다른 중요한 고려 사항이 있습니까?

감사.

답변:


9

우리는 다른 이유로 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를 사용하여 redis를 백업하는 방법입니다. 이것이 AWS의 기능입니까? 언제, 어떻게 백업을 생성합니까? 당신이 그것을 명확히 할 수 있다면 감사합니다!
badera

나의 "지원"은 전통적인 방식의 백업을 의미하지 않습니다. 우리는 실제로 DynamoDB에 항상 쓰고 있으며 먼저 Redis를 사용하여 읽습니다. 따라서 Redis가 데이터를 잃어버린 경우에도 DynamoDB에서 사용할 수 있습니다. DAX ( aws.amazon.com/de/dynamodb/dax )를 사용하면이 사용 사례가 훨씬 쉬워졌습니다!
Osterjour

7

DynamoDB 대신 Elasticache를 사용하는 주된 이유는 속도입니다. 작은 객체에 대해 1ms 미만의 왕복 대기 시간을 얻습니다. 이 박스는 실제로 EC2 시스템에 가깝고 메모리는 디스크, 심지어 SSD보다 훨씬 빠릅니다.

다른 가격 책정 모델을 감안할 때 비용 이점이있을 수도 있지만, 그에 대해서는 자세히 설명하지 않았습니다.


여전히 관련이 있습니까? DAX는 그것을 바꾸지 않았습니까?
dmigo 2016 년

1
DAX는 많은 대기 시간 문제를 해결할 것입니다. 정확한 속도 차이는 확실하지 않습니다. 작은 개체 네트워크의 경우 대기 시간의 주요 원인이됩니다.
Maximilian

1

Redis / memcached는 메모리 내 저장소이며 일반적으로 캐시 / 큐 유형 데이터의 경우 DynamoDB보다 빠릅니다. 또한 Dynamo에는없는 만료 키, Redis의 Pub / Sub 등과 같은 편리한 추가 항목이 있습니다.


1
감사. 캐시가 메모리에 있다는 것을 알고 있지만 캐시에 도달하고 돌아올 때까지 ~ 10ms 이상의 왕복이 예상 될 수 있다는 것을 읽었으며 성능 특성은 Dynamo와 동일합니다. 다이너 모에서는 사용할 수없는 memcached의 특정 기능을 원할 수도 있습니다. 그러나 RAM 캐시의 주요 장점은 내구성있는 저장소보다 성능이 크게 향상되어 여기에 적용되지 않는 것 같습니다.
Scott Klarenbach
당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.