기술스택을 쌓아보자/데이터 엔지니어링11 데이터 중심 애플리케이션 설계 - 트랜잭션 트랜잭션 트랜잭션은 수십년동안 여러 내결함성 결여로 인해 발생되는 문제를 해결하는 메커니즘으로 채택되어 왔다. 데이터베이스에 접속하는 애플리케이션에서 프로그래밍모델을 단순화 하려는 목적으로 만든 것이다. 안전성보장: safety guarantee: db에서 트랜잭션 사용을 통해 어플의 잠재적 오류와 동시성 문제를 무시할 수 있다. 항상 트랜잭션이 필요한 것은 아니다.‘ 이번장의 중요 질문: 트랜잭션이 필요한지 아닌지 어떻게 알 수 있을까? 애매모호한 트랜잭션의 개념 관계형 데이터베이스는 거의 모두 트랜잭션을 채택하는 경우가 많고, 비관계형 베이스는 채택하는 경우도, 아닌 경우도 있다. ⇒ 이 과정에서 트랜잭션의 의미가 약화되었다. ACID의 의미 원자성(atomicity), 일관성 (consistency.. 2023. 4. 26. 데이터 중심 애플리케이션 설계 - 파티셔닝 파티셔닝 샤딩 : 데이터를 파티션으로 쪼갤 필요가 있다. 파티션 : region, tablet, vnode, vbucket 처럼 서비스마다 쓰이는 용어가 다양하다. 데이터 단위가 하나의 파티션에 속한다. 파티셔닝을 원하는 주된 이유는 확장성이다. ⇒ 분산하여 질의 부하를 감소시킴 트랜잭션 기반인지, 분석 기반인지에 따라 시스템을 튜닝하는 방법은 다르지만, 기본적으로 둘ㄷ ㅏ파티셔닝의 원칙이 적용된다. 파티셔닝과 복제 보통 복제와 파티셔닝을 함께 적용해 각 파티션의 복사본을 여러노드에 적용한다. 한 노드에 여러 파티션을 저장할 수도 있다. 각 파티션마다 리더파티션이 있는 구조 키-값 데이터 파티셔닝 파티셔닝의 목적은 질의부하를 노드사이에 고르게 분산시키는 것이다. Skewed: 파티셔닝이 고르게 이루어지지.. 2023. 4. 24. 데이터 중심 애플리케이션 설계 - 복제 - 다중 리더 복제 다중 리더 복제 리더에 대한 의존성이 높다. 리더가 여러개: 다중리더설정, 마스터미스터 액티브/액티브 복제 다중 리더 복제의 사용사례 다중 데이터센터 운영 데이터 센터마다 리더를 두고 복제를 진행 오프라인 작업을 하는 클라이언트 인터넷이 끊어진 동안 앱이 계속 동작해야하는 경우 이 경우 로컬 데이터베이스가 있다. 아키텍처 관점에서 보면 근본적으로 다중 리더복제와 동일하다.(구글 캘린더?) 협업 편집 실시간 협업 편집 애플리케이션: ex 구글독스 오프라인 사용 사례와 공통점이 많다. 로컬에 적용하고 이후 비동기방식으로 타 사용자의 db와 연동한다. 충돌이 없으려면 편집전 문서의 lock을 얻어야한다. [펌] 파일락(File Lock) 쓰기 충돌 다루기 동기 대 비동기 충돌감지 단일 리더: 들어온 순서대로 .. 2023. 4. 21. 데이터 중심 애플리케이션 설계 - 복제 - 복제 지연 문제- 복제 지연 문제 리더기반 복제 : read-scaling 아키텍처 쓰기는 하나의 노드에서(리더기반) 나머지 복제된 노드는 읽기 처리만 진행하면 됨 쓰기비율이 낮고 읽기 비율이 높은 경우 유용하다. 실제로는 비동기식 복제에서만 동작한다. 동기식으로 처리시 네트워크 중단 등으로 시스템 불안정 초래 또한 비동기 처리 후 과거 데이터를 보여줄 수 있음.(불일치 발생=일시적인 효과 ⇒ 최종적 일관성) 자신이 쓴 내용읽기 일반적으로 사용자는 사용자가 제출한 데이터를 읽을 수 있음. 이때 종종 새로운 데이터는 리더에게 전송하지만 팔로워에서 읽을 수 있도록 함 ⇒ 데이터가 팔로워에 반영되지 않을 경우 유실된 것처럼 보이기도 함. 이 경우 입력은 보장하나 읽기는 보장할 수 없다 ⇒ 쓰기 후 읽기 일관성의 필요성 수정 시.. 2023. 4. 20. 이전 1 2 3 다음