NoSQL Distilled

뇌피셜 주의!

이 글은 이 책을 읽고 느낀 개인적인 생각을 적은 글입니다. 곧이 곧대로 믿지 말아주시고, 틀린 내용이나 의견 있으면 자유롭게 남겨주세요 :)

NoSQL Distilled

최근 읽은 책중에 재밌게 읽은 게 있어서 소개해 보려고 가져왔다. 크게 1부(기본 개념)와 2부(적용)로 나뉘어 있는데, 2부에서는 각 NoSQL 제품군들의 종류에 대한 간략한 소개가 들어있다. 정말 간략한 소개이기 때문에 1부만 보아도 충분할 것 같다.

 

그렇기에 이번 내용에도 거의 1부 내용만 소개하려고 한다. 내가 재밌게 읽었던 부분들은 다음과 같다.

 

- NoSQL의 등장 배경과 특성

  - aggregate data model의 특성

- 일관성 / 분산 모델 / 맵 리듀스

- 스키마 관련

 

이 책을 읽고나서 원래 가지고 있던 NoSQL에 대한 의문들 중 3가지 정도 해결되었다.

 

- 어디서는 NoSQL이 읽기에 빠르다고 하고, 어디서는 쓰기에 빠르다고 하고, 또 어디서는 대용량 처리에 좋다고 한다. 그럼 모든 곳에서 좋다는 것 아닌가? 그러면 왜 안 쓰지? 그냥 RDB가 레퍼런스가 많고 비교적 오래 되었으니 지원이나 버그가 적어서 그런 건가? 아님 group by와 같은 것들의 성능이 좋으니 범용으로 쓰기 좋아서 그런 건가?

- NoSQL을 사용하면 스키마가 없다고 해서 좋다고 한다. 근데 애플리케이션에서는 어쨌든 데이터 꼴을 알아야 질의를 하던 가공을 하던 할텐데? 이러한 것들은 어떻게 관리되는 거지? 그냥 ALTER 날리지 않아도 되는 것 외에 어떤 장점이 있는 거지?

- read DB들은 분산하면 되지만, write DB는 1개 뿐인데 쓰기 부하가 많이 걸리면 어떻게 해결하지? 쓰기 DB가 많아지면 정합성은 어떻게 관리하지?

 

일단 이번 글에서는 제일 흥미로웠던 aggregate data model의 특성에 대해 내가 이해한 내용을 정리해 보았고, 평소 궁금하던 NoSQL에서 스키마 없음이 왜 장점인지에 대한 내용도 써보았다.

 

NoSQL의 특성

NoSQL의 장점은 크게 2가지가 있다.

- 개발 생산성: row꼴의 데이터만 활용할 수 있는 RDB와 달리, 더 다양한 자료구조를 활용할 수 있다. 이는 애플리케이션의 객체와 더 쉽게 대응할 수 있기 때문에 생산성이 높아진다

- 대규모 데이터: RDB는 1대의 장비에서 실행되도록 설계되었지만, 몇몇 NoSQL 솔루션들은 작고 값싼 장비 여러 대로 클러스터를 구성할 수 있어 더 저렴하게 운용 가능하다.

 

여기서 말한 NoSQL이 모든 NoSQL의 특성을 대표하는 것은 아니다. 지금 NoSQL이라 부르는 솔루션들은 내가 느끼기에 비유하자면 "사람 아닌 생물"을 말하는 듯한 느낌이다.

 

예를 들어 고양이는 높은 곳에 잘 올라가지만 고등어는 높은 곳에 올라가기는 커녕 물 밖에 나올 수도 없다. 같은 "사람 아닌 생물"임에도 불구하고 말이다.

 

따라서 NoSQL 제품군 종류를 묶을 수는 있지만, 모든 NoSQL을 한 번에 묶기에는 어려운 듯 싶다. 위에서 말하는 NoSQL의 특성은 aggregate 기반 모델의 특성이라고 보는 편이 더 좋은 것 같다. (내가 보기엔)

 

NoSQL 생태계에서 가장 많이 쓰이는 분류는 key-value(키-값), document(문서), column-family, graph 이렇게 4가지인데, (이게 주류라는 것이고 4가지 말고 더 있을 것이다) 이중 앞서 3가지가 aggregate oriented(집합 지향)라는 특성을 공유한다.

 

책에서는 집합 지향, 키-값, 문서 이런 식으로 한글로 명세했는데 일단 나는 문서 db라던가, 집향이라는 표현을 쓰는 사람은 거의 못보고 도큐먼트라던가 애그리것이라고 부르는 사람들을 훨씬 많이 봐왔기 때문에 영어로 표기하는 게 데 자연스럽다고 생각해 이렇게 표기했다.

 

여기서 aggregate의 의미는 에릭 에반스의 DDD에서 나온 용어이다. DDD에서 aggregate은 단위로 다루고 싶은 관련된 객체의 무리를 뜻한다.

 

aggregate 기반 모델들은 aggregate 단위로 데이터를 조작하며 트랜잭션 단위로 사용한다. RDB에서는 세션 단위로 여러 row들을 한꺼번에 트랜잭션을 잡는 ACID 트랜잭션을 사용하지만, aggregate 기반 NoSQL 모델들은 그렇지 않고 단지 aggregate 단위로 데이터의 원자성을 보장한다. NoSQL은 트랜잭션을 지원하지 않는다는 말을 한다면 이 특성에서 온 것일 것이다.

 

RDB는 aggregate 단위가 아닌 단순한 튜플 구조로만 데이터를 다룰 수 있다

 

대신 aggregate 기반 모델들은 정규화 / 역정규화를 신경써야 한다. 트랜잭션 단위기 때문에 신중하게 결정해야 하며, 만일 충분히 데이터를 담지 못하면 참조키를 통해 다시 접근하는 꼴로 만들어야 한다. 그런데 내 생각에 이러한 꼴은 권장되는 패턴은 아닌 것 같다. 일단 내 생각에는 (aggregate 기반)NoSQL의 특성상 데이터의 중복을 허용해야 하는데, 이러면 참조키로 접근할 때 중복되는 것들을 다 찾아야 할 수도 있을 것 같다는 생각이다.

 

따라서 다음과 같이 도메인 마다 형태가 데이터를 저장하는 형태가 달라질 수 있다.

 

 

 

위 사례는 같은 데이터에 대해서 모델 설계를 어떻게 하느냐에 따라 모델이 달라진다. 저 데이터를 활용하는 비즈니스 요구사항에 따라 형태가 달라질 것이다. 이렇게 보면 비즈니스 요구사항이 명확한 경우 / 비즈니스 요구사항이 잘 분석된 경우에 사용하는 게 좋을 것 같다.

 

위에서 말한 중복을 허용하는 특성상, update 치기도 힘들기 때문에 필요한 데이터가 없으면 다른 데서 참조해 와야 할텐데, 이건 꽤 큰 낭비가 될 것 같다.

 

이래서 NoSQL 쓸 때는 "그냥 데이터 다 때려넣고 써!"라는 말들을 하시는 것 같다.

 

이렇게 모델 하나에 데이터를 다 때려넣으면 읽기에 최적화된 모델이 된다. 한 상황에서 한 aggregate만 읽으면 되기 때문에 JOIN 등이 필요 없어진다.

 

우아콘 대규모 트랜잭션을 처리하는 배민 주문시스템 규모에 따른 진화 영상을 보면 위와 같은 이유로 역정규화하고, 이를 통해 CQRS를 구현한 걸 볼 수 있다.

 

https://www.youtube.com/watch?v=704qQs6KoUk

 

 

참고로 영상 내용이 너무너무 좋으니 안 봤으면 꼭 보는 걸 추천하고, 나도 필요할 때마다 다시 돌려봐야겠다고 생각한다.

 

아무튼, 내 생각에도 가능한 데이터 다 때려넣고 가능한 참조할 일 없도록 만드는 게 더 좋은 것 같긴 하다. 비즈니스 요구사항이 어떻게 변할지도 모르고, 참조할 경우 데이터 일관성을 지키기 어려워지기 때문이다.

 

 

 

위 예시처럼, order과 customer를 분리하면 customer 입장에서는 order의 변경에 따라 쥐고 있는 order_id들에 대해 변경이 필요해질 수도 있을 것 같다.

 

이걸 보고 누군가가, 이건 애초에 모델이 잘못되었어요! 주문의 주체는 order가 아니라 customer기 때문에 DIP가 깨지는 구조니까 잘못 되었어요! 그러니까 order에 customer_id가 들어있으면 해결되는 문제에요! 라고 할 수도 있을 것 같다.

 

하지만 내 생각에는 customer가 order_id를 가지도록 설계할 수도 있을 것 같다. 갑자기 생각하려니 적절한 예시가 잘 떠오르진 않지만, 각 고객들의 어림잡은 주문 수를 알아야 하는 도메인이라던가 하면 customer가 order_id들을 가지는 게 충분히 이상하지 않은 모델이라고 생각된다.

 

No 스키마

NoSQL의 장점으로 스키마가 없다는 점을 꼽는 주장을 몇번 봤었는데, 그걸 볼때마다 들었던 생각은 '아니 어차피 그래도 코드에서 데이터를 읽고 다루려면 필드 값들을 알아야 할텐데 이게 왜 장점이지?' 이런 생각을 많이 했었다.

 

그러다가 나중에는 '아 스키마가 없으니 ALTER를 마음껏 할 수 있어서 좋은 건가?' 하는 생각으로 생각이 좀 바뀌었는데, 이 이유 때문에 스키마 없음이 장점이라고 하는 게 맞는건진 잘 모르겠다.

 

어쨌든 이 책에서도 스키마가 없음이 장점은 아니라고 말한다. 그 이유는 결국 스키마가 '애플리케이션'에 존재해야 하기 때문이라고 한다. 그래서 충분히 필요한 데이터들이 변경된 스키마로 채워질 때까지 버전에 따라 다른 데이터를 다룰 수 있도록 전환을 기다려야 하는데, 이를 점진적 전환이라고 부른다.

 

딱봐도 컨텍스트 공유가 안 되면 관리하기 엄청 복잡할 것 같다. 그냥 ALTER 치는 게 더 나아보일 수도 있을 것 같다... 또한 한 DB를 여러 애플리케이션에서 본다면, 각기 다른 애플리케이션에서 스키마 변경에 따라 모두 애플리케이션 스키마를 변경해야 한다.