奇虎是中國最大的安卓移動發佈平台。奇虎也是中國最頂尖的病毒軟件防護公司，同時為網絡以及移動平台提供產品。自從2011年成為MongoDB的用戶之後，奇虎已經在MongoDB上構建了100多個不同的應用，其中包括新服務以及從MySQL和Redis上遷移過來的服務——每天都會在MongoDB上運行超過1, 500個實例並且支持200億次查詢。
我很高興能夠有一個機會與奇虎的高級DBA——楊豔傑進行交流，瞭解更多關於他們使用MongoDB的過程及原因、他們的最佳實踐以及為那些剛開始使用MongoDB的用戶提供的建議。
問：請您先向我們簡單介紹一下奇虎。
奇虎360技術有限公司是一個領先的中國互聯網公司。在2014年6月末，我們已經擁有了大約5億的月活躍電腦端互聯網用戶以及6.4億以上移動用戶。
將識別病毒軟件防護視為所有互聯網及移動用戶的一個基本需求，我們通過提供全方位高效、人性化的互聯網和移動安全產品及服務來保護用戶的電腦及移動設備，以防範病毒軟件及網站攻擊，最後形成了龐大的用戶基礎。我們的產品及服務由基於雲的安全技術支持，而在我們看來，這項技術是在病毒軟件防護產業最先進和健康的技術之一。我們通過為用戶集群提供在線廣告以及互聯網增值服務來盈利。
在市場地位方面，我們是：
就用戶基數而言，中國前三的互聯網公司；中國最大的基於安卓的移動發佈平台；中國最大的互聯網及移動病毒軟件防護產品及服務提供商；中國第二的個人電腦搜索引擎。
問：奇虎是什麼時候開始使用MongoDB的？
我們是MongoDB非常早的嘗試者，在2011年的時候就已經在MongoDB上構建了第一個應用。我想，那個時候我們使用的是MongoDB 1.8！
問：如今，奇虎如何使用MongoDB？
MongoDB已經成為我們標準的現代數據庫平台。我們已經在MongoDB上構建了一百多個應用——包括外部面向用戶的服務以及內部商業應用。
總的說來，在我們內部搭建的「HULK」雲平台上，每天都運行著1,500多個實例以及共計200億次查詢。
我們業務中三個特別典型的應用為：
基於位置的移動搜索應用。我們通過使用MongoDB的地理空間索引及查詢來向移動用戶發送基於地理的搜索結果。用戶有可能在搜索任何東西：從一個當地的飯店，到一輛車的代理權。該應用將會檢測到用戶的位置，然後基於距離為用戶提供索索結果。在這個應用中，MongoDB每天都會處理12億次的查詢。用戶認證數據的緩存層。對於很多中國網絡用戶而言，奇虎是一個核心的門戶網站。在登錄我們的網站之後，我們的用戶可以直接連接到其它許多合作網站。我們為用戶提供了多重服務的單點登錄（SSO），因此在瀏覽相關網站的過程中，用戶可以不需要一直提供他們的安全認證信息。為了更快地讀取，用戶的單點登錄會話被存儲到MongoDB中。MongoDB可以支持成千上萬的並行用戶，每秒鐘大致可以處理3萬個操作以及每天支撐18億次的查詢。日誌分析平台。我們需要瞭解業務是否在正常運行。此外，內部業務人員也希望通過新的促銷策略和活動來瞭解用戶的參與度。為了實現上述功能，我們從Linux、Apache網頁服務器以及Tomcat服務器上收集所有的日誌數據，並將其直接流式傳輸到MongoDB中。從上述數據中，公司內部的業務人員可以使用基於PHP的商務智能（BI）平台生成實時的分析及報表。在任何時候，MongoDB中在18個分片中存儲著25億的文檔，並且通過三個節點的複製集保證了實時的可獲得性。MongoDB每天都會為其處理10億次的寫操作。
問：您們還使用了什麼其它的數據庫？
MongoDB是我們使用較多的三種數據庫（MySQL,Redis,MongoDB）之一，但在一些場景中MongoDB並不適用。例如我們使用MySQL來解決關係型數據問題及一些需要事務的場景，使用Redis來解決一些高並發及緩存場景。隨著時間的推移，我們已經將一些更適合MongoDB的業務從MySQL和Redis遷移到MongoDB中。
問：什麼因素推動著這些遷移？
我們始終希望在每個場景中使用最適合該場景的數據庫，對於某些場景下的MySQL而言，遷移的原因是我們希望提高該場景下的數據庫可擴展性，例如在用戶量增長到億級的時候，在一些場景中MySQL的擴展性可能會成為瓶頸，因為作為一個關係型數據庫，MySQL無法簡單方便的進行擴展。
而另一些遷移是因為某些場景中的開發需求不夠確定或是變更頻繁，MongoDB的數據模型非常靈活。在這需求多變的場景中，我們的開發人員們使用MongoDB能夠實現更快的開發迭代。
對於Redis而言，遷移的兩個主要原因是：成本及靈活性。在一些QPS並不是很高的場景中，我們認為MongoDB能夠滿足此類需求。因為MongoDB使用磁盤存放數據，所以這對於使用內存來存放數據的Redis，遷移到MongoDB後我們能夠存放更多的數據並大大降低服務器成本。此外，相對於Redis的K-V模型我們可以使用MongoDB的文檔數據模型實現更多的功能。所以對於那些QPS並不是很高但數據體積很有可能快速增長的應用，我們會優先選擇MongoDB。
問：請您介紹一下在MongoDB上運行的平台。
我們的大部分應用都是基於PHP的，我們在x86的硬件上運行CentOS系統。此外，我們的MongoDB全部使用SSD並進行了標準化，這給我們帶來的很棒的性能。目前我們使用的是MongoDB 2.4版本以及最新的2.6版本。我們也非常期待即將到來的MongoDB 3.0。
問：您們是如何配置MongoDB的？
視應用的具體情況而定，複製集和分片集我們都有使用。我們的機房分佈在全國各地，主要機房在北京。為了提高災難恢復速度並降低本地機房的讀寫延遲，我們會將MongoDB部署在多個機房中。
在這種多機房的場景中，網絡質量是最不可控的。而MongoDB集群對網絡質量要求較高。所以對於關鍵應用，我們會在多個數據中心部署獨立的集群，並使用我們自己開發的集群間數據同步工具來維護多個MongoDB集群數據的一致性，這樣就能降低網絡質量帶來的影響，在機房間網絡中斷時仍然保持高可用。
問：您們如何管理MongoDB的部署？
我們使用HULK私有雲平台對所有的mongodb進行管理，HULK私有雲平台是支撐360重要業務線的技術平台，在最初起名的時候，我們希望它能夠讓我們的工程師踩在巨人的肩膀上成長–借助平台技術優勢加速產品開發的流程。所以最終我們使用了HULK這個綠巨人的名字。HULK目前提供了彈性Web、RDS、NoSQL、分佈式存儲等基礎服務，同時以開放平台的理念將360內部各團隊的技術成果進行平台化改進，為各業務線提供可以拿來即用的服務，並幫助業務線在效率和技術深度上得到很大提升。
MongoDB是HULK中非常重要的服務之一，為此我們在HULK上做了大量的功能開發，目前已經達到了較高的自動化程度：對於管理者而言，dba能夠通過HULK管理端進行一鍵部署、一鍵擴容（我們將大部分需要多個複雜步驟才能完成的工作變為了一鍵完成），而對應的備份、監控模塊都是全自動的，例如當你將一個新的mongoDB集群或是節點部署之後HULK會自動的為它們添加對應的監控、備份策略。而對於用戶（我們的後端開發工程師）而言，他們能夠通過HULK用戶端看到mongoDB的多種狀態，並能夠通過用戶端直接提交工單，在大多數場景下我們與工程師們已不需要通過IM、郵件來進行需求溝通，他們只需要在HULK點幾下鼠標，填幾個選項即可。
問：您們如何備份MongoDB？
我們使用一系列備份策略，具體由應用的恢復點目標及恢復時間目標決定：
全量備份：這是默認的備份方式。我們將會關閉一個複製集成員，然後進行備份。增量備份：我們開發了一套基於mongodb OPLOG的增量備份方案，其中有增量備份工具及恢復工具延遲複製：在某些特殊場景中，對數據恢復的時間有著很高的要求。所以對於該場景我們使用延遲複製策略來降低數據恢復時間。
問：您能和我們分享一下在擴展MongoDB基礎設施的最佳實踐嗎？
在這裡，我想和大家分享三個小建議：
儘量去瞭解業務的使用場景、數據量、QPS。開發通常會給出大致的需求，但通常這是非常不準確的，一個非常不準確的評估很可能導致後期手忙腳亂，所以我一般會在他們的需求上增加50%再進行評估。儘量使用SSD來承載對於請求耗時敏感的業務，因為MongoDB的內存管理原理導致它在大多數場景下很依賴磁盤性能，所以有時候DBA的辛苦調優及開發對於程序邏輯的反覆修改得到的收益遠不如換一塊SSD來的快。MongoDB的數據空間分配、使用方式導致在高寫入、刪除場景下會產生比較多的磁盤碎片，儘量關注磁盤碎片的體積並在適當的時候進行回收。
問：您是否衡量過MongoDB對您業務的影響？
是的，就業務上線週期而言，MongoDB給我們帶來影響的一個例子是一一公司業務線對於2014年發生在雲南省地震的響應速度。當時國內每一個人都希望瞭解到最新的消息，很多人希望能夠盡快聯繫到在地震災區的朋友及家人。公司認為實現該需求的最好方式是構建一個應用，並整合來自多個消息源的動態信息。
於是我們在地震發生後的那天上午就設計好了這個應用，開發同事們中午就寫好了代碼，下午該應用就正式發佈了。它從一個概唸到實際產生只用了不到一個工作日，MongoDB數據結構的靈活性幫了大忙！
問：您是否期待MongoDB 3.0？
在得到第一個候選版本發佈之後，我們就立即開始對MongoDB 3.0進行測試並且向MongoDB公司匯報了一些我們發現的BUG。
我們很期待文檔級的並發控制。這將進一步提高寫操作的可擴展性並滿足我們一些寫入密集業務的需求。此外，壓縮對我們而言也是一個非常好的功能。因為我們的MongoDB服務器全部使用了SSD，所以壓縮意味著我們在同一個磁盤上存儲更多的數據，這將大大降低我們的成本。
問：對於那些正在考慮在他們下一個項目上使用MongoDB的用戶，您有什麼建議？
MongoDB的文檔數據模型有著很高的靈活性，該特性為開發帶來了極大的便捷。但這同樣代表著更多的責任一一MongoDB的靈活性會讓開發變懶，請絕對不要濫用這種靈活性。我建議大家不要在一個集合中存儲多個維度或是數據結構變化太多的文檔，因為這將會使後期的維護變得異常複雜。將不同類型及結構的文檔分散存放在他們自己的集合中是正確的做法。我們為此開發了一個文檔掃瞄抽樣分析工具，它能夠找出異常的集合，比如該集合中的平均文檔體積過大、結構過於複雜、結構不規範等。然後我們會通知相關的開發人員，並協助他們進行調整。這就是我開始提到的地方。
