확장 가능한 이미지 스토리지

확장 가능한 이미지 스토리지

---

저는 현재 일종의 이미지 저장소도 제공해야 하는 웹 기반 응용 프로그램용 아키텍처를 설계하고 있습니다. 사용자는 서비스의 주요 기능 중 하나로 사진을 업로드할 수 있습니다. 또한 이러한 이미지를 보는 것이 (웹을 통해) 주요 용도 중 하나가 될 것입니다.

그러나 내 애플리케이션에서 이러한 확장 가능한 이미지 스토리지 구성 요소를 구현하는 방법을 잘 모르겠습니다. 나는 이미 다른 해결책에 대해 생각했지만 경험이 없기 때문에 제안을 듣기를 기대합니다. 이미지 외에도 메타 데이터도 저장해야 합니다. 내 초기 생각은 다음과 같습니다.

1. 업로드된 이미지 및 서비스 요청을 저장하기 위해 HDFS와 같은 (분산) 파일 시스템을 사용하고 전용 웹 서버를 "파일 시스템 클라이언트"로 준비합니다. 이미지 메타 데이터는 각 이미지에 대한 파일 경로 정보를 포함하는 추가 데이터베이스에 저장됩니다.

2. HDFS 위에 HBase와 같은 BigTable 지향 시스템을 사용하고 이미지와 메타 데이터를 함께 저장합니다. 다시 말하지만, 웹 서버는 이미지 업로드와 요청을 연결합니다.

3. 이미지와 메타데이터를 모두 저장하기 위해 CouchDB와 같은 완전히 스키마가 없는 데이터베이스를 사용합니다. 또한 HTTP 기반 RESTful API를 사용하여 업로드 및 전달을 위해 데이터베이스 자체를 사용합니다. (추가 질문: CouchDB는 Base64를 통해 blob을 저장합니다. 그러나 이미지/jpeg 등의 형태로 데이터를 반환할 수 있습니까?)

---

이를 위해 CouchDB를 사용하여 이미지를 "첨부 파일"로 저장했습니다. 그러나 1년 후 수십 GB CouchDB 데이터베이스 파일이 골치 아픈 것으로 판명되었습니다. 예를 들어 매우 큰 문서 크기와 함께 사용하는 경우 CouchDB 복제에는 여전히 문제가 있습니다.

그래서 우리는 이미지 정보에 CouchDB를 사용하고 실제 이미지 저장에 Amazon S3를 사용하도록 소프트웨어를 다시 작성했습니다. 코드는 http://github.com/hudora/huImages 에서 사용할 수 있습니다.

프로젝트에 대해 현장에서 Amazon S3 호환 스토리지 서비스를 설정할 수 있습니다. 이렇게 하면 유연성을 유지할 수 있으며 현재로서는 외부 서비스가 필요하지 않고 Amazon 옵션을 떠날 수 있습니다. Walruss 는 가장 인기 있고 확장 가능한 S3 클론이 된 것 같습니다.

또한 뛰어난 오픈 소스 MogileFS 및 Perlbal 제품 으로 Livejournal의 디자인을 살펴보시기 바랍니다 . 이 조합 은 아마도 가장 유명한 이미지 제공 설정일 것입니다.

또한 flickr Architecture 는 Livejournal과 같이 공개 소스 소프트웨어를 대중에게 제공하지 않지만 영감을 줄 수 있습니다.

---

"추가 질문: CouchDB는 Base64를 통해 얼룩을 저장합니다."

CouchDB는 Blob을 Base64로 저장 하지 않고 스트레이트 바이너리로 저장합니다. JSON 문서를 검색할 때 JSON에 ?attachments=true안전하게 추가하기 위해 온디스크 바이너리를 Base64로 변환하지만 이는 프레젠테이션 수준의 문제일 뿐입니다.

독립형 첨부 를 참조하십시오 .

CouchDB는 저장된 콘텐츠 유형의 첨부 파일을 제공하며, 실제로 일반적으로 HTML, CSS 및 GIF/PNG/JPEG 첨부 파일을 브라우저에 직접 서버에 보내는 것이 가능합니다.

첨부 파일을 스트리밍할 수 있으며 CouchDB 1.1에서는 Range 헤더도 지원합니다(미디어 스트리밍 및/또는 중단된 다운로드 재개용).

---

사용 해초-FS (위드 FS 호출하는 데 사용), 페이스 북의 건초 더미 종이의 구현입니다.

Seaweed-FS는 매우 유연하며 기본에 충실합니다. 수십억 개의 이미지를 저장하고 빠르게 제공하기 위해 만들어졌습니다.

---

Amazon Web Services를 고려해 보셨습니까? S3는 웹 기반 파일 저장소이고 SimpleDB는 키->속성 저장소입니다. 둘 다 성능이 뛰어나고 확장성이 뛰어납니다. 자체 서버 및 설정을 유지 관리하는 것보다 비용이 많이 들지만(사용자를 고용하지 않고 직접 수행한다고 가정) 훨씬 더 빨리 시작하고 실행할 수 있습니다.

편집: 나는 그것을 다시 가져옵니다. 대량으로 장기적으로 더 비싸지 만 소량의 경우 하드웨어 구입의 초기 비용을 능가합니다.

S3: http://aws.amazon.com/s3/ (여기에 이미지 파일을 저장할 수 있으며 성능을 위해 서버에 이미지 캐시가 있거나 없을 수 있음)

SimpleDB: http://aws.amazon.com/simpledb/ (메타데이터는 여기로 이동할 수 있습니다: 저장하려는 데이터에 대한 이미지 ID 매핑)

편집 2: 저도 몰랐는데 Amazon CloudFront( http://aws.amazon.com/cloudfront/ ) 라는 새로운 웹 서비스가 있습니다. 빠른 웹 콘텐츠 전달을 위한 것으로 S3와 잘 통합됩니다. 이미지의 경우 Akamai와 비슷합니다. 이미지 캐시 대신 이것을 사용할 수 있습니다.

---

MogileFS를 사용합니다. 우리는 8TB 미만이고 약 5천만 개의 파일이 있는 소규모 사용자입니다. 파일 이름과 성능을 더 잘 제어하기 위해 몇 년 전에 Amazon S3에 저장하는 것으로 전환했습니다.

가장 멋진 소프트웨어는 아니지만 매우 "현장 테스트"되었으며 기본적으로 모든 사용자가 동일한 방식으로 사용하고 있습니다.

---

Facebook hayStack에 대한 설명을 살펴보십시오.

건초 더미의 바늘: 수십억 장의 사진을 효율적으로 저장

---

Cloudant의 일부로 제품을 푸시하고 싶지는 않습니다. 하지만 BigCouch는 내 과학 응용 프로그램 스택에서 이 문제를 해결합니다(물리학 -- Cloudant와 관련이 없으며 확실히 이익과 관련이 없습니다!). 단일 서버 CouchDB에서 누락된 자동 샤딩 및 확장성과 함께 CocuhDB 설계의 단순성을 결합합니다. 나는 일반적으로 적은 수의 큰 파일(multi-GB)과 많은 수의 작은 파일(100MB 이하)을 저장하는 데 사용합니다. S3를 사용하고 있었지만 실제로 반복적으로 액세스하는 작은 파일에 대해 가져오기 비용이 합산되기 시작했습니다.

---

모든 AWS 기능이 작동하지 않을 경우 몇 가지 생각을 해볼 수 있습니다.

(3)만큼 바이너리 데이터를 데이터베이스에 넣으면 같은 데이터가 나온다. 그것을 jpeg로 만드는 것은 데이터베이스가 생각하는 것이 아니라 데이터의 형식입니다. 클라이언트(웹 브라우저)가 jpeg라고 생각하게 만드는 것은 Content-type헤더를 로 설정할 때 image/jpeg입니다. 또한 텍스트와 같은 다른 것으로(권장되지 않음) 설정할 수 있으며 이것이 브라우저가 해석을 시도하는 방식입니다.

온디스크 스토리지의 경우 단순성 때문에 CouchDB를 좋아하지만 HDFS는 확실히 작동합니다. 다음은 CouchDB의 이미지 콘텐츠 제공에 대한 게시물 링크입니다. http://japhr.blogspot.com/2009/04/render-couchdb-images-via-sinatra.html

편집: memcached에서 이미지를 캐싱하는 것과 linux/apache에서 디스크에서 이미지를 제공하는 것에 대한 유용한 토론에 대한 링크가 있습니다.

---

저는 Python 보기 서버의 CouchDB 보기 서버에서 사용할 수 있는 _update 기능 중 일부를 실험해 왔습니다.

내가 한 정말 멋진 일 중 하나는 PIL을 사용하여 썸네일 및 기타 관련 이미지를 만들고 CouchDB에 푸시될 때 문서에 첨부할 수 있도록 이미지 업로드를 위한 업데이트 기능이었습니다.

이는 이미지 조작이 필요하고 따라가야 하는 코드와 인프라의 양을 줄이려는 경우에 유용할 수 있습니다.

---

나는 cassandra 위에 이미지 저장소를 작성했습니다. 우리는 많이 있고 쓰기 및 임의 읽기 읽기/쓰기가 낮습니다. 높은 읽기/쓰기 비율을 위해서는 You mongodb(GridFs)를 제안합니다.

---

다음은 PHP Laravel을 사용하여 CouchDB에 Blob 이미지를 저장하는 예입니다. 이 예에서는 사용자 요구 사항에 따라 세 개의 이미지를 저장하고 있습니다.

CouchDB에서 연결 설정.

$connection = DB::connection('your database name');

/*region Fetching the Uers Uploaded Images*/

$FirstImage = base64_encode(file_get_contents(Input::file('FirstImageInput')));
$SecondImage =base64_encode(file_get_contents(Input::file('SecondImageInput')));
$ThirdImage = base64_encode(file_get_contents(Input::file('ThirdImageInput')));

list($id, $rev) = $connection->putDocument(array(
    'name' => $name,
    'location' => $location,
    'phone' => $phone,
    'website' => $website,
    "_attachments" =>[
        'FirstImage.png' => [
            'content_type' => "image/png",
            'data' => $FirstImage
        ],
        'SecondImage.png' => [
            'content_type' => "image/png",
            'data' => $SecondImage
        ],
        'ThirdImage.png' => [
            'content_type' => "image/png",
            'data' => $ThirdImage
        ]
    ],
), $id, $rev);

...

단일 이미지를 저장할 수 있는 것과 동일합니다.

ReferenceURL : https://stackoverflow.com/questions/1961191/scalable-image-storage