본문 바로가기

 

Intro  

 

 

  현재 회사에 입사한지 2개월이 지났다. 회사에서 정말 다양한 종류의 NoSQL을 사용하고 있다. (Elastic Search, CouchBase, MongoDB, Casandra, Redis...). 대용량 데이터를 만져본 경험이 없었고 엔터프라이즈 레벨의 애플리케이션을 개발/운영해본 경험이 없었기 때문에 신선한 충격이였다. NoSQL에 대해서 잘 알지 못했는데 (RDBMS를 잘아는것도 아님..) 회사 선배님이 책을 추천해주셨다. 특정 벤더의 DB에 대해서 설명하는 내용이 아니라 왜 NoSQL이 필요한지 RDBMS와 어떤차이를 가지는지 잘 설명해주고 있는 책이였다.

 

  NoSQL을 왜 사용해야하는지, 언제사용해야하는지를 이해하고 특정 NoSQL에 대해서 깊게 공부하는게 좋을것 같아서 바로 구매하였다. 빅데이터 세상으로 떠나는 간결한 안내서 NoSQL 이라는 책을 읽으면서 중요한 포인트를 정리하였다.

 

 

 

 

NoSQL

NoSQL 세상을 일목요연하게 이해할 수 있는 가장 간결한 책NoSQL은 십억이 넘는 사용자가 스마트폰 등으로 끊임없이 막대한 정보를 쏟아내는 환경에 적응하고 이를 처리하기 위해 고안된 기술이다

www.yes24.com

 

 

2장 집합적 데이터 모델


 

2장은 집합이라는 용어를 통해서 기존의 RDBMS에서 데이터를 관리하는 모델과 NoSQL에서 데이터를 관리하는 모델을 설명해주고 있다.

집합(aggregate)

 책에서 `집합(aggregate)`라는 용어가 계속 등장하였다. aggregate가 에릭 에반스의 도메인 주도설계에서 나오는 aggregate와 같은 개념인지 궁금했는데 책에서 같은 의미를 가진다고 설명해주고 있다.

 

1) 관계형 DB에서의 집합

 

`관계형 데이터 모델`에서의 정보를 튜플(행)으로 구분하고 하나의 테이블이 된다. 관계형 데이터베이스 모델에서는 집합이 존재하지 않는다고 설명하고있다.

 

  나는 이 설명을 읽고 사실 이해가 가지 않았다. 외래키로 테이블끼리 관계를 맺고 JOIN연산을 통해서 가져오면 집합형성된거 아닌가?? 이 질문을 3장까지 읽고나서 내가 잘못된 생각을 했다는걸 알게되었다. 단일 테이블을 생각하면 역정규화를 하지 않는이상 집합형태의 데이터를 저장하지 못한다. 고객테이블, 주문테이블이 따로 저장되고 JOIN연산을 통해서 둘의 관계가 하나의 집합처럼 표현된다. 반면 NoSQL에서는 고객ID라는 key값에 대응하는 Value로 고객정보와,주문정보를 집합으로 구성시킬수 있다.

 

2) NoSQL에서의 집합

 

  `NoSQL` 세상에서는 집합(aggregate)을 키-값, 칼럼-패밀리,Document모델과 같이 다양한 방식으로 표현한다. 이를 공통적으로 표현할 단어가 정의되어있지 않기때문에 마틴파울러는 aggregate라는 용어를 통해 이를 설명하고있다.

 

 

※ DDD (Domain Driven Design)

 

에릭 에반스의 도메인 주도설계기법 에서 aggregate는 하나의 단위로 다루고싶은 관련객체의 무리를 의미

 

 

DDD (Domain Driven Design)

Intro 소프트웨어의 본질은 사용자를 위해 도메인에 관련된 문제를 해결하는 것이다. 기술적으로 뛰어난 성능을 갖추더라도 본질적인 문제를 해결하지 못하는 소프트웨어는 실패한 소프트웨어��

syundev.tistory.com

 

 

 

4장 분산모델


 

  NoSQL이 주목받는 이유는 클러스터 환경에 최적화되어있다는 점이다. 여기서 `집합모델이 주는 장점`이 있는데 명시적으로 집합이 구성되면 `집합(aggregate)`은 클러스터의 `같은 노드`에 저장하면 클라이언트가 하나의 노드에만 접근해서 최대한 유용한 정보를 얻어갈 수 있다. 이제 NoSQL이 왜 클러스터 환경에서 강점을 가지는지 알았다. 그렇다면 데이터베이스를 클러스터 환경으로 만드는 방법은 뭘까?

 

데이터베이스 분산모델

 

1) 샤딩(Sharding) 

 

  `샤딩`은 노드마다 서로 다른 데이터를 저장하는 방식이다. 집합이 잘 구성되어 있으면 하나의 클라이언트는 여러개의 노드에 접근할 필요 없이 한개의 노드에서 필요한 정보를 다 얻게된다. 반면, 하나의 노드가 실패하면 해당 노드에 있는 데이터를 사용할수 없는 문제가 있기때문에 샤딩만으로는 한계가 있다.

 

2) 복제(Replication)

 

  DB를 복제시켜서 다른노드에도 똑같이 저장하는 방식이다. `Master-Slave방식`으로 복제를하게되면 Master에서만 업데이트를 수행하고 Slave에서는 읽기만 가능하게 하면 읽기 연산이 많은 애플리케이션에서 강점을 보인다. 샤딩과 달리 하나의 노드가 실패하더라도 다른 노드에 붙으면 데이터 사용이 가능하다. 하지만, Master에서만 업데이트가 가능하기때문에 쓰기작업이 많아서 Master가 죽으면 업데이트 연산이 불가능해진다. 또한, 네트워크 유실과 같은 상황에서 Slave로 데이터가 복제되지 않으면 서로 다른 데이터를 읽는 현상이 발생할 수 있다.   

  이런 문제를 해결하기 위해서 `Peer-to-Peer방식`의 복제도 있는데 Slave도 업데이트 연산을 수행할 수 있다. 업데이트 연산을 Slave도 하기때문에 Master의 실패가 전체 클러스터에 영향을 주지는 않지만 여러 Slave에서 동시에 같은 데이터를 업데이트하면 일관성 문제가 생기게 된다.

 

 

 

 

5장 일관성


 

'개발서적' 카테고리의 다른 글

테스트 주도 개발 시작하기  (0) 2020.08.09

댓글