Chapter 02. 데이터 모델과 질의 언어
데이터 모델은 아마도 소프트웨어 개발에서 제일 중요한 부분으로 - 소프트웨어가 어떻게 작성됐는지 뿐만 아니라, 해결하려는 문제를 어떻게 생각해야 하는지에 대해서도 지대한 영향을 미친다.
데이터 모델을 표현하는 방법 예시
- 애플리케이션 개발자: api 모델링
- 데이터 구조 저장시: XML, JSON, RDB 등등 이용
- 개발자는 데이터 어떻게 표현할지 결정
- 더 낮은 수준에서 하드웨어 엔지니어는 전류 빛의 파동 자기장의 관점에서 바이트 표현방법 알아냄
각 계층은 명확한 데이터 모델을 제공해 하위 계층의 복잡성을 숨긴다. 추상화를 통해 다른 그룹의 사람들이 효율적으로 함께 일할 수 있게끔 한다. 데이터 모델은 소프트웨어가 할수 있는일과 없는 일에 지대한 영향을 주므로 애플리케이션에 적합한 데이터 모델을 선택하는 작업은 상당히 중요하다. 이번 장에서는 관계형 모델 / 문서모델/ 몇가지 그래프 기반 데이터 모델을 비교하고, 다양한 질의언어도 비교한다.
관계형 모델과 문서 모델
SQL - 데이터는 관계로 구성되고, 각 관계는 순서없는 튜플 (SQL에서 로우) 모음이다. RDB의 근원은, 1960~1970년대에 메인프레임 컴퓨터에서 수행된 비즈니스 데이터 처리에 있고, 보통 트랜잭션 처리와 일괄처리 등에 사용되었다. 관계형 모델의 목표는 정리된 인터페이스 뒤로 구현 세부사항을 숨기는 것 이다. 수년 동안 여러 모델이 경쟁했고, 네트워크 모델과 계층모델이 주요 대안이었지만 관계형 모델이 우위를 차지했다. 그러면서 관계형 데이터베이스가 비즈니스 데이터 처리라는 본래 영역을 넘어 폭넓은 다양한 사용사례에도 보편화 되었다.
NoSQL의 탄생
NoSQL은 관계형 모델의 우위를 뒤집으려는 가장 최신 시도로, Not Only SQL로 재해셕된다. 채택이유로는 여러가지가 있는데
- 대규모 데이터셋이나 매우 높은 쓰기 처리량 달성을 쉽게 할 수 있는 뛰어난 확장성
- 오픈소스에 대한 선호도 확산
- RDB에서 지원하지 않는 특수 질의 동작
- RDB 스키마 제한에 대한 불만과 동적이고 표현력 풍부한 데이터 모델에 대한 바람
가까운 미래에는 RDB가 폭넓은 다양함을 가진 비관계형 데이터 스토어와 함께 사용될것 -> “polyglot persistence”
객체 관계형 불일치
오늘날 대부분 애플리케이션은 객체지향 언어로 개발하는데, 데이터를 RDB에 저장하려면 애플리케이션 코드와 데이터 베이스 모델 객체 사이에 전환계층이 필요하다. 이런 분리를 임피던스 불일치라고 부른다.
ORM 프레임워크를 통해 코드 양은 줄이지만, 두 모델간 차이를 완벽히 숨길 수는 없다. 예를들어 링크드인의 프로필데이터 -> 이력서 같은 데이터 구조는 모든 내용을 갖추고 있는 문서라 JSON 표현에 매우 적합하다. Document-oriented DB는 JSON 데이터 모델을 지원한다 (몽고DB, 카우치DB 등) 물론 데이터 부호화 형식으로써 JSON이 가진 문제도 있지만 이는 나중에 설명
JSON 표현은 더 나은 지역성을 가지며, RDB라면 다중 질의, 다중 조인을 수행해야 하는데 JSON 표현에서는 모든 관련 정보가 한 곳에 있어서 쿼리 하나로 충분하다.
다대일과 다대다 관계
몇가지 값은 ID로 저장되어 있는데 그 이유는 표준목록을 만들어 드롭다운 리스트나, 자동 완성 기능을 만들기 편리하기 떄문이다. 또한 중복의 문제로 ID를 사용하는 경우 - 의미있는 정보만 한 곳에 저장하고, 참조하는 모든것을 ID를 활용한다. 또한 ID 자체는 아무 의미가 없기 때문에 변경할 필요가 없고, 의미를 가지는 경우라면 언젠가는 변경해야 할 수도 있다.
중복된 데이터를 정규화하려면 다대일 관계가 필요한데 다데일 관계는 문서모델에 적합하지 않다. 관계형 데이터베이스는 조인이 쉬워서 다른 테이블참조가 일반적이지만, 문서 db는 조인에 대한 지원이 보통 약하다.
DB 자체가 조인을 지원하지 않으면 애플리케이션 코드에서 조인을 흉내내야 한다.
문서 데이터베이스는 역사를 반복하고 있나?
관계형 데이터베이스는 일상적으로 다대다 관계와 조인을 사용하지만 문서 데이터베이스와 NoSQL은 데이터베이스에서 다대다 관계를 표현하는 제일 좋은 방법에 대한 논쟁을 다시 열었다.
IMS 설계는 계층모델이라 부르는 상당히 간단한 데이터 모델을 사용했는데 이는 놀랍게도 JSON 모델과 비슷하다. 모든 데이터를 레코드 내에 중첩된 레코드 트리로 표현한다. IMS는 일대다 관계에서는 잘 동작하지만, 다대다 관계 표현은 어렵고 조인은 지원하지 않는다. -> 이는 오늘날 문서 데이터베이스 사용하는 개발자가 풀어야 할 문제와 비슷
계층 모델의 한계를 해결하기 위해 다양한 해결책이 제안되었고, 두가지로 관계형 모델과 네트워크 모델이 있다.
네트워크 모델
CODASYL 위원회에서 표준화 되었으며, 계층모델을 일반화한다. 계층모델의 트리 구조에서 모든 레코드는 정확하게 하나의 부모가 있고, 네트워크 모델에서 레코드는 다중 부모가 있을 수 있다. 코다실 모델은 다대일과 다대다 관계를 모델링 할 수 있다.
네트워크 모델에서 레코드간 연결은 포인터와 비슷한 방식으로 최상위 레코드부터 연속된 연결경로를 따라 탐색한다. (접근경로)
코다실의 질의는 레코드 목록을 반복해 접근 경로를 따라 커서를 움직여 수행한다. 제한된 하드웨어 성능을 가장 효율적으로 사용할 수 있었지만 데이터베이스 질의와 갱신을 위한 코드가 복잡하고 유연하지 못한 문제가 있었다.
관계형 모델
관계형모델이 하는 일은 알려진 모든 데이터를 배치하는 것 이다. 쿼리 옵티마이저는 질의의 어느 부분을 어떤 순서로 실행할지 결정하고 사용할 색인을 자동으로 결정한다 (-> 접근경로) 하지만 질의 최적화기가 이를 자동으로 만든다. 새로운 색인을 사용하기 위해 질의를 바꿀 필요가 없어서 관계형 모델은 새로운 기능을 추가하기가 훨씬 쉽다.
문서 데이터베이스와의 비교
문서 db는 별도 테이블이 아닌 상위 레코드내 중첩된 레코드를 저장한다. 다대일과 다대다 관계를 표현할때 관계형DB, 문서 DB 둘다 고유한 식별자로 관련 항목 참조한다. (각각 외래키, 문서 참조라 부른다)
관계형 데이터베이스와 오늘날의 문서 데이터 베이스
문서 데이터모델을 선호하는 주요 이유는 스키마 유연성, 지역성에 기인한 더 나은 성능 때문이다. 일부는 애플리케이션 데이터 구조와 더 비슷해서 이다. 관계형 모델은 조인, 다대일, 다대다 관계를 더 잘 지원함으로써 문서 데이터모델에 대항한다.
어떤 데이터 모델이 코드를 더 간단하게 할까?
애플리케이션에서 데이터가 문서와 비슷한 구조이면 문서 모델을 사용하는 것이좋다. 하지만 문서 내 중첩 항목을 바로 참조할 수 없고 조인 지원이 미흡하다. 애플리케이션에서 다대다 관계를 사용하는 경우 문서 모델은 매력이 떨어진다. 상호 연결이 많은 데이터의 경우 문서 모델 보다는 관계형 모델이 낫고, 그래프 모델이 제일 좋다.
문서 모델에서의 스키마 유연성
JSON은 문서의 데이터에 스키마를 강요하지 않는다. 스키마가 없다는 뜻은 임의의 키와 값을 문서에 추가할 수 있고, 읽을 떄 클라이언트 문서에 포함된 필드의 존재 여부를 보장하지 않는다는 의미이다.
- 쓰기 스키마(RDB) : 스키마는 명시적이고, DBMS는 데이터가 스키마를 따름을 보장
- 읽기 스키마(Document DB) : Data구조는 암묵적이고 읽을때만 해석된다.
질의를 위한 데이터 지역성
애플리케이션이 자주 전체 문서에 접근해야 할때 저장소 지역성을 이용하면 성능 이점이 있다.
문서 데이터베이스와 관계형 데이터베이스의 통합
대부분의 RDB는 2000년대 중반 이후 xml 지원한다. 또한 JSON 문서에 대해 비슷한 수준의 지원 기능을 제공한다. Document DB 쪽에서는 리싱크 DB는 질의 언어에 대한 관계형 조인을 지원하고, 몽고DB 드라이버는 자동으로 데이터베이스 참조를 확인한다. -> 즉 각 데이터 모델이 서로 부족한 부분 보완해나가고 있다.