爬蟲爬下來的數據(100G級別，2000W以上數據量)用mysql還是mongodb存儲好？

12-28

MongoDB作為非關係型資料庫，其主要的優勢在於schema-less。由於爬蟲數據一般來說比較「臟」，不會包含爬取數據的所有field，這對於不需要嚴格定義schema的MongoDB再合適不過。而MongoDB內置的sharding分散式系統也保證了它的可擴展性。MongoDB的aggregation framework除了join以外可以完全替代SQL語句，做到非常快速的統計分析。而題主的100GB、20m數據量(5k per record)，據我的經驗，這對於MongoDB來說不是太大問題，需要全局統計的話就做sharding＋自帶的Map Reduce進行優化，需要filter的話就做索引（前人也提到MongoDB的查詢速度是MySQL不能比的），而且需要join的概率也不大（不需要normalize）。

總而言之，主要看你用來做什麼，如果是簡單的raw data儲存直接存誠txt文件，後續載入到HDFS都可以。如果是數據倉庫設計的話，MySQL可以作為一個輕量級的aggregate table載體，作為OLAP的後端數據源。

反正，在這種情況下，我是看不到MySQL單純用做儲存的必要。

well，
這個量級，且用處來看，mysql or mongo 都無所謂，區別不大。
不過你既然爬蟲的數據，就會要跟著源數據結構變動而變動，mongo的模式就會更方便適合些
BTW
樓上 @一字騰雲朋友所說「查詢起來速度比較快些，雖然mysql也可以通過創建索引可以加快速度，但和mongodb相比之下，還不是一個級別的」，有一點小問題。
這個嘛。。。一般資料庫的需求都需要索引嘛。
我們要知其所以然。
Mongo快的原因主要有以下幾點：
寫：
-3.0以前是mmap ，內存映射模式，寫入數據時候在內存里完成後就是可以返回的，這樣並發會高，當然也有各種級別的安全寫級別，應對不同的安全需求。
-3.0之後，WT引擎其MVCC機制更是大幅度提高了寫效率，多版本控制機制提高了並發，降低了鎖的粒度。

讀：
MongoDB 與mysql不同，文檔型的結構設計使同一條document中的內容在連續的位置內（內存啊，硬碟啊）。而關係型資料庫需要把數據從各個地方找過來，join啊之類的，減少了隨機io。

Mongo的設計模式也會讓我們儘可能的把working set能在ram中裝下。

3.0以後WT的MVCC也大幅度提高了效率。

然後，
sharding的存在，讓我們對於帶有shard key的讀與寫都有了橫向水平擴展的能力，也提高了效率。

Mysql和mongodb之間的區別

Mysql是關係型資料庫
Mongodb是非關係型資料庫
而且mongodb支持集群化存儲。另外，查詢起來速度比較快些，雖然mysql也可以通過創建索引可以加快速度，但和mongodb相比之下，還不是一個級別的

這個問題是釣魚吧...
存100G，2KW條數據隨便一個資料庫都妥妥的，真正用來做選擇的是要怎麼用...

首先，數據大了，存儲絕對不是一件容易的事，要考慮很多因素。

爬蟲爬下來的大量數據，存在關係型資料庫里往往不是很恰當的，因為當數據量和並發很大時，關係型資料庫的容量與讀寫能力會是瓶頸，另一方面，爬蟲保存的頁面信息之間一般也不需要建立關係。

比較好的做法應該是存在列族資料庫類型的Nosql里。Google的BigTable論文里就提出了使用BigTable存儲網頁信息，開源的列族資料庫，像HBase、Cassandra也都很適合存儲這類信息。每爬一個網頁，構造一個Key（比如是倒排域名的url，或者是散列的key）和一系列Column（網頁內容等），插到HBase的里，作為一行。

有一套較通用的大規模分散式爬蟲方案是Nutch + Gora + HBase + Solr／Elasticsearch，爬蟲爬的數據通過Gora作為數據抽象層存在HBase里，然後導入Solr或者Elasticsearch里建立索引。也可以通過Gora執行MapReduce或者導入Spark進行計算。

但是上述方案其實並不適合普通的開發者，因為搭建和維護HBase是很繁瑣的，引入很多學習成本，遇到問題還要排查。重要的是這跟爬蟲毫無關係啊，完全是存儲問題。

所以我最終推薦的是雲的方案，阿里雲的OTS是一個類似HBase的Nosql資料庫，成本低、讀寫性能好，非常適合爬蟲這個場景：

不需要自己搭建與運維，開通實例即可使用，完全不用擔心規模問題。
按照讀寫預留能力收費，爬蟲爬的時候讀寫預留能力調上去，爬完了讀寫預留能力調下來。
存儲成本非常低。
數據存在OTS上，計算資源就可以彈性的擴容或者縮減。舉個例子，假如爬蟲爬的時候要使用很多雲伺服器，等爬蟲爬完了，這些伺服器就可以及時釋放；另一方面，如果要對爬下來的數據做分析計算，也只需要在計算的時候購買雲伺服器，從OTS中把數據導下來，計算完成伺服器即可釋放。

開放結構化數據服務OTS_海量數據存儲

利益相關：OTS開發

那個熟悉用那個。

首先，你就目前數據量來講，並不大。
那需要考慮什麼呢？
1.數據使用頻度
你是僅僅存放呢，還是經常查詢呢？全量讀取呢？
2.數據更新頻率及量級
你目前是100G數據，那你3個月內呢，半年內呢，1年呢？
3.應用場景
你是1S內必須查詢出來呢，還是無所謂呢。是有具體的數據規格呢還是沒有呢。
我覺得你可以寫下上面3個問題在考慮具體用什麼資料庫及怎麼實施。正常來講，爬蟲爬取的數據都不是規整的，所以會先存放至臨時庫，後經ETL清洗後，存放在正式資料庫。不同的階段，對應的資料庫也不同。如果僅僅只是存放的話，mysql還是mongodb影響都不大。

Cassandra 妥妥的，latency 和 throughput 完爆mongoDB. 需要analytics 就上spark，想怎麼分析怎麼分析。全部scalable，維護成本低。

我們大概每天300W+下載量，目前策略是正文放hbase里(hadoop集群)，統計關係表放mysql集群里，中間有一些緩存中間件（memcached、redis和MQ之類的）用來緩存url信息。

量級太小，用什麼都差不多，對mysql熟悉就用mysql，如果不熟悉就用mongo，畢竟mongo是不用設計的資料庫，mysql可不是。要是連索引都不會加，爬蟲去重的時候就可以死了。。。

2000w並不算多，mysql扛得住

2kw應該都可以，不過mongo應該好點，畢竟單機就可以解決。

mongo

沒有schema的嚴格定義，json存取
爬蟲的欄位會經常變化，欄位定義可能會變更，mongo就對這方面很寬鬆
mongo是文檔型的，天生為海量數據存儲準備
可以很輕鬆的橫向擴展，分片，複製集群分分鐘

使用mongo也有坑，3.2之後就換了新的WiredTiger引擎，占的內存略坑，對於沒有太多query的存的資料庫來看，內存還是會偶爾斷片，沒關係，在上面套一個docker ，還是一樣很方便。

另外如果你對爬蟲有興趣的話，這裡有教程：
http://brucedone.com/archives/771

都是些什麼數據？拿到後做什麼處理？query pattern是啥？
一般join, filter多的用mysql.整塊數據讀的用mongo.
要是簡單的話plain text JSON也不錯。

存不是太大問題吧，主要要看你咋用啊？

Hbase是首選。大數據處理框架基本上能夠和Hbase適配。用分步處理的思路。
1、抓取原始的html，包括包含js的頁面，用selenium類plugin即可。（所有目標頁面的信息都在這裡了）
2、用mapreduce，spark etc工具抽取需要的數據，存儲目標還是Hbase，但此時數據已經有schema了。
3、對於已經有schema的數據，用hive，phoenix等作分析。

這樣整過流程都圍繞Hbase進行，PB級別也沒問題吧。

100Gb數據怎麼只有兩千萬條？

用TerarkDB吧...高壓縮高查詢...
首頁 - Terark · 重新定義數據技術

這個量很小，如果以後不漲就可以選一個自己喜歡的。如果以後可能漲，那麼看看BigTable的論文裡面有google的網頁數據的存儲思路，開源實現是Hbase，服務實現是阿里雲表格存儲。

kafka。
把爬下來的數據當消息日誌丟給kafka後，你可以導入mysql或者hadoop平台，或者storm流式系統等計算框架。