NoSQL數據庫是否意味著缺乏安全性？

NoSQL薄弱的安全性會給企業帶來負面影響 。Imperva公司創始人兼CTO Amichai Shulman如是說。在新的一年中，無疑會有更多企業開始或籌劃部署NoSQL。方案落實后就會逐漸發現種種安全問題，因此早做準備才是正確的選擇。 作為傳統關系型數據庫的替代方案，NoSQL在查詢中并不使用SQL語言，而且允許用戶隨時變更數據屬性。此類數據庫以擴展性良好著稱，并能夠在需要大量應用程序與數據庫本身進行實時交互的交易處理任務中發揮性能優勢，Couchbase創始人兼產品部門高級副總裁James Phillips解釋稱：NoSQL以交易業務為核心。它更注重實時處理能力并且擅長直接對數據進行操作，大幅度促進了交互型軟件系統的發展。Phillips指出。其中最大的優勢之一是能夠隨時改變(在屬性方面)，由于結構性的弱化，修改過程非常便捷。 NoSQL最大優勢影響其安全性 NoSQL的關鍵性特色之一是其動態的數據模型，Shulman解釋道。我可以在其運作過程中加入新的屬性記錄。因此與這種結構相匹配的安全模型必須具備一定的前瞻性規劃。也就是說，它必須能夠了解數據庫引入的新屬性將引發哪些改變，以及新加入的屬性擁有哪些權限。然而這個層面上的安全概念目前尚不存在，根本沒有這樣的解決方案。 根據Phillips的說法，某些NoSQL開發商已經開始著手研發安全機制，至少在嘗試保護數據的完整性。在關系型數據庫領域，如果我們的數據組成不正確，那么它將無法與結構并行運作，換言之數據插入操作整體將宣告失敗。目前各種驗證規則與完整性檢查已經比較完善，而事實證明這些驗證機制都能在NoSQL中發揮作用。我們與其他人所推出的解決方案類似，都會在插入一條新記錄或是文檔型規則時觸發，并在執行過程中確保插入數據的正確性。 Shulman預計新用戶很快將在配置方面捅出大婁子，這并非因為IT工作人員的玩忽職守，實際上主要原因是NoSQL作為一項新技術導致大多數人對其缺乏足夠的知識基礎。Application Security研發部門TeamSHATTER的經理Alex Rothacker對上述觀點表示贊同。他指出，培訓的一大問題在于，大多數NoSQL的從業者往往屬于新生代IT人士，他們對于技術了解較多，但往往缺乏足夠的安全管理經驗。 如果他們從傳統關系型數據庫入手，那么由于強制性安全機制的完備，他們可以在使用中學習。但NoSQL，只有行家才能通過觀察得出正確結論，并在大量研究工作后找到一套完備的安全解決方案。因此可能有90%的從業者由于知識儲備、安全經驗或是工作時間的局限而無法做到這一點。 NoSQL需在安全性方面進行優化 盡管Phillips認同新技術與舊經驗之間存在差異，但企業在推廣NoSQL時加大對安全性的關注會起到很大程度的積極作用。他認為此類數據存儲機制與傳統關系類數據庫相比，其中包含著的敏感類信息更少，而且與企業網絡內部其它應用程序的接觸機會也小得多。 他們并不把這項新技術完全當成數據庫使用，正如我們在收集整理大量來自其它應用程序的業務類數據時，往往也會考慮將其作為企業數據存儲機制一樣，他補充道。當然，如果我打算研發一套具備某種特定功能的社交網絡、社交游戲或是某種特殊web應用程序，也很可能會將其部署于防火墻之下。這樣一來它不僅與應用程序緊密結合，也不會被企業中的其它部門所觸及。 但Rothacker同時表示，這種過度依賴周邊安全機制的數據庫系統也存在著極其危險的漏洞。一旦系統完全依附于周邊安全模型，那么驗證機制就必須相對薄弱，而且缺乏多用戶管理及數據訪問方面的安全保護。只要擁有高權限賬戶，我們幾乎能訪問存儲機制中的一切數據。舉例來說，Brian Sullivan就在去年的黑帽大會上演示了如何在完全不清楚數據具體內容的情況下，將其信息羅列出來甚至導出。 而根據nCircle公司CTO Tim ‘TK’ Keanini的觀點，即使是與有限的應用程序相關聯，NoSQL也很有可能被暴露在互聯網上。在缺少嚴密網絡劃分的情況下，它可能成為攻擊者窺探存儲數據的薄弱環節。因為NoSQL在設計上主要用于互聯網規模的部署，所以它很可能被直接連接到互聯網中，進而面臨大量攻擊行為。 其中發生機率最高的攻擊行為就是注入式攻擊，這也是一直以來肆虐于關系類數據庫領域的頭號公敵。盡管NoSQL沒有將SQL作為查詢語言，也并不代表它能夠免受注入式攻擊的威脅。雖然不少人宣稱SQL注入在NoSQL這邊不起作用，但其中的原理是完全一致的。攻擊者需要做的只是改變自己注入內容的語法形式，Rothacker解釋稱。也就是說雖然SQL注入不會出現，但JavaScript注入或者JSON注入同樣能威脅安全。 此外，攻擊者在籌劃對這類數據庫展開侵襲時，也很可能進一步優化自己的工具。不成熟的安全技術往往帶來這樣的窘境：需要花費大量時間學習如何保障其安全，但幾乎每個IT人士都能迅速掌握攻擊活動的組織方法。因此我認為攻擊者將會始終走在安全部署的前面，Shulman說道。遺憾的是搞破壞總比防范工作更容易，而我們已經看到不少NoSQL技術方面的公開漏洞，尤其是目前引起熱議的、以JSON注入為載體的攻擊方式。 NoSQL安全性并非其阻礙 然而，這一切都不應該成為企業使用NoSQL的阻礙，他總結道。我認為歸根結底，這應該算是企業的一種商業決策。只要這種選擇能夠帶來吸引力巨大的商業機遇，就要承擔一定風險，Shulman解釋道。但應該采取一定措施以盡量弱化這種風險。 舉例來說，鑒于數據庫對外部安全機制的依賴性，Rothacker建議企業積極考慮引入加密方案。他警告稱，企業必須對與NoSQL相對接的應用程序代碼仔細檢查。換言之，企業必須嚴格挑選負責此類項目部署的人選，確保將最好的人才用于這方面事務，Shulman表示。當大家以NoSQL為基礎編寫應用程序時，必須啟用有經驗的編程人員，因為客戶端軟件是抵擋安全問題的第一道屏障。切實為額外緩沖區的部署留出時間與預算，這能夠讓員工有閑暇反思自己的工作內容并盡量多顧及安全考量多想一點就是進步。綜上所述，這可能與部署傳統的關系類數據庫也沒什么不同。 具有諷刺意味的是，近年來數據庫應用程序在安全性方面的提升基本都跟數據庫本身沒什么關系，nCircle公司安全研究及開發部門總監Oliver Lavery如是說。

上思網站制作公司哪家好，找創新互聯公司！從網頁設計、網站建設、微信開發、APP開發、響應式網站建設等網站項目制作，到程序開發，運營維護。創新互聯公司于2013年開始到現在10年的時間，我們擁有了豐富的建站經驗和運維經驗，來保證我們的工作的順利進行。專注于網站建設就選創新互聯公司。

為什么要使用NoSQL？NOSQL的優勢

這次的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的淺談

1、性能

都比較高，性能對我們來說應該都不是瓶頸。

總體來講，TPS 方面 redis 和 memcache 差不多，要大于 mongodb。

2、操作的便利性

memcache 數據結構單一。（key-value）

redis 豐富一些，數據操作方面，redis 更好一些，較少的網絡 IO 次數，同時還提供 list，set，

hash 等數據結構的存儲。

mongodb 支持豐富的數據表達，索引，最類似關系型數據庫，支持的查詢語言非常豐富。

3、內存空間的大小和數據量的大小

redis 在 2.0 版本后增加了自己的 VM 特性，突破物理內存的限制；可以對 key value 設置過

期時間（類似 memcache）

memcache 可以修改最大可用內存,采用 LRU 算法。Memcached 代理軟件 magent，比如建立

10 臺 4G 的 Memcache 集群，就相當于有了 40G。 magent -s 10.1.2.1 -s 10.1.2.2:11211 -b

10.1.2.3:14000 mongoDB 適合大數據量的存儲，依賴操作系統 VM 做內存管理，吃內存也比較厲害，服務

不要和別的服務在一起。

4、可用性（單點問題）

對于單點問題，

redis，依賴客戶端來實現分布式讀寫；主從復制時，每次從節點重新連接主節點都要依賴整

個快照,無增量復制，因性能和效率問題，

所以單點問題比較復雜；不支持自動 sharding,需要依賴程序設定一致 hash 機制。

一種替代方案是，不用 redis 本身的復制機制，采用自己做主動復制（多份存儲），或者改成

增量復制的方式（需要自己實現），一致性問題和性能的權衡

Memcache 本身沒有數據冗余機制，也沒必要；對于故障預防，采用依賴成熟的 hash 或者環

狀的算法，解決單點故障引起的抖動問題。

mongoDB 支持 master-slave,replicaset（內部采用 paxos 選舉算法，自動故障恢復）,auto sharding 機制，對客戶端屏蔽了故障轉移和切分機制。

5、可靠性（持久化）

對于數據持久化和數據恢復，

redis 支持（快照、AOF）：依賴快照進行持久化，aof 增強了可靠性的同時，對性能有所影

響

memcache 不支持，通常用在做緩存,提升性能；

MongoDB 從 1.8 版本開始采用 binlog 方式支持持久化的可靠性

6、數據一致性（事務支持）

Memcache 在并發場景下，用 cas 保證一致性redis 事務支持比較弱，只能保證事務中的每個操作連續執行

mongoDB 不支持事務

7、數據分析

mongoDB 內置了數據分析的功能(mapreduce),其他不支持

8、應用場景

redis：數據量較小的更性能操作和運算上

memcache：用于在動態系統中減少數據庫負載，提升性能;做緩存，提高性能（適合讀多寫

少，對于數據量比較大，可以采用 sharding）

MongoDB:主要解決海量數據的訪問效率問題。

表格比較：

memcache redis 類型 內存數據庫 內存數據庫

數據類型 在定義 value 時就要固定數據類型 不需要

有字符串，鏈表，集 合和有序集合

虛擬內存 不支持 支持

過期策略 支持 支持

分布式 magent master-slave，一主一從或一主多從

存儲數據安全 不支持 使用 save 存儲到 dump.rdb 中

災難恢復 不支持 append only file(aof)用于數據恢復

性能

1、類型——memcache 和 redis 都是將數據存放在內存，所以是內存數據庫。當然，memcache 也可用于緩存其他東西，例如圖片等等。

2、 數據類型——Memcache 在添加數據時就要指定數據的字節長度,而 redis 不需要。

3、 虛擬內存——當物理內存用完時，可以將一些很久沒用到的 value 交換到磁盤。

4、 過期策略——memcache 在 set 時就指定，例如 set key1 0 0 8,即永不過期。Redis 可以通

過例如 expire 設定，例如 expire name 10。

5、 分布式——設定 memcache 集群，利用 magent 做一主多從;redis 可以做一主多從。都可

以一主一從。

6、 存儲數據安全——memcache 斷電就斷了，數據沒了；redis 可以定期 save 到磁盤。

7、 災難恢復——memcache 同上，redis 丟了后可以通過 aof 恢復。

Memecache 端口 11211

yum -y install memcached

yum -y install php-pecl-memcache

/etc/init.d/memcached start memcached -d -p 11211 -u memcached -m 64 -c 1024 -P /var/run/memcached/memcached.pid

-d 啟動一個守護進程

-p 端口

-m 分配的內存是 M

-c 最大運行并發數-P memcache 的 pid

//0 壓縮（是否 MEMCACHE_COMPRESSED） 30 秒失效時間

//delete 5 是 timeout

本文題目：淺談nosql技術,nosql數據庫技術與應用
本文鏈接：http://m.2m8n56k.cn/article30/hogoso.html

成都網站建設公司_創新互聯，為您提供動態網站、營銷型網站建設、外貿網站建設、網站排名、品牌網站制作、定制網站

廣告

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