dynamoDB -UseCases를 사용하는 경우

Question

아마존의 dynamoDB에 가장 적합한 유스 케이스가 무엇인지 알아 내려고했습니다.

내가 대부분의 블로그를 검색했을 때 DyanmoDb는 많은 양의 데이터 (BigData)에만 사용될 것이라고합니다.

나는 관계형 DB의 배경 지식을 가지고있다. NoSQL DB는 나에게 새로운 기술입니다.이 문제를 정상적인 관계 DB 지식과 관련 짓려고 할 때.

DynamoDb와 관련된 개념의 대부분은 파티션 키/정렬 키가있는 스키마없는 테이블을 만드는 것입니다. 그리고 키를 기반으로 쿼리를 시도하십시오. 또한 쿼리를 더 쉽고 간단하게 만드는 저장 프로 시저의 개념이 없습니다.

이러한 거대한 데이터를 관리 할 때마다 복잡한 쿼리를 수행 할 때마다 데이터를 검색 할 때 저장 프로 시저가없는 올바른 방법일까요?

참고 : 개념을 잘못 이해했을 수 있습니다. 그래서, 사람이 사전에 여기 내 생각

감사를 취소하십시오
제이 한마디로

Answer 1

는, DynamoDB의 같은 시스템이 큰 데이터 세트를 지원하도록 설계되어 높은 쓰기 (단일 서버에 맞게 너무 커서)/읽기 처리량 관계형 데이터베이스에서 역사적으로 가장 보편적 인 방식 인 수직 확장과 달리 수평 적으로 확장합니다.

수평 확장 성을 지원하는 주요 접근법은 데이터를 분할하는 것입니다. 즉, 데이터 세트는 여러 조각으로 분할되고 여러 서버로 분산됩니다. 이렇게하면 더 많은 스토리지와 IOPS를 사용할 수있어 더 큰 데이터 세트와 더 높은 읽기/쓰기 처리량을 허용합니다.

그러나 데이터 분할로 인해 여러 물리적 서버간에 데이터가 분산되므로 조인 등의 복잡한 쿼리를 지원하기가 어렵습니다. 스토어드 프로시 저는 동일한 이유로 지원되지 않습니다. 역사적으로 스토어드 프로 시저 뒤에있는 아이디어는 데이터 지역성입니다. 즉, 네트워크 작동없이 데이터 근처의 서버에서 실행됩니다. 그러나 데이터가 여러 서버로 분산되는 경우이 이점은 사라집니다. (최소한 저장 프로 시저의 형태로).

따라서 이러한 시스템에서 데이터를 쿼리하는 가장 효율적인 방법은 레코드 키를 사용하는 것입니다. 데이터 파티션은 키를 기반으로하며 주어진 키에 대해 레코드가 물리적으로 어디에 존재하는지 파악하기 쉽습니다. 이러한 많은 시스템은 2 차 인덱스도 지원하지만 일반적으로 어떤 방식으로나 비싸지 만 복잡한 소프트웨어 솔루션의 요구 사항을 충족 시키기에는 충분하지 않을 수 있습니다. 아주 일반적인 접근법은 레코드의 일부분에 대해 복잡한 쿼리를 실행하여 레코드 키를 계산 한 다음 레코드를로드하는 데 사용할 수있는 보완적인 인덱싱/쿼리 솔루션 (Elasticsearch 및 Solr을 기반으로하는 솔루션을 보았습니다)을 사용하는 것입니다. .