작은 파일로 인해 Google 파일 시스템에서 핫 스폿이 생성되는 이유는 무엇입니까?

Question

나는 작은 파일이 덩어리의 작은 숫자, 아마 한 구성되어 Google File Systems Paper

에서이 문제를 이해하지 않습니다. 이러한 청크를 저장하는 chunkserver는 많은 클라이언트 이 동일한 파일에 액세스하는 경우 핫 스폿이 될 수 있습니다.

작은 파일로는 어떤 차이가 있습니까? 많은 클라이언트가 액세스하는 대용량 파일이 문제를 일으킬 가능성이 있습니까?

나는/다음을 읽고 생각했습니다 : -

• 나는 큰 파일의 덩어리가되어 부하를 분산 다른 chunkservers에 저장되어있는 것을 (내가 틀렸다면 정정 해줘) 가정합니다. 이러한 시나리오에서는 1000 개의 클라이언트가 각 chunkserver에서 파일의 1/100에 액세스한다고합니다. 따라서 각 chunkserver는 필연적으로 1000 개의 요청을 받게됩니다. (1000 개의 클라이언트가 하나의 작은 파일에 액세스하는 것과 같지 않습니다. 서버는 작은 파일에 대해 1000 개의 요청을 받거나 큰 파일의 일부에 대해 1000 개의 요청을받습니다.)
• 나는 스파 스 파일에 대해 약간 읽었습니다. 종이에 따라 작은 파일은 청크 또는 여러 청크를 채 웁니다. 그래서 내 이해에 작은 파일을 재구성하지 않으며 따라서 나는 핫스팟에 대한 가능한 원인으로 이것을 제거했습니다.

Answer 1

후속 텍스트의 일부는 도움이 될 수 있습니다 명확히 : GFS 먼저 일괄 큐 시스템에 의해 을 사용하는 경우

그러나, 핫스팟 개발했다 : 실행은 하나 같이 GFS 에 기록 된 -chunkfile을 실행하고 수백 대의 컴퓨터에서 동시에 시작합니다. 이 실행 파일을 저장하는 몇 개의 chunkservers는 수백 개의 동시 요청으로 인해 과부하가 걸렸습니다. 이 문제는 더 높은 복제 계수를 가진 과 같은 실행 파일을 저장하고 batchqueue를 시스템 스 태거 애플리케이션 시작 시간으로 설정함으로써 해결되었습니다. 잠재적 인 장기 해결책은 클라이언트가 다른 상황에서 다른 클라이언트로부터 데이터를 읽을 수 있도록하는 것입니다.

1000 명의 클라이언트가 동시에 작은 파일을 읽으려는 경우, 유일한 청크를 보유한 N 개의 chunkservers는 1000/N 동시 요청을 수신합니다. 이 갑작스런로드는 핫스팟의 의미입니다.

대용량 파일은 지정된 클라이언트에서 한 번에 모두 읽히지 않습니다 (결국 크기가 큽니다). 대신 파일의 일부분을로드하고 작업하고 다음 부분으로 이동합니다.

sharding (MapReduce, Hadoop) 시나리오에서 작업자는 동일한 청크를 전혀 읽지 않을 수도 있습니다. N 중 하나의 클라이언트는 파일의 1/N 청크를 다른 클라이언트와 구별합니다.

실제로 비 샤딩 시나리오에서도 클라이언트는 완전히 동기화되지 않습니다. 모두가 전체 파일을 읽지 만 랜덤 액세스 패턴으로 인해 통계적으로 핫스팟이 없습니다. 또는 순차적으로 읽는다면 워크로드의 차이 때문에 동기화되지 않을 것입니다 (의도적으로 클라이언트를 동기화하지 않는 한 ....).

많은 클라이언트의 경우에도 대용량 파일이 수반하는 작업 특성으로 인해 대용량 파일의 핫 스포팅이 적습니다.은으로 보장되지는 않습니다. 귀하의 질문에 귀하가 말하고있는 것이지만 실제로는 분산 된 클라이언트가 다중 청크 파일의 모든 청크에서 일하지 않습니다.