HBase行關鍵設計

我正在使用Hbase與phoenix進行交互式分析，我試圖設計一個IOT項目的hbase行鍵，但我不確定我是否做得對。HBase行關鍵設計

我的數據庫可以表示成這樣的：

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.

而在第e列族中，我們將具有傳感器的值和倍數meta_data。

我的問題是這個hbase行的關鍵設計的請求，說我們希望所有傳感器的ID爲1的集羣是有效的？

我想也只是把密鑰的Sensor_ID，TimeStamp，並把所有的根系列，但這個設計我不知道它很適合我的要求。

我對這個項目的第三個想法是將neo4j用於數據的生根和hbase。

任何人都有類似問題的經驗，以指導我設計這個數據庫的最佳方法？

來源

2016-09-20 azelix

您是否知道給定客戶可能擁有的項目/羣集/傳感器的最大數量？ – Gevorg

每個傳感器產生多少個數據點？ – Gevorg

@Gevorg不，我沒有任何最大的數字，它是一個top10和top60傳感器，所以它每天可以產生大約1440個數據點/傳感器，最近我試圖查找時間序列數據庫，很適合在hadoop生態系統像opentsdb，有什麼建議嗎？ – azelix

看來你正在處理時間序列數據。使用HBase與時間序列數據（或其他形式的單調遞增鍵）的主要風險一旦爲hotspotting。這是可能發生的危險情況，並使您的羣集表現爲一臺機器。

你應該考慮在HBase之上的OpenTSDB，因爲它很好地解決了這個問題。要理解的最重要的一件事是如何工程師HBase schema/key。請注意，時間戳不在密鑰的前面，它假設從節點和區域服務器的數量不同（這對於平衡羣集是必不可少的）。

的OpenTSDB鍵具有以下結構：

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

根據您的具體使用情況，你應該工程師的metric_uid適當的（可能是複合鍵唯一一個傳感器讀數）以及標籤。標籤將在數據聚合中發揮重要作用。

注意：自v2.0開始，OpenTSDB引入了Trees的概念，可能對導航您的傳感器讀數和促進聚合非常有幫助。我不太熟悉它們，但我認爲你可以創建一個分層結構，這將有助於確定哪個傳感器與哪個客戶端，項目，集羣，建築物等等相關聯...

P.S.我不認爲Neo4J在這個項目中有空間。

來源

2016-09-29 20:32:52 Gevorg

HBase行關鍵設計

回答

相關問題