SQL 모델과 NOSQL 모델의 선택 방법

 

 

내 언어의 한계는 내 세계의 한계를 의미한다. -루티비히 비트겐슈타인-

데이터 모델은 해결하려는 문제를 어떻게 생각하는 지에 대해 영향을 미친다.

 

관계형 데이터 베이스 (SQL)모델과 문서형 데이터베이스 (NOSQL)모델 중에 어떤 것이 자신의 애플리케이션과 적합할까?

또는 더 적합한 모델이 있을까?

 

이번 게시글에선는 데이터 중심 애플리케이션 설계 서적(마틴 클레프만 저)을 읽으면서 알게된 모델 선택방법에 대해 정리해보려한다.

 

관계형 (SQL)모델

 

관계형 모델은 테이블간에 관계를 가진다.

이는 1960~70년대에 비즈니스 데이터 처리와 함께 발전했다.

관계형 데이터 베이스는 항공 예약이나 재고 처리, 은행 거래와 같은 트랜젝션 처리처럼 일상적으로 수행되는 일들에 적합했고, 현재는 관계형 데이터베이스는 비즈니스 데이터 처리의 영역을 넘어 폭 넓게  자리잡고 있다.

 

 

 

문서형 (NOSQL)모델

 

NoSQL은 2010년대에 등장한 관계형 모델의 경쟁자이다.

뛰어난 확장성과 오픈 소스, 특수 질의, 풍부한 표현력이 장점이다.

 

관계형 모델은 스프링을 해보면 알겠지만, 임피던스 불일치가 문제가 된다.

따라서 실제 애플리케이션 코드와 데이터 베이스 모델 객체 사이에 전환 계층이 필요하다.

스프링은 하이버네이트와 같은  ORM 프레임워크를 통해 해소하려하지만, 여전히  불편하다.

 

예를 들어 SQL은 이력서라는 테이블에서 직업이라는 한개의 컬럼이 여러가지 값을 가질 수 없기 때문에 다른 테이블을 만들어 참조시켜야한다.

이를 위해 xml을 도입하였지만, 사실 여러 값을 가지는 문서를 표현하는데는 JSON이 가장 강력하다.

따라서 여러개의 테이블에서 join과 같은 번거로운 작업 없이 한번에 질의로 가져올 수 있다.

단, 다대다 관계가 많으면 문서 모델은 적절하지 않을 수 있다.

 

데이터를 ID로 표현하는 이유는 데이터가 변경되어도 ID는 의미가 없기 때문에 변경이 필요없기 때문이다.

ID를 의미가 있는 데이터로 표현하면 언젠가는 변경할 필요가 있을 수 있다.

 

문서 데이터 모델을 선호하는 경우, 스키마의 유연성과 지역성으로의 더 나은 성능, 실제 사용하는 객체 데이터 구조와 가깝기 때문이다.

관계형 모델은 조인, 다대일, 다대다 관계를 더 잘 지원하므로 그만의 장점이 있다.

 

 

그럼 어떤게 좋다는 건가?

 

그렇다면 어떤것이 애플리케이션의 코드를 더 간단하게 해줄까?

이에 대해서는 애플리케이션 데이터가 문서와 구조가 비슷하기 때문에 문서 모델이다.

관계형 데이터는 문서와 같은 구조를 여러가지 테이블로 나누어 찢기 때문에 불필요하게 복잡한 코드를 만들어낸다.

 

하지만 문서형은 미흡한 JOIN 지원때문에 어떤 애플리케이션이냐에 따라서는 적절하지 않을 수 있다.

특히 다대다 관계가 필요하다면 문서형에서 이를 흉내낼 경우 굉장히 복잡해질 수 있다.

 

문서형은 스키마를 강제하지 않기때문에 스키마리스(Schemaless)라고도 불린다.

문서형에서는 기존의 데이터로 새로운 데이터 필드를 바로 만들면되지만,(read-schema)

관계형처럼 정적 타입인 경우 마이크레이션을 진행해야한다.(write-schema)

따라서 정적인 타입이 정해지지 않고 여러 오브젝트를 저장하고 싶다면 문서형이 적합하다.

 

사실 관계 형 데이터 베이스들이 JSON문서에대한 지원 기능을 추가하고 있기 때문에, 관계형과 문서형의 혼합 모델이 데이터베이스들이 나아가고 있는길이다.

 

MongoDB와 같은 NOSQL은 빅데이터 처리에도 많이 사용되는데 그 이유는 맵리듀스를 지원하기 때문이다.

맵리듀스는 대량의 데이터 처리에 특화되었다. MongoDB와 같은 일부 NoSQL에서 제한적으로 지원한다.

이러한 함수는 pure해야한다.(부수 효과가 없어야 함.)

또한 MongoDB는 집계파이프라인(Aggregation Pipeline)이라는 효과적인 선언형 질의 언어를 추가했다.

 

결과적으로

일대다 관계, 레코드간 관계가 없다면 문서 모델이 적합.

다대다 관계와 레코드간의 관계가 여럿 존재한다면 관계형 모델이 적합하다.

 

 

그래프 모델

 

그런데 반대로 다대다가 너무 많으면 그래프 모델링이 적절하다.

 

페이스북은 데이터를 소셜 그래프로 저장한다.

정점은 사람, 장소, 이벤트 등이 될 수 있고, 간선은 누가 코멘트를 달았는지, 어떤 위치에서 체크인을 했는지 등을 나나낸다.

그래프 모델들은 단일 그래프에서도 정점과 간선을 여러가지 타입으로 저장할 수 있다.

그러므로 발전성이 좋아 기능 추가 시에도 그래프를 쉽게 확장할 수 있다.

 

이러한 속성 그래프 모델은 사이퍼 질의를 통해 데이터베이스에 선언형 질의를 할 수 있다.

관계형에도 그래프 데이터를 넣을 수 있지만 사이퍼 질의에 비해서 굉장히 질의가 복잡해진다.

즉, 서로 다른 데이터 모델들은 서로 다른 사용 사례를 위해 설계되었다. 

따라서 애플리케이션에 따라 적합한 모델을 선택해야한다.

 

 

트리플 저장소 모델

 

트리플 저장소는 모든 정보를 주어, 서술어, 목적어인 세 부분 구문 형식으로 저장한다.

[나, 좋아하다, 예술]과 같은 것이다.

목적어는 속성이나 주어처럼 정점이 될 수 있다.

 

데이터로그는 서술어(주어, 목적어)로 좀더 일반화 시켰다.

하둡에서는 데이터로그의 구현체로 캐스캘로그를 사용하여 대용량 데이터셋에 질의를 한다.

 

 

 

결론

 

데이터 모델들은 서로 다른 사용 사례를 위해 설계되었다.

따라서 어떤 애플리케이션이냐에 따라 적합한 모델을 선택해야한다.

 

즉, 데이터베이스 모델에 "은탄환은 없다."

 

 

 

참고 서적

https://search.shopping.naver.com/book/catalog/32466573690?cat_id=50010586&frm=PBOKPRO&query=%EB%8D%B0%EC%9D%B4%ED%84%B0+%EC%A4%91%EC%8B%AC+%EC%95%A0%ED%94%8C%EB%A6%AC%EC%BC%80%EC%9D%B4%EC%85%98+%EC%84%A4%EA%B3%84&NaPm=ct%3Dljr32yhc%7Cci%3D98a713f7b3b8c00459cb0d23849a3ee2ede04558%7Ctr%3Dboknx%7Csn%3D95694%7Chk%3D050414cfaf4c3f6669fead301901feef1e8e385e

데이터 중심 애플리케이션 설계 : 네이버 도서