DynamoDB 및 MongoDB NoSQL [폐쇄]

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는 그렇지 않았지만 지금은 옵션이 있습니다.

Secondly was that some documents were unstructured and we did not know ahead of time what the data would be, so for example lets say user a inputs a document in the "form" collection like this: {"username": "user1", "email": "me@me.com"}. And another user puts this in the same collection {"phone": "813-555-3333", "location": [28.1234,-83.2342]}. With mongo we can search any of these dynamic and unknown fields at any time, with Dynamo, you could do this but would have to make a index every time a new field was added that you wanted searchable. So if you have never had a phone field in your Dynamo document before and then all of the sudden, some one adds it, its completely unsearchable.

Now this brings up another point in which you have mentioned. Sometimes choosing the right solution for the job does not always mean choosing the best product for the job. For example you may have a client who needs and will use the system you created for 10+ years. Going with a SaaS/IaaS solution that is good enough to get the job done may be a better option as you can rely on amazon to have up-kept and maintained their systems over the long haul.

---

I have worked on both and kind of fan of both.

But you need to understand when to use what and for what purpose.

I don't think It's a great idea to move all your database to DynamoDB, reason being querying is difficult except on primary and secondary keys, Indexing is limited and scanning in DynamoDB is painful.

I would go for a hybrid sort of DB, where extensive query-able data should be there is MongoDB, with all it's feature you would never feel constrained to provide enhancements or modifications.

DynamoDB is lightning fast (faster than MongoDB) so DynamoDB is often used as an alternative to sessions in scalable applications. DynamoDB best practices also suggests that if there are plenty of data which are less being used, move it to other table.

So suppose you have a articles or feeds. People are more likely to look for last week stuff or this month's stuff. chances are really rare for people to visit two year old data. For these purposes DynamoDB prefers to have data stored by month or years in different tables.

DynamoDB is seemlessly scalable, something you will have to do manually in MongoDB. however you would lose on performance of DynamoDB, if you don't understand about throughput partition and how scaling works behind the scene.

DynamoDB should be used where speed is critical, MongoDB on the other hand has too many hands and features, something DynamoDB lacks.

for example, you can have a replica set of MongoDB in such a way that one of the replica holds data instance of 8(or whatever) hours old. Really useful, if you messed up something big time in your DB and want to get the data as it is before.

That's my opinion though.

---

Bear in mind, I've only experimented with MongoDB...

From what I've read, DynamoDB has come a long way in terms of features. It used to be a super-basic key-value store with extremely limited storage and querying capabilities. It has since grown, now supporting bigger document sizes + JSON support and global secondary indices. The gap between what DynamoDB and MongoDB offers in terms of features grows smaller with every month. The new features of DynamoDB are expanded on here.

Much of the MongoDB vs. DynamoDB comparisons are out of date due to the recent addition of DynamoDB features. However, this post offers some other convincing points to choose DynamoDB, namely that it's simple, low maintenance, and often low cost. Another discussion here of database choices was interesting to read, though slightly old.

My takeaway: if you're doing serious database queries or working in languages not supported by DynamoDB, use MongoDB. Otherwise, stick with DynamoDB.

참고URL : https://stackoverflow.com/questions/17931073/dynamodb-vs-mongodb-nosql