AWS MySQL RDS 대 AWS DynamoDB [닫힌]

109

나는 지금 당분간 MySQL을 사용해 왔으며 구조 및 SQL 쿼리 등에 익숙합니다.

현재 AWS에서 새로운 시스템을 구축하고 있으며 DynamoDB를 살펴보고 있습니다. 현재 나는 그것에 대해 조금만 알고 있습니다.

하나가 다른 것보다 낫습니까?

DynamoDB의 장점은 무엇입니까?

MySQL 쿼리 등에서 플랫 스타일 DB 로의 전환은 어떻습니까?

— 아담
소스

66

여기에서 AWS 설명을 읽을 수 있습니다 .

간단히 말해 조인 쿼리가 아닌 조회 쿼리 가 주로있는 경우 DynamoDB (및 기타 NoSQL DB)가 더 좋습니다. 많은 데이터 를 처리해야하는 경우 MySQL (및 기타 RDBMS)을 사용할 때 제한됩니다.

MySQL 쿼리 나 데이터 스키마를 재사용 할 수는 없지만 NoSQL을 배우기 위해 노력한다면 도구 상자에 중요한 도구를 추가하게됩니다. DynamoDB가 가장 간단한 솔루션을 제공하는 경우가 많습니다.

— 사람
소스

262

실제로 DynamoDB와 MySQL은 사과와 오렌지입니다. DynamoDB는 NoSQL 스토리지 계층이고 MySQL은 관계형 스토리지에 사용됩니다. 응용 프로그램의 실제 요구 사항에 따라 사용할 항목을 선택해야합니다. 실제로 일부 응용 프로그램은 둘 다 사용하여 잘 제공 될 수 있습니다.

예를 들어, 단일 키 또는 키 / 범위 조합에 대해 조회 할 수있는 관계형 스키마 (트리 구조, 스키마없는 JSON 표현 등)에 적합하지 않은 데이터를 저장하는 경우 DynamoDB ( 또는 다른 NoSQL 저장소)가 최선의 방법 일 것입니다.

관계형 구조에 잘 맞을 수있는 데이터에 대해 잘 정의 된 스키마가 있고 다양한 방법으로 데이터를 쿼리 할 수있는 유연성이 필요한 경우 (물론 필요에 따라 인덱스 추가) RDS가 더 나은 솔루션이 될 수 있습니다. .

DynamoDB를 NoSQL 스토어로 사용할 때의 주요 이점은 클러스터 된 데이터 스토어 관리에 대해 걱정할 필요없이 필요한 수준에서 읽기 / 쓰기 처리량이 보장된다는 것입니다. 따라서 애플리케이션에 초당 1000 개의 읽기 / 쓰기가 필요한 경우 해당 수준의 처리량에 대해 DynamoDB 테이블을 프로비저닝 할 수 있으며 기본 인프라에 대해 걱정할 필요가 없습니다.

RDS는 인프라 자체에 대해 걱정할 필요가 없다는 것과 동일한 이점이 있지만 가장 큰 인스턴스 크기가 더 이상 유지되지 않는 지점까지 상당한 수의 쓰기 작업을 수행해야하는 경우에는 옵션 (읽기 전용 복제본을 사용하여 읽기를 위해 수평으로 확장 할 수 있음).

업데이트 된 참고 사항 : DynamoDb는 이제 글로벌 보조 인덱싱을 지원하므로 이제 해시 또는 해시 및 범위 키 조합 이외의 데이터 필드에서 최적화 된 조회를 수행 할 수 있습니다.

— 마이크 브랜트
소스

10

내가 당신의 대답을 100으로 찬성 할 수 있다면 그렇게 할 것입니다.

— Salil

정보 모델의 어떤 종류의 문제는 NoSQL 종류의 구현에 적합합니다. 이러한 문제를 발견하면 NoSQL Db를 사용하는 것이 합당한 지 스스로에게 질문하십시오. 이러한 엔터티 중 일부는 다음과 같습니다. 로그, 시계열 데이터, 소셜 네트워크, 콘텐츠 관리, 제품 카탈로그 등

— user398039

150

방금 모든 DynamoDB 테이블을 RDS MySQL로 마이그레이션했습니다.

특정 작업에 DynamoDB를 사용하는 것이 합리적 일 수 있지만 DynamoDB 위에 새로운 시스템을 구축하는 것은 정말 나쁜 생각입니다. 최적의 계획 등, 항상 DB에서 추가 유연성이 필요합니다.

DynamoDB에서 이전 한 이유는 다음과 같습니다.

인덱싱-새 테이블을 생성하지 않고 즉시 키를 변경하거나 추가하는 것은 불가능합니다.
쿼리-데이터 쿼리는 매우 제한적입니다. 특히 색인화되지 않은 데이터를 쿼리하려는 경우. 물론 조인은 불가능하므로 코드 / 캐시 레이어에서 복잡한 데이터 관계를 관리해야합니다.
백업-이러한 지루한 백업 절차는 RDS의 매끄러운 백업에 비해 실망스러운 놀라움입니다.
GUI-나쁜 UX, 제한된 검색, 재미 없음.
속도-RDS에 비해 응답 시간이 문제가됩니다. RDS의 내부 캐싱을 위해 정착했을 위치에서이를 보상하기 위해 정교한 캐싱 메커니즘을 구축하고 있습니다.
데이터 무결성-유동적 인 데이터 구조의 개념은 처음에는 좋게 들리지만 일부 데이터는 "석에 설치"하는 것이 좋습니다. 강력한 타이핑은 작은 버그가 데이터베이스를 파괴하려고 할 때 축복입니다. DynamoDB를 사용하면 모든 것이 가능하며 실제로 잘못 될 수있는 모든 것이 가능합니다.

이제 일부 시스템의 백업으로 DynamoDB를 사용하고 있으며, 앞으로 잘 정의 된 특정 작업에 DynamoDB를 사용할 것이라고 확신합니다. 나쁜 DB가 아니라 핵심 시스템의 100 %를 제공하는 DB가 아닙니다.

장점에 관한 한, 확장 성과 내구성이라고 말하고 싶습니다. 엄청나게 투명하게 확장되며 항상 (일종의) 증가합니다. 이것들은 정말 훌륭한 기능이지만 단점을 보완하지 않습니다.

— 야미 글릭
소스

11

매우 구체적인 장단점. 멋진 대답

— stevendesu

10

이 중 일부는 오래되었습니다. 예를 들어, 1은 더 이상 참이 아닙니다.

— mbroshi

2

매우 잘 문서화 된 답변입니다. 그러나 이러한 우려 중 일부는 드문 사용 사례에 국한 될 수 있습니다. 2 번- "조인은 물론 불가능합니다"-DynamoDB 데이터 구조에는 관계가 없어야합니다-기간. 테이블은 완전히 비정규 화되어야합니다. 즉, 일부 속성이 중복됩니다. 이러한 경우 다이나모 트리거 또는 조건부 쓰기를 사용하십시오. 사용자가 조건부 쓰기 지연 시간을 처리 할 수없는 경우 애플리케이션과 발전기 사이에 SQS 대기열을 배치합니다. 또한, 포인트 번호 6은 DynamoDB의 "무결성"에 의문을 제기 할 정도로 이름이 잘못 지정되었습니다. 이는 의도가 아닐 수도 있습니다 ...

— doles

1

Dynamo는 쿼리하는 동안 여전히 유연성이 부족합니다. GSI는 큰 도움이되지만 여전히 RDBMS 스키마를 사용하여 데이터를 더 잘 모델링 할 수 있습니다.

— Pavan

1

DynamoDB 내의 쿼리 기능에 몇 가지 "문제"가 있다고 덧붙였습니다. 예를 들어 기본 키가 해시로만 구성된 경우 Dynamo 쿼리는 1 개의 항목 만 반환 할 수 있으며, 쿼리 시간에 해시 전용 키에 범위를 제공 할 수 없으며, 특정 해시를 몰라도 쿼리 할 수 없습니다. 당신이 찾고있는 항목. BatchGet은 요청에서 100 개의 가져 오기, 1MB 총 응답 크기 또는 1MB 총 쿼리 크기 중 먼저 오는 것을 허용합니다. 스캔은 유연한 검색을 제공하지만 매우 비효율적이고 비용이 많이 들고 필터링 전에 전체 테이블을 반환합니다.

— Brooks

12

DynamoDB를 사용할 때 DynamoDB의 항목 / 레코드가 400KB로 제한된다는 사실도 알아야합니다 ( DynamoDB 제한 참조 ). 많은 사용 사례에서 이것은 작동하지 않습니다. 따라서 DynamoDB는 일부에 적합하지만 전부는 아닙니다. 다른 많은 NoSQL 데이터베이스에서도 마찬가지입니다.

— 알리
소스