GridFS는 생산을 위해 충분히 빠르고 안정적입니까?

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

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

nginx를 사용한 벤치 마크

이미 생산 환경에서 GridFS를 사용하는 사람이 있습니까? 아니면 새 프로젝트에 사용할 사람이 있습니까?

나는 명예로운 트래픽 통계 (하루 약 25,000 명의 방문자)를 가진 가격 비교 웹 사이트의 일부인 서버 중 하나에서 gridfs를 사용합니다. 서버에는 램, 2 기가 많지 않고 CPU도 실제로 빠르지는 않지만 (Core 2 duo 1.8Ghz) 서버에는 충분한 저장 공간이 있습니다. RAID 0 구성에서 10Tb (sata)입니다. 서버가 수행하는 작업은 매우 간단합니다.

가격 비교기의 각 제품에는 이미지가 있으며 (제품 DB에 따라 약 천만 개의 제품이 있음) 서버 작업은 이미지를 다운로드하고 크기를 조정 한 다음 gridfs에 저장하고 방문자 브라우저에 전달하는 것입니다. .. 그리드에없는 경우 ... 또는 ... 그리드에 이미 저장되어있는 경우 방문자 브라우저에 전달합니다. 따라서 이것은 '전통적인 cdn 스키마'라고 부를 수 있습니다.

이 서버가 실행 중이기 때문에이 서버에 4 백만 개의 이미지를 저장하고 처리했습니다. 크기 조정 및 저장 작업은 간단한 PHP 스크립트로 수행됩니다.하지만 확실하게 Python 스크립트 또는 Java와 같은 것이 더 빠를 수 있습니다.

현재 데이터 크기 : 11.23g

현재 저장 용량 : 12.5g

지수 : 5

색인 크기 : 849.65m

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

속도 정보 : 확실히 로컬 파일 저장소만큼 빠르지 않고 10 % 정도 느리지 만 이미지를 처리해야 할 때에도 실시간으로 사용할 수있을만큼 빠릅니다. 우리의 경우는 매우 PHP에 따라 다릅니다. 유지 관리 및 개발 시간도 단축되었습니다. 단일 또는 여러 이미지를 삭제하는 것이 매우 간단 해졌습니다. 간단한 삭제 명령으로 db를 쿼리하기 만하면됩니다. 또 다른 흥미로운 점 : 로컬 파일 저장소 (수천 개의 폴더에있는 수백만 개의 파일)를 사용하여 이전 서버를 재부팅했을 때 시스템이 파일 무결성 검사를 수행하기 때문에 때때로 몇 시간 동안 중단됩니다 (정말 몇 시간이 걸렸습니다 ...). gridfs에서는 더 이상이 문제가 발생하지 않습니다. 이제 이미지가 큰 mongodb 청크 (2GB 파일)에 저장됩니다.

그래서 ... 내 마음에 ... 예, gridfs는 프로덕션에 사용할 수있을만큼 빠르고 안정적입니다.

언급했듯이 일반 파일 시스템만큼 빠르지는 않지만 일반 파일 시스템에 비해 사람에게 이점을 제공합니다. 약간의 속도를 포기할 가치가 있다고 생각하는 제공합니다.

궁극적으로 샤딩을 사용하면 GridFS 스토리지가 일반 파일 시스템 및 단일 노드와 달리 실제로 더 빠른 옵션이되는 지점에 도달 할 수 있습니다.

하지만 더 큰 DB의 수리에 대한주의-우리가 개발중인 새로운 시스템, mongo는 깨끗하게 종료되지 않았으며 7TB GridFS를 수리하는 데 130 시간이 걸릴 것으로 보입니다.

이 때문에 OpenStack Swift 또는 Ceph로 전환하는 방법을 살펴 보겠습니다. 그래도 그때까지는 좋았습니다. 그리고 nginx-gridfs 모듈은 훌륭합니다.

mdirolf의 nginx-gridfs 모듈은 훌륭하고 설정하기 매우 쉽습니다. 우리는 paint.ly의 프로덕션에서 모든 그림을 제공하기 위해 그것을 사용하고 있으며 지금까지 아무런 문제가 없었습니다.

나는 당신이 무엇을하고 있는지 알지 못한다면 gridfs를 사용하지 않는 것이 좋습니다. GridFS는 파일을 청크로 분할하고 파일을 두 개의 컬렉션에 저장하는 추상화 계층입니다. 더 많은 파일-더 많은 오버 헤드. 파일이 32M 정도를 넘지 않고 같은 크기로 예상된다면 올바른 방법입니다. gridfs에 큰 파일을 저장하지 마십시오. 왜?

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

로드 된 프로젝트 읽기에 대해 생각하는 경우-파일을 문서에 직접로드하거나 (16M 이하인 경우) 다른 clusterfs를 선택하고 파일 이름 / inode를 논리에 연결하십시오.

도움이 되었기를 바랍니다.