왜 NoSQL인가 ?

‘빅데이터 세상으로 떠나는 간결한 안내서 NoSQL’를 읽고 정리하고자함

요점 정리

  • 관계형 데이터베이스는 20년 이상 성공적인 기술이며, 지속성, 동시성 제어, 통합 매커니즘을 제공함
  • 애플리케이션 개발자는 관계형 모델과 데이터 내 데이터 구조간의 객체-관계 불일치로 불만이 많았음
  • 데이터베이스를 통합점으로 사용하는 방식에서 데이터베이스를 애플리케이션 안에 캡슐화하고 서비스를 통해 통합하는 방식으로 이동하려는 움직이 있음
  • 데이터 저장소의 변화의 중요한 요인은, 클러스터에서 실행되는 엄청난 양의 데이터를 지원해야한다는 점으로, 관계형 데이터베이스는 클러스터에서 효율적으로 동작하도록 설계되어 있지않음
  • NoSQL은 공통 특징이 있음
    1. 관계형 모델을 사용하지 않음
    2. 클러스터에서 잘 작동함
    3. 오픈 소스이며, 21세기 웹 환경을 위해 구축되었음
    4. 스키마가 없다
  • NoSQL 등장의 가장 큰 결과는 다중 저장소의 지속성임, 즉 관계형 데이터베이스가 저장 방식의 한가지 일뿐.

1. 관계형 데이터베이스의 가치

장점

  1. 데이터 저장
    • 데이터베이스의 가장 명확한 가치는 ‘많은 양의 데이터를 보관’ 하는 것
    • 컴퓨터 아키텍쳐에서 두 종료의 저장 장치 개념이 있음
      1. 메모리 - 크기 제한이 있고 특정 문제가 생기면 모든 데이터를 잃어버림
      2. 보조 저장소 (디스크)
    • 보조 저장소는 ‘파일시스템’,’데이터베이스’ 등 어떤 것으로도 구성할 수 있음
    • 데이터베이스는 파일시스템보다 많은 양의 데이터를 저장할 때 융통성을 제공하므로, 애플리케이션에서 필요한 정보를 빠르고 쉽게 얻을 수 있음
  2. 동시성
    • 애플리케이션에서는 많은 사람이 동시에 같은 데이터를 보고 수정할 수 있음
    • 관계형 데이터베이스는 트랙잭션 통해 데이터에 대한 모든 접근을 통제해 동시성 문제를 처리함
    • 트랙잭션은 오류처리 역할도 가능한데, 뭔가 수정하다 오류가 발생한 경우 롤백해 데이터 정리할 수 있음
  3. 통합
    • 여러 애플리케이션이 한개의 데이터베이스에 데이터 저장하도록 하는 ‘통합 데이터베이스 공유’방식을 사용할 수 있음
    • 이렇게 되면, 모든 애플리케이션이 다른 애플리케이션의 데이터에 쉽게 접근할 수 있으며, 데이터베이스의 동시성 제어 기능을 통해 한 애플리케이션에서 여러 사용자를 처리하는 것과 같은 방법으로 여러 애플리케이션 처리 가능
  4. 표준모델
    • 위의 3가지 장점을 표준적인 방법으로 제공, 즉 벤더가 달라도 SQL구뭉느 거의 비슷하고 transacion 동작도 큰 차이가 없음

불만 및 단점

  1. 애플리케이션 개발자가 느끼는 ‘객체-관계 불일치’, 즉 관계형 모델과 메모리 내 데이터 구조 간의 차이
    • 관계형 데이터 모델은 테이블, 행, 관계와 튜플로 데이터를 구조화함
      • 튜플 ? 이름-값 쌍의 집합
      • 관계 ? 튜플의 집합
    • 관계형 튜플 안의 값은 단순, 중첩된 레코드나 리스트 등 다른 구조를 포함 할 수 없음
    • 하지만, 메모리내, 어플리케이션 내에서는 데이터 구조에 대한 제약이 없어 훨씬 복잡한 구조를 다룰 수 있으며, 그 결과 복잡한 메모리 내 구조를 데이터베이스에 저장 하려면 먼저 관계형 표현으로 변환해야함
    • 이 문제를 해결하고자 ORM, 객체-관계 매핑 프레임워크가 널리 사용되면서 지겨운 작업은 많이 줄어들었지만, 데이터베이스나 쿼리 성능 같은 것을 무시하면 다른 문제가 생길 수 있음

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

통합 데이터베이스

  • 장점
    1. 여러 팀에서 다양한 애플리케이션을 개발했고, 공통 데이터베이스에 저장함
    2. 모든 애플리케이션이 일관된 데이터 집합을 가지고 동작해 커뮤니케이션이 향상함
  • 단점
    1. 여러 애플리케이션을 통합하려고 설계한 구조는 단일 애플리케이션에서 필요한 구조보다 더 복잡해짐
    2. 특정 애플리케이션의 요구사항으로 데이터 저장소를 변경하고 싶을 경우, 데이터베이스를 사용하는 다른 애플리케이션과의 조율이 필요함
      • 인덱스 설계 등등,
    3. 각 애플리케이션은 다른 팀에서 만들기 때문에 모든 애플리케이션의 데이터 적합성을 보장하는 방식으로 데이터를 갱신하는지 확신할 수 없음
    4. 따라서, 데이터 적합성 보장의 책임은 데이터베이스 자체가 책임져야하는 상황이 발생함

애플리케이션 데이터베이스

  • 단일 팀이 관리하는 단일 애플리케이션만 직접 접근하는 방법
    • 사용하는 팀만 데이터베이스 구조를 알면 되므로, 스키마 유지보수가 쉬움
    • 데이터 적합성 보장에 대한 책임을 애플리케이션 코드내에서 처리할 수 있음
  • 통합 데이터베이스를 사용할 계획이라면, HTTP REST api로 사용하는 것이 좋음
  • 저자는 애플리케이션 데이터베이스를 사용하면 데이터베이스의 융통성 이외에 많은 장점을 얻을 수 있으몰, 보통 애플리케이션 데이터베이스를 권장한다고함

3. 클러스터의 공격

  • 데이터와 트래픽이 증가하면서 더 많은 컴퓨팅 자원이 필요해짐
  • 이런 증가를 처리하는 두가지 방법이 있음
  1. 수직 확장 (scale-up)
    • 더 큰 장비에 더 많은 프로세서와 디스크, 메모리르 장착하는법
    • 장비 크기와 성능을 키우는 것은 한계가 있고, 장비가격도 엄청 비싸짐
  2. 수평 확장 (scale-out)
    • 작은 장비를 많이 모아 클러스터를 구성
    • 저가 하드웨어로 구축할 수 있으모, 바용이 적게 들고, 장비가 한 대가 실패하더라도 클러스터 전체는 중단 없이 서비스하도록 구축할 수 있음
    • 높은 가용성을 제공
  • 이렇게 수평확장을 통한 서비스가 클러스터로 이동함에 따라 새로운 문제가 발생함
    • 관계형 데이터베이스는 클러스터에서 동작하도록 설계되어있지 않음
      • 오라클 RAC, 마이크로소프트 SQL 서버 같은 클러스터 관계형 데이터베이스는 공유 디스크 개념을 사용함
      • 하지만 파일 시스템을 사용해 고가용성 디스크 서브시스템에 데이터를 기록하는데, 이는 디스크 서브시스템이 SPOF
      • 물론, 관계형 데이터베이스에서 샤딩하여, 부하를 분산할 수 있지만, 애플리케이션에서 모든 샤딩을 제어해야힘
      • 즉, 어떤 데이터가 어느 데이터베이스 서버에서 처리해야하는지 애플리케이션에서 파악해야한다는 것
      • 또 여러 샤드에 걸치는 쿼리나, 참조 정합성, 트랙잭션, 일관성 제어 등의 어려움이 수반되는 상황이 발생함
  • 그래서 관계형 데이터베이스와 클러스터 환경에서의 부조화로, 구글의 BigTable, 아마존의 DynamoDB가 등장함
  • 클러스터 세상에 맞는 데이터베이스를 만들기를 탐구하기 시작

4. NoSQL의 출현

  • NoSQL 데이터베이스는 대부분 클러스터 환경에서 실행할 목적으로 만들어졌음
    • 모든 NoSQL이 클러스터에 실행되도록 맞춰지지는 않음
    • 그래프 데이터베이스는 NoSQL의 한가지 형태이지만, 관계형 데이터베이스와 비슷한 분산 모델을 사용하지만 복잡한 관계의 데이터 처리에 유리한 다른 데이터모델을 사용함
  • 관계형 데이터베이스는 데이터베이스 전반에 걸쳐 일관성을 유지하려고 ACID 트랙재션을 사용함

  • 하지만, 클러스터 환경과 본질적으로 맞지 않아 NoSQL 데이터베이스는 ‘일관성’과 ‘분산’ 에 대한 여러 종류의 선택사양을 제공

  • NoSQL은 스키마 없이 동작하며, 구조에 대한 정의를 변경할 필요없이 데이터베이스 레코드에 자유롭게 필드를 추가할 수 있음
  • NoSQL은 기술이라기보다는 동향으로 보는 것이 옳으며, 관계형 데이터베이스가 사라지지 않을 것
  • 이제는 관계형 데이터베이스를 데이터 저장소에 대한 한가지 선택사항으로 생각할 수 이으며, 이런 관점에서 ‘다중 저장소 지속성(polyglot persistent)’라고 부름
    • 즉, 상황에 따라 다른 데이터 저장소를 선택해야한다는 것
    • 우리가 저장하는 데이터의 본질이 무엇인지, 이 데이터를 어떻게 조작하고 싶은지 이해햐함

  • 통합 데이터베이스에서 애플리케이션 데이터베이스로 이동해야하는것이 저자의 관점

  • NoSQL를 고려하는 데는 두가지 주요 이유
    1. 클러스터가 필요한 규모의 데이터 크기와 성능 요건 하에서의 데이터 접근 처리
    2. 좀 더 편리한 데이터 조장 방식을 통한 애플리케이션 개발 생산성