XE 파일을 보면

 

문서번호 기준으로 3자리씩 끊어서 폴더를 생성합니다.

 

예를 들어 123456 이라는 문서 번호에 첨부파일을 올리면

 

456/123/첨부파일~~

 

이런 식으로 경로가 설정되어 올라가게 되지요.

 

이전에 XE 공홈에서 잠깐 설명을 들은 듯 한데,


폴더가 많으면 그만큼 액세스 하는 속도가 느려진다고 했던 것 같은데,

그래서 어떻게 하면 효율적으로 첨부파일을 분배하면서 넣을 수 있을까 라는 연구(?) 끝에 이런 방식을 사용하였던 걸로

 

얼핏 기억합니다.

 

이게 실제로 효율이 있나? 체감할 수 있는 지가 궁금하더라구요.

 

또, XE가 아닌 다른 CMS나 다른 곳에서는 첨부파일이 어떻게 관리 하는지도 궁금하구요..!

 

이번에 나름 첨부파일 위주에 사이트를 만들고 있는데, 현행 방식으로는 관리할 때 애로사항이 꽃피어서...

별도로 첨부파일을 관리해야 할 것 같아서 어떤 식으로 파일을 배치하는지 궁금하기도 하구요..ㅎㅎ

 

 

  • profile

    워드프레스는 그냥 년/월(2016/05 같이) 관리하는것 같습니다. 파일을 올리니 http://example.com/wp-content/uploads/2015/02/filename.ext 처럼 올라가네요.

  • profile profile
    저도 이런식이 차라리 나을 것 같은데..
  • profile

    서버 환경에 따라 차이가 있지만, 한 폴더에 파일이나 서브폴더 수가 몇천 개를 넘어가면 성능이 눈에 띄게 나빠지기 시작합니다. 파일명을 콕 찝어서 요청할 때는 상관없지만, 쉘이나 FTP에서 폴더 단위로 관리하려고 하면 기본적인 ls 명령조차 한참 걸리죠. 파일시스템도 일종의 DB라고 생각하면 이유를 짐작하실 수 있을 거예요. 개별 파일을 요청하는 것은 PK로 검색하는 셈이고, 폴더 단위의 관리작업은 그 밖의 넌클러스터드 인덱스로 검색하는 셈이니까요. 즉, 사이트 자체의 로딩속도보다는 관리자의 체감속도 문제입니다.

     

    물론 XE는 이걸 너무 지나치게 세분화해 놓은 경향이 있습니다. 시퀀스 값을 통째로 분할하다 보니 마지막 레벨의 폴더 안에는 파일이 한두 개씩밖에 들어 있지 않은 경우가 대부분이지요. 시퀀스 갯수만큼 폴더가 생성되므로 사이트 규모가 조금만 커지면 폴더 트리가 어마어마하게 커져 버립니다.

     

    사실 파일을 저장한 경로는 DB에 기록되어 있으니까 (files 테이블의 uploaded_filename 필드 사용) 어디에 어떤 구조로 분할해서 저장하든 상관이 없습니다. 기존에 저장된 파일이 많고, 그걸 본문에서 링크한 경우도 많고, 시퀀스 기반의 폴더 구조가 관례로 굳어져서 거기에 의존하는 서드파티 자료도 있을 수 있기 때문에 바꾸기 힘든 것 뿐이죠. 라이믹스에서는 아마 언젠가 한 번 손을 보게 될 거예요. 그래도 기존에 저장된 파일들은 건드리지 않을 듯 합니다.

  • profile profile
    구글은 어떻게 관리하는 지 궁금하네요..

    유튜브라든지... 등등.. 파일 수가 엄청날텐데...
  • profile profile
    일반인: 천만개의 파일을 어떻게 관리하지?
    구글: 천만대의 서버를 어떻게 관리하지?
  • profile profile
    ㄷㄷㄷㄷㄷ