데이터베이스 대 데이터베이스로 S3 사용(예: MongoDB)

데이터베이스 대 데이터베이스로 S3 사용(예: MongoDB)

셋업이 간단하고 비용도 저렴하기 때문에 NoSQL 데이터베이스 대신 AWS S3 버킷을 사용하여 간단한 사용자 설정을 JSON(약 30개의 문서)으로 저장하는 것을 검토하고 있습니다.

사용 사례와 관련이 없는 데이터베이스를 사용하지 않을 경우의 다음과 같은 단점을 조사했습니다.

• 버킷/파일 목록에는 비용이 많이 듭니다.
• 업데이트 없음 - 파일을 업데이트할 수 없습니다. 교체만 하면 됩니다.
• 인덱스가 없습니다.
• 버전 관리 비용은 $$입니다.
• 검색 없음
• 트랜잭션 없음
• 쿼리 API 없음(SQL 또는 NoSQL)

데이터베이스 대신 S3 버킷을 사용하는 것에 대해 다른 단점이 있습니까?

"NoSQL 데이터베이스 대신 AWS S3 버킷 사용을 고려 중"이지만, 사실은 Amazon S3가 사실상 NoSQL 데이터베이스입니다.

매우 큰 Key-Value 스토어입니다.키는 파일 이름이고 값은 파일의 내용입니다.

"이 키로 값 저장" 및 "이 키로 값 가져오기"만 요구하면 문제가 없습니다.

실제로 Amazon.com의 오래된 주문(1년 이상 경과)은 읽기 전용(반품, 변경 없음)이기 때문에 Amazon S3에 보관되어 있는 것 같습니다.

Amazon S3는 DynamoDB보다 느리지만 스토리지 비용은 상당히 저렴합니다!

컨텍스트: 일부 "데이터베이스"(키/값 구조화 스토리지)에 S3를 사용합니다.

S3에는 실제로 검색이 있으며 데이터 구조화 방법에 따라 S3 Select(S3 선택) 형식의 쿼리가 있습니다(시간이 있는 경우:Athena).

편집: 2020년 12월 이전에는 S3가 일관성을 유지했습니다.이제 그것은 강하게 일치한다.다음과 같은 단점은 더 이상 적용되지 않지만, 역사적 이유로 여기에 있습니다.

---

2020년 12월 이전에는 S3가 일관성을 유지한다는 것이 가장 큰 단점/아키텍처상의 과제였습니다(이 때문에 실제로 파일을 "업데이트"할 수 없었습니다).이는 아키텍처에서 허용해야 하는 몇 가지 동작에서 드러났습니다.

• 조작은 키로 캐시되었기 때문에 존재하지 않는 오브젝트를 취득하여 작성하려고 하면 해당 오브젝트에 일정시간* 동안 접속하면 존재하지 않는 오브젝트가 반환됩니다.
• 글로벌 캐시가 없기 때문에 덮어쓰기 후 일정 기간* 동안 같은 개체의 두 가지 다른 버전을 가져올 수 있습니다.
• 목록 작업은 반불안정 반복기를 제공했습니다.업데이트 중인 버킷에 많은 개체를 나열할 경우 반복기 종료까지 모든 개체를 참조하지 못할 수 있습니다.

※ AWS에서는 의도적으로 기간을 정의하지 않지만, 관찰 결과 1분을 넘는 경우는 거의 없습니다.

언급URL : https://stackoverflow.com/questions/56108144/using-s3-as-a-database-vs-database-e-g-mongodb