전체 글

오프셋 기반 페이지네이션과 커서 기반 페이지네이션 오프셋 기반 SELECT * FROM table ORDER BY create_at DESC limit 10 offset 0 limit 와 offsey을 사용해서 조회 페이지 단위 구분 1. 오프셋 기반의 데이터 중복 문제 SELECT * FROM post ORDER BY modified_up_time DESC limit 1 offset 0 에서 한 페이지를 넘기면 SELECT * FROM post ORDER BY modified_up_time DESC limit 1 offset 1 으로 검색을 할텐데, 그 사이에 여기서 누군가가 새로운 글을 썼다고 가정했을 때 페이지를 넘겼는데도 똑같은 게시글이 조회가 되는 경우가 생긴다. 2. 오프셋 기반의 성능 저하 ..

프록시 서버란? 프록시 서버(Proxy Server)는 서버와 클라이언트 사이에 클라리언트가 자신을 통해 다른 네트워크 서비스에 간접적으로 접속할 수 있게 해주는 컴퓨터 시스템이나 응용 프로그램을 가리킵니다. 프록시 서버로 쓰는 Nginx Nginx는 비동기 이벤트 기반의 구조와 다수의 연결을 효과적으로 처리 가능한 웹 서버입니다. 주로 Node.js 앞단의 프록시 서버로 활용합니다. 익명 사용자가 직접적으로 서버에 접근하는 것을 차단하고, 간접적으로 한 단계를 더 거치게 만들어서 보안을 강화할 수 있습니다. 실제 포트를 숨길 수 있고, 정적 자원을 gzip 압축하거나, 메인 서버 앞단에서 로깅을 할 수도 있습니다.

@Override @Transactional public void deletePost(Member member, Long postId) { Post post = findPost(postId); // repository에서 Post 찾기 checkPostWriter(member, post); // Post의 작성자가 Member가 일치하는 지 s3ImageServiceImplV1.deleteImageUrlList(post.getImageUrl()); // S3에서 이미지 객체 삭제 post.deletePost(); // Post isDeleted 컬럼 true로 바꾸기 } 내가 작성했던 코드다 해당 코드를 보면 Transactional 이 달려있고 S3에서 이미지를 삭제하는 메서드가 있다. 문제 Entit..

NoSQL 특징 NoSQL은 비관계형 데이터베이스입니다. 스키마가 존재하지 않고 Map 형태로 Key Value 로 이루어져 있으며 관계형 데이터베이스와 달리 PK, FK 등의 관계를 정의 하지 않습니다. 장점 데이터 모델링이 유연합니다. 관계형 데이터베이스에 비해 쓰기와 읽기 성능이 빠릅니다. 최적화된 키 값 저장 기법을 사용해서 응답속도나 처리효율 등에서 성능이 뛰어납니다. 단점 데이터 중복을 계속 업데이트해야 합니다. RDBMS RDBMS는 관계형 데이터베이스입니다. 스키마가 존재하며, Row와 Column 으로 구성되어 있습니다. PK, FK 로 관계를 정의 할 수 있고 PK로 데이터 무결성을 보장하며, FK로 참조 무결성을 보장합니다. 데이터가 이미 정해진 스키마에 따라 저장이 되며 관계를 통해..

S3 버킷의 객체를 삭제하는 방법은 AmazonS3 의존성을 이용해 안에 있는 메서드로 지워주면 된다. 나는 현재 이런 방식으로 저장하고 있는데... { "0": "https://amazonawss3.com/UUID", "1": "https://amazonawss3.com/UUID" } 여기서 value의 uuid(객체 이름)만 가져와서 삭제하라고 하면 된다. @Override public void deleteImageUrlList(Map originalImageUrl) { for(int i = 0; i < originalImageUrl.size(); i++) { String[] urlSplit = originalImageUrl.get(i).toString().split("/"); String objec..

쿼리 최적화란 성능이 낮은 쿼리의 응답 속도를 개선하는 작업입니다. SELECT 에는 꼭 필요한 컬럼만 WHERE절에 가급적이면 별도의 연산을 하지않는 것을 권장여기서 Inefficient 쿼리의 경우, Full Table Scan을 하면서 모든 Cell 값을 탐색하고, 수식을 건 뒤, 조건 충족 여부를 판단해야 합니다. 반편 Improved 쿼리의 경우 기존에 r.value 가 가지고 있는 index를 그대로 활용할 수 있기 때문에 모든 필드 값을 탐색할 필요가 없어 Inefficient 쿼리 대비 더 짧은 러닝 타임을 가질 수 있다. -- Inefficient SELECT m.id, ANY_VALUE(m.title) title, COUNT(r.id) r_count FROM movie m INNER J..