nosql支持事務,nosql支持事務嗎

NoSQL和MySQL的區別大嗎？

即非關系型數據庫和關系型數據庫。

為右江等地區用戶提供了全套網頁設計制作服務，及右江網站建設行業解決方案。主營業務為成都網站設計、成都做網站、右江網站設計，以傳統方式定制建設網站，并提供域名空間備案等一條龍服務，秉承以專業、用心的態度為用戶提供真誠的服務。我們深信只要達到每一位用戶的要求，就會得到認可，從而選擇與我們長期合作。這樣，我們也可以走得更遠！

MySQL的優點：事務處理—保持數據的一致性；由于以標準化為前提，數據更新的開銷很小（相同的字段基本上只有一處）；可以進行Join等復雜查詢

NoSQL的優點：首先它是基于內存的，也就是數據放在內存中，而不是像數據庫那樣把數據放在磁盤上，而內存的讀取速度是磁盤讀取速度的幾十倍到上百倍，所以NoSQL工具的速度遠比數據庫讀取速度要快得多，滿足了高響應的要求。即使NoSQL將數據放在磁盤中，它也是一種半結構化的數據格式，讀取到解析的復雜度遠比MySQL要簡單，這是因為MySQL存儲的是經過結構化、多范式等有復雜規則的數據，還原為內存結構的速度較慢。NoSQL在很大程度上滿足了高并發、快速讀/和響應的要求，所以它也是Java互聯網系統的利器。

簡單的擴展：典型例子是Cassandra，由于其架構是類似于經典的P2P，所以能通過輕松地添加新的節點來擴展這個集群;

低廉的成本：這是大多數分布式數據庫共有的特點，因為主要都是開源軟件，沒有昂貴的License成本;

NoSQL的缺點：大多數NoSQL數據庫都不支持事務，也不像 SQL Server和Oracle那樣能提供各種附加功能，比如BI和報表等; 不提供對SQL的支持

那么該如何選擇？

如果規模和性能比24小時的數據一致性更重要，那NoSQL是一個理想的選擇（NoSQL依賴于BASE模型——基本可用、軟狀態、最終一致性）。

但如果要保證到“始終一致”，尤其是對于機密信息和財務信息，那么MySQL很可能是最優的選擇（MySQL依賴于ACID模型——原子性、一致性、獨立性和耐久性）。

如果關系數據庫在你的應用場景中，完全能夠很好的工作，而你又是非常善于使用和維護關系數據庫的，那么我覺得你完全沒有必要遷移到NoSQL上面，除非你是個喜歡折騰的人。如果你是在金融，電信等以數據為王的關鍵領域，目前使用的是Oracle數據庫來提供高可靠性的，除非遇到特別大的瓶頸，不然也別貿然嘗試NoSQL。

然而，在WEB2.0的網站中，關系數據庫大部分都出現了瓶頸。在磁盤IO、數據庫可擴展上都花費了開發人員相當多的精力來優化，比如做分表分庫（database sharding）、主從復制、異構復制等等，然而，這些工作需要的技術能力越來越高，也越來越具有挑戰性。如果你正在經歷這些場合，那么我覺得你應該嘗試一下NoSQL了。

具體問題具體分析

MySQL體積小、速度快、成本低、結構穩定、便于查詢，可以保證數據的一致性，但缺乏靈活性。

NoSQL高性能、高擴展、高可用，不用局限于固定的結構，減少了時間和空間上的開銷，卻又很難保證數據一致性。

————————————————

原文鏈接：

如何搞定NoSQL事務機制

在SequoiaDB巨杉數據庫聯合創始人兼CTO王濤看來，目前只有少量的NoSQL數據庫支持事務機制，如VoltDB、RavenDB、SequoiaDB、MarkLogic。并且，“NoSQL支持事務（ACID）是未來的趨勢，不支持事務的NoSQL會大大縮小其應用場景。”對于ACID來說，是指數據庫事務機制正確執行的四大基本要素，包含了：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）、持久性（Durability）。

高性能 NoSQL

關系數據庫經過幾十年的發展，已經非常成熟，但同時也存在不足：

表結構是強約束的，業務變更時擴充很麻煩。

如果對大數據量的表進行統計運算，I/O會很高，因為即使只針對某列進行運算，也需要將整行數據讀入內存。

全文搜索只能使用 Like 進行整表掃描，性能非常低。

針對這些不足，產生了不同的 NoSQL 解決方案，在某些場景下比關系數據庫更有優勢，但同時也犧牲了某些特性，所以不能片面的迷信某種方案，應將其作為 SQL 的有利補充。

NoSQL != No SQL，而是：

NoSQL = Not Only SQL

典型的 NoSQL 方案分為4類：

Redis 是典型，其 value 是具體的數據結構，包括 string, hash, list, set, sorted set, bitmap, hyperloglog，常被稱為數據結構服務器。

以 list 為例：

LPOP key 是移除并返回隊列左邊的第一個元素。

如果用關系數據庫就比較麻煩了，需要操作：

Redis 的缺點主要體現在不支持完成的ACID事務，只能保證隔離性和一致性，無法保證原子性和持久性。

最大的特點是 no-schema，無需在使用前定義字段，讀取一個不存在的字段也不會導致語法錯誤。

特點：

以電商為例，不同商品的屬性差異很大，如冰箱和電腦，這種差異性在關系數據庫中會有很大的麻煩，而使用文檔數據庫則非常方便。

文檔數據庫的主要缺點：

關系數據庫是按行來存儲的，列式數據庫是按照列來存儲數據。

按行存儲的優勢：

在某些場景下，這些優勢就成為劣勢了，例如，計算超重人員的數據，只需要讀取體重這一列進行統計即可，但行式存儲會將整行數據讀取到內存中，很浪費。

而列式存儲中，只需要讀取體重這列的數據即可，I/O 將大大減少。

除了節省I/O，列式存儲還有更高的壓縮比，可以節省存儲空間。普通行式數據庫的壓縮比在 3:1 到 5:1 左右，列式數據庫在 8:1 到 30:1，因為單個列的數據相似度更高。

列式存儲的隨機寫效率遠低于行式存儲，因為行式存儲時同一行多個列都存儲在連續空間中，而列式存儲將不同列存儲在不連續的空間。

一般將列式存儲應用在離線大數據分析統計場景，因為這時主要針對部分列進行操作，而且數據寫入后無須更新。

關系數據庫通過索引進行快速查詢，但在全文搜索的情景下，索引就不夠了，因為：

假設有一個交友網站，信息表如下：

需要匹配性別、地點、語言列。

需要匹配性別、地點、愛好列。

實際搜索中，各種排列組合非常多，關系數據庫很難支持。

全文搜索引擎是使用倒排索引技術，建立單詞到文檔的索引，例如上面的表信息建立倒排索引：

所以特別適合根據關鍵詞來查詢文檔內容。

上面介紹了幾種典型的NoSQL方案，及各自的適用場景和特點，您可以根據實際需求進行選擇。

為什么大部分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在同樣分區上也支持多鍵事務，但是不支持跨分區的事務。

總之：傳統分布式事務性能不佳的原因是確保原子性(分布式協調)和隔離性同時重疊，創建一個高吞吐量分布式事務的關鍵是分離這兩種關注，這種分離原

子性和隔離性的視角將導致兩種類型的系統，第一種選擇是弱隔離性能讓沖突事務并行執行和確認提交;第二個選擇重新排序原子性和隔離性機制保證它們不會某個

時間重疊，這是一種放棄公平的事務執行，所謂放棄公平就是不再同時照顧原子性和隔離性了，有所傾斜，放棄高標準道德要求就會帶來高自由高效率。

常見NoSQL數據庫的應用場景是怎么樣的

文檔數據庫

源起：受Lotus Notes啟發。

數據模型：包含了key-value的文檔集合

例子：CouchDB, MongoDB

優點：數據模型自然，編程友好，快速開發，web友好，CRUD。

圖數據庫

源起：歐拉和圖理論。

數據模型：節點和關系，也可處理鍵值對。

例子：AllegroGraph, InfoGrid, Neo4j

優點：解決復雜的圖問題。

關系數據庫

源起： E. F. Codd 在A Relational Model of Data for Large Shared Data Banks提出的

數據模型：各種關系

例子：VoltDB, Clustrix, MySQL

優點：高性能、可擴展的OLTP，支持SQL，物化視圖，支持事務，編程友好。

對象數據庫

源起：圖數據庫研究

數據模型：對象

例子：Objectivity, Gemstone

優點：復雜對象模型，快速鍵值訪問，鍵功能訪問，以及圖數據庫的優點。

Key-Value數據庫

源起：Amazon的論文 Dynamo 和 Distributed HashTables。

數據模型：鍵值對

例子：Membase, Riak

優點：處理大量數據，快速處理大量讀寫請求。編程友好。

BigTable類型數據庫

源起：Google的論文 BigTable。

數據模型：列簇，每一行在理論上都是不同的

例子：HBase, Hypertable, Cassandra

優點：處理大量數據，應對極高寫負載，高可用，支持跨數據中心， MapReduce。

數據結構服務

源起： ?

數據模型：字典操作，lists, sets和字符串值

例子：Redis

優點：不同于以前的任何數據庫

網格數據庫

源起：數據網格和元組空間研究。

數據模型：基于空間的架構

例子：GigaSpaces, Coherence

優點：適于事務處理的高性能和高擴展性

什么是New SQL?分析NewSQL是如何融合NoSQL和RDBMS兩者的優勢

NewSQL是對一類現代關系型數據庫的統稱，這類數據庫對于一般的OLTP讀寫請求提供可橫向擴展的性能，同時支持事務的ACID保證。這些系統既擁有NoSQL數據庫的擴展性，又保持傳統數據庫的事務特性。NewSQL重新將“應用程序邏輯與數據操作邏輯應該分離”的理念帶回到現代數據庫的世界，這也驗證了歷史的發展總是呈現出螺旋上升的形式。

在21世紀00年代中，出現了許多數據倉庫系統 (如 Vertica，Greeplum 和AsterData)，這些以處理OLAP 請求為設計目標的系統并不在本文定義的NewSQL范圍內。OLAP 數據庫更關注針對海量數據的大型、復雜、只讀的查詢，查詢時間可能持續秒級、分鐘級甚至更長。

NoSQL的擁躉普遍認為阻礙傳統數據庫橫向擴容、提高可用性的原因在于ACID保證和關系模型，因此NoSQL運動的核心就是放棄事務強一致性以及關系模型，擁抱最終一致性和其它數據模型?(如 key/value，graphs 和Documents)。

兩個最著名的NoSQL數據庫就是Google的BigTable和Amazon的Dynamo，由于二者都未開源，其它組織就開始推出類似的開源替代項目，包括Facebook的 Cassandra (基于BigTable和Dynamo)、PowerSet的 Hbase(基于BigTable)。有一些創業公司也加入到這場NoSQL運動中，它們不一定是受BigTable和Dynamo的啟發，但都響應了NoSQL的哲學，其中最出名的就是MongoDB。

在21世紀00年代末，市面上已經有許多供用戶選擇的分布式數據庫產品。使用NoSQL的優勢在于應用開發者可以更關注應用邏輯本身，而非數據庫的擴展性問題；但與此同時許多應用，如金融系統、訂單處理系統，由于無法放棄事務的一致性要求被拒之門外。

一些組織，如Google，已經發現他們的許多工程師將過多的精力放在處理數據一致性上，這既暴露了數據庫的抽象、又提高了代碼的復雜度，這時候要么選擇回到傳統DBMS時代，用更高的機器配置縱向擴容，要么選擇回到中間件時代，開發支持分布式事務的中間件。這兩種方案成本都很高，于是NewSQL運動開始醞釀。

NewSQL數據庫設計針對的讀寫事務有以下特點：

1、耗時短。

2、使用索引查詢，涉及少量數據。

3、重復度高，通常使用相同的查詢語句和不同的查詢參考。

也有一些學者認為NewSQL系統是特指實現上使用Lock-free并發控制技術和share-nothing架構的數據庫。所有我們認為是NewSQL的數據庫系統確實都有這樣的特點。

網站名稱：nosql支持事務,nosql支持事務嗎
本文地址：http://m.kartarina.com/article0/hddhoo.html

成都網站建設公司_創新互聯，為您提供企業建站、定制開發、手機網站建設、自適應網站、小程序開發、用戶體驗

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源：創新互聯

猜你還喜歡下面的內容