개발자의 공부 이야기 개발자의 공부 이야기

https://github.com/rlawls1991/commerce/tree/main/docker GitHub - rlawls1991/commerce: 내가 만드는 커머스 내가 만드는 커머스. Contribute to rlawls1991/commerce development by creating an account on GitHub. github.com docker를 이용하여 MySQL 서버 및 Redis 서버를 관리하고자 한다. 버전은 3버전을 선택했으며, docker 이미지는 biarms/mysql 5.7 및 redis 5.08버전을 사용하기로 하였다. 그리고 MySQL 같은 경우 Master/Slave 구조로 작성하였다. version: '3' services: mysql-master: image..

첫 회사의 매운맛을 보고 난 뒤 두번째 회사로 위메프에 들어가게 되었다. 다니면서 새로운 기술, 내가 생각하지 못했던 아키텍쳐 등등.. 많은 사람들에게 도움을 받았고, 배울수가 있었다. 다니면서 내가 개발을 못한다고 생각을 아예 하지 못했다.. 근데 퇴사 후 여러군데 면접을 다니다보니 내가 부족한 부분이 보이기 시작했다. 예를 들면 AWS, Kafka 등등.. 한마디로 우물안 개구리처럼 위메프정도면 나쁘지 않은 회사지 하면서 회사만 열심히 다녔었다. 그룹장님이 새로 오면서 바깥쪽 이야기좀 해주었지만 위메프 정도면 나쁘지 않지.. 라는 생각을 하게되었고, 결국 타회사 면접다니면서 이 말씀이 사실이라는것을 알게되었다. 그래서 내가 한번 만들어 볼려고 한다. 기존에 위메프에서 작업했던것들 중에 내가 개선하고 ..

참고 https://godekdls.github.io/Reactive%20Spring/webclient/#21-configuration

WebFlux 란? Spring WebFlux는 Spring 5에서 새롭게 등장 reactive-stack web framework이며 non-blocking에 reactive stream을 지원 장점 : 고성능, spring 과 완벽한 통합, netty 지원, 비동기 non-blocking 메세지 처리 단점 : 오류처리가 다소 복잡. Back Pressure 기능 없음 참고 https://docs.spring.io/spring-framework/docs/current/reference/html/web-reactive.html#webflux-framework-choice

브로커 카프카 클라이언틑와 데이터를 주고 받기 위해 사용하는 주체 데이터를 분산 저장하여 장애가 발생하더라도 안전하게 사용할 수 있도록 도와주는 애플리케이션 하나의 서버에는 한 개의 카프카 브로커 프로세스가 실행되지만 데이터를 안전하게 보관하기 위해서 3대 이상의 브로커 서버를 1개의 클러스터로 묶어서 운영 카프카 구조 토픽 토픽은 데이터를 구분하기 위해 사용하는 단위입니다. RDBS랑 비슷한 개념 토픽에는 한개 이상의 파티션이 존재하는데 파티션 내부에는 프로듀서로부터 받은 데이터를 보관 위의 데이터를 레코드 토픽에 저장한 데이터들은 먼저 컨슈머가 가져가는 형태로 저장이된다.(FIFO) 컨슈머에서 파티션에 저장되어있는 레코드를 가져가도 삭제 되지 않는다. (RabbitMQ랑 다름) 새로운 컨슈머가 등록이..

테이블 설계시 Index를 고민하면서 설계를 해야되며, 이를 이용해서 쿼리를 잘 작성해야 된다는 것을 알고 있었으나 근래 회사 프로젝트를 진행하면서 더욱 중요하다는 것을 알게 되었다. 좋은 쿼리를 만들 수 있는 방법이 실행계획을 보는 것을 알게 되었고 한번 정리를 해보고자 한다. explain 예시 아래의 쿼리 앞에 사용쿼리 앞에 explain을 붙이면 발생되는 화면이다. (DB 클라이언트는 DBeaver를 사용) 위의 실행계획을 보게 된다면 id, select_type, table, partitions, type, possible_keys, key, key_len, ref, rows를 볼 수 있는데 해당되는 컬럼의 타입은 아래와 같다. select_type id 해당 id 내에 있는 select문 에 ..

디스크 읽기 방식 저장소 하드 디스크 드라이브(HDD)와 솔리드 스테이트 드라이브(SSD) SSD는 기존 하드 디스크 드라이브에서 데이터 저장용 플레터(원판)을 제거하고, 그 대신 플래시 메모리를 장착하고 있다. 그래서 디스크 원판을 기계적으로 회전시킬 필요가 없으므로 아주 빨리 데이터를 읽고 쓸 수 있다. 플레시 메모리는 전원이 공급되지 않아도 데이터가 삭제되지 않는다. 게다가 데이터 베이스 서버에서 순차 I/O 작업은 비중이 크지 않고, 보통 랜덤 I/O 작업을 통해 작은 데이터를 읽고 쓰는 작업이 대부분이기 때문에 DBMS용으로 SSD를 많이 사용하고 있다. 순차 I/O와 랜덤 I/O란 위 그림을 보게 된다면 순차 I/O는 디스크 헤더를 한번만 사용한 반면 랜덤 I/O은 헤더가 3번을 움직였다. 헤..

과거 정리한 내역이다. 해당 내역은 기본적인 이론만 작성했고, 이번에는 기본적인 내용과 깊은 내역까지 정리할 것이다. 2021.03.09 - [DataBase/공통] - DB 트랜잭션 격리수준(Isolation Level) 트랜잭션 격리수준에 따른 발생되는 문제 격리수준(Isolation Level) 설명 READ UNCOMMITTED Shared Lock이 걸리지 않는 상태이다. 해당 그림을 보게 된다면 사용자 A는 Lara라는 데이터를 Insert를 했고, 아직 commit상태가 아닌경우지만 사용자 B는 Lara라는 데이터를 읽을 수가 있다. 즉 coomit 상태가 아닌경우에도 데이터를 읽읅 수 있다. 사용자 A가 처리도중 알 수 없는 오류로 롤백한다고 하더라고 사용자 B는 Lara가 정상적인 상태라..