💡 개요 Bulk을 사용한 저장이 하나씩 저장하는 것보다 빠른 이유에 대해 정리해 보자. 🛠️ Bulk Bulk을 사용한 저장이란, 여러 데이터를 한번에 모아 저장하는 것을 말한다. 일반적으로 Batch Insert나 Bulk Insert 등으로 표현된다. 하나씩 저장for (User user : userList) { userRepository.save(user);} 한번에 모아 저장userRepository.saveAll(userList); 한 번에 저장하는 방식이 성능 면에서 유리한 이유는 무엇일까? 가장 큰 이유는 지연 시간 감소에 있다. 일반적으로 데이터베이스는 데이터를 저장할 때 트랜잭션을 사용한다. 데이터를 하나씩 저장하면 그에 따라 커밋도 여러 번 발생하게 되고, 이..

💡 개요 오늘은 데이터를 주고받을 때 사용되는 데이터 타입인 MIME에 대해 정리해 보자. 🛠️ MIME MIME(Multipurpose Internet Mail Extensions)은 이메일을 비롯한 인터넷을 통한 데이터 전송에서 텍스트 이외의 다양한 형식의 데이터를 전송할 수 있게 해주는 표준이다. 보통 이메일을 전송할 땐 내부에 텍스트 뿐만 아니라 파일을 전송하는 경우가 많다. 그래서 첨부파일과 같은 데이터는 MIME을 사용해 영문과 숫자 조합으로 변환하여 메일 본문 내부에 포함하면, 마치 첨부파일을 텍스트 데이터처럼 처리한다. 한글로 작성된 메일은 7비트 US-ASCII로 표현을 못하기 때문에 위와 같은 방법으로 MIME을 활용하고 있다. 실제로 MIME을 사용한 메일 데이터를 보면..

💡 개요 오늘은 DB의 테이블에 적용되는 레코드 수준의 잠금이 뭔지 정리해 보자. 🛠️ 레코드 수준의 잠금 레코드 수준의 잠금은 DB을 공부할 때마다 자주 나오는 용어이다. 여기서 레코드란 테이블의 한 행 을 의미하며, 레코드 수준의 잠금은 특정 행을 하나의 트랜잭션이 점유(lock)함으로써, 다른 트랜잭션이 해당 행에 접근(읽기 또는 쓰기)하지 못하도록 막는 것을 말한다. MySQL에 여러 트랜잭션이 동일한 테이블에 데이터를 삽입할 때 레코드 수준의 잠금 때문에 지연이 발생한다고 알고있다. 내가 보기엔 그러한 이유는 테이블에는 고유한 인덱스가 부여되기 때문인데, 이를 유지하려면 삽입 시 해당 인덱스에 대한 잠금이 필요하기 때문이다. 즉, 동시에 여러 트랜잭션이 같은 인덱스를 갱신하려고 하..

💡 개요 어젠 WebRTC의 연결과정에서 사용되는 기술이나 프로토콜을 정리했다. 오늘은 WebRTC에서 사용되는 화상통화 구현 방식에 대해 정리해 보자. 👨🏻‍💻 WebRTC 구현 방식 WebRTC를 구현할 때 주로 사용되는 서버 형태는 주로 Signaling, SFU, MCU가 있다. ⚙️ Signaling Signaling 서버의 역할은 피어 간에 offer, answer, ICE candidate 등 초기 연결 정보를 중계하는 것이다. 즉, WebRTC 연결이 성립되기 전까지 필요한 메타데이터만 전달할 뿐, 실제 미디어(오디오/비디오) 데이터는 중계하지 않는다. 그렇기 때문에 피어(화상채팅을 하고자하는 사용자)가 서로 연결될 때 서버의 부하가 발생한다. 그 이후엔 별도의 부하는 ..

💡 개요 SSAFY할 때 한번 써봤던 것.. 하지만 너무 오래돼서 기억이 안 나기 때문에 한번 정리해 보자. 🛠️ WebRTC WebRTC란 웹 브라우저 내부에서 따로 플러그인을 설치하지 않고 오디오, 비디오, 일반 채팅을 실시간으로 주고받을 수 있게 해주는 기술이다. 그리고 오디오나 비디오같은 데이터는 P2P(Peer-To-Peer) 방식으로 전송된다. ✨ P2P P2P란 한 피어와 다른 피어가 데이터를 주고받는 통신 방식을 의미하는데, 여기서 피어는 WebRTC 통신에 참여하는 다른 사용자(브라우저)를 의미한다. 그렇기 때문에 두 사용자 사이에 중간 서버를 거치지 않고, 직접 데이터를 주고받기 때문에 속도 측면에서 더 유리하다. 하지만 처음 연결을 성립할 땐 연결 과정(시그널링), N..

💡 개요 오늘은 회원의 비밀번호를 암호화하는 로직에 대해 정리해 보자. 🛠️ 비밀번호 암호화 보통 회원의 정보를 담고 있는 데이터베이스의 테이블에선 비밀번호를 단방향 암호화를 진행한 후, 저장된다. 그렇게 때문에 아무리 실제 DB에 접근할 수 있는 개발자라고 해도, 회원의 비밀번호는 알 수 없다. 이러한 이유 때문에 비밀번호를 찾을 때 사용중이던 비밀번호를 알려주는 것이 아니라 아예 비밀번호를 재설정하는 것 이다. DB도 찐 비밀번호를 모르기 때문! 그런데 회원이 로그인을 위해 입력하는 비밀번호는 평문아닌가? 회원이 입력한 평문 형태의 비밀번호와 DB에 저장된 암호화된 비밀번호를 어떻게 비교하는 거지? ⚙️ 단방향 해시 Spring에서 사용하는 대표적인 단방향 해시 기술은 BCryptP..