☰

Windows 폴더 구조에 수천 개의 이미지를 저장하는 가장 좋은 방법은 무엇입니까?

tag-icon • tag-icon performance directory images
Windows 폴더 구조에 수천 개의 이미지를 저장하는 가장 좋은 방법은 무엇입니까?

이와 같은 Windows 폴더 구조에는 수십만 개의 jpg 이미지가 있지만 빠른 방식으로 상호 작용하고 작업하는 것은 정말 어렵습니다(목록을 작성하는 데 시간이 걸리고 복사하는 데 시간이 걸립니다). 구조는 다음과 같습니다.

images/
  1/
    10001/
      10001-a.jpg
      10001-b.jpg
      ...
      10001-j.jpg (10 images in each XXXXX folder)
    10002/
    10003/
    ...
    19999/
  2/
    20001/
    20002/
    20003/
    ...
    29999/
  3/
  4/
  5/
  6/
  7/
  8/
  9/

이제 appr이 있기 때문에 이러한 이미지를 탐색하는 것이 약간 느립니다. 각 X 폴더에 10,000개의 폴더가 있으며 이를 나열하는 데는 시간이 걸립니다.

하위 폴더/항목 수가 적어서 이미지를 정리하는 더 좋은 방법이 있습니까? 구조를 이렇게 바꾸면 효과가 있을까요?

images/
  1/
    0/
      0/
        0/
          0/
          1/
          2/
          3/
          4/
          5/
          6/
          7/
          8/
          9/
          10000/ (image folder, same as path)
            10000-a.jpg
            10000-b.jpg
            ...
            10000-j.jpg (10 images in each image folder)
        1/
        2/
        3/
        4/
        5/
        6/
        7/
        8/
        9/
      1/
      2/
      3/
      4/
      5/
      6/
      7/
      8/
      9/
    1/
    2/
    3/
    4/
    5/
    6/
    7/
    8/
    9/
  2/
  3/
  4/
  5/
  6/
  7/
  8/
  9/

따라서 이미지 48617-c.jpg를 찾는 것은 경로 4/8/6/1/7/48617/48617-c.jpg와 같습니다.

전체 경로 번호가 48617인 별도의 폴더를 갖는 이유는 전체 10개 이미지 배치의 복사(전체 폴더 복사)를 단순화하기 위한 것입니다.

이제 폴더에는 11개 이상의 하위 폴더가 없지만 분리 목적으로 추가로 한 자릿수 폴더가 많이 있을 것입니다. 이 설정을 사용하면 여러 사용자가 이미지를 추가/복사/삭제하는 등의 검색 및 상호 작용 속도가 빨라지나요?

답변1

Windows는 엄청난 양의 파일이 포함된 폴더 레이아웃에 있어 약간 특별합니다. 특히 이미지는 Windows 탐색기에서 특별하게 취급되기 때문입니다. 즉, 상황이 악화되는 것을 방지하기 위해 따라야 할 몇 가지 지침이 있습니다.~도손이 닿지 않는 곳:

  • 어떤 이유로든 Windows 탐색기에서 디렉터리 구조를 탐색하려는 경우 디렉터리(파일 및 하위 디렉터리)의 항목을 10,000개 미만으로 유지하십시오.
  • CLI 유틸리티나 코드를 통해서만 상호 작용하는 경우 10K 제한이 훨씬 더 유연합니다.
  • 너무 많은 하위 디렉터리를 만들지 마십시오. 생성한 각 디렉터리는 복사할 때 복사본이 수행해야 하는 또 다른 개별 작업입니다.
    • 각 파일이 N개의 디렉터리를 생성하는 경우파일 시스템 객체해당 파일에 의해 생성된 값은 1+N이 되며, 이는 복사 시간을 선형적으로 확장합니다.
    • 짧은 지수 트리(각각 256개의 하위 디렉토리가 있는 3계층 디렉토리)는 디렉토리당 10K 제한에 도달하기 전에 놀라울 정도로 확장될 수 있습니다.
  • 코드를 사용하여 액세스하는 경우 열기 전에 디렉터리 목록을 구문 분석하는 대신 직접 열기를 선택하세요. 실패한 fopen()과 디렉터리 검색은 많은 경우 보장된 fopen()이 뒤따르는 dir 검색보다 빠릅니다.

주의사항:

  • 파일 수는 변경할 수 없지만 디렉터리 수는 사용자에게 달려 있습니다. 이 두 개수의 합은 복사 작업 속도에 영향을 미칩니다.
  • 가능하다면 꼭 필요한 경우가 아니면 Windows 탐색기를 사용하지 마십시오. 큰 디렉토리에는 잘 맞지 않으며 이에 대해 할 수 있는 일도 많지 않습니다.

답변2

내 답변에는 수학에 관한 좋은 정보가 많이 있습니다.디렉토리 복잡성이 i-node에 어떤 영향을 미치나요?

즉, 다양한 파일 시스템은 다양한 방식으로 디렉터리의 많은 수의 파일을 처리합니다. 일부는 10,000개의 항목으로 괜찮고 다른 일부는 버클입니다. 빠르게 고안된 경험 법칙에 따르면 설계 제어가 가능하다면 1,000이 아마도 좋은 목표 상한선일 것입니다. 디렉토리의 항목은 일반적으로 일종의 목록으로 저장되며 순서를 정렬하는 것은 읽기 응용 프로그램에 달려 있습니다. 예를 들어, lsUnix 세계에서는 디렉토리 순서로 메모리에 내용을 읽어온 다음 알파벳 순서로 인쇄합니다.

다른 질문의 수학을 살펴보세요. 또한 Explorer가 다르게 동작하는 것에 대해 sysadmin1338이 말한 내용을 고려하십시오. Explorer는 이미지로 인식되는 모든 것의 축소판을 만든 다음 축소판을 읽어 표시합니다. 파일로 가득 찬 디렉토리를 보려면 많은 디스크 IO가 필요합니다.

답변3

이러한 시스템을 개발할 리소스가 있는지 여부에 따라 이는 다음을 사용하는 SQL Server 데이터베이스에 적합한 후보처럼 들립니다.파일 스트림파일 저장. 이렇게 하면 디렉터리 구성을 SQL Server에 맡기고 걱정해야 할 것은 데이터 자체를 관리하는 방법뿐입니다. 데이터베이스 크기를 계산할 때 FILESTREAM 데이터가 고려되지 않으므로 SQL Express를 사용할 수 있습니다.

관련 정보