개발놀이터

데이터베이스에서 가장 중요한 작업은 뭘까요? Create? Read? 어느것 하나 중요하지 않은게 없죠. 그럼 데이터베이스에서 가장 리소스가 많이 드는 작업은 뭘까요? HDD에선 헤드를 여러번 움직여야하고 SSD에선 erase 후에 write 를 해야하는 CUD가 아닐까 싶습니다. 이번 포스팅에선 데이터베이스에서 리소스가 가장 많이 드는 작업인 CUD를 데이터베이스들이 어떻게 최적화하는지에 대해서 공부해본 내용을 정리해볼까합니다. Dirty Page데이터베이스는 삽입, 변경, 삭제 쿼리 (이하 쓰기 쿼리) 가 들어오면 곧장 이를 물리적인 저장소에 저장하는 것이 아니라 Page라고 부르는 메모리에 저장해뒀다가 한번에 flush라는 명령어를 통해 밀어넣습니다. 이렇게 쿼리가 실행되고 메모리에 올라와있..

PostgreSQL은 이제 명실상부 RDBMS의 대표주자로서 자리를 잡았습니다. 다양한 인덱스 설정으로 RDBMS 중에서도 읽기 성능은 상위권에 있으면서, 개발자가 원한다면 CP 데이터베이스 AP 데이터베이스로 스왑이 가능하고, 오픈소스라는 특징 때문에 엄청나게 방대한 커뮤니티를 가지고 있다는 것이 바로 그 이유이죠. 이런 팔방미인 PostgreSQL에게 약점이 있으니 바로 Vacuum입니다. PostgreSQL은 튜닝할 수 있는 설정이 굉장히 많아서 잘만 사용하면 뛰어난 성능의 데이터베이스로 만들 수 있지만 자칫 잘못 사용하면 겉잡을 수 없이 커지는 장애가 발생하게 되는데요. 오늘 포스팅에서는 PostgreSQL의 1순위 장애 이유인 Auto Vacuum Bloating에 대해서 공부해본 내용을 정..

요즘 사이드프로젝트가 끝나고 어떤 공부를 해야할지 고민중이었는데 평소에 궁금했던 gRPC에 대해서 공부해보았습니다. 이번 포스팅에선 서버간 통신에서 REST API의 대안이 된 gRPC에 대해서 정리해봤습니다. gRPC의 세가지 무기gRPC는 세개의 무기를 가지고 있습니다. 바로 헤더 압축, Protobuf, 멀티플렉싱이죠. 각각의 특징이 gRPC가 왜 서버간 동기 통신에서 선택받았는지 자세히 정리해보겠습니다. 헤더 압축저도 gRPC를 공부하면서 깜짝 놀랐습니다. 헤더 압축? 헤더가 뭐 얼마나 된다고 헤더를 압축해? 근데 엄청나게 차이가 많이납니다. 이번 섹션에선 기존 HTTP/1.1을 사용하는 REST API와 HTTP/2를 사용하는 gRPC에 각각 요청을 직접 날려보면서 패킷을 뜯어보고 헤더 압..

죄송합니다.. 블로그 인생 처음으로 어그로좀 끌어봤습니다... 이번 포스팅에선 비밀번호 암호화, 암호화 된 해시값을 추적하는 해킹 기법들, 그리고 어떻게 웹 개발자로서 방지할 수 있는지에 대해서 공부한 내용을 정리해보도록 하겠습니다. 비밀번호 암호화보통 비밀번호는 평문으로 저장하는건 위험하다고 알려져있습니다. 데이터베이스가 털렸을 때를 대비해서 비밀번호만큼은 지켜낸다는 일념인 것이죠. 데이터베이스를 털릴걸 가정하고 암호화를 한다니? 데이터베이스가 털릴걸 가정하고 암호화를 하는게 아니라 데이터베이스가 '털리더라도' 안전하게 지키는 것이 목적인 것이죠. 그런 의미에서 base64로 인코딩하는건 말도안되는 소리지요. base64는 역연산으로 얼마든지 비밀번호를 얻어낼 수 있으니까요. BCryptBCry..

이번 포스팅에서는 CAP정리를 간단하게 복기해보고 CP, AP 데이터베이스의 특징에 대해서 정리해보도록 하겠습니다.  CAP 정리CAP 정리는 2000년에 Brewer가 발표한 이론으로서 "분산 시스템에서 C, A, P를 모두 만족하는 데이터베이스는 없다" 라는 이론입니다. 이 이론에 대한 증명이 끝났기 때문에 더이상 이론이 아니라 정리라고 불러야하는 것이죠.  CAP 정리에 대해 포스팅한 것이 있어서 그걸 좀 가져와봤습니다.  https://coding-review.tistory.com/312 CAP 정리와 한계 PACELC 정리이번 포스팅에서는 Brewer (브루어)의 CAP정리에 대해서 알아보도록 하겠습니다. CAP정리가 20년도 더 된 정리이기 때문에 그걸 보완한 PACELC 정리에 대해서도 알아..

NoSQL 중에서 가장 인기있는 데이터베이스를 꼽아보라고 한다면 당연 MongoDB이지않을까 싶습니다. 저도 NoSQL에 대해서 공부하기 전에도 MongoDB는 알고 있었을 정도니까 말 다한것이죠.  오늘 포스팅에선 NoSQL 그 중에서 MongoDB가 어느 부분이 특별해서 이렇게 많은 개발자들에게 사랑받고 있는지 정리해봤습니다.  MongoDB의 구성 요소MongoDB의 구성요소는 RDBMS의 그것과 굉장히 닮아있습니다. 하나씩 살펴보겠습니다.  Collection : Collection은 RDBMS에서 테이블에 해당하는 개념으로 문서들의 집합체입니다. Collection은 스키마가 따로 존재하지 않아서 다양한 구조의 문서를 저장할 수 있습니다. Document : MongoDB의 데이터 저장 단위로 ..

약 20일전에 "메세지 브로커의 근심과 걱정" 이라는 포스팅을 작성하였습니다.  https://coding-review.tistory.com/566 메세지 브로커의 근심과 걱정마이크로 서비스와 메세지 브로커는 뗄 수 없는 사이입니다. 서로 다른 도메인이 여러개의 서버로 나눠져 있는 상황에서 모든 서버에 동일하게 데이터를 전달해야 하는 경우에 메세지 브로커만coding-review.tistory.com 위의 포스팅에서는 데이터베이스의 트랜잭션과 메세지 브로커의 통합을 위해서 어떤 부분을 고려해야 하는지에 대한 내용이었습니다.  정상적인 상황에서는 문제 없지만 만약 예외 상황에서 트랜잭션 롤백이 되었을 때 메세지 브로커도 그에 맞춰서 메세지가 전송되지 않아야하는데 트랜잭션과 메세지 브로커를 통합하는 것은 또..

우리가 파일을 다운로드 하는 경우는 정말 흔하게 일어나죠. 그 중에서 이번 포스팅에선 TCP프로토콜을 이용해서 파일을 다운로드 하는 경우에 패킷이 어떤 흐름으로 이동하는지에 대해서 공부해보고 정리해봤습니다! 패킷 한 조각의 모험, 바로 시작해보겠습니다! 패킷의 여행보통 대부분의 네트워크는 TCP/IP 프로토콜을 이용하는 것으로 알고 있습니다. 때문에 이번 포스팅에서도 TCP프로토콜에 한정하여 이야기해보도록 하겠습니다.  서버는 우리 컴퓨터와 네트워크로 연결하기 위해 TCP/IP 프로토콜을 사용합니다. 서버는 TCP연결을 위해 소켓을 여는데 이 소켓은 유닉스 체계에서 파일로 이루어져 있습니다.  파일을 들고 있는 서버는 웹 서버라고 한다면 이 웹 서버는 프로세스 위에서 동작합니다. 즉, 추상화 해보면 프로..

TCP프로토콜은 전세계적으로 가장 많이 사용되는 프로토콜 중 하나인데요. 이 TCP프로토콜이 OS레벨에서는 어떻게 움직이는지 살짝 궁금해져서 공부해보고 정리해봤습니다!  OS레벨에서 개요를 살펴보고 여기에 Nginx, Tomcat이 들어가고 데이터베이스가 어떻게 데이터를 가져오는지 흐름에 대해서 정리해봤습니다.  해당 포스팅은 TCP/IP에 대한 내용이 생략되어있습니다. 아래의 링크에 부족하지만 어느정도 정리가 되어있으니 참고해주시면 감사하겠습니다.  https://coding-review.tistory.com/466 네트워크 흐름제어와 혼잡제어 (Flow Control, Congestion Control)우리가 흔히 말하는 네트워크 통신은 TCP 3way handshaking에 의해 일어납니다. 그리고..

MySQL의 InnoDB 스토리지 엔진의 기본 격리수준은 REPEATABLE READ입니다. 하지만 REPEATABLE READ에서 발생할 수 있는 문제 중 하나인 Phantom Read를 피할 수는 없는데요.  MySQL은 각종 locking 매커니즘을 이용해서 Phantom Read를 막을 수 있었다고 MySQL팀은 설명했습니다. 하지만 무조건 Phantom Read가 발생하지 않는 것은 아닙니다.  이번 포스팅에선 MySQL에 사는 유령에 대해서 공부해보고 정리해봤습니다.  Phantom Read우선 Phantom Read에 대해서 간단하게 짚고 넘어가도록 하겠습니다.  어떤 상황이 Phantom Read를 발생시킬까요? A트랜잭션이 SELECT 쿼리를 날린다B트랜잭션이 이후 INSERT 쿼리를 날..