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

'CH.01 신뢰할 수 있고(신뢰성) 확장 가능하며(확장성) 유지보수하기 쉬운(유지보수성) 애플리케이션'은 이 책이 다루는 주제인 '데이터 중심 애플리케이션 설계'의 전반적인 원칙에 대해 다루는 장이다.자, 그럼 하나씩 각 요소들을 살펴보기 전 데이터 중심 애플리케이션

오늘은 RDB 및 Document, Graph 데이터베이스 모델과 각 모델의 특징을 다룬다. 관계형 모델과 문서모델의 개념 관계형 모델(RDBMS) SQL은 1970년에 탄생 데이터는 테이블이라 불리는 관계로 구성되고 각 관계는 순서 없는 튜플(tuple)(

관계형 모델의 질의 언어와 문서 데이터 베이스 질의 언어의 비교 문서 데이터베이스와 관계형 데이터 베이스가 통합된다면? 문서 모델의 스키마 유연성 질의를 위한 데이터 지역성 선언형 질의와 명령형 질의 맵리듀스 질의 사이퍼 질의 사이퍼 질의를 SQL로 구현

이번 장에서는 데이터베이스의 저장과 검색에 대해 다룬다. B-tree와 LSM-tree을 중심으로 비교한다.데이터베이스의 기본 역할가장 기본적인 데이터베이스의 역할은 데이터를 저장하고, 요청한 데이터를 제공하는 것개발자의 입장에서 특정 작업부하 유형에서 좋은 성능을 내

고수준에서 저장소 엔진은 트랜잭션 처리 최적화(OLTP)와 분석 최적화(OLAP)라는 두 가지 범주로 나뉨OLTP보통 대량의 요청을 받음. 보통 애플리케이션이 각 질의마다 작은 수의 레코드를 다룸.저장소 엔진은 데이터를 찾기 위해 색인을 사용하며, 대개 디스크 탐색이

앞선 예제에서와 같이 부호화된 레코드는 결국 부호화된 필드의 연결일 뿐임. 각 필드는 태그 숫자(예제 스키마의 숫자 1,2,3)로 식별하고 데이터 타입을 주석으로 달고, 필드 값을 설정하지 않은 경우엔 단순히 부호화 레코드에서 생략하는 방식필드 태그는 부호화된 데이터를

추상화된 개념으로 하나의 프로세스에서 다른 프로세스로 데이터를 전달하는 것메모리를 공유하지 않는 프로세스 간의 데이터 전달을 위해서는 부호화/복호화 과정이 필수그렇다면, 누가 부호화/복호화를 수행할까?데이터 베이스서비스 호출(REST, RPC)비동기 메시지데이터베이스에

확장성데이터 볼륨, 읽기 부하, 쓰기 부하가 단일 장비에서 다룰 수 있는 양보다 커지면 부하를 여러 장비로 분배할 수 있음내결함성/고가용성(HA)장비 하나(또는 여러 장비나 네트워크, 전체 데이터센터)가 죽더라도 애플리케이션이 계속 동작해야 한다면 여러 장비를 사용해

네트워크로 연결된 여러 장비에 동일한 데이터의 복사본을 유지하는 것장점지리적으로 사용자와 가깝게 데이터를 유지해 지연시간을 줄일 수 있음장애 발생시, Fail-over 가능Read-only 장비를 확장해 읽기 처리량을 늘릴 수 있음데이터가 변경되지 않는다면, 복제를 구

복제는 내결함성만을 위해 필요한 것이 아님. 확장성과 지연시간은 복제를 구성하는 주요 이유 중 하나리더 기반 복제는 쓰기 요청을 리더가 담당하며, 수 많은 읽기 요청을 팔로워가 담당즉, 대부분이 읽기 요청이고 쓰기 요청이 작은 비율로 구성된 작업부하를 가진 시스템이라면

리더가 하나만 존재하고 모든 쓰기를 해당 리더가 처리해야 함어떤 이유로든 리더에 연결할 수 없다면, 데이터베이스에 쓰기를 할 수 없음그래서 등장한 것이 다중 리더 복제단일 리더 복제와 동일한 방식을 사용하지만, 쓰기 처리를 하는 다중 리더는 데이터 변경을 다른 모든 노

단일 리더와 다중 리더 복제는 클라이언트가 쓰기 요청을 한 노드(리더)에게 전송한 뒤 데이터베이스 시스템이 쓰기를 다른 복제 서버에 복사하는 아이디어를 기반으로 함일부 시스템은 리더의 개념을 버리고 클라이언트에게 모든 복제 서버로의 쓰기 요청을 허용하는 방식을 적용아마

데이터 셋이 매우 크거나 질의 처리량이 매우 높다면, 복제만으로는 부족하며 데이터를 파티션으로 쪼갤 필요가 있음. 이를 샤딩이라고도 함파티션은 보통 각 데이터 단위(레코드, 로우, 문서)를 기준으로 구성파티셔닝을 하는 목적확장성 : 데이터 셋을 여러 디스크에 분산부하

DB의 소프트웨어나 하드웨어는 언제라도 실패할 수 있음애플리케이션은 언제라도 죽을 수 있음네트워크가 끊기면 애플리케이션과 DB의 연결이 끊기거나 DB 노드 사이의 통신이 끊길 수 있음여러 클라이언트가 동시에 DB를 사용해서 다른 클라이언트가 쓴 내용을 덮어쓸 수 있음클

직렬성 격리 직렬성 격리는 데이터베이스가 여러 트랜잭션들이 직렬적으로 실행되는 것즉 동시성 없이 한 번에 트랜잭션 하나만 실행)과 동일한 결과가 나오도록 보장한다는 것을 의미 하지만, 현실적으로 직렬성 격리를 달성하는 것은 간단한 일이 아님. 달성한다고 해도 직렬

갱신 손실 방지 동시에 실행되는 쓰기 트랜잭션 사이에 발생할 수 있는 충돌에는 더티 쓰기 이외에도 다양한 것이 존재 이중 가장 널리 알려진 것이 갱신 손실이며 이전에 동시에 카운터를 증가시키는 예시가 이 문제임 갱신 손실은 애플리케이션이 데이터베이스에서 값을 읽고

직렬성 격리는 가장 강력한 격리 수준여러 트랜잭션이 병렬로 실행되더라도 최종 결과는 동시성 없이 한 번에 하나씩 직렬로 실행될 때와 같도록 보장즉, 데이터베이스에서 발생할 수 있는 모든 경쟁조건을 막음말 그대로 한 번에 트랜잭션 하나씩만 직렬로 단일 스레드에서 실행하는

단일 시스템에서는 하드웨어가 올바르게 동작하면, 같은 연산은 항상 같은 결과를 냄(결정적)하드웨어 문제가 있으면 시스템은 완전히 실패하며, 성공과 실패 그 중간 상태가 되지는 않음분산 시트템에서는 시스템의 어떤 부분은 잘 동작하지만 다른 부분은 예측할 수 없는 방식으로

분산 시스템에서는 통신이 즉각적이지 않으므로 시간은 다루기 까다로움메시지를 받은 시간은 항상 보낸 시간보다 나중이지만 네트워크의 지연의 변동성 때문에 얼마나 나중일지는 알 수 없음게다가 네트워크에 있는 개별 장비는 자신의 시계를 갖고 있어 다른 장비보다 약간 빠를 수도

분산 시스템에는 공유 메모리가 없고 지연 변동이 큰 신뢰할 수 없는 네트워크를 통해 메시지를 보낼 수 있을 뿐이며 부분 장애, 신뢰성 없는 시계, 프로세스 중단이 발생할 수 있음네트워크에 있는 노드는 어떤 것도 확실히 알지 못함. 따라서 타임아웃을 사용해 상대 노드의

분산 시스템에서 발생할 수 있는 결함은 크게 세 가지네트워크에 의한 패킷 손실, 순서 뒤섞임, 임의의 시간 동안 지연시간의 오류노드가 죽음(ex. GC)이러한 결함이 발생하더라도 서비스는 올바르게 작동한다면, 이런 시스템은 내결함성(Fault Tolerance)를 지닌

단일 리더 복제에서 리더의 주 목적은 복제 로그에서 쓰기의 순서, 즉 팔로워가 쓰기를 적용하는 순서를 결정하는 것직렬성은 트랜잭션들이 마치 어떤 일련 순서에 따라 실행되는 것처럼 동작하도록 보장하는 것분산 시스템에서 타임스탬프와 시계 사용은 무질서한 세상에 질서를 부여

여러 노드들이 뭔가에 동의하게 만드는 것원자적 커밋여러 노드/파티션에 걸친 트랜잭션을 지원하는 데이터베이스에서는 트랜잭션의 원자성을 유지해야하며, 이를 위해서는 모든 노드가 트랜잭션의 결과에 동의하게 만들어야 함리더 선출단일 리더 복제 데이터베이스에서 모든 노드는 어떤

2단계 커밋으로 구현된 분산 트랜잭션에 대한 평판은 엇갈림한 가지 예로 MySQL의 분산 트랜잭션은 단일 노드 트랜잭션보다 10배 이상 느리다고 보고됨한편에서는 다른 방법으로 달성하기 어려운 중요한 안전성 보장을 제공하는 것으로 평가받음분산 트랜잭션의 두 가지 종류데이

단순하게 말해 합의란 어떤 노드(들)이 값을 제안하며, 합의 알고리즘이 그 값 중 하나를 결정하는 것. 이를 위해 달성해야 할 속성은 다음과 같음균일한 동의어떤 두 노드도 다르게 결정하지 않음무결성어떤 노드도 두 번 결정하지 않음유효성한 노드가 값 v를 결정한다면 v는

3부에서 다룰 내용1,2부에서는 단일 데이터베이스에 대해서 다룸하지만, 큰 애플리케이션에서는 단일 데이터베이스를 사용하는 것이 아니라, 대개 여러 다른 데이터스토어, 색인, 캐시, 분석 시스템 등을 조합해 사용함3부에서는 다양한 데이터 시스템을 일관성 있는 하나의 애플

서비스(온라인 시스템)서비스는 클라이언트로부터 요청이 올 때까지 기다림. 요청 하나가 들어오면 서비스는 가능한 빨리 요청을 처리해 응답하며, 응답 시간은 성능 측정의 중요한 지표로 작용함일괄 처리 시스템(오프라인 시스템)매우 큰 데이터를 받아 데이터를 처리하는 작업을

맵리듀스는 유닉스 도구와 비슷하지만, 수천 대의 장비로 분산해서 실행이 가능하다는 점에서 차이가 존재유닉스 도구와 마찬가지로 입력을 수정하지 않기 때문에 출력을 생산하는 것 외에 다른 부수 효과는 없음유닉스는 stdin과 stdout을 입력과 출력으로 사용하지만, 맵리

지난 포스팅에서 설명된 여러 조인 알고리즘은 실제 조인 로직을 리듀서에서 실행하기 때문에 리듀스 사이드 조인이라고 함리듀스 사이드 접근에서는 입력 데이터에 대한 특정한 가정이 필요하지 않음. 매퍼는 각 입력 레코드에서 키와 값을 추출해 리듀서 파티션으로 할당하고 키별로

2000년대 후반 맵리듀스는 가장 인기있는 분산 시스템의 프로그래밍 모델 중 하나였지만, 데이터 양, 자료 구조, 데이터를 처리하는 방식에 따라 다른 도구가 연산을 표현하는 데 더 적합할 수 있음그럼에도 불구하고 맵리듀스는 학습하기 매우 유용하며 단순함. 여기서 단순함

일괄 처리는 입력으로 파일 집합을 읽어 출력으로 새로운 파일 집합을 생성하는 기술출력은 파생 데이터 형태이며, 필요하다면 일괄 처리를 다시 수행해 재생성 가능한 데이터셋을 의미하지만 일괄 처리는 입력을 사전에 알려진 유한한 크기로 한정한다는 가정이 있음. 그리고 이는

브로커와 데이터베이스는 전통적으로 전혀 다른 범주의 도구로 생각되지만, 로그 기반 브로커는 데이터베이스에서 아이디어를 얻어 메시징에 적용함그렇다면 그 반대도 가능할 것. 메시징과 스트림에서 아이디어를 가져와 데이터베이스에 적용한 사례는?이벤트는 특정 시점에 발생한 사건

지금까지 스트림은 어디서 오는지(사용자 활동 이벤트, 센서, 데이터베이스에 쓰기)와 스트림이 어떻게 전송되는지(직접 메시징, 메시지 브로커, 이벤트 로그)에 대해 설명함스트림을 처리하는 방법에는 크게 세 가지가 있음이벤트에서 데이터를 꺼내 데이터베이스나 캐시, 검색 색

해당 장은 이전 장들의 정리 + 저자의 생각에 관한 내용으로 따로 정리하지 않기로 함한 번 읽어보는 정도면 충분할 듯