-4

個人的な使用のために、独自の Web ページのサムショット クラウド サービスを構築したいと考えています。4,000,000,000 個以上の小さな画像 (10KB) を用意する予定です。Amazon S3 のような外部サービスは使用したくありません。独自のクラウドを構築したいと考えています。

それをどのように保存し、スケーラブルに保ちますか? たとえば、cassandra 分散データベースや GlusterFS ファイルシステムに...

HTTP を介してどのように効率的にサービスを提供しますか? たとえば、cassandra データベースを読み取る多くの http サーバーに nginx ロード バランサーを使用します。

4

5 に答える 5

2

あなたの質問は漠然としており、十分に調査および形成されていませんが、ここにいくつかの指針を示します。

私的な使用のための親指ショット クラウド サービス。

これがあなた自身の個人的な使用のためのものである場合、データベースをまったく使用しないことを強くお勧めしますが、代わりに、高いネットワーク使用率と IO 読み取りに合わせて特別に調整された High IOPs SSD でバックアップされたクラスター (サーバーのセット) 上のファイル システムを使用することを強くお勧めします。

注: これは急速に拡大し、S3 などの外部サービスよりもはるかに高価になります。

それをどのように安全に保管しますか (40 TB が必要です)。

これは少し広範であり、その音による実際の調査が不足していますが、Web アプリ側から保護し、Web アプリのみが画像へのアクセスを許可されていることを示すルールを画像サーバーのファイアウォールに入れることができます。次に、Web アプリで、画像の使用を保護するためのルールを設定します。

HTTP を介してどのように効率的にサービスを提供しますか?

サーバー上 (Web アプリ内) の Varnish などの形式と、無限の有効期限 (おそらく) を追加することによるブラウザー内の両方で、キャッシング メカニズムを使用します。

もちろん、「最適な」キャッシング メカニズムは、Web サーバーと使用法 (Nginx や Apache など) によって異なります。

これは、あいまいで広すぎる質問に対する基本的な回答です。いくつかの調査を行い、使用したいサーバーを介して画像を提供することを検討することを強くお勧めします.

于 2013-03-20T14:47:21.510 に答える
1

さて、最大の問題はそのような容量のストレージを見つけることですが、見つけたとしても、通常のデータベースではそのような量のデータを処理できるとは思わないので、保存するためのカスタムソリューションを作成する必要があります/読む。とにかく、元の問題を説明できれば、40億枚の画像を処理することは現実的ではないため、そのような量の画像を保存する必要のない他の実際の解決策があるかもしれません。

于 2013-03-20T14:45:26.250 に答える
0

ブロブ(Binary Large OBjectS)を使用する必要があると思います。Google App Engineのブロブストアを検討しましたか?BLOBに慣れていない場合は、クラウドコンピューティングと画像サービスを開始するための優れた安価な方法です。Python、Java、またはGoogleの新しいコンパイル言語goでblobhandlingをプログラムできます。GAEを使用すると、アプリケーションですべてを実行できるようになり、ハードドライブやオペレーティングシステムについて心配する必要がなくなります。独自のスタックを作成する場合は、サービスプロバイダーがサポートしているクラスタリングの種類を確認する必要があります。

于 2013-03-20T18:11:50.110 に答える
0

このように聞こえるかもしれません: http ://docs.basho.com/riakcs/latest/

オープンソースであり、独自のS3を構築するために明示的に設計されています

于 2013-03-21T15:16:55.230 に答える
0

OpenStack Swiftは、RackspaceとWikimediaが数百万の画像を保存するために使用するオブジェクトストレージプロジェクトです。

http://docs.openstack.org/developer/swift/

于 2013-03-21T17:34:03.017 に答える