217      阿裏雲  技術社區[雲棲]

多方位拓展之路：監控平台MongoDB實踐

多方位拓展之路：監控平台MongoDB實踐

  摘要：在“監控平台MongoDB實踐”上，千尋位置的技術專家肖應軍從MongoDB的使用場景等方麵細致而全麵地講述了MongoDB基本現狀和技術要點，分享了其統一監控平台使用 MongoDB 的實踐經驗,介紹了MongoDB未來的發展計劃和研究方向。

他的演講內容主要分為四個方麵：1. 使用MongoDB的原因及 MongoDB的現狀2.MongoDB的使用場景有哪些？

3.監控平台MongoDB實踐中有哪些經驗值得參考？4.MongoDB接下來的研究方向側重哪些方麵？

以下是根據現場演講和PPT的整理內容

  一、為什麼使用MongoDB以及MongoDB的現狀又如何呢？

   MongoDB早在11,12年時便首次提出，當時QA數據庫剛開始流行起來，有人評論MongoDB數據庫是最傾向於QA數據庫的數據庫，關於這個說法有兩點說明，首先，MongoDB傾向於關係型數據庫是因為其速度快，無論寫或讀，都會最大可能的使用內存。關係數據庫最明顯的特征之一是有各種各樣複雜的事務隔離級別，保證高頻發情況下數據的一次性，而在寫多讀少且沒有事務的場景下，則恰好利用了MongoDB這個特點。其次，MongoDB雖傾向於關係型數據庫但並不是強調它的關係型，也就是說MongoDB在關係型上有別於QA數據庫。第一個不同之處在於MongoDB有行有列，這是區別於QA數據庫的最明顯的特征，第二個不同點是MongoDB的數據不固定，為什麼呢？首先，阿裏雲是一個通信公司，其次，監控係統本身數據來源很廣，有技術監控以及運營監控和應用監控，且應用監控的變化最大，所以數據結構不穩定成為了一個非常明顯的特征，而MongoDB沒有固定的數據結構，這恰好成為它本身的獨到優勢，當需要把監控數據做成列表以及曲線圖、餅圖和散點圖等各種各樣可視化的方式時， MongoDB非固定的數據結構便完美的配合了可視化的需求，這是選用MongoDB作為主要存儲工具的原因。

目前，MongoDB的現狀是每天大約存儲十億條數據，平均為每秒鍾存儲一萬條，每日增量達到了20G+之多，並用到了四套複製集用以實現雲加工。

二、MongoDB的使用場景

    MongoDB的使用場景有三：監控數據、業務數據和報表計算。隨著業務量的增長業務數據逐漸龐大進而成為最頻繁的使用場景，下麵具體探討各種使用場景下的數據特點同時對比不同場景下數據的異同點。

   1.  監控數據

      監控數據最為明顯的場景是數據沒有寫入高峰，並且采樣平穩，隻會根據機器和應用的場景多少來增加量，本身不會隨著用戶的增長而增長，所以監控數據特點一是數據量不會呈現出爆發式的增長，而是線性增長的趨勢。特點二，由於做報表或數據可視化時經常會長區間的拉數據，使得返回數據量很大，但是讀取的並發率卻很低，再一次說明MongoDB對於寫多讀少的場景十分適用。特點三 ，隨著時間的積累，監控數據會越來越多，此時常需要用到TTL索引——時間過激索引，TTL索引是MongoDB特別引進的，目前隻為MongoDB所獨有，其他數據庫並不具備。特點四，抽稀算法。在監控數據時常用RRD 數據庫存儲數據，主要原因在於它具有很強的抽稀能力，所以目前若想使用MongoDB，則需要自身去實現這個算法。那麼，抽稀算法的重要之處到底在哪裏呢？例如，正常情況下，看一兩天的數據趨勢可能會把數據一分鍾一分鍾的拉出來，但是如果連續看一個月那麼一分鍾一分鍾的展示是不可能實現的，這時候抽稀算法的重要性便凸顯出來，目前MongoDB已成功實現了一套抽稀算法。

   2.業務數據

    業務數據跟監控數據差別很大，第一點，隨著用戶的增長，用戶的行為會導致業務數據瞬間峰值非常高，所以業務數據具有數據峰值；第二，業務數據的定期查詢也會增加。做報表時很多的定時任務會使業務數據的查詢頻次驟增，針對這個問題需要一係列解決方案，例如：隊列削峰，而隊列削峰又是通過什麼實現的呢？最初的途徑是使用JAVA本地的Q實現隊列削峰，而現在則是利用統一寫入層實現削峰。第三，監控數據與業務數據在模型上也有所差異，監控數據通過Agent—Service—Mongo Replset模型進行存儲，而業務數據則是利用Queue收數據，其主要目的也是實現隊列削峰。

   3.報表計算

   監控數據和業務數據主要是兩個存儲場景，而報表計算則是對數據加以利用，隨著業務量的逐步增長，報表計算的發展經曆了兩個階段，第一個階段時數據量不是很大，單次報表源數據在百萬級以下，這種情況下一套簡單的架構便可以實現，例如Mongo自帶的AGM功能，這種場景對硬件資源較少、沒有大規模集成框架的創業初期或數據量不是很大時更為簡單靈活，能夠快速實現需求、快速響應。這些功能基本上都是由JAVA實現的，屬於Mongo的自身功能，所以並發性等問題可以巧妙地避免。然而，使用這種方式時也有一些事項值得注意，Mongo目前利用AGM這三個軟件架構實現聚合功能，Aggregate是輕量級的聚合功能，適用於單列或者簡單的聚合且速度非常快，例如，求最大值、最小值和平均值等簡單運算，隻需要一個socket語句就可以實現。當需要完成複雜邏輯時，Aggregate顯然不能勝任，此時就要用到Groupby和Mapreduce，由於Mapreduce和AMI模型是一樣的，所以兩者相比，Mapreduce的功能更強大，但當前場景下，主要是用Groupby架構來實現聚合功能，這是為什麼呢？問題就在於Mapreduce隻支持sharding，而Groupby則是把查詢的數據及結果一行一行地傳給函數，函數逐一處理，所以Groupby雖功能不如Mapreduce強大，但大部分情況下是可以滿足數據聚合的功能。同時，Groupby的使用也有注意事項，Mongo數據的結構是bson, 且最終返回的值同樣通過bson形式返回，而bson的要求之一是當一個返還的結構體超過64k時便無法實現，總之，要根據實際的情況選擇合適的方法來完美地實現功能。

以上是報表一期使用的一整套架構方案，總結來說，報表一期適用於數據在百萬級以下的情況，若超過百萬，整個複製集就會出現不穩定因素，此時就需要監控報警，更複雜情況下甚至需要修改方案。隨著業務的增長，業務數據量越來越大，出現了億級、十億級甚至百億級，繁多的業務報表隨之出現，統計周期發生變化變化，從小時報到天報到周報再到月報，而統計頻次逐漸升高，從小時報到分鍾報甚至是秒報。顯而易見前麵的一套方案已經不再適合了，亟待設計一套新的架構方案來應對愈加龐大的數據量和業務報表，報表二期應運而生。

  第二階段的方案架構分為四部分，第一部分以Service直接寫入，第二部分是阿裏雲的SLS服務，SLS的速度非常快，即使是千萬級的數據也僅僅需要秒級的延遲，一般情況下不會出現問題。在SLS服務下，第三方應用隻需要把日誌打入本地磁盤，阿裏雲收集後把數據分發到Mongo或ODPS裏即可，這是目前的采集模型，除增加了SLS模型外與第一階段並無太大變化。第三部分由Metric Mongo Replset和Report Mongo Replset兩個複製集構成，Metric Mongo Replset是一套存儲原始數據的Mongo複製集，而Report Mongo Replset則是用來存儲報表的結果數據，兩者不同之處在於，Metric Mongo Replset中會有大量數據的寫入，導致TTL索引應用較為頻繁，而Report Mongo Replset則是查詢操作占主要部分。第四部分是兩個大規模集成框架——EMR和ODPS，先來說ODPS，這裏既用到它的大數據集成框架也用到它的存儲功能，所以在要求原始數據的場景的情況下一般會存儲到ODPS裏，如果隻是用來快速查詢且保護時間不需要太久的話，一般會把它存放在 Mongo ，這也是把 Mongo 和ODPS放到同一層級的原因，ODPS本身具有的大數據計算功能使得有些報表同樣可以利用ODPS計算。再來說EMR，到了目前階段特別是需要做秒級報表時，ODPS的缺陷便顯現出來了，而EMR更為強大的功能則能適時填補ODPS的缺陷。在報表計算第二階段的架構下，同樣有一些注意事項，例如，EMR如何跟 Mongo驅動呢？這裏就用到了connector來實現這一功能，Mongo-spark-connector是 Mongo官方推薦的一套connector，在使用Mongo-spark-connector時會用到兩個partitioner，這裏簡單介紹MongoSamplePartitioner和MongoShardedPartitioner兩種。前文介紹過，利用JAVA方式查報表的方式是單行層拉數據，所以若使用多線程就會涉及到各種各樣分區的概念和問題，而Mongo-spark-connector恰好解決了這個問題，即Mongo-spark-connector會在讀取數據時根據spark模型的數量直接分區，一般來說分區有很多種，但在Mongo做數據源的場景下，按照Mongo文檔的概念來分區更為易於人們使用，例如，按分頁來分區，每頁十個。所以Mongo分段的特性提供了一係列的Partitioner，複製集中用到了簡單的MongoSamplePartitioner，當然還可以根據實際場景選擇其他的Partitioner。

   三、實踐經驗

   肖應軍專家分享了其統一監控平台使用 MongoDB 的實踐經驗。

  ·一主二從

  複製集在一般情況下一主一從便足夠，但是複製集承受較大壓力時，最好還是一主二從，從而避免各種問題的發生。

 ·慢查詢導致鎖庫

  當習慣用關係型數據庫時，慢查詢可能會導致鎖庫就成為了一個極易容易忽略的問題，在關係型數據庫中模型搜素語句變慢會導致鎖表，高級的數據庫會鎖行，但是Mongo可能會直接鎖 庫，特別是在慢查詢情況下，要注意防止鎖庫現象的發生。

 ·寫入壓力大導致整個庫響應慢

 ·新增索引{backgroud:true}

 利用新增索引{backgroud:true}在後台進行索引不會導致前台數據庫寫入變化而使索引變化， 以避免鎖庫。

 ·監控工具grafana

 grafana是一個開源的監控工具，布好後，讀入寫入以及文檔更新等監控指標就會顯示出來，是一個成本很低的監控方案。

 ·寫Mongo批處理腳本時，避免使用lord命令，推薦使用mongo--shell a.js寫批處理腳本。

 ·TTL索引必須使用Date類型字段

 在不特別注意的情況下，寫入Mongo裏的數據是longer類型字段，而TTL索引必須使用Date類型字段，解決方法是可以針對Date類型自己寫一個序列化的方法。

 ·連接驅動WriteConcern,推薦W1

 使用複製集情況下通常會遇到一個主從問題，即“主”寫入而“從“還未同步的情況，Mongo官方推薦的WriteConcern可以解決這個問題，其中W1類型是”從“寫入即認為全部寫入，適用於多數場景。

 ·基於ECS自建MongoReplset的IOPS上限                        

 普通雲盤：3000，SSD：10000

   當用戶數據量或業務數據量達到一秒十萬、百萬時就會出現各種各樣的問題，推薦使用阿裏雲的產品，因為自己運維成本較高，其中最主要的問題體現在數據的存儲上，目前是使用虛擬機，之後要采用實體機乃至SSD高效磁盤來解決數據存儲上存在的問題，由於CPU、內存等可能都要應用實體機完成，所以部分問題仍能夠得以解決的。

    四、Mongo進一步的開發計劃

    Mongo未來的研究方向：

    首先，針對位置數據主要探索一些技術相關的搜索引擎，即未知數據相關引擎-GIS。其次是與監控特性相關的時序數據庫相關引擎-TSDB，一些最基本的技術監控會隨著時間的推移而產生數據的變化，此時便經常會用到時序數據庫來存儲這一類的數據。然後，目前的單台複製集數據量最快能達到一秒一萬，當達到一秒十萬時，無論如何分工、分表、分業務，能達到的數據量都是有限的、無法滿足需求的，此時Sharding的應用便顯得至關重要了。最後是跨機房與異地雙活，目前阿裏雲已經實現了這些功能，使用方便。

最後更新：2017-04-19 23:31:08

  上一篇： MongoDB使用實踐：媽媽幫平台技術架構

  下一篇： 阿裏雲智能語音交互技術實踐幹貨分享