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

    데이터중심 애플리케이션 설계 - 7장 [트랜잭션] 리뷰 - 1

    6장과 비교했을 때 굉장히 내용이 많다. 다양한 정의 및 내용이 나오다보니 개인적으로 헷갈리는 부분이 많았다. 트랜잭션 (Transaction) 애플리케이션에서 다수의 읽기와 쓰기 작업을 하나의 논리적 단위로 묶는 방법 (개념적으로 하나의 트랜잭션 내에서는 모든 읽기 / 쓰기는 하나의 연산으로 실행) 트랜잭션은 전체가 성공(commit) or 실패(abort, rollback) 된다. 트랜잭션이 필요한 이유 1. DB, SW, HW, 모두 언제라도 연산 및 작업이 실패할 수 있다. 2. 네트워크 오류로 인해 노드 사이의 통신 실패 3. Client 사이의 경쟁 조건으로 인해 예상치 못한 버그 유발 가능 ACID 원자성(Atomicity), 일관성(Consistency), 격리성(Isolation), 지속..

    데이터중심 애플리케이션 설계 - 6장 [파티셔닝] 리뷰 - 3

    이번 포스팅에서는 6장에서의 3번째 주제 파티션 재균형화에 대해 리뷰한다. 파티션 재균형화 재균형화(Rebalancing) : 특정 노드에 대한 데이터와 요청을 다른 노드로 옮기는 과정 재균형화에 대한 요구사항 재균형화 이후에는 부하가 클러스터의 노드들에 대해 균등하게 분배 재균형화 도중에도 DB에 read/write 요청이 가능해야함 재균형화는 빠르게 실행되어야하며, 네트워크, 디스크 I/O 부하를 최소화할 수 있도록 노드간의 데이터 이동은 최소로 이동 파티션 리벨런싱 전략 사용하면 안되는 방법 : 해시값에 mod N 연산 실행 문제점 : 노드 개수 N 이 바뀌면, 대부분의 키의 위치가 노드 사이에서 옮겨진다. 즉, 필요이상의 데이터가 이동하게 되므로 리벨런싱 비용이 너무 많아짐 # 파티션 개수 고정 ..

    데이터중심 애플리케이션 설계 - 6장 [파티셔닝] 리뷰 - 2

    인덱스와 파티셔닝의 상호 작용 key - value 데이터 모델에 의존한 파티셔닝 방식 = 기본키를 통해 레코드를 식별한다. 파티셔닝과 보조 색인 보통 보조색인의 역할 : 특정한 값이 발생한 항목을 검색하는 수단으로 이용 ex) user_123 의 실행 액션 조회 / 'water' 가 들어간 글을 모두 조회 보조 색인이 있는 DB 색인 방식 2가지 문서 기반 파티셔닝 [local Index] 용어 기반 파티셔닝 [Global Index] 문서 기반 보조 색인 파티셔닝 문서 파티셔닝 색인 local index(지역 색인)으로 칭하기도 함 각 파티션은 본인의 보조 색인을 유지 보조 색인은 해당 파티션이 속하는 document만 담당 [Create, Update, Delete 시의 파티션만 다루면 된다] 장점..

    데이터중심 애플리케이션 설계 - 6장 [파티셔닝] 리뷰 - 1

    5장 리뷰 작성을 미루다가 6장을 먼저 공부해버렸다. 이후에 5장도 마저 작성하도록한다... 6장 preview 파티셔닝 방법 인덱스와 파티셔닝 간의 상호 작용 재균형화 데이터베이스가 올바른 파티션을 찾아 요청을 전달하고 질의를 실행하는 방법 파티셔닝 데이터 셋이 크거나, 질의 처리량이 매우 높은 경우 데이터를 작은 단위[파티션]으로 쪼개는 작업 (≒ 샤딩) ex) - 샤드(MongoDB, Elasticsearch, Solr), 리전 (Hbase), 태블릿 (Bigtable) - 브이노드 (Cassandra, Riak), 브이버켓 (Couchbase) 파티션은 보통 각 데이터 단위(record, row, document)가 하나의 파티션에 속함 물론 파티셔닝과 샤딩의 정확한 의미의 차이는 존재합니다. 파..

    데이터중심 애플리케이션 설계 - 4장 [부호화와 발전] 리뷰

    Data outlives code (데이터는 코드보다 오래 산다) 최근 서비스는 무중단배포(ex_ 블루그린배포) - staged rollout 방식과 마이크로서비스와 같은 구조적 차이를 띈다. 그만큼 서비스 내부 코드는 더욱 자주 바뀐다. # 호환성 상위 호환성 : 이전 코드는 새로운 버전의 데이터를 읽을 수 있어야한다. 하위 호환성 : 새로운 코드는 예전 버전의 데이터를 읽을 수 있어야한다. # 직렬화(부호화), 역직렬화(복호화) 직렬화(부호화, 마샬링) : 데이터를 인메모리 표현 -> 바이트열 변환 역직렬화(복호화, 언마샬링) : 데이터를 바이트열 -> 인메모리 표현으로 변환 데이터 부호화 4가지 방식 언어별 내장 라이브러리 JSON, XML, CSV binary Encoding Libaray bas..

    데이터중심 애플리케이션 설계 - 3장 [저장소와 검색] 리뷰 - 3 : 트랜잭션 처리 / 분석

    트랜잭션 처리나 분석 데이터베이스를 트랜잭션 처리 뿐만이 아니라 데이터 분석에도 점점 더 사용하기 시작 OLTP (Online Transcation Processing) / OLAP (Online Analytic Processing) 초반에는 트랜잭션 처리와 분석 질의를 위해 동일한 데이터베이스를 사용 OLTP 시스템을 분석 목적으로 사용하지 않고 개별 데이터 베이스에서 분석을 수행하려 함 이 개별 데이터베이스를 데이터 웨어하우스라고 부름 데이터 웨어하우징 OLTP 시스템 사업 운영에 대단히 중요 - 일반적으로 높은 가용성 / 낮은 지연시간의 트랜잭션 처리를 기대 이 때문에 비즈니스 분석가가 OLTP 데이터베이스에 즉석 분석 질의(ad hoc anaytic query)를 실행하는 것을 꺼려함 데이터 웨어..

    데이터중심 애플리케이션 설계 - 3장 [저장소와 검색] 리뷰 - 2

    B Tree (B 트리) 가장 널리 사용되는 인덱스 구조 ( RDB / NoSQL) SS 테이블과 동일하게 K-V 정렬 유지 (키 - 값 검색 / 범위 쿼리 효율적) 기본 구조 4KB 내외 크기의 고정 크기 페이지(블록)로 나누고 한 번에 하나의 페이지에 읽기 또는 쓰기 (디스크는 고정 크기 블록으로 배열되기 때문) 각 페이지는 주소나 위치를 이용해 식별 가능 -> 해당 방식으로 하나의 페이지가 다른 페이지를 참조 가능 B tree 구조에는 하나의 루트 페이지 존재 (색인에서 키를 찾기 위해서는 루트에서부터 시작) 페이지는 여러 키와 하위 페이지 참조를 포함 최종적으로는 리프 페이지를 포함하는 페이지에 도달 분기 계수 : 한 페이지에서 하위 페이지를 참조하는 수 (페이지 참조와 범위 경계를 저장할 공간의..

    데이터중심 애플리케이션 설계 - 3장 [저장소와 검색] 리뷰 - 1

    3장을 읽으며 발췌 및 정리하면 좋을 내용들에 대해서만 정리하였다. DB의 작업 data 저장 data 요청시, 제공 개발자가 DB 내 저장 및 검색 처리 방법을 주의해야 하는 이유 : - 처음부터 저장소 엔진을 구현하는 것이 아닌, 사용 가능한 여러 저장소 엔진 중 가장 적합한 엔진을 선택해야 하기 때문 ex_ transaction 작업 부하에 맞추어 최적화된 저장소 엔진과 분석을 위해 최적화된 엔진 간의 차이는 크다. 로그 구조 계열 저장소 엔진(Log-structured) - ex) B-tree 페이지 지향 계열 저장소 엔진(Page-Oriented) DB 를 강력하게 만드는 데이터 구조 일반적으로 많은 DB는 내부적으로 추가 전용(append-only) 데이터 파일인 로그(log)를 사용 로그 -..