약 1,000 만 개의 파일 (책 표지)이 [0-f] 범위의 3 단계 하위 디렉토리에 저장된 웹 사이트를 운영합니다.

0/0/0/
0/0/1/
...
f/f/f/

이로 인해 디렉토리 당 약 2400 개의 파일이 생성되므로 하나의 파일을 검색해야 할 때 매우 빠릅니다. 이것은 또한 많은 질문에 의해 제안 된 관행 입니다.

그러나 이러한 파일을 백업해야하는 경우 10m 파일을 보유한 4k 디렉토리를 찾아 보려면 며칠이 걸립니다.

따라서이 파일을 컨테이너 (또는 4k 컨테이너)에 저장할 수 있는지 궁금합니다.이 파일은 각각 파일 시스템 (일부 마운트 된 ext3 / 4 컨테이너)과 똑같이 작동합니까? 나는 이것이 파일 시스템의 파일에 직접 액세스하는 것만큼이나 효율적일 것이라고 생각하며, 이것은 다른 서버로 매우 효율적으로 복사되는 큰 이점을 가질 것입니다.

최선을 다하는 방법에 대한 제안이 있으십니까? 또는 실행 가능한 대안 (noSQL, ...)?

수백만 개의 파일에 빠르게 액세스하고 백업하기위한 옵션

비슷한 문제를 가진 사람들에게서 빌리십시오

이것은 USENET 뉴스 서버와 웹 프록시 캐싱에 직면하는 더 쉬운 종류의 문제처럼 들립니다. 무작위로 액세스되는 수억 개의 작은 파일입니다. 일반적으로 백업을 수행 할 필요가없는 경우를 제외하고는 힌트를 얻을 수 있습니다.

http://devel.squid-cache.org/coss/coss-notes.txt

http://citeseer.ist.psu.edu/viewdoc/download;jsessionid=4074B50D266E72C69D6D35FEDCBBA83D?doi=10.1.1.31.4000&rep=rep1&type=pdf

순환 뉴스 파일 시스템의 주기적 특성은 분명히 관련이 없지만, 압축 된 이미지가있는 여러 디스크 파일 / 장치 및 위치 정보를 찾기 위해 사용자가 제공 한 정보의 빠른 색인을 갖는 저수준 개념은 매우 적합합니다.

전용 파일 시스템

물론 이것들은 사람들이 파일에 파일 시스템을 만들고 자신의 파일 시스템 코드를 작성하는 것을 제외하고는 파일을 루프백에 마운트하는 것과 비슷한 개념입니다. 물론 시스템이 대부분 읽기 전용이라고 말했기 때문에 실제로 디스크 파티션 (또는 크기 조정의 유연성을 위해 lvm 파티션)을이 한 가지 목적으로 사용할 수 있습니다. 백업하려면 파일 시스템을 읽기 전용으로 마운트 한 다음 파티션 비트를 복사하십시오.

LVM

위의 LVM은 파티션의 동적 크기 조정을 허용하여 많은 빈 공간을 백업 할 필요가없는 것으로 언급했습니다. 그러나 물론 LVM에는 적용 할 수있는 다른 기능이 있습니다. 특히 파일 시스템을 한 번에 고정 할 수있는 "스냅 샷"기능. 우발적 rm -rf이거나 스냅 샷을 방해하지 않는 모든 것. 수행하려는 작업에 따라 백업 요구에 충분할 수 있습니다.

RAID-1

RAID에 대해 이미 잘 알고 있고 이미 안정성을 위해 이미 사용하고있을 것입니다. 그러나 최소한 소프트웨어 RAID를 사용하는 경우 RAID-1을 백업에도 사용할 수 있습니다 (하드웨어 RAID와 함께 사용할 수는 있지만 실제로는 동일한 모델 / 개정 컨트롤러를 읽으려면 신뢰성이 떨어집니다). 개념은 정상적인 안정성 요구를 위해 실제로 연결해야하는 것보다 하나 이상의 디스크로 RAID-1 그룹을 생성하는 것입니다 (예 : 두 개의 디스크로 소프트웨어 RAID-1을 사용하는 경우 세 번째 디스크 또는 큰 디스크 및 하드웨어- 하드웨어 RAID-5 위에 소프트웨어 RAID-1이있는 더 작은 디스크가있는 RAID5). 백업을 할 시간이되면 디스크를 설치하고 mdadm에게 해당 디스크를 RAID 그룹에 추가하도록 요청하고 완료를 나타낼 때까지 기다렸다가 선택적으로 확인 스크럽을 요청한 다음 디스크를 제거하십시오. 당연하지,

루프백 관리자를 사용하여 가상 파일 시스템을 마운트 할 수 있지만 백업 프로세스 속도가 빨라지지만 정상적인 작동에 영향을 줄 수 있습니다.

또 다른 대안은 dd를 사용하여 전체 장치를 백업하는 것입니다. 예를 들면 다음과 같습니다 dd if=/dev/my_device of=/path/to/backup.dd.

아시다시피, 문제는 지역성입니다. 일반적인 디스크 탐색에는 10ms 정도 걸립니다. 따라서 무작위로 배치 된 1000 만 개의 파일에서 "stat"(또는 open ())을 호출하면 1,000 만 탐색 또는 약 100000 초 또는 30 시간이 필요합니다.

따라서 관련 숫자가 탐색 시간이 아닌 드라이브 대역폭 (일반적으로 단일 디스크의 경우 50-100MB / 초)이되도록 파일을 더 큰 컨테이너에 넣어야합니다. 또한 RAID를 던져 대역폭을 높일 수는 있지만 탐색 시간을 줄일 수는 없습니다.

나는 당신에게 아직 당신이 모르는 것을 말하지 않을 것이지만, 나의 요점은 당신의 "컨테이너"아이디어가 문제를 확실히 해결할 것이며, 어떤 컨테이너도 할 것이라고 생각합니다. 루프백 마운트는 무엇이든 작동 할 것입니다.

몇 가지 옵션이 있습니다. 가장 단순하고 모든 Linux 파일 시스템에서 작동해야하는 dd것은 전체 파티션 ( /dev/sdb3또는 /dev/mapper/Data-ImageVol)을 단일 이미지 로 복사하고 해당 이미지를 아카이브하는 것입니다. 단일 파일을 복원하는 경우 이미지 ( mount -o loop /usr/path/to/file /mountpoint)를 루프백 마운트하고 필요한 파일을 복사하십시오. 전체 파티션 복원의 경우 초기 dd명령 의 방향을 반대로 바꿀 수 있지만 실제로 동일한 크기의 파티션이 필요합니다.

귀하의 유스 케이스에서 판단 할 때 개별 파일 복원이 전혀 발생하지 않는 경우가 매우 드 event니다. 이것이 바로 이미지 기반 백업이 여기에 의미가있는 이유입니다. 개별 복원을 더 자주 수행해야하는 경우 단계적 LVM 스냅 샷을 사용하는 것이 훨씬 편리합니다. 그러나 중요한 "모든 것을 잃어버린"재난에 대해서는 이미지 기반 백업을 수행해야합니다. 이미지 기반 복원 은 단순히 블록을 복원하기 때문에 tar 기반 복원보다 훨씬 빠르게 진행 되는 경향이 있으며 , 매 fopen / fclose마다 약간의 메타 데이터 작업이 발생하지 않으며, 순차적 인 디스크 작업도 가능합니다. 추가 속도가 증가합니다.

또는 @casey의 Google 비디오에서 반쯤 언급 한 것처럼 XFS는 훌륭한 파일 시스템입니다 (복잡한 경우). XFS의 더 좋은 유틸리티 중 하나 xfsdump는 전체 파일 시스템을 단일 파일로 덤프하고 일반적으로 할 수있는 것보다 훨씬 빠른 유틸리티 tar입니다. 파일 시스템 전용 유틸리티이므로 tar가 할 수없는 방식으로 fs internals를 활용할 수 있습니다.

아직 실행하고 있지 않은 경우 먼저 EXT4로 업그레이드하는 것이 좋습니다.

구글은 왜 EXT4가 좋은 아이디어인지에 대해 많은 연구를 해왔다 .

그런 다음 분산 파일 시스템 아키텍처를 배포해야합니다. 예를 들면 다음과 같습니다.

• http://www.xtreemfs.org/
• http://code.google.com/p/kosmosfs/
• http://hadoop.apache.org/hdfs/

아마도 간단한 대답 일 것입니다. 그러나 첫 번째 생각은 MongoDB에 내장 된 GridFS 와 같은 것을 사용하는 것이 었습니다 . 대부분의 주요 언어 드라이버는 기본 언어로 지원하므로 코드의 파일 읽기 섹션과 교체 할 수 있습니다. 또한 기존 디렉토리 경로에서 이러한 파일의 키를 만들 수 있습니다.

몽고가 디스크에서 항상 찾는 경우 속도가 매우 느려지는 문제가 있습니다. 천만 개의 파일이 있으면 대부분의 데이터가 디스크에있을 것으로 예상됩니다. 내가 기억 하듯이 GridFS의 파일 청크는 4MB이므로 파일이 크면 파일 하나를 얻기 위해 많은 비용이 드는 작업을 수행하게됩니다. 열쇠는 이미 깔끔한 디렉토리 구조를 기반으로 파일을 분할하여 여러 상자에서 여러 Mongo 인스턴스를 실행하여로드를 가볍게하는 것입니다. 그러나 성능 요구 사항이 무엇인지 잘 모르므로 지나치게 생각할 수 있습니다.

이 모든 것의 이점은 무엇입니까? 올바르게 수행되면 디스크 읽기와 거의 일치하는 성능입니다 . 또한 Mongo에는 데이터베이스가 계속 실행중인 경우에도 DB 인스턴스에서 전체 데이터를 신속하게 백업 할 수있는 몇 가지 기본 제공 방법이 내장되어 있습니다.

데이터 스토리지를위한 어플라이언스 모델에 만족한다면 NexentaStor를 고려할 수 있습니다. OpenSolaris에서 ZFS를 실행하지만 모든 관리는 웹 GUI를 통해 이루어집니다.

문제를 해결하는 데 도움이되는 몇 가지 기능이 있습니다.

• Enterprise 버전은 전체 파일 시스템을 통한 스캔이 필요없는 스냅 샷을 기반으로 한 원격 복제 형식을 지원합니다.

• 손이 더러워지지 않는다면 ZFS는 매우 편리한 ZFS diff 명령을 사용하여 전체 파일 시스템을 스캔하지 않고도 마지막 스냅 샷 이후에 추가, 수정 또는 삭제 된 파일을 효율적으로 알려줍니다. 이를 증분 백업을 수행하는 데 필요한 시간을 크게 줄이기 위해이를 백업 시스템에 통합 할 수 있습니다.

dump많은 파일로 EXT4 파일 시스템을 백업하기 위해 표준 유틸리티를 사용할 수 있습니다 . 이 유틸리티는 먼저 파일 시스템에서 사용되는 블록을 확인한 다음 디스크 순서대로 백업하여 대부분의 탐색을 제거합니다.

에 restore의해 생성 된 백업을 복원하기위한 해당 유틸리티가 dump있습니다.

마지막 레벨 0 (전체) 백업에서 수정 된 레벨 1 레벨 백업 파일, 레벨 1-레벨 1 백업에서 수정 된 레벨 등을 사용하여 레벨 증가 백업을 지원합니다.

증분 백업의 경우 새 덮개를위한 두 번째 섀도 트리를 갖는 옵션이 있습니다. 즉, 모든 읽기 작업에 사용되는 기본 트리가 있습니다. newfiles/012345.....jpg디렉토리 도 있습니다 . 새로 추가 된 표지는 기본 트리뿐만 아니라 여기에도 하드 링크를 만듭니다. 백업을 수행 할 때 기본 트리를 가끔 백업 할 수 있지만 훨씬 더 작은 newfiles트리를 훨씬 더 정기적으로 백업하십시오 .

newfiles기본 트리의 새 백업을 수행하기 전에 트리를 작게 유지하려면 새 파일 트리를 비울 수 있습니다.

mv newfiles newfiles_
mkdir newfiles
rm -rf newfiles_

물론이 작업을 수행하면 기본 트리의 새 백업을 생성 할 수 있습니다.

약간의 동시성을 추가하면 일반적으로 도움이됩니다.

나는 당신과 비슷한 문제가 있습니다. 내 경우에는 약 3 천만 개의 파일, 대부분 HTML, PHP 또는 JPEG 파일을 백업해야합니다. 나에게 BackupPC + ssh를 통한 rsync는 정상적으로 작동합니다. 전체 백업은 하루 정도 걸리지 만 증분은 보통 몇 시간 안에 완료됩니다.

비결은 BackupPC에서 복사 할 새 대상으로 각 기본 디렉토리 (0, 1, 2 ... a, b, c ...)를 추가하고 동시에 백업을 수행하도록하여 디렉토리를 동시에 백업하는 것입니다. a / , b / , c / * 등. 디스크 서브 시스템에 따라 몇 개의 프로세스 사이에서 약 10 개의 프로세스 사이에있는 것이 가장 빠른 백업 방법 일 것입니다.

LVM 스냅 샷 및 블록 수준 백업도 옵션이지만 BackuPC 및 파일 수준 백업을 사용하면 필요한 경우 여전히 개별 파일 또는 디렉토리를 복원 할 수 있습니다.

베냐민,

디렉토리 레벨 당 파일 수로 문제를 해결할 수 있다고 생각합니다!

디렉토리에 20 000 개의 파일을 저장하면 액세스 시간이 크게 변합니까?

또한 파일 시스템 메타 데이터를 SSD와 같은 별도의 빠른 액세스 드라이브에 저장하셨습니까?

대신 좋은 오래된 관계형 데이터베이스를 추천합니다.

이미지 데이터 bytea를 외부 저장소가있는 (이진) 열로, 파일 식별자를 기본 키로 사용하여 256 개의 분할 테이블 (cover_00, cover_01, ..., cover_ff)과 함께 PostgreSQL을 사용합니다 . 이미지 검색 속도가 빠르며 (기본 키의 인덱스 덕분에) 데이터 무결성이 보장되며 (ACID 호환 데이터베이스) 백업 순서는 디스크 순서이므로 너무 많은 검색이 필요하지 않습니다.