Linux 웹 서버에서 1,000,000 개 이상의 작은 gzip 파일을 가장 효율적으로 저장하고 제공하는 방법은 무엇입니까?

Linux 기반 웹 서버를 통해 제공해야하는 큰 정적 콘텐츠가 있습니다. 백만 개가 넘는 작은 gzip 파일 세트입니다. 파일의 90 %는 1K 미만이고 나머지 파일은 최대 50K입니다. 앞으로이 파일은 1,000 만 gzip 파일로 커질 수 있습니다.

이 컨텐츠를 파일 구조에 두어야합니까? 아니면이 모든 컨텐츠를 데이터베이스에 두어야합니까? 파일 구조 인 경우 큰 디렉토리를 사용할 수 있습니까? 아니면 작은 디렉토리를 고려해야합니까?

파일 구조가 더 빠르다는 말을 들었지만 다른 한편으로는 파일 블록이 1K 이상이기 때문에 파일이 디스크에서 많은 공간을 차지한다는 것을 알고 있습니다.

배송 실적과 관련하여 가장 좋은 전략은 무엇입니까?

최신 정보

기록을 위해 Windows 7에서 50 만 개의 파일로 테스트를 수행했습니다.

FS 구조가 더 빠를 것이라고 생각하지만 파일 수가 많은 디렉토리를 피하려면 좋은 디렉토리 구조가 필요합니다.

디스크 공간 손실에 대해 너무 걱정하지 않아도됩니다. 예를 들어, 16K 블록 크기에서는 최악의 경우 단일 파일마다 하나의 추가 블록이 필요한 경우 15GB의 공간을 잃게됩니다. 오늘날의 디스크 크기 만 있으면 아무 것도 아닙니다. 파일 시스템의 매개 변수를 특정 요구에 맞게 조정할 수 있습니다.

파일 구조 옵션을 선택하면 디스크 I / O 성능을 적어도 어느 정도 향상시키기 위해 할 수있는 한 가지 방법은 파티션이 필요하지 않은 경우 noatime + nodiratime으로 파티션을 마운트하는 것입니다. 그들은 전혀 중요하지 않으므로 그렇게하는 것이 좋습니다. 솔리드 스테이트 드라이브를 사용할 수도 있습니다.

여기에 정답은 파일 색인 생성 방법에 따라 달라집니다. 주어진 파일을 언제 배달하도록 선택하는지 결정합니다.

파일 이름을 결정하기 위해 이미 데이터베이스 쿼리를 작성하는 경우 파일을 db 레코드에 그대로 두는 것이 가장 좋습니다. 데이터베이스의 일부 페이징 설정을 조정하면 최상의 결과를 얻을 수 있습니다 선택하고 db에 파일을 저장하거나 (예 : 모든 blob 레코드를 설명하기 위해 더 큰 페이지) 파일 시스템을 사용하는 것이 여전히 낫습니다.

데이터베이스 옵션은 백만 개의 레코드로 각 파일이 똑같이 쿼리되지 않을 가능성이 높으므로 해결할 가능성이 적습니다. 한 파일이 여러 번 연속으로 또는 거의 연속적으로 쿼리 될 수있는 상황에서 데이터베이스는 최근에 검색된 파일에 대한 사실상의 캐시 역할을 할 수 있으며,이 경우 종종 파일 결과가 나타납니다 이미 메모리에로드되었습니다. 원하는 동작을 얻으려면 데이터베이스 엔진 내부를 신중하게 조정해야합니다.

그러나 내 대답에서 벗어나야 할 가장 중요한 것은 대표적인 테스트 데이터로 시도하고 결과를 측정하기 전에는 무엇이 가장 효과가 있을지 실제로 모른다는 것입니다.

최신 파일 시스템을 사용하면 큰 문제가되지 않습니다. 동일한 디렉토리에서 10 억 개의 파일로 XFS를 테스트했으며 파일 시스템 자체가 너무 크지 않은 한 ext4도 제대로 작동 할 것이라고 확신합니다. 디렉토리 항목을 캐시하기에 충분한 메모리가 있어야합니다. 프로세서 캐시가 클수록 많은 도움이됩니다.