[DB] MongoDB 와 MySQL 의 비교

[hyoseok0]

MongoDB

• NoSQL DB

MySQL

• RDB

MongoDB 용어

상세

DDL 여부

• MySQL
  • RDB 이므로 DDL 을 통한 schema 정의 필요
• MongoDB
  • NoSQL DB 이므로 DDL 없음

sharding

• sharding?

  • 하나의 Collection 내 document 들을 shard key 에 따라 여러 서버에 나눠 할당
  • sharding 은 운영 DB 에만 적용되며, standalone 구성인 개발 DB 는 적용되지 않습니다.
  • shard key 에 따른 sharding 종류
  • range sharding
    • 데이터를 일정 기준(shard key)으로 나눠 분산
  • hash sharding
    • 단일 필드를 hash 로 바꾼 뒤 range sharding
  • sharding 종류 선택 tip
  • shard key 에 포함될 첫번째 field 가 이미 hash 값(ex. Auth) 일 때, range sharding 선택
    • hash sharding 은 저장 및 조회 모두 field 를 hash 로 바꿔야 하므로, range sharding 에 비해 resource 가 많이 들어간다.
  • 그렇지 않으면, hash sharding 선택

• sharding 으로 인한 제한

  • unique 인덱스
  • shard key 를 포함하는 index 에 대해서만 적용 가능
    • unique 보장에는 순서가 필요 없으나, 샤드키+기타필드 순서 지켜야 unique 인덱스 생성 가능
  • 프라이머리 키(_id) 에 임의 값 지정 시에도 unique 보장하지 않음
  • 단일 document 수정 작업
  • updateOne(), replaceOne(), deleteOne() 과 같은 단일 document 수정 시 제한
    • deleteOne(), updateOne()(upsert 옵션이 false) 는 filter 에 shard key 또는 _id를 포함해야 함
    • updateOne()(upsert 옵션이 true), replaceOne()(upsert 옵션이 true) 는 filter 에 shard key 가 포함되어야 함

• shard key 생성

• 참고

  • 가급적 collection 에 데이터 입력 전 shard key 설정 하는 것 추천합니다. 입력 후 shard key 생성 시, DB 간 데이터 분배로 DB 부하가 커져, 해당 collection 조회가 느려질 수 있습니다.
  • _id 에 {a: 1, b: "bb"} 와 같은 embedded document 가 매핑될 때, _id 를 shard key 로 설정하는 방법이 두가지가 있다고 하고, 쿼리할 수 있는 shard 를 지정하는 targeted operation 관점에서 장단이 있다고 합니다.
  • _id 로 hashed index 를 만들어 hash sharding
    • find 내 filter 가 {_id: {a:1, b: 'bb'}} 가 많은 경우 유리
  • {"_id.a": 1, "_id.b": 1} 또는 {"_id.a": hashed, "_id.b": hashed} 과 같은 compound index 를 만들고, 해당 index 로 range 또는 hash sharding
    • find 내 filter 가 {"_id.a": 1, "_id.b": "bb"} 가 많은 경우 유리 ()
    • 현재 cake java 프로젝트들에서는 이 방안으로 쿼리 구성하므로 위 방안 추천
  • VO entity 의 @Sharded annotation 관련 설정
  • shard key 를 _id 가 아닌 다른 field 들로 지정하고, MongoTemplate save method 호출 시, document class 에 shardKey property 에 shard key 들을 설정한 @Sharded annotation 을 추가해야 합니다.
    • MongoTemplate.save 는 내부적 upsert option 을 true 로 설정한 replaceOne 을 호출하는데요. upsert option 을 true 일 때, replaceOne 의 filter 에 full shard key 가 있어야 한다고 합니다.
    • @Sharded annotation 가이드 링크
    • ex) @Sharded(shardKey = {"authId", "dateYmd"})
    • _id 에 embedded document (ex. _id: {a: 1, b: 'bb'})가 설정되고, shard key 를 embedded document 의 개별 field 로 잡은 경우 ({_id.a: 1, _id:b: 1}), 개별 field 들에 대해 @Sharded(shardKey = {"_id.a", "_id.b"}) 와 같은 annotation 을 설정해야 합니다.
    • 설정하지 않을 때 아래 에러가 발생합니다.

      org.springframework.dao.DataIntegrityViolationException: Failed to target upsert by query :: could not extract exact shard key;

primary key

개괄

• MySQL
  • 한개 또는 복수개의 column 들을 대상으로 PRIMARY KEY Constraint 지정
  • primary key column 명이 꼭 id 일 필요는 없음. id 이름을 가진 column 이 없어도 됨
• MongoDB
  • _id field 에 primary key 로 지정할 value 또는 document 지정
  • _id field 가 모든 document 에 있어야 함
  • 만약 collection 에 추가하는 document 에 _id 가 없다면, MongoDB driver 가 값을 생성해서 _id 에 할당. 생성된 값은 12-byte hexadecimal string 인 ObjectId

2개 이상의 column(field) 을 PRIMARY KEY 로 지정 시,

• MySQL
  • 복수개의 column 을 대상으로 PRIMARY KEY Constraint 지정
• MongoDB
  • _id field 에 document 로 지정
  • 추가 인덱스 생성 필요
    • ex) _id 에 {authId, dateYmd} 설정 시, {'_id.authId': 1, '_id.dateYmd': 1} 를 key 로 가진 index 생성 필요. 해당 index 가 없으면 _id.authId 조건으로 조회 시, 전체 collection scan 이 발생합니다.

참고) id 를 auto increment 값으로 설정하고, 실제 primary key 를 unique index 로 지정 후 insert 또는 update 가능 여부

• MySQL
  • INSERT ... ON DUPLICATE KEY UPDATE Statement 사용 시 가능
  • 위 구문에서 기존 데이터와의 duplicate 기준은 UNIQUE index or PRIMARY KEY duplicate 로 체크
• MongoDB
  • MongoTemplate 의 save method 호출 시, 불가능
  • 위 method 에서 기존 데이터와의 duplicate 기준은 _id 가 같은지 여부입니다. _id 가 다르고, unique index 에 같은 값이 설정된 document 로 save 를 하면, insert 를 하고, unique index constraint 에 걸러 에러가 납니다.
  • 위 경우 실제 primary key 를 _id 에 설정하면, MongoTemplate 의 save method 호출 시 insert 또는 update 가 가능합니다.