모든 소스에서 데이터를 요청할 때 항상 약간의 지연이 있습니다. 웹 서버에 대한 Ping은 밀리초 단위로 측정되며 스토리지 액세스 시간은 마이크로초 단위의 지연 시간을 가질 수 있는 반면 RAM 지연 시간은 CPU 클럭 주기로 측정됩니다. 물론 이러한 종류의 속도는 불과 수십 년 전만 해도 상상할 수 없었을 것이지만 현재는 결코 빠르지 않습니다. 액세스 속도는 정기적으로 일종의 성능 병목 현상입니다. 이 문제를 해결할 수 있는 방법 중 하나는 캐싱을 사용하는 것입니다.
캐싱은 평소보다 빠르게 액세스할 수 있는 방식으로 리소스의 임시 복사본을 저장하는 프로세스입니다. 소프트웨어와 하드웨어 모두에서 광범위한 구현이 있습니다. 캐시는 읽기 캐시, 쓰기 캐시 또는 둘 다의 역할을 할 수 있습니다.
캐시 읽기
읽기 캐시에서 이전에 요청된 데이터는 더 빠른 액세스를 위해 캐시에 저장됩니다. 일부 시나리오에서는 캐시에 데이터가 미리 로드되어 첫 번째 요청이 후속 요청이 아니라 캐시에서 제공될 수도 있습니다.
가장 친숙한 읽기 캐시는 브라우저 캐시입니다. 여기에서 브라우저는 요청된 리소스의 로컬 복사본을 저장합니다. 즉, 웹 페이지가 다시 로드되거나 동일한 콘텐츠를 많이 사용하는 유사한 페이지가 로드되는 경우 해당 콘텐츠는 웹 서버가 아닌 캐시에서 제공될 수 있습니다. 이는 웹 페이지가 더 빨리 로드될 수 있음을 의미할 뿐만 아니라 웹의 로드를 줄여줍니다. 측정된 데이터에서 중요할 수 있는 사용자가 다운로드해야 하는 데이터의 양을 줄입니다. 사이.
RAM 자체는 또한 하드 드라이브의 데이터에 대한 읽기 캐시 역할을 합니다. 이 경우 CPU가 더 빨리 접근할 수 있도록 실행 중인 프로그램에 대한 데이터를 RAM에 선제적으로 로드합니다. RAM의 데이터는 CPU 캐시에 추가로 캐시되지만 CPU 캐시가 기가바이트가 아닌 메가바이트 단위로 측정되기 때문에 프로세스가 훨씬 더 복잡합니다.
쓰기 캐시
쓰기 캐시는 느린 장치에 기록되는 데이터를 흡수할 수 있는 캐시입니다. 이에 대한 일반적인 예는 최신 SSD의 SLC 캐시입니다. 이 캐시는 데이터를 더 빨리 읽을 수 없도록 합니다. 그러나 SSD의 나머지 부분을 구성하는 TLC 또는 QLC 플래시에 쓰는 것보다 쓰는 것이 훨씬 빠릅니다. SLC 캐시는 고속 쓰기 작업을 흡수한 다음 가능한 한 빨리 해당 데이터를 TLC 플래시로 오프로드하여 훨씬 더 나은 스토리지 밀도를 제공하지만 쓰기 속도가 훨씬 느립니다. 이러한 방식으로 플래시 메모리를 사용하면 빠른 쓰기 속도와 높은 저장 밀도 모두에 최적화됩니다.
하이브리드 캐시
캐시가 읽기 및 쓰기 캐시로 작동하도록 허용할 수 있는 캐시를 처리하는 방법에는 여러 가지가 있습니다. 이러한 각 방법은 쓰기 작업을 다르게 처리하며 장점과 단점이 있습니다. 세 가지 옵션은 write-around, write-through 및 write-back입니다. write-around 캐시는 쓸 때 캐시를 완전히 건너뛰고, write-through 캐시는 캐시에 쓰지만 스토리지에 쓰여졌을 때만 작업이 완료된 것으로 간주합니다. 후기입 캐시는 캐시에 쓴 다음 필요한 경우 캐시에 의존하여 작업이 완료된 것으로 간주합니다.
write-around는 캐시 변동을 최소화하므로 많은 양의 쓰기가 예상되는 경우 유용할 수 있습니다. 그러나 이는 기록된 데이터를 읽는 작업이 처음으로 적어도 하나의 캐시 누락에 직면하게 됨을 의미합니다. 연속 기입 캐시는 쓰기 작업을 즉시 캐시하므로 처음 요청될 때 캐시에서 결과를 제공할 수 있습니다. 그러나 완전한 것으로 간주되기 위해서는 쓰기 작업이 데이터를 디스크에 써야 하므로 대기 시간이 추가됩니다. 후기입 캐시는 연속 기입과 동일한 이점이 있어 작성된 데이터를 캐시에서 즉시 제공할 수 있습니다. 그러나 완전한 것으로 간주되기 위해 디스크에 쓰기 위해 쓰기 작업이 필요하지는 않습니다. 이렇게 하면 쓰기 대기 시간이 줄어들지만 캐시가 휘발성이고 전원이 끊기기 전에 스토리지에 데이터 쓰기를 완료하지 않으면 데이터 손실 위험이 따릅니다.
캐시에서 데이터를 제거하는 방법은 무엇입니까?
모든 캐시의 제한 요소 중 하나는 용량입니다. 큰 캐시는 검색하는 데 오랜 시간이 걸리므로 애초에 캐시를 사용하는 이점의 상당 부분을 무효화합니다. 캐싱에 사용되는 메모리 기술은 또한 캐싱하는 메모리보다 더 비싼 경향이 있습니다. 그렇지 않은 경우 해당 메모리 계층이 성능 향상을 위해 메모리 기술을 전환했을 가능성이 큽니다. 이 두 가지 요인 모두 캐시가 상대적으로 작은 경향이 있음을 의미합니다. 특히 캐시가 저장되는 저장 매체와 비교할 때 더욱 그렇습니다. RAM은 스토리지보다 용량이 적고 CPU 캐시는 RAM보다 용량이 적습니다. SLC 캐시는 TLC 메모리보다 용량이 적습니다.
이 모든 것은 캐시해야 하는 새 데이터를 위한 공간을 확보하기 위해 캐시에서 데이터를 순환해야 하는 경우가 많다는 것을 의미합니다. 이에 대한 다양한 접근 방식이 있습니다. "가장 적게 사용됨"은 액세스 수가 가장 적은 캐시 항목을 제거하는 것을 선호합니다. 이것은 미래의 캐시 미스에 가장 적은 영향을 미칠 항목을 예측하는 데 유용할 수 있지만 또한 매우 최근에 추가된 항목을 액세스 수가 적은 것으로 간주하여 캐시로 이어질 수 있습니다. 휘젓다.
"최근 사용"은 한동안 사용되지 않은 캐시 항목을 제거하는 것을 선호합니다. 이것은 현재 사용되지 않는다고 가정하지만 얼마 전에 많이 사용되었는지는 고려하지 않습니다. "가장 최근에 사용됨"은 가장 최근에 사용된 캐시 항목을 제거하는 것을 선호하며 사용되었으며 다시 사용할 필요가 없습니다. 가장 좋은 방법은 일반적으로 사용 통계에 따라 세 가지를 모두 조합하는 것입니다.
오래된 정보 및 보안 위험
캐시의 주요 위험은 캐시에 포함된 정보가 오래될 수 있다는 것입니다. 원래 데이터가 업데이트되어 캐시 항목이 최신 상태가 아닌 경우 캐시 항목은 오래된 것으로 간주됩니다. 제공되는 라이브 사본이 여전히 캐시된 사본과 일치하는지 정기적으로 확인하는 것이 중요합니다.
특히 웹 사이트에서는 캐시할 수 있는 데이터와 캐시할 수 없는 데이터를 식별하는 것도 매우 중요합니다. 예를 들어, 변경되지 않는 큰 JavaScript 파일을 캐시하는 것은 완벽합니다. 이렇게 하면 사용자가 매번 다운로드하지 않아도 되며 동일한 캐시가 제공하는 다른 사용자에게도 도움이 될 수 있습니다. 그러나 세션별 데이터를 캐시할 수는 없습니다. 자신으로 로그인한 상태에서 메시징 앱을 탐색했는데 다른 사용자의 메시지가 캐시된 버전으로 제공되었다는 사실을 알게 된다면 어떤 일이 벌어질지 상상해 보십시오. 고맙게도 웹 서버는 캐시할 수 있는 리소스와 캐시할 수 없는 리소스를 지정할 수 있으며 이러한 문제는 일반적으로 잘 알려져 있으므로 이와 같은 문제가 거의 없습니다.
결론
캐시는 일반적인 데이터 액세스 프로세스를 다시 완료하는 것보다 액세스가 더 빠른 저장 방법으로 최근에 사용한 데이터를 저장할 수 있는 메모리의 일부입니다. 캐시는 일반적으로 용량이 제한되어 있으므로 가득 차면 항목을 제거해야 합니다. 캐시는 일반적으로 사용자에게 투명합니다. 즉, 지연 시간은 결과가 캐시를 통해 제공되었다는 유일한 표시입니다.