수백만 개의 작은 파일에 대한 블록 크기

Debian Wheezy의 하드웨어 RAID1에 2x 4TB 디스크가 있습니다 (LSI MegaRaid 일 수 있음). 물리적 블록 크기는 4kB입니다. 150 ~ 2 억 개의 작은 파일 (3 ~ 10kB)을 저장하려고합니다. 성능을 요구하는 것이 아니라 스토리지를 절약 할 수있는 최상의 파일 시스템 및 블록 크기입니다. 8200 바이트의 파일을 4kB의 블록 크기를 가진 ext4에 복사했습니다. 이것은 32kB의 디스크를 필요로했다!? 저널링이 그 이유입니까? 그렇다면 작은 파일의 저장 공간을 절약하기 위해 어떤 옵션이 있습니까?

— 라 부드
소스

참조 : 나는 리눅스에 ext3 파티션의 블록 크기를 결정하는 방법은?

— Chris S

그 상황에 처한 경우 모든 데이터를 별도의 파일이 아닌 컴팩트 한 오프셋 기반 인덱스를 사용하여 단일 파일에 저장할 수있는 데이터베이스를 찾고 있습니다. 필요할 때 파일로 상호 작용할 수있는 FUSE 드라이버가있는 데이터베이스가 실제로는 별도의 파일이 아닐 수도 있습니다.

또는 파일 크기의 60-70 번째 백분위 수를보고 해당 파일 크기를 디스크의 별도 블록이 아닌 파일 시스템 트리 노드에 직접 맞추십시오. 각 노드에 10k를 저장하는 것이 큰 요청 일 수 있지만 거기에 파일의 60 % -70 %를 얻을 수 있다면 아마도 큰 승리 일 것입니다.

특정 파일 시스템만이 그렇게 할 수 있습니다 (reiserfs는 하나임). 백분위 수가 트리에 맞는지 여부에 따라 백분위 수의 크기에 달려 있다고 생각합니다. 조정할 수 있습니다. 나머지를 하나의 블록에 맞추려고합니다.

저널에 대해 걱정하지 마십시오. 어쨌든 크기 제한이 있습니다.

아니요 아니요 아니요 아니요 아니요 아니요 아니요 첫 번째 단락에는 없습니다. 나는 몇 년 전에이 실수를했고 나중에 취소해야했습니다. 이 디자인 패턴을 사용하는 시스템도 상속했습니다. 파일을 결합 해야하는 경우 파일은 파일 시스템에 속하거나 SQL Server FileStream 객체의 손상으로 간주 됩니다 (FUSE 드라이버 일 수도 있지만 아직은 아닙니다). 파일 시스템에서 작업 할 때 한 폴더에 4 백만 개의 파일을 넣지 않는 것과 같은 다른 고려 사항이 있습니다 (또한 실수했습니다).

— 마크 헨더슨

@MarkHenderson 그러나 문제는 파일이어야하는 것과 레코드 해야하는 것을 정의하는 것입니다. 더 자세한 정보를 제공하지 않으면 수억 개의 작은 것들이 레코드처럼 들립니다. 그가 현재 파일로 파일을 가지고 있다고해서 그런 식으로 남아 있어야한다고 생각하지는 않습니다. 또한, 나는 두 번째로 일을 위해 SQL Server를 사용하도록 제안하지 않았다;)

5 년 전 저는 단일 폴더에 백만 개의 파일과 매일 약 10,000 개의 새로운 1-4KB 파일을 가진 시스템을 물려 받았습니다. 나는 "이봐, 그들은 분석을위한 평범한 텍스트 일 뿐이야"라고 ISAM 테이블에 모두 던지기로 결정했습니다. 그리고 나서 처리 된 후 대부분 아무것도하지 않는 squillion 행이있는 단일 12GB 테이블이 있었기 때문에 큰 실수로 판명되었습니다. 그래서 파일 이름의 GUID를 기반으로 heirachial 폴더가있는 파일 시스템에 파일을 넣는 것으로 다시 전환했습니다.

— Mark Henderson

(스 쿼리 행이있는 단일 12GB 테이블이 왜 문제가 되었는가는 다른 문제였습니다.)

— Mark Henderson

@MarkHenderson : 그것은 다른 문제가 아닙니다. 그것이 왜 당신이 그것이 잘못된 해결책이라고 말한 이유입니다. 잘못된 데이터베이스 엔진 / 테이블 형식을 선택하지만 INDEX를 사용하여 작은 파일을 하나의 파일에 넣는 개념은 적절합니다. 당신이 원하는 것은 자동 샤딩을 통해 수백만 개의 작은 객체에 대해 키 / 값 저장소에서 뛰어난 데이터베이스입니다. 또한 그는 특히 성능, 공간에만 신경을 쓰지 않습니다.