1樓：爸爸的大肚皮
1. row id 可以指定start, end的範圍達到某種匹配的效果。如果要LIKE之類的操作怎麼辦？答案是你自己解決。
2. 為什麼不做成SQL一樣功能強大？即便是SQL進行模糊匹配時，全表掃瞄也是無法絕對避免的，一旦全表掃瞄，效能下降是必然，不然，也不用SQL優化了，而SQL優化是有侷限的，最後你會發現，你需要的是重新設計整個系統。
hbase是為大資料而生，這決定了在hbase上進行全表掃瞄是不可行的，因此rowid作為全域性索引才能滿足大資料查詢的效能要求，不僅如此，列族，稀疏表空值不佔位等等都提高了hbase的讀效能。
3. hbase的表在設計時需要你重新審視你的資料。hbase是反規範化的，也就是存在資料冗餘，資料冗餘會增加資料量，但是通過冗餘的設計，盡可能為各種查詢設計合理的rowid，反而可以加快大資料的讀取速度。
如果設計者覺得某種查詢是必須的，就應該為這種查詢設計合理的rowid。以下資料以LIKE操作為例，如果關心的是起始位置兩位的字元為AB的資料（欄位中每一位均為A~Z,沒有數字），SQL使用AB%，而hbase的rowid中可以包含欄位前兩位的值，這樣通過指定範圍0001#AB就可以快速定位資料，絕不要做全表掃瞄再來判斷的傻事。
0001#AB#00001#ABCEEE
0001#AB#00002#ABCBBB
如果rowid設計成以下的樣子
0001#ABCBBB#00002
0001#ABCEEE#00001
那麼指定範圍0001#ABAAAA~0001#ABZZZZ，通過範圍來定位資料也可以，範圍越小，查詢越快。
由於資料量巨大，分布式系統的查詢目前還沒有SQL如此靈活，儘管通過各個子生態的努力，盡可能貼近SQL語法，但也是要付出計算量增大的代價的。設計rowid滿足業務需求不是一件容易的事情，但確是最高效的。最簡單的，也最可靠。
HBase讀效能怎麼樣？
浪尖 hbase讀效能可以，關鍵設計好rowkey 1，資料量大的讀hbase 2，資料量小的讀redis 3，也可以用redis做hbase的cache 這樣我想到某個看似非核心實則主流程強依賴的業務，由於運維手段和業務使用的原因，即便在前面擋了一層mc快取，hbase的讀取效能仍然讓人深感無力。...
HBase是否適合做資料探勘？
HBase做DM的結果儲存應該會好一點，但個人覺得不是很適合做DM的輸入。DM時需要的資料及資料處理，用Hive之類的會好一些。 孔德雨 hadoop 系來做資料探勘，主流是hdfs hive的表現層。按天分表 檔案 然後用hive 做HQL查詢。hbase 用來做資料探勘沒必要。 李永會 可以用，...
Redis 加 HBase 的組合靠譜嗎？
關力 看場景，資料量。高併發的時候，如果直接呼叫hbase,transaction處理速度不夠的話，就會出現雪崩效應。應用伺服器會全部down掉。我們的服務就發生過一次。因為redis down掉，導致直接查詢hbase，效能下降。導致Log資訊丟失2小時。Redis的key如果設計得好的話，可以擋...