분류 전체보기

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. 헤더..

문제https://www.acmicpc.net/problem/11559 풀이bfs가 포함된 빡 구현 문제이다. 제거할 뿌요를 bfs로 찾고, 삭제하고, 중력을 통해 재 정렬을 해야한다. 여러 그룹의 삭제될 뿌요가 한 텀에 있어도 연쇄는 한 번이라는 것을 잊으면 안된다. 여기서 연속된 4개 이상이 연결된 뿌요를 찾아 제거해야하는데, 그냥 BFS를 사용해 탐색하면, ㅓ ㅏ ㅗ ㅜ 모양의 탐색은 visited에 걸려 탐색을 할 수가 없다. 이것은 단순하게 해결 가능한데, 최대 2번까지 방문을 허용하기만 하면 ㅓ ㅏ ㅗ ㅜ 탐색이 가능하게 된다. 중력에 의한 재정렬은 stack을 이용해 구현했다. 제거할 뿌요를 제외한 값을 stack에 push하고, 다시 map[][]의 아래부터 stack에서 pop을 하며 값..

문제https://www.acmicpc.net/problem/1461풀이정렬을 포함한 구현 문제이다. 처음에는 방문 배열을 적용해 탐색을 해야하나 싶었지만, 다시금 아이디어를 떠올려보니 단순 구현으로 해결될 것 같았다. "세준이가 한 번에 들 수 있는 책"을 보고, 가지고 있는 책의 매개변수를 관리해야하나 싶었는데, 여기서 책의 숫자는 배열상 인덱스 거리와 같기 때문에 단순 배열에서의 거리 이동으로 구현했다.  아이디어는 우선 center를 구한다. center는 세준이가 돌아오는 기점이면서 책을 충전하는 곳이다. 그러기 위해 배열을 입력받을 때 0 인덱스 위치를 포함시켰다. 배열을 정렬하고 값이 0인 인덱스 위치를 저장한다.  그리고 책을 놓으러 다닌다. 여기서 핵심 아이디어는 0에서 가장 멀리 떨어진..

async는 await이 없다면 필요하지 않다는 생각에 코드를 아래처럼 수정한 적이 있다.  기존 코드TaskState.js async deleteTask(taskId) { deleteTaskAPI(taskId) .then(() => this.fetchTasks()) } ..  deleteCard.jsfunction deleteTask() { if (currentTaskId !== null){ taskStateInstance.deleteTask(currentTaskId) .then(() => { alert(`카드가 삭제되었습니다. cardId: ${currentTaskId}`); closeModal(); }) }}deleteCard.js 에서 Ta..

사용자가 카드를 추가하면, 실시간으로 사용자의 히스토리에 view를 업데이트해야하는 요구 조건이 있었다.목록 1에 카드를 추가하면, 히스토리 판넬에도 동시에 기록이 추가되어야 한다.  이를 위해 옵저버 패턴을 적용했다.  카드라는 상태를 관리할 TaskState 클래스를 정의해준다.import {fetchTasksAPI, addTaskAPI, editTaskAPI, deleteTaskAPI} from '../api/taskAPI.js';export class TaskState { constructor() { this.tasks = []; this._observers = []; } subscribe(observer) { this._observers.push(observer); } ..