Python爬取數(shù)據(jù)后使用哪個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)數(shù)據(jù)比較好?

一般爬蟲使用的數(shù)據(jù)庫(kù)，是根據(jù)項(xiàng)目來(lái)定的。如需求方指定了使用什么數(shù)據(jù)庫(kù)、如果沒(méi)指定，那么決定權(quán)就在爬蟲程序員手里，如果自選的話，mysql 和mongodb 用的都是比較多的。但不同的數(shù)據(jù)庫(kù)品種有各自的優(yōu)缺點(diǎn)，不同的場(chǎng)景任何一種數(shù)據(jù)庫(kù)都可以用來(lái)存儲(chǔ)，但是某種可能會(huì)更好。比如如果抓取的數(shù)據(jù)之間的耦合性很高，關(guān)系比較復(fù)雜的話，那么mysql可能會(huì)是更好的選擇。如果抓取的數(shù)據(jù)是分版塊的，并且它們之間沒(méi)有相似性或關(guān)聯(lián)性不強(qiáng)，那么可能mongodb 會(huì)更好。

另外主流的幾種永久存儲(chǔ)數(shù)據(jù)庫(kù)，都是具備處理高并發(fā)、具備存儲(chǔ)大量數(shù)據(jù)的能力的，只是由于各自的實(shí)現(xiàn)機(jī)制不一樣，因此優(yōu)化方案也是不盡相同?？偨Y(jié)就是：數(shù)據(jù)庫(kù)的選擇盡量從項(xiàng)目的數(shù)據(jù)存在的特性來(lái)考慮，還有一個(gè)問(wèn)題就是開(kāi)發(fā)人員最擅長(zhǎng)那種數(shù)據(jù)庫(kù)。

MongoDB 是使用比較多的數(shù)據(jù)庫(kù)，這里以MongoDB 為例，大家需要結(jié)合自己真實(shí)開(kāi)發(fā)環(huán)境選擇。

原因：

1)與關(guān)系型數(shù)據(jù)庫(kù)相比，MongoDB 的優(yōu)點(diǎn)如下。

①弱一致性(最終一致)，更能保證用戶的訪問(wèn)速度舉例來(lái)說(shuō)，在傳統(tǒng)的關(guān)系型數(shù)據(jù)庫(kù)中，一個(gè)COUNT類型的操作會(huì)鎖定數(shù)據(jù)集，這樣可以保證得到“當(dāng)前”情況下的較精確值。這在某些情況下，例如通過(guò)ATM查看賬戶信息的時(shí)候很重要，但對(duì)于Wordnik說(shuō)，數(shù)據(jù)是不斷更新和增長(zhǎng)的，這種“較精確”的保證幾乎沒(méi)有任何意義，反而會(huì)產(chǎn)生很大的延 遲。他們需要的是一個(gè)“大約”的數(shù)字以及更快的處理速度。但某些情況下MongoDB 會(huì)鎖住數(shù)據(jù)庫(kù)。如果此時(shí)正有數(shù)百個(gè)請(qǐng)求，則它們會(huì)堆積起來(lái)，造成許多問(wèn)題。我們使用了下面的優(yōu)化方式來(lái)避免鎖定。每次更新前，我們會(huì)先查詢記錄。查詢操作會(huì)將對(duì)象放入內(nèi)存，于是更新則會(huì)盡可能的迅速。在主/從部署方案中，從節(jié)點(diǎn)可以使用“-pretouch”參數(shù)運(yùn)行，這也可以得到相同的效果。使用多個(gè)mongod 進(jìn)程。我們根據(jù)訪問(wèn)模式將數(shù)據(jù)庫(kù)拆分成多個(gè)進(jìn)程。

②文檔結(jié)構(gòu)的存儲(chǔ)方式，能夠更便捷的獲取數(shù)據(jù)。

對(duì)于一個(gè)層級(jí)式的數(shù)據(jù)結(jié)構(gòu)來(lái)說(shuō)，如果要將這樣的數(shù)據(jù)使用扁平式的，表狀的結(jié)構(gòu)來(lái)保存數(shù)據(jù)，這無(wú)論是在查詢還是獲取數(shù)據(jù)時(shí)都十分困難。

③內(nèi)置GridFS，支持大容量的存儲(chǔ)。

GridFS 是一個(gè)出色的分布式文件系統(tǒng)，可以支持海量的數(shù)據(jù)存儲(chǔ)。內(nèi)置了GridFS 了MongoDB，能夠滿足對(duì)大數(shù)據(jù)集的快速范圍查詢。

④內(nèi)置Sharding。

提供基于Range 的Auto Sharding 機(jī)制：一個(gè)collection 可按照記錄的范圍，分成若干個(gè)段，切分到不同的Shard 上。Shards 可以和復(fù)制結(jié)合，配合Replica sets 能夠?qū)崿F(xiàn)Sharding+fail-over，不同的Shard 之間可以負(fù)載均衡。查詢是對(duì) 客戶端是透明的。客戶端執(zhí)行查詢，統(tǒng)計(jì)，MapReduce等操作，這些會(huì)被MongoDB 自動(dòng)路由到后端的數(shù)據(jù)節(jié)點(diǎn)。這讓我們關(guān)注于自己的業(yè)務(wù)，適當(dāng)?shù)臅r(shí)候可以無(wú)痛的升級(jí)。MongoDB 的Sharding 設(shè)計(jì)能力較大可支持約20 petabytes，足以支撐一般應(yīng)用。

這可以保證MongoDB 運(yùn)行在便宜的PC 服務(wù)器集群上。PC 集群擴(kuò)充起來(lái)非常方便并且成本很低，避免了“sharding”操作的復(fù)雜性和成本。

⑤第三方支持豐富。(這是與其他的NoSQL 相比，MongoDB 也具有的優(yōu)勢(shì))

現(xiàn)在網(wǎng)絡(luò)上的很多NoSQL 開(kāi)源數(shù)據(jù)庫(kù)完全屬于社區(qū)型的，沒(méi)有官方支持，給使用者帶來(lái)了很大的風(fēng)險(xiǎn)。而開(kāi)源文檔數(shù)據(jù)庫(kù)MongoDB 背后有商業(yè)公司10gen 為其提供供商業(yè)培訓(xùn)和支持。

而且MongoDB 社區(qū)非?；钴S，很多開(kāi)發(fā)框架都迅速提供了對(duì)MongDB 的支持。不少知名大公司和網(wǎng)站也在生產(chǎn)環(huán)境中使用MongoDB，越來(lái)越多的創(chuàng)新型企業(yè)轉(zhuǎn)而使用MongoDB 作為和Django，RoR 來(lái)搭配的技術(shù)方案。

⑥性能優(yōu)越

在使用場(chǎng)合下，千萬(wàn)級(jí)別的文檔對(duì)象，近10G 的數(shù)據(jù)，對(duì)有索引的ID的查詢不會(huì)比mysql慢，而對(duì)非索引字段的查詢，則是全面勝出。mysql實(shí)際無(wú)法勝任大數(shù)據(jù)量下任意字段的查詢，而mongodb的查詢性能實(shí)在讓我驚訝。寫入性能同樣很令人滿意，同樣寫入百萬(wàn)級(jí)別的數(shù)據(jù)，mongodb 比我以前試用過(guò)的couchdb要快得多，基本10分鐘以下可以解決。補(bǔ)上一句，觀察過(guò)程中mongodb 都遠(yuǎn)算不上是CPU殺手。

2)Mongodb與redis相比較

①mongodb 文件存儲(chǔ)是BSON 格式類似JSON，或自定義的二進(jìn)制格式。

mongodb 與redis 性能都很依賴內(nèi)存的大小，mongodb 有豐富的數(shù)據(jù)表達(dá)、索引;最類似于關(guān)系數(shù)據(jù)庫(kù)，支持豐富的查詢語(yǔ)言，redis數(shù)據(jù)豐富，較少的IO，這方面mongodb優(yōu)勢(shì)明顯。

②mongodb 不支持事物，靠客戶端自身保證，redis 支持事物，比較弱，僅能保證事物中的操作按順序執(zhí)行，這方面 redis 優(yōu)于mongodb。

③mongodb 對(duì)海量數(shù)據(jù)的訪問(wèn)效率提升，redis 較小數(shù)據(jù)量的性能及運(yùn)算,這方面 mongodb性能優(yōu)于redis .monbgodb 有mapredurce 功能，提供數(shù)據(jù)分析，redis沒(méi)有，這方面 mongodb優(yōu)于redis。

Python興趣課程，0基礎(chǔ)Python 3天入門課程

   ·了解Python主流就業(yè)方向，把握最新熱點(diǎn)技術(shù)
   ·掌握Python的基礎(chǔ)語(yǔ)法及API調(diào)用
   ·能夠使用Python對(duì)數(shù)據(jù)獲取、使用和展示
   ·打造自己的數(shù)據(jù)分析項(xiàng)目并自動(dòng)生成工作報(bào)告