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

서평

• 데이터 처리의 기본기를 다지기에 좋은 참고서로 데이터 모델 설계, 질의 언어 , 복제, 트랜잭션, 일괄 처리, 스트림 처리 등 데이터 처리의 다양한 측면을 다루고있다. 이 책의 목적은 다양하고 빠르게 변하는 데이터 저장과 처리 기술 분야를 탐험하는데 도움을 준다. 책의 서문에는 다음과 같은 독자에게 추천하고 있다.
  • 데이터 시스템을 확장성 있게 만드는 방법을 알고 싶은 사람(웹 또는 모바일 앱이 수백만 명의 사용자를 감당할 수 있게 하고 싶다)
  • 애플리케이션이 고가용성을 갖춰야 하고(중단시간 최소화) 운영상 견고해야 함
  • 시스템 규모가 커지고 요구사항과 기술이 바뀌더라도 오랜 기간 쉽게 유지보수할 수 있는 방법을 찾고 있다.
  • 사물의 동작 방식에 대해 타고난 호기심이 있다. 대형 웹사이트와 온라인 서비스의 내부가 어떻게 돌아가는지 알고 싶다. 이책은 다양한 데이터베이스와 데이터 처리 시스템의 내부를 분해한다. 이런 시스템 설계에 반영된 기발한 생각을 탐험하는 것이 매우 즐겁다
• 데이터베이스가 데이터를 저장하는 방법과 데이터를 요청 했을 때 다시 찾을 수 있는 방법에 대해서 자세하게 설명 하고 있다. 애플리케이션 개발자가 데이터베이스에 데이터를 제공하는 형식과 나중에 다시 요청할 수 있는 메커니즘인 데이터 모델과 질의 언어에 대해 책으로 경험해 볼 수 있어서 좋았다.
• 이 책은 애플리케이션과 시스템을 신뢰할 수 있고 확장 가능하며 유지보수하기 쉽게 만드는 방법을 탐구하는 것으로 신뢰성 개선에 도움을 주는 많은 내결함성 알고리즘과 확장성을 개선하기 위한 파티셔닝, 그리고 유지보수성을 개선하기 위한 진화와 추상화 매커니즘에 대해 설명하고 있다. 책 전반에 걸쳐 데이터 시스템의 다양한 아키텍처와 각각의 장단점에 대해 설명하고 신뢰할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션을 구축하는 기술도 배울 수 있었다. 데이터 엔지니어로써 신입이 읽기에는 조금 난이도가 있지만 전반적인 책 내용은 많은 도움이 되었다.

데이터 시스템의 기초

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

• 애플리 케이션이 유용하려면 다양한 요구사항을 충족해야함
  • 기능적 요구 사항 : 여러 방법으로 데이터를 저장하고 조회하고 검색하고 처리하게끔 허용하는 작업과 같이 해야하는 일
  • 비기능적 요구사항 : 보안, 신뢰성, 법규 준수, 확장성, 호환성, 유지보수성과 같은 일반 속성
• 데이터 중심 애플리케이션(data-intensive application)은 기술적 발전을 활용해 실현 가능한 범위를 넓힘
  • 데이터 중심적(data-intensive) : 데이터 양, 데이터 복잡성, 데이터가 변하는 속도 등, 데이터가 주요 도전과제인 애플리케이션
  • 계산 중심적(compute-intensive) : CPU 사이클이 병목인 경우
    • 표준 구성 요소(standard building block)
      • 구동 어플리케이션이나 다른 애플리케이션에서 나중에 다시 데이터를 찾을 수 있게 데이터를 저장(데이터베이스)
      • 읽기 속도 향상을 위해 값비싼 수행 결과를 기억(캐시)
      • 사용자가 키워드로 데이터를 검색하거나 다양한 방법으로 필터링할 수 있게 제공(검색 색인(search index))
      • 비동기 처리를 위해 다른 프로세스로 메시지 보내기(스트림 처리(stream processing))
      • 주기적으로 대량의 누적된 데이터를 분석(일괄 처리(batch processing))
• 데이터 시스템에 대한 생각
  • 레디스(Redis) : 메시지 큐로 사용하는 데이터 스토어
  • 아파치 카프카(Apache Kafka) : 데이터베이스처럼 지속성(durability)을 보장하는 메시지 큐
  • 복합 데이터 시스템(composite data system) : 외부 클라이언트가 일관된 결과를 볼 수 있게끔 쓰기에서 캐시를 올바르게 무효화하거나 업데이트하는 등의 특정 보장 기능을 제공함
• 신뢰성(Reliability) : 결함이 발생해도 시스템이 올바르게 동작하게 만든다
  • 하드웨어나 소프트웨어 결함, 심지어 인적 오류 같은 역경에 직면하더라도 시스템은 지속적으로 올바르게 동작
  • 기대치
    • 애플리케이션은 사용자가 기대한 기능을 수행함
    • 시스템은 사용자가 범한 실수나 예상치 못한 소프트웨어 사용법을 허용함
    • 시스템 성능은 예상된 부하와 데이터 양에서 필수적인 사용 사례를 충분히 만족함
    • 시스템은 허가되지 않은 접근과 오남용을 방지함
  • 내결함성(fault-tolerant) 또는 탄력성(resilient) : 결함을 예측하고 대처할 수 있는 시스템
    • 결함 : 사양에서 벗어난 시스템의 한 구성 요소
    • 장애 : 사용자에게 필요한 서비스를 제공하지 못하고 시스템 전체가 멈춘 경우
  • 하드웨어 결함
    • 하드디스크가 고장 나고, 램에 결함이 생기고, 대규모 정전 사태가 발생하고, 누군구가 네트워크 케이블을 잘못 뽑는 것과 같은 결함
    • 시스템 장애율을 줄이기 위해 각 하드웨어 구성 요소에 중복(redundancy)을 추가하는 방법
  • 소프트웨어 오류
    • 시스템 내 체계적 오류(systematic error)
      • 잘못된 특정 입력이 있을 때 모든 애플리케이션 서버 인스턴스가 죽는 소프트웨어 버그
      • CPU 시간, 메모리, 디스크 공간, 네트워크 대역폭처럼 공유 자원을 과도하게 사용하는 일부 프로세스
      • 시스템의 속도가 느려져 반응이 없거나 잘못된 응답을 반환하는 서비스
      • 한 구성 요소의 작은 결함이 다른 구성 요소의 결함을 야기하고 차례차례 더 많은 결함이 발생하는 연쇄 장애(cascading failure)
  • 인적 오류
    • 실제 사용자에게 영향이 없는 비 프로덕션 샌드박스(sandbox)를 제공
    • 롤아웃(roll out) : 예상치 못한 버그가 일부 사용자에게만 영향이 미치게함
    • 모니터링 = 원경 측정(telemtery)
• 확장성(Scalability) : 부하가 증가해도 좋은 성능을 유지하기 위한 전략
  • 시스템의 양, 트래픽 양, 복잡도가 증가하면서 이를 처리할 수 있는 적절한 방법
  • 부하 기술하기
    • 시스템의 현재 부하를 간결하게 기술
    • 부하 매개변수(load parameter) : 웹 서버의 초당 요청 수, 데이터베이스의 읽기 대 쓰기 비율, 대화방의 동시 활성 사용자(active user), 캐시 적중률 등
  • 성능 기술하기
    • 시스템의 부하를 기술하면 부하가 증가할 때 어떤 일이 일어나는지 조사
      • 부하 매개변수를 증가시키고 시스템 자원(CPU,메모리,네트워크 대여폭 등)은 변경하지 않고 유지하면 시스템 성능은 어떻게 영향을 받을까?
      • 부하 매개변수를 증가시켰을 때 성능이 변하지 않고 유지되길 원한다면 자원을 얼마나 많이 자원을 늘려야 할까?
      • 성능 수치 필요
        • 하둡 같은 일과 처리 시스템 -> 처리량(throughput: 초당 처리할 수 있는 레코드 수나 일정 크기의 데이터 집합으로 작업을 수행할 때 걸리는 전체 시간)
        • 온라인 시스템 : 서비스 응답 시간(response time) - 클라이언트가 요청을 보내고 응답을 받는 사이의 시간
          • 응답 시간(response time) : 클라이언트 관점에서 본 시간, 요청을 처리하는 실제 시간(서비스 시간) 외에도 네트워크 지연과 큐 지연도 포함함
          • 지연 시간(latency) : 요청이 처리되길 기다리는 시간, 서비스를 기다리며 휴지(latent) 상태인 시간
    • 추가 지연을 일으키는 여러 원인
      • 백그라운드 프로세스의 컨텍스트 스위치(context switch), 네트워크 패킷 손실과 TCP 재전송, 가비지 컬렉션 휴지(garbage collection pause), 디스크에서 읽기를 강제하는 페이지 폴트(page fault), 서버 랙의 기계적인 진동
    • 백분위
      • 중앙값, 50분위, p50
      • 95분위, 99분위, 99.9분위(p95,p99,p999(
      • 서비스 수준 목표(service level objective,SLO)와 서비스 수준 협약서(service level agreement,SLA)에 자주 사용하고 기대 성능과 서비스 가용성을 정의하는 계약서에도 자주 등장
    • 선두 차단(head-of-line blocking) : 서버는 병렬로 소수의 작업만 처리할 수 있기 때문에(ex-CPU 코어수에 제한됨) 소수의 느린 요청 처리만으로도 후속 요청 처리가 지체됨
  • 부하 대응 접근 방식
    • 용량 확장(scaling up, 수직확장 vertical scaling) : 좀 더 강력한 장비로 이동
    • 규모 확장(scaling out, 수평확장 horizontal scaling) : 다수의 낮은 사양 장비에 부하를 분산
    • 비공유 아키텍처(shared-nothing) : 다수의 장비에 부하를 분산하는 아키텍처
    • 탄력적(elastic) : 부하 증가를 감지하면 컴퓨팅 자원을 자동으로 추가
    • 아키텍처를 결정하는 요소 : 읽기의 양, 쓰기의 양 ,저장할 데이터의 양, 데이터의 복잡도, 응답 시간 요구사항, 접근 패턴 등
• 유지보수성(Maintainability)
  • 시스템에서 작업하는 엔지니어와 운영 팀의 삶을 개선, 좋은 추상화는 복잡도를 줄이고 쉽게 시스템을 변경할 수 있께하며 새로운 사용 사례에 적용
  • 좋은 운용성이란 시스템의 건강 상태를 잘 관찰할 수 있고 시스템을 효율적으로 관리하는 방법을 보유
  • 시간이 지남에 따라 여러 다양한 사람들이 시스템 상에서 작업할 것이기 때문에 모든 사용자가 시스템 상에서 생산적으로 작업할 수 있게 함
  • 버그 수정, 시스템 운영 유지, 장애 조사, 새로운 플랫폼 적응, 새 사용 사례를 위한 변경, 기술 채무(technical debt) 상환, 새로운 기능 추가 등
  • 소프트웨어 시스템 설계 원칙
    • 운용성(operability) : 운영의 편리함 만들기
      • 운영팀이 시스템을 원활하게 운영할 수 있게 쉽게 만들기
      • 좋은 운영팀
        • 시스템 상태를 모니터링하고 상태가 좋지 않다면 빠르게 서비스를 복원
        • 시스템 장애, 성능 저하 등의 문제를 원인을 추적
        • 보안 패치를 포함해 소프트웨어와 플랫폼을 최신 상태로 유지
        • 다른 시스템이 서로 어떻게 영향을 주는지 확인해 문제가 생길 수 있는 변경 사항을 손상을 입히기 전에 차단
        • 미래에 발생가능한 문제를 예측해 문제가 발생하기 전에 해결(용량 계획)
        • 배포, 설정 관리 등을 위한 모범 사례와 도구를 마련
        • 애플리케이션을 특정 플랫폼에서 다른 플랫폼으로 이동하는 등 복잡한 유지보수 태스크를 수행
        • 설정 변경으로 생기는 시스템 보안 유지보수
        • 예측 가능한 운영과 안정적인 서비스 환경을 유지하기 위한 절차 정의
        • 개인 인사 이동에도 시스템에 대한 조직의 지식을 보존함
      • 데이터 시스템은 동일 반복 태스크를 쉽게 하기 위해서
        • 좋은 모니터링으로 런타임 동작과 시스템의 내부에 대한 가시성 제공
        • 표준 도구를 이용해 자동화와 통합을 위한 우수한 자원을 제공
        • 개별 장비 의존성을 회피, 유지보수를 위해 장비를 내리더라도 시스템 전체에 영향을 주지 않고 계속해서 운영 가능해야 함
        • 좋은 문서와 이해하기 쉬운 운영 모델(ex- X를 하면 Y가 발생한다) 제공
        • 만족할 만한 기본 동작을 제공하고, 필요할 때 기본값을 다시 정으히라 수 있는 자유를 관리자에게 부여
        • 적절하게 자기 회복(self-healing)이 가능할 뿐 아니라 필요에 따라 관리자에게 시스템 상태를 수동으로 제어할 수 있게 함
        • 예측 가능하게 동작하고 예기치 않은 상황을 최소화함
    • 단순성(simplicity) : 복잡도 관리
      • 시스템에서 복잡도를 최대한 제거해 새로운 엔지니어가 시스템을 이해하기 쉽게 만들어라
      • 복잡도 : 같은 시스템에서 작업해야하는 모든 사람의 진행을 느리게 하고 나아가 유지보수 비용이 증가
        • 증상 : 상태 공간의 급증, 모듈 간 강한 커플링(tight coupling), 복잡한 의존성, 일관성 없는 명명(naming)과 용어,성능 문제 해결을 목표로 한 해킹, 임시방편으로 문제를 해결한 특수 사례(specital-casing)
    • 발전성(evolvability)
      • 엔지니어가 이후에 시스템을 쉽게 변경할 수 있게 해라, 예기치 않은 사용 사례를 적용하기가 쉬움 -> 유연성(extensibility), 수정 가능성(modifiability), 적응성(plasticity)
      • 조직 프로세스 측면에서 애자일(agile) 작업 패턴은 변화에 적응하기 위한 프레임워크를 제공
      • 애자일 커뮤니티는 테스트 주도 개발(test-driven development(TDD))과 리팩토링(refactoring) 같이 자주 변화하는 환경에서 소프트웨어를 개발할때 도움이 되는 기술 도구와 패턴을 개발

데이터 모델과 질의 언어

• 데이터 모델
  • 데이터 모델은 소프트웨어가 어떻게 작성됐는지 뿐만 아니라 해결하려는 문제를 어떻게 생각해야 하는지에 대해서도 지대한 영향을 미침
  • 하위 계층 관점에서 데이터 모델을 표현하는 방법
    • 애플리케이션 개발자는 현실(사람,조직,상품,행동,자금 흐름, 센서 등)을 보고 객체나 데이터 구조, 그리고 이러한 데이터 구조를 다루는 API를 모델링함, 이런 구조는 보통 애플리케이션에 특화됌
    • 데이터 구조를 저장할 때는 JSON이나 XML 문서, 관계형 데이터 베이스 테이블이나 그래프 모델 같은 범용 데이터 모델로 표현함
    • 데이터베이스 소프트웨어를 개발하는 엔지니어는 JSON/XML/관계형/그래프 데이터를 메모리나 디스크 또는 네트워크 상의 바이트 단위로 표현하는 방법을 결정함, 이 표현은 다양한 방법으로 데이터를 질의, 탐색, 조작, 처리할 수 있게 함
    • 더 낮은 수준에서 하드웨어 엔지니어는 전류, 빛의 파동, 자기장 등의 관점에서 바이트를 표현하는 방법을 알아냄
• 관계형 모델과 문서 모델
  • 데이터는 (SQL에서 테이블이라 불리는) 관계(relation)로 구성되고 각 관계는 순서 없는 튜플(tuple)(SQL에서 로우(row)) 모음
  • 트랜잭션 처리(영업이나 은행거래, 항공 계약, 창고에 재고 보관)와 일괄 처리(고객 송장 작성, 급여 지불, 보고)
• NoSQL
  • Not Only SQL
  • 원동력
    • 대규모 데이터셋이나 매우 높은 쓰기 처리량 달성을 관계형 데이터베이스보다 쉽게 할 수 있는 뛰어난 확장성의 필요
    • 상용 데이터베이스 제품보다 무료 오픈소스 소프트웨어에 대한 선호도 확산
    • 관계형 모델에서 지원하지 않는 특수 질의 동작
    • 관계형 스키마의 제한에 대한 불만과 더욱 동적이고 표현력이 풍부한 데이터 모델에 대한 바람
• 객체 관계형 불일치
  • 임피던스 불일치(impedance mismatch) : 데이터를 관계형 테이블에 저장하려면 애플리케이션 코드와 데이터베이스 모델 객체(테이블, 로우 , 칼럼) 사이에 거추장스러운 전환 계층이 필요한데 모델 사이의 분리를 뜻함
  • 관계형 모델이 하는 일은 알려진 모든 데이터를 배치하는 것, 관계(테이블)는 단순히 튜플(로우)의 컬렉션이 전부
• 스키마 유연성
  • 쓰기 스키마(schema-on-write) : 관계형 데이터베이스의 전통적인 접근 방식으로 스키마는 명시적이고 데이터 베이스는 쓰여진 모든 데이터가 스키마를 따르고 있음을 보장함
    • 정적(컴파일 타임) 타입 확인과 비슷
  • 읽기 스키마(schema-on-read) : 데이터 구조는 암묵적이고 데이터를 읽을 때만 해석됨
    • 프로그래밍 언어에서 동적(런타임) 타입 확인과 유사
• 질의를 위한 데이터 지역성
  • 문서는 보통 JSON, XML로 부호화된 단일 연속 문자열이나 (몽고 DB의 BSON 같은) JSON 또는 XML의 이진 변형으로 저장됨
• 맵리듀스 질의
  • 맵리듀스(MapReduce) : 컴퓨터에서 대량의 데이터를 처리하기 위한 프로그래밍 모델, 여러 함수형 프로그래밍 언어에 있는 map(collect라고도 함)과 reduce(fold나 inject라고도 함) 함수를 기반으로 함
• 그래프형 데이터 모델
  • 두 유형의 객체로 이루어짐
    • 정점(vertex) : 노드나 엔터티
      • 고유한 식별자
      • 유출(outgoing) 간선 집합
      • 유입(incoming) 간선 집합
      • 속성 컬렉션(키-값 쌍)
    • 간선(edge) : 관계나 호(arc)
      • 고유한 식별자
      • 간선이 시작하는 정점(꼬리 정점)
      • 간선이 끝나는 정점(머리 정점)
      • 두 정점 간 관계 유형을 설명하는 레이블
      • 속성 컬렉션(키-값 쌍)
    • 예시
      • 소셜 그래프 : 정점은 사람이고 간선은 사람들이 서로 알고 있음을 나타냄
      • 웹 그래프 : 정점은 웹페이지고 간선은 다른 페이지에 대한 HTML 링크를 나타냄
      • 도로나 철도 네트워크 : 정점은 교차로이고 간선은 교차로나 간 도로나 철로 선을 나타냄
• 사이퍼 질의 언어
  • 사이퍼(Cypher) : 속성 그래프를 위한

저장소와 검색

• 실제 데이터베이스 문제 : 동시성 제어, 로그가 영원히 커지지 않게끔 디스크 공간을 회수, 오류 처리, 부분적으로 기록된 레코드 처리
• 색인 : 어떤 부가적인 메타데이터를 유지하는 것
• 실제 구현에서 중요한 문제
  • 파일 형식
    • CSV는 로그에 가장 적합한 형식이 아님, 바이트 단위의 문자열 길이를 부호화한 다음 원시 문자열을 부호화하는 바이너리 형식을 사용하는 편이 더 빠르고 간단함
  • 레코드 삭제
    • 키와 관련된 값을 삭제하려면 데이터 파일에 특수한 레코드(툼스톤(tombstone)라 불림)를 추가해야함, 로그 세그먼트가 병합될 때 툼스톤은 병합 과정에서 삭제된 키의 이전 값을 무시함
  • 고장(Crash) 복구
    • 데이터베이스가 재시작되면 인메모리 해시 맵은 손실됨, 원칙적으로는 전체 세그먼트 파일을 처음부터 끝까지 읽고 각 키에 대한 최신 값의 오프셋을 확인해서 각 세그먼트 해시 맵을 복원할 수 있음
  • 부분적으로 레코드 쓰기
    • 데이터베이스는 로그에 레코드를 추가하는 도중에도 죽을 수 있음, 비트캐스크 파일은 체크섬을 포함하고 있어 로그의 손상된 부분을 탐지해 무시할 수 있음
  • 동시성 제어
    • 쓰기를 엄격하게 순차적으로 로그에 추가할 때 일반적인 구현 방법은 하나의 쓰기 스레드만 사용하는 것 , 데이터 파일 세그먼트는 추가 전용이거나 불변(immutable)이므로 다중 스레드로 동시에 읽기를 할 수 있음
• B트리
  • 전통적으로 4KB 크기(때로는 더 큰)의 고정 크기 블록이나 페이지로 나누고 한 번에 하나의 페이지에 읽기 또는 쓰기를 함
  • 로그 구조화 색인 : 데이터베이스를 일반적으로 수 메가바이트 이상의 가변 크기를 가진 세그먼트로 나누고 항상 순차적으로 세그먼트를 기록
• 다중 칼럼 색인
  • 결합 색인(concatenated index)
    • 하나의 칼럼에 다른 칼럼을 추가하는 방식으로 하나의 키에 여러 필드를 단순히 결합함
• 트랜잭션 처리와 분산 시스템의 특성 비교

특성	트랜잭션 처리 시스템(OLTP)	분석 시스템(OLAP)
주요 읽기 패턴	질의당 적은 수의 레코드, 키 기준으로 가져옴	많은 레코드에 대한 집계
주요 쓰기 패턴	임의 접근, 사용자 입력을 낮은 지연 시간으로 기록	대규모 불러오기(bulk import, ETL) 또는 이벤트 스트림
주요 사용처	웹 애플리케이션을 통한 최종 사용자/소비자	의사결정 지원을 위한 내부 분석가
데이터 표현	데이터의 최신 상태(현재 시점)	시간이 지나며 일어난 이벤트 이력
데이터셋 크기	기가바이트에서 테라바이트	테라바이트에서 페타바이트

• 데이터 웨어하우징
  • 데이터웨어하우스 : 분석가들이 OLTP 작업에 영향을 주지 않고 마음껏 질의할 수 있는 개별 데이터베이스
  • ETL(Extract-Transform-Load) : OLTP 데이터베이스에서(주기적인 데이터 덤프나 지속적인 갱신 스트림을 사용해) 추출(extract)하고 분석 친화적인 스키마로 변환(transform) 하고 깨끗하게 정리한 다음 데이터 웨어하우스에 적재(load)함
• 드릴 다운 : 요약된 정보에서 상세 정보까지 계층을 나눠 점점 구체적으로 분석하는 작업
• 슬라이싱과 다이싱 : 상세한 분석을 위해 주어진 큰 규모의 데이터를 작은 단위로 나누고 원하는 세부 분석 결과를 얻을 때까지 반복함
• 분석용 스키마 : 별 모양 스키마와 눈꽃송이 모양 스키마
  • 별 모양 스키마(star schema)(차원 모델링(dimensional modeling))
    • 테이블 관계가 시각화될 때 사실 테이블이 가운데에 있고 차원 테이블로 둘러싸고 있다는 사실에 비롯됌
  • 눈꽃송이 모양 스키마(snowflake schema) : 차원이 하위차원으로 더 세분화됨
  • 스키마 중심에 소위 사실 테이블(fact table)
    • 사실 테이블의 각 로우는 특정 시각에 발생한 이벤트에 해당
    • 차원 테이블(dimension table) 다른 테이블을 가리키는 외래 키 참조
• OLTP 시스템은 보통 사용자 대면이기 때문에 대량의 요청을 받을 수 있음, 부하를 처리하기 위해 보통 애플리케이션이 각 질의마다 작은 수의 레코드만 다룸, 애플리케이션은 키의 일부만 사용하는 레코드를 요청하고 저장소 엔진은 요청한 키의 데이터를 찾기 위해 색인을 사용함, 디스크 탐색이 병목
• 데이터 웨어하우스와 유사한 분석 시스템은 최종 사용자가 아닌 비즈니스 분석가가 주로 사용하기 때문에 덜 알려져 있음, OLTP시스템보다 훨씬 더 적은 수의 질의를 다루지만 각 질의는 대개 매우 다루기 어렵고 짧은 시간에 수백만 개의 레코드를 스캔해야함, 일반적으로 디스크 대역폭(디스크 탐색이 아닌)이 병목, 칼럼 지향 저장소는 이런 종류의 작업부하를 처리할 때 사용 가능한 날로 인기가 높아지고 있는 솔루션
• OLTP 관점
  • 로그 구조화 관점에서 파일에 추가와 오래된 파일의 삭제만 허용하고 한 번 쓰여진 파일을 절대 갱신하지 않음, 비트캐스크, SS테이블, LSM 트리, 레벨DB, 카산드라, HBase, 루씬 등이 이 그룹에 속함
  • 제자리 갱신 관점에서 덮어쓰기 할 수있는 고정 크기 페이지의 셋으로 디스크를 다룸, 이 관점에서 가장 큰 예가 B트리, B트리는 모든 주요 관계형 데이터베이스와 많은 비정형 데이터베이스에서도 사용함

부호와와 발전

• 데이터 부호화 형식
  • 메모리에 객체(object), 구조체(struct), 목록(list), 배열(array), 해시 테이블(hash table), 트리(tree) 등으로 데이터가 유지됨
  • 인메모리 표현에서 바이트열로의 전환을 부호화(직렬화,마샬링), 그 반대로 복호화(파싱, 역직렬화, 언마샬링)
  • XML과 CSV에서는 수와 숫자(digit)로 구성된 문자열을 구분할 수 없다(외부 스키마 참조는 제외). JSON 문자열과 수를 구분하지만 정수와 부동소수점 수를 구별하지 않고 정밀도를 지정하지 않음
• 쓰기 스키마와 읽기 스키마
  • 쓰기 스키마(writer's schema)
    • 애플리케이션이 파일이나 데이터베이스에 쓰기 위해 또는 네트워크를 통해 전송 등의 목적으로 어떤 데이터를 아브로로 부화하길 원한다면 알고 있는 스키마 버전을 사용해 데이터를 부호화함
  • 읽기 스키마(reader's schema)
    • 애플리케이션이 파일이나 데이터베이스에서 또는 네트워크로부터 수신 등으로 읽은 어떤 데이터를 복호화하길 원한다면 데이터가 특정 스키마로 복호화하길 기대함
• 서비스를 통한 데이터플로 : REST와 RPC
  • 서버 : 네트워크를 통해 API를 공개
  • 클라이언트 : API로 요청을 만들어 서버에 연결할 수 있음
  • 서비스 : 서버가 공개한 API
  • 웹의 동작 방식
    • 클라이언트(웹 브라우저)는 웹 서버로 요청을 보냄, HTML,CSS,자바스크립트,이미지 등을 다운로드 하기 위해서는 GET 요청을 보내고, 서버로 데이터를 전송하기 위해서는 POST 요청을 보냄, API는 표준화된 프로토콜과 데이터 타입(HTTP,URL,SSL/TLS,HTML 등)으로 구성됨, 웹 브라우저, 웹 서버, 웹 사이트 작성자 대부분이 이 표준에 동의하기 때문에 모든 웹 브라우저로 모든 웹 사이트에 접근 할 수 있음
• 웹 서비스
  • REST는 간단한 데이터 타입을 강조하며 URL을 사용해 리소스를 식별하고 캐시 제어, 인증, 콘텐츠 유형 협상에 HTTP 기능을 사용함
  • RESTful : REST 원칙에 따라 설계된 API
  • SOAP : 네트워크 API 요청을 위한 XML 기반 프로토콜 , HTTP 상에서 가장 일반적으로 사용되지만 HTTP와 독립적이며 대부분의 HTTP 기능을 사용하지 않음
• 분산 액터 프레임워크
  • 액터 모델(actor model) : 단일 프로세스 안에서 동시성을 위한 프로그래밍 모델
  • 아카(Akka) : 기본적으로 자바의 내장 직렬화를 사용, 상위 호환성이나 하위 호환성을 제공하지 않음
  • 올리언스(Orleans) : 기본적으로 사용자 정의 데이터 부호화 형식을 사용함
  • 얼랭(erlang)

분산 데이터

• 여러 장비 간 분산된 데이터베이스를 필요로 하는 이유
  • 확장성
    • 데이터 볼륨, 읽기 부하, 쓰기 부하가 단일 장비에서 다룰 수 있는 양보다 커지면 부하를 여러 장비로 분배할 수 있음
  • 내결함성/고가용성
    • 장비 하나(또는 여러 장비나 네트워크, 전체 데이터센터)가 죽더라도 애플리케이션이 계속 동작해야 한다면 여러 장비를 사용해 중복성을 제공할 수 있음, 장비 하나가 실패하면 다른 하나가 이어받음
  • 지연 시간
    • 전 세계에 사용자가 있다면 사용자와 지리적으로 가까운 곳의 데이터센터에서 서비스를 제공하기 위해 전 세계 다양한 곳에 서버를 두고 싶을 것
• 고부하로 확장
  • 더 강력한 장비를 구매하는것(수직확장, 용량 확장)
  • 많은 CPU, 많은 메모리 칩, 많은 디스크를 하나의 운영체제로 함께 결합함
  • 공유 메모리 아케틱처(shared-memory architecture)
• 비공유 아키텍처(shared-nothing) - 수평 확장, 규모 확장
  • 노드 : 데이터베이스 소프트웨어를 수행하는 각 장비나 가상 장비
• 복제 대 파티셔닝
  • 복제 : 같은 데이터의 복사본을 잠재적으로 다른 위치에 있는 여러 노드에 유지함
  • 파티셔닝 : 큰 데이터베이스를 파티션이라는 작은 서브넷으로 나누고 각 파티션은 각기 다른 노드에 할당함(샤딩)

복제

• 다양한 용도로 사용
  • 고가용성 : 한 장비(또는 여러 장비나 전체 데이터 센터)가 다운될 때도 시스템이 계속 동작하게 함
  • 연결이 끊긴 작업 : 네트워크 중단이 있을 때도 애플리케이션이 계속 동작할 수 있게 함
  • 지연 시간 : 지리적으로 사용자에게 가까이 데이터를 배치해 사용자가 더 빠르게 작업할 수 있게 함
  • 확장성 : 복제본에서 읽기를 수행해 단일 장비에서 다룰 수 있는 양보다 많은 양의 읽기 작업을 처리할 수 있음
• 네트워크로 연결된 여러 장비에 동일한 데이터의 복사본을 유지
  • 지리적으로 사용자와 가깝게 데이터를 유지해 지연 시간을 줄임
  • 시스템의 일부에 장애가 발생해도 지속적으로 동작할 수 있게 해 가용성을 높임
  • 읽기 질의를 제공하는 장비의 수를 확장해 읽기 처리량을 늘림
• 3가지 주요 접근 방식
  • 단일 리더 복제 : 클라이언트는 모든 쓰기를 단일 노드(리더)로 전송하고 리더는 데이터 변경 이벤트 스트림을 다른 복제 서버(팔로워)로 전송함
  • 다중 리더 복제 : 클라이언트는 각 쓰기를 여러 리더 노드 중 쓰기를 받아들일 수 있는 노드로 전송함
  • 리더 없는 복제 : 클라이언트는 각 쓰기를 여러 노드로 전송함
• 리더와 팔로워
  • 복제 서버(replica) : 데이터베이스의 복사본을 저장하는 각 노드
  • 데이터베이스의 모든 쓰기는 모든 복제 서버에서 처리돼야함
  • 리더기반 복제(leader-based replication, 능동/수동, 마스터 슬레이브 복제) : 복제 서버 중 하나를 리더(마스터나 프라이머리)로 지정함
  • 팔로워(follower, 읽기 복제 서버(read replica), 슬레이브, 2차, 핫 대기(hot standby)) : 리더가 로컬 저장소에 새로운 데이터를 기록할 때마다 데이터변경을 복제 로그(replication log)나 변경 스트림(change stream)의 일부로 팔로워에게 전송함
• 동기식 대 비동기식 복제
  • 동기식 : 리더는 팔로워 1이 쓰기를 수신했는지 확인해줄 때까지 기다림, 확인이 끝나면 사용자에게 성공을 보고하고 다른 클라이언트에게 해당 쓰기를 보여줌
    • 동기식 복제의 장점 : 팔로워가 리더와 일관성 있게 최신 데이터 복사본을 가지는 것을 보장함
    • 단점 : 동기 팔로워가 응답하지 않는다면 쓰기가 처리될 수 없음, 리더는 모든 쓰기를 차단(block)하고 동기 복제 서버가 다시 사용할 수 있을때 까지 기다려야함
  • 비동기식 : 리더는 메시지를 전송하지만 팔로워의 응답을 기다리지 않음
    • 시스템이 원활히 동작할 때는 빠르지만 복제 지연이 증가하고 서버 장애가 발생하면 어떤 일이 일어났는지 파악하는 작업이 중요함
  • 반동기식(semi-synchronous) : 두 노드(리더와 하나의 동기팔로워)에 데이터의 최신 복사본이 있는 것을 보장함
• 리더 장애 : 장애 복구
  • 자동 장애 복구
    • 리더가 장애인지 판단함 : 고장,정전,네트워크 문제 등 잠재적으로 여러가지가 잘못될 수 있음
    • 새로운 리더를 선택함 : 새로운 리더로 가장 적합한 후보는 보통 이전리더의 최신 데이터 변경사항을 가진 복제 서버
    • 새로운 리더 사용을 위해 시스템을 재설정함 :요청 라우팅
• 쓰기 전 로그 배송
  • 일반적으로 모든 쓰기는 로그에 기록함
    • 로그 구조화 저장소 엔진의 경우 로그 자체가 저장소의 주요 부분, 로그 세그먼트는 작게 유지되고 백그라운드로 가비지 컬렉션을 함
    • 개별 디스크 블록에 덮어쓰는 B 트리의 경우 모든 변경은 쓰기 전 로그(Write-ahead log, WAL)에 쓰기 때문에 고장 이후 일관성 있는 상태로 색인을 복원함
• 다중 리더 복제 토폴로지
  • 복제 토폴로지 : 쓰기를 한 노드에서 다른 노드로 전달하는 통신 결로를 설명함
  • 암시된 핸드오프 : 네트워크 장애 상황이 해제되면 한 노드가 다른 노드를 위해 일시적으로 수용한 모든 쓰기를 해당 홈 노드로 전송
• 최종 쓰기 승리(LWW, 동시 쓰기 버리기)
  • 최종적 수렴 달성이 목표지만 지속성을 희생함, 동일한 키에 여러 번의 동시 쓰기가 있다면 클라이언트에게 모두 성공으로 보고될지라도(w개의 복제 서버에 쓰여졌기 때문에) 쓰기 중 하나만 남고 다른 쓰기는 조용히 무시됨
  • 이전 발생(happens-before) : 작업 B가 작업 A에 대해서 알거나 A에 의존적이거나 어떤 방식으로든 A를 기반으로 한다면 작업 A는 작업 B의 이전발생
  • 동시작업 : 작업이 다른 작업보다 먼저 발생하지 않는 경우
• 동시에 쓴 값 병합
  • 형제(sibling) : 여려 작업이 동시에 발생하면 클라이언트는 동시에 쓴 값을 합쳐 정리해야함
  • 툼스톤 : 시스템은 형제를 병합할 때 상품을 제거했음을 나타내기 위해 해당 버전 번호에 표시를 남겨둬야함
  • 버전 벡터(version vector) : 모든 복제본의 버전 번호 모음
• 복제 지연
  • 쓰기 후 일관성 : 사용자는 자신이 제출한 데이터를 항상 볼 수 있어야 함
  • 단조 읽기 : 사용자가 어떤 시점에 데이터를 본 후에는 예전 시점의 데이터는 나중에 볼 수 없음
  • 일관된 순서로 읽기 : 사용자는 인과성이 있는 상태의 데이터를 봐야 함

파티셔닝

• 샤딩 : 데이터셋이 매우 크거나 질의 처리량이 매우 높다면 복제만으로는 부족하고 데이터를 파티션으로 쪼갤 필요가 있음
  • 파티션 : 몽고DB, 엘라스틱서치, 솔라클라우드의 샤드(shard), HBase에서는 리전, 빅데이틀에서는 태블릿, 카산드라와 리악에서는 브이노드, 카우치베이스에서는 브이버켓
• 파티셔닝 기법
  • 키 범위 파티셔닝 : 키가 정렬돼 있고 개별 파티션은 어떤 최솟값과 최댓값 사이에 속하는 모든 키를 담당함
  • 해시 파티셔닝 : 각 키에 해시 함수를 적용하고 개별 파티션은 특정 범위의 해시값을 담당함
• 보조 색인
  • 문서 파티셔닝 색인(지역 색인) : 보조 색인을 기본키와 값이 저장된 파티션에 저장함
  • 용어 파티셔닝 색인(전역 색인) : 색인된 값을 사용해서 보조 색인을 별도로 파티셔닝함
• 키-값 데이터 파티셔닝
  • 파티셔닝의 목적 : 데이터와 질의 부하를 노드 사이에 고르게 분산
  • 쏠렸다(skewed) : 파티셔닝이 고르게 이뤄지지 않아 다른 파티션보다 데이터가 많거나 질의를 많이 받는 파티션
  • 핫스팟 : 불균형하게 부하가 높은 파티션
    • 피하는 방법: 레코드를 할당할 노드를 무작위로 선택하는것 -> 데이터가 노드들 사이에 매우 고르게 분산되지만 커다란 단점 존재 -> 어떤 레코드를 읽으려고 할 때 해당 레코드가 어느 노드에 저장됐는지 알 수 없으므로 모든 노드에서 병렬적으로 질의를 실행해야함
• 키 범위 기준 파티셔닝
  • 종이백과사전, 각 파티션에 연속된 범위(어떤 최솟값에서 최댓값까지)의 키를 할당하는 것, 각 범위들 사이의 경계를 알면 어떤 키가 어느 파티션에 속하는지 쉽게 찾을 수 있음, 어떤 파티션이 어느 노드에 할당됐는지 알면 적절한 노드로 요청을 직접 보낼수 있음
• 키의 해시값 기준 파티셔닝
  • 쏠림과 핫스팟의 위험 때문에 많은 분산 데이터스토어는 키의 파티션을 정하는 데 해시 함수를 사용함
  • 일관성 해싱 : 키를 파티션 사이에 균일하게 분산시킴, 파티션 경계는 크기가 동일하도록 나눌 수도 있고 무작위에 가깝게 선택할 수 있음
    • CDN(content delivery network) 같은 인터넷 규모의 캐시 시스템에서 부하를 균등하게 분산시키는 방법
    • 중앙 제어나 분산 합의(distributed consensus)가 필요하지 않도록 파티션 경계를 무작위로 선택함
• 파티셔닝과 보조 색인
  • 스캐터/개더(scatter/gather) : 파티셔닝된 데이터베이스에 질의를 보내는 방법
  • 지역 색인 : 각 파티션이 자신만의 보조 색인을 갖게 함
  • 전역 색인 : 모든 파티션의 데이터를 담당함
• 파티션의 재균형화
  • 시간이 지날 때 데이터베이스의 변화
    • 질의 처리량이 증가해서 늘어난 부하를 처리하기 위해 CPU를 더 추가하고 싶음
    • 데이터셋 크기가 증가해서 데이터셋 저장에 사용할 디스크와 램을 추가하고 싶음
    • 장비에 장애가 발생해서 그 장비가 담당하던 역할을 다른 장비가 넘겨받아야 함
  • 재균형화(rebalancing) : 클러스터에서 한 노드가 담당하던 부하를 다른 노드로 옮기는 과정
    • 재균형화 후, 부하(데이터 저장소 ,읽기 쓰기 요청)가 클러스터 내에 있는 노드들 사이에 균등하게 분배돼야 함
    • 재균형화 도중에도 데이터베이스는 읽기 쓰기 요청을 받아들여야 함
    • 재균형화가 빨리 실행되고 네트워크와 디스크 I/O 부하를 최소화할 수 있도록 노드들 사이에 데이터가 필요 이상으로 옮겨져서는 안 됨
    • 파티션 개수 고정 : 파티션을 노드 대수보다 많이 만들고 각 노드에 여러 파티션을 할당 함
    • 파티션이 너무 크면 재균형화를 실행할 때와 노드 장애로부터 복구할 때 비용이 큼, 그러나 파티션이 너무 작으면 오버헤드가 너무 커짐, 파티션 개수는 고정돼 있고 데이터셋 크기는 변한다면 적절한 크기를 정하기 어려움
• 운영: 자동 재균형화와 수동 재균형화
  • 완전 자동 재균형화(관리자의 개입이 전혀 없이 시스템이 자동으로 언제 파티션을 노드 사이에 이동할지 결정함)와 완전 수동 재균형화(관리자가 명시적으로 파티션을 노드에 할당하도록 설정하고 관리자가 재설정할 때만 파티션 할당이 변경됨)

트랜잭션

• 애플리케이션이 어떤 동시성 문제와 어떤 종류의 하드웨어와 소프트웨어 결함이 존재하지 않는 것처럼 동작할 수 있게 도와주는 추상층
• 애플리케이션에서 몇 개의 읽기와 쓰기를 하나의 논리적 단위로 묶는 방법
• 트랜잭션은 전체가 성공(커밋)하거나 실패(어보트(abort),롤백)한다
• 데이터베이스에 접속하는 애플리케이션에서 프로그래밍 모델을 단순화하려는 목적으로 만든 것
• ACID
  • 트랜잭션이 제공하는 안전성 보장,
  • 원자성(Atomicity)
    • 오류가 생겼을 때 트랜잭션을 어보트하고 해당 트랜잭션에서 기록한 모든 내용을 취소하는 능력은 ACID 원자성의 결정적인 특징
    • 쓰기를 이어서 실행하는 도중 오류가 발생하면 트랜잭션은 어보트돼야 하고 그때까지 쓰여진 내용은 폐기돼야 한다, 즉 데이터베이스는 전부 반영되거나 아무것도 반영되지 않는 것을 보장함으로써 부분 실패를 걱정할 필요가 없게 도와준다
  • 일관성(Consistency)
    • 항상 진실이어야 하는, 데이터에 관한 어떤 선언(불변식(invariant))
  • 격리성(Isolation)
    • 동시에 실행되는 트랜잭션은 서로 격리된다는 것을 의미, 트랜잭션은 다른 트랜잭션을 방해할 수 없음
    • 동시에 실행되는 트랜잭션은 서로를 방해하지 말아야 한다, 한 트랜잭션이 여러 번 쓴다면 다른 트랜잭션은 그 내용을 전부 볼 수 있든지 아무것도 볼 수 없든지 둘 중 하나여야 하고 일부만 볼 수 있어서는 안 된다.
  • 지속성(Durability)
    • 트랜잭션이 성공적으로 커밋됐다면 하드웨어 결함이 발생하거나 데이터베이스가 죽더라도 트랜잭션에서 기록한 모든 데이터는 손실되지 않는다
  • BASE : ACID 표준을 따르지 않는 시스템 - 기본적으로 가용성을 제공하고(Basically Available), 유여한 상태를 가지며(Soft state), 최종적 일관성(Eventual consistency)
• 오류와 어보트 처리
  • 트랜잭션의 핵심 기능은 오류가 생기면 어보트되고 안전하게 재시도
  • 트랜잭션이 실제로는 성공했지만 서버가 클라이언트에게 커밋 성공을 알리는 도중 네트워크가 끊겼을 때(클라이언트는 실패했다고 생각하게 된다) 재시도하면 트랜잭션이 두 번 실행됨
• 격리 수준들의 특징
  • 더티 읽기 : 한 클라이언트가 다른 클라이언트가 썼지만 아직 커밋되지 않은 데이터를 읽는다
    • 트랜잭션이 데이터베이스에 데이터를 썼지만 아직 커밋되거나 어보트되지 않았다고 할때, 다른 트랜잭션에서 커밋되지 않은 데이터를 볼 수 있을까?
  • 더티 쓰기 : 한 클라이언트가 다른 클라이언트가 썼지만 아직 커밋되지 않은 데이터를 덮어쓴다
    • 먼저 쓴 내용이 아직 커밋되지 않은 트랜잭션에서 쓴 것이고 나중에 실행된 쓰기 작업이 커밋되지 않은 값을 덮어써버리면 어떻게 될까?
  • 읽기 스큐(비반복 읽기) : 클라이언트는 다른 시점에 데이터베이스의 다른 부분을 본다
  • 갱신 손실 : 두 클라이언트가 동시에 read-modify-write 주기를 실행한다
    • 애플리케이션이 데이터베이스에서 값을 읽고 변경한 후 변경된 값을 다시 쓸 때(read-modify-write 주기) 발생
    • 때려눕힌다(clobber) : 두 트랜잭션이 이 작업을 동시에 하면 두 번째 쓰기 작업이 첫 번째 변경을 포함하지 않으므로 변경 중 하나는 손실될 수 있다
  • 쓰기 스큐 : 트랜잭션이 무언가를 읽고 읽은 값을 기반으로 어떤 결정을 하고 그 결정을 데이터베이스에 쓴다
  • 팬텀 읽기 : 트랜잭션이 어떤 검색 조건에 부합하는 객체를 읽는다
    • 팬텀(phantom) : 어떤 트랜잭션에서 실행한 쓰기가 다른 트랜잭션 검색 질의 결과를 바꾸는 효과
• 원자적 쓰기 연산
  • 커서 안정성(cursor stability) : 원자적 연산은 보통 객체를 읽을 때 그 객체에 독점적인(exclusive) 잠금을 획득해서 구현함, 갱신이 적용될 때까지 다른 트랜잭션에서 그 객체를 읽지 못하게 함
• 직렬성 트랜잭션 구현
  • 말 그대로 트랜잭션을 순서대로 실행하기
  • 2단계 잠금
  • 직렬성 스냅숏 격리(SSI)
    • 스냅숏 겨리 : 읽는 쪽에서 쓰는 쪽을 결코 차단하지 않고 쓰는 쪽에서 읽는 쪽을 결코 차단하지 않는다

분산 시스템의 골칫거리

• 네트워크 분단(network partition), 네트워크 분리(netsplit) : 네트워크 결함 때문에 네트워크 일부가 다른 쪽과 차단되는 것
• 가비지 컬렉터(garbage collector, GC) : 여러 프로그래밍 언어 런타임에는 가끔식 실행 중인 모든 스레드를 멈춰야 함
• 서스펜드(suspend) : 모든 프로세스 실행을 멈추고 메모리 내용을 디스크에 저장
• 재개(resume) : 메모리 내용을 복원하고 실행을 계속함

일관성과 합의

• 선형성 : 복제된 데이터가 오직 하나의 복사본만 있는 것처럼 보이게 하고 데이터에 대한 모든 연산을 원자적으로 만드는 것
  • 이해하기 쉬우므로 매력적(데이터베이스가 단일 스레드 프로그램의 변수처럼 동작하게 만들어줌)
  • 느리다는 단점
  • 시스템에 데이터 복사본이 하나만 있고 그 데이터를 대상으로 수행하는 모든 연산은 원자적인 것처럼 보이게 만드는 것
  • 직렬성 : 모든 트랜잭션이 여러 객체(로우,문서,레코드)를 읽고 쓸 수 있는 상황에서의 트랜잭션들의 격리 속성
  • 선형성 : 레지스터(개별 객체)에 실행되는 읽기와 쓰기에 대한 최신성 보장
• 인과성 : 시스템에서 발생한 이벤트에 순서를 부여함, 원인과 결과를 기반으로 어떤 것이 어떤 것보다 먼저 실행됐는지
  • 인과적 일관성은 선형성의 코디네이션 오버헤드가 없고 네트워크 문제에 훨씬 덜 민감함
• 합의
  • 선형성 compare-and-set 레지스터
    • 레지스터는 현재 값이 연산의 매개변수로 넘겨진 값과 같은지 여부에 따라 값을 설정할지 말지 원자적으로 결정해야 함
  • 원자적 트랜잭션 커밋
    • 데이터베이스는 분산 트랜잭션을 커밋할 것인지 어보트할 것인지 결정해야 함
  • 전체 순서 브로드캐스트
    • 메시징 시스템은 메시지를 전달할 순서를 결정해야 함
  • 잠금과 임차권
    • 여러 클라이언트들이 잠금이나 임차권을 얻기 위해 경쟁하고 있을 때 잠금은 누가 성공적으로 잠금을 획득할지 결정함
  • 멤버십/코디네이션 서비스
    • 장애 감지기(예를 들어 타임아웃)가 주어지면 시스템은 어떤 노드는 살아 있고 어떤 노드는 세션 타임아웃이 발생해서 죽었다고 생각돼야 하는지 결정해야 함
  • 유일성 제약 조건
    • 여러 트래잭션들이 동시에 같은 키로 충돌되는 레코드를 생성하려고 할 때 이 제약 조건은 어떤 것을 허용하고 어떤 것을 제약 조건 위바능로 실패하도록 할 것인지 결정해야 함
  • 내결함성을 지닌 합의
    • 균일한 동의 : 어떤 두 노드도 다르게 결정하지 않음
    • 무결성 : 어떤 노드도 두 번 결정하지 않음
    • 유효성 : 한 노드가 값 v를 결정한다면 v는 어떤 노드에서 제안된 것이다
    • 종료 : 죽지 않은 모든 노드는 결국 어떤 값을 결정함
• 원자성
  • 실패한 트랜잭션이 절반만 완료된 결과나 절반만 갱신된 상태로 데이터베이스를 어지럽히는 것을 막아줌
  • 보조 식앤이 주 데이터와 일관성을 유지하도록 보장함
• 단일 리더(단일 리더 복제 : 모든 쓰기를 리더에게 전달하고 쓰기를 같은 순서로 팔로워에 적용해서 복제본이 최신 상태를 유지하게 하는 것)에 장애가 나거나 네트워크가 끊겨서 리더에 접속할 수 없게 되면 시스템은 아무 진행도 하지 못함
  • 리더가 복구될 때까지 기다리고 시스템이 그동안 차단되는 것을 받아들임, 여러 XA/JTA 트랜잭션 코디네이터는 이 선택지를 채택함, 이 방법은 종료 속성을 만족하지 않기 때문에 합의를 완전히 해결하지 않음. 리더가 복구되지 않으면 시스템은 영원히 차단됨
  • 사람이 새 리더 노드를 선택하고 시스템이 그 노드를 사용하도록 재설정해서 수동으로 장애 복구를 함. 많은 관계형 데이터베이스가 이 방법을 취함. 불가항력에 의한 일종의 합의, 컴퓨터 시스템 밖에 있는 인간 운영자가 결정을 내림, 장애 복구 속도는 사람이 행동하는 속도로 제한되며 일반적으로 컴퓨터보다 느림
  • 자동으로 새 리더를 선택하는 알고리즘을 사용함. 알고리즘이 필요하고 불리한 네트워크 조건을 올바르게 처리하는 입증된 알고리즘을 사용하는게 현명함

일괄 처리

• 3가지 시스템
  • 서비스 (온라인 시스템)
    • 서비스는 클라이언트로부터 요청이나 지시가 올 때까지 기다림, 요청 하나가 들어오면 서비스는 가능한 빨리 요청을 처리해서 응답을 되돌려 보내려 함, 응답시간은 서비스 성능을 측정할 때 중요한 지표
  • 일괄 처리 시스템(오프라인 시스템)
    • 매우 큰 입력 데이터를 받아 데이터를 처리하는 작업을 수행하고 결과 데이터를 생산함, 일괄 처리 작업은 수 분에서 때론 수 일이 걸리기 때문에 대개 사용자가 작업이 끝날 때까지 대기하지 않음, 대부분 하루에 한번 수행과 같이 반복적인 일정으로 수행함, 일괄 처리 작업의 주요 성능 지표는 처리량
  • 스트림 처리 시스템(준실시간 시스템)
    • 온라인과 오프라인/일괄 처리 사이의 어딘가에 있기 때문에 때론 준실시간 처리(near-real-time processing 또는 nearline processing), 요청에 대해 응답하지 않으며 입력 데이터를 소비하고 출력 데이터를 생산함, 일괄 처리 작업은 정해진 크기의 입력 데이터를 대상으로 작동하지만 스트림 처리는 입력 이벤트가 발생한 직후 바로 작동함, 스트림 처리 시스템은 같은 작업을 하는 일괄 처리 시스템보다 지연 시간이 낮음
• 일괄 처리는 신뢰 할 수 있고 확장 가능하며 유지보수하기 쉬운 애플리케이션을 구축하는 데 매우 중요한 구성요소
• 프로그램을 단순히 stdin 으로부터 입력을 읽어 stdout으로 출력하도록 작성하면 데이터 처리 파이프라인에 바로 끼워 사용할 수 있음
• 분산 일괄 처리 프레임워크가 해결해야할 두 가지 문제
  • 파티셔닝
    • 맵리듀스에서 매퍼는 입력 파일 블록에 따라 파티셔닝됨, 매퍼의 출력은 재파티셔닝해 정렬하고 리듀서 파티션으로 병합함
  • 내결함성
    • 맵 리듀스는 번번히 디스크에 기록, 디스크에 기록하면 개별 태스크가 실패하더라도 전체 작업을 재수행하지 않고 쉽게 복구 할 수 있음, 작업이 실패하지 않는 경우 수행 시간이 느려지는 것은 감수해야함
• 파티셔닝 알고리즘
  • 정렬 병합 조인
    • 조인할 각 입력은 조인 키를 추출하는 매퍼를 통과함, 파티셔닝,정렬,병합 과정을 마치면 같은 키를 가지는 모든 레코드는 하나의 리듀서에서 호출됨
  • 브로드캐스트 해시 조인
    • 조인할 입력 두 개 중 하나가 상대적으로 작다면 파티셔닝하지 않고 해시 테이블에 모두 적재할 수 있음
  • 파티션 해시 조인
    • 조인 입력 두 개를 같은 방식으로 파티셔닝하면(같은 키와 같은 해시 함수와 같은 파티션 수를 사용) 해시 테이블 방식을 각 파티션별로 독립적으로 사용할 수 있음
• 맵리듀스와 분산 파일 시스템
  • 수천 대의 장비로 분산해서 실행이 가능함
  • 상당히 불친절하고 무차별 대입 방법이지만 대신 엄청나게 효율적인 도구
  • 단일 맵리듀스 작업은 하나 이상의 입력을 받아 하나 이상의 출력을 만들어 낸다는 점에서 단일 유닉스 프로세스와 유사함
  • 맵리듀스 작업은 분산 파일 시스템상의 파일을 입력과 출력으로 사용함
  • HDFS(Hadoop Distributed File System) : GFS(Google File System)을 재구현한 오픈소스
  • 맵리듀스는 HDFS 같은 분산 파일 시스템 위에서 대용량 데이터셋을 처리하는 코드를 작성하는 프로그래밍 프레임워크
  • 2단계(맵)와 4단계(리듀스)는 사용자가 직접 작성한 데이터 처리 코드, 1단계는 파일을 나누어 레코드를 만드는데 입력 형식 파서를 씀, 3단계는 정렬 단계로 맵리듀스에 내재하는 단계라서 직접 작성할 필요가 없는데 매퍼의 출력은 리듀스로 들어가기 전에 이미 정렬됐음
    • 매퍼(Mapper)
      • 매퍼는 모든 입력 레코드마다 한 번씩만 호출 됨
      • 매퍼는 입력 레코드로부터 키와 값을 추출하는 작업
    • 리듀서(Reducer)
      • 맵리듀스 프레임워크는 매퍼가 생산한 키-값 쌍을 받아 같은 키를 가진 레코드를 모으고 해당 값의 집합을 반복해 리듀서 함수를 호출함, 리듀서는 출력 레코드르 생산함
  • 셔플(suffle) : 리듀서를 기준으로 파티셔닝하고 정렬한 뒤 매퍼로부터 데이터 파티션을 복사하는 과정
  • 관계형 모델에서는 외래키(foreign key), 문서 모델에서는 문서 참조(document reference)라 하고 그래프 모델에서는 간선(edge)
  • 보조 정렬(secondary sort) : 리듀서가 항상 사용자 데이터베이스를 먼저 보고 활동 이벤트를 시간 순으로 보게 하는 식으로 맵리듀스에서 작업 레코드를 재배열함
  • 세션화(sessionization) : 특정 사용자가 취한 일련의 활동을 찾기 위해 사용자 세션별 활동 이벤트를 수집 분석할 때도 일반적으로 그룹화함
  • 쏠림 다루기
    • 린치핀 객체(linchpin object), 핫 키(hot key) : 불균형한 활성 데이터베이스 레코드
    • 핫스팟 : 한 리듀서가 다른 리듀서보다 엄청나게 많은 레코드를 처리해야한다는 뜻, 모든 매퍼와 리듀서가 완전히 끝나야지만 맵리듀스 작업이 끝나기 때문에 가장 느린 리듀서가 작업을 완료할 때까지 후속 작업들은 시작하지 못한 채 기다려야 함
    • 쏠림 조인(skewed join) : 어떤 키가 핫 키인지 결정하기 위해 샘플링 작업을 수행함, 핫 키를 여러 리듀서에 퍼뜨려서 처리하게 하는 방법
  • 맵 사이드 조인
    • 리듀스 사이드 조인(reduce-side join) : 여러 조인 알고리즘은 실제 조인 로직을 리듀서에서 수행함
    • 매퍼는 각 입력 레코드에서 키와 값을 추출해 추출한 키-값 쌍을 리듀서 파티션으로 할당하고 키별로 정렬함, 입력 데이터를 준비하는 역할
    • 맵사이드 조인(map-side-join) : 축소된 맵리듀스 작업, 리듀서는 물론 정렬 작업도 없음, 각 매퍼가 할 작업은 분산 파일 시스템에서 단순히 입력 파일 블럭 하나를 읽어 다시 해당 분산 파일 시스템에 출력하는 것이 전부
    • 브로드 캐스트 : 큰 입력의 파티션 하나를 담당하는 각 매퍼는 작은 입력 전체를 읽는다는 것
  • 대규모 병렬 처리(massively parallel processing, MPP) 데이터베이스
  • MPP 데이터베이스는 장비 클러스터에서 분석 SQL 질의를 병렬로 수행하는 것에 초점을 두지만 맵리듀스와 분산 파일 시스템의 조합은 아무 프로그램이나 실행할 수 있는 운영체제와 비슷한 속성을 제공함
  • 데이터플로 엔진(dataflow engine) : 여러 처리 단계를 통해 데이터 흐름을 명시적으로 모델링하기 때문에 이러한 시스템을 일컬음
    • 맵리듀스 처럼 단일 스레드에서 사용자 정의 함수를 반복 호출해 한번에 레코드를 한 개씩 처리함
    • 데이터플로 엔진은 입력을 파티셔닝해 병렬화함
    • 테즈 : 노드 간에 데이터를 실제로 복사하는 데 YARN 셔플 서비스에 의존하는 상당히 가벼운 라이브러리
    • 스파크,플링크 : 자체 네트워크 통신 계층과 스케줄러 그리고 사용자 측 API를 갖춘 대형 프레임워크

스트림 처리

• 일괄 처리 : 입력으로 파일 집합을 읽어 출력으로 새로운 파일 집합을 생성하는 기술
• 복수 소비자
  • 로드 밸런싱 : 메시지를 처리하는 비용이 비싸서 처리를 병렬화하기 위해 소비자를 추가하고 싶을 때 유용함
  • 팬 아웃 : 여러 독립적인 소비자가 브로드캐스팅된 동일한 메시지를 서로 간섭 없이 청취할 수 있음
• 스트림 처리 : 고정 크기의 입력이 아니라 끝이 없는 스트림 상에서 연속적으로 실행됨
  • AMQP/JMS 스타일 메시지 브로커 : 브로커는 개별 메시지를 소비자에게 할당하고 소비자는 받은 메시지를 처리하는 데 성공하면 개별 메시지의 확인 응답을 보냄, 브로커가 확인 응답을 받은 메시지는 삭제됨
  • 로그 기반 메시지 브로커 : 브로커는 한 파티션 내의 모든 메시지를 동일한 소비자 노드에 할당하고 항상 같은 순서로 메시지를 전달함, 병렬화는 파티션을 나누는 방식을 사용
  • 스트림 스트림 조언
    • 두 입력 스트림은 활동 이벤트로 구성하고 조인 연산자는 시간 윈도우 내에 발생한 관련 이벤트를 검색함
  • 스트림 테이블 조인
    • 한 입력 스트림은 활동 이벤트로 구성하고 다른 스트림은 데이터베이스의 변경 로그로 구성함
  • 테이블 테이블 조인
    • 양쪽 입력 스트림이 모두 데이터베이스의 변경 로그
  • 이벤트에서 데이터를 꺼내 데이터베이스나 캐시, 검색 색인 또는 유사한 저장소 시스템에 기록하고 다른 클라이언트가 이 시스템에 해당 데이터를 질의함
  • 이벤트를 사용자에 직접 보냄
  • 하나 이상의 입력 스트림을 처리해 하나 이상의 출력 스트림을 생산함
  • 연산자(operator)나 작업(job) : 스트림을 처리하는 코드 조각
• 변경 데이터 캡처(change data capture, CDC)
  • 데이터베이스에 기록하는 모든 데이터의 변화를 관찰해 다른 시스템으로 데이터를 복제할 수 있는 형태로 추출하는 과정
• 이벤트 시간 대 처리 시간
  • 처리 지연 : 큐 대기, 네트워크 결함, 메시지 브로커나 처리자에서 경쟁을 유발하는 성능 문제, 스트림 소비자의 재시작, 결함에서 복구하는 도중이나 코드 상의 버그를 고친 후 과거 이벤트의 재처리
• 윈도우 유형
  • 텀블링 윈도우(Tumbling window)
    • 텀블링 윈도우의 크기는 고정 길이, 모든 이벤트는 정확히 한 윈도우에 속함
  • 홉핑 윈도우(Hopping window)
    • 홉핑 윈도우도 고정 길이를 사용, 홉핑 윈도우는 결과를 매끄럽게 만들기 위해 윈도우를 중첩함
  • 슬라이딩 윈도우(Sliding window)
    • 슬라이딩 윈도우는 각 시간 간격 사이에서 발생한 모든 이벤트를 포함함
  • 세션 윈도우(Session window)
    • 이전 윈도우 유형과는 다르게 세션 윈도우는 고정된 기간이 없음, 대신 같은 사용자가 짧은 시간 동안 발생시킨 모든 이벤트를 그룹화해서 세션 윈도우를 정의함
• 마이크로 일괄 처리(microbatching) : 스트림을 작은 블록으로 나누고 각 블록을 소형 일괄 처리와 갈이 다루는 방법

데이터 시스템의 미래

• 람다 아키텍처(lambda architecture) : 입력 데이터를 불변 이벤트로서 증가하기만 하는 데이터셋에 추가하는 방식으로 기록해야 한다는 것, 이벤트 소싱과 유사함
  • 두 개의 다른 시스템을 병행해서 운용하기를 제안함
  • 하둡 맵리듀스 같은 일괄 처리 시스템과 스톰 같은 분리된 스트림 처리 시스템을 함께 운용
• 데이터 저장소 기술 구성하기
  • 보조 색인 : 필드 값을 기반으로 레코드를 효율적으로 검색할 수 있는 기능
  • 구체화 뷰 : 질의 결과를 미리 연산한 캐시의 일종
  • 복제 로그 : 데이터의 복사본을 다른 노드에 최신 상태로 유지하는 기능
  • 전문 검색 색인 : 텍스트에서 키워드 검색을 가능하게 하는 기능
• 연합 데이터베이스(federated database), 폴리스토어(polystore) : 엄청나게 많은 하단 저장소 엔진과 처리 메서드를 통합해 질의하는 인터페이스를 제공함
• 느슨한 결합(loose coupling) : 로그 기반 통합의 큰 장점은 다양한 구성 요소간 느슨한 결합
  • 시스템 수준에서 비동기 이벤트 스트림을 사용하면 전체 시스템이 개별 구성 요소의 장애나 성능 저하가 생겨도 잘 견디게 만들 수 있음, 이벤트 소비자가 느리거나 장애가 난다면 이벤트 로그는 메시지를 버퍼링하고 생산자와 다른 소비자는 영향 없이 계속해서 수행함
  • 인적 수준에서 데이터 시스템을 언번들링하면 소프트웨어 구성 요소와 서비스를 다른 팀에서 각자 개발하고 개선하고 독립적으로 유지보수 할 수 있음, 각 팀을 전문화하고 다른 팀 시스템과 인터페이스를 잘 정의하는 방식으로 연동한다면 각 팀은 한 가지 일을 잘 해내는 데만 집중하면 됨
• 데이터플로 주변 애플리케이션 설계
  • 데이터베이스 인사이드 아웃 접근법 : 애플리케이션 코드로 특화된 저장소와 처리 시스템을 조립하는 언번들링 데이터베이스 접근법
• 파생 함수로서의 애플리케이션 코드
  • 보조 색인 : 단순한 변환 함수를 사용하는 파생 데이터셋의 일종, 기반 테이블의 각 로우나 문서마다 색인할 칼럼이나 필드를 골라 그 값을 기준으로 정렬함
  • 전문 검색 색인 : 언어 감지, 단어 분리, 어간 추출, 기본형 처리, 철자 교정, 동의어 식별 등의 다양한 자연어 처리 함수를 적용한 다음 효율적인 조화를 위한 자료 구조를 구축함
  • 머신러닝 시스템에서 모델 : 다양한 특징(feature) 추출과 통계 분석 함수를 사용해 학습 데이터로부터 파생된 것으로 간주 할 수 있음
  • 캐시 : 사용자 인터페이스(UI)에 보여줄 형태의 데이터 집합을 포함함
• 파생 상태 관찰하기
  • 쓰기 경로(write path) : 데이터플로 시스템은 검색 색인이나 구체화 뷰 또는 예측 모델과 같은 파생 데이터셋을 생성하고 최신 상태로 유지하는 과정에 사용함
  • 시스템에 정보를 기록할 때마다 일괄 처리와 스트림 처리의 여러 단계를 거친 다음 결과적으로 기록된 데이터를 모든 파생 데이터셋에 통합해 갱신함
• 로그 기반 메시징의 유일성
  • 전체 순서 브로드캐스트(total order broadcast) : 로그는 모든 소비자가 동일한 순서로 메시지를 보도록 보장함, 합의와 동일
• 적시성(Timeliness) : 사용자가 시스템을 항상 최신 상태로 관착 가능함
• 무결성(Integrity) : 무결성은 손상이 없음, 누락된 데이터도 없고 모순된 데이터도, 잘못된 데이터도 없음
• 코디네이션 회피 데이터 시스템
  • 데이터플로 시스템은 원자적 커밋과 선형성, 그리고 파티션에 걸친 동기 코디네이션 없이도 파생 데이터에 대한 무결성 보장을 유지
  • 엄격한 유일성 제약 조건은 적시성과 코디네이션을 요구하지만 많은 애플리케이션은 느슨한 제약 조건을 사용해도 실제로 괜찮음
  • 코디네이션 회피(coordination-avoiding) : 데이터플로 시스템은 코디네이션 없이도 많은 애플리케이션용 데이터 관리 서비스를 제공할 수 있을 뿐 아니라 여전히 무결성을 강력하게 보장함
• 감사(auditing) : 데이터 무결성을 체크하는 작업

용어

• 비동기(asynchronous) : 어떤 작업이 완료될 때까지(ex-네트워크 상에서 데이터를 다른 노드로 전달하기) 기다리지 않고 해당 작업이 얼마나 오래 걸릴지 가정하지 않음
• 원자적(atomic)
  • (동시성 연산의 맥락에서) 연산의 효과가 어느 한 시점에 나타나서 절반만 수행된 상태를 동시에 실행되는 다른 프로세스에서 볼 수 없음
  • (트랜잭션 맥락에서) 반드시 모두 커밋되거나 모두 롤백돼야 하는(결함이 생기더라도)쓰기 집합을 묶음
• 배압(backpressure)
  • 데이터 수신자가 데이터를 따라잡을 수 없을 때 데이터 전송자가 전송 속도를 낮추는 것, 흐름 제어(flow control)
• 일괄 처리(batch process)
  • 고정된(대개 매우 큰) 데이터셋을 입력으로 사용하며 입력은 변경하지 않은 채 다른 데이터를 출력으로 생산하는 연산
• 제한 있는(bounded)
  • 알려진 상한(upper limit)이나 크기가 있는
• 비잔틴 결함(Byzantine fault) : 무작위로 잘못된 행동을 하는 노드
• 캐시(cache) : 이후에 같은 데이터를 읽을 때 속도를 높이기 위해 최근에 사용한 데이터를 기억하는 구성 요소, 일반적으로 모든 데이터를 보유하지 않음, 특정 데이터가 캐시에 없을 때 완벽한 데이터 복사본을 가진 느린 하단 데이터 시스템에서 해당 데이터를 불러와야함
• CAP 정리(CAP theorem) : 실제로 유용하지 않은 널리 잘못 알려진 이론적 결과
• 인과성(causality) : 시스템에서 어떤 일이 다른 일 보다 먼저 발생할 때 생기는 이벤트 간 의존 관계
• 합의(consensus) : 분산 컴퓨팅의 근본적인 문제로 여러 노드가 특정 사안에 대해서 동의를 구할 때 발생함
• 데이터 웨어하우스(data warehouse) : 여러 다른 OLTP 시스템의 데이터를 합쳐 데이터 분석 목적으로 쓰기 위해 준비된 데이터베이스
• 선언적(declarative) : 어떤 속성을 가져야 하는지 기술하지만 그 속성을 달성하는 정확한 과정은 기술하지 않음, 질의의 맥락에서 질의 최적화기는 선언형 질의를 받아 어떻게 하면 가장 잘 실행할지를 결정함
• 비정규화(denormalize) : 읽기 속도를 높히기 위해 일반적으로 캐시나 색인과 같은 형태로 정규화된 데이터셋에 일부 중복을 도입하는 것, 비정규화된 값은 사전에 계산된 질의 결과로 구체화 뷰와 유사함
• 파생 데이터(derived data) : 다른 데이터로부터 반복 가능한 처리를 통해 생선된 데이터셋, 파생 데이터는 대개 특정한 형태로 데이터를 읽는 속도를 높이는 데 사용됨, 파생 데이터의 예로 색인, 캐시 , 구체화 뷰가 있음
• 결정적(deterministic) : 같은 입력을 줄 때 항상 같은 출력을 생산하는 함수를 가리켜 결정적이라고 함, 함수가 결정적이면 무작위 수, 시각, 네트워크 통신이나 다른 예측하지 못한 것에 의존하지 않음
• 분산된(distributed) : 네트워크로 여러 노드를 연결해서 구동함, 부분 실패(partial failure)가 나타나는 특징
• 지속성 있는(durable) : 다양한 결함이 발생해도 손실되지 않는다고 여겨지는 방식으로 데이터를 저장함
• ETL : 추출(Extract)-변환(Transform)-적재(Load), 원천 데이터베이스에서 데이터를 추출하는 과정과 분석 질의에 더 적합한 형태로 데이터를 변환하는 과정
• 장애복구(failover) : 단일 리더가 있는 시스템에서 장애 처리는 리더십이 한 노드에서 다른 노드로 옮겨가는 과정
• 내결함성(fault-tolerant) : 무언가 잘못됐을 때 자동으로 복구하는 능력
• 흐름 제어(flow control) : 배압(backpressure)
• 팔로워(follwer) : 클라이언트로부터 쓰기 요청을 직접 수용하지 않고 리더로부터만 데이터 변경 사항을 받아 처리하는 복제본, 보조 복제본(secondary replica), 슬레이브 복제본(slave replica), 읽기 복제본(read replica), 핫 스탠바이(hot standby)
• 전문 검색(full-text search) : 임의 키워드로 텍스트를 찾는 것으로 흔히 부가 기능으로 철자가 비슷한 단어나 동의어를 찾는 기능이 있음
• 그래프(graph) : 정점(vertex,참조 가능한것, 노드(node), 엔티티(entity))과 간선(edge, 한 정점과 다른 정점의 연결, 관계(relationship)나 아크(arc))으로 구성된 데이터 구조
• 해시(hash) : 입력을 무작위로 보이는 숫자로 바꾸는 함수, 같은 값을 입력하면 항상 같은 숫자를 출력으로 반환함,두 다른값을 입력해도 같은 출력을 반환할 가능성이 있음(충돌(collision))
• 멱등(idempotent) : 안전하게 재시도할 수 있는 연산을 설명할 때 사용함, 이 함수를 한 번 이상 실행해도 딱 한 번만 실행한 것과 같은 효과를 냄
• 색인(index) : 특정 필드에서 특정 값을 갖는 모든 레코드를 효율적으로 찾게 해주는 자료
• 격리(isolation) : 트랜잭션 맥라에서 동시에 실행하는 트랜잭션이 서로 얼마나 간섭하는지 나타내는 정도를 설명함,직렬성(serializable) 격리는 가장 강력한 보장을 지원하지만 완화된 격리 수준도 사용함
• 조인(join) : 같은 값을 갖는 레코드를 함께 모음,한 레코드가 다른 레코드를 참조하면서(외래키,문서 참조, 그래프의 간선)참조가 가리키는 레코드를 얻어야 하는 경우 주로 사용됨
• 리더(leader) : 리더는 데이터나 서비스가 여러 노드에 걸쳐 복제됐을 때 변경사항 반영이 가능하도록 지정된 복제본
• 선형성(linearizable) : 원자적 연산으로 갱신되는 시스템에서 데이터가 단일 복제본만 존재하는 것처럼 작동함
• 지역성(locality) : 자주 동시에 필요한 여러 데이터를 같은 장소에 함께 두는 성능 최적화의 한 가지 방법
• 잠금(lock) : 스레드나 노드 또는 트랜잭션이 특정 자원에 단 하나만 접근 가능함을 보장하는 매커니즘
• 로그(log) : 뎅티ㅓ 저장을 위한 추가 전용 파일, 쓰기 전 로그(write-ahead-log)는 저장소 엔진을 장애에 견딜 수 있게 만드는데 사용, 로그 구조화(log structured) 저장소 엔진은 로그를 주요 저장 형식으로 사용함, 복제 로그(replication log)는 리더에서 팔로워로 쓰기를 복제할때 사용함, 이벤트 로그(event log)는 데이터 스트림을 표현할 수 있음
• 구체화(materialize) : 요청했을 때 결과를 계산하는 것과 반대로 미리 연산을 수행하는 것
• 노드(node) : 컴퓨터 상에서 실행하고 있는 소프트웨어 인스턴스로 특정 태스크를 수행하기 위해 네트워크를 거쳐 다른 노드와 통신함
• 정규화된(normalized) : 중복이 없는 방식으로 구조화된 것을 말함, 정규화된 데이터베이스에서는 데이터 변화가 있을 때 여러 장소에 있는 복사본이 아니라 한 곳의 데이터만 변경하면 됨
• OLAP : 온라인 분석 처리, 많은 레코드를 대상으로 한 집계(ex- 카운트,합계,평균)가 특징인 접근 패턴
• OLTP : 온라인 트랜잭션 처리, 대개 키(key)로 색인된 적은 수의 레코드를 대상으로 읽고 쓰는 빠른 질의가 특징인 접근 패턴
• 파티셔닝(partitioning) : 단일 장비에서 처리하기에 너무 큰 대규모 데이터셋 또는 연산을 작은 부분으로 나누고 여러 장비에 분배하는 작업, 샤딩(sharding)
• 백분위(percentile) : 기준치 위나 아래에 값이 얼마나 많이 있는지 세어 값의 분포를 측정하는 방법
• 기본키(primary key) : 레코드를 고유하게 식별하는 값으로 숫자나 문자열을 사용하는 것이 일반적
• 정족수(quorum) : 연산을 성공한 것으로 간주하기 위한 투표에 필요한 최소 노드의 수
• 재균형화(rebalance) : 부하를 동등하게 분해바기 위해 한 노드에서 다른 노드로 데이터나 서비스를 옮기는 일
• 복제(replication) : 특정 데이터가 있는 한 노드에 접근할 수 없더라도 다른 노드에서 해당 데이터 접근이 가능하도록 데이터 복사본을 여러 노드(복제본)에 유지하는 일
• 스키마(schema) : 데이터 구조를나타내는 명세, 필드와 데이터형식을 포함함, 특정 데이터가 스키마를 준수하는지 데이터의 일생의 여러 시점에서 확인할 수 있음
• 보조 색인(secondary index) : 기본 데이터 저장소와 함께 유지되는 추가적인 데이터 구조로서 특정 조건에 맞는 레코드를 효율적으로 찾는 데 사용함
• 직렬성(serializable) : 여러 트랜잭션이 동시에 실행될 때 트랜잭션이 연속된 순서로 한 번에 하나씩만 실행되는 것처럼 작동하게 보장한다는 의미
• 비공유(shared-nothing) : 각기 CPU와 메모리, 디스크를 가지는 독립된 노드로 구성된 아키텍처, 노드들은 일상적으로 사용하는 네트워크로 연결돼 있음
• 쏠림(skew) : 파티션 간 부하 불균형, 특정 파티션만 요청이나 데이터가 많고 다른 파티션은 훨씬 적은 상태를 말함, 핫스팟(hot spot)
• 스큐(skew) : 이벤트 순서를 예측할 수 없으며 비순차적으로 나타나게 하는 타이밍 이상 현상
• 스플릿 브레인(split brain) : 두 노드가 동시에 자신을 리더로 판단하는 시나리오
• 스토어드 프로시저(stored procedure) : 완전히 데이터베이스 서버에서 실행되고 실행 중에 클라이언트와 통신하지 않는 방식으로 트랜잭션 로직을 부호화하는 방법
• 스트림 처리(stream process) : 끝나지 않는 이벤트스트림을 입력으로 소비해 입력으로부터 어떤 출력을 파생하기 위해 지속적으로 실행하는 연산
• 동기(synchronous) : 비동기(asynchronous)의 반대
• 레코드 시스템(system of record) : 근본적이고 권위 있는 데이터 버전을 보유하는 시스템으로서 진실의 근원(source or truth)이라고 함, 변경 사항이 처음 기록되는 곳이고 여기서 다른 데이터셋이 파생됨
• 타임아웃(timeout) : 결함을 감지하는 가장 간단한 방법 중 하나, 즉 일정 시간 동안 응답이 없음을 관측하는 일
• 전체 순서(total order) : 항상 둘 중 하나가 크고 다른 하나가 작다고 항상 판별할 수 있는 비교 방법(타임 스탬프), 비교할 수 없는 것들이 포함된 순서화는 부분순서(partial order)
• 트랜잭션(transaction) : 오류 처리와 동시성 문제를 단순화하기 위해 여러 읽기 쓰기를 하나의 논리적 단위로 묶은 것
• 2단계 커밋(two-phase commit,2PC) : 트랜잭션이 여러 데이터베이스 노드에서 모두 커밋하거나 모두 어보트되게 하는 알고리즘
• 2단계 잠금(2PL) : 직렬성 격리를 수행하는 알고리즘으로 트랜잭션이 읽거나 쓰는 모든 데이터를 대상으로 잠금을 획득하고 트랜잭션이 끝날때까지 잠금을 보유하는 방식으로 동작함
• 제한 없는(unbounded) : 한계나 크기를 알지 못하는, 제한 있는(bounded)의 반대