책너두 (데이터 중심 애플리케이션 설계) 4일차 (~49p)

요약

• 문서 데이터베이스의 역사에 대해 알게 됨.
  • 다대다 관계 처리를 위한 여러 모델이 나옴.
    • 계층 모델
    • 네트워크 모델
    • 관계형 모델
• 관계형 데이터베이스와 문서 데이터베이스의 차이를 알게 됨
  • 문서로 표현하기 쉬운 데이터 → 문서 데이터 베이스
    • 스키마 유연성을 가지기 쉬움 (읽기 스키마 → 데이터 구조가 달라도 됨)
  • 다대다 관계 → 관계형 데이터베이스
    • 조인, 다대일, 다대다 관계를 지원
  • 데이터 지역성
    • 문서 : 저장소 지역성 이용
      • 문서의 많은 부분이 필요한 경우에만 사용
    • 관계 : 데이터 그룹화
• 문서와 관계형 데이터베이스는 서로의 단점을 보완하는 형태로 발전 중임
• 데이터를 위한 질의 언어에 대한 내용을 알게 됨
  • 선언형 (SQL)
    • 웹에서 CSS Selected 로 유용하게 사용 가능
  • 명령형 (프로그래밍 언어)
    • 절차, 방법에 대한 내용
    • 경우에 따라 선언형보다 훨씬 복잡한 형태로 표현될 수 있음.

발췌

• 문서 모델의 경우 문서의 작은 부분에만 접근해도 전체 문서를 적재해야 하므로 문서를 아주 작게 유지하면서 문서의 크기가 증가하는 쓰기를 피하라고 권장함 (p41.)
• 관계형과 문서의 혼합 모델은 미래 데이터베이스들이 가야할 올바른 길임.(p42)

메모

문서 데이터베이스는 역사를 반복하고 있나?

• 다대다 관계
  • 관계형 데이터베이스는 조인을 통해 다대가 관계를 관리
  • NoSQL은 다대다 관계를 표현하는 제일 좋은 방법
  → 위와 같은 논쟁이 오래동안 이루어지고 있음.
• IBM의 정보 관리 시스템(Information Management Sstem, IMS) (1970)
  • IMS 설계는 계층 모델이라 불림 (간단한 데이터 모델)
  • 이 계층 모델은 문서 데이터베이스에서 사용하는 JSON 모델과 비슷함.
  • 이 계층 모델은 일대다 관계에서 잘 동작하지만, 다대다 관계표현은 어려움.
  • 이 계층 모델의 한계를 해결하기 위해 해결책 두 가지가 있었음.
    1. 관계형 모델(SQL)
    2. 네트워크 모델(지금은 거의 잊혀짐)
    → 두 진영간의 대 논쟁이 1970년대 대부분 동안 지속됨

네트워크 모델

• 코다실(Conference on Data Systems Languages, CODASYL) 이라 불리는 위원회에서 표준화됨.
• 여러 데이터베이스 벤더가 네트워크 모델을 구현함 (코다실 모델이라고 부름)
• 코다실 모델은 계층 모델을 일반화함.
  • 트리 구조 → 모든 레코드는 정확하게 하나의 부모가 잇음.
  • 네트워크 모델에서 레코드 간 연결은 외래 키 보다는 프로그래밍 언어의 포인터와 더 비슷함.
  • 레코드에 접근하려면 최상위 레코드에서 연속된 연결 경로를 따라야 함(=접근 경로)
• 코다실의 질의는 레코드 목록을 반복해서 접근 경로를 따라 테이베이스 끝에서 끝까지 커서를 움직여 수행한다.
  • 만약, 레코드가 다중 부모를 가진다면, 다양한 관계를 모두 추적해야 함.
  • 따라서 수동 접근 경로를 선택하면 제한된 하드웨어 성능을 가장 효율적으로 사용할 수 있음.
    • 하지만, 애플리케이션 코드를 수작업으로 살펴봐야함.
    • 애플리케이션에서 데이터 모델을 바꾸는 작업은 매우 어려운 일임

관계형 모델

• 모든 데이터를 배치함
• 관계(테이블)는 단순히 튜플(로우)의 컬렉션이 전부임.
  • 얽히고 설킨 중첩구조에 대한 복잡한 접근 경로가 없음.
  • 관계형 데이터베이스의 최적화기 (query optimizer)가 질의어를 어떤 순서로 실행하고 사용할 색인을 자동으로 결정한다.
    • 이 자체가 접근 경로지만, 애플리케이션 개발자가 아니라 질의 최적화기가 자동으로 만들어줌.

문서 데이터베이스와의 비교

• 문서 데이터베이스는 일대다 관계 관점에서 계층 모델의 한 가지 측면을 가진다.
• 하지만 다대일, 다대다 관계 표현시는 계층 모델과 다름
  • 관계형 데이터베이스와 문서 데이터베이스가 근본적으로 다르지 않음.
    • 관계형 모델에서는 외래 키라 부름
    • 문서 모델에서는 문서 참조(document reference) 라고 부름.
    • 이 식별자를 이용하여 조인이나 후속 질의를 사용하여 읽기 시점에 확인한다.

관계형 데이터베이스와 오늘날의 문서 데이터베이스

• 관계형 데이터베이스 vs 문서 데이터베이스
  • 내결함성, 동시성 처리를 포함하여 고려할 점이 많음.
• 문서 데이터 모델 선호 이유
  • 스키마 유연성
  • 지역성에 따른 더 나은 성능
  • 일부 애플리케이션은, 애플리케이션에서 사용하는 데이터 구조와 가까움
• 관계형 모델 선호 이유
  • 조인, 다대일, 다대다 관계를 더 잘 지원함.

어떤 데이터 모델이 애플리케이션 코드를 더 간단하게 할까?

• 애플리케이션에서의 데이터와 문서와 비슷한 구조라면 문서 모델을 사용하는게 좋음.
  • 문서와 비슷한 구조를 여러 테이블로 나누어 찢는(shredding) 관계형 기법은 스키마를 다루기 힘들게 하고, 복잡한 애플리케이션 코드를 발생시킴.
• 문서내에 중첩 항목이 있을 경우, 해당 항목을 바로 참조할 수 없는 제한이 있음.
  • 문서가 너무 깊게 중첩되지 않으면 일반적으로 문제가 되진 않음.
• 만약 애플리케이션이 다대다 관계를 사용한다면 문서 모델은 매력이 떨어짐.
  • 비정규화로 조인의 필요성 줄이기가 가능하지만 애플리케이션 코드는 비정규화된 데이터의 일관성을 유지하기 위해 추가 작업을 해야 함.
  • 문서 모델은 조인을 지원하지 않기에, 애플리케이션 코드로 조인을 흉내내야하는데, 관계형 데이터베이스의 특화된 코드로 수행되는 조인보다 느림.
• 결론 : 애플리케이션에서 쓰는 데이터 모델의 형태에 따라 문서 혹은 관계형 모델 둘중 적합한 모델이 있을 수 있고, 나에게 맞는 모델을 선택하면 된다.

문서 모델에서의 스키마 유연성

• 문서 데이터베이스와 관계형 데이터베이스에서 지원하는 JSON은 문서의 데이터에 어떤 스키마를 강요하지 않음.
  • 스키마가 없다 = 임의의 키와 값을 문서에 추가할 수 있음. + 읽을 때 클라이언트는 문서에 포함된 필드의 존재 여부를 보장하지 않음.
• 문서 데이터베이스를 종종 스키마리스(schemaless) 라고 부르기도 함. → 오해의 소지가 있음.
  • 데이터를 읽는 코드는 보통, 구조의 유형을 어느 정도 가정함.
  • 즉, 암묵적인 스키마가 있지만, 데이터베이스가 이를 강요하지는 않음. (= 읽기 스키마)
    • 쓰기 스키마(schema-on-write) → 관계형 데이터베이스의 전통적인 접근 방식 (모든 데이터가 스키마를 따름)
      • 정적 타입 확인과 비슷(컴파일 타임)
    • 읽기 스키마(schema-on-read) → 데이터 구조는 암묵적이며, 데이터를 읽을 때만 해석
      • 동적 타입 확인과 비슷(런타임)
• 문서 모델과 관계형 모델은 위와 같은 접근 방식의 차이가 있고, 특히, 데이터 타입을 변경하고자할 때 뚜렷하게 그 차이가 나타남.
  • ex) 하나의 필드에 이름을 저장하고 있는데, 성과 이름으로 분리해서 저장할 경우
  • 문서 : 읽기 후, 성, 이름이 없는 경우 새롭게 넣어준다.
  • 관계형 : 마이그레이션(migration) 수행 or 문서 모델과 같이 읽을때마다 채워주기
• 읽기 스키마 접근 방식은 컬렉션 안의 항목이 동일한 구조가 아닐 때 유리함. 그이유는 아래와 같음.
  • 다른 여러 유형의 오브젝트가 있다면, 그 오브젝트를 자체 테이블에 넣는 방법을 실용적이지 않음.
  • 변경 가능한 외부 시스템에 대해서 데이터 구조가 결정됨.
    • 이 상황에서 스키마의 사용은 득보다 실이 더 많음.
• 하지만, 레코드가 동일한 구조이고, 예상이 가능하다면 스키마가 유용한 메커니즘이 된다.

질의를 위한 데이터 지역성

• 문서는 JSON, XML로 부호화된 단일 연속 문자열이나 JSON 또는 XML의 이진 변형으로 저장됨.
• 웹 페이지 상의 문서를 보여주는 동작처럼 애플리케이션이 자주 전체 문서에 접근해야 할 때, 저장소 지역성(storage locality)을 활용하면 성능 이점이 있음.
  • 이 지역성은 한 번에 해당 문서의 많은 부분을 필요로 하는 경우에만 적용됨.
    • 왜냐면 문서 모델은 문서의 작은 부분에만 접근해도 전체 문서를 적재해야 하므로 큰 문서에서는 낭비일 수 있음.
    • 이러한 이유로, 문서를 아주 작게 유지하면서 문서의 크기가 증가하는 쓰기를 피하라고 권장함.
    → 이 떄문에 문서 데이터베이스가 유용한 상황이 많이 줄어듦.
• 관계형 모델에도 지역성을 위한 데이터를 함꼐 그룹화함.
  • ex) 구글 스패너 데이터베이스
  • 오라클의 다중 테이블 색인 클러스터 테이블(muti-table index cluster table)
  • 빅테이블 데이터 모델의 칼럼 패밀리(column-family) → 카산드라, HBase 에서 사용

문서 데이터베이스와 관계형 데이터베이스의 통합

• 관계형 데이터베이스는 XML 문서를 지원하고 있음 (MySQL 제외)
  • XML 문서의 지역적 수정 &문서 내부 색인 및 질의 기능을 포함함.
• 문서 데이터베이스의 경우, 리싱크 DB는 질의 언어에서 관계형 조인을 지원함. 몽고 DB 드라이버는 자동으로 데이터베이스 참조를 확인함. (실제로는 클라이언트 측에서 조인을 수행함 → 네트워크 왕복이 추가로 필요하고 최적화가 덜 되기 때문에 관계형 데이터베이스의 조인보다는 느릴 수 있음.)
• 서로 비슷해지고 있는 것은 긍정적 상황임.
  • 서로의 부족한 부분을 보완해 나가고 있기 때문

데이터를 위한 질의 언어

• 선언형 질의 언어(ex: SQL)
  • 목표를 달성하기 위한 방법이 아니라, 알고자 하는 데이터의 패턴, 데이터를 어떻게 변환할지를 지정
  • 명령형 API 보다 간결하고 쉽게 작업 가능
    • 특히, 데이터베이스 엔진의 상세 구현이 숨겨져 있어서 질의를 변경하지 않아도 데이터베이스 시스템 성능을 향상시킬 수 있음.
    • 즉, SQL이 기능적으로 더 제한적으로 보일 지라도 사실 데이터베이스에게 자동으로 최적화할 수 있는 여지를 더 많이 줌.
  • 종종 병렬 실행에 적합함.
    • 결과의 패턴만 지정하므로 병렬 실행으로 더 빨라질 가능성이 큼
• 명령형 질의 언어(ex: IMS, 코다실, 프로그래밍 언어)
  • 특정 순서로 특정 연산을 수행하게끔 컴퓨터에 지시 (목표를 달성하기 위한 방법임)
  • 만약 데이터베이스 내부에서 최적화를 위해 데이터 순서가 바뀌면 코드가 순서에 의존할 경우, 문제가 될 수 있음.
  • 명령어를 특정 순서로 실행하기에 다중 코어나 다중 장비에서 병렬 처리가 힘듦.

웹에서의 선언형 질의

• 선언형 질의 언어는 데이터베이스에만 국한되지 않음.
  • ex) CSS 의 선택자에 의해 엘리먼트의 패턴을 선언할 수 있음.
  • 만약 명령형 접근 방식을 사용할 경우, 자바 스크립트에서 코어 DOM(Document Object Model) API를 사용해야 함.
    • CSS 의 선택자로는 단순히 엘리먼트만 지정해주면 패턴이 정해졌는데, 명령형 접근을 했떠니 코드량이 엄청 많아짐.
    • CSS, XSL 보다 이해하는데 더 오래 걸리고, 심각한 문제까지 있음. (p46 예시 참고)
• 따라서, 웹 브라우저에서는 선언형 CSS 스타일을 사용하는 것이 자바스크립트에서 명령형 스타일을 다루는 것보다 훨씬 나음.