우리가 개발중인 애플리케이션에 AWS DynamoDB를 사용할 것을 고려하고 있습니다. DynamoDB에서 S3으로 데이터를 내보내는 백업 작업을 설정하면 EMR이있는 데이터 파이프 라인이 필요하다는 것을 알고 있습니다. 하지만 제 질문은 1 일차에 백업 작업을 설정하는 것에 대해 걱정할 필요가 있습니까? 데이터 손실이 발생할 수있는 기회는 무엇입니까?AWS Dynamo DB의 백업 데이터 파이프 라인을 매일 설정해야합니까?
이것은 실제로 주관적입니다. IMO 당신은 그들에 대해 '지금'걱정하지 않아야합니다. 간단한 솔루션 인 other than pipleline을 사용할 수도 있습니다. 아마도 그것은 시작할 수있는 좋은 곳이 될 것입니다.
DynamoDB를 1 년 넘게 주요 프로덕션 데이터베이스로 실행 한 후에 훌륭한 경험이라고 할 수 있습니다. 데이터 손실 및 중단 시간 없음. 우리가 신경 쓰는 유일한 이유는 SDK의 오작동과 프로비저닝 된 처리량을 조정하는 것입니다.
(1) 데이터를 실수로 삭제의 경우에 복원하기 위해, 매일 S3에 백업을 만들거나 더 나쁜 아직 드롭 테이블 : DynamoDB의 테이블 데이터를 다른 곳에 복사에 대한
DynamoDB에 대한 경험을 공유해 주셔서 감사합니다. 파이프 라인이 아닌 간단한 솔루션에 대해 자세히 설명해 주시겠습니까? – DaHoopster
CSV로 내보내기 옵션에 링크했습니다 (파이프 라인 링크 제외) –
여러 사용 사례가 있습니다 (코드 버그?)
(2) S3에서 백업을 만들어 분석 워크 플로의 시작점이됩니다. 이 데이터가 S3에 백업되면 RDBMS 시스템 (RDS 또는 사내 구축 형) 또는 로그 파일의 다른 S3 데이터와 결합 할 수 있습니다. 데이터 통합 워크 플로에는 BI 쿼리를 위해 최종적으로 ETL (Redshift)에로드 할 EMR 작업이 포함될 수 있습니다. 또는 더 많은 ELT 스타일을 수행하기 위해 이것을 Redshift에 직접로드하십시오. - 변형은 Redshift 내에서 발생합니다.
(3) 한 테이블에서 다른 테이블로 데이터를 복사합니다 (동일한 영역 또는 다른 영역 내에서) - 오래된 테이블은 통제 된 성장과 비용 절감을 위해 쓰레기 수거가 가능합니다. 이 테이블 간 복사는 지역별 가용성 문제와 관련하여 쉽게 사용할 수있는 백업 테이블로 사용할 수도 있습니다. 또는이 메커니즘을 사용하여 하나의 영역에서 다른 영역으로 데이터를 복사하여이를 사용하는 DynamoDB 클라이언트 응용 프로그램과 가까운 쪽의 끝점에서 처리 할 수 있습니다.
(4) S3에서 데이터의 주기적 복원. 높은 동시성, 낮은 대기 시간 요구 사항을 갖춘 온라인 응용 프로그램에서 사후 분석 데이터를 다시 DynamoDB에로드하여로드 균형을 조정할 수있는 방법입니다.
AWS Data Pipeline은 유연한 데이터 전송 솔루션 (아래 EMR 사용)을 통해 이러한 모든 시나리오를 예약하는 데 도움이됩니다.
이러한 솔루션을 사용할 때주의해야 할 점은 특정 시점 백업이 아니라는 점입니다. 따라서 백업 중에 발생하는 기본 테이블 변경 사항이 일치하지 않을 수 있습니다.
@SudheerT 사례 연구 개요 감사합니다 – DaHoopster
S3 버킷에 매일 백업하도록 데이터 파이프 라인을 설정하는 것이 좋습니다. 정말로 안전하고 싶다면.
Dynamo DB 자체는 매우 안정적 일 수 있지만 실수로 삭제 한 경우를 방지 할 수있는 사람은 아무도 없습니다 (사용자 또는 동료가 실수로 콘솔에서 테이블을 삭제 한 경우). 그래서 나는 매일 백업을 설치하도록 제안 할 것이다 - 어떤 경우에는 그렇게 많은 비용이 들지 않는다.
실제 사용자가 지연을 볼 수 없도록 백업이 진행되는 동안 파이프 라인이 용량의 25 % 만 소모한다고 말할 수 있습니다. 모든 백업은 "꽉 찼습니다"(증분이 아님). 따라서 주기적으로 저장을 염려하는 경우 일부 오래된 백업을 삭제할 수 있습니다.
주로 데이터를 다른 지역으로 복사하는 데 사용됩니다 (DR 사고) – Guy