데이터 중심 애플리케이션 설계 - 관계형 데이터베이스와 문서 데이터베이스

데이터 모델의 관점에서 관계형 데이터베이스와 문서 데이터베이스의 비교

• 애플리케이션의 데이터가 문서와 비슷한 구조일 경우 문서 데이터베이스를 사용하는 것이 좋다.
  • 문서를 여러 테이블에 찢어(shredding) 저장하는 것은 스키마와 애플리케이션 코드를 복잡하게 만든다.
• 문서 데이터베이스의 미흡한 조인은 때로는 문제일수도 아닐 수도 있다.
  • 다대다 관계를 사용하는 애플리케이션에서 문서 모델의 매력은 떨어진다.
    • 애플리케이션 코드에서 비정규화된 데이터의 일관성을 유지하기 위해 추가 작업을 해야 한다.
    • 애플리케이션 코드를 통해 조인을 흉내낼 수 있지만, 복잡도가 애플리케이션 레벨로 넘어가고 대게 데이터베이스에서 특화되어 수행되는 조인보다 느리다.

스키마 유연성

스키마가 없다는 것이 아니다. 암묵적인 스키마가 존재하지만, 데이터베이스는 이를 강요하지 않는다. 정확한 용어로는 쓰기 스키마와 반대되는 읽기 스키마이다.

• 쓰키 스키마 (schema-on-write)
  • RDBMS의 전통적인 방식. 스키마는 명시적이고 데이터베이스는 쓰여진 모든 데이터가 스키마를 따르고 있음을 보장
• 읽기 스키마 (schema-on-read)
  • 데이터 구조는 암묵적이고 데이터를 읽을 때만 해석된다.

두 방식의 차이는 데이터 타입을 변경하고자 할 때 명확하게 나타난다.

schema-on-read

if (user && !user.department) {
  user.department = "engineering";
}

새로운 필드 (department)를 가진 새로운 문서를 작성하기 시작하고, 애플리케이션에서는 예전 문서를 읽은 경우를 처리하는 코드만 있으면 된다.

schema-on-write

ALTER TABLE users ADD COLUMN department TEXT;
UPDATE users SET department = "engineering";

마이그레이션을 수행한다.

• 스키마 변경은 대게 느리고 중단시간이 필요하기 때문에 좋지 않다.

읽기 스키마 접근 방식은 컬렉션의 항목들이 동일한 구조가 아닐 때 유리하다. 이유는 아래와 같다.

• 다른 여러 유형의 오브젝트를 유형별로 테이블에 넣는 방법은 실용적이지 않다.
• 사용자가 제어할 수 없고 언제나 변경 가능한 외부 시스템에 의해 데이터 구조가 결정된다.

이러한 상황에서 스키마는 득보다 실이 많다. 스키마리스가 더 자연스러운 데이터모델이다. 하지만, 모든 데이터가 동일한 구조라면 스키마가 구조화를 강제할 수 있는 유용한 수단이다.

질의를 위한 데이터 지역성

• 웹페이지에 문서를 보여주는 것처럼 애플리케이션이 자주 문서 전체에 접근할 경우 storage locality를 사용하면 성능에 이점이 있다. 만약 문서가 여러 테이블에 나눠져있다면 문서 전체를 조회하기 위해 더 많은 시간이 소요된다.
• 지역성의 이점은 한 번에 해당 문서의 많은 부분을 필요로 하는 경우에만 적용된다.
  • 데이터베이스에서는 대게 문서의 작은 부분에만 접근해도 전체 문서를 적재해야 하기 때문에 큰 문서에서는 낭비일 수 있다.
  • 문서를 갱신할 때에도 전체를 재작성해야 한다.
  • 따라서 문서를 작게 유지하면서, 문서의 크기가 증가하는 쓰기를 피하는 것을 권장한다.
  • 이러한 성능 제한으로 데이터 베이스가 유용하게 사용될 수 있는 상황이 많이 줄어든다.

 

출처 - 데이터 중심 애플리케이션 설계