필기하면서 읽지 않으면 계속 내용들이 머릿속에서 휘발되고 있다.
주관적인 이해에 따른 필기용으로 작성중이다.

데이터 중심 어플리케이션 설계

머리말

• 데이터 중심 애플리케이션(data-intensive application)은 이러한 기술적 발전을 활용해 실현 가능한 범위를 넓힘
  • 대규모의 데이터 및 트래픽을 효율적으로 처리하기 위해 만들어야 했던 새로운 도구
  • 개발 주기 단축과 유연한 데이터 모델의 필요
  • 여러 분야의 자유 오픈소스 소프트웨어 선호
  • CPU 클록 속도는 더이상 증가하지 않고 멀티코어 프로세서가 표준이 됐지만 네트워크는 계속 빨라지고 있으므로, 병렬 처리가 계속 늘고 있음
  • 서비스형 인프라(IaaS)덕에 여러 장비와 여러 지역의 분산 시스템 개발과 구축이 가능해짐
  • 고객들이 많은 서비스에 고가용성을 요구함, 서비스 중단 상황을 점점 받아들이지 못함
• 데이터 양, 데이터 복잡성, 데이터가 변하는 속도 등 데이터가 주요 도전 과제인 애플리케이션을 데이터 중심적(data-intensive)라고 하고 CPU 사이클이 병목인 경우 계산 중심적(compute-intensive)이라고 함
• 급격한 기술 변화에도 변하지 않는 원리가 있으며, 이 원리를 이해하면 각 도구가 적합한 장소와 도구를 잘 활용하는 방법, 그리도 도구에 숨어있는 함정을 피하는 방법을 알 수 있다.
• 시스템 내부 동작 방식에 대한 직관을 기른다면 시스템 동작을 추론할 수 있고 올바른 설게를 위한 의사결정이 가능하고 발생 가능한 모든 문제를 추적할 수 있다.

대상 독자

• 이 중 하나라도 해당한다면 이 책이 매우 유용하다.
  • 데이터 시스템을 확장성 있게 만드는 방법을 알고 싶다. 예를 들어 웹 또는 모바일 앱이 수백만 명의 사용자를 감당할 수 있게 하고 싶다.
  • 애플리케이션이 고가용성을 갖춰야 하고(중단시간 최소화) 운영상 견고해야 한다.
  • 시스템 규모가 커지고 요구사항과 기술이 바뀌더라도 오랜 기간 쉽게 유지보수할 수 있는 방법을 찾고 있다.
  • 사물의 동작 방식에 대해 타고난 호기심이 있다. 대형 웹사이트와 온라인 서비스의 내부가 어떻게 돌아가는지 알고 싶다. 이 책은 다양한 데이터베이스와 데이터 처리 시스템의 내부를 분해한다. 이런 시스템 설계에 반영된 기발한 생각을 탐험하는 것이 매우 즐겁다.

이 책에서 다루는 내용

• 이 책에서는 데이터 시스템 아키텍처와 데이터 중심 애플리케이션으로 데이터 시스템을 통합하는 방법을 주로 다룬다.
• 이 책에서 설명하는 많은 기술은 유행어인 빅데이터 영역에 속한다.

Part 1 데이터 시스템의 기초

01장. 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션

• 오늘날 많은 애플리케이션은 계산 중심(compute-intensive)과는 다르게 데이터 중심(data-intensive)적이다.
• 일반적으로 데이터 중심 애플리케이션은 공통으로 필요로 하는 기능을 제공하는 표준 구성 요소(standard building block)로 만든다.
  • 구동 애플리케이션이나 다른 애플리케이션에서 나중에 다시 데이터를 찾을 수 있게 데이터를 저장: 데이터베이스
  • 읽기 속도 향상을 위해 값비싼 수행 결과를 기억: 캐시
  • 사용자가 키워드로 데이터를 검색하거나 다양한 방법으로 필터링할 수 있게 제공: 검색 색인(search index)
  • 비동기 처리를 위해 다른 프로세스로 메시지 보내기: 스트림 처리(stream processing)
  • 주기적으로 대량의 누적된 데이터를 분석: 일괄 처리(batch processing)

데이터 시스템에 대한 생각

• 데이터 저장과 처리를 위한 여러 새로운 도구는 최근에 만들어져 다양한 사용 사례(case use)에 최적화됐기 때문에 더이상 전통적인 분류에 딱 들어맞지 않는다.
• 점점 더 많은 애플리케이션이 단일 도구로는 더 이상 데이터 처리와 저장 모두를 만족시킬 수 없는 과도하고 광범위한 요구사항을 갖고있다.
• 데이터 시스템이나 서비스를 설계할 때 까다로운 문제가 많이 생기기 때문에, 이에 따라 대부분의 소프트웨어 시스템에서 중요하게 여기는 세 가지 관심사:
  • 신뢰성(Reliabliity): 하드웨어나 소프트웨어 결함, 심지어 인적 오류(human error) 같은 역경에 직면하더라도 시스템은 지속적으로 올바르게 동작(원하는 성능 수준에서 정확한 기능을 수행)해야 한다.
  • 확장성(Scalability): 시스템의 데이터 양, 트래픽 양, 복잡도가 증가하면서 이를 처리할 수 있는 적절한 방법이 있어야 한다.
  • 유지보수성(Maintainablility): 시간이 지남에 따라 여러 다양한 사람들이 시스템 상에서 작업(현재 작업을 유지보수하고 새로운 사용 사례를 시스템에 적용하는 엔지니어링과 운영)할 것이기 때문에 모든 사용자가 시스템 상에서 생산적으로 작업할 수 있게 해야 한다.

신뢰성

• 소프트웨어의 일반적인 기대치는 다음과 같으며, 이 모든 것이 "올바르게 동작함"을 의미하는 경우, 대략 "무언가 잘못되더라도 지속적으로 올바르게 동작함"을 신뢰성의 의미로 이해할 수 있다:
  • 애플리케이션은 사용자가 기대한 기능을 수행한다.
  • 시스템은 사용자가 범한 실수나 에상치 못한 소프트웨어 사용법을 허용할 수 있다.
  • 시스템 성능은 예상된 부하와 데이터 양에서 필수적인 사용 사례를 충분히 만족한다.
  • 시스템은 허가되지 않은 접근과 오남용을 방지한다.
• 잘못될 수 있는 일을 결함(fault)이라고 부르고, 결함을 예측하고 대처할수 있는 시스템을 결함성(fault-tolerant) 또는 탄력성(resilient)을 지녔다고 말함
  • 모든 종류의 결함을 견딜 수 있는 시스템은 실현가능하지 않으므로, 내결함성이라는 용어는 특정 유형의 결함 내성에 대해서만 이야기하는 것이 타당함
• 결함은 장애(failure)와 동일하지 않음. 결함은 사양에서 벗어난 시스템의 한 구성 요소로 정의되고, 장애는 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우.
• 결함 확률을 0으로 줄이는 것은 불가능함에 따라 결함으로 장애가 발생하기 않게끔 내결함성 구조를 설계하는 것이 가장 좋다.
• 넷플릭스의 카오스몽키: 고의적으로 결함을 일으켜 결함률을 증가시키는 정급 방식의 한 예
• 보안 문제의 경우 공격자가 시스템을 손상시키고 민감한 데이터에 접근 권한을 얻는다면 되돌릴 수 없으므로, 해결책보다 예방책이 더 좋은 경우이다.

하드웨어 결함

• 일반적으로는 각 하드웨어 구성 요소에 중복(redundancy)을 추가하는 방법
  • 디스크: RAID 구성 설치
  • 서버: 이중 전원 디바이스, 핫 스왑(hot-swap) 가능 CPU
  • 데이터센터: 건전지, 예비 전원용 디젤 발전기
• 데이터 양과 애플리케이션의 계산 요구가 늘어나며 많은 애플리케이션이 많은 수의 장비를 사용함에 비례해 하드웨어 결함율이 증가함
  • AWS같은 일부 클라우드 플랫폼은 가상 장비 인스턴스가 별도의 경고 없이 사용할 수 없게 되는 상황이 상당히 일반적
  • 이러한 플랫폼은 단일 장비 신뢰성보다 유연성과 탄력성을 우선적으로 처리하게끔 설계됐기 때문
• 따라서 소프트웨어 내결함성 기술을 사용하거나 하드웨어 중복성을 추가해 전체 장비의 손실을 견딜 수 있는 시스템으로 점점 옮겨가고 있다

소프트웨어 오류

• 시스템 내 체계적 오류(systematic error): 예상하기 더 어렵고 노드 간 상관관계 때문에 상관관계가 없는 하드웨어 결함보다 오히려 시스템 오류를 더 많이 유별하는 경향이 있다.
• 소프트웨어의 체계적 오류 문제는 신속한 해결책이 없다.
  • 시스템의 가정과 상호작용에 대해 주의 깊게 생각하기
  • 빈틈없는 테스트
  • 프로세스 격리(process isolation)
  • 죽은 프로세스의 재시작 허용
  • 프로덕션 환경에서 시스템 동작의 측정
  • 모니터링
  • 분석하기
• 시스템이 뭔가를 보장하길 기대한다면 수행 중에 이를 지속적으로 확인해 차이가 생기는 경우 경고를 발생시킬 수 있다.

인적 오류

• 연구에 따르면 운영자의 설정 오류가 중단의 주요 원인인 반면 하드웨어(서버나 네트워크) 결함은 중단 원인의 10~25%정도에 그친다.
• 최고의 시스템은 다양한 접근 방식을 결합한다.
  • 오류의 가능성을 최소화 하는 방향으로 시스템을 설계하라.
  • 사람이 가장 많이 실수하는 장소(부분)에서 사람의 실수로 장애가 발생할 수 있는 부분을 분리하라.
  • 단위 테스트부터 전체 시스템 통합 테스트와 수동 테스트까지 모든 수준에서 철저하게 테스트하라.
  • 장애 발생의 영향을 최소화 하기 위해 인적 오류를 빠르고 쉽게 복구할 수 있게 하라.
  • 성능 지표와 오류율 같은 상세하고 명확한 모니터링 대책을 마련하라.
  • 조작 교육과 실습을 시행하라.

신뢰성은 얼마나 중요할까?

• 비즈니스 애플리케이션에서 버그는 생산성 저하의 원인이고 전자 상거래 사이트의 중단은 매출에 손실이 발생하고 명성에 타격을 준다는 면에서 많은 비용이 듬.
• 중요하지 않은 애플리케이션도 사용자에 대한 책임이 있다.
• 증명되지 않은 시장을 위해 신뢰성을 희생해야 하는 상황이 있다. 이 경우에는 비용을 줄여야 하는 시점을 매우 잘 알고 있어야 한다.

확장성

• 성능 저하를 유발하는 흔한 이유 중 하나는 부하 증가다.
• 확장성은 증가한 부하에 대처하는 시스템 능력을 설명하는 데 사용하는 용어

부하 기술하기

• 시스템의 현재 부하를 간결하게 기술해야 한다. 그래야 부하 성장 질문을 논의할 수 있다.
• 부하는 부하 매개변수(load parameter)라 부르는 몇 개의 숫자로 나타낼 수 있다. 가장 적합한 부하 매개변수 선택은 시스템 설계에 따라 달라진다. 평균적인 경우가 중요할 수도, 소수의 극단적인 경우가 병목 현상의 원인일 수도 있다.
  • 웹 서버의 초당 요청 수
  • 데이터베이스의 읽기 대 쓰기 비율
  • 대화방의 동시 활성 사용자(activ user)
  • 캐시 적중률

성능 기술하기

• 시스템 부하를 기술하면 부하가 증가할 때 어떤 일이 일어나는지 조사할 수 있는데, 살펴볼 수 있는 아래 두 질문 모두 성능 수치가 필요하다.
  • 부하 매개변수를 증가시키고 시스템 자원은 변경하지 않고 유지하면 시스템 성능은 어떻게 영향을 받을까?
  • 부하 매개변수를 증가 시켰을 때 성능이 변하지 않고 유지되길 원한다면 자원을 얼마나 많이 늘려야 할까?
• 하둡같은 일괄 처리 시스템은 보통 처리량(throughput)에 관심을 가지고, 온라인 시스템에서 더 중요한 사항은 서비스 응답 시간(response time)이다.
• 응답 시간은 매번 다르므로 단일 숫자가 아니라 측정 가능한 값의 분포로 생각해야 한다.
• 가끔 꽤 오래 걸리는 특이 값(outlier)은 보통 아래와 같은 다른 여러 원인으로 추가 지연이 생길 수 있다.
  • 백그라운드 프로세스의 컨텍스트 스위치(context switch)
  • 네트워크 패킷 손실과 TCP 재전송
  • 가비지 컬렉션 휴지(garbage collection pause)
  • 디스크에서 읽기를 강제하는 페이지 폴트(page fault)
  • 서버 랙의 기계적인 진동
• 보고된 서비스의 산술 평균(arithmetic mean) 응답 시간을 살피는 일은 일반적이나 얼마나 많은 사용자가 실제로 지연을 경험했는지 알려주지 않기 때문에 전형적인 응답 시간을 알고 싶다면 평균은 좋은 지표가 아니다.
• 일반적으로는 평균보다는 백분위(percentile)를 사용하는 편이 더 좋다.
  • 사용자가 보통 얼마나 오랫동안 기다려야 하는지 알고 싶다면 중앙값이 좋은 지표다.
  • 특이 값이 얼마나 좋지 않은지 알아보려면 상위 백분위를 살펴보는 것도 좋다.
  • 꼬리 지연 시간(tail latency)으로 알려진 상위 백분위 응답 시간은 서비스의 사용자 경험에 직접 영향을 주기 때문에 중요하다.
  • 백분위는 서비스 수준 목표(service level objective, SLO0와 서비스 수준 협약서(service level agreement, SLA)에 자주 사용하고 기대 성능과 서비스 가용성을 정의하는 계약서에도 자주 등장한다.
• 선두 차단(head-of-ine blocking) 현상: 소수의 느린 요청 처리만으로도 후속 요청 처리가 지체된다.
  • 이런 문제 때문에 클라이언트 쪽 응답 시간 측정이 중요하다.
• 시스템의 확장성을 테스트하려고 인위적으로 부하를 생성하는 경우 부하 생성 클라이언트는 응답 시간과 독립적으로 요청을 지속적으로 보내야 한다.
  • 클라이언트가 다음 요청을 보내기 전에 이전 요청이 완료되길 기다리면 테스트에서 인위적으로 대기 시간을 실제보다 더 짧게 만들어 평가를 왜곡한다.
• 실전 백분위
  • 상위 백분위는 단일 최종 사용자 요청의 일부로서 여러 번 호출되는 백엔드 서비스에서 특히 중요하다.
  • 서비스의 모니터링 대시보드에 응답 시간 백분위를 추가하려면 지속적으로 백분위를 효율적으로 계싼할 필요가 있다.
  • 상황에 따라 포워드 디케이(forward decay), T 다이제스트(t-digest), Hdr히스토그램(HdrHistogram) 같은 백분위 근사치를 계산할 수 있는 알고리즘이 있다.
  • 백분위 평균은 수학적으로 의미가 없으니 주의하자.

부하 대응 접근 방식

• 용량 확장 scaling up(수직 확장 vertical scaling): 좀 더 강력한 장비로 이동
• 규모 확장 scaling out(수평 확장 horizontal scaling): 다수의 낮은 사양 장비에 부하를 분산
• 비공유(shared-nothing) 아키텍처: 다수의 장비에 부하를 분산하는 아키텍처
• 탄력적(elastic) 시스템: 부하 증가를 감지하면 컴퓨팅 자원을 자동으로 추가할 수 있다. 부하를 에측할 수 없을 만큼 높은 경우 유용하지만 수동으로 확장하는 시스템이 더 간단하고 예상치 못한 일이 더 적다.
• 상태 비저장(stateless) 서비스를 다수에 장비에 배포하기는 간단하지만, 단일 노드에 상태 유지(stateful) 데이터 시스템을 분산 설치하는 것은 많은 복잡도가 추가된다. 확장 비용이나 데이터베이스를 분산으로 만들어야 하는 고가용성 요구가 있을 때 까지 단일 노드에 데이터베이스를 유지하는 것(용량 확장)이 최근까지의 통념이었다.
• 분산 시스템을 위한 도구와 추상화가 좋아지며 대용량 데이터와 트래픽을 다루지 않는 사용 사례에도 분산 데이터 시스템이 향후 기본 아키텍처로 자리 잡을 가능성이 있다.
• 대개 대규모로 동작하는 시스템의 아키텍처는 해당 시스템을 사용하는 애플리케이션에 특화되어 있다. 범용적이고 모든 상황에 맞는(one-size-fits-all) 확장 아키텍처는 없다.
• 아키텍처를 결정하는 요소
  • 읽기의 양
  • 쓰기의 양
  • 저장할 데이터의 양
  • 데이터의 복잡도
  • 응답 시간 요구사항
  • 접근 패턴 등
  • 혹은 이 요소 중 일부 조합에 더 많은 문제가 추가된 경우
• 특정 애플리케이션에 적합한 확장성을 갖춘 아키텍처는 주요 동작이 무엇이고 잘 하지않는 동작이 무엇인지에 대한 가정을 바탕으로 구축하고, 이 가정은 곧 부하 매개변수가 된다.
  • 이 가정이 잘못되면 확장에 대한 엔지니어링 노력은 헛수고가 된다.
  • 스타트업 초기 단계나 검증되지 않은 제품의 경우 미래를 가정한 부하에 대비해 확장하기 보다 빠르게 반복해서 제품 기능을 개선하는 작업이 좀 더 중요하다.
• 확장성을 갖춘 아키텍처가 특정 애플리케이션에 특화됐을지라도 보통 익숙한 패턴으로 나열된 범용적인 구성 요소로 구축한다.

유지보수성

• 소프트웨어 비용의 대부분은 초기 개발이 아니라 지속해서 이어지는 유지보수에 들어간다
  • 버그 수정
  • 시스템 운영 유지
  • 장애 조사
  • 새로운 플랫폼 적응
  • 새 사용 사례를 위한 변경
  • 기술 채무(technical debt) 상환
  • 새로운 기능 추가 등
• 유지보수 중 고통을 최소화 하고 레거시 소프트웨어를 직접 만들지 않게끔 소프트웨어를 설계하기 위해 주의를 기울여야 할 소프트웨어 시스템 설계 원칙
  • 운용성(operability): 운영팀이 시스템을 원활하게 운영할 수 있게 쉽게 만들어라.
  • 단순성(simplicity): 시스템에서 복잡도를 최대한 제거해 새로운 엔지니어가 시스템을 이해하기 쉽게 만들어라(사용자 인터페이스의 단순성과는 다르다는 점에 유의하라).
  • 발전성(evolvability): 엔지니어가 이후에 시스템을 쉽게 변경할 수 있게 하라. 그래야 요구사항 변경 같은 예끼치 않은 사용 사례를 적용하기가 쉽다. 이 속성은 유연성(extensibility), 수정 가능성(modifiability), 적응성(plasticity)으로 알려져 있다.

운용성: 운영의 편리함 만들기

• 시스템이 지속해서 원활하게 작동하려면 운영팀은 필수다. 좋은 운영팀은 일반적으로 다음과 같은 작업 등을 책임진다.
  • 시스템 상태를 모니터링하고 상태가 좋지 않다면 빠르게 서비스를 복원
  • 시스템 장애, 성능 저하 등의 문제의 원인을 추적
  • 보안 패치를 포함해 소프트웨어와 플랫폼을 최신 상태로 유지
    -다른 시스템이 서로 어떻게 영향을 주는지 확인해 문제가 생길 수 있는 변경 사항을 손상을 입히기 전에 차단
  • 미래에 발생 가능한 문제를 예측해 문제가 발생하기 전에 해결(용량 계획 등)
  • 배포, 설정 관리 등을 위한 모범 사례와 도구를 마련
  • 애플리케이션을 특정 플랫폼에서 다른 플랫폼으로 이동하는 등 복잡한 유지보수 태스크를 수행
  • 설정 변경으로 생기는 시스템 보안 유지보수
  • 에측 가능한 운영과 안정적인 서비스 환경을 유지하기 위한 절차 정의
  • 개인 인사 이동에도 시스템에 대한 조직의 지식을 보존함
• 좋은 운영성이란 동이할게 반복되는 태스크를 쉽게 수행하게끔 만들어 운영팀이 고부가가치 활동에 노력을 집중한다는 의미로, 데이터 시스템은 동일 반복 태스크를 쉽게 하기 위해 아래 항목 등을 포함해 다양한 일을 할 수 있다.
  • 좋은 모니터링으로 런타임(runtime) 동자과 시스템의 내부에 대한 가시성 제공
  • 표준 도구를 이용해 자동화와 통합을 위한 우수한 자원을 제공
  • 개별 장비 의존성을 회피, 유지보수를 위한 장비를 내리더라도 시스템 전체에 영향을 주지 않고 계쏙해서 운영 가능해야 함.
  • 좋은 문서와 이해하기 쉬운 운영 모델 제공
  • 만족할 만한 기본 동작 제공, 필요할 때 기본값을 다시 정의할 수 있는 자유를 관리자에게 부여
  • 적절하게 자기 회복(self-healing)이 가능할 뿐 아니라 필요에 따라 관리자가 시스템 상태를 수동으로 제어할 수 있게 함
  • 예측 가능하게 동작하고 예기치 않은 상황을 최소화함

단순성: 복잡도 관리

• 복잡도는 같은 시스템에서 작업해야 하는 모든 사람의 진행을 느리게 하고 나아가 유지보수 비용이 증가한다. 복잡도 수렁에 빠진 소프트웨어 프로젝트를 때론 커다란 진흙 덩어리(big ball of mud)로 묘사한다.
• 복잡도는 다양한 증상으로 나타난다.
  • 상태 공간의 급증
  • 모듈 간 강한 커플링(tight coupling)
  • 복잡한 의존성
  • 일관성 없는 명명(naming)과 용어
  • 성능 문제 해결을 목표로 한 해킹
  • 임시방편으로 문제를 해결한 특수 사례(special-casing) 등
• 복잡도를 줄이면 소프트웨어 유지보수성이 크게 향상된다. 따라서 단순성이 구축하려는 시스템의 핵심 목표여야 한다.
• 시스템을 단순하게 만드는 일이 반드시 기능을 줄인다는 의미는 아니고, 우발적 복잡도(accidental complexity)를 줄인다는 뜻일 수도 있다.
• 우발적 복잡도를 제거하기 위한 최상의 도구는 추상화다.

발전성: 변화를 쉽게 만들기

• 시스템의 요구사항이 영원히 바뀌지 않을 가능성은 매우 적고, 시스템의 요구사항이 끊임없이 변할 가능성이 훨씬 크다.
• 조직 프로세스 측면에서 애자일(agile) 작업 패턴은 변화에 적응하기 위한 프레임워크를 제공한다. 또한 애자일 커뮤니티는 테스트 주도 개발과 리팩토링같이 자주 벼화하는 환경에서 소프트웨어를 개발할 때 도움이 되는 기술 도구와 패턴을 개발하고 있다.
• 간단하고 이해하기 쉬운 시스템은 대개 복잡한 시스템보다 수정하기 쉽다. 데이터 시스템 수준에서 민첩성을 언급할 때는 발전성이라는 단어를 사용한다.

정리

• 애플리케이션이 유용하려면 다양한 요구사항을 충족시켜야 한다.
  • 기능적 요구사항: 여러 방법으로 데이터를 저장하고 조회하고 검색하고 처리하게끔 허용하는 작업과 같이 해야 하는 일
  • 비기능적 요구사항: 보안, 신뢰성, 법규 준수, 확장성, 호환성, 유지보수성과 같은 일반 속성
• 신뢰성: 결함이 발생해도 시스템이 올바르게 동작하게 만든다는 의미.
  • 결함은 하드웨어와 소프트웨어 버그와 사람에게 잇을 수 있다.
  • 내결함성 기술은 최종 사용자에게 특정 유형의 결함을 숨길 수 있게 해준다.
• 확장성: 부하가 증가해도 좋은 성능을 유지하기 위한 전략을 의미.
  • 양적으로 부하와 성능을 설명하는 방법이 필요
  • 확장 가능한 시스템에서는 부하가 높은 상태에서 신뢰성을 유지하기 위해 처리 용량을 추가할 수 있다.
• 유지보수성: 본질은 시스템에서 작업하는 엔지니어와 운영 팀의 삶을 개선하는 데에 있다.
  • 좋은 추상화는 복잡도를 줄이고 쉽게 시스템을 변경할 수 있게 하며 새로운 사용 사례에 적용하는 데 도움이 된다.
  • 좋은 운용성이란 건강 상태를 잘 관찰할 수 있고 시스템을 효율적으로 관리하는 방법을 보유한다는 의미다.
• 애플리케이션을 신뢰할 수 있고 확장 가능하며 유지보수하기 쉽게 만들어주는 간단한 해결책은 없지만, 여러 애플리케이션에서 계속 재현되는 특정 패턴과 기술이 있다.

02장. 데이터 모델과 질의 언어

• 데이터 모델은 문제를 어떻게 생각해야 하는지에 대해 큰 영향을 끼치기 때문에 소프트웨어 개발에서 제일 중요한 부분이다.

관계형 모델과 문서 모델

• 가장 잘 알려진 데이터 모델은 관계형 모델 기반 SQL
• 관계형 데이터베이스의 근원은 비즈니스 데이터 처리

NoSQL의 탄생

• NoSQL 데이터베이스 채택의 원동력
  • 대규모 데이터셋이나 매우 높은 쓰기 처리량 달성을 관계형 데이터베이스보다 쉽게 할 수 있는 뛰어난 확장성의 필요
  • 상용 데이터베이스 제품보다 무료 오픈소스 소프트웨어에 대한 선호도 확산
  • 관계형 모델에서 지원하지 않는 특수 질의 동작
  • 관계형 스키마의 제한에 대한 불만과 더욱 동적이고 표현력이 풍부한 데이터 모델에 대한 바람
• 관계형 데이터베이스가 폭넓은 다향함을 가진 비관계형 데이터스토어와 함께 사용되는 것을 다중 저장소 지속성(polyglot persistence)이라 한다.

객체 관계형 불일치

• 객체지향 프로그래밍의 데이터를 관계형 테이블에 저장하려면 데이터 베이스 모델 객체 사이에 거추장스러운 전환 계층이 필요하고, 이런 모델 사이의 분리를 종종 임피던스 불일치(impedance mismatch)라고 부른다.
• 객체 관계형 매핑(ORM) 프레임워크는 두 모델 간의 차이를 완벽히 숨길 수 없다.

다대일과 다대다 관계

• ID나 텍스트 문자열의 저장 여부는 중복의 문제다.
• 중복된 데이터를 정규화하려면 다대일(many-to-one) 관계가 필요하다. 하지만 문서 모델에는 적합하지 않다.
• 애플리케이션에 기능을 추가하면서 데이터는 점차 상호 연결되는 경향이 있어, 초기 버전이 조인 없는(join-free) 문서 모델에 적합하더라도 이후 다대다(many-to-many) 관계를 필요로 할 수 있다.

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

• IMB 정보 관리 시스템(Information Management System, IMS): 1970년대 계층 모델이라 부르는 상당히 간단한 데이터 모델을 사용했다.
• 계층 모델의 한계를 해결하기위해 관계형 모델(SQL)과 네트워크 모델이 제안되었다.

네트워크 모델

• 레코드는 다중 부모가 있을 수 있다. 다대일과 다대다 관계를 모델링할 수 있다.
• 레코드에 접근하는 유일한 방법은 최상위 레코드(root record)에서부터 연속된 연결 경로를 따르는 방법이고, 이를 접근 경로라 한다.
• 매우 제한된 하드웨어 성능을 가장 효율적으로 사용 가능하지만 데이터베이스 질의와 갱신을 위한 코드가 복잡하고 유연하지 못하다.

관계형 모델

• 대조적으로 관계형 모델은 알려진 모든 데이터를 배치하는 일을 한다.
• 질의 최적화기(query optimizer)는 질의의 어느 부분을 어떤 순서로 실행할지를 결정하고 사용할 색인을 자동으로 결정한다.(이 선택은 실제로 "접근 경로"다.)