Web1.0的時代,數據訪問量很有限,用一夫當關的高性能的單點服務器可以解決大部分問題。
成都創新互聯公司-專業網站定制、快速模板網站建設、高性價比八宿網站開發、企業建站全套包干低至880元,成熟完善的模板庫,直接使用。一站式八宿網站制作公司更省心,省錢,快速模板網站建設找我們,業務覆蓋八宿地區。費用合理售后完善,10余年實體公司更值得信賴。
隨著Web2.0的時代的到來,用戶訪問量大幅度提升,同時產生了大量的用戶數據。加上后來的智能移動設備的普及,所有的互聯網平臺都面臨了巨大的性能挑戰。
NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,泛指非關系型的數據庫。
NoSQL 不依賴業務邏輯方式存儲,而以簡單的key-value模式存儲。因此大大的增加了數據庫的擴展能力。
Memcache Memcache Redis Redis MongoDB MongoDB 列式數據庫 列式數據庫 Hbase Hbase
HBase是Hadoop項目中的數據庫。它用于需要對大量的數據進行隨機、實時的讀寫操作的場景中。
HBase的目標就是處理數據量非常龐大的表,可以用普通的計算機處理超過10億行數據,還可處理有數百萬列元素的數據表。
Cassandra Cassandra
Apache Cassandra是一款免費的開源NoSQL數據庫,其設計目的在于管理由大量商用服務器構建起來的龐大集群上的海量數據集(數據量通常達到PB級別)。在眾多顯著特性當中,Cassandra最為卓越的長處是對寫入及讀取操作進行規模調整,而且其不強調主集群的設計思路能夠以相對直觀的方式簡化各集群的創建與擴展流程。
主要應用:社會關系,公共交通網絡,地圖及網絡拓譜(n*(n-1)/2)
這次的NoSQL專欄系列將先整體介紹NoSQL,然后介紹如何把NoSQL運用到自己的項目中合適的場景中,還會適當地分析一些成功案例,希望有成功使用NoSQL經驗的朋友給我提供一些線索和信息。
NoSQL概念隨著web2.0的快速發展,非關系型、分布式數據存儲得到了快速的發展,它們不保證關系數據的ACID特性。NoSQL概念在2009年被提了出來。NoSQL最常見的解釋是“non-relational”,“Not Only SQL”也被很多人接受。(“NoSQL”一詞最早于1998年被用于一個輕量級的關系數據庫的名字。)
NoSQL被我們用得最多的當數key-value存儲,當然還有其他的文檔型的、列存儲、圖型數據庫、xml數據庫等。在NoSQL概念提出之前,這些數據庫就被用于各種系統當中,但是卻很少用于web互聯網應用。比如cdb、qdbm、bdb數據庫。
傳統關系數據庫的瓶頸
傳統的關系數據庫具有不錯的性能,高穩定型,久經歷史考驗,而且使用簡單,功能強大,同時也積累了大量的成功案例。在互聯網領域,MySQL成為了絕對靠前的王者,毫不夸張的說,MySQL為互聯網的發展做出了卓越的貢獻。
在90年代,一個網站的訪問量一般都不大,用單個數據庫完全可以輕松應付。在那個時候,更多的都是靜態網頁,動態交互類型的網站不多。
到了最近10年,網站開始快速發展。火爆的論壇、博客、sns、微博逐漸引領web領域的潮流。在初期,論壇的流量其實也不大,如果你接觸網絡比較早,你可能還記得那個時候還有文本型存儲的論壇程序,可以想象一般的論壇的流量有多大。
Memcached+MySQL
后來,隨著訪問量的上升,幾乎大部分使用MySQL架構的網站在數據庫上都開始出現了性能問題,web程序不再僅僅專注在功能上,同時也在追求性能。程序員們開始大量的使用緩存技術來緩解數據庫的壓力,優化數據庫的結構和索引。開始比較流行的是通過文件緩存來緩解數據庫壓力,但是當訪問量繼續增大的時候,多臺web機器通過文件緩存不能共享,大量的小文件緩存也帶了了比較高的IO壓力。在這個時候,Memcached就自然的成為一個非常時尚的技術產品。
Memcached作為一個獨立的分布式的緩存服務器,為多個web服務器提供了一個共享的高性能緩存服務,在Memcached服務器上,又發展了根據hash算法來進行多臺Memcached緩存服務的擴展,然后又出現了一致性hash來解決增加或減少緩存服務器導致重新hash帶來的大量緩存失效的弊端。當時,如果你去面試,你說你有Memcached經驗,肯定會加分的。
Mysql主從讀寫分離
由于數據庫的寫入壓力增加,Memcached只能緩解數據庫的讀取壓力。讀寫集中在一個數據庫上讓數據庫不堪重負,大部分網站開始使用主從復制技術來達到讀寫分離,以提高讀寫性能和讀庫的可擴展性。Mysql的master-slave模式成為這個時候的網站標配了。
分表分庫隨著web2.0的繼續高速發展,在Memcached的高速緩存,MySQL的主從復制,讀寫分離的基礎之上,這時MySQL主庫的寫壓力開始出現瓶頸,而數據量的持續猛增,由于MyISAM使用表鎖,在高并發下會出現嚴重的鎖問題,大量的高并發MySQL應用開始使用InnoDB引擎代替MyISAM。同時,開始流行使用分表分庫來緩解寫壓力和數據增長的擴展問題。這個時候,分表分庫成了一個熱門技術,是面試的熱門問題也是業界討論的熱門技術問題。也就在這個時候,MySQL推出了還不太穩定的表分區,這也給技術實力一般的公司帶來了希望。雖然MySQL推出了MySQL Cluster集群,但是由于在互聯網幾乎沒有成功案例,性能也不能滿足互聯網的要求,只是在高可靠性上提供了非常大的保證。
MySQL的擴展性瓶頸
在互聯網,大部分的MySQL都應該是IO密集型的,事實上,如果你的MySQL是個CPU密集型的話,那么很可能你的MySQL設計得有性能問題,需要優化了。大數據量高并發環境下的MySQL應用開發越來越復雜,也越來越具有技術挑戰性。分表分庫的規則把握都是需要經驗的。雖然有像淘寶這樣技術實力強大的公司開發了透明的中間件層來屏蔽開發者的復雜性,但是避免不了整個架構的復雜性。分庫分表的子庫到一定階段又面臨擴展問題。還有就是需求的變更,可能又需要一種新的分庫方式。
MySQL數據庫也經常存儲一些大文本字段,導致數據庫表非常的大,在做數據庫恢復的時候就導致非常的慢,不容易快速恢復數據庫。比如1000萬4KB大小的文本就接近40GB的大小,如果能把這些數據從MySQL省去,MySQL將變得非常的小。
關系數據庫很強大,但是它并不能很好的應付所有的應用場景。MySQL的擴展性差(需要復雜的技術來實現),大數據下IO壓力大,表結構更改困難,正是當前使用MySQL的開發人員面臨的問題。
NOSQL的優勢易擴展NoSQL數據庫種類繁多,但是一個共同的特點都是去掉關系數據庫的關系型特性。數據之間無關系,這樣就非常容易擴展。也無形之間,在架構的層面上帶來了可擴展的能力。
大數據量,高性能
NoSQL數據庫都具有非常高的讀寫性能,尤其在大數據量下,同樣表現優秀。這得益于它的無關系性,數據庫的結構簡單。一般MySQL使用Query Cache,每次表的更新Cache就失效,是一種大粒度的Cache,在針對web2.0的交互頻繁的應用,Cache性能不高。而NoSQL的Cache是記錄級的,是一種細粒度的Cache,所以NoSQL在這個層面上來說就要性能高很多了。
靈活的數據模型
NoSQL無需事先為要存儲的數據建立字段,隨時可以存儲自定義的數據格式。而在關系數據庫里,增刪字段是一件非常麻煩的事情。如果是非常大數據量的表,增加字段簡直就是一個噩夢。這點在大數據量的web2.0時代尤其明顯。
高可用NoSQL在不太影響性能的情況,就可以方便的實現高可用的架構。比如Cassandra,HBase模型,通過復制模型也能實現高可用。
總結NoSQL數據庫的出現,彌補了關系數據(比如MySQL)在某些方面的不足,在某些方面能極大的節省開發成本和維護成本。
MySQL和NoSQL都有各自的特點和使用的應用場景,兩者的緊密結合將會給web2.0的數據庫發展帶來新的思路。
NoSQL,泛指非關系型的數據庫。隨著互聯網web2.0網站的興起,傳統的關系數據庫在應付web2.0網站,特別是超大規模和高并發的SNS類型的web2.0純動態網站已經顯得力不從心,暴露了很多難以克服的問題,而非關系型的數據庫則由于其本身的特點得到了非常迅速的發展。NoSQL數據庫的產生就是為了解決大規模數據集合多重數據種類帶來的挑戰,尤其是大數據應用難題。
雖然NoSQL流行語火起來才短短一年的時間,但是不可否認,現在已經開始了第二代運動。盡管早期的堆棧代碼只能算是一種實驗,然而現在的系統已經更加的成熟、穩定。不過現在也面臨著一個嚴酷的事實:技術越來越成熟——以至于原來很好的NoSQL數據存儲不得不進行重寫,也有少數人認為這就是所謂的2.0版本。這里列出一些比較知名的工具,可以為大數據建立快速、可擴展的存儲庫。
NoSQL(NoSQL = Not Only SQL ),意即“不僅僅是SQL”,是一項全新的數據庫革命性運動,早期就有人提出,發展至2009年趨勢越發高漲。NoSQL的擁護者們提倡運用非關系型的數據存儲,相對于鋪天蓋地的關系型數據庫運用,這一概念無疑是一種全新的思維的注入。
對于NoSQL并沒有一個明確的范圍和定義,但是他們都普遍存在下面一些共同特征:
不需要預定義模式:不需要事先定義數據模式,預定義表結構。數據中的每條記錄都可能有不同的屬性和格式。當插入數據時,并不需要預先定義它們的模式。
無共享架構:相對于將所有數據存儲的存儲區域網絡中的全共享架構。NoSQL往往將數據劃分后存儲在各個本地服務器上。因為從本地磁盤讀取數據的性能往往好于通過網絡傳輸讀取數據的性能,從而提高了系統的性能。
彈性可擴展:可以在系統運行的時候,動態增加或者刪除結點。不需要停機維護,數據可以自動遷移。
分區:相對于將數據存放于同一個節點,NoSQL數據庫需要將數據進行分區,將記錄分散在多個節點上面。并且通常分區的同時還要做復制。這樣既提高了并行性能,又能保證沒有單點失效的問題。
異步復制:和RAID存儲系統不同的是,NoSQL中的復制,往往是基于日志的異步復制。這樣,數據就可以盡快地寫入一個節點,而不會被網絡傳輸引起遲延。缺點是并不總是能保證一致性,這樣的方式在出現故障的時候,可能會丟失少量的數據。
BASE:相對于事務嚴格的ACID特性,NoSQL數據庫保證的是BASE特性。BASE是最終一致性和軟事務。
NoSQL數據庫并沒有一個統一的架構,兩種NoSQL數據庫之間的不同,甚至遠遠超過兩種關系型數據庫的不同。可以說,NoSQL各有所長,成功的NoSQL必然特別適用于某些場合或者某些應用,在這些場合中會遠遠勝過關系型數據庫和其他的NoSQL。
本文主要內容是測試了不同NoSQL數據庫在測試工具YCSB中的表現。我們選取了3款流行的內存(in-memory)數據庫管理系統:Redis,Tarantool 以及 CouchBase,還有緩存系統Memchached。Memchached雖然不屬于數據庫管理系統但常作為快速存儲系統使用。
測試環境由4臺在Microsoft Azure Cloud中的虛擬機組成的計算機組組成。這些虛擬機同屬于一個數據中心。nosql-1和nosql-2用作測試Tarantool和CouchBase,nosql-3和nosql-4用作測試Redis,Azure Redis Cache 以及 Memcached。這些機器都安裝和配置了相應數據庫和測試項目。虛擬機的配置為4核A3 CPU,7GB RAM,120GB硬盤。
數據庫及設置
內存數據庫管理系統會存儲所有在主內存中的數據并在磁碟上進行持續更新操作;透過日志記錄每個數據的修改以確保連貫性。由于是以append-only方式進行日志寫入,因此它很少遇到瓶頸問題;讀取/寫入都不會造成頻繁的磁碟頭移動。
Redis在2009推出,目前的最新版本是3.0.5。我們這里使用的版本是3.0.4,以append-only(只附加)方式進行數據管理,與其配合使用的是Microsoft Azure Redis Cache工具。
Tarantool是一款開源NoSQL數據庫管理系統。我們使用的是Tarantool 1.6.7-126-gb35aff9,日志采用write-ahead(先寫)模式。Memcached是一款分布式內存緩存系統,這里使用是Memcached 1.4.14-0ubuntu9。
Couchbase Server是開源分布式NoSQL面向文檔數據庫,這里使用的版本是Couchbase 4.0.0-4047-1。
YCSB測試工具
Yahoo! Cloud Serving Benchmark(YCSB)是功能強大的NoSQL數據庫性能測試工具,它提供了6種主要的負載工作類型,以字母A到F來區分。
負載A負責更新操作,極值是50/50的讀寫操作,如用于進行新近操作記錄。負載B負責讀取操作,極值是95/5的讀寫操作,如用于進行圖片標簽管理,多進行標簽讀取操作。負載C負載100%的讀取操作,如用于進行用戶屬性獲取。負載D以先進先出方式進行插入操作,如用戶進行最新數據讀取。負載E負責小范圍記錄讀取而不是單個記錄讀取,如線程會話。負載F負責記錄的讀取,修改和寫入,如用戶信息管理。
我們對配置文件作了兩處參數修改:數據條目recordcount設為200000,操作條目operationcount設為5000000。YCSB是多線程工具,我們將以8, 16, 32, 64, 128 及256 線程來進行測試。詳細的測試腳本請點擊這里進行下載。
下列測試結果圖以顏色進行測試對象區分,
Tarantool (HASH) (藍)
Tarantool (TREE)(淺藍)
Redis (紅)
Azure Redis Cache (橙)
Memcached (綠)
CouchBase(黑)
更多圖片請點擊[這里]查看。
結論
Tarantool在所有負載類型測試中皆取得了最優成績。它創建了一個無鎖內存引擎,以協同多任務方式進行操作而不是互斥或并行處理方式。根據以下性能圖表現,我們的結論是Tarantool的高吞吐量處理是其最大優勢之一。因此在多數場合下,Tarantool是用戶的最佳選擇。
即非關系型數據庫和關系型數據庫。
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高性能、高擴展、高可用,不用局限于固定的結構,減少了時間和空間上的開銷,卻又很難保證數據一致性。
————————————————
版權聲明:本文為CSDN博主「蒟蒻熊」的原創文章,遵循CC 4.0 BY-SA版權協議,轉載請附上原文出處鏈接及本聲明。
原文鏈接:
NoSQL太火,冒出太多產品了,保守估計也成百上千了。
互聯網公司常用的基本集中在以下幾種,每種只舉一個比較常見或者應用比較成功的例子吧。
1. In-Memory KV Store : Redis
in memory key-value store,同時提供了更加豐富的數據結構和運算的能力,成功用法是替代memcached,通過checkpoint和commit log提供了快速的宕機恢復,同時支持replication提供讀可擴展和高可用。
2. Disk-Based KV Store: Leveldb
真正基于磁盤的key-value storage, 模型單一簡單,數據量不受限于內存大小,數據落盤高可靠,Google的幾位大神出品的精品,LSM模型天然寫優化,順序寫盤的方式對于新硬件ssd再適合不過了,不足是僅提供了一個庫,需要自己封裝server端。
3. Document Store: Mongodb
分布式nosql,具備了區別mysql的最大亮點:可擴展性。mongodb 最新引人的莫過于提供了sql接口,是目前nosql里最像mysql的,只是沒有ACID的特性,發展很快,支持了索引等特性,上手容易,對于數據量遠超內存限制的場景來說,還需要慎重。
4. Column Table Store: HBase
這個富二代似乎不用贅述了,最大的優勢是開源,對于普通的scan和基于行的get等基本查詢,性能完全不是問題,只是只提供裸的api,易用性上是短板,可擴展性方面是最強的,其次坐上了Hadoop的快車,社區發展很快,各種基于其上的開源產品不少,來解決諸如join、聚集運算等復雜查詢。
分享題目:本地nosql性能,nosql主要解決了大數據環境下的
鏈接地址:http://www.yijiale78.com/article8/hdegip.html
成都網站建設公司_創新互聯,為您提供全網營銷推廣、關鍵詞優化、網站制作、電子商務、App開發、網站建設
聲明:本網站發布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網站立場,如需處理請聯系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經允許不得轉載,或轉載時需注明來源: 創新互聯
猜你還喜歡下面的內容