0

ユーザー情報を格納するHbaseテーブルを設計する必要があります。この情報は、年齢、性別、教育、趣味、本を読む、旅行した国など、ソーシャル ネットワーキングを対象としています。注: 今後さらに情報を追加する可能性があります。今すべての情報を知っています。

例: 名前: Olha、年齢: 25、性別: 女性、学歴: 学士情報技術、学歴: コンピューター サイエンスのマスター、趣味: バスケットボール、趣味: 卓球、本: 風と共に去りぬ、本: ダヴィンチ コード、言語: 英語、言語: フランス語、国: ドイツ

主なアイデアは、次のようなクエリを実行できるようにすることです: 女性であるすべての人を返す、年齢: 22 歳、話す: 英語、話す: フランス語、風と共に去った本を読む、ピンポンのように、バスケットボールとドイツ語のように.

そのため、検索クエリに任意の条件を追加できます。

この種の検索クエリを最適化した HBASE テーブル スキーマ (行キー、列ファミリー ...) についてのあなたの提案は何ですか (今後さらに情報を追加することを考慮して) そのようなクエリ (スキャン) を記述する最良の方法は何ですか? 、取得、MapReduce )。

ありがとうございました

4

2 に答える 2

1

Solr/Lucene とそのファセット クエリと結合により、見たい方法でデータをピボットできるという Ian Varley に同意しますが、あなたの質問は「カウント」の質問または「メンバーシップ」である可能性もあります。質問....

(N) 個の属性に一致する人のリストを探しているようですね。問題は、属性ごとに何百万ものユーザー ID を持つことができるということですか?

HBase は、交差点/ユニオンのサイズを計算するだけの場合に適しています。キーと値のペアを Hbase に入れることができ、ユーザーの ID をブルーム フィルターと HyperLogLog のいずれかに「エンコード」できます。正確さとメモリのために速度をトレードします。何らかのタイプのログ集約のクリックストリームで、マップ/リデュース スタイルのジョブを毎時/毎晩実行している可能性があります。

他の人は、あなたが実行しているクエリのタイプとまったく同じように、広告スペースとオンラインスペースでこれを行っています ( 「フロリダに住んでいるレッドブルとポップタルトが好きな人を見つける」 )

参考文献

Apache Hive と Amazon EMR を使用したコンテキスト広告http://aws.amazon.com/articles/2855

分散カウンターのスケーリング: http://whynosql.com/scaling-distributed-counters/

Google: シャーディング カウンターhttps://developers.google.com/appengine/articles/sharding_counters

HBase での分散カウンターのパフォーマンス - パート 1 http://palominodb.com/blog/2012/08/24/distributed-counter-performance-hbase-part-1

Facebook の新しいリアルタイム分析システム: 1 日あたり 200 億のイベントを処理する HBase http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html

Hadoop と HBase を使用したリアルタイム分析 - http://www.slideshare.net/larsgeorge/realtime-analytics-with-hadoop-and-hbase

HBase によるログ イベント処理http://tellapart.com/log-event-processing-with-hbase

BazaarVoice でのクリックストリーム分析http://www.slideshare.net/bazaarvoice_engineering/austin-scales-clickstream-analytics

HBase を使用したリアルタイム分析 - http://www.slideshare.net/alexbaranau/realtime-analytics-with-hbase-long-version

于 2013-06-09T16:48:45.917 に答える
0

これはまさに検索インデックス (Lucene など) が適している種類のものであるという意味で、HBase の優れた使用方法ではありません。

ユーザーとその情報を格納する通常のスキーマの 1 つは、ユーザーごとに 1 つの行を持ち、すべての属性を列と値 (age=22、language=french など) として格納するという点で、リレーショナル データベースによく似ているかもしれません。これは、言及した拡張性に適しています (新しい属性を保存するためにスキーマを変更する必要はありません)。このスキーマを使用すると、一意のユーザー ID で任意の 1 人のユーザー (およびそのすべての属性) を検索できます。ユーザーの数に関係なく、これは非常に高速です。

ただし、そのスキーマでは、説明した方法で検索したい場合 (「年齢が 22 歳のすべてのユーザーを返す」)、すべてのクエリは最終的にテーブル全体のスキャンになります。主キーを介して物事にアクセスします。いかなる種類のセカンダリ インデックスもありません。これは非常に非効率的です (1 つのクエリを実行するたびに 100 万行をスキャンする必要があることを考えると)。

これを修正する方法は？データの順序を「逆」にし、値を行キーに入れ、その値を持つすべてのユーザーを指すことができます。たとえば、行キーが「age:22」の場合、行の列に 22 歳のすべてのユーザー ID が含まれる可能性があります。これは多くの理由で問題になります。非常に高価で、更新を行うのが難しい。ただし、これらの特定のクエリではうまく機能します。

トリック？これはまさに検索インデックス (Lucene など) が行うことであり、HBase を使用して独自に作成するよりもはるかに優れています。ここで使用したいツールのようですね。

HBase を使用する必要がある場合(研究プロジェクトであるため)、HBase と Lucene を一緒に使用することを検討する価値があるかもしれません。ポインターについてはグーグルで検索してください。

于 2013-04-15T15:01:48.507 に答える