수억 개의 작은 파일을 효율적으로 저장합니다. 자체 호스팅 솔루션

커뮤니티 여러분, 이 글에서는 수억 개의 작은 파일을 효율적으로 저장하고 검색하는 방법에 중점을 둘 것입니다. 이 단계에서는 목발 없이도 클러스터 잠금을 포함하여 잠금을 완벽하게 지원하는 POSIX 호환 파일 시스템에 대한 최종 솔루션이 제안됩니다.

그래서 저는 이 목적을 위해 나만의 사용자 정의 서버를 작성했습니다.
이 작업을 구현하는 과정에서 우리는 주요 문제를 해결하는 동시에 클러스터 파일 시스템이 무자비하게 소비하고 있던 디스크 공간과 RAM을 절약했습니다. 실제로 이러한 수의 파일은 클러스터 파일 시스템에 해롭습니다.

아이디어는 다음과 같습니다.

간단히 말하면, 작은 파일은 서버를 통해 업로드되고, 아카이브에 직접 저장되기도 하고, 아카이브에서 읽어오기도 하며, 큰 파일은 나란히 배치됩니다. 구성표: 폴더 1개 = 아카이브 1개, 전체적으로 수억 개의 파일이 아닌 작은 파일이 포함된 수백만 개의 아카이브가 있습니다. 그리고 이 모든 것은 스크립트나 파일을 tar/zip 아카이브에 넣지 않고도 완벽하게 구현됩니다.

짧게 쓰도록 노력하겠습니다만, 글이 길다면 미리 사과드립니다.

이 모든 것은 기존 아카이브와 객체 스토리지에 내재된 단점 없이 HTTP 프로토콜을 통해 수신된 데이터를 직접 아카이브에 저장할 수 있는 적합한 서버를 세상에 찾을 수 없다는 사실에서 시작되었습니다. 그리고 검색을 하게 된 이유는 10대의 서버로 구성된 오리진 클러스터가 대규모로 성장해 이미 250,000,000억 XNUMX천만 개의 작은 파일이 축적되어 성장세가 멈추지 않을 것이기 때문이었습니다.

기사를 읽는 것을 좋아하지 않는 사람들에게는 약간의 문서가 더 쉽습니다.

여기에 и 여기에.

그리고 동시에 docker에서는 다음과 같은 경우에 대비하여 내부에 nginx만 포함하는 옵션이 있습니다.

docker run -d --restart=always -e host=localhost -e root=/var/storage 
-v /var/storage:/var/storage --name wzd -p 80:80 eltaline/wzd

다음 :

파일이 많으면 상당한 리소스가 필요하고, 그중 일부가 낭비되는 것이 가장 큰 문제입니다. 예를 들어 클러스터 파일 시스템(이 경우 MooseFS)을 사용하는 경우 파일은 실제 크기에 관계없이 항상 최소 64KB를 차지합니다. 즉, 크기가 3KB, 10KB 또는 30KB인 파일의 경우 디스크에 64KB가 필요합니다. 2억 개의 파일이 있는 경우 10~1테라바이트가 손실됩니다. MooseFS에는 각 파일의 복제본 하나에 XNUMX억 개를 넘지 않는다는 제한이 있으므로 새 파일을 무한정 생성하는 것은 불가능합니다.

파일 수가 증가할수록 메타데이터를 위해 많은 RAM이 필요합니다. 빈번한 대규모 메타데이터 덤프도 SSD 드라이브의 마모에 영향을 줍니다.

wZD 서버. 우리는 디스크에 물건을 정리했습니다.

서버는 Go로 작성되었습니다. 우선 파일 수를 줄여야 했습니다. 어떻게 하나요? 보관 때문에, 하지만 이 경우에는 압축하지 않았습니다. 왜냐하면 내 파일은 단지 압축된 사진이기 때문입니다. BoltDB가 구출되었지만 여전히 단점을 제거해야 했으며 이는 문서에 반영되어 있습니다.

전체적으로 10억 개의 파일 대신 제 경우에는 Bolt 아카이브가 1천만 개만 남았습니다. 만약 현재 디렉터리 파일 구조를 바꿀 기회가 생긴다면 대략 XNUMX만개 정도의 파일로 줄일 수 있을 것 같습니다.

모든 작은 파일은 Bolt 아카이브에 압축되어 해당 파일이 위치한 디렉토리의 이름을 자동으로 수신하고 모든 큰 파일은 아카이브 옆에 남아 있습니다. 압축할 필요가 없으며 사용자 정의가 가능합니다. 작은 것은 보관되고 큰 것은 변경되지 않습니다. 서버는 두 가지 모두와 투명하게 작동합니다.

wZD 서버의 아키텍처 및 기능.

서버는 Linux, BSD, Solaris 및 OSX 운영 체제에서 작동합니다. Linux에서는 AMD64 아키텍처에 대해서만 테스트했지만 ARM64, PPC64, MIPS64에서도 작동합니다.

주요 특징:

• 멀티스레딩;
• 내결함성과 로드 밸런싱을 제공하는 다중 서버
• 사용자 또는 개발자를 위한 최대 투명성
• 지원되는 HTTP 메소드: GET, HEAD, PUT 및 DELETE;
• 클라이언트측 헤더를 통해 읽기 및 쓰기 동작을 관리합니다.
• 고도로 구성 가능한 가상 호스트 지원
• 쓰기/읽기 시 CRC 데이터 무결성을 지원합니다.
• 최소한의 메모리 소비와 최적의 네트워크 성능 튜닝을 위한 반동적 버퍼
• 지연된 데이터 압축
• 또한 서비스를 중단하지 않고 파일을 마이그레이션할 수 있는 다중 스레드 아카이버 wZA가 제공됩니다.

실제 경험:

저는 오랫동안 라이브 데이터에 대한 서버와 아카이버를 개발하고 테스트해 왔으며 이제는 별도의 SATA 드라이브에 있는 250,000,000개의 디렉터리에 있는 15,000,000개의 작은 파일(그림)을 포함하는 클러스터에서 성공적으로 작동하고 있습니다. 10개 서버로 구성된 클러스터는 CDN 네트워크 뒤에 설치된 Origin 서버입니다. 이를 서비스하기 위해 Nginx 서버 2대 + wZD 서버 2대가 사용됩니다.

이 서버를 사용하기로 결정한 사람들은 사용하기 전에 해당되는 경우 디렉토리 구조를 계획하는 것이 좋습니다. 서버가 모든 것을 1 Bolt 아카이브에 담을 의도가 없다는 점을 즉시 예약하겠습니다.

성능 시험:

압축된 파일의 크기가 작을수록 GET 및 PUT 작업이 더 빠르게 수행됩니다. HTTP 클라이언트가 일반 파일과 Bolt 아카이브에 쓰고 읽는 데 소요되는 총 시간을 비교해 보겠습니다. 32KB, 256KB, 1024KB, 4096KB 및 32768KB 크기의 파일 작업을 비교합니다.

Bolt 아카이브로 작업할 때 각 파일의 데이터 무결성이 확인됩니다(CRC 사용). 기록 전과 기록 후에도 즉시 읽기 및 재계산이 발생하므로 당연히 지연이 발생하지만 가장 중요한 것은 데이터 보안입니다.

SATA 드라이브에 대한 테스트에서는 뚜렷한 차이가 나타나지 않기 때문에 SSD 드라이브에 대한 성능 테스트를 수행했습니다.

테스트 결과를 기반으로 한 그래프:

보시다시피 작은 파일의 경우 보관된 파일과 보관되지 않은 파일 간의 읽기 및 쓰기 시간 차이가 작습니다.

32MB 크기의 파일 읽기 및 쓰기를 테스트하면 완전히 다른 그림이 나타납니다.

파일 읽기 간의 시간 차이는 5-25ms 이내입니다. 녹음하면 상황이 더 나빠지며 차이는 약 150ms입니다. 하지만 이 경우 대용량 파일을 업로드할 필요가 없으며 그렇게 해도 아무런 의미가 없으며 아카이브와 별도로 존재할 수 있습니다.

*기술적으로 NoSQL이 필요한 작업에 이 서버를 사용할 수 있습니다.

wZD 서버 작업의 기본 방법:

일반 파일 로드:

curl -X PUT --data-binary @test.jpg http://localhost/test/test.jpg

Bolt 아카이브에 파일 업로드(아카이브에 포함될 수 있는 최대 파일 크기를 결정하는 서버 매개변수 fmaxsize가 초과되지 않은 경우, 이를 초과하면 파일이 평소와 같이 아카이브 옆에 업로드됩니다):

curl -X PUT -H "Archive: 1" --data-binary @test.jpg http://localhost/test/test.jpg

파일 다운로드(디스크와 아카이브에 이름이 같은 파일이 있는 경우 다운로드 시 기본적으로 아카이브되지 않은 파일에 우선순위가 부여됩니다):

curl -o test.jpg http://localhost/test/test.jpg

Bolt 아카이브에서 파일 다운로드(강제):

curl -o test.jpg -H "FromArchive: 1" http://localhost/test/test.jpg

다른 방법에 대한 설명은 설명서에 있습니다.

wZD 문서
wZA 문서

서버는 현재 HTTP 프로토콜만 지원하며 아직 HTTPS에서는 작동하지 않습니다. POST 메서드도 지원되지 않습니다(필요한지 여부는 아직 결정되지 않았습니다).

소스 코드를 파고드는 사람은 거기에서 버터스카치를 발견할 것입니다. 모든 사람이 그것을 좋아하는 것은 아니지만, 인터럽트 핸들러를 제외하고는 메인 코드를 웹 프레임워크의 기능에 연결하지 않았으므로 앞으로는 거의 모든 경우에 빠르게 다시 작성할 수 있습니다. 엔진.

할일 :

• 클러스터 파일 시스템 없이 대규모 시스템에서 사용할 수 있는 자체 복제기 및 배포자 + geo 개발(성인을 위한 모든 것)
• 메타데이터가 완전히 손실된 경우 전체 역복구 가능(배포자를 이용하는 경우)
• 다양한 프로그래밍 언어에 대해 지속적인 네트워크 연결 및 드라이버를 사용하는 기능을 위한 기본 프로토콜
• NoSQL 구성 요소 사용을 위한 고급 가능성
• Bolt 아카이브 내부의 파일이나 값 및 일반 파일에 대한 다양한 유형(gzip, zstd, snappy)의 압축
• Bolt 아카이브 내부의 파일 또는 값과 일반 파일에 대해 다양한 유형의 암호화
• GPU를 포함하여 지연된 서버 측 비디오 변환

나는 모든 것을 가지고 있습니다. 이 서버가 누군가에게 유용하기를 바랍니다. BSD-3 라이센스, 이중 저작권. 내가 일하는 회사가 없었다면 서버가 작성되지 않았을 것이기 때문입니다. 나는 유일한 개발자입니다. 버그나 기능 요청을 발견하시면 감사하겠습니다.

출처 : habr.com