Hello backEnd

# 데이터 압축 - 디스크에 저장된 데이터 파일 크기는 일반적으로 쿼리 성능, 백업, 복구 시간과 밀접하게 연결된다. - 쿼리 처리할 때에 데이터 페이지를 InnoDB 버퍼 풀로 읽어서 - 새로운 페이지가 버퍼 풀로 적재되니까 더티 페이지가 더 자주 디스크로 기록되어서 - 데이터 파일이 크면 백업/복구에 오래 걸린다 이를 해결하기 위해 도입된게 데이터 압축 ## 페이지 압축 - Transparent Page Compression이라고도 한다. - MySQL서버가 디스크에 저장하는 시점에 데이터 페이지가 압축되어 저장되고, 읽어올 때에는 압축이 해제되니까 - 즉 버퍼 풀에 데이터 페이지가 한 번 적재되면 InnoDB 스토리지 엔진은 압축이 해제된 상태로만 데이터 페이지를 관리함 - 압축 여부와 관계없이 투..

트랜잭션과 락 트랜잭션 작업의 완전성을 보장 데이터의 정합성 보장 잠금 동시성 제어 기능 트랜잭션 여러 논리작업이 한꺼번에(다같이 되거나 다같이 안되거나) 진행되도록 하는것이다. 그리고 트랜잭션은 무조건 모든곳에 넣는것은 좋지 않은데 예를 들어 유저가 글을 쓰는 로직을 볼 때 유저 정보 가져옴 글쓰기 오류 판별 업로드 파일 확인 및 저장 사용자 입력 정보 DBMS 저장 저장 내용을 DBMS에서 조회 게시물 등록 알림을 메일로 전송 알림 메일 발송 이력을 DBMS 저장 이렇게 보면 3 ~ 4가 실제 DB에 글을 저장하는 로직 7이 DB에 글을 저장하는 로직이다. 그리고 다른 부분은 이를 활용하는 것이거나 '6'번처럼 네트워크를 써서 문제가 생기는 경우가 있을 것이다. 처음부터 트랜잭션을 만들..

아키텍쳐 MySQL엔진 MySQL엔진은 SQL 문장 분석이나 최적화같은 두뇌역할을 수행 얘는 MySQL서버 하나에 한개밖에 없다. 커넥션 핸들러, SQL파서 및 전처리기 옵티마이저 쿼리의 최적화된 실행을 위해 스토리지 엔진 데이터 저장 / 불러오는 역할 수행 이거는 여러개 동시사용 가능하다. 스레딩 구조 MySQL서버는 프로세스가 아니라 스레딩 기반으로 동작 포그라운드 스레드 최소 mysql에 접근한 클라이언트의 수만큼 존재 그래서 사용하면 여기있고 다쓰면 스레드캐시로 돌아감 근데 스레드캐시가 일정 갯수 이상이면 그냥 종료시킨다. 데이터를 데이터버퍼나 캐시로부터 가져온다. 없는 경우에는 직접 디스크나 인덱스 파일에서부터 데이터를 가져옴 (InnoDB기준) 데이터 버퍼나 캐시에 저장 이후는 백그라운드에서 ..

IoC 컨테이너 Inversion of Controll 말하자면 제어의 역전 이라는 것이다. 그래서 그게 뭔데? 라고 하면 말하자면 "주도권을 뺴앗겨서, 그 주도권이 Spring에게 있다."는 뜻이다. 예를 들어 Class 설계도 Object 실체화가 가능한 것 예를 들어 abstract class처럼 실제로 존재하지 않는 것들은 Object가 될 수 없다. Instance 실체화 된 것 이런 3개에 대하여 생각해 보았을 때에 보통은 java에서 Public void MakeHandsomeMan() { Ryoochan ryoochan = new Ryoochan(); }이런 식으로 직접 heap영역에 만들었을 것이다. 그러면 MakeHandsomeMan 에서만 ryoochan이 존재하고, 다른 곳에서는 사..

-> https://www.youtube.com/watch?v=xqrIDHbGjOY&t=4s 카프카를 공부해보기 위해 찾아보다가 정말 좋은 강의가 있어 이론에 대한 기초를 알기 위해 보고 정리해 보았다. 데이터 스트리밍 및 이벤트 기반 데이터 파이프라인을 위한 메시지 큐 시스템. 기본 모양 카프카 클러스터 메세지를 저장하는 저장소 하나의 카프카 클러스터는 여러개의 브로커로 구성된다. 각 브로커는 메세지를 나눠서 저장하고(이중화 처리 / 장애시 대체 등등도 여기서 한다) 한다. 주키퍼는 클러스터를 관리하는데에 쓰인다. 프로듀서 카프카 클러스터에 메세지를 보낸다. 컨슈머 메세지를 카프카에서 읽어오는 역할을 한다. 토픽과 파티션 토픽 메시지를 구분하는 단위 파일시스템의 폴더와 유사 프로듀서가 메시지를 카프카에..

정리 스트림을 활용하는 방법에 관한 내용인데, 사실 이 부분은 어느 정도 알고 있기 때문에 정리하고자 한다. 이전에서 보았듯, 스트림은 내부 반복 뿐 아니라 코드를 병렬로 실행할지 여부를 알고 있다. 그래서 내부적으로 다양한 최적화가 가능하다. 필터링 프레디케이트 필터링 (filter) 프레디케이트를 사용해서 필터핑을 한다. 고유 요소 필터링 (distinct) 이름에서 알 수 있듯, 중복된 값을 제거하는것 객체의 Equals, HashCode를 통해 진행한다. 슬라이싱 요소의 선택이나 스킵 프레디케이트 활용 슬라이싱 Takewhile predicate결과값 이외는 모두 버리는 연산 즉, 결과값이 TRUE일 때까지는 값을 가져오지만 false가 되는 순간 스트림이 중지되고 반환 filter와의 차이점은 ..

코드는 https://github.com/RyooChan/redis-pipeline/tree/main 여기서 확인 가능 Springboot에서 외부 Redis에 값을 넣고 빼보자(feat.pipeline, Spring boot 3.0) 해당 테스트를 하기 전에 Redis는 localhost가 아닌 외부에 존재한다고 가정한다. (외부 레디스를 사용하면 네트워크 지연 시간이 발생하게 될 것이다.) 알다시피 레디스는 굉장히 속도가 빠르다. 그렇지만 레디스와 서버는 TCP 네트워크 모델을 기반으로 통신한다. 이게 무슨 뜻일까... 하면, redis와 서버간의 통신 과정에서 TCP 3-way handshake를 따르고, 여러 번 통신을 하면 결국 속도에서 손해를 볼 수밖에 없다는 것이다. 한번 이를 테스트해 보자..

레디스를 로컬이 아닌 외부에 두는 이유 보통 우리가 공부할 때에는 레디스를 로컬에서 실행한다. 근데 회사를 가면 열에 아홉은 외부 레디스를 쓸 것이다. 로컬에서 실행할때 얻을 수 있는 장점은 빠른 속도 외부 레디스의 경우 통신 과정이 필요하므로 레이턴시가 걸리게 된다. 개발 및 테스트 개발 환경에서의 접근과 설정, 테스트가 용이하다. 정도일 것이다. 단점은 무엇일까?? 어쩌면 뻔하다고 생각될 수 있지만 다음과 같다. 데이터 손상 로컬에 레디스가 존재하는 경우 데이터가 손실될 염려가 더 크다. ex) 서버가 중단되는 경우 데이터의 손상 또 외부에 두게 되면 Redis자체적으로 제공되는 스냅샷을 백업하거나 디스크 로그에 저장하는 등등을 통해 데이터를 조금 더 편하게 저장 가능하다. 확장성 결국 로컬 컴퓨터에..

보통 개발할 때에 반드시 공부하고 적용하는게 페이징일 것 같다. 그리고 아마... 처음에는 offset limit을 써서 적용을 할 것 같다. 이 offset limit에 대해, 그리고 offset limit의 문제점에 대해, 해결 방안에 대해 써보려고 한다. 일단은 간단한 테스트를 위해 CREATE TABLE board ( id INT AUTO_INCREMENT PRIMARY KEY, title VARCHAR(255) NOT NULL, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, updated_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, heart INT DEFAULT 0 );이런 테이..

정리 스트림과 컬렉션의 차이가 뭘까? 사실 회사에서 스트림을 쓰고 있는데 사용하면서도 이게 컬렉션보다 보기 편하고 쓰기 편하군ㅇㅇ 이정도 감상이었는데 이번에 확실히 감이 잡히더라 스트림 시작 여기서 제일 인상깊었고, 컬렉션과의 차이에 대해 쉽게 접근할 수 있었던게, 컬렉션의 주제는 데이터고 스트림의 주제는 계산 이라는 점이었다. 말하자면 컬렉션은 요소 저장 및 접근, 스트림은 그걸 가지고 계산하는 것이 주가 된다는 것이다. 그리고 스트림이 가진 두가지 중요 특징이 파이프라이닝 대부분의 스트림 연산은 스트림 연산끼리 연결해서 커다란 파이프라인을 구성할 수 있도록 스트림 자신을 반환함 lazy(결과값이 필요할 때에 계산하도록... 그니까 알아서 스트림의 중간/최종 연산을 통해 안쓸거는 안쓰게 하는 최적화 같..