為什么大部分NoSQL不提供分布式事務？
像MongoDB, Cassandra, HBase, DynamoDB, 和 Riak這些NoSQL缺乏傳統的原子事務機制，所謂原子事務機制是可以保證一系列寫操作要么全部完成，要么全部不會完成，不會發生只完成一系列中一兩個寫操作;因為數據庫不提供這種事務機制支持，開發者需要自己編寫代碼來確保一系列寫操作的事務機制，比較復雜和測試。
這些NoSQL數據庫不提供事務機制原因在于其分布式特點，一系列寫操作中訪問的數據可能位于不同的分區服務器，這樣的事務就變成分布式事務，在分布式事務中實現原子性需要彼此協調，而協調是耗費時間的，每臺機器在一個大事務過程中必須依次確認，這就需要一種協議確保一個事務中沒有任何一臺機器寫操作失敗。
這種協調是昂貴的，會增加延遲時間，關鍵問題是，當協調沒有完成時，其他操作是不能讀取事務中寫操作結果的，這是因為事務的all-or-nothing原理導致，萬一協調過程發現某個寫操作不能完成，那么需要將其他寫操作成功的進行回滾。針對分布式事務的分布式協調對整體數據庫性能有嚴重影響，不只是吞吐量還包括延遲時間，這樣大部分NoSQL數據庫因為性能問題就選擇不提供分布式事務。
MongoDB, Riak, HBase, 和 Cassandra提供基于單一鍵的事務，這是因為所有信息都和一個鍵key有關，這個鍵是存儲在單個服務器上，這樣基于單鍵的事務不會帶來復雜的分布式協調。
那么看來擴展性性能和分布式事務是一對矛盾，總要有取舍?實際上是不完全是，現在完全有可能提供高擴展的性能同時提供分布式原子事務。
FIT是這樣一個在分布式系統提供原子事務的策略，在fairness公平性, isolation隔離性, 和throughput吞吐量(簡稱FIT)可以權衡。
一個支持分布式事務的可伸縮分布式系統能夠完成這三個屬性中兩個，公平是事務之間不會相互影響造成延遲;隔離性提供一種幻覺好像整個數據庫只有它自己一個事務，隔離性保證當任何同時發生的事務發生沖突時，能夠保證彼此能看到彼此的寫操作結果，因此減輕了程序員為避免事務讀寫沖突的強邏輯推理要求;吞吐量是指每單元時間數據庫能夠并發處理多少事務。
FIT是如下進行權衡：
- 保證公平性fairness 和隔離性isolation, 但是犧牲吞吐量
- 保證公平性fairness和吞吐量, 犧牲隔離性isolation
- 保證隔離性isolation和吞吐量throughput, 但是犧牲公平性fairness.
犧牲公平性：放棄公平性，數據庫能有更多機會降低分布式事務的成本，主要成本是分布式協調帶來的，也就是說，不需要在每個事務過程內對每個機器都依次確認事務完成，這樣排隊式的確認commit事務是很浪費時間的，放棄公平性，意味著可以在事務外面進行協調，這樣就只是增加了協調時間，不會增加互相沖突事務因為彼此沖突而不能運行所耽擱的時間，當系統不需要公平性時，需要根據事務的優先級或延遲等標準進行指定先后執行順序，這樣就能夠獲得很好的吞吐量。
G-Store是一種放棄公平性的 Isolation-Throughput 的分布式key-value存儲，支持多鍵事務(multi-key transactions)，MongoDB 和 HBase在鍵key在同樣分區上也支持多鍵事務，但是不支持跨分區的事務。
總之：傳統分布式事務性能不佳的原因是確保原子性(分布式協調)和隔離性同時重疊，創建一個高吞吐量分布式事務的關鍵是分離這兩種關注，這種分離原子性和隔離性的視角將導致兩種類型的系統，***種選擇是弱隔離性能讓沖突事務并行執行和確認提交;第二個選擇重新排序原子性和隔離性機制保證它們不會某個時間重疊，這是一種放棄公平的事務執行，所謂放棄公平就是不再同時照顧原子性和隔離性了，有所傾斜，放棄高標準道德要求就會帶來高自由高效率。
