class Singletonjava
{正則表達式
public:算法
static Singleton &Instance(){ //1數據庫
if( !m_pInstatnce){ //2後端
Lock(m_mutex) //3數組
If( !m_pInstance ) //4緩存
m_pInstance = new Singleton;//5服務器
UnLock(m_mutex); //6網絡
}數據結構
return *m_pInstance; //7
}
private:
static volatitle Singleton *m_pInstatnce; //8
private:
Singleton(); //9
Singleton(const Singleton&); //10
Singleton& operator=(const Singleton&); //11
~Singleton(); //12
}
Singleton *Singleton:m_pInstatnce = NULL; //13
一、 可拓展性 :能夠以最小的代價、無須停機的方式增長存儲系統的容量。一些狀況下咱們須要快速增長系統的容量,而且可以自動負載、利用到這些新的硬件設備。
二、 高寫入吞吐量 :大多數應用都須要存儲巨大量的數據,這就要求很高的寫入吞吐量。
三、 單個data center內高性能、低延遲的強一致性 :一些重要的應用、好比消息、要求很強的單個數據中心內的一致性,這些需求很直觀來自於用戶需求,好比展現在主頁的「未讀消息」的數目和inbox頁面顯示的消息就應當是高度一致的。儘管全局強一致性的分佈式系統幾乎是不可能的,可是一個系統至少可以提供在單個數據中心內的強一致性,這可以帶來很好的用戶體驗。
四、 高效的隨機讀取性能 :儘管應用層的緩存技術(無論是嵌入式的仍是memcached方式)被普遍應用,可是不少訪問仍然沒辦法命中緩存,須要後端的存儲系統來處理,Hbase隨機讀取性能很穩定。MySQL在隨機讀取方面很是優秀,但若是Hbase結合分佈式緩存MemeCached或者MemBase,那麼其讀取性能就能夠和MySQL比肩了。
五、 高可用性以及災難恢復 :咱們須要提供給用戶高度可用的服務,無論是遇到計劃中的事件(好比軟件升級、或者硬件/容量的增長),仍是遇到一些計劃以外的事件(好比硬件失效)。咱們也須要可以允許數據中心的一些數據丟失,可以在合理的時間範圍內切換到其餘數據中心來爲用戶提供服務。
六、 故障隔離 :咱們在大量的MySQL數據庫上的應用經驗代表,故障隔離是很是關鍵的。單個數據庫能夠down掉,可是僅只有很小一部分用戶會被這樣的事件影響。相似地,在咱們的Hadoop存儲中,單個磁盤故障僅只會影響到一小部分數據,並且系統能夠很快恢復。
七、 原子的「讀-修改-寫」原語 :原子的計數器和檢查並設置(checkand set、或者稱compare and swap)等API在構建無鎖的併發應用時很是有用,能夠幫助用戶有效地解決多線程競爭形成的不少問題。
八、 範圍掃描 :一些應用要求特定範圍內的行的集合的高效檢索。例如,給定用戶的最近100條消息的檢索。
一、 可拓展性
雖然全部NoSQL數據庫都承諾可拓展性,可是面對挑戰是水平卻不盡相同。
BigTable的類似產品Hbase和Hypertable暫時處於領先地位,內存存儲(Membase或Redis)和文檔數據庫(MongDB或CouchBase)緊隨其後,他們之間的差別隨着數據量的增大而被無限放大,特別是到了PB級之後。
拓展性方面Hbase具有天生的優點,支持自動負載均衡,故障轉移,壓縮和單服務器多分片,並且Hbase和HDFS配合的很是好,HDFS可以經過複製和自動平衡輕鬆容納跨越多個服務器的大文件。
因此所若是須要極端拓展性的話,列族NoSQL是最好的選擇。
可是話又說回來,若是你的大量數據會以驚人的快節奏出現,例如一些實時的交易數據或者廣告點擊追蹤數據,那麼單靠列式存儲沒法提供完美的解決方案。這個時候你須要一些更加輕快、既支持快速讀寫、又支持實時處理的存儲,沒有什麼比在內存裏面處理數據更快了,因此你能夠在Hbase前面搭配上MongDB/Redis來進行實時數據處理以及實時的數據挖掘等。其餘一些實時性不是很是高的批量查詢和數據挖掘能夠利用Mapreduce在Hbase上進行。
二、 事務完整性和一致性
Hbase和Hypertable提供行級的原子更新以及一致性狀態,MongDB提供文檔級別的原子更新,Cassandra只能提供最終一致性。
可是事務的要求並非必須的,許多數據,好比網絡流量日誌,社交網絡狀態更新(微博等),廣告點擊,道路交通數據,交易數據和遊戲分數等是一次寫、屢次讀,這樣的數據對事務的需求有限,甚至沒有。
有些數據雖然已更新和刪除,可是修改一般只限於單記錄而非數據集的某個範圍,有時更新很是頻繁且涉及範圍操做。若是範圍操做很常見而且須要保持更新的一致性,那麼RDBMS纔是最佳選擇,若是單個條目的原子性已經足夠,那麼列式數據庫、文檔數據庫和部分鍵/值存儲均可以。若是須要事務完整性可是能夠容納暫時的窗口不一致,那麼最終一致性存儲也是不錯的選擇。
三、 數據模型
MongDB支持類SQL查詢、基本的關係型引用和數據庫對象,若是使用NoSQL的主要緣由是可使用寬鬆的數據結構,那麼MongDB確定是開始使用NOSQL的最佳選擇。
不少Web爲中心的業務都開始使用MongDB,主要是由於它支持靈活的數據模型(弱Schema),同時可以提供快速的讀寫能力。(如今敏捷開發很重要、MongoDB能更快地開發應用程序。一個明顯的緣由是MongoDB沒有固定的Schema,全部花在提交、溝通和實施Schema變動的時間都省下來了)
此外MongDB對Web框架的支持很是好,好比Spring、Rails等。
最後要說明的是,MongDb很是容易上手,學習週期很短。
四、 查詢支持
挑選NoSQL主要考慮的因素除了存儲,還有查詢。
MongDB和Redis的查詢能力比較強。
像MongDB的查詢,與SQL類似,語法簡單,容易學習。MongoDB支持範圍查詢,正則表達式查詢,對子文檔內屬性的查詢,能夠取代原來大多數任務的SQL查詢。
像Redis的查詢,查詢方法很全,命令文檔也很豐富。
Hbase只支持基於Rowkey的單條記錄查找、基於Rowkey的範圍查找以及全表掃描。
要注意的是幾乎全部NoSQL存儲都不支持表之間的join操做。
提到查詢不得不提到索引,MongDB自己支持二級索引,Hbase不支持二級索引,可是如今也有不少方法(最多見是藉助協處理器)能夠幫助Hbase實時創建二級索引。
五、 性能
(1) 50/50讀和更新、即讀少寫多。
Cassandra最優秀,每秒執行超過1W次操做,平均讀延遲只有25ms、更新性能更好只有10ms。
Hbase緊隨其後。至於MySQL,每秒執行4000左右操做的時候才和上面兩個有可比性,超過5000以後延遲迅速攀升。
(2) 95/5讀和更新、即讀多寫少。
仍是Cassandra最優秀。
列式存儲連續範圍的讀取性能很是優秀,這證實和Hbase批量讀寫的性能很是好。
Hbase表現很是穩定,與每秒操做數無關,5%的更新在Hbase裏面幾乎沒有延遲。
只讀狀況下MySQL性能最好,可能與緩存有關。
若是結合分佈式緩存MemeCached或者MemBase,那麼Hbase的讀取性能就能夠和MySQL比肩了。
當全部節點的pRand都拷貝完成後,再將合併鏈表分紅兩個鏈表就能夠了。