개발서적

NL 조인의 원리

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. NL 조인은 Nested Loop 조인의 약자로 중첩 루프 문과 같은 방법으로 조인이 이루어진다. 위 두 테이블를 사원 번호로 조인한다고 가정해보자. 프로그래밍 식으로 로직을 구현해보면 다음과 같이 할 수 있다. for(int i=0;i= '19960101' AND e.부서코드 = 'Z123' AND c.관리사원번호 = e.사원번호 AND c. 최종주문금액 >= 20000 위와 같은 쿼리를 실행 후, ROWS | OPERATION 5 |NESTED LOOPS 3 |TABLE ACCESS BY INDEX ROWID OF 사원 2780 | INDEX RANGE SCAN OF 사원_X1 5 | TABLE ACCESS BY INDE..

Chapter 7. 객체 분해

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 프로시저 추상화와 기능 분해 💡 프로시저는 반복적으로 실행되거나 거의 유사하게 실행되는 작업들을 하나의 장소에 모아놓음으로써 로직을 재사용하고 중복을 방지할 수 있는 추상화 방법이다. 전통적인 기능 분해 방법은 시스템을 구성하는 최상위 기능을 정의하고 작은 단계의 하위 기능으로 분해해 나가는 방법을 사용한다. 💡 세분화된 마지막 하위 기능이 프로그래밍 언어로 구현가능한 수준이 될 때까지 계속 된다. 하향식 프로시저 추상화를 통해 만든 프로그램은 다음과 같은 구성이 된다. 최상위 기능(){ 세부기능1(); 세부기능2(); 세부기능3(); .. } 최상위 기능을 수행하기 위한 여러개의 세부기능이 호출되어 원하는 최상위 기능을 수..

Where 조건 절에서 Between 과 Like

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. Between 과 Like의 스캔 범위 차이 Between 과 Like 는 범위 검색을 할 때 활용될 수 있는데, 언뜻 비슷해보이지만 효율적인 측면에서 살펴보면 다르게 동작한다. 예를 들어, 학생 테이블에 생년월 칼럼과 학점 칼럼이 있고 [생년월 + 학점] 이 인덱스라고 가정해보자. 1995년생이면서 학점이 'B'인 레코드들을 검색하기 위해서는 1️⃣ Between 의 경우 SELECT * FROM 학생 WHERE 생년월 BETWEEN "199501" AND "199512" AND 학점 = 'B'; 2️⃣ Like 의 경우 SELECT * FROM 학생 WHERE 생년월 LIKE "1995%" AND 학점 = 'B'; 와 같..

Where 조건 절에서 Between 과 in 의 차이

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. Between 과 In 조건절의 인덱스 스캔 범위 비교해보기 위와 같이, DEPTNO 와 JOB 으로 인덱스를 구성했다고 가정해보자. SELECT * FROM TABLE WHERE DEPTNO BETWEEN 10 AND 30 AND JOB = 'B' 위와 같은 쿼리가 실행되면 어떻게 될까? 먼저, DEPTNO가 10이면서 JOB이 'B' 인 레코드에서 탐색을 시작하여 DEPTNO 가 30이면서 JOB이 'B'가 아니게 되는 레코드 까지 탐색할 것이다. 수직적 탐색은 한번 이루어지지만, 수평적 탐색이 많은 레코드를 탐색하게된다. 반면에, SELECT * FROM TABLE WHERE DEPTNO IN (10,20,30) AND..

Chapter 6. 메시지와 인터페이스

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 메시지와 메서드 💡 메시지란, 객체가 다른 객체에게 유일하게 접근할 수 있는 방법이다. 자바 문법을 예로 들면 아래와 같은 것이 메시지 전송이다. 수신자.오퍼레이션명(인자); [ ex. condition.isSatisfiedBy(screening) ] ❓ 메세지와 메서드는 그러면 같은거 아니야? 만약, 수신자 객체가 인터페이스 형태가 아닌 구현체라면 맞는 말이 될 수 있다. 하지만, 🚨 수신자 객체가 인터페이스로 정의되어있다면, 해당 메시지를 어떻게 구현하느냐에 따라 실제 실행되는 프로세스가 달라진다. 따라서, 💡 메서드는 수신자 객체가 메시지를 받아, 실제로 실행되는 프로세스(함수)를 메서드라고 부른다. 메시지를 전송하는 ..

배치 I/O와 인덱스를 믿고 쿼리에 ORDER BY를 생략하면 안되는 이유

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. 인덱스의 비효율적인 랜덤 I/O 엑세스 인덱스는 큰 테이블에서 소량 데이터를 추출할때 유용하다고 배웠다. 인덱스로 레코드에 접근하는 경우, 인덱스와 연결된 해당 레코드가 존재하는 블록 정보를 통해서 레코드에 접근해야하기 때문에 랜덤 I/O 로 접근해야하고 이 랜덤 I/O가 많아지면, 전체 테이블을 풀 스캔해서 시퀀셜 엑세스로 접근하는게 비용이 더 적어질 수 있기 때문이다. 💡 이러한 성능 비효율을 어느정도 감소시키기 위해, 이전 인덱스를 통해 접근했던 테이블 블록 정보를 저장해두었다가 일치하면 바로 접근하는 캐싱 방법을 사용하긴하지만 인덱스로 정렬된 레코드마다 다른 블록을 가리키면 효과를 보기 힘든 방법이다. 그래서 고안해낸..

Chapter 5. 책임 할당하기

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 책임 주도 설계 데이터를 중심으로 설계하게되면 유연한 설계를 하기 힘들다. 애초에, '데이터' 라는 것은 객체의 구체적인 정보이고, 이는 구현에 해당한다. 따라서, 데이터 중심적 설계는 객체의 구현부에 초점을 맞추고 설계 한다는 의미이다. 그리고, 데이터를 중점으로 객체 간 협력을 생각하게 되면 외부 객체에게 자신의 데이터 정보를 넘겨주는 것이므로 캡슐화를 방해하게된다. 결과적으로, 구현을 중점으로한 설계는 캡슐화를 저해하고 응집도는 낮추고 결합도는 높임으로서 변화에 취약한 설계가 된다. 💡 따라서, 객체 지향의 핵심인 협력, 책임, 역할 중 가장 중요한 책임 을 중점으로 설계하는 것이 유연한 설계를 할 수 있게 해준다. [..

인덱스 튜닝

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. 인덱스를 통해 레코드를 찾아가는 과정 먼저, 인덱스를 활용할 수 있는 인덱스 테이블이 캐싱되어 있는지 확인한다. 캐싱되어 있다면, 인덱스 테이블에서 인덱스 조건에 맞는 레코드를 찾는다. 그러면, 해당 조건에 맞는 실제 디스크 상 레코드의 위치 정보를 파악할 수 있다.(ROWID) 실제 접근해야하는 디스크 상 레코드의 위치는 일반적으로 블록으로 관리하므로, 해당 블록이 이미 버퍼에 캐싱되어 있는지 확인하고 있다면 캐싱된 블록에 접근해서 가져온다. 만약, 그렇지 않다면 실제 디스크로 접근한다. 버퍼에서는 테이블 블록 위치 값을 해싱하여 고유한 값으로 변경 후 관리한다. 그 과정에서, 해싱 계산이 필요하므로 바로 주 메모리 위치를..

인덱스 컬럼 결정과 가공

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. 인덱스 스캔 데이터를 찾는 방법은 크게 2 가지로 나눌 수 있다. 1. 테이블 전체 스캔 2. 인덱스 스캔 테이블 전체 스캔은 말 그대로, 테이블 데이터가 저장되어 있는 블록 전체를 스캔한다. 인덱스 스캔은 인덱스로 설정한 기준에 따라 일정량을 스캔한다. ❓ 인덱스 스캔 방식이 항상 유리할까? 그렇지 않다. 💡 인덱스 스캔 방식은 큰 테이블에서 소량의 데이터를 찾고자 할때 유용하다. 예로, 전체 테이블 스캔을 진행하면 버퍼 캐시에 데이터가 존재하지 않을 시, 모든 레코드를 탐색하므로 오랜 시간이 소요될 수 있다. 하지만, 한번 가져오고 난 뒤에는 해당 테이블과 관련한 데이터는 물리적 I/O 없이 탐색할 수 있다. 인덱스 스캔..

SQL 처리 과정과 I/O

조시형님의 친절한 SQL 튜닝을 읽고 개인적으로 공부한 내용을 정리한 글입니다. SQL 처리 과정 SQL파싱과 최적화 1️⃣ SQL 파싱 사용자로부터 SQL을 전달받으면 SQL 파서가 파싱을 진행한다. 💡 SQL 문을 이루는 개별 구성 요소를 분석하여 파싱 트리를 생성한다. 💡 그리고 전달 받은 SQL 문에서 문법적 오류 (사용할 수 없는 키워드 사용 등) 나 의미상 오류(존재하지 않는 테이블 혹은 컬럼 사용 등)가 존재하는지 확인한다. 2️⃣ SQL 최적화 💡 옵티마이저는 다양한 실행 경로를 생성해서 비교한 후, 가장 효율적인 하나를 선택한다. 그렇게 선택한 경로를 실행 가능한 코드 또는 프로시저 형태로 포맷팅한다. 실행 계획과 비용 MySQL 서버로 요청된 쿼리는 결과는 동일하지만 그 결과를 만들어 ..

Chapter 4. 설계 품질과 트레이드오프

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 협력, 책임, 역할 그리고 설계 품질 협력은 객체들 간 메시지를 주고받으며 진행되는 상호작용이다. 책임은 객체가 수행하는 행동이다. 역할은 책임들의 집합이다. 협력, 책임, 역할 할당이 잘 되어야 바람직한 객체 지향 설계가 가능해진다. 💡 그 중에서도 책임이 잘 할당되는 것이 중요하다. 🚨 역할은 책임의 집합이기 때문에, 책임의 품질에 의존하게 된다. 협력 역시, 책임이 잘 할당되지 못하면 효율적으로 할 수 없게된다. ❓ 책임을 어떤 식으로 할당해야할까? 비슷한 책임끼리 하나의 목적을 위해 협력하는 것 끼리 모아두는 높은 응집도와 다른 책임끼리 분리하는 낮은 결합도를 만족하도록 하는 것이 좋다. 그래야만, 변경이 일어났을 때..

Chapter 3. 역할, 책임, 협력

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 객체 지향에서 가장 중요한 것은 💡 역할, 책임, 협력이다. 클래스, 상속, 지연 바인딩과 같은 개념은 구현에 초점이 맞추어져 있기 때문에, 애플리케이션의 기능을 구현하기 위해 어떤 협력이 필요하고 협력을 위해 어떤 역할과 책임이 필요한지 고민을 하는 것이 더 중요하다. 1️⃣ 협력 객체들이 애플리케이션의 기능을 구현하기 위해 수행하는 상호작용을 말한다. 두 객체의 협력은, 하나의 객체가 다른 객체에게 도움을 요청할 때 시작된다. 객체는 다른 객체의 상세한 내부 구현에 직접 접근할 수 없으므로, 💡 메시지 전송을 통해 협력한다. 만약 다른 객체의 내부 구현에 접근하여 동작한다면, 객체의 자율성을 훼손하는 행위이다. 따라서, ..

Chapter 2. 객체지향 프로그래밍

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 객체 지향 프로그래밍을 할 때, 유념해야할 부분은 다음과 같다. 어떤 클래스가 필요한지 고민하기 전에 어떤 객체들이 필요한지 고민해야한다. 코드로서 바라보기 전에 기능이 동작되는 메커니즘을 잘 생각하라는 의미인 것 같다. 객체를 고립된 존재로 바라보지 말고 협력에 참여하는 협력자로 바라보아야 한다. 무작정 결합도를 줄이려고 노력하기 보다 효율적으로 협력하기 위한 방법을 고민하는 것이 필요하다. 클래스의 경계를 잘 구분 지어야 한다. Chapter 1에서도 많이 설명했듯이, 객체는 자신의 필드를 자신이 관리하도록 해야하며 그러기 위해서는 캡슐화를 통해 외부에 공개하지 않는 것이 좋다. 외부에서 접근이 가능한 메서드를 통해 간접..

Chapter 1. 객체, 설계

조영호님의 오브젝트를 읽고 제 머릿속에 있는 내용들을 정리하며 작성한 글입니다. 변경에 취약한 코드 public class Theater { private TicketSeller ticketSeller; public Theater(TicketSeller ticketSeller) { this.ticketSeller = ticketSeller; } public void enter(Audience audience) { // 관람객 가방에 초대권이 있다면? if (audience.getBag().hasInvitation()) { Ticket ticket = ticketSeller.getTicketOffice().getTicket(); // 티켓 제공 audience.getBag().setTicket(ticket..

대규모 트래픽을 감당할 수 있는 시스템 설계를 위한 기초 지식

도서 가상 면접 사례로 배우는 대규모 시스템 설계 기초 를 보고 정리한 글입니다. 대규모 사용자를 감당할 수 있는 시스템을 설계하기 위한 지식들에 대해서 살펴보자. 📌 RDBMS vs NoSQL RDBMS는 자료를 테이블과 열, 칼럼으로 표현한다. 그리고 SQL을 이용해 테이블에 있는 데이터를, 그 관계에 따라 JOIN 하여 합칠 수 있다. 💡 정형화 된 스키마에 따라 구조화되어 저장되기 때문에, 데이터의 일관성과 무결성을 보장할 수 있다. NoSQL은 대량의 데이터를 처리하는데 특화되어 있다. 💡 데이터의 구조가 비정형이거나 아주 많은 양의 데이터를 저장할 필요가 있을 때 사용하면 좋다. 📌 Scale Up vs Scale Out Scale Up 은 서버에 고사양 자원을 추가하는 행위이고, Scale ..