0
우리의 요구 사항은 매우 간단합니다. 우리는 며칠 이상이면 안되는 센서 용 GPS 위치를 저장하려고합니다. 데이터의 전체 세분성은 최대 약 1 분 정도입니다.SimpleDB 또는 DynamoDB를위한 생존 시간
총 센서 수는 10 억 개를 초과 할 수 있으므로 직접 파티션 논리를 작성하지 않으면 SimpleDB를 사용할 수 없습니다. SimpleDB는 각 속성을 색인화하지만 2 일 이상 된 항목을 삭제하는주기적인 정리 스크립트를 한 번만 실행할 수 있습니다.
DynamoDB는 데이터 양에 제한이 없으므로 훨씬 뛰어납니다. sensorID + timestamp에 파티션 + 범위 기본 키를 사용할 수 있습니다. 그러나 오래된 데이터를 삭제하려면 타임 스탬프 필드에 글로벌 보조 인덱스가없는 한 스캔 쿼리가 필요합니다. 이 보조 글로벌 인덱스를 사용하면 검색어가 잠재적으로 더 빠를 수 있습니다.
더 나은 방법이있을 수 있다고 생각하는 사람은 저뿐입니까? 전체 배포가 AWS 환경에 있기 때문에 DynamoDB/SimpleDB를 사용하는 것이 더 좋으며 많은 작업에 투자하지 않으려합니다. Mongo DB와 같은 다른 NOSQL DB가이를 지원한다는 것을 알고 있습니다.
GPS 위치가 ** 동일한 형식 ** 인 NOSQL DB에 더 잘 저장되는 것을 실제로 볼 수 없습니다. 이는 실제로 테이블에서 저장, 인덱싱, 검색 및 분석 할 수있는 데이터의 정의입니다. –
수십억 개의 항목이 있기 때문에. 시스템을 자동으로 공유/파티션하고 싶지 않으므로 걱정하지 않으셔도됩니다. 유연한 스키마가없는 NOSQL을 사용하는 사람은 실수를 저지르고있는 것처럼 들리지만 그렇지 않습니다. – Ouroboros
"수십억의 동일하게 구성된 항목"**은 스키마가없는 NOSQL이 아닌 관계형 데이터베이스를 사용해야하는 이유입니다. 수십억 개의 동일한 데이터 포인트가 있지만 키 - 값 쌍으로 저장하는 경우 (예 : 데이터베이스가하는 일을 이해하지 못하고 키 - 값 저장소를 분할하는 것이 왜 정렬 가능/인덱싱 가능 테이블을 파티셔닝합니다. –