NoSQL - 왜 NoSQL인가?

왜 NoSQL인가? §

NoSQL과 관계형 데이터베이스간의 비교를 통해, 왜 NoSQL이 대세가 되었는지 보여주고 있다.

관계형 데이터베이스의 가치 §

관계형 데이터베이스의 장점은 다음과 같다.

• 데이터 저장

데이터는 빠르지만 저장할 수 있는 양이 적은 ‘주 메모리’와, 크지만 느린 ‘보조 저장소’로 나눌 수 있다. 관계형 데이터베이스는 주로 보조 저장소로 이용한다.

• 동시성

트렌젝션을 통해 여러 사용자가 동시에 데이터를 읽고 쓰는 경우, 제대로 동작하게 할 수 있다.

• 통합

서로 다른 팀이 작성한 애플리케이션이, 동일한 저장소에 대해 읽고/쓸 수 있게 한다. 예를 들면 A팀에서 노드를 이용하여 작업하고, B팀에서 자바를 이용하여 작업할 때에도 같은 저장소에 읽고/쓸 수 있다.

관계형 데이터베이스는 위의 장점들을 가장 표준적인 방법으로 제공하여 성공했다. 그 결과, 개발자와 데이터베이스 전문가들은 관계형 모델을 배워, 자신의 프로젝트에 적용할 수 있었다. 그러나 장점이 있다면 단점도 있는 법

관계형 데이터베이스의 단점 §

객체-관계 불일치 §

관계형 모델과 메모리 내 데이터 구조가 불일치한다. 관계형 데이터 모델에서는 테이블과 행, 관계와 튜플로 데이터를 구조화한다. 여기서 튜플은 key-value값을 의미하고, 관계는 튜플의 집단이다.(예를 들면, 테이블)

SQL에서 모든 연산은 관계를 소비하고 반환하는데, 수학적으로 우아한 관계 대수로 설명할 수 있다. 반면에 단점도 존재한다.

• 튜플 안의 값은 단순해야 한다.

반드시 key-value의 단순한 값만 가능하며, 중첩된 레코드나 리스트가 value에 들어갈 수 없다. 반면에 메모리에 저장하는 객체는 훨씬 더 복잡한 구조를 취할 수 있어서, 그 구조를 관계형 데이터베이스에 걸맞는 key-value 구조로 변환해야 한다.

이제는 하이버네이트나 iBATIS같은 객체 - 관계 매핑 프레임워크가 사용되면서 위의 불일치는 조금 완화되었지만, 여전히 논쟁거리이다.

애플리케이션 데이터베이스와 통합 데이터베이스 §

• 관계형 데이터베이스가 객체 지향 데이터베이스를 이긴 이유는, 애플리케이션을 통합하는 방법으로서의 SQL 역할 때문이다.
  • 모든 애플리케이션이 일관된 데이터 집합을 가지고 동작하여, 커뮤니케이션이 향상됨
• 다만 불리한 점도 존재한다.
  • 애플리케이션마다 구조나 성능 조건이 다르다.
    • 어떤 애플리케이션에서는 인덱스가 필요하지만, 어떤 애플리케이션에서는 필요없다.
    • 데이터 정합성을 보존하는 방식으로 데이터를 갱신하는지 확인할 수 없다.
    • 따라서 데이터 정합성을 지키는 역할은 데이터베이스가 맡게 된다.
• 텍스트, 혹은 성능이 중요한 경우에는 바이너리를 이용하여 통신하는 애플리케이션 데이터베이스를 사용할 수도 있다.
  • 그러나 애플리케이션 데이터베이스로 완전히 넘어간 경우는 드물다.

클러스터의 공격 §

변화의 바람은 다른 측에서 찾아왔다. 닷컴 거품이 생기며, 웹의 규모가 극적으로 향상되었다. 웹의 규모가 향상되면서, 웹 사이트는 사용자 활동을 추적하고 구체적으로 구조화 할 필요가 생겼다. 즉, 데이터와 트레픽이 많아졌다.

데이터와 트레픽이 많아지면서, 더 많은 컴퓨팅 자원이 필요하게 되었다. 이는 수평 확장, 혹은 수직 확장을 통해 처리할 수 있었는데, 수직 확장(장비 크기를 키워 더 많은 프로세스, 디스크 스토리지, 메모리를 장착)은 실질적인 한계도 있고, 장비 비용도 어마어마하게 비싸진다.

반면 수평 확장은 작은 장비를 많이 모아 클러스터를 구성하는 것이다. 이는 비용이 적게 들고, 장비 한대가 실패해도 전체 클러스터가 중단 없이 동작할 수 있어 안정성이 높아진다.

여기서 관계형 데이터베이스의 문제점이 들어난다.

• 관계형 데이터베이스는 데이터 집합을 한 개의 하드디스크에 두는 경우가 많다. 물론, 관계형 데이터베이스도 샤딩을 통해 데이터 집합을 별도 서버에서 처리하게 할 수 있지만, 애플리케이션에서 모든 샤딩을 제어해야 한다.
• 여러 샤드에 걸치는 쿼리나 참조 적합성, 트랜잭션, 일관성 제어 같은 것을 사용할 수 없다.
• 라이센스 비용이 비싸다(클러스터에서 실행하면 라이센스 비용이 증가한다.)

관계형 데이터베이스와 클러스터 간의 부조화로, 데이터 저장을 위한 다른 대안을 고민하기 시작했다. 이런 흐름의 선두에 있던 것은 구글과 아마존으로, 2000년대가 끝날 무렵 두 회사는 구글의 빅 테이블과 아마존의 다이나모를 발표하게 된다.

NoSQL의 출현 §

빅 테이블과 다이나모의 출현은 여러 프로젝트에 영감을 주었다. 이를 통해 NoSQL이라는 모임이 발족하게 된다. NoSQL이라는 용어는 들불처럼 퍼져나갔지만, 정확하게 정의된 것은 없었다.

분명한 것은, 다음과 같다.

• NoSQL은 SQL을 사용하지 않는다. (일부 NoSQL에서 사용하는, 비슷한 것은 존재할 수 있다.)
• 보통 오픈 소스 프로젝트이다.
• 대부분 클러스터에서 실행할 목적으로 만들어졌다.
• 스키마 없이 동작하며, 구조에 대한 정의를 변경할 필요 없이 데이터베이스 레코드에 자유롭게 필드를 추가할 수 있다.

결론 §

• 관계형 데이터베이스를 완전히 대체할 수는 없다.
• 데이터의 성질을 살펴보고, 어떤 데이터베이스를 사용할지 결정할 수 있다.