programing

GridFS는 실전 가동에 충분한 속도와 신뢰성을 갖추고 있습니까?

lastmoon 2023. 4. 2. 11:48
반응형

GridFS는 실전 가동에 충분한 속도와 신뢰성을 갖추고 있습니까?

새로운 웹 사이트를 개발했는데 GridFS를 일반 파일 시스템 스토리지에 비해 많은 이점을 제공하기 때문에 모든 사용자 업로드를 위한 스토리지로 사용하고 싶습니다.

nginx가 제공하는 GridFS를 사용하는 벤치마크는 nginx가 제공하는 일반 파일 시스템만큼 빠르지 않음을 나타냅니다.

nginx를 사용한 벤치마크

실제 가동 환경에서 GridFS를 이미 사용하고 있거나 새로운 프로젝트에 GridFS를 사용하고 있는 사람이 있습니까?

저는 회사에서 gridf를 사용하고 있습니다.gridf는 우수한 트래픽 통계(하루 방문자 수 25,000명)가 있는 가격 비교 웹 사이트의 일부입니다.서버의 RAM은 2기가바이트도 많지 않고 CPU의 속도도 그다지 빠르지 않지만(Core 2 duo 1.8Ghz), raid 0 구성의 경우 10 Tb(sata)의 스토리지 용량이 충분합니다.서버가 수행하는 작업은 매우 간단합니다.

가격 비교의 각 제품에는 이미지가 있습니다(제품 DB에 따르면 약 1000만 개의 제품이 있습니다).서버 작업은 이미지를 다운로드하여 크기를 조정하고 그리드프에 저장한 후 방문자 브라우저에 전달하는 것입니다.그게 그리드에 없다면... 아니면...이미 그리드에 저장되어 있는 경우 방문자 브라우저로 전달합니다.이를 '기존 cdn 스키마'라고 부릅니다.

이 서버는 가동되고 있기 때문에 400만 개의 이미지를 저장하고 처리했습니다.크기 조정 및 저장 작업은 단순한 php 스크립트로 수행됩니다.python 스크립트나 java 같은 것이 더 빠를 수 있습니다.

현재 데이터 크기: 11.23g

현재 스토리지 크기: 12.5g

인덱스: 5

인덱스 크기: 849.65m

신뢰성에 대해서: 이것은 매우 신뢰성이 있습니다.서버가 로드되지 않고, 인덱스 크기가 정상이며, 쿼리가 빠릅니다.

속도에 대해서: 확실히 로컬 파일 스토리지로서는 빠르지 않고, 아마 10% 느리지만, 이미지를 처리해야 할 때에도 실시간으로 사용할 수 있을 만큼 빠릅니다.이 경우 php에 매우 의존합니다.유지보수 및 개발 시간도 단축되었습니다.하나 또는 여러 이미지를 쉽게 삭제할 수 있습니다.단순한 delete 명령으로 db를 조회하기만 하면 됩니다.또 다른 흥미로운 점은 로컬 파일 스토리지(수천 개의 폴더 안에 수백만 개의 파일)를 사용하여 오래된 서버를 재부팅했을 때 시스템이 파일 무결성 검사를 수행하고 있었기 때문에 서버가 몇 시간 동안 중단되는 경우가 있다는 것입니다(이 작업은 실제로 몇 시간이 걸렸습니다).gridf에서는 이 문제가 없어졌습니다.이미지는 큰 mongodb 청크(2GB 파일)에 저장됩니다.

그래서... 내 머릿속에는...네, gridf는 프로덕션에서 사용할 수 있을 만큼 빠르고 안정적입니다.

앞에서 설명한 것처럼 일반 파일 시스템만큼 빠르지 않을 수도 있지만, 그러면 일반 파일 시스템보다 더 많은 이점을 얻을 수 있습니다.이러한 파일 시스템은 조금 더 속도를 낼 가치가 있다고 생각합니다.

결국 샤딩을 사용하면 GridFS 스토리지가 일반 파일 시스템 및 단일 노드가 아닌 더 빠른 옵션이 될 수 있습니다.

대규모 DB 복구에 대한 경고입니다. 개발 중인 새로운 시스템은 mongo가 완전히 종료되지 않았으며 7TB GridFS를 복구하는 데 130시간이 걸릴 것으로 보입니다.

그래서 OpenStack Swift나 Ceph로 바꾸려고 합니다.그래도 그때까지는 괜찮았어요.그리고 nginx-gridfs 모듈은 달콤합니다.

mdirolf의 nginx-gridfs 모듈은 훌륭하고 셋업이 매우 쉽습니다.우리는 모든 그림을 제공하기 위해 paint.ly에서 제작에 사용하고 있으며, 현재까지 아무런 문제가 없습니다.

자신이 무엇을 하고 있는지 모르는 한 gridf를 사용하는 것은 권장하지 않습니다.GridFS는 청크의 파일을 분할하여 2개의 컬렉션에 저장하는 추상화 레이어입니다.파일 수가 많을수록 오버헤드가 커집니다.파일 크기가 32M을 넘지 않는 매우 동일한 파일이라면 올바른 방법입니다.큰 파일을 gridf에 저장하려고 하지 마십시오. 왜일까요?

  1. 다른 언어의 드라이버가 파일의 작은 부분을 읽을 때 파일 전체를 읽을 수 있습니다.(예를 들어, 청크).
  2. 파일을 수정하면 모든 청크에 영향을 미쳐 데이터베이스 로드가 증가할 수 있습니다.파일 시스템이 성장 중인 경우 gridfs를 샤드할 것을 결정해야 합니다.조심해!샤딩 초기화 시 일관성이 보장되지 않습니다!

읽기 로드된 프로젝트를 고려하는 경우 파일을 직접 문서에 로드하거나(16M 이하의 크기인 경우) 다른 clusterfs를 선택하여 파일 이름/inode를 로직에 링크하는 것을 고려해 보십시오.

이게 도움이 됐으면 좋겠다.

언급URL : https://stackoverflow.com/questions/3413115/is-gridfs-fast-and-reliable-enough-for-production

반응형