HBaseの行のキーデザイン

Question

私は、Hibernateとphoenixを組み合わせて解析を行っています。私はiotプロジェクトのhbase行のキーをdesingしようとしていますが、私が正しくやっているかどうかは分かりません。

私のデータベースは、このようなものに表すことができます。

Client--->Project ----> Cluster1 ---> Cluster 2 ----> Sensor1 
Client--->Project ----> Building ----> Sensor2 
Client--->Project ----> Cluster1 ---> Building ----> Sensor3 

何私が行っていること（CLIENT_ID、PROJECT_ID、CLUSTER_ID、Building_iD、SensorID）

(1,1,1#2,0,1) 
(1,1,0,1,2) 
(1,1,1,1,3) 

の複合主キーであり、セパレータ＃1＃2＃454など を持つ複数のクラスタまたは建物を指定できます。ノードがない場合は、0を挿入します。

我々はセンサーの値と複数のmeta_dataを持つことになります。

私の質問IDが1のクラスタのすべてのセンサーが有効であると言う要求に対して、このhbase行のキーの設計がありますか？

私は、Sensor_ID、TimeStampをキーに入れて、すべてのルートを列ファミリに配置することも考えましたが、この設計では自分の要求に適しているかどうかわかりません。

このプロジェクトの3番目のアイデアは、データのルートとhbaseにneo4jを組み合わせることです。

誰もが、このデータベースを設計するための最善のアプローチについて私にご案内するために類似の問題を経験しましたか？

Answer 1

あなたは時系列データを扱っているようです。 HBaseを時系列データ（または単調増加キーの他の形式）で使用する主なリスクは、hotspottingです。これは危険なシナリオであり、クラスタが単一のマシンとして動作する可能性があります。

HBaseの上にOpenTSDBがあるとよく考えてください。これは問題に非常によく似ています。理解しておくべき最も重要なことは、HBase schema/keyをエンジニアリングする方法です。タイムスタンプはキーの先頭部分ではなく、スレーブノードとリージョンサーバーの数の異なるmetric_uid >>>（これはバランスの取れたクラスタにとって不可欠です）を想定しています。あなたはmetric_uid適切に（多分センサーの読み取りに固有のキー化合物）などのタグを設計する必要があり、あなたの特定のユースケースに応じて、

<metric_uid><timestamp><tagk1><tagv1>[...<tagkN><tagvN>] 

：

アンOpenTSDBキーは、以下の構造を有しています。タグは、データ集約において基本的な役割を果たします。

注：OpenTSDBは、Treesのコンセプトを導入しました。このコンセプトは、センサーの読み値をナビゲートして集計を容易にするのに非常に役立ちます。私はあまりよく知られていませんが、どのセンサーがどのクライアント、プロジェクト、クラスター、ビルディングなどと関連しているかを判断するのに役立つ階層構造を作成することができると仮定します...

P.S.私はこのプロジェクトにNeo4Jのための余地があるとは思わない。