DynamoDB 및 MongoDB NoSQL [닫기]

나는 미래의 프로젝트에 무엇을 사용할 수 있는지 알아 내려고 노력하고 있습니다. 우리는 첫해에 한 달에 약 500k 레코드를 저장할 계획이며 앞으로 몇 년 동안 이것은 수직 응용 프로그램이므로 더 이상 사용할 필요가 없습니다. 이것이 noSQL 데이터 스토리지를 선택하기로 결정한 이유입니다.

내 마음에 들었던 첫 번째 옵션은 mongo db 였으므로 커뮤니티의 많은 지원을받는 매우 성숙한 제품이지만 최고의 성능으로 관리 서비스를 제공하는 새로운 제품을 개발했습니다. 응용 프로그램이지만 유지 관리 계획은 없지만 (최소한 현재) 아마존은 확장 가능한 탄력적 인 방법을 제공하기 때문에 큰 이점이 될 것이라고 생각합니다.

내 주요 관심사는 쿼리 구조에 관한 것이지만, dynamoDB 쿼리 기능을 아직 보지 않았지만 ak / v 데이터 스토리지이므로 mongo db보다 더 제한적이라고 생각합니다.

누군가 mongoDB에서 DynamoDB로 프로젝트를 이동 한 경험이 있다면 조언을 부탁드립니다.

최근에 MongoDB를 DynamoDB로 마이그레이션하고 3 개의 블로그를 작성하여 성능, 비용에 대한 경험과 데이터를 공유했습니다.

MongoDB에서 AWS DynamoDB + SimpleDB로 마이그레이션

DynamoDB보다 MongoDB를 사용해야하는 7 가지 이유

MongoDB보다 DynamoDB를 사용해야하는 3 가지 이유

나는 이것이 오래되었다는 것을 알고 있지만 비교를 검색 할 때 여전히 나타납니다. 우리는 몽고를 사용하고 있었고 거의 모든 것을 디나모로 옮겼습니다. 더 많은 기능을 가지고 있기 때문에 그렇지 않습니다. Mongo는 더 나은 쿼리 언어를 가지고 있으며 구조 내에서 색인을 생성 할 수 있습니다. Dynamo의 우월성은 OP가 의견에서 언급 한 내용에 있습니다. 쉽습니다. 서버를 관리 할 필요가 없습니다. Mongo 샤드 솔루션을 설정하기 시작하면 복잡해집니다. 호스팅 회사 중 하나에 갈 수는 있지만 저렴하지는 않습니다. Dynamo에서는 처리량이 더 필요한 경우 버튼을 클릭하면됩니다. 자동으로 확장 할 스크립트를 작성할 수 있습니다. Dynamo를 업그레이드 할시기가되면 완료된 것입니다. 그것은 많은 소중한 스트레스와 시간이 소비되지 않은 것입니다. 당신이하지 않으면

이제 기본적으로 Dynamo를 사용합니다. Mongo는 아마도 데이터 구조가 그것을 보장하기에 충분히 복잡하다면 아마도 SQL 데이터베이스로 돌아갈 것입니다. Dynamo는 애매 모호하므로 실제로 어떻게 구축 할 것인지 생각해야하며 Elasticcache에서 Redis를 사용하여 복잡한 작업에 사용할 수 있습니다. 그러나 그것을 돌볼 필요가없는 것이 좋습니다. 당신은 코딩합니다. 그게 다야.

500k 문서를 사용하면 크기를 조정할 필요가 없습니다. SSD와 8GB 램이 장착 된 일반적인 랩톱은 천만 건의 레코드를 쉽게 수행 할 수 있으므로, 스케일링으로 인해 선택하려는 경우 실제로 중요하지 않습니다. 가장 마음에 드는 것을 선택하고 가장 온라인 지원을받을 수있는 곳을 선택하는 것이 좋습니다.

빠른 개요 비교를 위해 AWS DynamoDB vs MongoDB와 같은 많은 비교 페이지가있는이 웹 사이트가 정말 마음에 듭니다. http://db-engines.com/en/system/Amazon+DynamoDB%3BMongoDB

짧은 대답 : SQL로 시작하고 필요한 경우에만 NoSQL을 추가하십시오. (단순한 쿼리 이외의 것을 필요로하지 않는 한)

개인적 경험 : 쿼리에 MongoDB를 사용하지는 않았지만 2015 년 4 월 현재 DynamoDB는 가장 기본적인 키 / 값 쿼리를 넘어서는 문제에 대해서는 여전히 무너져 있습니다. 나는 기본적인 것을 좋아하지만 쿼리 언어를 원한다면 실제 SQL 데이터베이스 솔루션을 찾으십시오.

DynamoDB에서는 해시 또는 해시 및 범위 키를 쿼리 할 수 ​​있으며 여러 보조 글로벌 인덱스를 가질 수 있습니다. 4 개의 가능한 필터 매개 변수를 사용하여 단일 테이블에서 쿼리를 수행하고 결과를 정렬하면 필터 표현식과 함께 글로벌 보조 인덱스를 사용하여 거의 지원되지 않습니다. 필터와 일치하는 총 결과를 얻으려고 할 때 문제가 발생합니다. 필터와 일치하는 처음 10 개 항목을 검색 할 수는 없지만 10 개 항목을 확인하면 0 개의 유효한 결과를 얻을 수 있습니다. 연속 키에서 스캔-목에 통증이 있고 간단한 시나리오를 위해 너무 많은 테이블 읽기 할당량을 소비합니다.

쿼리에서 필터의 제한 문제에 대해 구체적으로 설명하면 다음과 같습니다 ( http://docs.aws.amazon.com/amazondynamodb/latest/developerguide/QueryAndScan.html#ScanQueryLimit ).

응답으로 DynamoDB는 모든 일치하는 결과를
한계 값의 범위 예를 들어 검색어를 발행 한 경우
또는 제한 값이 6이고 필터가없는 스캔 요청
식에서 연산은 
요청 매개 변수와 일치하는 테이블 당신이 또한 공급하는 경우
FilterExpression, 작업은 
필터 요구 사항과 일치하는 표의 처음 6 개 항목

필자의 결론은 FilterExpressions와 관련된 쿼리는 매우 드문 경우에만 사용할 수 있으며 각 쿼리가 너무 많은 DynamoDB 읽기 단위를 소비하는 테이블의 대부분 또는 전부를 쉽게 읽을 수 있기 때문에 확장 할 수 없다는 것입니다. 너무 많은 읽기 단위를 사용하면 제한을 받고 성능이 저하됩니다.

전문가 의견 : 2015 년 4 월 9 일 AWS 서밋에서 AWS의 솔루션 아키텍처 관리자 인 Brett Hollman은 처음 1,000 만 명의 사용자를 대상으로 SQL 데이터베이스를 시작한 다음 NoSQL을 사용하는 것이 좋습니다. 조만간 스택에 SQL 서버가 필요할 것입니다. 그의 슬라이드는 다음과 같습니다. http://www.slideshare.net/AmazonWebServices/deep-dive-scaling-up-to-your-first-10-million-users 슬라이드 28을 참조하십시오.

우리는 건강 관리 제품으로 Mongo / Dynamo의 조합을 선택했습니다. 기본적으로 mongo는 더 나은 검색을 허용하지만 호스팅 된 Dynamo는 추가 작업없이 HIPAA를 준수하므로 훌륭합니다. 따라서 표준 설정에서 개인 데이터가없는 몽고 부분을 호스팅하고 아마존이 인프라 측면에서 HIPAA 부분을 처리 할 수 ​​있습니다. 관련성있는 Dynamo 문서의 포인터 (ID)가있는 문서를 가져 오는 mongo에서 특정 항목을 쿼리 할 수 ​​있습니다.

dynamo에서 전체 애플리케이션을 호스팅하는 대신 mongo를 사용하여이 작업을 수행 한 주된 이유는 두 가지 이유 때문입니다. 먼저, 우리는 현재 몽고가 가장 좋았던 위치 기반 검색을 수행해야했지만 Dynamo는 그렇지 않았지만 지금은 옵션이 있습니다.

두 번째로 일부 문서는 구조화되지 않았으며 데이터가 무엇인지 미리 알지 못했기 때문에 예를 들어 { "username": "user1", "과 같이"form "컬렉션에 문서를 입력 할 수 있습니다. 이메일 ":"me@me.com "}. 그리고 다른 사용자는 이것을 같은 모음 { "phone": "813-555-3333", "location": [28.1234, -83.2342]}에 넣습니다. mongo를 사용하면 언제든지 동적 및 알 수없는 필드를 검색 할 수 있습니다 .Dynamo를 사용하면이 작업을 수행 할 수 있지만 검색 할 수있는 새 필드가 추가 될 때마다 색인을 만들어야합니다. 따라서 Dynamo 문서에 전화 필드를 한 번도 본 적이 없으면 갑자기 검색 할 수없는 일부 필드가 추가됩니다.

이제 이것은 당신이 언급 한 또 다른 요점을 불러옵니다. 때로는 작업에 적합한 솔루션을 선택한다고해서 항상 작업에 가장 적합한 제품을 선택하는 것은 아닙니다. 예를 들어 10 년 이상 생성 한 시스템이 필요하고 사용할 클라이언트가있을 수 있습니다. 작업을 수행하기에 충분한 SaaS / IaaS 솔루션을 사용하는 것은 아마존이 장기적으로 시스템을 유지하고 유지 관리하기 위해 의존 할 수 있기 때문에 더 나은 옵션이 될 수 있습니다.

나는 둘 다와 두 종류의 팬 모두에서 일했습니다.

그러나 언제 어떤 용도로 어떤 용도로 사용해야하는지 이해해야합니다.

나는 모든 데이터베이스를 DynamoDB로 옮기는 것이 좋은 생각이라고 생각합니다. 기본 키와 보조 키를 제외하고 쿼리가 어려운 이유, 인덱싱이 제한되어 있으며 DynamoDB에서 스캔하기가 어렵습니다.

광범위한 쿼리 가능 데이터가 있어야하는 몽고 DB (MongoDB)가있는 하이브리드 종류의 DB를 사용하려고한다.

DynamoDB는 매우 빠르며 (MongoDB보다 빠름) DynamoDB는 종종 확장 가능한 애플리케이션의 세션에 대한 대안으로 사용됩니다. 또한 DynamoDB 모범 사례에 따르면 사용량이 적은 데이터가 많으면 다른 테이블로 이동하는 것이 좋습니다.

기사 나 피드가 있다고 가정 해 봅시다. 사람들은 지난 주 물건이나 이번 달 물건을 찾을 가능성이 높습니다. 사람들이 2 살짜리 데이터를 방문 할 가능성은 거의 없습니다. 이러한 목적으로 DynamoDB는 데이터를 다른 테이블에 월 또는 연도별로 저장하는 것을 선호합니다.

DynamoDB는 확장 성이 뛰어나며 MongoDB에서 수동으로 수행해야하는 작업입니다. 그러나 처리량 파티션과 스케일링이 배후에서 어떻게 작동하는지 이해하지 못하면 DynamoDB의 성능이 저하됩니다.

속도가 중요한 곳에서는 DynamoDB를 사용해야하며, MongoDB에는 너무 많은 손과 기능이있어 DynamoDB에없는 것이 있습니다.

예를 들어, 복제본 중 하나가 8 시간 (또는 기타) 시간의 데이터 인스턴스를 보유하는 방식으로 복제본 MongoDB 세트를 가질 수 있습니다. DB에서 큰 시간을 허비하고 이전과 같이 데이터를 얻으려는 경우 정말 유용합니다.

그래도 내 의견이다.

명심하십시오, 나는 MongoDB로만 실험했습니다 ...

내가 읽은 내용에서 DynamoDB는 기능면에서 먼 길을 왔습니다. 이전에는 스토리지 및 쿼리 기능이 극히 제한적인 초급 키-값 저장소였습니다. 그 이후로 더 큰 문서 크기 + JSON 지원 및 글로벌 보조 인덱스를 지원 합니다. 기능 측면에서 DynamoDB와 MongoDB가 제공하는 것의 격차는 매월 점점 작아지고 있습니다. DynamoDB의 새로운 기능이 여기에서 확장되었습니다 .

최근에 DynamoDB 기능이 추가되어 MongoDB 대 DynamoDB 비교의 대부분이 오래되었습니다. 그러나이 게시물 에서는 DynamoDB를 선택할 수있는 다른 확실한 요점을 제공합니다. 즉 간단하고 유지 보수가 적으며 비용이 저렴하다는 점입니다. 데이터베이스 선택에 대한 또 다른 토론 은 약간 오래되었지만 흥미 롭습니다.

내 테이크 아웃 : 심각한 데이터베이스 쿼리를 수행하거나 DynamoDB에서 지원하지 않는 언어로 작업하는 경우 MongoDB를 사용하십시오. 그렇지 않으면 DynamoDB를 사용하십시오.