커서 기반 페이지네이션 커서 기반 페이지네이션은 오프셋 기반 페이지네이션의 한계를 극복하기 위한 방법으로, 마지막으로 읽은 위치를 나타내는 커서 또는 마커를 사용하여 데이터의 연속된 페이지를 효율적으로 검색하는 방식입니다. 커서 기반 페이지네이션은 오프셋 기반 페이지네이션의 한계를 극복하기 위해 커서 또는 마커를 사용하여 마지막으로 읽은 위치를 추적합니다. 커서 기반 페이지네이션에서는 다음과 같은 방식으로 작동합니다. 커서는 마지막으로 읽은 키 또는 마커를 받아옵니다. 이는 데이터셋 내에서 특정 위치를 나타냅니다. 고유 식별자, 타임스탬프 또는 데이터셋 내 위치를 정의하는 다른 값을 사용할 수 있습니다. 오프셋 값 대신 커서를 기반으로 다음 데이터 세트를 검색합니다. 이를 통해 스캔하고 폐기할 필요 없이..
카카오테크캠퍼스
오프셋 기반 페이지네이션 오프셋 기반의 페이지네이션은 페이지를 조회하기 위해 오프셋(offset)과 크기(size)를 사용하는 방식입니다. 이 방식은 특정 페이지의 데이터를 요청할 때, 이전 페이지까지의 데이터를 스캔해야 하는 단점이 있습니다. 이에 따라 성능 이슈가 발생할 수 있습니다. 오프셋 기반의 페이지네이션 구현 레포지터리 구성 먼저 오프셋 기반의 페이지 구성을 사용하도록 레포지터리를 구성해야 합니다. 레포지터리 인터페이스에서 findAllBy 메서드를 정의합니다. public Page findAllByMemberId(Long memberId, Pageable pageRequest) { var params = new MapSqlParameterSource() .addValue("memberId",..
페이지네이션 페이지네이션은 웹 사이트에서 데이터를 한 페이지에 특정 수만큼 표시하도록 하는 기능입니다. 사용자가 다음 페이지를 클릭하면 다음 데이터 세트가 표시되는 것이죠 일반적으로 흔하게 대용량 데이터를 유저에게 제공할 때 쉽게 접할 수 있는 방식입니다. 오프셋 기반 페이지네이션 오프셋 기반 페이지네이션은 가장 일반적인 페이지네이션 방식으로, 데이터의 시작 위치(오프셋)와 한 페이지에 표시할 데이터의 수(리미트)를 지정합니다 예를 들어, 다음과 같이 SQL 쿼리에서 사용할 수 있습니다. public Page getPosts(Long memberId, Pageable pageable) { var posts = findAllBy(memberId, pageable); var count = getCount(m..
조회 최적화를 위한 인덱스 Intro. 왜 인덱스를 써야 할까? 우린 주로 데이터를 메모리와 디스크에 저장한다. 그 중에서도 일반적으로 데이터베이스의 저장된 데이터는 실제로 디스크에 저장 된다 모두가 알다시피 디스크는 메모리에 비해 느리지만, 영속성과 가격 측면에서 유리함을 가지고 있기 때문이다 우리가 고민해야 할 점은 결국 디스크에 데이터에 저장해야 하는데 어떻게 효율적으로 데이터를 읽고 쓰냐이다 디스크에 접근하는 방식에 따라서 크게 랜덤 I/O와 순차 I/O 2가지 방법으로 나뉩니다 순차 접근은 연속된 블록의 데이터를 가져오는 것이며, 랜덤 접근은 특정 위치에 있는 데이터를 가져오는 것입니다. 순차 접근은 데이터를 연속적으로 읽거나 쓰는 작업에서 효율적이지만, 랜덤 접근은 특정 위치의 데이터에 접근해..
정규화 데이터베이스 설계는 어떤 데이터를 어떻게 저장할 것인가에 대한 결정하는 것입니다 그 중에서도 '정규화’와 '반정규화’는 데이터베이스의 효율성과 성능에 큰 영향을 미칩니다 정규화(Normalization) 정규화란 '중복을 최소화하는 것’입니다. 간단하게 말해서, 동일한 데이터를 여러 곳에 반복하여 저장하지 않는 원칙입니다. 이는 데이터베이스 내에서 데이터의 일관성을 유지하는 데 중요합니다. 예를 들어, 사용자의 주소 정보가 변경되었을 때 정규화된 데이터베이스에서는 해당 사용자의 주소 정보를 단 한 번만 변경하면 되지만, 중복이 허용된 데이터베이스에서는 모든 중복된 주소 정보를 찾아 변경해야 합니다. 하지만 이 방식은 트레이드 오프가 있습니다. 데이터를 읽을 때 항상 원본 데이터를 참조해야 하기 때..
Soft Parsing과 Hard Parsing 데이터베이스에서의 쿼리 실행에는 Soft Parsing과 Hard Parsing이라는 두 가지 과정이 있습니다. Soft Parsing Soft Parsing은 쿼리가 이전에 실행되어 이미 Parsing 정보가 캐시에 저장된 경우를 의미합니다. 이런 경우에는 SQL 문장을 파싱하고 옵티마이저를 거치는 과정을 생략하고 바로 쿼리를 실행하게 됩니다 이를 통해 시스템 리소스를 절약하고 응답 시간을 단축시킬 수 있습니다. Hard Parsing Hard Parsing은 쿼리가 처음 실행되거나, 캐시에 파싱 정보가 없는 경우에 이루어집니다. 이 때는 SQL 문장을 파싱하고, 옵티마이저를 거쳐 실행 계획을 작성한 후 쿼리를 실행하게 됩니다. 이 과정은 시스템 리소스를..
MySQL 아키텍처 일반적으로 MySQL 서버와 통신을 할 때는 위와 같은 그림으로 동작합니다 웹 서버에서는 MySQL 서버와 통신하기 위한 컴포넌트인 커넥터를 사용합니다 커넥터는 MySQL 서버와의 연결을 설정하고, 쿼리 및 다른 데이터베이스 작업을 수행하기 위한 인터페이스를 제공하죠 그 대표적인 예시로 JDBC가 있습니다 MySQL 서버 아키테처를 이해하기 위해서는 주요한 컴포넌트들을 알아야 합니다. 이는 MySQL 엔진, 스토리지 엔진, 운영체제, 그리고 디스크로 구성되어 있습니다. MySQL 엔진 MySQL 엔진은 쿼리 파서, 전처리기, 옵티마이저, 그리고 쿼리 실행기로 구성되어 있습니다. 쿼리 파서 쿼리 파서는 사용자로부터 입력 받은 SQL을 파싱하여 Syntax tree를 생성합니다 이 과정에..
대용량 시스템 아키텍처 왜 대용량 처리는 어려운가? 부하가 상당하여 단일 서버나 데이터베이스로는 감당하기 어려운 상황에서, 서버의 스케일 업과 스케일 아웃에서 고민했듯이 다수의 서버와 데이터베이스를 하나처럼 운영해야 한다. 하지만, 동기화와 데이터 일관성 문제 등이 복잡하게 얽혀있다 게다가, 웹 서비스들은 24시간 무중단 운영을 전제로 하므로, 잘못된 코드 한 줄이 서비스 전체에 영향을 미치는 범위가 큽니다. 그리고, 서비스 간 복잡하게 얽힌 의존성은 시스템 복잡도를 급격히 증가시킵니다. 대용량 처리시 지켜야 할 점 고가용성 사용자는 언제든지 서비스를 이용할 수 있어야 합니다. 장애 점을 최소화하고 복구 시간을 단축하는 데에 중점을 두어야 합니다. 확장성 시스템 규모와 사용자 수가 증가하면서 데이터와 트..
스케일 업과 스케일 아웃 클라이언트 입장에서 서비스는 항상 일관된 결과를 반환해야 합니다 하지만 서비스가 발전하면 시스템은 복잡해집니다 또한, 웹 서버를 단순히 늘리는 것만으로는 성능 향상의 한계에 부딪히게 되죠 부족한 리소스를 극복하기 위해 서버의 갯수를 늘리느냐, 크기를 키우느냐에 엔지니어들은 직면하게 됩니다 오늘은 이 문제에 대해 이야기 해봅시다 스케일 업과 스케일 아웃 정의 스케일 업(Scale-Up) 스케일 업이란 하나의 서버의 성능을 향상시키는 방식을 의미합니다. 예를 들면, 서버에 CPU나 RAM을 추가하거나, 디스크 용량을 확장하는 방식이 있습니다. 이런 방식은 설계가 간단하고 데이터의 일관성 유지가 비교적 쉽다는 장점이 있지만, 서버 자체의 물리적 한계가 있고 비용이 많이 들 수 있다는 ..
데이터 변환 with Spring Custom Property Editor: Spring이 사용 가능한 경우 유형 변환에 사용할 첫 번째 메커니즘입니다. 변환 서비스(Converter 및 Formatter 포함): 적합한 사용자 정의 PropertyEditor를 사용할 수 없는 경우 Spring은 해당 유형에 등록된 Converter 또는 Formatter를 사용합니다. 기본 속성 편집기: 다른 변환을 수행할 수 없는 경우 Spring은 기본 PropertyEditor로 폴백합니다. PropertyEditor PropertyEditor는 양방향 유형 변환을 위해 Spring에서 사용되는 Java Beans의 기능입니다. 속성 편집기에는 두 가지 유형이 있습니다. Default Property Editor..
