NoSQL 데이터베이스 설계를위한 모범 사례

방금 NoSQL 문서 기반 데이터베이스 (MongoDB)를 사용하기 시작했으며 데이터베이스 설계를위한 모범 사례가 궁금합니다.

아키텍처가 관계형 데이터베이스와 달라야한다고 생각합니까? 여전히 표준화 된 데이터베이스를 목표로해야합니까?

예를 들어 특정 사용 사례가 있습니다.

대여 내역 (주소 배열)을 가진 사용자가 해당 배열이 사용자의 배열이거나 공유 키가있는 별도의 컬렉션이어야합니까?

NoSQL 데이터베이스 설계에 대한 적절한 접근 방식은 DDD ( Domain Driven Design )입니다. RDBMS를 디자인하는 데 사용했던 일부 사람들에게 NoSql은 Sql 안티 패턴처럼 보이고 DDD 범위에서 고려할 때 더 의미가 있습니다.

주소 사용에 따라 임대 내역 모델 / 엔터티 내의 값 개체로 정의 할 수 있습니다.

다음은 NoSQL을 사용한 디자인에 대한 생각을 명확하게하는 몇 가지 참고 자료입니다.

• NoSQL 관리자 안내서
• Wakanda : 모델 중심 웹 애플리케이션을위한 NoSQL-NoSQL이 2012 년에 중요
• NoSQL 비평 해결
• 도메인 이벤트에 대한 경험

TL; DR

RDBMS의 정규화를 통해 관계형 패러다임의 장점을 활용할 수 있습니다.

NoSQL의 비정규 화를 통해 NoSQL 패러다임의 장점을 활용할 수 있습니다.

긴 대답

RDBMS는 고유 한 구조적 엔터티 (변경 가능 여부)와 서로의 관계를 모델링 할 수 있기 때문에 훌륭합니다. 즉, 엔티티 수준에서 작업하고 속성을 업데이트하고 다른 속성을 삽입하거나 삭제하는 등의 작업이 매우 쉽다는 것을 의미합니다. RDBMS는이 모든 것을 용이하게하는 도구를 제공합니다. 그것은 당신을 위해 참여 할 것이고, 당신을 위해 엔터티 간의 원자 적 변화를 처리 할 것입니다.

NoSQL 데이터베이스는 반 / 구조화되지 않은 집계 및 동적 엔터티를 모델링 할 수 있기 때문에 훌륭합니다. 즉, 동일한 속성과 계층 적 집계를 모두 공유하지 않는 엔터티, 변화하는 엔터티를 모델링하기가 매우 쉽습니다.

NoSql을 모델링하려면 엔터티 및 관계 대신 계층 구조 및 집계를 고려해야합니다. 그래서 당신은 사람, 임대 주소 및 그들 사이의 관계가 없습니다. 각 임대 주소에 대해 임대 주소를 집계 한 임대 기록이 있습니다.

어떤 데이터를 함께 변경해야하는지 물어봐야합니다. 다른 데이터를 논리적으로 그룹화하는 데이터 귀하의 경우 사람은 좋은 집계처럼 들립니다. 나머지 데이터를 향한 논리적 진입 점은 무엇입니까?

NoSQL은 자신이 가지고있는 다른 것을 가진 것을 저장한다고합시다. 사물의 전체 계층 구조를 다시 알려주십시오. 원하는대로 변경하겠습니다. 이제 전체 계층 구조를 변경된 계층 구조로 바꾸십시오. 그것이 당신에게주는 전부입니다. 왜 유용한가요? 당신이 가진 것은 항상 전체적으로 상호 작용하는 것들의 계층 구조입니다. 또는 대규모로 확장해야하는 경우.

RDBMS가 제공하는 모든 것은 코드와 스키마에서 수동으로 구현해야합니다. 집계가 필요한 경우 코드에 참여해야합니다. 집계의 일부만 필요한 경우 구문 분석해야합니다. 복제물을 원하지 않으면 고유성을 확인해야합니다. 집계 등을 처리 할 때 고유 한 트랜잭션 논리를 구현해야합니다.

따라서 필요한 모든 것을 갖춘 하나의 큰 테이블을 갖는 것이 NoSql로가는 길입니다. 원자 성은 그 수준에서만 보장되고 성능도 보장됩니다. 관계를 조기에 파악하는 것이 중요합니다. 이것이 비정규 화입니다.

RDBMS에서 비정규 화는 DB를 NoSQL 데이터베이스에 효과적으로 손상시킵니다. 따라서 일반적으로 반대, 즉 정규화를 원합니다. 그렇지 않으면 대신 NoSQL DB를 사용해야합니다. 둘 다 필요하지 않으면