MySQL은 내부적으로 OS의 파일 I/O를 사용한다. 그럼 어느 정도는 직접 구현해볼 수 있지 않을까? 우선 MySQL의 아키텍처를 참고해보았다.MySQL은 SQL 구문이 들어오면 Parser -> 전처리기 -> 옵티마이저 -> 엔진 실행기 -> 스토리지 엔진 순서로 동작한다. 설계여기서 옵티마이저와 엔진 실행기는 제거하고 설계했다. 옵티마이저의 실행 계획 알고리즘 CBO를 구현할 역량이 없다고 생각했다. 또 내부적으로 실행 계획에 따라 풀스캔이나 인덱스로 탐색하는 것을 구현해야하는데, 마찬가지로 구현할 역량이 없다고 판단했다. 스토리지 엔진은 InnoDB를 참고했다. 그런 이유로 아키텍처는 아래와 같이 구성했다. 이번 구현에서 초점을 둔 것은, Disk I/O를 최대한 줄이는 것을 목표로 ..
csv을 이용해 100만 개의 데이터를 DB에 넣은 상태이다. explain 명령을 통해 각 쿼리의 실행 계획이 어떻게 변화하는지를 살펴보자. Explain과 AnalyzeExplain우선, mysql에서 explain 키워드를 붙이면 아래와 같이 실행 계획을 조회할 수 있다. explain은 쿼리를 직접 실행하지는 않는다. 여기서 나오는 각 필드의 개념을 표로 정리해보았다.항목내용id실행계획의 순서. 이 순서대로 select 문이 실행select typeSIMPLE : 단순 select문PRIMARY : 첫번째 쿼리DERIVED : select문으로 추출된 테이블 ( from 절에서의 서브쿼리 또는 inline view)SUBQUERY : sub query 중 첫번째 select문UNION : U..
OAuth는 이전에 몇 번 사용해보았는데, 말로 꺼내어 설명하기가 어려웠다. 이번 기회에 정리를 해보려 한다. 이번 포스팅에서는 간단한 소개로 진행할 것이다. 필요 상황우선 세 명의 참여자가 있다고 생각해보자. (캠퍼가 만든 서비스, 사용자, 구글) 캠퍼가 만든 서비스가 있고, 거기서 구글에 연동하려고 한다. 구글에 접근하려면 어떻게 해야할까?가장 쉬운 방법은 구글의 사용자 id와 비번이 있으면 된다.! 문제1. 사용자 입장에서는 캠퍼의 서비스에 맡겨야 한다 (얘네들 주니어 개발자인데 맡길 수 있나? 이 서비스에서 유출되면 다 털리는데)2. 캠퍼의 서비스도 구글의 아이디 비번을 관리하는 것은 매우 큰 부담이다. (털리면 책임져야함)3. 구글도 자신 아이디 비번을 신뢰하지 않는 캠퍼의 서비스가 가지는게..
MySQL에서 B+ 트리 자료구조를 인덱스로 활용하는 이유가 무엇일까? B+ 트리를 DB 인덱스로 사용하는 이유는 크게 두 가지이다. 시간 복잡도 B+ 트리는 어떤 경우에도 O(log N)의 시간 복잡도를 가지기 때문에 빠른 검색이 가능하다. 이는 데이터가 크거나 데이터베이스가 복잡해져도 효율적인 조회 성능을 보장하는 중요한 장점이다. 예를 들어 이진 트리의 경우 최대 O(N)의 시간 복잡도를 가지게 된다. 하지만 B+ 트리는 균형 트리의 일종으로, 왼쪽과 오른쪽 노드의 밸런스를 항상 유지한다. 디스크 I/O의 효율성그럼 이런 의문이 들 수 있다. AVL 트리, 이진 탐색 트리, 레드-블랙 트리 등의 자료구조도 균형 잡힌 트리인데, 왜 B+ 트리일까? 이 의문점을 해소하려면 우선 한 가지 개념을..
Node.js로 간단한 WAS를 구현하면서 직접 HTTP 메시지 파싱 기능을 만들어보았다. 처음에는 HTTP 요청을 받아 파싱하는 과정이 단순할 것이라 생각했지만, 실제 구현 과정에서는 다양한 예외 케이스를 마주했다. 특히, 요청이 예상과 다르게 분할되거나 헤더와 바디의 경계를 처리하는 과정에서 난관이 많았다. 같은 문제로 고생하는 다른 캠퍼들도 많았고, 문득 스프링에서는 HTTP 메시지를 어떻게 파싱하고 있는지가 궁금해졌다. 직접 라이브러리 코드를 분석해보니, 예상과는 다르게 동작하는 부분이 많았다. 스프링에서의 HTTP 메시지 파싱 방식 스프링이 내부적으로 HTTP 요청을 처리하는 방식을 살펴보면, 기본적인 흐름은 다음과 같다. 1. 포인터 방식으로 HTTP 메시지를 한 글자씩 읽어 나간다.2...
지금껏 MySQL을 쓰면서 innoDB는 무엇이고 스레드풀은 무엇인지 등, 내부에 대해 용어만 듣고 정확히 아는 것이 별로 없었다. MySQL의 내부를 살펴보며 각각을 하나씩 살펴보려고 한다. MySQL 엔진 아키텍처MySQL 서버는 크게 MySQL 엔진과 스토리지 엔진의 두 가지로 나뉜다. MySQL 엔진은 클라이언트로부터 요청된 문장을 분석하거나, 최적화하여 처리하는 역할을 담당하는데, 그림에서 보이듯 커넥션 핸들러, 파서, SQL 인터페이스, SQL 옵티마이저, 캐시버퍼 등이 있다. 스토리지 엔진은 실제 데이터를 디스크 스토리지에 저장하거나 조회하는 역할을 담당한다. 여러 엔진을 동시에 사용할 수 있다. MyISAM 엔진, InnoDB 엔진 등이 있다. 이렇게만 말하면 확 와닿지는 않으니, 실제 ..