Select와 Disk 사이의 3개 캐시 레이어
Select와 Disk 사이의 3개 캐시 레이어 이 탐구는 세 가지로 나누어 그 중요성과 잠재적 영향을 조사합니다. — Mewayz 비즈니스 OS.
Mewayz Team
Editorial Team
애플리케이션이 SELECT 문을 실행할 때 해당 쿼리는 회전하는 디스크나 원시 플래시 스토리지에 거의 영향을 미치지 않습니다. 쿼리는 응답이 마이크로초 또는 밀리초 단위로 도착하는지 자동으로 결정하는 3개의 개별 캐시 계층을 통과합니다. 이러한 계층을 이해하는 것은 쉽게 확장되는 비즈니스 플랫폼과 실제 부하에 따라 작동하지 않는 비즈니스 플랫폼의 차이입니다.
SELECT 쿼리가 애플리케이션을 떠나는 순간 무슨 일이 발생합니까?
애플리케이션이 SELECT 쿼리를 보내는 순간 대부분의 개발자가 검사하지 않는 파이프라인에 들어갑니다. 데이터베이스 엔진은 I/O가 발생하기 전에 요청을 가로채서 SQL을 내부 실행 계획으로 구문 분석하고 첫 번째 방어선인 쿼리 결과 캐시를 즉시 참조합니다. 최근에 동일한 매개변수를 사용하는 동일한 쿼리가 실행된 경우 엔진은 단일 데이터 페이지를 건드리지 않고도 캐시된 결과 집합을 반환할 수 있습니다. 이를 쿼리 캐시 또는 결과 캐시라고도 하며, 분석 대시보드 및 보고 모듈과 같이 읽기 작업이 많고 쓰기 작업이 적은 워크로드에서는 대부분의 디스크 읽기를 완전히 제거할 수 있습니다.
여기서 중요한 통찰력은 쿼리 캐시가 데이터 변형에 매우 민감하다는 것입니다. 기본 테이블에 대한 INSERT, UPDATE 또는 DELETE는 캐시된 관련 결과를 무효화합니다. 이것이 바로 쓰기가 많은 트랜잭션 시스템이 종종 쿼리 캐시를 완전히 비활성화하고 대신 더 깊은 계층에 의존하는 이유입니다.
버퍼 풀이란 무엇이며 생각보다 중요한 이유는 무엇입니까?
프로덕션 시스템에서 가장 중요한 두 번째 캐시 계층은 버퍼 풀(PostgreSQL에서는 공유 버퍼, MySQL에서는 InnoDB 버퍼 풀이라고 함)입니다. 이는 데이터베이스 엔진이 최근에 액세스한 데이터 페이지를 보관하는 데 사용하는 RAM 영역입니다. 결과 캐시에서 쿼리를 제공할 수 없는 경우 엔진은 디스크 읽기를 실행하기 전에 필요한 데이터 페이지가 버퍼 풀에 이미 있는지 확인합니다.
버퍼 풀은 시간적, 공간적 지역성의 원칙에 따라 작동합니다. 최근에 액세스한 데이터는 다시 액세스할 가능성이 높으며, 액세스한 데이터 근처에 저장된 데이터는 곧 액세스할 가능성이 높습니다. 데이터베이스 관리자는 가장 영향력 있는 구성 결정 중 하나로 버퍼 풀 크기를 조정합니다. 버퍼 풀이 너무 작으면 지속적인 페이지 제거가 발생하여 시스템이 쿼리를 실행하는 것보다 캐시 누락을 관리하는 데 더 많은 시간을 소비하는 스래싱이라는 현상이 발생합니다.
💡 알고 계셨나요?
Mewayz는 8개 이상의 비즈니스 도구를 하나의 플랫폼으로 대체합니다.
CRM · 인보이싱 · HR · 프로젝트 · 예약 · eCommerce · POS · 애널리틱스. 영구 무료 플랜 이용 가능.
무료로 시작하세요 →주요 통찰: 대부분의 OLTP 워크로드에서 적절한 크기의 버퍼 풀은 모든 데이터 읽기의 95~99%가 RAM에서 제공된다는 의미입니다. 쿼리가 실제로 자주 접촉하는 데이터의 하위 집합인 작업 집합은 전체 데이터베이스 크기보다 훨씬 작은 경우가 많습니다. 전체 데이터세트가 아닌 작업 세트에 맞게 버퍼 풀 크기를 조정하는 것은 취할 수 있는 가장 높은 수익을 내는 단일 조정 작업입니다.
운영 체제 캐시는 RAM과 디스크 사이의 간격을 어떻게 메우나요?
데이터베이스 자체 버퍼 풀이 누락된 경우에도 쿼리는 아직 실제 디스크 읽기를 수행하지 않습니다. 운영 체제는 블록 장치에 대한 읽기 및 쓰기를 버퍼링하는 커널 관리 RAM 영역인 페이지 캐시(파일 시스템 캐시라고도 함)를 유지 관리합니다. 데이터베이스 엔진이 버퍼 풀에 없는 페이지를 요청하면 OS 커널은 스토리지 컨트롤러에 물리적 I/O 명령을 실행하기 전에 자체 페이지 캐시를 확인합니다.
이 세 번째 계층은 애플리케이션 개발자에게는 거의 보이지 않지만 데이터베이스 버퍼 풀이 과소 프로비저닝되는 시스템에서는 매우 중요합니다. OS 페이지 캐시는 모든 프로세스에서 공유되므로 애플리케이션 서버, 웹 서버 및 동일한 호스트에서 실행되는 기타 소프트웨어와 경쟁합니다. 전용 데이터베이스 서버에서는 이러한 경쟁이 최소화되며 OS 캐시는 의미 있는 두 번째 버퍼를 제공합니다. 메모리 제한이 엄격한 공유 호스트나 컨테이너에서는 OS 캐시가 너무 작아 도움이 되지 않는 경우가 많습니다.
실제로 가장 많은 성능 승리를 담당하는 캐시 계층은 무엇입니까?
실제 생산 시스템에서는 버퍼 풀 도미
Build Your Business OS Today
From freelancers to agencies, Mewayz powers 138,000+ businesses with 207 integrated modules. Start free, upgrade when you grow.
Create Free Account →Related Posts
비슷한 기사 더 보기
주간 비즈니스 팁 및 제품 업데이트. 영원히 무료입니다.
구독 중입니다!
관련 기사
Hacker News
Big Diaper가 미국 부모로부터 수십억 달러의 추가 달러를 흡수하는 방법
Mar 8, 2026
Hacker News
새로운 애플이 등장하기 시작하다
Mar 8, 2026
Hacker News
Claude는 ChatGPT 이탈에 대처하기 위해 고군분투합니다.
Mar 8, 2026
Hacker News
AGI와 타임라인의 변화하는 골대
Mar 8, 2026
Hacker News
내 홈랩 설정
Mar 8, 2026
Hacker News
HN 표시: Skir – 프로토콜 버퍼와 비슷하지만 더 좋음
Mar 8, 2026
행동할 준비가 되셨나요?
오늘 Mewayz 무료 체험 시작
올인원 비즈니스 플랫폼. 신용카드 불필요.
무료로 시작하세요 →14일 무료 체험 · 신용카드 없음 · 언제든지 취소 가능