Python數據分析及可視化實例之存儲方式簡介

系列文章總目錄：Python數據分析及可視化實例目錄

1.簡介

關於數據存儲方式的選擇，沒有什麼可以討論的。

各有優缺，你熟悉哪個就用哪個。

比如我自己熟悉MongoDB，我就推薦它。

2.MongoDB介紹

# 這篇文章是在3年前我剛開始接觸MongoDB的時候查看到的，從收藏夾翻出來供大家參考。n

在過去的很長一段時間中，關係型資料庫（Relational Database Management System）一直是最主流的資料庫解決方案，他運用真實世界中事物與關係來解釋資料庫中抽象的數據架構。然而，在信息技術爆炸式發展的今天，大數據已經成為了繼雲計算，物聯網後新的技術革命，關係型資料庫在處理大數據量時已經開始吃力，開發者只能通過不斷地優化資料庫來解決數據量的問題，但優化畢竟不是一個長期方案，所以人們提出了一種新的資料庫解決方案來迎接大數據時代的到來——NoSQL（非關係型資料庫）。

　　NoSQL非常年輕，但他擁有的眾多優秀的特性已經讓眾多企業和開發者開始接受，讓我們來看一下來自於美國資料庫知識網站DB-engines上個月的資料庫排名情況。

　　從排名中可以看到MongoDB資料庫從眾多的RDBMS（關係型資料庫）中脫穎而出，已經成為第五名，並且還在不斷上升中。

　　如果將資料庫比喻成人類的話，那麼MongoDB完全可以說是神童了，年僅5歲的他單槍匹馬挑戰一群叔叔級別的人物，並且按照近幾年的發展速度來看，他也即將超越PgSQL成為第四名，雖然距離前方三位有著NB爹的富二代還有一定的距離，但在這樣一個技術爆炸的年代還有什麼不可能的事呢？

為什麼選擇MongoDB？

1.性能

　　在大數據時代中，大數據量的處理已經成了考量一個資料庫最重要的原因之一。而MongoDB的一個主要目標就是儘可能的讓資料庫保持卓越的性能，這很大程度地決定了MongoDB的設計。在一個以傳統機械硬碟為主導的年代，硬碟很可能會成為性能的短板，而MongoDB選擇了最大程度而利用內存資源用作緩存來換取卓越的性能，並且會自動選擇速度最快的索引來進行查詢。MongoDB儘可能精簡資料庫，將儘可能多的操作交給客戶端，這種方式也是MongoDB能夠保持卓越性能的原因之一。

2.擴展

　　現在互聯網的數據量已經從過去的MB、GB變為了現在的TB級別，單一的資料庫顯然已經無法承受，擴展性成為重要的話題，然而現在的開發人員常常在選擇擴展方式的時候犯了難，到底是選擇橫向擴展還是縱向擴展呢？

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

橫向擴展（scale out）是以增加分區的方式將資料庫拆分成不同的區塊來分布到不同的機器中來，這樣的優勢是擴展成本低但管理困難。

縱向擴展（scale up） 縱向擴展與橫向擴展不同的是他會將原本的伺服器進行升級，讓其擁有更強大的計算能力。這樣的優勢是易於管理無需考慮擴展帶來的眾多問題，但缺點也顯而易見，那就是成本高。一台大型機的價格往往非常昂貴，並且這樣的升級在數據達到極限時，可能就找不到計算能力更為強大的機器了。

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

　　而MongoDB選擇的是更為經濟的橫向擴展，他可以很容易的將數據拆分至不同的伺服器中。而且在獲取數據時開發者也無需考慮多伺服器帶來的問題，MongoDB可以將開發者的請求自動路由到正確的伺服器中，讓開發者脫離橫向擴展帶來的弊病，更專註於程序的開發上。

3.使用

　　MongoDB採用的是NoSQL的設計方式，可以更加靈活的操作數據。在進行傳統的RDBMS中你一定遇到過幾十行甚至上百行的複雜SQL語句，傳統的RDBMS的SQL語句中包含著大量關聯，子查詢等語句，在增加複雜性的同時還讓性能調優變得更加困難。MongoDB的面向文檔（document-oriented）設計中採用更為靈活的文檔來作為數據模型用來取代RDBMS中的行，面向文檔的設計讓開發人員獲取數據的方式更加靈活，甚至於開發人員僅用一條語句即可查詢複雜的嵌套關係，讓開發人員不必為了獲取數據而絞盡腦汁。

NoSQL對傳統資料庫設計思維的影響

1.預設計模式與動態模式

傳統資料庫設計思維中，項目的設計階段需要對資料庫表中的欄位名稱、欄位類型、進行規定，如果嘗試插入不符合設計的數據，資料庫不會接受這條數據以保證數據的完整性。

--資料庫欄位:NAME, SONGnnINSERT INTO T_INFO VALUES(John,Come Together); --成功nnINSERT INTO T_INFO VALUES(小明, 20, xiaoming@111.com); --失敗n

　NoSQL採用的是對集合（類似"表"）中的文檔（類似於"行"）進行動態追加，在創建集合之初不會對數據類型進行限定，任何文檔都可以追加到任何集合中去，例如我們可以將這樣兩條文檔添加到一個集合中去：

{"name" : "John", "song" : "Come Together"}nn{"name" : "小明", "age":"20", "email" : "xiaoming@111.com"}n

　　MongoDB中文檔的格式類似於我們常見的JSON，由此可見，我們第一個擁有"name"、"song"兩個欄位，而第二個擁有"name"、"age"、"email"三個欄位，這在預設計模式中的資料庫是不可能插入成功的，但在MongoDB的動態模式是可以的，這樣做的優勢是我們不必為一些數量很少，但種類很多的欄位單獨設計一張表，可以將他們集中在單獨一張表進行存儲，但這樣做的弊病也是顯而易見的，我們在獲取數據時需要對同一張表的不同文檔進行區分，增加了開發上的代碼量。所以在設計之初需要權衡動態模式的優劣來選擇表中的數據類型。

2.範式化與反範式化

範式化（normalization）是關係模型的發明者埃德加·科德於1970年提出這一概念，範式化會將數據分散到不同的表中，利用關係模型進行關聯，由此帶來的優點是，在後期進行修改時，不會影響到與其關聯的數據，僅對自身修改即可完成。

反範式化（denormalization）是針對範式化提出的相反理念，反範式化會將當前文檔的數據集中存放在本表中，而不會採用拆分的方式進行存儲。

　　範式化和反範式化之間不存在優劣的問題，範式化的好處是可以在我們寫入、修改、刪除時的提供更高性能，而反範式化可以提高我們在查詢時的性能。當然NoSQL中是不存在關聯查詢的，以此提高查詢性能，但我們依舊可以以在表中存儲關聯表ID的方式進行範式化。但由此可見，NoSQL的理念中反範式化的地位是大於範式化的。

MongoDB還年輕

　　MongoDB又有眾多卓越的設計，但MongoDB依然存在著許多不擅長的問題，其中包括：

1. MongoDB不支持事務，現在眾多的軟體依舊需要事務的管理，所以對於事務一致性要求較高的程序只能在軟體層面進行管理，而無法從資料庫進行管理。

2. 其他工具的支持範圍，MongoDB從發布起到現在還不到5年的時間，所以會面臨著許多的語言沒有對應的工具包，所以如果你使用的語言沒有對應的包，可能是導致你無法使用MongoDB最大的阻礙。

3. 社區的資源量，這個問題同第二個問題一樣是因為MongoDB過於年輕導致的，相對於其他大型資料庫的社區而言，MongoDB顯然是無法與之相比的，然而社區往往也是一個重要考量因素之一，社區資源的匱乏會導致問題解決周期延長，從而拖延工作。

　　近幾年的技術發展之快是激動人心的，每年都會出現讓人眼前一亮的產品，然而它都需要經過時間的累積才能成為一個成熟的產品，MongoDB還需要成長，但他優秀的設計，肯定會讓越來越多的開發者接受它。

補充優點：遷移方便、地理坐標聚合、分散式存儲；這貨就是為大數據而生的。n

順手搜了一下2017年1月全球資料庫排名TOP 20：

DB-Engines：2017年1月全球資料庫排名TOP 20

膠水語言博大精深，

本主只得一二為新人帶路，

老鳥可去另一專欄：Python中文社區

新手可查閱歷史目錄：

Python數據分析及可視化實例目錄

最後，別只收藏不關注哈

推薦閱讀：