본문 바로가기

분류 전체보기

 (319)
MySQL의 기본 -2 InnoDB의 MVCC와 일관된 읽기 InnoDB는 MVCC(Multi-Version Concurrency Control, 다중 버전 동시성 제어)를 통해, 여러 트랜잭션이 동시에 안전하게 데이터를 읽고 쓸 수 있도록 보장합니다. 이 방식에서는 한 레코드에 대해 여러 버전의 데이터가 언두 로그(Undo Log)에 보관되어, 각각의 트랜잭션이 일관된 데이터를 볼 수 있게 해줍니다.데이터 버전 관리와 격리 수준에 따른 조회 UPDATE와 같은 변경 쿼리가 실행되면, InnoDB는 커밋 여부와 무관하게 버퍼 풀(Buffer Pool)에서 데이터를 갱신합니다. 데이터 파일(디스크)은 Write 스레드나 체크포인트 시점에만 동기화될 수 있으며, ACID 보장을 위해 일반적으로 버퍼 풀과 데이터 파일의 상태가 일치..
MySQL의 기본(이해가 필요한 내용 다시 읽어보기) -1 MySQL의 메모리 구조MySQL의 메모리 구조는 공식 문서 기준으로 글로벌 메모리 영역(Global Memory Area)과 로컬(세션/커넥션) 메모리 영역(Local/Session Memory Area)으로 나뉩니다. 글로벌 메모리 영역은 MySQL 서버가 시작될 때 운영체제로부터 할당받으며, 모든 클라이언트 스레드가 공유합니다. 대표적으로 InnoDB 버퍼 풀, 테이블 캐시, 리두 로그 버퍼, InnoDB 어댑티브 해시 인덱스, 스레드 캐시, MyISAM 키 캐시 등이 있습니다. 로컬 메모리 영역(세션/커넥션 메모리 영역)은 각 클라이언트 커넥션(스레드)별로 독립적으로 할당됩니다. 커넥션 버퍼, 소트 버퍼, 조인 버퍼, 결과 버퍼, 바이너리 로그 캐시, 네트워크 버퍼 등이 여기에 속합니다. 이 영역..
Redis에 대해서 -6 Redis의 Set 자료구조 내부 동작 방식과 저장 전략Redis에서 Set은 중복되지 않는 원소들의 집합을 저장하는 자료구조로, 순서가 없으며 특정 값의 존재 여부를 빠르게 확인할 수 있는 특징이 있다. Redis는 이러한 Set을 내부적으로 다양한 방식으로 저장하며, Set의 크기와 저장되는 값의 특성에 따라 최적의 자료구조를 자동으로 선택하여 성능과 메모리 효율을 극대화한다.Redis가 Set을 저장할 때 사용하는 내부 자료구조와 그 동작 방식먼저 Redis의 Set은 정확히 세 가지 내부 구현 구조를 가진다. 바로 intset, hashtable, 그리고 Bitmaps과 같은 특별한 경우이다. 흔히 잘못 이해하는 것과 달리, Set은 링크드 리스트를 내부 저장 구조로 사용하지 않는다. 링크드 리스..
Redis에 대해서 -5 Redis에서의 GET, DEL, SET 동작 방식과 메모리 관리 전략Redis를 사용할 때 우리는 종종 GET, SET, DEL 같은 기본 명령어를 무심코 사용했습니다. 하지만 이 단순한 명령어들조차 Redis 내부에서 어떻게 동작하는지, 그리고 그에 따른 메모리 관리 전략은 무엇인지 이해하는 것은 매우 중요합니다. 특히 서비스의 트래픽이 증가하고 대량의 데이터를 Redis에 주고받는 경우, 이러한 내부 동작을 제대로 이해하지 못하면 성능 저하나 장애로 이어질 수 있습니다.우선 GET 명령어는 메모리 누수를 유발하지 않는다. Redis에서 데이터를 조회할 때는 CPU 캐시나 LRU 정책이 간접적인 영향을 줄 수는 있으나, 메모리 측면에서 직접적인 문제가 발생하지 않는다. 단순히 값을 읽기만 하기 때문에..
Redis에 대해서 -4 Redis Pipeline의 원리와 메모리 사용에 대한 고찰 Redis에서 Pipeline은 성능을 향상시키는 대표적인 기법 중 하나다. 여러 개의 명령을 클라이언트가 Redis 서버에 한 번에 전송하고, 그에 대한 응답을 한꺼번에 수신하는 방식으로 작동한다. 이는 단순한 트릭이 아니라, RTT(Round Trip Time)를 획기적으로 줄이고, 시스템 콜 수를 감소시켜 Redis의 초당 처리 능력을 극대화하는 핵심적인 기술이다. 하지만 Pipeline은 항상 긍정적인 효과만을 가져오는 것은 아니다. 특히, 명령어 수가 많아질수록 Redis 서버의 메모리 사용량이 비약적으로 증가할 수 있으며, 이는 실제 운영 환경에서 성능 저하의 원인이 되기도 한다. Pipeline이 필요한 이유: 성능 최적화의 본질 ..
Redis에 대해서 -3 조금은 더 자세하게 Pipeline을 살펴보기위해 작성된 글이다.Redis 파이프라이닝의 메모리 부하: TCP 구조와 단일 스레드의 한계 Redis는 초당 수십만 건의 명령어를 처리할 수 있을 정도로 빠르지만, 그 이면에는 TCP와 커널, 그리고 Redis의 이벤트 루프 구조에 따른 메모리적 병목이 잠재되어 있다. 특히 파이프라이닝(pipelining)은 명령어 전송의 네트워크 효율을 높이는 강력한 기법이지만, 무분별한 사용은 Redis 서버에 상당한 메모리 부하(memory pressure)를 유발할 수 있다. 이 글에서는 파이프라이닝이 어떻게 메모리 부하를 유발하는지, 그리고 그 원인이 어디에 있는지를 TCP의 구조와 Redis의 내부 처리 메커니즘을 통해 분석해보자.파이프라이닝의 동작 흐름과 버퍼의..
Redis에 대해서 -2 Redis PipelineRedis의 파이프라이닝(Pipelining)은 단순한 명령어 전송 최적화 기술을 넘어, TCP 네트워크 계층, OS 커널 수준의 시스템 콜 처리, CPU 메모리 접근 패턴까지 고려한 다단계 성능 최적화 메커니즘이다. 이는 Redis가 초당 수십만 건 이상의 명령어 처리 성능을 구현할 수 있도록 해주는 핵심 요소 중 하나다. Pipelining은 클라이언트가 MULTI 명령 없이도 여러 개의 Redis 명령어를 내부 버퍼에 누적한 뒤, 이를 단일 TCP 패킷으로 서버에 전송하는 방식으로 동작한다. Redis 프로토콜인 RESP(REdis Serialization Protocol)는 텍스트 기반 구조이지만, 매우 단순하고 직관적인 구문 설계를 기반으로 하여 바이트 수준의 직접 파싱..
Redis에 대해서 -1 Redis ArchitectureRedis는 Event-Driven Architecture (EDA)를 따르는 고성능 인메모리 데이터베이스로, 버전 6부터는 기존의 단일 스레드 구조를 확장하여 I/O 멀티스레딩 기능을 도입했습니다. Context Switching의 제거이를 통해 네트워크 처리 병목을 줄이고, 수십만 개의 동시 연결을 보다 효율적으로 처리할 수 있게 되었습니다. 이 구조는 내부적으로 I/O Multiplexing 기술(epoll, kqueue 등)과 Non-blocking socket 그리고 이벤트 루프(Event Loop) 기반의 구조로 운영됩니다. Redis는 클라이언트 연결과 I/O 처리를 비동기적으로 처리하기 위해 epoll (Linux) 혹은 kqueue (BSD/macOS)와 ..

티스토리툴바