2012 年NOSQL學習筆記之三
最終一緻性
一言以蔽之：過程松，結果緊，最終結果必須保持一緻性
為了更好的描述用戶端一緻性，我們通過以下的場景來進行，這個場景中包括三個組成部分：
存儲系統
存儲系統可以了解為一個黑盒子，它為我們提供了可用性和持久性的保證。
Process A
ProcessA主要實作從存儲系統write和read操作
Process B 和ProcessC
ProcessB和C是獨立于A，并且B和C也互相獨立的，它們同時也實作對存儲系統的write和read操作。
下面以上面的場景來描述下不同程度的一緻性：
強一緻性
強一緻性（即時一緻性）假如A先寫入了一個值到存儲系統，存儲系統保證後續A,B,C的讀取操作都将傳回最新值
弱一緻性
假如A先寫入了一個值到存儲系統，存儲系統不能保證後續A,B,C的讀取操作能讀取到最新值。此種情況下有一個“不一緻性視窗”的概念，它特指從A寫入值，到後續操作A,B,C讀取到最新值這一段時間。
最終一緻性是弱一緻性的一種特例。假如A首先write了一個值到存儲系統，存儲系統保證如果在A,B,C後續讀取之前沒有其它寫操作更新同樣的值的話，最終所有的讀取操作都會讀取到最A寫入的最新值。此種情況下，如果沒有失敗發生的話，“不一緻性視窗”的大小依賴于以下的幾個因素：互動延遲，系統的負載，以及複制技術中replica的個數（這個可以了解為master/salve模式中，salve的個數），最終一緻性方面最出名的系統可以說是DNS系統，當更新一個域名的IP以後，根據配置政策以及緩存控制政策的不同，最終所有的客戶都會看到最新的值。
關系型資料庫中的表都是存儲一些格式化的資料結構，每個元組字段的組成都一樣。
這樣做的好處就是：這樣的結構非常友善進行表與表之間連接配接等操作。
但從另一個角度來說它也是關系型資料庫性能瓶頸的一個因素。為什麼呢？
因為不是每個元組都需要所有的字段，但是關系型資料庫會為每個元組配置設定所有的字段。
而非關系型資料庫以鍵值對存儲，它的結構不固定，每一個元組可以有不一樣的字段，每個元組可以根據需要增加一些自己的鍵值對，這樣就不會局限于固定的結構，可以減少一些時間和空間的開銷。
n 它們可以處理超大量的資料。
n 它們運作在便宜的PC伺服器叢集上。
PC叢集擴充起來非常友善并且成本很低，避免了“sharding”操作的複雜性和成本。
n 它們擊碎了性能瓶頸。
NoSQL的支援者稱，通過NoSQL架構可以省去将Web或Java應用和資料轉換成SQL友好格式的時間，執行速度變得更快。
“SQL并非适用于所有的程式代碼，”
對于那些繁重的重複操作的資料，SQL值得花錢。但是當資料庫結構非常簡單時，SQL可能沒有太大用處。
n 沒有過多的操作。
雖然NoSQL的支援者也承認關系資料庫提供了無可比拟的功能集合，而且在資料完整性上也發揮絕對穩定，他們同時也表示，企業的具體需求可能沒有那麼多。
n Bootstrap支援
因為NoSQL項目都是開源的，是以它們缺乏供應商提供的正式支援。這一點它們與大多數開源項目一樣，不得不從社群中尋求支援。
公司
NoSQL産品
補充說明
BigTable
Cassandra
Amazon
Dynamo
Apache
HBase
日本第一大SNS網站mix
Tokyo Cabinet (TC)
日本第二大SNS網站green.jp
Flare
淘寶網
Tair
Tair是由淘寶網自主開發的Key/Value結構資料存儲系統，在淘寶網有着大規模的應用。您在登入淘寶、檢視商品詳情頁面或者在淘江湖和好友“搗漿糊”的時候，都在直接或間接地和Tair互動。
新浪網
memcachedb
memcachedb是一個由新浪網的開發人員開放出來的開源項目，給memcached分布式緩存伺服器添加了Berkeley DB的持久化存儲機制和異步主輔複制機制，讓memcached具備了事務恢複能力、持久化能力和分布式複制能力，非常适合于需要超高性能讀寫速度，但是不需要嚴格事務限制，能夠被持久化儲存的應用場景，例如memcachedb被應用在新浪部落格上面。
Leveldb是一個google實作的非常高效的kv資料庫，目前的版本1.2能夠支援billion級别的資料量了。在這個數量級别下還有着非常高的性能，主要歸功于它的良好的設計。特别是LSM算法。
LevelDB
是單程序的服務，性能非常之高，在一台4個Q6600的CPU機器上，每秒鐘寫資料超過40w，而随機讀的性能每秒鐘超過10w。
滑鐵盧大學
NoSQL資料庫根據不同的用途和環境大緻可以分為以下的三類：
代表性産品有：
Redis，Tokyo Cabinet， Flare
MongoDB，CouchDB
Cassandra，Voldemort
七、
序号
資料存儲模型
産品
特點
1
key-value存儲
Kyoto Cabinet/Tycoon
可以通過key快速查詢到其value。一般來說，存儲不管value的格式，照單全收。（Redis包含了其他功能）
Redis
Berkeley DB
MemcacheDB
2
文檔存儲
MongoDB
文檔存儲一般用類似json的格式存儲，存儲的内容是文檔型的。這樣也就有有機會對某些字段建立索引，實作關系資料庫的某些功能。
CouchDB
3
列存儲
Hbase
顧名思義，是按列存儲資料的。最大的特點是友善存儲結構化和半結構化資料，友善做資料壓縮，對針對某一列或者某幾列的查詢有非常大的IO優勢。
Hypertable
4
圖存儲
Neo4J
圖形關系的最佳存儲。使用傳統關系資料庫來解決的話性能低下，而且設計使用不友善。
FlockDB
5
對象存儲
db4o
通過類似面向對象語言的文法操作資料庫，通過對象的方式存取資料。
Versant
6
XML資料庫
Berkeley DB XML
高效的存儲XML資料，并支援XML的内部查詢文法，比如XQuery,Xpath。
BaseX
![【MySQL資料庫】資料庫索引事務1.索引2.事務[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)