1.資料模型
資料有多種儲存的方式，包括鍵值對【類似map】、半結構化的列式儲存和文件結構儲存。
2.儲存模型
記憶體還是磁碟持久化可以和rdbms進行比較，它們通常持久化儲存資料到磁碟中。即使需要的是純粹記憶體模式，也仍舊有其他方案。一旦考慮持久化儲存，就需要考慮選擇的方案是否影響到訪問模式。
3.一致性模型
嚴格一致性還是最終一致性？問題在於儲存系統如何實現它的目標：是否必須降低一致性要求?雖然這種問題很粗淺，但是在特定的場景中會產生巨大影響。因為一致性可能會影響操作延遲，即系統響應讀寫請求的速度。這需要權衡投入和產出後得到乙個折中結果。
4.物理模型
分布式模式還是單機模式？這種架構看起來像什麼？是僅僅執行在單個機器上，還是分布在多台機器上，但分布及擴充套件規則由客戶端管理，換句話說，由使用者自己的**管理？也許分布式模式僅僅是個事後的工作，並且只會在使用者需要擴充套件系統時產生問題。如果系統提供了一定的擴充套件性，那麼需要使用者採取特定的操作嗎？最簡單的解決方案就是一次增加一台機器，並且設定好分割槽（這點對於不支援虛擬分割槽的系統非常重要），設定時需要考慮同時提高每個分割槽的處理能力，因為系統的每個部分都需要提供均衡的效能。
5.讀/寫效能
使用者必須了解自己的應用程式的訪問模式。是讀多寫少還是讀寫相當，或者是寫多讀少。是用範圍掃瞄資料好，還是用隨機讀請求資料更好？有些系統僅僅對這些中的一種支援的非常好，有些系統則對各種情況都提供了很好的支援。
6.輔助索引
輔助索引支援使用者按不同的字段和排序方式來訪問表。這個維度覆蓋了某些完全沒有輔助索引支援且不保證資料排序的系統（類似於hashmap，及使用者需要知道資料對應鍵的值），到某些可能通過外部手段簡單支援這些功能的系統。如果儲存系統不提供這項功能，使用者的應用應該可以應對或自己模擬輔助索引。
7.故障處理
機器會崩潰是乙個客觀存在的問題，需要有一套資料遷移方案來應對這種情況。每個資料儲存如何進行伺服器故障處理？故障處理完畢之後是否可以正常工作？這與一致性模式維度有關係，因為失去一台伺服器可能會造成資料儲存的空洞。甚至使整個資料儲存不可用。如果替換故障伺服器，那麼恢復100%服務的難度有多大？從乙個正在提供服務的集群中解除安裝一台伺服器時，也會遇到類似的問題。
8.壓縮
當使用者需要儲存tb級的資料時，尤其當這些資料差異很小或由可讀性文字組成時，壓縮會帶來非常好的效果，即能節省大量原始資料儲存。有些壓縮演算法可以將此類的資料壓縮到原始檔案大小的十分之一。有可選擇的壓縮元件，有哪些壓縮演算法可用。
9.負載均衡
假如使用者有高讀寫吞吐量的需求，就要考慮配置一套能夠隨著負載變化自動均衡處理能力的系統。雖然這樣不能完全解決該問題，但是也可以幫助使用者設計高讀寫吞吐量的程式。
10.原子操作的讀-修改-寫
rdbms提供了很多這類的操作（因為它是乙個集中式的面向單伺服器的系統），但這些操作在分布式系統中較難實現，這些操作可以幫助使用者避免多執行緒造成的資源競爭，也可以幫助使用者完成無共享應用伺服器的設計。有了這些比較並交換操作，或者說檢查並設定操作，在設計系統的時候可以有效地降低客戶端的複雜度。
11.加鎖、等待和死鎖
眾所周知，複雜的事務處理，如兩階段提交，會增加多個客戶端競爭同乙個資源資源的可能性。最糟糕的情況就是死鎖，這種情況也很難解決。使用者需要支援的系統採用哪種模型？這種鎖模型能否避免等待和死鎖。
rdbms非常適合事務性操作，但不見長於超大規模的資料分析處理，因為超大規模的查詢需要進行大規模的資料記錄掃瞄或全表掃瞄。分析型資料庫可以儲存數百或數千tb的資料，在一台伺服器上做查詢工作的響應時間，會遠遠超過使用者可接受的合理響應時間。垂直擴充套件伺服器效能，即增加cpu核數和磁碟數目，也並不能很好地解決該問題。
更糟糕的是，rdbms的等待和死鎖的出現頻率，與事務和併發的增加並不是線性關係，準確地說，與併發數目的平方以及事務規模的3次方甚至5次方相關。分割槽通常是乙個不切實際的解決方案，因為它需要客戶端採用非常複雜的方式和較高的代價來維護分割槽資訊。
一些商業rdbms也解決過類似的問題，但它們往往只是特定地解決了問題的某幾個方面，更重要的是，它們非常的昂貴。而一些開源的rdbms解決方案中，往往放棄了其中的一些甚至全部的關係型特性，如輔助索引，來換取更高的效能拓展能力。
問題是，為了效能而一直放棄以上關係型特徵是否值得？使用者可以反正規化化資料模型來避免等待，並且可以通過降低鎖粒度的方式來盡量避免死鎖。資料增長時，無需重新分割槽遷移資料並內嵌水平擴充套件性的方法。最後，使用者還要面對容錯和資料可用性問題，採用提高擴充套件性的機制，使用者最終會得到乙個nosql的解決方案，更確切地說，hbase可以滿足這些需求。
不同的規模，經常需要設計不同的系統結構，對這種原則的最佳描述是：反正規化化、複製和智慧型的主鍵。這就需要重新思考在類似bigtable的儲存系統中如何才能高效合理地儲存資料。
部分原則是採用反正規化化模式，例如將資料之前存放在多張表中的資料儲存在一張表中，這樣在讀取的時候就不需要從多張表中聚合資料。或者預先物化所需的檢視，一次優化從而避免進一步的處理來提高讀取效能。
有非常多的方法來轉換一對
一、一對多、多對多的關係，以適應hbase的底層架構。使用者需要充分理解hbase儲存設計的潛在能力，然後深思熟慮地決定用哪一種實現方式。對稀疏矩陣、寬表、列式儲存的支援使得資料在儲存的時候無需規範化，同時也可以避免查詢時採用開銷很大的join操作聚合資料。使用智慧型的主鍵可以控制資料怎樣去儲存以及儲存在什麼位置。由於可以使用行鍵的部分內容進行範圍檢索，行鍵作為組合鍵設計時，與字典序左部分為頭的索引效果相似。因此，正確的設計能夠使效能不會因為資料的增長而下降，例如，當資料從10條增加到1000萬條時，系統仍舊可以保持相同的讀寫效能【只限少量資料的rowkey讀寫】。
LEB128相關知識
leb128 little endian base 128 是一種變長的整數壓縮編碼形式，它是出自於dwarf debug file format。在android的dalvik executable format中使用該編碼用於表示32位整數。由於32位整數占用固定的4個位元組，可能大多數整數並不...
面試準備3 相關知識
1.對深度學習相關神經網路理解深入，如dnn cnn rnn gan等 2.有深厚的理論研究背景和資料基礎，熟悉em mcmc lr lda pca 時間序列等數學方法 3.熟悉一種以上的深度學習的開源框架，如caffe tensorflow arm ai library snpe等 dnn長短期記...
H264相關知識
1 基本概念 p frame 前向 編碼幀又稱predictive frame，通過充分將低於影象序列中前面已編碼幀的時間冗餘資訊來壓縮傳輸資料量的編碼影象，也叫 幀 b frame 雙向 內插編碼幀 又稱bi directional interpolated prediction frame，既考...