데이터 중심의 애플리케이션 설계 - 데이터 모델
데이터 모델은 소프트웨어 개발에서 가장 중요하다. 소프트웨어가 작성되는 방식뿐만 아니라 해결하려는 문제를 생각하는 방식에도 영향을 미치기 때문이다.
복잡한 애플리케이션은 API를 기반으로 구축된 API를 갖는다. 이처럼 데이터 모델은 각 계층이 아래 계층의 복잡성을 숨긴다. 이러한 추상화를 통해 다양한 그룹의 사람들이 효과적으로 협업할 수 있다.
데이터 모델은 그 위에 있는 소프트웨어가 할 수 있는 일과 할 수 없는 일에 큰 영향을 미치므로, 애플리케이션에 적합한 데이터 모델을 선택하는 것이 중요하다.
관계형 모델과 도큐먼트 모델 비교
오늘날 가장 잘 알려진 데이터 모델은 1970년 에드가 코드가 제안한 관계형 모델에 기반한 SQL이다. 데이터는 관계(SQL에서는 테이블이라고 함)로 구성되며, 각 관계는 정렬되지 않은 튜플(SQL에서는 행, row)의 집합이다. 초기에 관계형 모델은 이론으로만 제안되었기에, 당시 많은 사람들이 이 모델이 효율적으로 구현될 수 있을지 의구심을 가졌다. 하지만, 1980년대 중반에 이르러 관계형 데이터베이스 관리 시스템(RDBMS)과 SQL은 규칙적인 구조로 데이터를 저장하고 쿼리해야 하는 대부분의 사람들이 선택하는 도구가 되었다. 관계형 데이터베이스의 지배는 약 25~30년 동안 지속되었다.
관계형 모델의 목표는 이러한 구현 세부 사항을 깔끔한 인터페이스 뒤에 숨기는 것이었다 수년에 걸쳐 관계형 모델의 여러 대안들이 있었다.
- 1970년대와 1980년대 초에는 네트워크 모델과 계층적 모델이 주요 대안이었다.
- 1980년대 말과 1990년대 초에 등장한 객체 데이터베이스는 등장했다가 사라졌다.
- XML 데이터베이스는 2000년대 초반에 등장했지만 일부 영역에서만 채택되었다.
컴퓨터가 훨씬 더 강력해지고 네트워크화되면서 컴퓨터는 점점 더 다양한 용도로 사용되기 시작했다. 관계형 데이터베이스는 원래의 비즈니스 데이터 처리 범위를 넘어 다양한 사용 사례가 되었다. 온라인 게시, 토론, 소셜 네트워킹, 전자상거래, 게임, 서비스형 소프트웨어 생산성 애플리케이션 등 오늘날 웹에서 볼 수 있는 많은 것들이 여전히 관계형 데이터베이스를 기반으로 하고 있다.
NoSQL의 탄생
2010년대 들어 관계형 모델의 지배를 뒤엎으려는 최근의 시도가 바로 NoSQL이다. 사실 “NoSQL”이라는 이름은 특정 기술을 지칭하는 것이 아니다. 2009년 오픈 소스, 분산형 비관계형 데이터베이스의 트위터 해시태그로 사용되었고, 현재 이 해시태그는 “Not Only SQL”로 재해석되었다.
다음의 사항들이 NoSQL 데이터베이스를 채택하게 된 이유다:
- 매우 큰 데이터 세트 또는 매우 높은 쓰기 처리량을 통한 관계형 데이터베이스보다 더 큰 확장성
- 상용 데이터베이스 제품보다 무료 오픈 소스 소프트웨어에 대한 광범위한 선호도
- 관계형 모델에서 잘 지원되지 않는 특수 쿼리 작업
- 관계형 스키마의 제한성이 아닌, 동적이고 표현력이 풍부한 데이터 모델에 대한 요구
- 동적이고 표현력이 풍부한 데이터 모델에 대한 요구
애플리케이션마다 요구 사항이 다르며, 하나의 사례에 가장 적합한 기술을 선택해야 한다. 따라서 가까운 미래에 관계형 데이터베이스는 다양한 비관계형 데이터베이스와 함께 계속 사용될 것으로 보인다.
객체-관계형 불일치
오늘날 대부분의 애플리케이션 개발은 객체 지향 프로그래밍 언어에서 이루어지기 때문에 SQL 데이터 모델에 대한 비판으로 이어진다. 데이터가 관계형 테이블에 저장되는 경우 애플리케이션 코드의 객체와 테이블, 행, 열로 구성된 데이터베이스 모델 사이에 어색한 변환 계층이 필요하다. 이러한 모델 간의 연결 단절을 임피던스 불일치라고 부르기도 한다.
Hibernate 와 같은 객체 관계 매핑(ORM) 프레임워크는 이 변환 계층에 필요한 코드를 줄여주지만 두 모델 간의 차이점을 완전히 숨길 수는 없다.
일부 개발자는 JSON 모델이 애플리케이션 코드와 스토리지 계층 간의 임피던스 불일치를 줄여준다고 생각한다. 그러나, 데이터 인코딩 형식으로서 JSON에는 몇가지 문제가 있다. 이 사항은 다음 챕터에서 살펴본다.
JSON 모델은 다중 테이블 스키마보다 로컬리티가 더 우수하다. 관계형 모델에서 여러 쿼리를 수행하거나 하위 테이블 간에 복잡한 다방향 조인을 수행해야 한다. 하지만, JSON 표현에서는 모든 관련 정보가 한 곳에 있으며 쿼리 한 번이면 충분하다. 일대다 관계는 데이터의 트리 구조를 암시하며, JSON 표현은 이 트리 구조를 명시적으로 보여준다.
다대일 연관관계와 다대다 연관관계
예제 2-1에서는 region_id와 industry_id가 일반 텍스트 문자열인 “Greater Seattle Area” 및 “Philanthropy”가 아닌 ID로 정의된다.
표준화된 지역 및 산업 목록을 만들고 사용자가 드롭다운 목록이나 자동 완성기에서 선택할 수 있도록 하면 이점이 있습니다:
- 일관성: 프로필 전반에서 일관된 스타일과 철자 사용
- 모호함 방지: 이름이 같은 도시가 여러 개 있는 경우
- 업데이트 용이성: 이름이 한 곳에만 저장되므로 변경이 필요한 경우 전반적으로 쉽게 업데이트할 수 있다. (예: 정치적 사건으로 인한 도시 이름 변경).
- 현지화 지원: 사이트가 다른 언어로 번역될 경우, 스탠드업 목록을 현지화할 수 있으므로 지역과 업종이 뷰어의 언어로 표시될 수 있다.
- 검색 개선: 워싱턴 주의 자선가를 검색할 경우, 지역 목록에 시애틀이 워싱턴에 있다는 사실을 인코딩할 수 있으므로 이 프로필과 일치시킬 수 있다.
ID를 저장하느냐 텍스트 문자열을 저장하느냐는 중복의 문제다. ID를 사용하면 사람에게 의미 있는 정보는 한 곳에만 저장되고, 이를 참조하는 모든 레코드는 데이터베이스 내에서만 의미를 갖는 ID를 사용한다. 텍스트를 직접 저장하면 해당 텍스트를 사용하는 모든 레코드에 인간에게 의미 있는 정보가 복제된다. ID를 사용할 때의 장점은 인간에게는 의미가 없기 때문에 변경할 필요가 없다는 것이다. 식별하는 정보가 변경되더라도 ID는 동일하게 유지될 수 있다.
사람에게 의미가 있는 정보는 언젠가 변경해야 할 경우가 생긴다. 또한, 정보가 중복되는 경우 모든 중복 사본을 업데이트해야 한다. 이 경우, 쓰기 오버헤드가 발생할 수 있으며, 정보의 일부 사본은 업데이트되지만 다른 사본은 업데이트되지 않는 불일치가 발생할 위험이 있다. 이러한 중복을 제거하는 것이 데이터베이스 정규화의 핵심 아이디어다.
안타깝게도 이러한 데이터를 정규화하려면 문서 모델에 잘 맞지 않는 다대일 관계(많은 사람들이 특정 지역에 거주하고, 많은 사람들이 특정 산업에 종사하는 등)가 필요하다. 관계형 데이터베이스에서는 조인이 쉽기 때문에 ID로 다른 테이블의 행을 참조하는 것이 일반적이다. 문서 데이터베이스에서는 일대다 트리 구조에 조인이 필요하지 않으며, 조인에 대한 지원도 빈약하다. 데이터베이스 자체가 조인을 지원하지 않는 경우 데이터베이스에 대한 여러 쿼리를 수행하여 애플리케이션 코드에서 조인을 흉내내야 한다.
애플리케이션의 초기 버전이 조인이 없는 도큐먼트 모델에 잘 맞더라도 애플리케이션에 기능이 추가됨에 따라 데이터의 상호 연결성이 높아지는 경향이 있다. 예를 들어, 이력서 예제에 적용할 수 있는 몇 가지 변경 사항을 생각해보자:
엔티티로서의 조직 및 학교
이전 설명에서 organization(조직)과 schoole_name(학교 이름)은 단순한 문자열이다.
대신 엔티티에 대한 자세한 정보가 필요할 수 있다.
이 경우, 각 조직, 학교 또는 대학교는 자체 웹 페이지(로고, 뉴스 피드 등)를 가질 수 있고, 각 이력서는 언급된 조직과 학교로 연결되며, 해당 로고와 기타 정보를 포함할 수 있다 (그림 2-3 참조).
권장 사항
한 사용자가 다른 사용자를 위한 추천을 작성할 수 있는 새로운 기능을 추가한다고 가정하자. 추천을 받은 사용자의 이력서에 추천을 작성한 사용자의 이름 및 사진이 함께 표시된다. 추천자가 자신의 사진을 업데이트하면 추천자가 작성한 모든 추천에 새 사진이 반영되어야 하다. 따라서 추천에는 작성자의 프로필에 대한 참조가 있어야 한다.
그림 2-4는 이러한 새로운 기능에 다대다 관계가 왜 필요한지 설명한다. 각 점선 사각형 내의 데이터는 하나의 문서로 그룹화할 수 있지만 조직, 학교 및 기타 사용자에 대한 참조는 참조로 표시되어야 하며 쿼리할 때 조인이 필요하다.