电竞比分网-中国电竞赛事及体育赛事平台

分享

mongodb小結(jié) – 不周山

 xmlostg 2010-06-13

mongodb小結(jié)

用了一陣子mongodb,作一些小結(jié),作為將來的參考。按照以往的習慣,先作一個總覽,然后再挑出一些自己比較關(guān)注的幾個點,作為珠璣,加以串聯(lián)闡述。

mongodb由C++寫就,其名字來自humongous這個單詞的中間部分,從名字可見其野心所在就是海量數(shù)據(jù)的處理。關(guān)于它的一個最簡潔描述為:scalable, high-performance, open source, schema-free, document-oriented database。我對于文檔型數(shù)據(jù)庫有一些個人的偏好,這種偏好是從半年前研究couchdb而來的,因為我覺得用它來描述一個具有個性化特征的實體對象正合適,比如網(wǎng)站上的用戶或商品書籍之類的條目。

一些概念:

跟mysqld一樣,一個mongod服務(wù)可以有建立多個數(shù)據(jù)庫,每個數(shù)據(jù)庫可以有多張表,這里的表名叫collection,每個collection可以存放多個文檔(document),每個文檔都以BSON(binary json)的形式存放于硬盤中。跟關(guān)系型數(shù)據(jù)庫不一樣的地方是,它是的以單文檔為單位存儲的,你可以任意給一個或一批文檔新增或刪除字段,而不會對其它文檔造成影響,這就是所謂的schema-free,這也是文檔型數(shù)據(jù)庫最主要的優(yōu)點。跟一般的key-value數(shù)據(jù)庫不一樣的是,它的value中存儲了結(jié)構(gòu)信息,所以你又可以像關(guān)系型數(shù)據(jù)庫那樣對某些域進行讀寫、統(tǒng)計等操作。可以說是兼?zhèn)淞薻ey-value數(shù)據(jù)庫的方便高效與關(guān)系型數(shù)據(jù)庫的強大功能。

索引

跟關(guān)系型數(shù)據(jù)庫類似,mongodb可以對某個字段建立索引,可以建立組合索引、唯一索引,也可以刪除索引。當然建立索引就意味著增加空間開銷,我的建議是,如果你能把一個文檔作為一個對象的來考慮,在線上應(yīng)用中,你通常只要對對象ID建立一個索引即可,根據(jù)ID取出對象某些數(shù)據(jù)放在memcache即可。如果是后臺的分析需要,響應(yīng)要求不高,查詢非索引的字段即便直接掃表也費不了太多時間。如果還受不了,就再建一個索引得了。

默認情況下每個表都會有一個唯一索引:_id,如果插入數(shù)據(jù)時沒有指定_id,服務(wù)會自動生成一個_id,為了充分利用已有索引,減少空間開銷,最好是自己指定一個unique的key為_id,通常用對象的ID比較合適,比如商品的ID。

capped collection

capped collection是一種特殊的表,它的建表命令為:

db.createCollection("mycoll", {capped:true, size:100000})

允許在建表之初就指定一定的空間大小,接下來的插入操作會不斷地按順序APPEND數(shù)據(jù)在這個預(yù)分配好空間的文件中,如果已經(jīng)超出空間大小,則回到文件頭覆蓋原來的數(shù)據(jù)繼續(xù)插入。這種結(jié)構(gòu)保證了插入和查詢的高效性,它不允許刪除單個記錄,更新的也有限制:不能超過原有記錄的大小。這種表效率很高,它適用于一些暫時保存數(shù)據(jù)的場合,比如網(wǎng)站中登錄用戶的session信息,又比如一些程序的監(jiān)控日志,都是屬于過了一定的時間就可以被覆蓋的數(shù)據(jù)。

復制與分片

mongodb的復制架構(gòu)跟mysql也很類似,除了包括master-slave構(gòu)型和master-master構(gòu)型之外,還有一個Replica pairs構(gòu)型,這種構(gòu)型在平常可以像master-slave那樣工作,一但master出現(xiàn)問題,應(yīng)用會自動了連接slave。要做復制也很簡單,我自己使用過master-slave構(gòu)型,只要在某一個服務(wù)啟動時加上–master參數(shù),而另一個服務(wù)加上–slave與–source參數(shù),即可實現(xiàn)同步。

分片是個很頭疼的問題,數(shù)據(jù)量大了肯定要分片,mysql下的分片正是成為無數(shù)DBA的噩夢。在mongodb下,文檔數(shù)據(jù)庫類似key-value數(shù)據(jù)庫那樣的易分布特性就顯現(xiàn)出來了,無論構(gòu)造分片服務(wù),新增節(jié)點還是刪除節(jié)點都非常容易實現(xiàn)。但mongodb在這方面做還不足夠成熟,現(xiàn)在分片的工作還只做到alpha2版本(mongodb v1.1),估計還有很多問題要解決,所以只能期待,就不多說了。

性能

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

GridFS

gridfs是mongodb一個很有趣的類似文件系統(tǒng)的東西,它可以用一大塊文件空間來存放大量的小文件,這個對于存儲web2.0網(wǎng)站中常見的大量小文件(如大量的用戶頭像)特別有效。使用起來也很方便,基本上跟一般的文件系統(tǒng)類似。

用合適的數(shù)據(jù)庫做適合的事情

mongodb的文檔里提到的user case包括實時分析、logging、全文搜索,國內(nèi)也有人使用mongodb來存儲分析網(wǎng)站日志,但我認為mongodb用來處理有一定規(guī)模的網(wǎng)站日志其實并不合適,最主要的就是它占空間過于虛高,原來1G的日志數(shù)據(jù)它可以存成幾個G,如此下去,一個硬盤也存不了幾天的日志。另一方面,數(shù)據(jù)量大了肯定要考慮sharding,而mongodb的sharding到現(xiàn)在為止仍不太成熟。由于日志的不可更新性的,往往只需APPEND即可,又因為對日志的操作往往只集中于一兩列,所以最合適作為日志分析的還是列存儲型的數(shù)據(jù)庫,特別是像infobright那樣的為數(shù)據(jù)倉庫而設(shè)計的列存儲數(shù)據(jù)庫。

由于mongodb不支持事務(wù)操作,所以事務(wù)要求嚴格的系統(tǒng)(如果銀行系統(tǒng))肯定不能用它。

mongodb占用空間過大的原因,在官方的FAQ中,提到有如下幾個方面:

1、空間的預(yù)分配:為避免形成過多的硬盤碎片,mongodb每次空間不足時都會申請生成一大塊的硬盤空間,而且申請的量從64M、128M、256M那樣的指數(shù)遞增,直到2G為單個文件的最大體積。隨著數(shù)據(jù)量的增加,你可以在其數(shù)據(jù)目錄里看到這些整塊生成容量不斷遞增的文件。

2、字段名所占用的空間:為了保持每個記錄內(nèi)的結(jié)構(gòu)信息用于查詢,mongodb需要把每個字段的key-value都以BSON的形式存儲,如果value域相對于key域并不大,比如存放數(shù)值型的數(shù)據(jù),則數(shù)據(jù)的overhead是最大的。一種減少空間占用的方法是把字段名盡量取短一些,這樣占用空間就小了,但這就要求在易讀性與空間占用上作為權(quán)衡了。我曾建議作者把字段名作個index,每個字段名用一個字節(jié)表示,這樣就不用擔心字段名取多長了。但作者的擔憂也不無道理,這種索引方式需要每次查詢得到結(jié)果后把索引值跟原值作一個替換,再發(fā)送到客戶端,這個替換也是挺耗費時間的。現(xiàn)在的實現(xiàn)算是拿空間來換取時間吧。

3、刪除記錄不釋放空間:這很容易理解,為避免記錄刪除后的數(shù)據(jù)的大規(guī)模挪動,原記錄空間不刪除,只標記“已刪除”即可,以后還可以重復利用。

4、可以定期運行db.repairDatabase()來整理記錄,但這個過程會比較緩慢。

因為官方文檔中對各方面的內(nèi)容已經(jīng)有很詳細的敘述,所以我并沒有再過多的引用原文與代碼,只是結(jié)合自己的使用歸納一些心得,有興趣的朋友不妨直接去翻文檔中自己感興趣的問題,超群的博客上有一個很好的入門介紹。

最后總結(jié)一句,文檔型數(shù)據(jù)庫有點像波粒二象性,總能在適當?shù)臅r候表現(xiàn)出它作為關(guān)系型數(shù)據(jù)庫或key-value數(shù)據(jù)庫的優(yōu)勢來。

實戰(zhàn)案例:

昨天我訪問mongodb的python程序開始出錯,經(jīng)常拋出AssertionError異常,經(jīng)查證只是master查詢異常,slave正常,可判斷為master的數(shù)據(jù)出了問題。

修復過程:

1、在master做db.repairDatabase(),不起作用;

2、停止slave的同步;

3、對slave作mongodump,備份數(shù)據(jù);

4、對master作mongostore,把備份數(shù)據(jù)恢復,使用–drop參數(shù)可以先把原表刪除。

5、恢復slave的同步。

    本站是提供個人知識管理的網(wǎng)絡(luò)存儲空間,所有內(nèi)容均由用戶發(fā)布,不代表本站觀點。請注意甄別內(nèi)容中的聯(lián)系方式、誘導購買等信息,謹防詐騙。如發(fā)現(xiàn)有害或侵權(quán)內(nèi)容,請點擊一鍵舉報。
    轉(zhuǎn)藏 分享 獻花(0

    0條評論

    發(fā)表

    請遵守用戶 評論公約

    類似文章 更多