전체 글26 MongoDB - (9) - 애플리케이션 설계 본 섹션은 내게는 굉장히 유의미한 섹션이 될 것이다. 따라서 다른 포스팅 처럼 대충하지 않고 열심히 해보겠다. 한 번에 전부 기술하지 않고 연결된 포스팅으로 아래사항을 다룰 것이다. 스키마 설계 고려 사항 데이터 embed 방식과 참조 방식 중 결정하기 최적화를 위한 팁 일관성 고려 사항 스키마 마이그레이션 방법 스키마 관리 방법 몽고 DB가 데이터 스토리지로 적합하지 않은경우 스키마 설계 고려 사항 RDBMS와는 달리 스키마를 모델링하기 위해서는 쿼리 데이터 접근 패턴 을 이해해야한다. 다음은 설계 시 주요 요소이다. 제약 사항 쿼리 및 쓰기의 접근패턴 관계 유형 카디널리티 제약 사항 몽고 DB의 도큐먼트 최대 크기는 16MB이며 디스크에서 전체 도큐먼트를 읽고 쓴다. 갱신은 전체 도큐먼트를 다시 쓰며.. 2023. 4. 22. MongoDB - (8) - 트랜잭션 트랜잭션은 읽기나 쓰기 작업이 가능한 데이터베이스 작업을 하나 이상 포함하는 데이터베이스의 처리 단위이다. 트랜잭션의 중요한 특징은 작업이 성공하든 실패하든 부분적으로 완료되지 않는 점이다. (중도 실패시 롤백) 따라서 진정한 트랜잭션이 되려면 ACID 속성을 만족해야한다. Atomicity - 원자성 Consistency - 일관성 Isolation - 고립성 Durability - 영속성 몽고 DB는 이를 만족한다. 2023. 4. 22. MongoDB - (7) - 집계 프레임워크 아래 aggregate로 companies collection에 name과 설립일자를 확인할 수 있다. db.companies.aggregate([ {$match : {founded_year: 2004}}, {$project : { _id: 0, name: 1, founded_year : 1 }} ]) aggregate는 집계 쿼리를 실행할때 호출하는 메서드로, 집계 파이프라인을 구현할 수 있는 메서드이고, 파이프라인은 도큐먼트를 요소로 포함하는 배열이다. limit을 추가한 코드를 보자. db.companies.aggregate([ {$match : {founded_year: 2004}}, {$limit : 5}, {$project : { _id: 0, name: 1, founded_year : 1 }.. 2023. 4. 22. MongoDB - (6) - 인덱싱2 MongoDB에서는 무조건 인덱싱을 사용하는 것은 옳지 않다. 데이터의 일부를 조회할 때 가장 효율적이며 어떤 쿼리는 인덱스가 없는게 더 빠르다. 인덱스는 컬렉션에서 가져와야 하는 부분이 많을 수록 비효율 적이다. 왜냐면 인덱스를 하나 사용하려면 두 번의 조회를 해야하기 때문이다. 아쉽게도 인덱스가 도움이 될지 혹은 방해가 될지 알 수 있는 공식은 없다. 실제 데이터 크기 인덱스 크기 도큐먼트 크기 결과 셋 평균 크기 에 따라 다르기 때문이다. 쿼리의 30% 이상을 반환하는 경우 인덱스는 종종 쿼리 속도를 높인다. 하지만 이 수치는 2% ~ 60% 까지 다양한 양상을 띈다. 인덱스가 적합한 경우 큰 컬렉션 큰 도큐먼트 선택적 쿼리 컬랙션 스캔이 적합한 경우 작은 컬렉션 작은 도큐먼트 비선택적 쿼리 인덱스.. 2023. 4. 22. 이전 1 2 3 4 5 ··· 7 다음