REST API 용 Mongo 데이터베이스 구성 방법

Question

Mongo와 함께 REST API를 작성 중이며 전체 문서 모델링 전략에 흥미를 느낍니다. 그것은 사람들이 처음으로 비정규 화하고 정상화 시키거나 그 반대의 경우를 말하는 매우 분열적인 문제인 것처럼 보입니다.

REST API의 리소스 구조가 문서 기반 db의 구조에 어떻게 영향을 주는지 알고 싶습니다. REST API 리소스 구조와 비슷하지만 Mongo의 장점 중 하나에 맞춰 작동하는 것처럼 보이지만 모든 장소 (예 : 위치, 입주자, 거래)에 대해 별도의 콜렉션을 갖는 것이 좋습니다.

제 질문은 NoSQL (특히 Mongo) 문서 데이터베이스에서 REST API의 리소스를 모델링하는 방법입니다.

Answer 1

대답은 최적화 할 대상에 따라 여러 가지가 있습니다. 일반적으로 문서 스키마 정의 및 컬렉션 분리는 문서의 특정 용도가 무엇인지, 즉 데이터를 어떻게 사용합니까?

컬렉션 사이의 조인은 값 비쌉니다. 기본적으로 하나의 컬렉션에서 외래 키를 가져오고 다른 컬렉션에서 다른 전체 조회를 수행하는 것이므로 정규화가 일반적으로 성능에 도움이되는 것입니다. - 사용 사례와 일치하는 경우 앞으로 MongoDB가 빛날 가능성이 있습니다. 요구 사항이 변경되면 문서 구조가 크게 변경 될 수도 있습니다.

두 번째 주요 고려 사항은 마지막으로 확인한 MongoDB 문서 크기 제한 - 약 16MB입니다. 블로그 게시물 모음과 함께 예전의 블로그 웹 사이트 예를 봅니다. 게시물 문서에 배열로 코멘트를 하위 문서로 저장하도록 선택할 수 있습니다. 이 방법으로/post/postID에 대한 나머지 API를 가질 수 있으며, 주석에 대한 다른 콜렉션에서 "조인"또는 조회를 수행하지 않고도 포스트 문서를 리턴 할 수 있습니다. 그러나 엄청난 양의 의견이있는 게시물이있는 경우 문제가 발생합니다. 따라서이 경우 주석을 다른 모음으로 구분하여 데이터를 표준화해야합니다.

데이터베이스의 검색 속도와 용이성 및 문서 저장 공간의 유연성 - 향후 문서 구조를 변경해야 할 경우 프로젝트 API를 계획 할 때 고려해야 할 두 가지 주요 고려 사항이 있습니다. .

문서/모음 X가 어떻게 사용 되나요? 언제 데이터를 가져와야합니까? 하나의 리소스 세입자에 "부모 리소스"가 인이고 액세스 위치가 실제로 세입자를 필요로하는 유일한 경우라면 모든 수단을 통해 세입자의 스토리지를 위치 스키마에 잠재적으로 설계 할 수 있습니다. 그러나 만약 당신이 스스로 세입자들에게 질의를 할 수 있어야한다면, 세입자들을 그들 자신의 수집 물로 나눌 수 있습니다. 따라서 올바른 방법이나 잘못된 방법은 없습니다. 데이터를 어떻게 사용할 것인지 계획을 세우십시오!

행운을 빈다.