1. 全域性查詢策略
應該一邊倒地依賴索引進行查詢，保證絕大多數的查詢是秒級返回。盡量避免動用全表掃瞄，讓全表掃瞄僅服務於非常有限的「生僻」查詢！實現這種格局需要盡可能地保證索引輕量短小(盡量縮短位元組)，然後建立多倍於主資料的索引資料（我們基於配置建立索引的機制保證了增加一條索引的工作量是可以忽略不計的），讓索引能覆蓋絕大多數的查詢。之所以這樣做可行且高效是基於這樣兩點：一、在基於rowkey檢索時hbase的效能是非常高的，完全不受資料條數的影響，我們基於索引的查詢本質上是基於rowkey的查詢，因此無論建立多少倍於主資料的索引資料都不會對效能產生明顯影響。二、保持索引輕量短小是為了節約儲存空間，降低全部資料的體量，同時也利於建立更多的索引。
2. 關於排序和結果集上限
類似於**上的商品檢索，可供排序的字段（人氣，銷量，信用，**）和結果集上限（100頁）是嚴格控制的，我們對排序和結果集上限也是有嚴格要求的，從實質上講這些是所有分布式系統在進行全集計算時都會面臨的問題（還有乙個常見的問題就是join，join也是基於資料全集進行的計算)。對於我們系統的排序：由於一種索引只能指定乙個排序字段，因此，可以查詢的排序字段應該嚴格控制，盡量貼近實際需要選擇最少的字段。體現到上層應用的ui上，就應像**一樣，將支援的排序欄位以單選框方式列出供使用者選擇。對於結果集上限，過大的結果集在返回客戶端後會導致oome，為此我們提供了乙個可配置的引數core.query.maxresultlimit，任何查詢要求的上限如果超出了該值在執行前會丟擲異常終止查詢。
3. 資料體量和blockcache
通過前一段時間的效能測試，關於blockcache有如下結論：
當資料體量4. 為什麼不在索引資料上冗餘多餘的列？
在索引資料上冗餘其他列的初衷大概有這麼兩個方面：一是寄希望於冗餘出的列支援更多條件的查詢，二是過去新增索引需要建立一張單獨的索引表，建立索引的成本（工作量）是很高的，為了能充分利用這張索引表都會冗餘一些字段，基於這樣一種慣性思維，也希望在新的索引機制下冗餘字段。但實際上在新的索引機制下是完全不需要也應該再冗餘多餘列的，這是因為：首先，建立索引已經變得非常簡單，索引的建立成本（工作量)是非常低的，所以不再需要在水平方向上「拉伸」索引，而是應該在垂直方向上「擴充套件」所引，也就是建立更多包含不同欄位的索引。第二點，重複第一點的理由，通過冗餘的列所支援到的查詢不但可以完全使用新的索引來支援，且速度只會比這種方式更快，因為該方式在定位了索引之後還需要取出各個qualifier進行比對，效能比更長包含更多字段的索引而言差距是顯而易見的。第三點：在使用索引檢索時是先通過scan索引找到目標資料的rowkey然後發起乙個二次的get（hregion不支援批量put）請求得到目標資料。如果寄希望通過多冗餘幾個字段，只scan索引資料而不去二次get主資料是不現實的，因為絕大部分的查詢需要的是整條記錄而不是一條記錄中的某幾個字段，除非索引冗餘了全部列。
5.對多rowkey的批判
一旦在索引上開啟冗餘其他列的口子，為了支援更多的查詢特別是迎合整條記錄的返回，勢必將冗餘越來越多的列，最後的情形就是冗餘了所有的列，一條索引資料變成了目標資料的全備份，不同之外只是換了另外一種形式的rowkey,這就是我給定義的「多rowkey"設計。「多rowkey"設計是一種笨重的，成本很高的索引方案，乙個系統能不計代價地承受多少倍的冗餘呢？「多rowkey"方案可以預見的結果是：翻了好幾倍的儲存空間，只能支援有限的幾個查詢, 利用率非低，成本太高。
6.若干技巧
1. 在取保可讀性的前提下使得盡可能短的column family和qulifier名，以及位元組較少的資料型別儲存資料，(如：可以使用byte的就不要使用int!)以此來減少資料儲存空間和傳輸速率，對系統整體效能的提公升是有幫助的
2.如果節點數量為n，n是乙個比較小的數值，而單個節點可以冗餘n倍的資料話，就將hdf.replication設為n，這是保證本地化讀取的最簡單方法，可以有效地提公升系統的效能。遠期目標應該實現乙個基於block進行本地化分配的loadbalancer，特別是在region re-online的時候，這貌似是乙個很基礎的需求，不知hbase何會加入？
Django CRM系統設計開發
設計乙個教育機構的客戶管理系統 crm 對該系統分析如下 crm customer relationship management 客戶管理系統 1.幹什麼用的？管理客戶 維護客戶關係 2.誰去使用？銷售 班主任 專案經理 3.需求 1.登入 2.註冊 3.銷售 1.客戶列表 增加 編輯客戶 2.客...
關於python開發CRM系統
注意本專案是針對培訓學校開發簡化的crm crm全稱 customer relationship management 沒有cmr的缺點及痛點 每個銷售會通過excel來統計客戶資訊，造成資訊不能同步和共享 客戶資訊沒有記錄和跟進資訊 會造成搶單問題 無法統計成單率和報表 沒有和客戶的溝通記錄 客戶...
關於系統設計及其它
1.看到手頭的一套系統，用struts，它定義了乙個基類action，使用了許多例項變數。這是極其糟糕，錯誤的設計。因為struts的action內建是單一例項的，但web環境是多執行緒。在訪問量達到一定數量時，系統將錯誤百出。這種問題必須避免。乙個原則，在struts的action類裡，不要定義任...