可靠性，可伸縮性，可維護性：
可靠性（reliability）
系統在困境（adversity）（硬體故障、軟體故障、人為錯誤）中仍可正常工作（正確完成功能，並能達到期望的效能水準）。
可伸縮性（scalability）
有合理的辦法應對系統的增長（資料量、流量、複雜性）（參閱「可伸縮性」）
可維護性（maintainability）
許多不同的人（工程師、運維）在不同的生命週期，都能高效地在系統上工作（使系統保持現有行為，並適應新的應用場景）。（參閱」可維護性「）
響應時間的高百分位點（也稱為尾部延遲（tail latencies））非常重要，因為它們直接影響使用者的服務體驗。例如亞馬遜在描述內部服務的響應時間要求時以99.9百分位點為準，即使它只影響一千個請求中的乙個。這是因為請求響應最慢的客戶往往也是資料最多的客戶，也可以說是最有價值的客戶 —— 因為他們掏錢了。保證**響應迅速對於保持客戶的滿意度非常重要，亞馬遜觀察到：響應時間增加100毫秒，銷售量就減少1％；而另一些報告說：慢 1 秒鐘會讓客戶滿意度指標減少16%
另一方面，優化第99.99百分位點（一萬個請求中最慢的乙個）被認為太昂貴了，不能為亞馬遜的目標帶來足夠好處。減小高百分位點處的響應時間相當困難，因為它很容易受到隨機事件的影響，這超出了控制範圍，而且效益也很小。
大規模的系統架構通常是應用特定的—— 沒有一招鮮吃遍天的通用可伸縮架構（不正式的叫法：萬金油（magic scaling sauce） ）。應用的問題可能是讀取量、寫入量、要儲存的資料量、資料的複雜度、響應時間要求、訪問模式或者所有問題的大雜燴。
舉個例子，用於處理每秒十萬個請求（每個大小為1 kb）的系統與用於處理每分鐘3個請求（每個大小為2gb）的系統看上去會非常不一樣，儘管兩個系統有同樣的資料吞吐量。
資料模型與查詢語言：
宣告式語言往往適合並行執行。現在，cpu的速度通過核心(core)的增加變得更快，而不是以比以前更高的時鐘速度執行。命令**很難在多個核心和多個機器之間並行化，因為它指定了指令必須以特定順序執行。宣告式語言更具有並行執行的潛力，因為它們僅指定結果的模式，而不指定用於確定結果的演算法。在適當情況下，資料庫可以自由使用查詢語言的並行實現
通常對於宣告式查詢語言來說，在編寫查詢語句時，不需要指定執行細節：查詢優化程式會自動選擇**效率最高的策略，因此你可以繼續編寫應用程式的其他部分。
儲存與檢索
編碼與演化
apache thrift 和protocol buffers（protobuf）是基於相同原理的二進位制編碼庫。 protocol buffers最初是在google開發的，thrift最初是在facebook開發的，並且在2007~2023年都是開源的。 thrift和protocol buffers都需要乙個模式來編碼任何資料。要在thrift的例4-1中對資料進行編碼，可以使用thrift 介面定義語言（idl） 來描述模式
計算密集型 IO密集型 資料密集型
2 計算密集型任務雖然也可以用多工完成，但是任務越多，花在任務切換的時間就越多，cpu執行任務的效率就越低，所以，要最高效地利用cpu，計算密集型任務同時進行的數量應當等於cpu的核心數。3 計算密集型任務由於主要消耗cpu資源，因此，執行效率至關重要。python這樣的指令碼語言執行效率很低，完全...
CPU 密集型 計算密集型，IO密集型
1 cpu 密集型 計算密集型 計算密集型，顧名思義就是應用需要非常多的cpu計算資源，在多核cpu時代，我們要讓每乙個cpu核心都參與計算，將cpu的效能充分利用起來，這樣才算是沒有浪費伺服器配置，如果在非常好的伺服器配置上還執行著單執行緒程式那將是多麼重大的浪費。對於計算密集型的應用，完全是靠c...
cpu密集型 計算密集型 io密集型 簡介
cpu密集型 cpu bound cpu密集型也叫計算密集型，指的是系統的硬碟 記憶體效能相對cpu要好很多，此時，系統運作大部分的狀況是cpu loading 100 cpu要讀 寫i o 硬碟 記憶體 i o在很短的時間就可以完成，而cpu還有許多運算要處理，cpu loading很高。在多重程...