디렉토리에 몇 개의 파일을 넣을 수 있습니까?


561

단일 디렉토리에 몇 개의 파일을 보관해야합니까? 그렇다면 디렉토리에있는 파일 수가 너무 많고 파일이 너무 많으면 어떤 영향이 있습니까? (이것은 Linux 서버에 있습니다.)

배경 : 사진 앨범 웹 사이트가 있으며 업로드 된 모든 이미지의 이름이 8 진수 ID (예 : a58f375c.jpg)로 바뀝니다. 이는 파일 이름 충돌을 피하기위한 것입니다 (예 : "IMG0001.JPG"파일이 많이 업로드 된 경우). 원본 파일 이름과 유용한 메타 데이터는 데이터베이스에 저장됩니다. 지금은 images 디렉토리에 약 1500 개의 파일이 있습니다. 이렇게하면 FTP 또는 SSH 클라이언트를 통해 디렉토리에 파일을 나열하는 데 몇 초가 걸립니다. 그러나 그것이 다른 효과가 있다는 것을 알 수 없습니다. 특히 이미지 파일이 사용자에게 얼마나 빨리 제공되는지에 영향을 미치지 않는 것 같습니다.

16 개의 하위 디렉토리 (0-9 및 af)를 만들어 이미지 수를 줄이는 것에 대해 생각했습니다. 그런 다음 파일 이름의 첫 번째 16 진수가 무엇인지에 따라 이미지를 하위 디렉토리로 이동합니다. 그러나 때때로 FTP / SSH를 통한 디렉토리 목록을 제외하고 그렇게 할 이유가 있는지 확실하지 않습니다.

답변:


736

FAT32 :

  • 최대 파일 수 : 268,173,300
  • 디렉토리 당 최대 파일 수 : 2 (16)  - 1 (65,535)
  • 최대 파일 크기 : LFS 없이 2 GiB-1 , 4 GiB-1

NTFS :

  • 최대 파일 수 : 2 (32)  - 1 (4,294,967,295)
  • 최대 파일 크기
    • 구현 : 2 44  - 2 6 바이트 (16 TiB 크기 - 64 킬로바이트)
    • 이론 2 64  - 2 6 바이트 (EIB 16 - 64 킬로바이트)
  • 최대 볼륨 크기
    • 구현 : 2 32  - 1 개 클러스터 (256 TiB 크기 - 64 킬로바이트)
    • 이론 2 개 64  - 1 클러스터 (1 YiB - 64 킬로바이트)

ext2 :

  • 최대 파일 수 : 10 18
  • 디렉토리 당 최대 파일 수 : ~ 1.3 × 10 20 (1 만 개 이상의 성능 문제)
  • 최대 파일 크기
    • 16GiB (1KiB의 블록 크기)
    • 256GiB (블록 크기 2KiB)
    • 2TiB (4 KiB의 블록 크기)
    • 2TiB (8 KiB의 블록 크기)
  • 최대 볼륨 크기
    • 4TiB (1 KiB의 블록 크기)
    • 8TiB (2 KiB의 블록 크기)
    • 16TiB (4 KiB의 블록 크기)
    • 32TiB (8 KiB의 블록 크기)

ext3 :

  • 최대 파일 수 : min (volumeSize / 2 13 , numberOfBlocks)
  • 최대 파일 크기 : ext2와 동일
  • 최대 볼륨 크기 : ext2와 동일

ext4 :

  • 최대 파일 수 : 2 (32)  - 1 (4,294,967,295)
  • 디렉토리 당 최대 파일 수 : 무제한
  • 최대 파일 크기 : 2 (44)  - 1 바이트 (16 TiB 크기 - 1)
  • 최대 볼륨 크기 : 2 (48)  - 1 바이트 (256 TiB 크기 - 1)

24
나는 이것이 디렉토리가 아니라 전체 파티션에 대한 최대 파일 수라고 가정합니다. 따라서이 정보는 문제와 관련하여 너무 유용하지 않습니다. 디렉토리를 파일로 계산하지 않는 한 방법에 관계없이 동일한 수의 파일이 있기 때문입니다.
strager

19
우리가 지금 2012 년에 있기 때문에, 나는 ext4가 하위 디렉토리의 수에 관한 제한이 없다는 것을 분명히 할 시간이라고 생각합니다. 또한 최대 파일 크기는 16TB로 증가했습니다. 또한 파일 시스템의 전체 크기는 최대 1EB = 1,048,576TB입니다.
devsnd

7
분명히 ext3는 디렉토리 당 60,000 개의 파일 (또는 디렉토리 또는 링크)로 제한됩니다. 나는 이것에 대한 어려운 길을 발견했다.
Stackular

8
대답은 알고 있습니다… 그러나 EXT4 를 작성할 때 – 최대 파일 수 : 2³²-1 (4,294,967,295)디렉토리 당 최대 파일 수 : 무제한 2³²-1! =“무제한”으로 인해 정말 혼란 스러웠습니다. 커피가 필요하다고 생각합니다. ;) 그럼에도 불구하고 +1
e-sushi

11
하드 파일 시스템 한계 "는 질문에 대답하지 않는 내가 하나의 디렉토리에 보관 얼마나 많은 파일이 중요합니까? "
ETKI

191

단일 ext3 디렉토리에 8 백만 개가 넘는 파일이 있습니다. libc에 readdir()의해 사용되는 find, ls다른 방법의 가장 큰 디렉토리 목록이 글에서 논의.

그 이유 lsfind이 경우 느린 것은 즉 readdir()단지 속도가 느린 디스크에 많은 많은 디렉토리를 나열하는 읽기가 필요합니다, 한 번에 디렉토리 항목의 32K를 읽습니다. 이 속도 문제에 대한 해결책이 있습니다. 나는 그것에 대해 꽤 자세한 기사를 썼습니다 : http://www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- ls /

핵심 요소는 다음과 같습니다. getdents()직접 사용 -libc를 기반으로하는 것이 아니라 http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.htmlreaddir() 사용하여 버퍼를 지정할 수 있습니다. 디스크에서 디렉토리 항목을 읽을 때 크기.


6
재미있는 읽을 거리! 어떤 상황에서 한 디렉토리에 8 백만 개의 파일이 있는지 물어볼 수 있습니까? haha
Aᴄʜᴇʀᴏɴғᴀɪʟ

나는 똑 같았다. 테이블의 Blob 열을 마이그레이션했습니다. 각 Blob 열은 파일로 내보냈습니다. 그것은 약 8 백만 파일입니다 :)
Spike

65

88,914 개의 파일이있는 디렉토리가 있습니다. 자신과 마찬가지로 이것은 축소판 그림을 저장하고 Linux 서버에 사용됩니다.

FTP 또는 PHP 기능을 통한 나열된 파일은 느리지 만 파일을 표시 할 때 성능이 저하됩니다. 예 : www.website.com/thumbdir/gh3hg4h2b4h234b3h2.jpg의 대기 시간은 200-400ms입니다. 다른 사이트와 비교할 때 디렉토리에 약 100 개의 파일이 있는데 ~ 40ms 대기 후 이미지가 표시됩니다.

대부분의 사람들이 디렉토리 검색 기능이 수행되는 방식을 작성 했으므로이 대답을주었습니다.이 폴더는 엄지 폴더에서 사용하지 않고 정적으로 파일을 표시하지만 파일을 실제로 사용할 수있는 방법에 관심이 있습니다. .


6
이것은 유일한 유용한 답변입니다. 비슷한 경험을했습니다. 백업 문제를 줄이기위한 제한은 1.000 개입니다 (너무 많은 디렉토리도 느려집니다).
mgutt

1
noatime으로뿐만 아니라와 드라이브를 탑재하는 것이 유용 할 수 있습니다 howtoforge.com/...를 이 너무 읽어 serverfault.com/questions/354017/...
mgutt

2
속도가 느린 곳에서 어떤 파일 시스템을 사용하고 있습니까? 예를 들어 XFS는 눈에 띄는 속도 저하없이 디렉토리에서 100,000 개의 파일을 쉽게 처리 할 수 ​​있어야합니다.
Ethan

1
대부분의 다른 사람들의 의견과 모순되어이 답변을 확인하고 싶습니다. 소셜 네트워크 웹 사이트에는 수십만 개의 이미지가 있습니다. 성능을 향상시키기 위해 우리는 100 개 (또는 일부 파일의 경우 1000 개) 서브 디렉토리를 가져 와서 파일을 배포했습니다 (linux + Apache의 경우 ext3).
wmac

57

Linux 서버에서 사용중인 특정 파일 시스템에 따라 다릅니다. 현재 기본값은 dir_index를 사용하는 ext3이며 큰 디렉토리를 매우 빠르게 검색합니다.

따라서 이미 언급 한 것 외에는 속도가 문제가되지 않아야합니다. 즉, 리스팅이 더 오래 걸립니다.

한 디렉토리에있는 총 파일 수에는 제한이 있습니다. 32000 파일까지 확실히 작동하는 것을 기억합니다.


4
그놈과 KDE는 달팽이 속도로 큰 디렉토리를로드하고, 윈도우는 디렉토리를 캐시하여 합리적입니다. 나는 리눅스를 좋아하지만 kde와 gnome은 제대로 작성되지 않았다.
rook

1
그리고 ext4는 기본적으로 dir_index와 동등한 것으로 보입니다.
Falken 교수 계약은

22
ext3의 한 디렉토리 에는 약 32K 하위 디렉토리가 있지만 OP는 이미지 파일에 대해 이야기하고 있습니다. Dir Index가 활성화 된 ext3 파일 시스템의 파일에는 (실제?) 제한이 없습니다.
피터 N 루이스

1
이 답변은 구식입니다. 요즘 기본값은 ext4 입니다.
보리스

1
"Dir Index가 활성화 된 ext3 파일 시스템의 파일에는 (실제?) 제한이 없습니다."-4TB ext4 파일 시스템의 디렉토리에 파일 공간이 부족합니다 dir_index. 디렉토리에 약 1700 만 개의 파일이있었습니다. 대답은 large_dirtune2fs 로 켜는 것이 었습니다 .
lunixbochs

49

Linux에서 파일이 너무 많은 디렉토리가 있으면 셸에서 와일드 카드를 확장하지 못할 수 있습니다. Linux에서 호스팅되는 사진 앨범에이 문제가 있습니다. 모든 크기 조정 된 이미지를 단일 디렉토리에 저장합니다. 파일 시스템은 많은 파일을 처리 할 수 ​​있지만 쉘은 처리 할 수 ​​없습니다. 예:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

또는

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

33
@Steve에서는 이러한 경우 find (1) 및 / 또는 xargs (1)를 사용하십시오. 같은 이유로 명령 줄 확장 대신 스크립트에서 이러한 도구를 사용하는 것이 좋습니다.
Dave C

3
@Steve 폴더의 파일 수가 증가 할 때 성능이 저하되는 것을 보십니까? 아니면 관계가 없습니까?
Pacerier

6
이것은 좋은 지적이지만 nitpick에게는 주어진 이유가 잘못되었습니다. 인수 목록이 너무 긴 하지만 시스템의의가 아닌 쉘의 제한 사항입니다 exec구현. 셸은 일반적으로 와일드 카드를 확장 할 수 있습니다 exec. 오류를 반환하는 많은 인수를 사용해야합니다.
jw013

지난 밤 디렉토리에 ~ 400,000 개의 파일이있는 "rm"(일부 파일 *)과 동일한 오류 (Fedora 15)가 발생했습니다. 와일드 카드로 "rm"할 수있는 지점까지 "find"로 오래된 파일을 다듬을 수있었습니다.
PJ Brunet

etx4의 디렉토리에 10.000.000 파일이 정상적으로 작동합니다. 액세스 할 때 성능이 크게 저하되지 않습니다. 그러나 와일드 카드에서는 속도가 느립니다. 파일 이름 정렬을 좋아하는 쉘 프로그램을 사용할 때주의하십시오! :)
Simon Rigét

25

지금 비슷한 문제를 겪고 있습니다. 우리는 계층 구조의 디렉토리 구조를 가지고 있으며 이미지 ID를 파일 이름으로 사용합니다. 예를 들어, 함께 화상을 id=1234567배치한다

..../45/67/1234567_<...>.jpg

마지막 4 자리 숫자를 사용하여 파일의 위치를 ​​결정합니다.

수천 개의 이미지로 1 단계 계층 구조를 사용할 수 있습니다. 우리의 sysadmin은 효율성 / 백업 / 그가 생각한 다른 이유에 대해 주어진 디렉토리 (ext3)에 수천 개 이상의 파일을 제안했습니다.


1
이것은 꽤 좋은 해결책입니다. 파일에 이르기까지 디렉토리의 모든 레벨은 2 자리 숫자로 나뉘면 최대 100 개의 항목을 포함하며 맨 아래 디렉토리에는 파일이 하나만 있습니다.
RobKohr


21

그만한 가치가 있기 위해 방금 디렉토리에 디렉토리를 만들었습니다. ext4 파일 시스템에 1,000,000 개의 파일이 다음 웹 서버를 통해 해당 파일에 무작위로 액세스했습니다. 파일이 10 개 이상인 사람들에게 액세스하는 것에 대해서는 아무런 프리미엄이 없었습니다.

이것은 몇 년 전에 이것을 한 경험과 근본적으로 다릅니다 ntfs.


어떤 종류의 파일입니까? 텍스트 또는 이미지? 나는 ext4에 있고 워드 프레스 아래 하나의 디렉토리에 80000 개의 이미지를 가져와야하는지 알기를 원합니다
Yvon Huynh

1
@YvonHuynh : 파일의 종류는 전혀 관련이 없습니다. 파일 나열 / 추적 디렉토리의 오버 헤드는 상관없이 동일합니다.
TJ 크라우 더

14

내가 겪었던 가장 큰 문제는 32 비트 시스템입니다. 특정 숫자를 통과하면 'ls'와 같은 도구가 작동을 멈 춥니 다.

일단 그 장벽을 통과하면 해당 디렉토리로 무언가를 시도하는 것은 큰 문제가됩니다.


9

나는 같은 문제를 겪고있다. ext4의 Ubuntu 서버에 수백만 개의 파일을 저장하려고합니다. 내 벤치 마크를 종료했습니다. 플랫 디렉토리는 사용이 더 단순하면서도 성능이 더 우수하다는 것을 알았습니다.

기준

기사를 썼습니다 .


솔루션에 대한 링크는 환영하지만 답변없이 유용한 답변을 얻으십시오 . 링크 주위에 컨텍스트를 추가 하여 동료 사용자가 그 이유와 그 이유를 파악한 다음 페이지의 가장 관련성이 높은 부분을 인용하십시오. 대상 페이지를 사용할 수없는 경우 다시 연결 링크에 불과한 답변은 삭제 될 수 있습니다.
Samuel Liew

1
흥미 롭군 10,000 개의 파일이 있더라도 성능을 사용할 수 없을 정도로 매우 빠르게 저하되는 것으로 나타났습니다. 우리는 최적의 성능을 달성하기 위해 파일을 각 레벨에서 약 100의 하위 디렉토리로 나누는 것으로 해결했습니다. 이야기의 도덕은 항상 자신의 요구 사항이있는 자체 시스템에서 자신을 위해 벤치 마크하는 것입니다.
Joshua Pinter

7

디렉토리 파티셔닝 체계를 구현하는 데 소요되는 시간이 최소라면 그것을 선호합니다. 콘솔을 통해 10000 파일 디렉토리를 조작하는 것과 관련된 문제를 처음으로 디버깅해야 할 때 이해할 수 있습니다.

예를 들어, F-Spot은 사진 파일을 YYYY \ MM \ DD \ filename.ext로 저장합니다. 즉 ~ 20000-photo 컬렉션을 수동으로 조작하는 동안 처리해야하는 가장 큰 디렉토리는 약 800 개의 파일입니다. 또한 타사 응용 프로그램에서 파일을보다 쉽게 ​​찾을 수 있습니다. 소프트웨어 만 소프트웨어 파일에 액세스 할 것이라고 가정하지 마십시오.


6
대량 가져 오기는 특정 날짜에 파일을 클러스터링 할 수 있기 때문에 날짜 별 파티셔닝에 대해 광고합니다.
최대

좋은 지적입니다. 파티셔닝 구성표를 선택하기 전에 사용 사례를 반드시 고려해야합니다. 나는 비교적 넓은 분포로 며칠 동안 사진을 가져오고, F-Spot 날짜 이후의 사진을 조작하고 싶을 때 가장 쉽게 사진을 찾을 수 있으므로 두 번의 승리입니다.
Sparr

7

파일 시스템에 따라 다릅니다. 많은 현대 파일 시스템은 디렉토리의 내용을 저장하기 위해 적절한 데이터 구조를 사용하지만 오래된 파일 시스템은 종종 항목을 목록에 추가했기 때문에 파일 검색은 O (n) 작업이었습니다.

파일 시스템이 올바르게 작동하더라도 디렉토리 내용을 나열하는 프로그램이 엉망이되어 O (n ^ 2) 정렬을 수행하는 것은 여전히 ​​가능합니다. 따라서 안전한면을 유지하기 위해 항상 파일 수를 제한합니다. 500 이하의 디렉토리.


7

실제로 사용되는 파일 시스템과 일부 플래그에 따라 다릅니다.

예를 들어, ext3 에는 수천 개의 파일이있을 수 있습니다. 그러나 몇 천 후에는 아주 느 렸습니다. 대부분 디렉토리를 나열 할 때뿐만 아니라 단일 파일을 열 때도 발생합니다. 몇 년 전, 파일 이름이 주어진 inode를 얻는 데 필요한 시간을 대폭 단축하는 'htree'옵션을 얻었습니다.

개인적으로, 나는 하위 디렉토리를 사용하여 대부분의 레벨을 수천 개 정도의 아이템으로 유지합니다. 귀하의 경우, ID의 마지막 두 자리 16 진수로 256 개의 디렉토리를 만듭니다. 첫 번째 숫자가 아닌 마지막 숫자를 사용하므로로드 균형이 조정됩니다.


6
파일 이름이 완전히 임의적이라면 어떤 숫자를 사용했는지는 중요하지 않습니다.
strager

실제로 이러한 파일 이름은 임의로 생성됩니다.
Kip

2
또는 파일 이름의 SHA-1 다이제스트의 첫 N 바이트를 사용하십시오.
gawi

6

ext3는 실제로 디렉토리 크기 제한이 있으며 파일 시스템의 블록 크기에 따라 다릅니다. 디렉토리 당 "최대 개수"파일이 아니라 디렉토리 당 "파일 항목을 저장하는 데 사용되는 최대 블록 수"가 있습니다. 특히 디렉토리 자체의 크기는 높이 3의 b- 트리를 넘어서는 안되며 트리의 팬 아웃은 블록 크기에 따라 다릅니다. 자세한 내용은이 링크를 참조하십시오.

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

나는 최근에 2K 블록으로 포맷 된 파일 시스템에서 물 렸는데, warning: ext3_dx_add_entry: Directory index full!다른 ext3 파일 시스템에서 복사 할 때 디렉토리 전체 커널 메시지를 얻을 수 없었습니다. 필자의 경우 파일이 480,000 개인 디렉토리를 대상으로 복사 할 수 없었습니다.


5

질문은 파일로 무엇을 할 것인지에 달려 있습니다.

Windows에서 파일이 2k를 초과하는 디렉토리는 탐색기에서 느리게 열리는 경향이 있습니다. 모두 이미지 파일 인 경우 축소판 그림보기에서 1k 이상이 매우 느리게 열리는 경향이 있습니다.

한 번에 시스템 부과 제한은 32,767이었습니다. 지금은 더 높지만 대부분의 상황에서 한 번에 처리하기에는 너무 많은 파일입니다.


5

위의 답변 중 대부분이 보이지 않는 것은 원래 질문에 대한 "하나의 크기에 맞는"답변이 없다는 것입니다.

오늘날의 환경에서 우리는 서로 다른 하드웨어 및 소프트웨어의 대기업을 보유하고 있습니다. 일부는 32 비트, 일부는 64 비트, 일부는 최첨단이며 일부는 시도되고 진실하며 신뢰할 수 있으며 절대 변하지 않습니다. 여기에는 다양한 구형 및 최신 하드웨어, 구형 및 최신 OS, 다른 공급 업체 (Windows, Unixes, Apple 등) 및 수많은 유틸리티 및 서버가 추가됩니다. 하드웨어가 개선되고 소프트웨어가 64 비트 호환성으로 변환됨에 따라이 매우 크고 복잡한 세계의 모든 부분이 빠른 속도의 변화에 ​​따라 훌륭하게 재생되는 데 상당한 지연이있었습니다.

IMHO 문제를 해결할 방법이 없습니다. 해결책은 가능성을 연구 한 다음 시행 착오를 통해 특정 요구에 가장 적합한 것을 찾는 것입니다. 각 사용자는 쿠키 커터 접근 방식을 사용하지 않고 시스템에 적합한 것을 결정해야합니다.

예를 들어 매우 큰 파일이 몇 개있는 미디어 서버가 있습니다. 결과는 3TB 드라이브를 채우는 약 400 개의 파일입니다. inode의 1 % 만 사용되지만 전체 공간의 95 %가 사용됩니다. 더 작은 파일이 많은 다른 사람은 공간을 채우기 전에 inode가 부족할 수 있습니다. 일반적으로 ext4 파일 시스템에서는 일반적으로 각 파일 / 디렉토리에 1 개의 inode가 사용됩니다. 이론적으로 디렉토리에 포함될 수있는 총 파일 수는 거의 무한하지만 실용성은 전체 사용량이 실제 단위가 아닌 실제 단위를 결정한다고 결정합니다. 파일 시스템 기능 만

위의 모든 다른 답변들이 극복 할 수없는 장애물을 제시하기보다는 생각과 문제 해결을 촉진하기를 바랍니다.


4

출력에서 많은 양의 파일을 생성하는 프로그램을 실행하는 것을 기억합니다. 파일은 디렉토리 당 30000으로 정렬되었습니다. 생성 된 출력을 재사용해야 할 때 읽기 문제가 발생한 것을 기억하지 못합니다. 32 비트 Ubuntu Linux 랩톱에 있었고 심지어 노틸러스 조차도 몇 초 후에도 디렉토리 내용을 표시했습니다.

ext3 파일 시스템 : 64 비트 시스템의 유사한 코드는 디렉토리 당 64000 개의 파일을 처리했습니다.


4

"파일 시스템에 따라"
일부 사용자는 성능에 미치는 영향이 사용 된 파일 시스템에 달려 있다고 언급했습니다. 물론이야. EXT3와 같은 파일 시스템은 매우 느릴 수 있습니다. 그러나 EXT4 또는 XFS를 사용하더라도 FTP와 같은 외부 연결을 통해 ls또는 find외부 연결을 통해 폴더를 나열 하면 속도가 느려지는 것을 막을 수 없습니다 .

해결책
나는 @armandino 와 같은 방식을 선호합니다 . 이를 위해 PHP 에서이 작은 함수를 사용하여 ID를 디렉토리 당 1000 파일을 생성하는 파일 경로로 변환합니다.

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

또는 영숫자 문자를 사용하려는 경우 두 번째 버전을 사용할 수 있습니다.

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

결과 :

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

$int-version에서 볼 수 있듯이 모든 폴더에는 최대 1000 개의 파일과 1000 개의 파일 및 99 개의 디렉토리를 포함하는 최대 99 개의 디렉토리가 있습니다 ...

그러나 많은 디렉토리에 동일한 성능 문제가 발생한다는 것을 잊지 마십시오!

마지막으로 총 파일 수를 줄이는 방법에 대해 생각해야합니다. 대상에 따라 CSS 스프라이트를 사용하여 아바타, 아이콘, 웃음 등과 같은 여러 개의 작은 이미지를 결합 할 수 있습니다. 또는 미디어 파일이 아닌 작은 파일을 많이 사용하는 경우 JSON 형식과 같은 조합을 고려하십시오. 내 경우에는 수천 개의 미니 캐시가 있었고 마침내 10 팩으로 묶기로 결정했습니다.


3

나는 이것이 얼마나 많은지에 대한 귀하의 질문에 완전히 대답하지는 않지만 장기적인 문제를 해결하기위한 아이디어는 원본 파일 메타 데이터를 저장하는 것 외에도 디스크에 저장된 폴더를 디스크에 저장한다는 것입니다. 메타 데이터를 제거하십시오. 폴더가 어느 정도 한계를 넘어 서면 성능, 미적 또는 기타 이유로 편안하게 사용할 수 있습니다. 두 번째 폴더를 만들어 파일을 드롭하기 만하면됩니다.


3

비슷한 문제가 발생했습니다. 10,000 개가 넘는 파일이있는 디렉토리에 액세스하려고했습니다. 파일 목록을 작성하고 파일에서 모든 유형의 명령을 실행하는 데 너무 오래 걸렸습니다.

나는 이것을 위해 작은 PHP 스크립트를 생각하고 브라우저에서 시간 초과를 막는 방법을 찾으려고 노력했다.

다음은 문제를 해결하기 위해 작성한 PHP 스크립트입니다.

FTP에 파일이 너무 많은 디렉토리에 파일 나열

누군가를 돕는 방법


1

답이 아니라 몇 가지 제안 만 있습니다.

더 적합한 FS (파일 시스템)를 선택하십시오. 역사적인 관점에서 볼 때, 모든 문제는 한때 수십 년에 걸쳐 진화 한 FS의 중심이되기에 충분히 현명했습니다. 더 현대적인 FS가 문제를 더 잘 지원한다는 의미입니다. 먼저 FS 목록 의 최종 목적에 따라 비교 결정 테이블을 만듭니다. .

나는 당신의 패러다임을 바꿀 시간이라고 생각합니다. 따라서 개인적으로 분산 시스템 인식 FS를 사용하는 것이 좋습니다. 는 크기, 파일 수 등과 관련하여 전혀 제한이 없습니다. 그렇지 않으면 조만간 새로운 예기치 않은 문제가 발생할 수 있습니다.

확실하지는 않지만 실험을 언급하지 않으면 현재 파일 시스템에 대해 AUFS를 사용해보십시오. 여러 폴더를 단일 가상 폴더로 모방하는 기능이 있다고 생각합니다.

하드웨어 제한을 극복하기 위해 RAID-0을 사용할 수 있습니다.


1

OS의 한계를 초과하지 않는 한 "너무 많은"단일 수치는 없습니다. 그러나 OS에 관계없이 디렉토리에 파일이 많을수록 개별 파일에 액세스하는 데 시간이 오래 걸리고 대부분의 OS에서는 성능이 비선형 적이므로 10,000 개 중 하나의 파일을 찾는 데 10 배 이상 걸린다 그런 다음 1,000에서 파일을 찾습니다.

디렉토리에 많은 파일이있는 것과 관련된 2 차 문제에는 와일드 카드 확장 실패가 포함됩니다. 위험을 줄이려면 업로드 날짜 또는 기타 유용한 메타 데이터로 디렉토리를 정렬하는 것이 좋습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.