일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | 6 | 7 |
8 | 9 | 10 | 11 | 12 | 13 | 14 |
15 | 16 | 17 | 18 | 19 | 20 | 21 |
22 | 23 | 24 | 25 | 26 | 27 | 28 |
29 | 30 | 31 |
- jvm
- redis
- OS
- K8s
- gradle
- 자바 ORM 표준 JPA 프로그래밍
- SpringBoot
- spring
- 보조스트림
- Stack
- 쿠버네티스
- IntellJ
- 이스티오
- 스트림
- Real MySQL
- Kotlin
- MSA
- 자바
- 토비의 스프링
- thread
- mysql
- JPA
- 스프링
- Java
- Collection
- Stream
- 백준
- GC
- list
- 토비의 스프링 정리
- Today
- Total
목록DataBase (14)
인생을 코딩하다.
reWriteBatchedInserts은 MySql 전용 옵션입니다. 사실 PostgreSql에서도 동일하게 사용되는 것으로 착각하고 있었으나 PostgreSql에서는 reWriteBatchedInserts가 아닌 rewriteBatchedStatements 사용하는게 맞습니다. mySql postgreSql reWriteBatchedInserts rewriteBatchedStatements 그럼 reWriteBatchedInserts, rewriteBatchedStatements은 무엇일까요? - 주말에 작성하기
PostgreSql using brin index란? BRIN (Block Range INdex)은 PostgreSQL에서 제공하는 인덱스 유형 중 하나입니다. BRIN 인덱스는 대량의 데이터를 가진 테이블에서 성능을 향상시키기 위해 설계되었습니다. BRIN은 블록 범위를 기반으로 한 인덱스로, 특히 정렬된 데이터에 적합합니다. CREATE TABLE member ( id integer, created_at timestamp, -- other columns ); -- BRIN 인덱스 생성 CREATE INDEX idx_created_at ON member USING BRIN (created_at); BRIN 인덱스는 데이터를 블록 단위로 그룹화하고 각 블록에 대한 최소값과 최대값을 저장합니다. 블록은 데..
Redis Pipeline에 설명하기에 앞서 No Pipeline에 관해 간략하 말씀드리겠습니다. redis는 요청을 보낼 때 일반적으로 아래와 같이 수행됩니다. 클라이언트는 서버에 쿼리를 보내고 일반적으로 차단 방식으로 소켓에서 서버 응답을 읽습니다. 서버는 명령을 처리하고 클라이언트에 응답을 다시 보냅니다. Redis는 클라이언트-서버 모델과 요청/응답 프로토콜을 사용하는 TCP 서버이며, 클라이언트가 서버에 명령을 보내고 응답을 받는 구조입니다. 위 과정은 클라이언트가 연속적으로 많은 요청을 보내야 하는 경우 RTT가 길어져 성능에 악영향을 미칠 수 있습니다. 예를 들어 RTT가 250밀리초인 경우, 초당 최대 4개의 요청만 처리할 수 있습니다. 만약 요청이 1000개라면 엄첨 느리겠죠? 위와 같이..
where절 작성 순서는 query 성능과 연관이 있을까요?SELECT * FROM hyungil.user AS u .... WHERE u.id = ? AND u.name = ? AND u.date = ?상관없습니다. Query Optimizer의 최적화 알고리즘에 의해 알아서 최적화됩니다. 비즈니스 로직의 순서에 맞춰서 작성하면 됩니다.FROM절 작성 순서는 query 성능과 연관이 있을까요?INNER JOINSELECT * FROM hyungil.A INNER JOIN hyungil.B ON A.col = B.col INNER JOIN hyungil.C ON C.col = B.colINNER JOIN은 Query Optimizer의 최적화 알고리즘(순서가 달라도 결과가 같아야 한다.)에 의해 알아서 ..
안녕하세요. 이번에는 MySQL 실행 계획을 통해 페이징 쿼리의 성능을 개선하는 과정을 작성해 보았는데요, UI가 무한 스크롤 방식이 아닌 오프셋 페이지 방식(>)이기 때문에 커서 기반 페이지네이션 쿼리 방식을 사용하지 않고, 오프셋 기반 페이지네이션 쿼리 방식을 커버링 인덱스 방식의 쿼리를 사용하여 페이징 쿼리의 성능을 개선하였습니다. 커서 기반 페이지네이션 : 클라이언트가 가져간 마지막 row의 순서상 다음 row들을 n개 요청, 응답하게 구현 오프셋 기반 페이지네이션 : DB의 offset 쿼리를 사용하여 페이지 단위로 요청/ 응답하게 구현 커버링 인덱스란? 쿼리를 충족시키는 데 필요한 모든 데이터를 갖고 있는 인덱스를 커버링 인덱스(Covering Index) 라고합니다. 인덱스는 데이터를 효율적..
안녕하세요. 오늘은 외래키(Foreign Key)를 사용할 때, 발생할 수 있는 데드락(Dead Lock)에 관해 글을 작성해보았습니다. 우선 외래키(Foreign Key)와 데드락(Dead Lock)란 무엇일까요? 데드락이란, 둘 이상의 프로세스가 다른 프로세스가 점유하고 있는 자원을 서로 기다릴 때 무한 대기에 빠지는 상황을 일컫습니다. 외래키란, 외래키는 두 테이블을 서로 연결하는 데 사용되는 키입니다. 외래키가 포함된 테이블을 자식 테이블이라고 하고 외래키 값을 제공하는 테이블을 부모 테이블이라고 합니다. Real MySQL 3장을 보면, "외래키는 부모테이블이나 자식 테이블에 데이터가 있는지 체크하는 작업이 필요하므로 잠금이 여러 테이블로 전파되고, 그로인해 데드락이 발생할 수 있다. 그래서 실..
안녕하세요. 이번 글은 제가 MySQL Master 서버 이외에 추가적으로 Replication된 Slave 서버를 생성한 이유와 과정에 관해 글을 작성해 보았습니다. 현재 진행중인 프로젝트인 Black-postoffice는 사용자가 지속적으로 증가함하며 많은 양의 트래픽이 발생한다는 가정하에 진행중이기 때문에 하나의 DB 서버로 모든 쓰기/읽기 작업이 집중된다면 쉽게 부하가 발생할 수 있다고 생각했습니다. 따라서 Master 서버 이외에 추가적으로 Replication된 Slave 서버를 두고 모든 읽기 작업(read-only)은 slave에게 향하게 함으로써 트래픽이 분산될 수 있도록 구현하였습니다. 이는 또한 단일 서버일 때 MySQL 서버가 죽게되어, 서비스를 진행할 수 없어 수익을 창출하지 못하..
프로젝트를 scale out 방식으로 확장할 계획을 하면서 그에 따른 session의 정합성에 관한 이슈가 생겼습니다. 별도의 독립적인 session 저장소로 세션의 정합성 문제를 해결하기 위해서는 대표적인 redis와 memcached 데이터 베이스를 고려해볼 수 있습니다. Amazon ElastiCache는 Memcached 및 Redis 캐시 엔진을 지원합니다. 각 엔진에는 몇 가지 장점이 있습니다. 이 항목의 정보를 활용하면 요구 사항에 가장 잘 맞는 엔진과 버전을 선택하는 데 도움이 됩니다. Memcached와 Redis 엔진은 둘 다 인 메모리 키-값 저장소입니다. NoSql 데이터베이스라고도 할 수 있죠. 그러나 실제로 상당한 차이점이 있습니다. session의 정합성 이슈를 해결하기 위해서..