70,000개의 정적 파일(jpg)을 서비스하는 최적의 방법은 무엇입니까?

Question

nginx를 사용하여 약 70,000개의 정적 파일(jpg)을 제공해야 합니다. 단일 디렉토리에 모두 덤프해야 합니까, 아니면 더 나은(효율적인) 방법이 있습니까? 파일 이름이 숫자이므로 다음과 같은 디렉토리 구조를 고려했습니다.

xxx/xxxx/xxx

OS는 CentOS 5.1입니다.

Answer 1

벤치마크, 벤치마크, 벤치마크! 아마도 당신은 찾을 것입니다큰 차이 없음두 가지 옵션 중 하나를 선택하면 다른 문제에 시간을 더 효율적으로 투자할 수 있습니다. 벤치마크를 수행하고 실제 차이점을 찾지 못한 경우 더 쉬운 구성표를 사용하십시오. 즉, 프로그램만 파일에 액세스해야 하는 경우 코딩하기 쉬운 방법, 또는 파일을 자주 작업해야 하는 경우 사람이 작업하기 쉬운 방법을 선택하십시오.

어느 쪽이든 더 빠른 경우 디렉터리 조회 시간은 디렉터리에 있는 파일 수의 로그에 비례한다고 생각합니다. 따라서 중첩된 구조에 대한 세 가지 조회 각각은 한 번의 큰 조회보다 빠르지만 세 가지 모두의 총합은 아마도 더 클 것입니다.

하지만 저를 믿지 마세요. 저는 제가 무엇을 하고 있는지 전혀 모릅니다!성과 측정중요한 때!

Answer 2

이는 실제로 파일을 저장하는 데 사용하는 파일 시스템에 따라 다릅니다.

일부 파일 시스템(ext2 및 ext3과 같은)은 한 디렉토리에 수천 개의 파일이 있을 때 끔찍할 정도로 느리므로 하위 디렉토리를 사용하는 것이 매우 좋습니다.

XFS 또는 reiserfs(*)와 같은 다른 파일 시스템은 하나의 디렉토리에 수천 개의 파일이 있어도 속도가 느려지지 않으므로 하나의 큰 디렉토리가 있는지 또는 많은 작은 하위 디렉토리가 있는지는 중요하지 않습니다.

(*) reiserfs는 몇 가지 좋은 기능을 가지고 있지만 치명적인 실패의 역사를 가진 실험적인 장난감입니다. 원격으로 중요한 것에도 사용하지 마십시오.

Answer 3

다른 사람들이 말했듯이 디렉토리 해싱이 아마도 가장 최적일 것입니다.

제가 제안하고 싶은 것은 URI를 만드는 것입니다.독립적인nginx의 재작성 모듈을 사용하여 사용하는 디렉토리 구성표(예: example.com/123456.jpg를 /path/12/34/123456.jpg로 매핑)

그런 다음 성능상의 이유로 디렉터리 구조를 변경해야 하는 경우 게시된 URI를 변경하지 않고도 디렉터리 구조를 변경할 수 있습니다.

Answer 4

nginx 서버 앞에 오징어 캐시를 넣을 수 있습니다. Squid는 인기 있는 이미지를 메모리에 보관하거나 빠른 조회를 위해 자체 파일 레이아웃을 사용할 수 있습니다.

Squid의 경우 기본값은 16개의 레벨 1 디렉터리와 256개의 레벨 2 디렉터리입니다. 이는 내 파일 시스템에 대한 합리적인 기본값입니다.

Squid와 같은 제품을 사용하지 않고 자신만의 파일 구조를 만드는 경우 파일에 대한 합리적인 해싱 알고리즘을 마련해야 합니다. 파일 이름이 무작위로 생성된 경우 이는 쉽고 파일 이름 자체를 사용하여 버킷으로 나눌 수 있습니다. 모든 파일이 IMG_xxxx처럼 보이는 경우 최하위 숫자를 사용하거나 파일 이름을 해시하고 해당 해시 번호를 기준으로 나누어야 합니다.