이미 소장하고 있다면 판매해 보세요.
|
1장 트랜잭션과 데이터 품질
1.1 데이터 품질저하 원인 1.2 동시성 제어의 중요성 증가 1.3 데이터베이스 제약의 한계 1.4 파일 시스템과 DBMS 1.5 상충 관계 1.6 트랜잭션의 특징 1.7 일관성/격리성에 대한 개발자의 역할 1.8 동시성 제어 1.9 요약 2장 문장 수준 읽기 일관성 2.1 동시 트랜잭션에 의해 나타날 수 있는 이상 현상 2.2 커밋되지 않은 데이터 읽기를 허용할 때 발생하는 현상 2.3 Dirty Read의 전통적인 해법 2.4 완벽한 읽기 일관성 확보 방안 2.5 트랜잭션 격리 수준 2.6 Lock 기반 동시성 제어 2.7 다중 버전 동시성 제어 2.8 완벽하지 않은 격리 수준, Read Committed 2.9 Repeatable Read 및 Serializable 격리 수준 2.10 Predicate Lock 2.11 MVCC 모델에서 읽기 일관성이 보장되지 않는 사례 2.12 요약 3장 문장 수준 쓰기 일관성 3.1 문장 수준 쓰기 일관성 3.2 읽기 모드에 따른 갱신 연산 차이 3.3 Consistent 모드로 갱신할 때 생기는 현상 3.4 Current 모드로 갱신할 때 생기는 현상 3.5 Consistent 모드로 읽고, Current 모드로 갱신할 때 생기는 현상 3.6 Consistent 모드로 대상을 식별하고, Current 모드로 확인 후 갱신 3.7 Oracle 재시작 메커니즘 3.8 Oracle이 재시작 메커니즘을 사용하는 이유 3.9 Oracle은 왜 Update 조건절 값이 변경됐을 때만 재시작할까? 3.10 Full Scan Update 3.11 Repeatable Read 및 Serializable 격리 수준 3.12 MVCC 모델에서 일관성 없게 갱신하는 사례 3.13 요약 4장 트랜잭션 수준 일관성 4.1 트랜잭션 이상 현상 4.1.1 Non-Repeatable Read 4.1.2 Phantom Read 4.2 트랜잭션 격리 수준 4.3 Repeatable Read 격리성 4.3.1 조회만 하는 경우 4.3.2 조회한 값을 변경하는 경우 4.3.3 Repeatable Read 격리성 요약 4.4 Serializable 격리성 4.4.1 조회만 하는 경우 4.4.2 조회한 값을 변경하는 경우 4.4.3 Serializable 격리성 요약 4.5 직렬화 이상 4.5.1 쓰기 왜곡 4.5.2 PostgreSQL 직렬화 가능 스냅샷 격리 4.5.3 Select For Update를 활용한 쓰기 왜곡 방지 4.5.4 강한 직렬화 4.5.5 강한 직렬화 방안 4.6 요약 5장 트랜잭션 동시성 제어 5.1 비관적 동시성 제어 5.2 낙관적 동시성 제어 5.3 데이터 누수 방지 5.4 스냅샷 또는 중간 집계 데이터 활용 5.5 페이지네이션 5.6 선분이력 정합성 유지 5.7 자원 요청 순서 정렬 5.8 대기 없이 큐 데이터 인출 5.9 채번 동시성 높이기 5.10 자율 트랜잭션 활용 5.11 외래 키 제약 구현 5.12 프로그램 병행 실행 제어 5.13 데이터베이스 설계 변경 5.14 One SQL 구현 및 SQL 튜닝 |
조시형의 다른 상품
|
■ 어떤 내용을 다루었나?
1장에서는 데이터 품질 저하의 주요 원인과 이를 방지하기 위한 동시성 제어의 중요성을 살펴본다. 2장에서는 Lock 기반 동시성 제어 모델과 다중 버전 동시성 제어 모델의 근본적인 차이점을 설명하고, 하나의 Select 문을 실행하는 과정에서 나타날 수 있는 비일관성 문제를 다룬다. 3장에서는 하나의 Update 문을 실행하는 과정에 나타날 수 있는 비일관성 현상을 설명하고, 이를 차단하기 위해 각 DBMS가 어떻게 동작하는지를 집중적으로 분석한다. 4장은 하나의 SQL 문을 넘어 트랜잭션 수준에서의 일관성을 조망하며, 격리 수준별로 발생할 수 있는 다양한 왜곡 현상과 해결 방안을 설명한다. 마지막 5장에서는 실무 시스템에서 실제로 적용할 수 있는 비관적/낙관적 동시성 제어, 데이터 누수 방지, 페이징 처리, 자원 요청 순서 정렬, 채번 동시성, 프로그램 병행 실행 제어 등 구체적인 동시성 제어 기법과 적용 사례들을 제시한다. ■ 이 책이 꼭 필요한 독자 1. 금융권(은행·증권·보험) 시스템 개발자 2. 대용량 트랜잭션 처리 시스템 개발자 3. 온디맨드(On-demand) 배치 프로그램 개발자 4. 이기종 DBMS 통합 운영 환경의 개발자 5. 아래 질문에 대한 답변이 명확하지 않은 개발자 · SELECT 수행 중 일부 데이터가 변경되거나 추가된다면? · UPDATE 수행 중 일부 데이터가 변경되거나 추가된다면? · 일련의 SQL을 수행하는 동안 일부 데이터가 변경되거나 추가된다면? · 동시에 진행하던 두 트랜잭션 간 처리 순서가 뒤바뀐다면? ■ 스크립트 다운로드 실습 스크립트는 DBian 포럼(www.dbian.net)에서 다운로드할 수 있다. 좌측 메뉴에서 ‘[도서] DB 트랜잭션 동시성 제어’를 클릭한 후 ‘공지’를 확인하기 바란다. ■ 내욤문의 : www.dbian.net, www.sqlp.co.kr ● 출판사 리뷰 “서버에 귀신이 산다”는 말을 들어본 적이 있는가? IT 현장에서 널리 쓰이는 이 표현은 논리적으로 설명하기 어려운 이상한 현상이 간헐적으로 발생할 때 개발자들이 내뱉는 자조 섞인 탄식이다. DB 서버도 예외는 아니다. 분명히 SQL은 올바르게 작성했는데, 가끔씩 조회 결과가 일관되지 않거나 정합성이 깨진 트랜잭션 결과를 마주한 개발자는 “귀신의 소행”을 의심하게 된다. 하지만 DB 서버에는 귀신이 살지 않는다. 대신 우리가 모르는 복잡한 메커니즘이 조용히 작동하고 있을 뿐이다. 특히 다중 트랜잭션 환경에서 발생하는 대부분의 기이한 현상은 개발자가 현재 사용 중인 DBMS의 Lock 메커니즘을 정확히 이해하지 못한 데서 기인한다. Oracle, SQL Server, MySQL, PostgreSQL 등 각각의 DBMS는 저마다 다른 방식으로 동시성을 제어한다. 그런데도 대부분 개발자들은 이들이 모두 동일하게 동작한다고 가정하며 코드를 작성한다. 이런 잘못된 가정이 문제의 시작이다. 동시성 제어에 대한 이해가 부족한 상태에서 개발된 프로그램들은 다양한 문제를 야기한다. 데이터 정합성이 깨지고, 예측할 수 없는 교착상태가 발생하며, 성능이 급격히 저하되기도 한다. 무엇보다, 문제가 발생해도 재현이 어려워 원인 파악조차 쉽지 않다. Lock에 대한 깊이 있는 이해는 DB를 다루는 모든 개발자에게 필수적이다. 각 DBMS의 특성을 정확히 파악하고, 그에 맞는 트랜잭션 동시성 제어 전략을 수립하는 것은 개발자가 갖추어야 할 핵심 역량이다. 하지만 안타깝게도 이를 체계적으로 다룬 교육 과정이나 실무 중심의 서적은 찾아보기 어렵다. Lock의 내부 동작 원리를 비교 분석한 책들은 있지만, 실제 애플리케이션 개발 관점에서 동시성 제어 기법을 깊이 있게 다룬 자료는 극히 드물다. 이러한 현실에 대한 문제의식이 이 책의 출발점이 되었다. “모든 상황에서 완벽하게 일관성을 보장하는 DBMS는 존재하지 않는다.” 목표는 명확했다. “동일한 트랜잭션이라도 DBMS별 동시성 제어 메커니즘의 차이로 인해 어떻게 서로 다른 결과가 나타나는지를 실무 개발자들에게 알리고, 다중 사용자 환경에서 발생할 수 있는 각종 이상 현상들을 효과적으로 제어하는 방법들을 제시하는 것.” 이 책에서 독자들은 Oracle, SQL Server, MySQL, PostgreSQL의 Lock 엔진이 어떻게 설계되었는지, 각각의 장단점이 무엇인지, 그리고 이러한 차이점들이 실제 애플리케이션에 어떤 영향을 미치는지를 깊이 있게 이해할 수 있을 것이다. 이제 서버에서 “귀신”을 쫓아낼 시간이다. 함께 떠나보자. 책에 대해 궁금한 사항은 저자가 직접 운영하는 아래 인터넷카페로 문의하기 바란다. 디비안 포럼 ▶ www.dbian.net, www.sqlp.co.kr |