DevLog 😶

✔️ 객체 지도 프로그래머의 가장 큰 숙제는 '변화하는 요구사항에 얼마나 더 잘 대응할 수 있는가?' 이다. 예를 들어보자. 고양이 스낵바에 새로운 신입 셰프냥이 들어왔다. 신입 셰프냥은 아직 메뉴 숙지에 미숙해서 레시피를 다 외우지 못했다. 이때 손님냥이 알바냥에게 딸기라떼를 주문했고, 알바냥은 신입 셰프냥에게 딸기라떼를 만들라고 지시했다. 하지만 신입 셰프냥은 딸기라떼 레시피를 몰라서 어떻게 해야 할지 고민 중인 상황이라면, 어떤 행위를 할 수 있을까? 1. 수석 셰프냥에게 딸기라떼 만드는 방법 물어보기 2. 레시피 북을 참고하여 딸기라떼 만들기 먼저, 첫 번째 방법의 경우, 만약 딸기라떼의 레시피를 얻을 수는 있지만, 변화하는 요구사항에 대응할 수 없다. 만약 손님이 추가적으로 ‘엇, 근데 딸기라떼..

옛날에 책 읽으면서 작성했던 건데 오랜만에 글 올릴 겸... 시리즈 마무리는 하면 좋을 것 같아서 올리려고 한다 :D ✔️ 자율적으로 행동하는 객체 앞선 챕터에서 늘 강조했던 것처럼, 객체는 자율적으로 행동이 가능하다. 이때, 객체가 행동하는 유일한 이유는, 다른 객체로부터 요청을 수신했기 때문이다. 여기서 요청을 처리하기 위해 객체가 수행하는 행동을 ‘책임’이라고 하며, 자율적인 객체란 스스로의 의지와 판단에 따라서 각자 맡은 책임을 수행하는 객체를 의미한다. 객체가 자신에 의지에 따라서 책임을 자율적으로 수행한다는 게 무엇을 의미하는 걸까? 쉽게 생각하기 위해 다시 고양이 스낵바 예제를 꺼내보자. 고양이 스낵바의 인기가 폭발하면서 아침부터 많은 음료 제조 요청이 들어왔다. 이때 알바냥에 셰프냥에게 ‘..

🌱 디스크 읽기 방식 💬 HDD (하드 디스크 드라이브) / SSD (솔리드 스레이트 드라이브) 메모리에 비해 실제 하드웨어 장치의 발전은 비교적 느리게 발전한다는 소리를 들은 적이 있을 것이다. 특히 HHD는 플래터(원판)을 돌려서 읽고나 쓰다 보니 성능이 매우 느릴 수밖에 없다. 이를 보완하기 위해 등장한 SSD의 경우 기존 하스크 드라이브에서 데이터 저장용 플래터(원판)을 제거하고 그 대신 플래시 메모리를 장착해서 빠르게 데이터를 읽고 쓸 수 있다. 플래시 메모리는 전원이 없어도 데이터가 삭제되지 않으며, 메모리보다는 느리지만 그래도 하드 디스크 드라이브보다는 훨씬 빠르다. 💬 랜덤 I/O와 순차 I/O 디스크 읽기 연산에서 '랜덤 I/O'와 '순차 I/O'라는 말을 들은 적이 있을 것이다. 랜덤 ..

🌱 들어가기 전이번 포스팅에서는 InnoDB의 인덱스와 락의 상관관계와 트랜잭션 격리 수준에 대해서 알아보자. 🌱 인덱스와 락지난 포스팅에서 레코드 락에 대해 정리할 때 다음과 같은 멘트를 남겼다.innoDB의 경우 레코드 자체를 잠그는 것보다는, 인덱스의 레코드를 잠근다.인덱스를 잠그기 때문에 레코드 검색 시 발견된 모든 레코드의 락을 걸게 된다. 예를 들어, crew 테이블에 age = 23인 사람이 100명이라고 생각해보자. 이때, age에는 인덱스가, name에는 인덱스가 걸려있지 않은 상태다.SELECT COUNT(*) FROM crew WHERE age = 23; # result: 100 하지만, age = 23이면서 name = 'journey'인 결과는 1개만 나온다고 가정해보자.SELEC..

🌱 들어가기 전이번 포스팅에서는 트랜잭션에 대한 간단한 개념과, MySQL과 InnoDB 스토리지엔진에서 제공하는 락에 대해서 알아보자. 🌱 트랜잭션 트랜잭션은 하나의 논리적인 작업 셋에 완전히 적용(commit)되거나, 아무것도 적용되지 않음 (rollback)을 보장해야 한다. InnoDB와 MyISAM 테이블은 트랜잭션 관점에서도 차이를 보이는데, 이를 확인해보자. 우선, 아래와 같이 myISAM과 innoDB를 사용한 2개의 테이블을 만들자.CREATE TABLE tb_myisam ( id INT NOT NULL, PRIMARY KEY (id) ) ENGINE=MYISAM; CREATE TABLE tb_innodb ( id INT NOT NULL, PRIMARY KEY (id) ) ENGINE=i..

🌱 들어가기 전이번 포스팅에서는 InnoDB의 전반적인 아키텍처 중에서 디스크 영역에 대해서 알아보자. 마찬가지로 간단하게만 짚고 넘어가고자 한다. 🌱 Tablespace테이블 스페이스는 데이터를 저장하기 위해 사용되는 큰 논리적인 단위이며, Segment -> Extent -> Page -> Row와 같은 형태로 구성된다. MySQL에서 테이블 스페이스는 저장하는 데이터의 종류에 따라서 5가지로 분류가 가능한데, 이는 다음과 같다. - System tablespace - File-Per-Table tablespace - General Tablespace - Temporary Tablespace - Undo Tablespace 🌱 System tablespaceSystem tablespace의 경우 My..

🌱 들어가기 전이번 포스팅에서는 InnoDB의 전반적인 아키텍처 중에서 메모리 영역에 대해서 알아보자. 상당히 복잡하기 때문에 대략적인 내용만 이해하고 넘어가도 충분하다고 생각한다. 🌱 InnoDB 버퍼 풀 (Buffer Pool)위 그림은 MySQL 8.0 기준 InnoDB 구조를 나타낸 그림이다. 이중에서 버퍼 풀의 경우 InnoDB 스토리지 엔진의 가장 핵심적인 부분이다. 디스크의 데이터 파일, 인덱스 정보를 메모리에 캐시도 해둘 수 있고, 쓰기 작업을 지연시켜서 일괄 처리도 가능하다.💡 그렇다면 크기는 어느 정도로 설정해야 할까? 보통 OS 전체 메모리 공간이 8기가 이하라면 50% 정도만 버퍼 풀로 설정하고, 나머지는 다른 프로그램이 사용할 공간으로 남겨두는 것이 좋다. 만약 메모리 공간이 더 ..

🌱 InnoDB 스토리지 엔진 아키텍처MySQL에서 가장 많이 사용하는 스토리지 엔진인 'InnoDB'에 대한 아키텍처를 알아보자.그림이 복잡하기는 하지만, 왼쪽은 이전에 봤던 MySQL 엔진이고, 오른쪽이 InnoDB 스토리지 엔진의 구성도이다. 이번 포스팅에서는 innoDB 스토리지 엔진의 특징에 대해서 알아보도록 하자. 1. PK에 의한 클러스터링기본적으로 InnoDB의 모든 테이블은 PK를 기준으로 클러스터링되어 저장된다. 여기서 클러스터링된다는 것은, PK 값이 비슷한 레코드끼리 묶어서 저장하는 것을 의미한다. PK 값이 레코드의 저장 위치를 결정하기 때문에 신중하게 결정해야 한다. 일반적인 DBMS에서 세컨더리 인덱스의 리프 노드에는 데이터의 실질적인 물리 주소가 들어가서, 해당 인덱스의 데이..

🌱 MySQL 전체 구조MySQL 서버는 크게 MySQL 엔진과 스토리지 엔진으로 나눌 수 있다. MySQL 엔진의 경우 클라이언트로부터 접속하고, 쿼리 요청을 처리하는 커넥션 핸들러와 SQL 파서, 옵지마이저로 이루어져 있다. 쿼리 관련 처리는 이곳에서 하기 때문에, 거의 '두뇌'와 같은 역할을 하면 된다고 생각하자. 스토리지 엔진의 경우 데이터를 실제 디스크에 저장하거나, 혹은 디스크에 저장된 데이터를 읽어오는 작업을 하며 하나의 MySQL 서버는 여러 개의 스토리지 엔진을 사용할 수 있다. MySQL 엔진과 스토리지 엔진은 서로 '핸들러 API'라는 것을 사용하여 데이터를 주고받으며, 어느 정도의 데이터 작업이 일어났는지 확인하고 싶다면 아래와 같이 명령어를 입력하면 된다. show global s..

✔️ 역할, 책임, 협력 (기억에서 잊혀졌겠지만) 1장에서 언급하였던 예제를 다시 가져와보자. 손님냥이 카페에서 커피를 주문하기까지 다음과 같은 요청과 응답이 이루어진다. 1. 손님냥은 알바냥에게 커피를 요청한다. 2. 알바냥은 셰프냥에게 커피를 만들 것을 요청한다. 3. 요청을 받은 셰프냥은 커피를 만들기 시작하면서 응답한다. 이는 손님냥의 커피 주문에 대한 응답이기도 하다. 4. 만든 커피를 알바냥이 건네받아 손님냥에게 응답한다. 여기서 셰프냥이 커피를 만들라는 요청을 받을 수 있는 이유가 무엇이었을까? 셰프냥은 바리스타 자격증이 있기 때문에 커피를 만들라는 요청에 대해 적합하게 대응할 수 있었기 때문이다. 객체지향 세계에서 어떤 객체가 어떤 요청에 대답할 수 있거나 적절한 행동을 할 의무가 있는 경..