16

私たちは、サイズが 8KB から 500KB までさまざまで、中央値が約 15KB、平均が 30KB の (1 桁の) 何百万もの画像を格納するシステムを持っています。現在、データ セットの合計は約 100 GB です。画像のハッシュに基づいて画像にアクセスします (これは変更できますが、画像が既にデータ ストアに効率的に存在するかどうかを確認する目的で、画像から計算可能である必要があります。画像は、2 つのイメージは、バイト単位で同一である場合、ピクセル単位で同一です)。永続性は (明らかに) 重要です。

現時点では、それらすべてをディレクトリ内のファイルとして保存します — ディレクトリのリストはカーネルによってキャッシュされ、実際のファイル読み取りは必要に応じて行われます。私が理解しているように、キー値ストアの主な利点 (ファイルシステムを 1 つとして使用する場合と比較して) は、単一の値ではなく、ページ全体をキャッシュできるため、より小さな値を読み取ることです。現在、すべてのアクセスはデータと同じサーバー上の Web サーバー (イントラネット上) から行われていますが、キーがリモート マシン (主に 10GbE 経由で接続) から存在するかどうかを確認するように移行する可能性があります。

これを変更する特別な理由はありませんが、システムの他の主要部分が変更されているため、現在のアプローチを再検討する価値があるようです。

頻繁な書き込み (1:10 程度の書き込み:読み取り) に加えて、読み取りが主に (単一の) 挿入順序での読み取りであり、任意のキーへのランダムな (ただし、繰り返し行われる可能性が非常に高い) アクセスであるワークロードを考えると、可能性は高いですか?ファイルシステムからキーバリュー ストアに移行する利点はありますか?

4

4 に答える 4

14

概要: データの整合性、永続性、サイズ、速度の要件については、Redisをお勧めします。

素敵な紹介プレゼンテーションがここで見られます:
https://simonwillison.net/static/2010/redis-tutorial/

nbより多くの情報が役立ちますが、あなたが提供したものと私が知っていることに基づいて、主なプレーヤーの一部を次に示します。

Memcached:
https://memcached.org/
動的な Web アプリケーションの高速化に適した、無料でオープン ソースの高パフォーマンスの分散メモリ オブジェクト キャッシュ システム。
+ Web アプリケーション、無料、オープン ソースに適しています。
-サーバーがダウンすると (memcached プロセスの障害またはシステムの再起動)、すべてのセッションが失われます。より高い (商用利用) レベルでのパフォーマンスの制限。

Redis:
https://redis.io/
memcached に似ていますが、データの永続性を備えており、複数の値の種類、アトミック インクリメント/デクリメントおよび組み込みのキー有効期限を備えたカウンターをサポートしています。
+データをディスクに保存するため、失われることはなく、非常にシンプルで、速度、柔軟性 (キーには文字列、ハッシュ、リスト、セット、およびソートされたセットを含めることができます)、シャーディング、個人ではなく vmware によって維持されます。
-限られたクラスタリング。

LevelDB:
https://google-opensource.blogspot.com/2011/07/leveldb-fast-persistent-key-value-store.html
文字列キーを文字列値にマップする、Google で作成された高速なキー値ストレージ エンジン。
+グーグル。
- ? Google + で可能 ;)

TokoyoCabinet:
https://fallabs.com/tokyocabinet/
ロック、ACID トランザクション、バイナリ配列データ型のサポートが含まれています。
+ スピードと効率。
- 米国など一部の地域ではあまり知られていない

Project Voldemort:
https://project-voldemort.com/
Java で記述された高度なキー値ストア。更新のためのマルチバージョン同時実行制御 (MVCC) を提供します。レプリカの更新は非同期で行われるため、データの一貫性は保証されません。
+機能性
-一貫性

MongoDB:
https://www.mongodb.org/
スケーラブルで高性能なオープン ソースのドキュメント指向データベース。C++ で書かれており、LAN と WAN 間のミラーリングと自動シャーディングを備えたレプリケーションと高可用性を備えています。Ruby on Rails コミュニティで人気があります。
+簡単なインストール、優れたドキュメント、サポート。
-比較的新しい。

Couch:
http://www.couchdb.org/
Mongo に似ており、ドキュメント データベースを対象としています。
+レプリケーション、高度なクエリ。
-クラスタリング、ディスク容量管理。

Cassandra:
https://cassandra.apache.org/
Apache Cassandra はフォールト トレラントで分散化されており、Netflix、Twitter、Reddit などで使用されています。
+クラスターとレプリケーション。
-より多くの設定知識が必要です。

時間がないので全てを紹介できませんが、参考になれば幸いです。

于 2011-11-25T14:24:09.823 に答える
11

応じて

  • ファイル数
  • FS でそれらをどのように構成するか
  • 使用しているFS
  • 使用しているストレージの種類

inode が不足するか、ファイルへのアクセスが再び遅くなる可能性があります (たとえば、1 つのディレクトリにあまりにも多くのエントリを入れた場合など)。

また、ファイルへのアクセス (および/またはディレクトリの作成) にアトミックに少し注意を払う必要がありますが、通常は KV ストアがそれを処理します。

fs-as-key-value-store アプローチでは、過去にこれらすべてに問題がありました:)。

しかし、それは可能です。たとえば、redis の作成者自身によるディスク上のファイルとしての redis KV プロトコルの実装であるBigdisを参照してください。ただし、ops には少し注意する必要があります。

問題によっては、MogileFSまたはストレート クラウド S3 がより良い解決策になる場合があります。

于 2011-11-26T10:02:14.823 に答える
2

提供する情報が少なすぎるため、具体的な回答を得ることができません。したがって、説明する内容に関連するいくつかの側面があります。

  • データの整合性
    これは何でもかまいません。つまり、不正なデータ変更を禁止するか、少なくともそのようなインシデントを検出する必要があります...または「RAIDおよび/またはバックアップ...」の領域にあるものである可能性があります。

  • 「同一の画像」
    画像ファイルには、いくつかのメタデータフィールド/領域が含まれています...一方にメタデータがあり、もう一方にメタデータがない（または一部のメタデータフィールドが異なる）場合、2つのピクセルごとに同一の画像が異なるものとして表示されます...それはあなたが望むものですか？
    この分野の別の側面は、ファイル形式（PNG対BMP対JPEGなど）と圧縮です...同じ画像と異なる形式および/または圧縮アルゴリズム（ZIP対LZWのようなロスレスのものでさえ、JPEGなどで悪化する可能性があります）同じ画像を別のものとして分類します-それはあなたが望むものですか？

  • 「数十万の画像」と「2KB-10MB」
    はあまり意味がありません...つまり、画像/ファイルサイズの中央値と平均値はどれくらいですか？

  • アクセス
    これらのファイル/イメージへのアクセスは（CDNのように）分散されていますか？それともLANベースですか？

あなたが説明することに関連する他の数十の側面があります...

さらに具体的な情報がなければ、統計/ベンチマーク/推奨事項はせいぜい幸運なショットだと思います。

考えられる解決策には、たとえば分散システム（ファイルシステム-/メモリ-/ DBベース）および/またはSSDおよび/またはRAIDおよび/またはSANなどに基づくストレージが含まれます。

あなたが興味を持っている「KeyValueStore」ポイントは関連している可能性がありますが、ほとんどの場合、私がそのようなストアに出くわしたこの量の画像を処理しても、独自の機能は追加されません（場合によっては傷つくことさえあります）。

于 2011-11-23T11:36:17.907 に答える