MySQL의 명령어를 공부해본 사람이라면, DROP과 TRUNCATE, DELETE 명령어의 차이를 들어보았을 것이다. 간단하게 이야기를 하자면, DELETE 명령어는 원하는 데이터를 지울 수 있고, 삭제 후 잘못 삭제한 것을 되돌릴 수 있다. TRUNCATE 명령어는 테이블은 삭제하지는 않고, 데이터만 삭제한다. 삭제 후 절대 되돌릴 수 없다. DROP 명령어는 테이블 전체를 삭제한다. 삭제 후 절대 되돌릴 수 없다. 그럼 DROP 명령어는 어떻게 작동하길래, 테이블이 통채로 사라질까?MySQL의 innoDB에서는 테이블을 .ibd 파일로 저장한다. DROP시 .ibd 파일이 어떻게 되는지 살펴보자.mysql> CREATE DATABASE test_db;Query OK, 1 row affecte..
분류 전체보기
MySQL은 내부적으로 OS의 파일 I/O를 사용한다. 그럼 어느 정도는 직접 구현해볼 수 있지 않을까? 우선 MySQL의 아키텍처를 참고해보았다.MySQL은 SQL 구문이 들어오면 Parser -> 전처리기 -> 옵티마이저 -> 엔진 실행기 -> 스토리지 엔진 순서로 동작한다. 설계여기서 옵티마이저와 엔진 실행기는 제거하고 설계했다. 옵티마이저의 실행 계획 알고리즘 CBO를 구현할 역량이 없다고 생각했다. 또 내부적으로 실행 계획에 따라 풀스캔이나 인덱스로 탐색하는 것을 구현해야하는데, 마찬가지로 구현할 역량이 없다고 판단했다. 스토리지 엔진은 InnoDB를 참고했다. 그런 이유로 아키텍처는 아래와 같이 구성했다. 이번 구현에서 초점을 둔 것은, Disk I/O를 최대한 줄이는 것을 목표로 ..
OAuth는 이전에 몇 번 사용해보았는데, 말로 꺼내어 설명하기가 어려웠다. 이번 기회에 정리를 해보려 한다. 이번 포스팅에서는 간단한 소개로 진행할 것이다. 필요 상황우선 세 명의 참여자가 있다고 생각해보자. (캠퍼가 만든 서비스, 사용자, 구글) 캠퍼가 만든 서비스가 있고, 거기서 구글에 연동하려고 한다. 구글에 접근하려면 어떻게 해야할까?가장 쉬운 방법은 구글의 사용자 id와 비번이 있으면 된다.! 문제1. 사용자 입장에서는 캠퍼의 서비스에 맡겨야 한다 (얘네들 주니어 개발자인데 맡길 수 있나? 이 서비스에서 유출되면 다 털리는데)2. 캠퍼의 서비스도 구글의 아이디 비번을 관리하는 것은 매우 큰 부담이다. (털리면 책임져야함)3. 구글도 자신 아이디 비번을 신뢰하지 않는 캠퍼의 서비스가 가지는게..
문제https://www.acmicpc.net/problem/1707풀이 이분 그래프를 판별하는 문제이다. 이분 그래프는 인접한 정점끼리 서로 다른 색으로 칠해서 모든 정점을 두 가지 색으로만 칠할 수 있는 그래프를 말한다. 풀이는 간단한데, 방문 시 1과 -1의 값으로 번갈아가며 방문 배열을 채워나가고, 만약 이전 방문 배열 값과 다음 방문 배열 값이 같으면 NO를 출력하면 끝이다. 그런데 여기서 주의해야할 것은 이분 그래프의 정의인데, 연결되지 않은 정점도 독립적인 그룹으로 이분 그래프의 조건을 만족한다. 그래서 탐색을 시작할 시작점은 방문되지 않은 점이 대상이 된다. (즉 모든 정점이 연결되어 있다고는 가정되어있지 않다! 이것땜에 43프로에서 틀렸다.) 다음은 소스 코드이다.소스 코드import..
MySQL에서 B+ 트리 자료구조를 인덱스로 활용하는 이유가 무엇일까? B+ 트리를 DB 인덱스로 사용하는 이유는 크게 두 가지이다. 시간 복잡도 B+ 트리는 어떤 경우에도 O(log N)의 시간 복잡도를 가지기 때문에 빠른 검색이 가능하다. 이는 데이터가 크거나 데이터베이스가 복잡해져도 효율적인 조회 성능을 보장하는 중요한 장점이다. 예를 들어 이진 트리의 경우 최대 O(N)의 시간 복잡도를 가지게 된다. 하지만 B+ 트리는 균형 트리의 일종으로, 왼쪽과 오른쪽 노드의 밸런스를 항상 유지한다. 디스크 I/O의 효율성그럼 이런 의문이 들 수 있다. AVL 트리, 이진 탐색 트리, 레드-블랙 트리 등의 자료구조도 균형 잡힌 트리인데, 왜 B+ 트리일까? 이 의문점을 해소하려면 우선 한 가지 개념을..
문제https://www.acmicpc.net/problem/11559 풀이bfs가 포함된 빡 구현 문제이다. 제거할 뿌요를 bfs로 찾고, 삭제하고, 중력을 통해 재 정렬을 해야한다. 여러 그룹의 삭제될 뿌요가 한 텀에 있어도 연쇄는 한 번이라는 것을 잊으면 안된다. 여기서 연속된 4개 이상이 연결된 뿌요를 찾아 제거해야하는데, 그냥 BFS를 사용해 탐색하면, ㅓ ㅏ ㅗ ㅜ 모양의 탐색은 visited에 걸려 탐색을 할 수가 없다. 이것은 단순하게 해결 가능한데, 최대 2번까지 방문을 허용하기만 하면 ㅓ ㅏ ㅗ ㅜ 탐색이 가능하게 된다. 중력에 의한 재정렬은 stack을 이용해 구현했다. 제거할 뿌요를 제외한 값을 stack에 push하고, 다시 map[][]의 아래부터 stack에서 pop을 하며 값..