ドキュメントストアデータベースとしてのHadoop

Question

現在、3TBのスペースで実行されている大きなドキュメントストアがあり、6か月ごとに1TBずつインクリメントします。現在、Windowsファイルシステムに格納されており、アクセスや検索の面で問題が発生しています。私たちは、Haddopベースのドキュメントストアデータベースを活用しようとしています。 Haddopを進めることは良い考えですか？誰もが同じことに暴露している？挑戦、同じものを達成する際の技術的な障壁は何か？

Answer 1

Hadoopは、データアクセスが高いバッチ処理に適しています。ドキュメント指向のデータベースのようないくつかのNoSQLシステムを見てください。あなたのデータが何であるかを知らなくても答えにくいです。

NoSQLデザインの第1のルールは、クエリシナリオを最初に定義することです。データのクエリ方法を理解したら、さまざまなNoSQLソリューションを調べることができます。デフォルトの配布単位が鍵です。したがって、ノード・マシン間でデータを効率的に分割できる必要があることを覚えておく必要があります。そうしないと、横方向にスケーラブルなシステムになりますが、すべての作業は1つのノードで行われます。

また、従来のリレーショナルDBMSがCAであるのに対して、ほとんどのNoSQLデータベースは最終的に一貫性があり（CPまたはAP）、CAP定理に戻って考える必要があります。これは、データの処理方法や特定のものの作成に影響を与えます。たとえば、キーの生成は厄介なものになります。明らかに、フォルダ内のファイルは少し異なります。

また、HBaseなどの一部のシステムでは、インデックス作成の概念がないことに注意してください（このWindows FSドキュメントストアにファイルインデックス設定があります）。すべての索引はアプリケーション・ロジックによって構築する必要があり、更新や削除はそのように管理する必要があります。 Mongoを使用すると、実際にフィールドにインデックスを作成して比較的早くクエリを実行できます。また、SolrをMongoに統合することも可能です。基本的にネストされたキーと値のペアがある列ファミリ（別名Google BigTableスタイルのデータベース）であるHBaseのように、MongoのIDでクエリするだけでなく、

あなたのデータ、保存したいもの、保存する方法、最も重要なのはアクセス方法です。 Lilyプロジェクトは非常に有望です。私は、ウェブから大量のデータを取り込み、それを分析し、分析し、分析し、分析し、ストリームし、更新するなど、私たちは関与しています。現在の仕事に最も適しています。このプロセスでは、さまざまなシステムをさまざまな段階で使用して、必要な場所に素早くアクセスし、リアルタイムでデータをストリーミングおよび分析し、重要なことにすべてを追跡します（データ損失システムは大したことです）。私はHadoop、HBase、Hive、MongoDB、Solr、MySQL、さらには古いテキストファイルを使用しています。これらのテクノジーを使用してシステムを生産するには、サーバーにOracleをインストールするよりも少し難しいことを覚えておいてください。いくつかのリリースは安定しておらず、実際にテストを行う必要があります。終わりには、ビジネスの抵抗レベルとシステムのミッションクリティカルな性質に大きく依存します。

これまでに誰も言及していない別のパスは、NewSQLです - すなわち、水平方向にスケーラブルなRDBMS ... MySQLクラスタ（私は考える）とあなたの原因に合ったVoltDBのようにいくつかあります。 （製品、請求書、楽器などの情報を含むdocsやtext docsのファイルです）

また、NoSQLシステムも非リレーショナル非リレーショナルデータセットに適しています。データが本質的にリレーショナルであり、デカルト製品（別名結合）のようなものを実際に実行する必要のあるSQL問合せ機能が必要な場合は、Oracleに固執し、索引付け、シャーディングおよびパフォーマンスのチューニングに時間を費やす方がよいでしょう。

私のアドバイスは、いくつかの異なるシステムで実際に遊ぶことです。見る;

MongoDBの - ドキュメント - CP

CouchDBの - ドキュメント - AP

カサンドラ - カラムファミリー - 利用可能な&パーティショントレラント（AP）

VoltDB - 本当にすばらしい製品、関係データベースが配布され、あなたのケースで役立つかもしれません。 ve）。また、企業のサポートを提供しているようにも見えます。これは、プロの環境に適しています（つまり、ビジネスユーザーにセキュリティの感覚を与える）。

これは私の2cです。システムを使いこなすことは、本当にあなたのケースで本当にうまくいくかを見つけるための唯一の方法です。

Answer 2

HDFSは適切な解決策ではないと思います。これは、データの大規模な並列処理に最適化されており、汎用ファイルシステムではありません。 具体的には、次のような制限があります。
a）ファイルの数に敏感です。実用的な制限は、何千ものファイルにする必要があります。
b）ファイルは読み取り専用であり、追加することはできますが編集はできません。分析データ処理には適していますが、必要なものではないかもしれません。
c）単一障害点 - 名前ノードを持っています。その信頼性には限界があります。

同等のスケーラビリティを備えていてもファイルの数には敏感ではないシステムが必要な場合は、OpenStackのSwiftをお勧めします。それはまた、SPOFをもたない。

Answer 3

あなたはNASストレージを購入することができます。あなたが考えることができる製品のEMS isilonの種類かもしれません。

Hadoop HDFSはファイルストレージ用ではありません。これは、データの処理にストレージをある（レポート、分析のために...）

NASは、ファイル共有のためである

SANは、データベースのためのより多くの

http://www.slideshare.net/jabramo/emc-sanoverviewpresentation

宣言です：私はEMCないですあなたはどんな製品でも考えられます。私はちょうど参照のためにEMCを使いました。