캐시(컴퓨팅)

Cache (computing)
CPU 메모리 캐시 작업 다이어그램

컴퓨팅에서 캐시(/ké//(listen) KASH)[1]는 데이터를 저장하는 하드웨어 또는 소프트웨어 컴포넌트입니다.캐시에 저장된 데이터는 이전에 계산한 결과이거나 다른 곳에 저장된 데이터의 복사본일 수 있습니다.캐시 적중은 요청된 데이터를 캐시에서 찾을 수 있을 때 발생하는 반면 캐시 누락은 캐시에서 찾을 수 없을 때 발생합니다.캐시 히트는 캐시에서 데이터를 읽음으로써 처리됩니다.이것은 결과를 재계산하거나 느린 데이터 저장소에서 읽는 것보다 빠릅니다.따라서 캐시에서 처리할 수 있는 요청이 많을수록 시스템의 [2]실행 속도가 빨라집니다.

비용 효율이 높고 데이터를 효율적으로 사용하려면 캐시가 상대적으로 작아야 합니다.그럼에도 불구하고 캐시는 컴퓨팅의 많은 분야에서 입증되었습니다. 왜냐하면 일반적인 컴퓨터 애플리케이션은 높은 참조 지역성으로 데이터에 액세스하기 때문입니다.이러한 액세스 패턴에는, 최근 요구되고 있는 데이터가 요구되고 있는 시간적 로컬리티와 요구되고 있는 데이터에 물리적으로 가까운 데이터가 요구되고 있는 공간적 로컬리티가 있습니다.

동기

크기와 속도 사이에는 고유의 트레이드오프(리소스가 클수록 물리적 거리가 넓어짐)가 있을 뿐만 아니라 고가의 프리미엄 테크놀로지(SRAM 등)와 저렴하고 쉽게 대량생산할 수 있는 상품(D램이나 하드디스크 등)의 트레이드오프도 있습니다.

캐시에 의해 제공되는 버퍼링은 지연과 throughput(대역폭) 중 하나 또는 둘 다에 도움이 됩니다.

레이텐시

리소스가 클수록 액세스 지연이 커집니다.예를 들어 최신 4GHz 프로세서가 DRAM에 도달하려면 수백 개의 클럭 사이클이 필요할 수 있습니다.이것은 다음 번 읽기가 인근 위치에서 이루어지기를 바라면서 큰 덩어리로 읽음으로써 완화됩니다.예측 또는 명시적 프리페치에서는 향후 읽기의 출처를 추측하고 사전에 요청을 할 수도 있습니다.정확하게 하면 지연 시간은 완전히 바이패스됩니다.

스루풋

또한 캐시를 사용하면 여러 미세 입자 전송을 더 크고 효율적인 요청으로 조립하여 기본 리소스로부터의 throughput을 높일 수 있습니다.DRAM 회선의 경우는, 보다 넓은 데이터 버스를 가지는 것으로, 이것을 실현할 수 있습니다.예를 들어 32비트 주소 공간에서 바이트에 액세스하지만 128비트 오프칩 데이터 버스에 의해 처리되는 프로그램을 생각해 보겠습니다.캐시되지 않은 개별 바이트 액세스에서는 총 대역폭의 1/16만 사용할 수 있으며 데이터 이동의 80%는 데이터 자체 대신 메모리 주소입니다.큰 청크를 읽으면 주소 정보 전송에 필요한 대역폭이 줄어듭니다.

조작

하드웨어는 다시 사용될 가능성이 있는 데이터의 임시 저장을 위한 메모리 블록으로 캐시를 구현합니다.중앙 처리 장치(CPU)와 하드 디스크 드라이브(HDD)는 하드웨어 기반 캐시를 자주 사용하는 반면 웹 브라우저와 웹 서버는 일반적으로 소프트웨어 캐시에 의존합니다.

캐시는 엔트리 풀로 구성됩니다.각 항목에는 연결된 데이터가 있으며, 이는 일부 백업 저장소에 있는 동일한 데이터의 복사본입니다.각 엔트리에는 엔트리가 복사된 백업스토어 내의 데이터 ID를 지정하는 태그도 있습니다.태그 부착을 통해 동시 캐시 지향 알고리즘을 차등 릴레이 간섭 없이 다층 방식으로 작동할 수 있습니다.

캐시 클라이언트(CPU, 웹 브라우저, 운영 체제)가 백업 저장소에 있는 것으로 추정되는 데이터에 액세스해야 할 경우 먼저 캐시를 확인합니다.원하는 데이터의 태그와 일치하는 엔트리를 찾을 수 있으면 엔트리의 데이터가 대신 사용됩니다.이 상황을 캐시 히트라고 합니다.예를 들어 웹 브라우저 프로그램은 디스크 상의 로컬캐시를 체크하여 특정 URL에 웹 페이지 내용의 로컬복사가 있는지 확인합니다.이 예에서는 URL이 태그이고 웹 페이지 내용이 데이터입니다.캐시 적중률이 되는 액세스의 비율을 캐시의 적중률 또는 적중률이라고 합니다.

캐시가 체크되어 원하는 태그를 가진 엔트리가 포함되지 않은 것을 발견한 대체 상황을 캐시 미스라고 합니다.이를 위해서는 백업 스토어에서 더 많은 비용을 들여 데이터에 액세스해야 합니다.요청된 데이터는 일반적으로 캐시에 복사되어 다음 액세스를 위해 준비됩니다.

캐시 누락 시 새로 검색된 데이터를 저장할 공간을 확보하기 위해 이전에 존재했던 캐시 엔트리가 제거됩니다.교체할 항목을 선택하는 데 사용되는 경험적 접근 방식을 교체 정책이라고 합니다.일반적인 대체 정책 중 하나인 "최신 사용 안 함"(LRU)은 가장 오래된 엔트리, 즉 다른 엔트리보다 최근에 액세스한 엔트리를 대체합니다(캐시 알고리즘 참조).보다 효율적인 캐싱 알고리즘은 캐시와 백업 저장소 모두의 지연 시간과 스루풋뿐만 아니라 저장된 콘텐츠의 크기에 대한 사용 적중 빈도를 계산합니다.이는 하드 드라이브 및 네트워크와 같은 대량의 데이터, 긴 지연 시간, 느린 스루풋에 적합하지만 CPU [citation needed]캐시 내에서 사용하는 데는 효율적이지 않습니다.

정책 쓰기

주요 기사:캐시 일관성
쓰기 없는 할당이 가능한 라이트 스루 캐시
쓰기 할당이 있는 라이트백 캐시

시스템은 캐시에 데이터를 쓸 때 어느 시점에서도 해당 데이터를 백업 저장소에 써야 합니다.이 기입의 타이밍은, 기입 정책이라고 불리는 것에 의해서 제어됩니다.다음 두 가지 기본적인 [3]쓰기 방법이 있습니다.

  • Write-through :캐시 및 백업스토어 양쪽에서 동시에 쓰기가 이루어집니다.
  • 라이트백(라이트백이라고도 함): 처음에는 캐시에만 쓰기가 수행됩니다.변경된 내용이 다른 캐시 블록으로 대체될 때까지 백업 저장소에 쓰기가 연기됩니다.

라이트백 캐시는, 어느 로케이션에 기입이 끝난지를 추적해, 나중에 백업 스토어에 쓸 수 있도록 더티라고 마크 할 필요가 있기 때문에, 실장이 보다 복잡합니다.이러한 위치에 있는 데이터는 캐시에서 제거된 경우에만 백업 저장소에 다시 쓰입니다. 이를 느린 쓰기라고 합니다.이러한 이유로 라이트백 캐시의 읽기 오류(블록을 다른 블록으로 대체해야 함)는 대개 2개의 메모리 액세스를 필요로 합니다. 하나는 캐시에서 교체된 데이터를 저장소로 다시 쓰고 다른 하나는 필요한 데이터를 가져옵니다.

다른 정책에서도 데이터 쓰기가 트리거될 수 있습니다.클라이언트는 캐시 내의 데이터를 여러 번 변경한 후 데이터를 다시 쓰도록 캐시에 명시적으로 알릴 수 있습니다.

쓰기 작업 시 요청자에게 데이터가 반환되지 않으므로 데이터가 캐시에 로드되는지 여부에 따라 쓰기 오류를 결정해야 합니다.이는 다음 두 가지 접근법에 의해 정의됩니다.

  • 쓰기 할당(쓰기 시 가져오기라고도 함): 쓰기 누락 위치의 데이터가 캐시에 로드된 후 쓰기 적중 작업이 수행됩니다.이 접근법에서 쓰기 오류는 읽기 오류와 유사합니다.
  • 쓰기 없음 할당(write-no-allocate 또는 write arround라고도 함): 쓰기 누락 위치의 데이터는 캐시에 로드되지 않고 백업 저장소에 직접 기록됩니다.이 접근 방식에서는 읽기 누락 시에만 데이터가 캐시에 로드됩니다.

라이트 스루 정책과 라이트백 정책 모두 다음 쓰기 오류 정책 중 하나를 사용할 수 있지만 일반적으로 이러한 방식으로 [4]쌍을 이룹니다.

  • 라이트백 캐시는 쓰기 할당을 사용하여 동일한 위치에 대한 후속 쓰기(또는 읽기)를 기대합니다. 이 경우 현재 캐시됩니다.
  • 라이트 스루 캐시는 쓰기 없는 할당을 사용합니다.여기서 후속 쓰기는 여전히 백업 저장소에 직접 작성해야 하므로 아무런 이점이 없습니다.

캐시 이외의 엔티티는 백업스토어의 데이터를 변경할 수 있습니다.이 경우 캐시 내의 복사가 오래된 것이 되거나 오래된 것이 될 수 있습니다.또는 클라이언트가 캐시의 데이터를 업데이트하면 다른 캐시에 있는 데이터의 복사본이 오래됩니다.데이터를 일관되게 유지하는 캐시 관리자 간의 통신 프로토콜을 일관성 프로토콜이라고 합니다.

프리페치

주요 기사:캐시 프리페치
주요 기사:메모리 페이징 » 페이지 치환 기술

캐시 읽기 누락 시 요구 페이징 정책을 사용하여 캐시가 백업 저장소에서 최소 용량을 읽습니다.예를 들어 요구 페이징 가상 메모리는 디스크에서 RAM의 디스크 캐시로 가상 메모리(대개 4KB)의 한 페이지를 읽습니다.예를 들어 일반적인 CPU는 128바이트의 단일 L2 캐시 행을 DRAM에서 L2 캐시로, 64바이트의 단일 L1 캐시 행을 L2 캐시에서 L1 캐시로 읽습니다.

프리페치 입력 큐 또는 보다 일반적인 예상 페이징 정책을 사용하는 캐시는 더 나아가 요청된 청크를 읽을 뿐만 아니라 다음 청크가 곧 필요할 것으로 예상되므로 데이터를 미리 캐시에 프리페치합니다.백업 저장소에서 첫 번째 청크를 읽기 위한 지연 시간이 길고 디스크 스토리지 및 DRAM과 같은 다음 몇 개의 청크를 순차적으로 읽기 위한 시간이 훨씬 짧은 경우 사전 페이징이 특히 유용합니다.

일부 운영체제는 실행파일 전체를 항상 RAM에 프리로드하는 로더로 한 단계 더 나아갑니다.

몇 개의 캐시는 더 나아가 파일 전체를 프리로드할 뿐만 아니라 프리페처와 관련된 페이지 캐시나 링크 프리페치와 관련된 웹 캐시 등 곧 요구될 수 있는 다른 관련 파일도 로드하기 시작합니다.

하드웨어 캐시 예시

CPU 캐시

주요 문서: CPU 캐시

CPU에 탑재되어 있거나 CPU 근처에 있는 작은 메모리는 큰 메인 메모리보다 더 빠르게 동작할 수 있습니다.1980년대 이후 대부분의 CPU는 1개 이상의 캐시를 사용했으며 때로는 캐스케이드 레벨로 사용되기도 했습니다. 현대의 하이엔드 임베디드, 데스크톱 및 서버 마이크로프로세서는 최대 6종류의 캐시를 가지고 있을 수 있습니다(레벨과 [5]기능 사이).특정 기능을 가진 캐시의 예로는 D-cache 및 I-cache 및 MMU 변환 룩사이드버퍼가 있습니다

GPU 캐시

이전의 그래픽 처리 장치(GPU)는 읽기 전용 텍스처 캐시가 제한적인 경우가 많았으며, 2D 캐시 일관성을 향상시키기 위해 Morton 오더 스위즐드 텍스처를 도입했습니다.예를 들어 mipmapping을 사용하지 않는 경우 캐시 누락은 성능에 큰 영향을 미칩니다.캐싱은 종종 픽셀당 4비트에 불과한 텍스처 데이터를 위해 32비트(및 더 넓은) 전송을 활용하기 위해 중요했습니다. 텍스처 데이터는 임의의 UV 좌표 및 역 텍스처 매핑의 투시 변환에 의해 복잡한 패턴으로 인덱싱됩니다.

GPU가 발전함에 따라(특히 GPGPU 컴퓨팅 셰이더 사용), 셰이더용 명령 캐시를 포함하여 점점 더 크고 일반적인 캐시가 개발되어 CPU 캐시와 관련된 일반적인 기능이 점점 더 많아지고 있습니다.예를 들어 GT200 아키텍처 GPU에는 L2 캐시가 없는 반면 Fermi GPU에는 768KB의 마지막 수준 캐시가 있고 Kepler GPU에는 1536KB의 마지막 수준 캐시가 있으며 Maxwell GPU에는 2048KB의 마지막 수준 캐시가 있습니다.이러한 캐시는 스레드와 원자 동작 간의 동기화 프리미티브를 처리하고 CPU 스타일의 MMU와의 인터페이스로 확장되었습니다.

DSP

디지털 신호 프로세서도 수년간 이와 유사하게 일반화되어 왔습니다.이전 설계에서는 DMA에서 제공하는 스크래치패드 메모리를 사용했지만 Qualcomm Hexagon과 같은 최신 DSP에는 CPU와 매우 유사한 캐시 세트가 포함되어 있는 경우가 많습니다(예: 공유 L2, 분할 L1 I-캐시 [6]및 D-캐시를 사용한 하버드 아키텍처 수정).

번역 룩사이드 버퍼

주요 기사:번역 룩사이드 버퍼

메인 메모리로부터 페이지 테이블 엔트리를 가져오는 메모리 관리 유닛(MMU)은, 가상 주소로부터 물리 주소 변환의 결과를 기록하기 위해서 사용되는 전용 캐시를 가진다.이 전용 캐시는 Translation Lookaside Buffer(TLB;[7] 변환 룩사이드버퍼)라고 불립니다.

네트워크 내 캐시

정보 중심의 네트워킹

정보중심 네트워킹(ICN)은 인터넷 인프라스트럭처를 항구적인 접속과 엔드 투 엔드 원칙에 기초한 호스트 중심 패러다임에서 벗어나 정보(또는 콘텐츠 또는 데이터)를 식별하는 네트워크 아키텍처로 발전시키는 접근법입니다.ICN에는 노드의 캐싱 기능이 내재되어 있기 때문에 캐싱 정책의 고유한 요건이 있는 느슨하게 연결된 캐시 네트워크로 간주될 수 있습니다.그러나 유비쿼터스 콘텐츠 캐싱은 무단 액세스에 대한 콘텐츠 보호에 대한 과제를 야기하며, 이에 대한 각별한 주의와 [8]솔루션이 필요합니다.프록시 서버와 달리 ICN에서는 캐시는 네트워크 수준의 솔루션입니다.따라서 캐시 상태가 빠르게 변화하고 요청 도착률이 높아집니다. 또한 캐시 크기가 작을수록 콘텐츠 삭제 정책에 대한 요구 사항이 더욱 다양해집니다.특히 ICN에 대한 퇴출 정책은 빠르고 가벼워야 한다.다양한 ICN 아키텍처 및 애플리케이션에 대한 다양한 캐시 복제 및 제거 방식이 제안되었습니다.

정책들

가장 최근에 사용한 시간 인식(TLRU)

Time aware Lest Recently Used(TLRU;[9] 시간 인식 최소 최근 사용)는 캐시에 저장된 컨텐츠의 유효 수명이 있는 상황을 위해 설계된 LRU의 변형입니다.이 알고리즘은 Information-Centric Networking(ICN; 정보중심 네트워킹), Content Delivery Network(CDN; 콘텐츠 전송 네트워크), 분산 네트워크 등의 네트워크 캐시 애플리케이션에 적합합니다.TLRU에는 TTU(Time to Use)라는 새로운 용어가 도입되었습니다.TTU는 콘텐츠/페이지의 타임스탬프로서 콘텐츠의 지역성과 콘텐츠 퍼블리셔 공지사항을 바탕으로 콘텐츠의 사용가능시간을 규정합니다.이 로컬 기반 타임스탬프 때문에 TTU는 로컬 관리자에게 네트워크 스토리지를 규제할 수 있는 더 많은 제어 기능을 제공합니다.TLRU 알고리즘에서는, 컨텐츠가 착신하면, 캐시 노드는 컨텐츠 퍼블리셔에 의해서 할당된 TTU 값에 근거해 로컬 TTU 값을 계산합니다.로컬 TTU 값은 로컬로 정의된 함수를 사용하여 계산됩니다.로컬 TTU 값이 계산되면 캐시 노드에 저장된 전체 콘텐츠의 서브셋에서 콘텐츠 치환이 수행됩니다.TLRU를 사용하면 인기가 적고 수명이 짧은 콘텐츠를 수신 콘텐츠로 대체할 수 있습니다.

최근 사용 빈도가 가장 낮은(LFRU)

Lefrequency Recently Used(LFRU)[10] 캐시 교환 방식은 LFU 및 LRU 방식의 이점을 결합합니다.LFRU는 정보중심 네트워킹(ICN), 콘텐츠 전송 네트워크(CDN), 분산 네트워크 등의 '네트워크 내' 캐시 애플리케이션에 적합합니다.LFRU에서는 캐시는 특권 파티션과 비특권 파티션이라는2개의 파티션으로 분할됩니다.특권 파티션은 보호된 파티션으로 정의할 수 있습니다.컨텐츠가 널리 사용되는 경우, 컨텐츠는 특권 파티션에 푸시됩니다.특권 파티션의 치환은 다음과 같이 이루어집니다.LFRU는 특권 파티션에서 콘텐츠를 제거하고 특권 파티션에서 특권 파티션으로 콘텐츠를 푸시한 후 마지막으로 새로운 콘텐츠를 특권 파티션에 삽입합니다.위의 절차에서는 특권 파티션에 LRU를 사용하고 특권 파티션에 근사 LFU(ALFU) 스킴을 사용합니다.따라서 LFRU는 생략형입니다.ALFU 방식으로 현지에서 인기 있는 콘텐츠를 걸러내고, 인기 콘텐츠를 특권 파티션 중 하나에 푸시하는 것이 기본 구상이다.

일기 예보

지난 2010년 뉴욕타임즈는 "날씨 뒤에 우편번호를 [11]입력하라"고 제안했다.2011년까지 일기예보 옵션을 갖춘 스마트폰 사용은 AccuWeather 서버에 과도한 부담을 주고 있었습니다.같은 파크 내에서 두 가지 요청을 하면 별도의 요청이 발생합니다.GPS 좌표를 소수점 이하 자리로 잘라내기 위해 에지 서버에 의한 최적화는 이전 쿼리의 캐시된 결과가 사용됨을 의미합니다.1일당 서버 검색 수가 [12]절반으로 감소했습니다.

소프트웨어 캐시

디스크 캐시

주요 기사: 페이지 캐시

CPU 캐시는 일반적으로 하드웨어에 의해 완전히 관리되지만 다양한 소프트웨어가 다른 캐시를 관리합니다.디스크 캐시의 일례인 메인 메모리의 페이지 캐시는 운영 체제 커널에 의해 관리됩니다.

하드 디스크 드라이브의 일부인 디스크 버퍼는 "디스크 캐시"라고 잘못 불리기도 하지만, 주요 기능은 쓰기 순서 지정과 읽기 프리페치입니다.드라이브의 용량에 비해 버퍼의 크기가 작기 때문에 캐시 적중 횟수가 반복되는 경우는 비교적 드뭅니다.그러나 하이엔드 디스크 컨트롤러에는 하드 디스크 드라이브의 데이터 블록에 대한 자체 온보드 캐시가 있는 경우가 많습니다.

마지막으로 고속 로컬 하드 디스크 드라이브는 리모트 서버(웹 캐시), 로컬 테이프 드라이브 또는 광학 주크박스 등 속도가 느린 데이터 스토리지 디바이스에 저장된 정보를 캐시할 수도 있습니다.이러한 스킴은 계층형 스토리지 관리의 주요 개념입니다.또한 고속 플래시 기반 솔리드 스테이트 드라이브(SSD)는 하이브리드 드라이브 또는 솔리드 스테이트 하이브리드 드라이브(SSHD)로 함께 작동하면서 느린 회전 미디어 하드 디스크 드라이브의 캐시로 사용할 수 있습니다.

웹 캐시

주요 기사:웹 캐시

웹 브라우저 및 웹 프록시 서버는 웹 페이지 및 이미지 등의 웹 서버로부터의 이전 응답을 저장하기 위해 웹 캐시를 사용합니다.웹 캐시는 이전에 캐시에 저장된 정보를 재사용할 수 있기 때문에 네트워크를 통해 전송해야 하는 정보의 양을 줄입니다.이것에 의해, Web 서버의 대역폭과 처리 요건이 경감되어 Web [13]유저의 응답성이 향상됩니다.

웹 브라우저는 내장 웹 캐시를 사용하지만 일부 Internet Service Provider(ISP; 인터넷서비스 공급자) 또는 조직에서는 캐싱 프록시 서버도 사용합니다.이 프록시 서버는 해당 네트워크의 모든 사용자가 공유하는 웹 캐시입니다.

캐시의 또 다른 형태는 P2P 캐싱입니다.P2P 캐싱에서는 P2P 전송을 고속화하기 위해 피어투피어 애플리케이션에서 가장 많이 요구하는 파일이 ISP 캐시에 저장됩니다.마찬가지로 분산형 등가물이 존재하며 이를 통해 커뮤니티는 Corelli [14]등 P2P 트래픽에 대해 동일한 작업을 수행할 수 있습니다.

메모화

주요 기사:메모화

캐시는 백업 저장소에서 검색하는 것이 아니라 필요에 따라 계산된 데이터를 저장할 수 있습니다.메모화는 리소스를 많이 사용하는 함수 호출 결과를 룩업테이블 내에 저장하는 최적화 기법입니다.이것에 의해, 이후의 콜은 보존된 결과를 재사용할 수 있어 계산의 반복을 회피할 수 있습니다.이것은 동적 프로그래밍 알고리즘 설계 방법과 관련이 있으며, 캐싱의 수단으로 생각할 수도 있습니다.

콘텐츠 전송 네트워크

주요 기사:콘텐츠 전송 네트워크

CDN(Content Delivery Network)은 사용자의 지리적 위치, 웹 페이지 원본 및 콘텐츠 전송 서버를 기반으로 페이지 및 기타 웹 콘텐츠를 사용자에게 전달하는 분산 서버의 네트워크입니다.

CDN은 HTML 페이지, 이미지 및 비디오와 같은 정적 콘텐츠의 전송 속도를 높이기 위한 방법으로 1990년대 후반에 시작되었습니다.CDN은 전 세계 여러 서버에서 콘텐츠를 복제하여 위치에 따라 사용자에게 전달함으로써 웹 사이트 또는 애플리케이션의 속도와 가용성을 크게 향상시킬 수 있습니다.사용자가 콘텐츠를 요청하면 CDN은 해당 콘텐츠의 복사본이 캐시에 있는지 확인합니다.이 경우 CDN은 [15]캐시에서 사용자에게 콘텐츠를 전달합니다.

클라우드 스토리지 게이트웨이

주요 기사:클라우드 스토리지 게이트웨이

엣지 파일러라고도 하는 클라우드 스토리지 게이트웨이는 로컬 네트워크를 하나 이상의 클라우드 스토리지 서비스(일반적으로 Amazon S3와 같은 개체 스토리지 서비스)에 연결하는 하이브리드 클라우드 스토리지 디바이스입니다.자주 액세스하는 데이터에 대한 캐시를 제공하여 클라우드 스토리지 서비스의 자주 액세스하는 데이터에 대한 빠른 로컬 액세스를 제공합니다.또한 클라우드 스토리지 게이트웨이는 기존 파일 서비스 프로토콜을 통해 클라우드 객체 스토리지에 액세스할 수 있을 뿐만 아니라 연결 [16]중단 중에도 캐시된 데이터에 계속 액세스할 수 있는 등의 추가적인 이점을 제공합니다.

기타 캐시

BIND DNS 데몬은 리졸바 라이브러리와 마찬가지로 도메인 이름과 IP 주소의 매핑을 캐시합니다.

통신이 불안정할 때 여러 라이트백 캐시 간에 필요한 일관성 프로토콜이 매우 복잡하기 때문에 이더넷 LAN과 같은 신뢰할 수 없는 네트워크를 통해 작동하는 경우 쓰기 작업이 일반적입니다.예를 들어 웹 페이지 캐시 및 클라이언트 측 네트워크 파일 시스템 캐시(NFS 또는 SMB의 캐시와 같은)는 일반적으로 네트워크 프로토콜을 단순하고 안정적으로 유지하기 위해 읽기 전용 또는 쓰기 전용입니다.

또한 검색 엔진은 색인화된 웹 페이지를 캐시에서 사용할 수 있도록 하는 경우가 많습니다.예를 들어 Google은 각 검색 결과 옆에 "캐시" 링크를 제공합니다.이 기능은 웹 서버에서 웹 페이지에 일시적으로 또는 영구적으로 액세스할 수 없는 경우에 유용합니다.

데이터베이스 캐싱은 인덱스, 데이터 사전 및 자주 사용되는 데이터 하위 집합 처리와 같은 데이터베이스 애플리케이션의 처리량을 크게 향상시킬 수 있습니다.

분산[17] 캐시는 네트워크 호스트를 사용하여 애플리케이션에 [18]확장성, 신뢰성 및 성능을 제공합니다.호스트는, 같은 장소에 배치하거나, 다른 지역에 분산할 수 있습니다.

버퍼 대 캐시

"buffer"와 "cache"의 의미는 완전히 다르지 않습니다.그렇다고 해도 캐싱 프로세스와 버퍼링 프로세스 사이에는 근본적인 의도에 차이가 있습니다.

기본적으로 캐싱은 반복적으로 전송되는 데이터 전송에 대한 성능 향상을 실현합니다.캐싱 시스템은 데이터 항목의 초기(일반적으로 쓰기) 전송 시 성능 향상을 실현할 수 있지만, 이러한 성능 증가는 캐싱 시스템 내에서 버퍼링이 발생하기 때문입니다.

읽기 캐시를 사용하는 경우 데이터 항목의 후속 읽기가 데이터의 상주 위치가 아닌 캐시의 (더 빠른) 중간 스토리지에서 가져올 수 있기 때문에 성능 향상을 실현하려면 데이터 항목을 상주 위치에서 한 번 이상 가져와야 합니다.쓰기 캐시를 사용하면 데이터 항목이 캐시의 중간 스토리지에 즉시 저장되고, 데이터 항목이 나중에 존재하는 스토리지로 전송되는 것을 지연시키거나 백그라운드 프로세스로 발생하는 것에 의해 데이터 항목의 첫 번째 쓰기 시에 데이터 항목의 쓰기 성능 향상을 실현할 수 있다.엄격한 버퍼링과 달리 캐싱 프로세스는 캐시의 중간 스토리지와 데이터가 상주하는 위치 간의 일관성을 유지하기 위해 (잠재적으로 분산된) 캐시 일관성 프로토콜을 준수해야 합니다.반면에 버퍼링은

  • 통신 프로세스 간의 새로운 데이터 전송 횟수를 줄임으로써 적은 수의 대규모 전송에 따른 여러 소규모 전송에 따른 오버헤드를 상각할 수 있습니다.
  • 서로 직접 전송할 수 없는 프로세스를 전달하기 위한 매개체를 제공합니다.
  • 는 전송에 관련된 통신 프로세스 중 적어도1개가 필요로 하는 최소한의 데이터 크기 또는 표현을 보증합니다.

일반적인 캐싱 구현에서는 처음으로 읽거나 쓰는 데이터 항목이 효과적으로 버퍼링됩니다. 쓰기의 경우 주로 쓰기가 시작된 애플리케이션보다 성능이 향상됩니다.또한 캐싱 프로토콜에서 개별 쓰기가 쓰기 배치로 지연되는 부분은 버퍼링의 한 형태입니다.캐싱 프로토콜에서 개별 읽기가 한 묶음으로 지연되는 부분도 버퍼링의 한 형태이지만, 이 형식은 적어도 초기 읽기의 성능에 부정적인 영향을 미칠 수 있습니다(개별 읽기의 합계에 긍정적인 영향을 미칠 수도 있음).실제로 캐싱은 거의 항상 어떤 형태의 버퍼링을 수반하지만 엄밀한 버퍼링은 캐싱을 수반하지 않습니다.

버퍼는 CPU 명령이 주변기기에 저장된 데이터를 직접 수신처로 지정할 수 없기 때문에 전통적으로 사용되는 임시 메모리 위치입니다.따라서, 주소 지정 가능한 메모리가 중간 단계로 사용됩니다.또, 이러한 버퍼는, 대량의 데이터 블록이 조립 또는 분해되었을 경우(기억 장치에 의해서 요구되고 있는 경우), 또는 데이터가 생성되는 순서와는 다른 순서로 전달되었을 경우에 실현될 수 있다.또, 데이터의 버퍼 전체는, 통상은 차례차례(예를 들면 하드 디스크)로 전송되기 때문에, 버퍼링 자체에 의해서, 레이텐시를 삭감하는 캐시에 비해, 전송 퍼포먼스가 향상하거나 전송 레이텐시의 변동이나 지터가 감소하는 일이 있습니다.버퍼링된 데이터를 버퍼에 한 번 쓰고 버퍼에서 한 번 읽어도 이러한 이점이 있습니다.

캐시를 사용하면 전송 성능도 향상됩니다.마찬가지로 증가의 일부는 여러 개의 작은 전송이 하나의 큰 블록으로 결합될 가능성에서 비롯됩니다.그러나 주요 성능 향상은 캐시에서 동일한 데이터를 여러 번 읽거나 기록된 데이터를 곧 읽을 가능성이 높기 때문에 발생합니다.캐시의 유일한 목적은 속도가 느린 기본 스토리지에 대한 액세스를 줄이는 것입니다.캐시는 일반적으로 인접 계층의 관점에서 보이지 않도록 설계된 추상화 계층이기도 합니다.

「 」를 참조해 주세요.

레퍼런스

  1. ^ "Cache". Oxford Dictionaries. Oxford Dictionaries. Retrieved 2 August 2016.
  2. ^ Zhong, Liang; Zheng, Xueqian; Liu, Yong; Wang, Mengting; Cao, Yang (February 2020). "Cache hit ratio maximization in device-to-device communications overlaying cellular networks". China Communications. 17 (2): 232–238. doi:10.23919/jcc.2020.02.018. ISSN 1673-5447. S2CID 212649328.
  3. ^ Bottomley, James (1 January 2004). "Understanding Caching". Linux Journal. Retrieved 1 October 2019.
  4. ^ John L. Hennessy; David A. Patterson (2011). Computer Architecture: A Quantitative Approach. Elsevier. pp. B–12. ISBN 978-0-12-383872-8.
  5. ^ L4 캐시에 대해 "Intel Broadwell Core i7 5775C '128MB L4 Cache' Gaming Behemoth and Skylake Core i7 6700K Flagship Processors Finally Available In Retail". 25 September 2015.설명합니다.개별 I-Cache 및 TLB를 조합하면 총 '캐시 수(레벨+기능)'가 6개가 됩니다.
  6. ^ "qualcom Hexagon DSP SDK overview".
  7. ^ Frank Uyeda (2009). "Lecture 7: Memory Management" (PDF). CSE 120: Principles of Operating Systems. UC San Diego. Retrieved 4 December 2013.
  8. ^ Bilal, Muhammad; et al. (2019). "Secure Distribution of Protected Content in Information-Centric Networking". IEEE Systems Journal. 14 (2): 1–12. arXiv:1907.11717. Bibcode:2020ISysJ..14.1921B. doi:10.1109/JSYST.2019.2931813. S2CID 198967720.
  9. ^ Bilal, Muhammad; et al. (2017). "Time Aware Least Recent Used (TLRU) Cache Management Policy in ICN". IEEE 16th International Conference on Advanced Communication Technology (ICACT): 528–532. arXiv:1801.00390. Bibcode:2018arXiv180100390B. doi:10.1109/ICACT.2014.6779016. ISBN 978-89-968650-3-2. S2CID 830503.
  10. ^ Bilal, Muhammad; et al. (2017). "A Cache Management Scheme for Efficient Content Eviction and Replication in Cache Networks". IEEE Access. 5: 1692–1701. arXiv:1702.04078. Bibcode:2017arXiv170204078B. doi:10.1109/ACCESS.2017.2669344. S2CID 14517299.
  11. ^ Simon Mackie (3 May 2010). "9 More Simple Google Search Tricks". New York Times.
  12. ^ Chris Murphy (30 May 2011). "5 Lines Of Code In The Cloud". InformationWeek. p. 28. 300 million to 500 million fewer requests a day handled by AccuWeather servers
  13. ^ Multiple (wiki). "Web application caching". Docforge. Archived from the original on 12 December 2019. Retrieved 24 July 2013.
  14. ^ Gareth Tyson; Andreas Mauthe; Sebastian Kaune; Mu Mu; Thomas Plagemann. Corelli: A Dynamic Replication Service for Supporting Latency-Dependent Content in Community Networks (PDF). MMCN'09. Archived from the original (PDF) on 18 June 2015.
  15. ^ "Globally Distributed Content Delivery, by J. Dilley, B. Maggs, J. Parikh, H. Prokop, R. Sitaraman and B. Weihl, IEEE Internet Computing, Volume 6, Issue 5, November 2002" (PDF). Archived (PDF) from the original on 9 August 2017. Retrieved 25 October 2019.
  16. ^ "Definition: cloud storage gateway". SearchStorage. July 2014.
  17. ^ Paul, S; Z Fei (1 February 2001). "Distributed caching with centralized control". Computer Communications. 24 (2): 256–268. CiteSeerX 10.1.1.38.1094. doi:10.1016/S0140-3664(00)00322-4.
  18. ^ Khan, Iqbal (July 2009). "Distributed Caching on the Path To Scalability". MSDN. 24 (7).

추가 정보