https://bcho.tistory.com/666 참고

1. 기본

Denormalization

NoSQL은 JOIN 지원 X

문제점

JOIN을 지원하지 않기때문에 두 테이블에 대해 2번의 SELECT 쿼리를 날려야함

해결

처음부터 JOIN이 되어있는 테이블을 하나 더 만들어 버리면됨

장점

• 성능 향상 : 쿼리 한번만 하니까
• 쿼리 로직 복잡도 낮아짐 : JOIN 없이 바로 조회만 하면되니까

단점

• 데이터 일관성 문제 발생 가능
  • JOIN이 된 테이블을 생성하는 경우 해당 칼럼이 포함된 테이블에서 UPDATE나 INSERT를 진행하는 경우 JOIN 된 테이블까지 수정을 해야함으로 불 일치성이 발생 할 수 있음
• 데이터 중복 저장으로 인한 용량 증가 발생

Aggregation

Scheme-less 또는 Soft Scheme 특성이 있음

→ 데이터 타입 구조가 다 달라됨

→ 데이터에 데이터를 넣는식(집합화)으로 구성

Application Side Join

두번 쿼리 날리는거

<aside> 💡 Server Side Join

• Riak나 MongoDB 같은 일부 NoSQL DB는 RDBMS stored procedure를 지원함. Map & Reduce 라는 이름으로 기능을 지원하고 Application Side Join에서 Application에서 지원하는 부분을 NoSQL서버에서 수행한다는 것임. NoSQL에 대한 부담이 커지긴함

</aside>

2. 확장된 데이터 모델링 패턴

Atomic Aggregation

장애로인한 데이터 일관성에 대해 문제가 생길때 사용

→ 그냥 두 테이블을 하나로 합치는거

→ Aggregation과 패턴상으로는 같은데 Aggregation은 1:n 관계 JOIN을 없애기 위함이고 이건 불일치성 해결을 위함임

Index Table

nosql에 index가 없기때문에 key 이외의 필드를 찾으면 테이블 전체를 스캔해야함

→ index를 위한 별도의 테이블을 만들어서 사용, 해당값만 조회할 수 있도록 인덱스들만 담는거임

Composite Key

RDBMS의 복합키와 같은 개념이라 생각하면 편함.

RDBMS는 여러 칼럼들을 PK로 지정하지만 NoSQL은 한 칼럼에 deliminator 이용해서 여러 키를 묶어서 넣음

“특정 서버로 몰림 현상” 주의해야함

• key 기준으로 N개의 서버에 나눠 저장되는데, 클러스터 서버 수 와 전체 데이터에서 해당 key가 점유하는 비율을 고려해서 성능 저하가 유발 되지않도록 부하가 골고루 분산되도록 key를 선정하는 것이 필요함

Inverted Search Index

검색 엔진에서 많이 사용

key가 URL일때 해당 URL의 문서내의 단어들을 색인해서 value로 두고, value에 있는 키워드로 접속했을때 value값을 통해 다시 value가 key인 DB에 조회함으로 검색 키워드를 가지고 있는 URL들을 보여주는 형식

Enumerable Keys