웹 응용 프로그램에서는 키 - 값 쌍으로 저장할 수있는 작은 데이터 블롭 (< 10KB)의 읽기/쓰기가 매우 짧습니다. DynamoDB (DAX 사용)와 EFS 및 ElastiCache를 고려하고 있습니다. AWS는 모두 대기 시간이 짧다고 주장하지만 헤드 - 헤드 비교를 찾을 수 없으며이 세 가지가 같은 리그에 있는지도 분명하지 않습니다. 누군가 통찰력을 공유 할 수 있습니까?AWS 초 저 지연 읽기/쓰기 데이터 저장소 : EFS 대 Dynamodb DAX 대 ElastiCache
다른 유스 케이스의 다른 스토리지 시스템을 다른 가격 모델과 비교하려고합니다.
EFS는 저장 장치를 준비 할 필요가없고 여러 EC2 인스턴스에서 액세스 할 수있는 파일 시스템입니다. EFS는 사용 사례에 따라 잘 작동하지만 파일을 관리해야합니다. 즉, 파일에 맞게 데이터를 구조화해야합니다. 또는 필요한 구조 및 검색 수준에 따라 키 - 값 또는 BLOB/객체 저장 시스템을 구축해야 할 수 있습니다. S3, DynamoDB, Elasticache Redis 또는 Memcached와 같이이 문제를 해결하는 제품이 있습니다.
S3는 구조가없고 데이터 유형이 없으며 항목을 바꿀 수만 있습니다. 버킷을 blob로 나열하여 쿼리 할 수 있습니다. 일반적으로 정적 미디어 파일을 저장하는 데 사용됩니다.
DynamoDB는 데이터가 구조화되고 강하게 입력되며 쿼리 기능이있는 문서 또는 키 - 값 저장소로 사용할 수있는 비 관계형 (일명 No-SQL) 데이터베이스입니다. 최대 400KB의 항목을 저장할 수 있습니다.
Elasticache (Redis 또는 Memcached)는 일반적으로 DynamoDB와 같은 영구 데이터 저장소 앞에있는 캐시로 사용되는 키 - 값 저장소입니다. 이 경우 응용 프로그램은 다른 계층을 인식해야합니다. 다른 API를 관리하고 응용 프로그램에서 캐싱 논리를 처리합니다.
DAX를 사용하면 응용 프로그램에 캐싱 논리가 없어도 원활하게 캐시 계층을 통합 할 수 있습니다. DAX는 현재 DynamoDB에 연속 기입 캐시를 제공합니다. DAX API는 DynamoDB API와 호환되므로 DynamoDB 클라이언트를 DAX 클라이언트로 대체하여 응용 프로그램에서 이미 DynamoDB를 사용하는 경우 캐시 계층을 추가 할 수 있습니다. DAX는 현재 Java 및 Node.js 클라이언트 만 지원합니다.
그래서 작업 부하에 따라 다릅니다. 캐시 레이어 관리의 어려움없이 응용 프로그램이 Java 또는 Node.js 인 경우 밀리 초 미만의 대기 시간이 필요한 경우 DAX를 사용할 수 있습니다.
너무 많은 EFS 성능 문제가이 유형의 문제에 대해 권장하는 것으로 들었습니다. DAX 및 ElastiCache (Redis)가있는 DynamoDB는 성능 측면에서 매우 유사합니다. 각각의 기능 (및 제한 사항)을 검토하고 어떤 것이 가장 적합한 지에 따라 선택해야합니다. –