MJmemento

오늘은 이번년도 5월부터 현재 10월 1일까지를 되돌아보는 시간을 가졌다. 객관적으로 어떻게 학습했고 성장했는가 되돌아볼 필요가 있었다.(서탈도 ㅠ )현재는 컴퓨터공학과 4학년 2학기를 재학 중이다. 기존에 4학년 1학기에 네이버 상반기 공채 면접 기회를 가질 수 있었고, 이에 기분이 설렘도 잠시.. 떨어지고는 CS와 알고리즘에 칼을 갈았다.  알고리즘알고리즘은 카카오 코테 기준으로 봤을 때, 2024 겨울 인턴십 문제를 4시간 45분에 5문제를 다 풀었다. (기억상 지인이 3문제 풀고 면접 갔던 것으로.. 3솔 컷 예상한다.)백준 기준 골드 문제는 이제 1시간 안에는 어떻게든 풀고.. 플레는 헉헉댄다.(백준플레 2는  5시간 시도하고 실패)  CSCS는 개발과 접목해서 생각하고, 쓸 수 있는 정도가 되..

이번에는 간접 쿼리 최적화에 대해 알아볼 예정이다.직접 쿼리 최적화가 많은 문제를 해결하지만, 전부를 해결해 주지는 않는다. 적절하게 인덱스가 되어 있는 쿼리지만 여전히 느린 상황을 접할 수도 있다. 일반적으로는 직접 쿼리 최적화로 충분하나 적은 데이터는 더 나은 성능을 가져오기에 데이터 접근과 스토리지를 줄이는 것이 성능 향상을 위한 기술이라 얘기할 수 있다.  세 가지 비밀MySQL 직접 쿼리 최적화에서 성능을 개선했다고 해도 의도치 않은 결과를 가질 수 있다. 이에 대해 알아보자.  인덱스가 도움이 되지 않을 수 있다. 인덱스 스캔인덱스 스캔은 테이블 행 수가 증가할 수록 인덱스 스캔을 사용하는 쿼리에 대한 응답 시간도 늘어나므로 반드시 지연 시간이 발생한다.이는 테이블 크기와 인덱스 크기가 같이 ..

MySQL은 하드웨어와 최적화, 인덱스를 활용하여 필요한 데이터에 접근할 때 성능을 발휘한다.최적화는 MySQL 측면에서 하드웨어를 효율적으로 활용하게 해주는 다양한 기술과 알고리즘, 데이터 구조를 의미한다.즉, 최적화는 하드웨어 성능에 초점을 맞추는 것이며 하드웨어보다 최적화가 MySQL 성능에 더 많은 영향력을 미치게된다.인덱스가 없는 MySQL 성능은 작은 규모의 데이터만 들어올릴 수 있는 성능으로 제한되지만,균형 잡힌 지렛대에 인덱스를 추가하면 MySQL은 대량의 데이터도 월등한 성능으로 처리한다.  성능 향상과 관련 없는 딴 짓MySQL성능을 향상 시키기 위한 방법을 찾을 때 두 가지 방법이 등장하는데 고사양의 하드웨어를 구매하는 것과 MySQL 튜닝이다.더 좋고 빠른 하드웨어MySQL 성능을 ..

“성능은 곧 쿼리 응답 시간이다.”해당 포스트의 목적은 MySQL 성능을 현저하게 개선하는 것이며, 다양한 측면에서 그 방안을 탐구하고자 한다. MySQL을 관리하는 입장이 아니라 사용하는 입장으로, 최소한의 노력으로 최대한의 성과가 필요한 개발자로서 접근하고자 한다는 것이다. 쿼리 응답 시간(Query Response Time)이란?쿼리 응답 시간은 MySQL이 쿼리를 실행하는데 소요되는 시간이다.소요 시간(timing)은 MySQL이 쿼리를 받을 때 시작되고 결과 세트를 클라이언트에게 전송한 시점까지의 경과 시간을 의미한다.쿼리 응답 시간은 여러 단계와 대기로 구성되지만, 완벽한 상세 명세는 가능하지도 않고 필요하지도 않다.핵심지표(North Star)로서 쿼리 응답 시간솔직히 DB가 빠를 때는 아무..

Spring REST Docs 를 사용하고자 하는 이유에 대해 말씀드리기에 앞서, 사전에 필요한 지식과 선례를 통한 문제 인식을 살펴봅니다. API 문서화 왜 하는 걸까?   표준화 된 API 명세서를 작성할 경우, Front-End, Back-End 개발자 간의 협업을 촉진하며,외부 개발자가 소프트웨어를 쉽게 이해하고 활용할 수 있게 합니다.더불어 정확하고 최신 업데이트 된 API 문서는 시스템의 에러를 빠르게 찾고 해결하는 데 도움이 됩니다 저희들은 이미 협업을 해본 개발자로서, API문서의 필요성과 사용하는 이유를 이미 숙지하고 있다 생각합니다. 그러나 위 설명에 적힌 API 문서 최신 업데이트는 종종 실수하는 요소입니다. (실제로 현재 리펙토링 하고자 하는 기존의 프로젝트의 API 문서도 최신화 ..

현재 FreindShip은 SptringBoot3.2.1 버전을 갖고 현재 개발을 하고 있습니다.그런데 Controller에서 RequestBody에 들어올 값을 직렬화하여 받을 DTO에 아래와 같은 이유로 올바르지 않는 값을 받고 싶지 않았습니다.  💡 이유BAD GUYS의 특수한 입력값을 통한 해킹 시도개발자가 의도하지 않은 양식의 값을 통한 버그그래서 RequestBody로 직렬화하여 DTO를 생성할 때 값이 의도하지 않은 양식이라면 예외 응답을 보내도록 하며, Client에게 양식에 맞게 보내라 하고 싶었습니다. 그래서 @NotNull 과 같은  에서 제공해주는 애노테이션을 통해 입력 값에 대한 검증을 시도하는데,내가 원하는 의도에 맞게 유효성 검사를 커스텀하고 싶어졌습니다.그래서 DTO내부에 ..

회원제 서비스를 구현하게 될 때 무심코 모든 회원의 정보를 하나의 테이블에 넣는 경우가 있습니다.(물론 취향의 차이로 존중해줄 수 있습니다.ㅎㅎ) 이 상태에서 만약 DB가 해킹된다면?회원 정보를 담은 테이블을 읽으면 김명준의 본명과 주소지를 알아낼 수도 있습니다.이를 예방하기 위해서 DB에 넣을 때 소중한 정보를 암호화하여 넣어줄 수 있습니다.그렇게 암호화된 정보를 DB에 저장할 시 ,DB 를 해킹하더라도 암호키를 알지 못한다면, DB에서는 알 수 없는 값이 보여지기 때문에 개인정보를 알아내기 어렵습니다.   그럼 다시, 회원의 모든 정보를 암호화해서 넣어줘야 할까?  물론 모든 정보에 대해 암호화하여 관리하면 더 안전할 겁니다.그러나 자주 사용되고 중요하지 않은 공개될 수 있는 (공개 게시물 제목, 내..

OverViewFriendship의 채팅 시스템은 웹소켓의 프로토콜의 일종인 STOMP 프로토콜을 사용하여 웹소켓을 통해 실시간으로 메시지를 교환합니다. Pub/Sub (Publish-Subscribe) 모델을 따르며, 이를 통해 사용자는 채팅방(chatRoom)에 메시지를 게시하고, 해당 채팅방의 메시지를 구독하는 형태를 따릅니다!  🍊 Pub/Sub 구조란?채팅 구조를 보여드리기 전에, 앞으로 언급될 Pub/Sub 구조에 대한 이해가 필요한데요. 혹시 제 설명이 부족하다면 질문해주시면 답변 드릴 수 있도록 하겠습니다!  먼저 Pub/Sub이란 'Publisher-Subscriber', 즉 '발행자와 구독자'의 약자입니다. 이름에서 알 수 있듯이 한쪽에서 메시지를 전달하는 발행자와, 그 메시지를 받는..