데이터 모델은 아마도 소프트웨어 개발에서 제일 중요한 부분일 것이다. 왜냐하면 데이터 모델은 소프트웨어가 어떻게 작성됐는지 뿐만 아니라, 문제를 어떻게 생각해야 하는지에 지대한 영향을 미치기 때문이다.

  • 대부분의 애플리케이션은 하나의 데이터 모델을 다른 데이터 모델 위에 계층을 둬서 만든다. 각 계층의 핵심적인 문제는 다음 하위 계층 관점에서 데이터 모델을 표현하는 것이다.

참고로 레이어 패턴은 하나의 레이어가 직전 레이어의 성립을 전제로 존재하고, 그러한 레이어들로 이루어진 구조를 말한다.

무튼 이번 장에서는 아래와 같은 것들을 살펴본다.

  1. 다양한 범용 데이터 모델들에 대한 소개
  2. 다양한 질의 언어와 사용 사례

관계형 모델과 문서 모델

관계형 모델과 문서 모델, 그리고 아주 약간의 그래프 모델에 대해 그리고 이들의 역사에 대해 살펴본다.

가장 중요하게 생각한건 어떠한 요구를 처리하다가 어떠한 db가 우위를 점했는지에 대한 내용이다.

관계형 모델

  • 관계형 모델은 1970년대에 제안된 모델로, 상당 기간 우위를 점했다.
  • 테이블과 관계를 튜플로 표현한 데이터의 모음으로 관리한다.
  • 트랜잭션 처리와 일괄 처리에 대한 지원을 강점으로 내세워 우위를 점했다.

NoSQL

  • NoSQL은 관계형 모델의 우위를 뒤집기 위한 가장 최근의 시도이다.
  • 처음에는 커뮤니티 밋업을 위한 해쉬태그였지만 점점 용어가 확산되어 Not Only SQL로 재해석됐다.
  • 주로 아래와 같은 이유로 사용된다.
    • 대규모 데이터 셋이나 매우 높은 쓰기 처리량을 필요로 하는 경우
    • 오픈소스 소프트웨어를 사용하고자 하는 경우
    • 동적이고 표현력이 풍부한 모델에 대한 바램

객체 관계 불일치

  • 객체 관계 불일치는 객체지향 프로그래밍 언어와 관계형 데이터베이스 간의 불일치를 의미한다.
  • 요즘은 가장 대중적으로 객체지향 프로그래밍 언어를 사용하는데, 이로 인해 객체지향 프로그래밍 언어와 관계형 데이터베이스 간의 불일치가 발생한다.
  • 이런 모델 사이의 불일치를 임피던스 불일치라고 한다.

아래의 예시 json 데이터는 객체 지향 프로그램의 데이터 모델과 아주 유사하다.

{
  "profile": {
    "firstName": "John",
    "lastName": "Doe",
    "headline": "Software Engineer at TechCorp",
    "location": {
      "city": "San Francisco",
      "region": "California",
      "country": "United States"
    },
    "summary": "Experienced software engineer with a passion for developing scalable web applications and working across the full stack.",
    "profilePictureUrl": "https://example.com/profile/johndoe.jpg",
    "contactInfo": {
      "email": "john.doe@example.com",
      "phone": "+1-123-456-7890",
      "linkedinUrl": "https://www.linkedin.com/in/johndoe"
    }
  },
  "experience": [
    {
      "title": "Senior Software Engineer",
      "company": "TechCorp",
      "location": "San Francisco, CA",
      "startDate": "2019-06",
      "endDate": "Present",
      "description": "Leading the development of microservices architecture and improving CI/CD pipelines."
    },
    {
      "title": "Software Engineer",
      "company": "Web Solutions Inc.",
      "location": "New York, NY",
      "startDate": "2016-01",
      "endDate": "2019-05",
      "description": "Developed web applications using modern JavaScript frameworks."
    }
  ],
  "education": [
    {
      "school": "University of California, Berkeley",
      "degree": "Bachelor of Science",
      "fieldOfStudy": "Computer Science",
      "startDate": "2012-09",
      "endDate": "2016-05"
    }
  ],
  "skills": [
    "JavaScript",
    "React",
    "Node.js",
    "Microservices",
    "Docker"
  ],
  "certifications": [
    {
      "name": "AWS Certified Solutions Architect",
      "authority": "Amazon Web Services",
      "issueDate": "2021-03",
      "expirationDate": "2024-03"
    }
  ],
  "recommendations": [
    {
      "name": "Jane Smith",
      "relationship": "Former Manager",
      "recommendationText": "John is an outstanding software engineer with exceptional leadership skills."
    }
  ]
}
  • 그러나 이런 데이터를 관계형 데이터베이스에 저장하려면, 객체를 테이블로 변환해야 한다.
  • 이러인해 많은 테이블, 스키마 들이 생기게 되고 이로 인해 지역성(locality)이 떨어지게 된다.
  • 예를들어 profile, experience 등의 테이블이 생겨나게 되고 조회를 위해서 매번 조인해야 한다.
  • 물론 이렇게 저장하고 관리하는게 모든 면에서 훌륭하지는 않다.
  • 다대일이나 다대다 관계를 표현하는 부분에서는 관계형 데이터베이스가 더 효율적이다.
    • id를 통해 참조하는 방식은 모호함을 회피하는데 좋다. (이름 같은 다른 도시가 있을 경우)
    • 갱신을 위한 비용이 적다.
    • 역조건으로 검색하는 경우 인덱스와 조인을 통해 빠르게 검색할 수 있다.

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

바로 위에 다뤘던 내용과 관련된 내용이다. 요약하면 문서 데이터 모델은 스키마 유연성, 지역성이 높고 그부분에 대한 성능으로 어필하고 관계형 데이터베이스는 다대일, 다대다 관계를 표현하는데 효율적이다.

  • 그래도 일반적으로는 관계형 데이터베이스가 ‘최근’ 어플리케이션들의 코드를 복잡하게 만드는 경향이 있다
    • 기본적으로 매번 데이터를 조인해야 어플리케이션 모델을 생성 할 수 있기 때문이다.
    • 책도 이부분에 대한 내용에 어느 정도 동의를 하고 있다.

물론 ORM들이 아마도 최근에 더 활발하게 사용되고 있는 부분을 고려해야 할 수 있기는 한 것 같다.

  • 반대로 문서형 데이터베이스 모델들은 상대적으로 rdb보다 코드를 간단하게 만들어 주는 것은 사실인 것 같다.
  • 그러나 이러한 모델들은 다대일, 다대다 관계를 표현하는데 비효율적이다.
    • 비정규화된 데이터로 중북을 감수해야 하고 데이터 일관성을 위한 추가적인 코드 작업이 필요하다.
  • 추가적으로 문서모델은 스키마유연성이 높다.
    • 그렇다고 schemaless하다고 표현하기에는 오해의 소지가 있을 수 있다.
    • ‘읽는’ 작업에서는 그래도 어느정도의 스키마를 가정한다. (암묵적으로)
    • 그러나 ‘쓰는’ 작업에서는 스키마가 유연하다. (쓰기 스키마를 가진다고 표현했다.)
  • 마지막으로 지역성에 대한 고려는 조회 한번에 거의 모든 데이터를 사용하는 경우는 지역성이 높은 모델이 훨씬 더 효율적이다.

데이터베이스 질의

선언형 질의와 명령형 질의, 그리고 맵리듀스 질의에 대한 내용이 나온다. 선언형 질의와 명령형 질의에 대한 내용이 이해가 잘 되지 않아서 좀 더 공부가 필요할 것 같다. (선언형 질의와 명령형 질의에 대한 내용 추후 작성 예정)

맵리듀스 질의

함수형 프로그래밍에서 나온 아이디어이며 함수형 프로그래밍의 맵, 리듀스를 알아야 한다.

  • 함수형 프로그래밍에서 map은 컬렉션의 각 요소에 동일한 함수를 적용하여 새로운 컬렉션을 생성하는 함수이다.
  • 각 요소가 독립적으로 처리되기 때문에 병렬 처리에도 용의하다.
  • reduce는 컬렉션의 모든 요소를 하나의 값으로 결합하는 함수이다. 여러개의 값을 결합해서 최종 결과를 도출한다.