問題タブ [hbase]

ご挨拶、

このサイトの質問を調べましたが、関連する質問は見つかりませんでした。

現在、Hadoop クラスターから抽出して MySQL テーブルにダンプする Flex/PHP/MySQL アプリを構築しています。私のデータセットが増え続けるにつれて、これにはいくつかの問題があります。

より堅牢なオープンソース ソリューションを探しているため、HBase と、PHP または Java を活用してデータを視覚化アプリに抽出する方法を検討し始めました。

Hadoop または HBase の上に視覚化プラットフォームを構築した人はいますか?

ありがとうございました！

HBaseのZookeeper構成を説明するときにこれに遭遇しましたが、この用語に慣れていません。「N」は、HBaseクラスター内のノードの数と関係がありますか？または、Zookeeperクラスターで使用する必要があるノードの数は？

同じ行の列ファミリーは、同じ RegionServer に属します。ここでの質問は、RegionServer が異なる列ファミリーを異なるマシンに格納するかどうかです。

私はHadoop：TomWhiteによる決定的なガイドを読んでいます。13.6章「HBasevsRDMS」で、データが多い場合、最近の10個のアイテムを取得するような単純なクエリでも非常にコストがかかり、PythonとPL/SQLを使用してそれらを書き直す必要があると述べました。

彼は例として次のクエリを示します。

そして、次のように述べています。「RDBMSクエリプランナーは、このクエリを次のように扱います。

ここでの問題は、上位10個のIDのみを追跡していることですが、クエリプランナーは実際にはマージ全体を具体化し、最後に制限します。....実際には、ヒープソートを実行するカスタムPL/Pythonスクリプトを作成するところまで行きました。...ほとんどすべての場合、これはネイティブSQL実装およびクエリプランナーの戦略を上回りました...

期待されるパフォーマンスと実験結果

このような単純なクエリを正しく実行するには、pl/pythonを記述しなければならないような問題を引き起こすデータセットを想像することはできませんでした。だから私はこの問題についてしばらく遊んで、次の観察を思いついた：

このようなクエリのパフォーマンスは、O（KlogN）によって制限されます。それは次のように何かに翻訳することができるので：

（各クエリの「LIMIT10」に注意してください。ところで、ユニオンを制限して順序付けすることはできませんが、読みやすくするためにラッピング選択を削除しました）

各サブクエリは、インデックスO（logN）で正しい位置を見つけ、10個のアイテムを返すのと同じ速さで実行する必要があります。そのK回繰り返すと、O（KlogN）が得られます。

また、クエリプランナーがひどくて最初のクエリを最適化できない場合でも、pl / pythonで何も記述せずに、いつでもそれをユニオン付きのクエリに変換して、目的のパフォーマンスを得ることができます。

計算を再確認するために、9,000,000のテストレコードで満たされた1つのpostgresqlの上でクエリを実行しました。結果は、両方のクエリが最初のクエリで100ミリ秒、2番目のクエリ（ユニオンのあるクエリ）で300ミリ秒と非常に高速であるという私の期待を裏付けました。

したがって、クエリが9,000,000（logn = 23）のレコードに対して100msで実行される場合、9,000,000,000（logn = 33）のレコードに対しては140msで実行されるはずです。

質問

• 上記の推論に欠陥がありますか？
• 上記のようなクエリをpl/pythonで書き直す必要があるデータセットを想像できますか？
• そのようなクエリがO（K log n）で機能しない状況はありますか？

時間範囲に基づいてデータを取得する必要があります。時間範囲に基づいて hbase テーブルを分割する方法はありますか。例: 9:00 から 9:05 までのデータが必要です。

プロパティ グラフを HBase に保存したいと考えています。プロパティ グラフはグラフ ノードであり、エッジにはプロパティがあり、エッジが異なるタイプに属している限り、複数のエッジがノードの同じタプルをリンクできます。

私のクエリ パターンは、プロパティと近傍を要求するか、グラフをトラバースします。例: Vertex[name=claudio]=>OutgoingEdge[knows]=>Vertex[gender=female] で、claudio が好きなすべての女性が表示されます。

グラフデータベースがこれを行うことは知っていますが、通常、巨大なデータセットの場合、複数のノードにスケーリングしません。したがって、これを NoSQL 列ストア (HBase、Cassandra など) に実装したいと考えています。

私のデータモデルは次のとおりです。

Vertices Table :
key: vertexid (uuid)
Family "Properties:": <property name>=><property value>, ...
Family "OutgoingEdges:": <edge key>=><other vertexid>, ...
Family "IncomingEdges:": 発信エッジと同じ...

このテーブルを使用すると、頂点とその隣接リストのプロパティをすばやく取得できます。複数のエッジ (異なるタイプ) が同じ 2 つの頂点を接続できるため、頂点 ID を他のエンドポイントとして使用できません。

Edges Table :
key: edge key (composite(<source vertexid>, <destination vertexid>, <edge typename>)) (ie vertexid1_vertexid2_knows)
Family "Properties:": <property name>=><property value>, ...

このテーブルを使用すると、エッジのプロパティをすばやく取得できます。

エッジ タイプ:
キー: コンポジット(<ソース頂点 ID>, "out|in", <エッジ タイプ名>) (つまり、頂点 ID1_OUT_KNOWS)
ファミリ "ネイバー:": <宛先頂点 ID>=>null,...

このテーブルを使用すると、頂点からの着信または発信のいずれかで、特定のタイプに属し、API のトラバース機能のコアとなるエッジを検索/スキャンできます (したがって、両方の点で可能な限り高速にしたいのネットワーク I/O (RPC)、ディスク I/O (シーク))。また、グラフのサイズに「スケーリング」する必要があります。つまり、グラフの成長に伴い、このタイプの操作のコストは、頂点とエッジの合計数ではなく、頂点から出力されるエッジの数に依存する必要があります。上記の例では、プロパティ name:claudio を持つソース頂点である vertexid1 を考慮し、 vertexid1_out_knows をスキャンして、接続されている頂点のリストを受け取ります。その後、これらの頂点の「Properties:gender」列をスキャンして、「female」値を持つものを探すことができます。

質問:

1) 全般: 運用に適したデータ モデルはありますか?
2) 特定のキーに対して一部のファミリが空になる (つまり、"OutgoingEdges:" ファミリはエッジに対して意味をなさない) 1 つのテーブルにすべてを収めることはできますか? ご覧のとおり、すべてのキーが vertexid uuid プレフィックスで構成されているため、それらは非常にコンパクトで、ほとんどが同じリージョンサーバーに収まります。
3) スキャンにはフィルターを多用すると思います。regexp Filter は私の友達になると思います。このデータ モデルに適用されるフィルターのパフォーマンスについて懸念がありますか?

hbase-site.xmlの動物園の飼育係のクォーラム設定は正確には何ですか？

こんにちは、開発とテストの目的で、ローカル ファイル システムを使用して Hbase 0.89 (10 月リリース) をインストールします。hbase シェルを使用していくつかのテーブルと行を作成しました。hbaseを再起動すると、データ/テーブルが利用できなくなります。これに関するアドバイスはありますか？

map reduce と HBase を使用するプロジェクトに取り組んでいます。hbase-0.89.20100924+28 がバンドルされている Cloudera の CDH3 ディストリビューションを使用しています。複数のマップ削減ジョブを必要とする処理があるため、カスケードを使用したいと思いますが、github でカスケードするための HBase アダプターのさまざまなフォークを調べたところ、HBase のバージョンに対応するものが見つからないようです。誰かが私を正しい方向に向けることができますか?

誰かがhbaseの何が問題なのか知っていますか？私はhadoopにclouderaディストリビューションのvmイメージを使用していますが、以前は正常に機能していましたが、すべてのテーブルを一覧表示しようとすると、毎秒このエラーが発生します。

10/12/26 06:48:07 INFO ipc.HbaseRPC：/127.0.0.1:58920のサーバーに、1回の試行後に到達できず、あきらめました。