前一阵子团队来一新人,分享了其所从事物联网相关领域的事件经验。其主要核心逻辑是收集处理来自海量的物联网设备上报的一些信息。比如大楼电路、温度、湿度等一些周期性的上报信息,记录这些信息的方式为使用HBase。其中一点是使用Salt 来避免数据分布的不均匀特性。

|  EntityID | TimeStamp  | Temp | Current| humidity|
| --- | --- |--- |--- |---|
| 1 | time1 | 10| 5|20| 
| 1 | time2 | 10| 5|20| 
| 2 | time1 | 10| 5|20| 
| 2 | time2 | 10| 5|20| 
| 2 | time3 | 10| 5|20| 
| 2 | time4 | 10| 5|20| 

一般来说Key的设计是EntityID + TimeStamp;但是现实中EntityKey划分相对比较集中,比如大企业一般来说会划分一大段连续的EntityKey,其产生的数据就非常集中,很容易导致查询热点(多个Entity之间的联合需求基本很少,一般都是根据EntityID来查询数据)。

这个时候 可以给数据加点盐,根据EntityID换算一个固定的Salt()作为Key 的一部分,比如Hash(EntityKey)。

|  Salt| EntityKey | TimeStamp  | Temp | Current| humidity|
| --- | --- |--- |--- |---|---|
|100100| 1 | time1 | 10| 5|20| 
|100100| 1 | time2 | 10| 5|20| 
|100120| 2 | time1 | 10| 5|20| 
|100120| 2 | time2 | 10| 5|20| 
|100120| 2 | time3 | 10| 5|20| 
|100120| 2 | time4 | 10| 5|20| 

INALL:其实加盐技术是存储方面split数据还算是蛮通用的一个引用层次的优化,做后台开发有时候很想通过通用的手段解决一些棘手的问题,其实很多时候,换个角度,从应用场景出发,反而能够事半而功倍。


This article used CC-BY-SA-4.0 license, please follow it.