基于MongoDB的大規(guī)模高頻金融交易數(shù)據(jù)處理

1、巨建華：基于MongoDB的大規(guī)模高頻金融交易數(shù)據(jù)處理發(fā)表于2011-11-26 12:00|4760次閱讀| 來源CSDN|0條評論| 作者CSDNmongodb應用服務器數(shù)據(jù)分析數(shù)據(jù)挖掘金融摘要：巨建華認為高頻金融交易數(shù)據(jù)的主要特點是實時性和大規(guī)模，目前滬深兩市每天4個小時的交易時間會產(chǎn)生3億條以上逐筆成交數(shù)據(jù)，隨著時間的積累數(shù)據(jù)規(guī)模非?？捎^，與一般日志數(shù)據(jù)不同的是這些數(shù)據(jù)在金融工程領域有較高的分析價值，金融投資研究機構需要經(jīng)常對歷史和實時數(shù)據(jù)進行挖掘創(chuàng)新，以創(chuàng)造.時至今日，“Big data”（大數(shù)據(jù)）時代的來臨已經(jīng)毋庸置疑，尤其是在電信、金融等行業(yè)，幾乎已經(jīng)到了“數(shù)據(jù)就是業(yè)務本身”的地

2、步。這種趨勢已經(jīng)讓很多相信數(shù)據(jù)之力量的企業(yè)做出改變。恰逢此時，為了讓更多的人了解和使用分析大數(shù)據(jù)，CSDN獨家承辦的大數(shù)據(jù)技術大會于今日在北京中旅大廈召開。本次大會匯集Hadoop、NoSQL、數(shù)據(jù)分析與挖掘、數(shù)據(jù)倉庫、商業(yè)智能以及開源云計算架構等諸多熱點話題。包括百度、淘寶、新浪等業(yè)界知名專家與參會者齊聚一堂，共同探討大數(shù)據(jù)浪潮下的行業(yè)應對法則以及大數(shù)據(jù)時代的抉擇。技術總監(jiān)巨建華巨建華認為高頻金融交易數(shù)據(jù)的主要特點是實時性和大規(guī)模，目前滬深兩市每天4個小時的交易時間會產(chǎn)生3億條以上逐筆成交數(shù)據(jù)，隨著時間的積累數(shù)據(jù)規(guī)模非?？捎^，與一般日志數(shù)據(jù)不同的是這些數(shù)據(jù)在金融工程領域有較

3、高的分析價值，金融投資研究機構需要經(jīng)常對歷史和實時數(shù)據(jù)進行挖掘創(chuàng)新，以創(chuàng)造和改進數(shù)量化交易模型，并將之應用在基于計算機模型的實時證券交易過程中，因此一般的數(shù)據(jù)庫系統(tǒng)無法滿足如此大規(guī)模和實時性，靈活性的要求。同時巨建華表示應用復雜性（包括高可用性、高性能，低延遲實時數(shù)據(jù)呈現(xiàn)、任意歷史盤中實時數(shù)據(jù)挖掘和支持用戶自定義腳本實現(xiàn)數(shù)據(jù)提取與運算）和數(shù)據(jù)規(guī)模（包括財務，金融+歷史匯總交易數(shù)據(jù)、新聞資訊及研報以及每個交易日數(shù)據(jù)增量等）是數(shù)據(jù)存儲方案面臨的挑戰(zhàn)。以下為文字實錄非常榮幸今天能有機會站在這里跟大家分享一下，最近三年以來一直在做的一項工作，就是高頻金融交易數(shù)據(jù)分析和處理。在這之前，跟劉工講做的工作有

4、點相似，我今天分享過程中不會講我們?nèi)绾稳シ治?，如何去形成更好的模型來對?shù)據(jù)做，拿著一些有用模型。如何高效對數(shù)據(jù)進行分析和處理存儲，然后來解決大規(guī)模數(shù)據(jù)的挖掘問題。這是我今天主要給大家講的，在開始之前大家會看到目前我從事主要是電子商務方面的工作，主要因為在前三年，主要是在做證券方面交易處理。可能在座如果是有做像這方面同仁，我們可能會認識。在開始之前，因為這個行業(yè)比較特殊，在我們之前CSDN有CTO俱樂部，我們在做相應活動的時候，實際上我們遇到的同事非常少。也就是說，這個領域如果我要向大家介紹如何使用MongoDB解決這個領域問題的時候，我需要給大家做一些關于這個行業(yè)背景的介紹。首先第一個證券，或

5、者金融這個行業(yè)數(shù)據(jù)類型是非常復雜的，而且這個數(shù)據(jù)對于結構化，有些數(shù)據(jù)結構化是非常差的，大多數(shù)都是一些PDF，甚至是一些文本文檔。但是有一部分數(shù)據(jù)結構還是非常強的，就是交易數(shù)據(jù)，也就是我們證券成交數(shù)據(jù)。大家炒股的時候都在用金融終端看我們股票數(shù)據(jù)變化等等情況，如果如果有一些高起點客戶會用技術指標，來進行數(shù)據(jù)分析。在做數(shù)據(jù)分析的時候會接觸，我們數(shù)據(jù)里面有資金持倉項目，有機構評級報告，還有新聞咨詢，交易龍虎榜。如果我們平時接觸少大家感覺不會很熟悉，所謂基金持倉，我們所有基金公司對市場上的股票持有情況，也就是說，每一個每個咨詢公司手上拿著什么樣股票進行發(fā)布，這樣數(shù)據(jù)連續(xù)20多年沉淀下來，數(shù)據(jù)沉淀非常強。

6、研究報告主要是機構，我們大家都知道很多分析師，每過一段時間就會編制一些研究報告，對每一支股票進行分析，這主要是文本類型的，主要以文本來展現(xiàn)。另外由于用戶習慣不同，我們股票在變化過程當中，不同用戶都采用不同周期K線數(shù)據(jù)來看盤，比如分鐘，月，周年進行統(tǒng)計，形成所謂日K線數(shù)據(jù)，就是統(tǒng)計出來在某一個時間段第一個價格，也就是開盤價，最高價格，以及最低，收盤價，包括成交量，成交額等等。這樣的數(shù)據(jù)之所以會形成這樣統(tǒng)計的原因，一個是用戶習慣，第二這個差異數(shù)據(jù)量實在太龐大了，如果我們不提前做統(tǒng)計的話，在形成這樣大量交易，我們想在盤中持續(xù)拿到這樣統(tǒng)計數(shù)據(jù)，系統(tǒng)都會很吃力，特別是在我們之前數(shù)據(jù)庫系統(tǒng)，以及分布式運算

7、方式?jīng)]有根本性改變的時候，最佳解決方案當時也就是預先把這些數(shù)據(jù)統(tǒng)計出來，如果說我們突然想之前，我們假設沒有提供33分鐘的數(shù)據(jù)，我們想對歷史數(shù)據(jù)進行回歸，這是一個非常龐大，這個時間會非常長。也就是說，如果我們計算，甚至說這樣認為是不可完成的，在我們沒有引入更好計算機制和存儲機制之前，也是這個行業(yè)一直以來面臨的問題。關于盤口和成交明細不多說了，都是非常多數(shù)據(jù)。之前數(shù)據(jù)實際應用中會不會通過終端展現(xiàn)出來，我們可以看到證券簡單截圖，我們看到前面各種類型通過相應軟件UI來展現(xiàn)，左側分析圖是通過分眾線實現(xiàn)，當前買一賣一，包括后面買實賣實等等。這些數(shù)據(jù)按照目前上交所更新頻率，基本上可以保持每3秒鐘有一個數(shù)據(jù)更

8、新，都有新增變更。每天我們大約有20條左右的數(shù)據(jù)變更，這樣變更之前由于沒有能力去分析，最終都被通過統(tǒng)計的形式，只是取得一部分，比如我們剛才說的匯總值，大部分數(shù)據(jù)都丟掉。實際上這種數(shù)據(jù)都以整個金融模型分析，包括怎么通過股票數(shù)據(jù)盈利都是非常有用的，在國外也有大量對沖基金在做這些事情，發(fā)現(xiàn)龐大數(shù)據(jù)發(fā)現(xiàn)某種交易規(guī)律，最終發(fā)現(xiàn)盈利，這是其中一個應用場景。第二就是我們剛才談到如何通過這些數(shù)據(jù)進行自動，機器自動交易。當然機器自動交易優(yōu)勢大家都可以知道，首先第一個分析數(shù)據(jù)非?？?，我們?nèi)四X根本不可能對那么多股票數(shù)據(jù)，A股有140多支股票，如果在美國股市是有1萬多支股票，這么大股票交易過程中如果沒有相應的機器來代

9、替人腦做一些事情，根本就沒有太多精力能抓住那么多交易機會。另外我們?nèi)嗽谧雠袛嗟臅r候，很受形式的影響。如果大家有炒股精力，當你股票漲一點，跌一點，或者漲停，爹跌停的時候大腦不受你操作，機器就可以避免。即使我們機器能夠做這樣自動交易的事情，也可以想像，如果每天用21條逐筆成交數(shù)字，我們一年兩年下來之后這個數(shù)據(jù)量非常龐大，這樣一個龐大數(shù)據(jù)，不是說我們只是通過機器就能搞定，實際上是一個非常大的工程型問題，從數(shù)據(jù)如何去存儲，到這些數(shù)據(jù)如何建模，計算，到最后形成結果之后如何應用這些數(shù)據(jù)，那都是非常龐大的工程。所以說，在這里我們首先需要解決，這么大數(shù)據(jù)，我怎么能夠有能力把他非常好的存儲起來，根據(jù)我的業(yè)務需求

10、能夠非?？焖俚陌堰@個數(shù)據(jù)拿出來使用，而不是說我要使用這個數(shù)據(jù)的時候，我需要非常長的時間，甚至我根本就拿不出這個數(shù)據(jù)出來。我們知道具體的應用場景之后，接下來我們來看一下目前行業(yè)內(nèi)主要采用的這種數(shù)據(jù)存儲方案，以及他們的一些優(yōu)缺點。這個應該是在04年以前大多數(shù)公司采用的這種，對證券行情數(shù)據(jù)處理的方式。我們都可以看到，基本上從交易所過來的數(shù)據(jù)，從交易所網(wǎng)關過來的數(shù)據(jù)全部通過自定義文件系統(tǒng)寫到文件里面去。前端會通過另外一個進程，這個進程為相應客戶端提供服務，為了能夠保證性能做法，同樣數(shù)據(jù)被寫到無數(shù)臺機器上，重復寫到N多臺機器上。我們在座有做金融數(shù)據(jù)公司都很熟悉這個模型，把所有交易數(shù)據(jù)按照相應的統(tǒng)計方法，

11、統(tǒng)計完之后把統(tǒng)計結果直接寫到文件系統(tǒng)里，每天數(shù)據(jù)會形成一個文件，到收盤之后在歸檔到最大文件里。最后我們就只提供，一個我們提供歷史的統(tǒng)計結果，把非常大的21條數(shù)據(jù)整合到可能只有2千條，3千條數(shù)據(jù)給用戶進行顯示。第二對于詳細數(shù)據(jù)我們處理方式，原來處理方式，我可能只提供一周數(shù)據(jù)，你如果想看更詳細，對不起看不了，因為我們系統(tǒng)，整個系統(tǒng)不支持這樣的操作。在這樣一個模型下，他的缺點，我們可以知道，因為數(shù)據(jù)量非常龐大也比較復雜，就能導致這個程序開發(fā)起來非常低效。而且為了追求效率，這樣系統(tǒng)都會用C+來開發(fā)，這個時候整個開發(fā)周期會非常長，開發(fā)完成之后，當你面對幾十種數(shù)據(jù)類型文件定義不同結構去操作的時候，你會發(fā)現(xiàn)

12、想要產(chǎn)生一點變更，某一天想增加一個新的數(shù)據(jù)類型，這個代碼內(nèi)容會非?？植馈ｋm然說我沒有很好管理方案，我們會做一些好的測試框架，從開發(fā)到測試周期也是很長的。實際應用過程中我們會發(fā)現(xiàn)不同，實際上有一個職業(yè)叫金融工程師，金融工程師他的工作主要是結合計算機和數(shù)學這樣的專業(yè)，包括金融這樣專業(yè)來提出一些新的模型，對數(shù)據(jù)進行挖掘。如果我們直接進入這樣專職，當然這個在國內(nèi)目前還不是很多，可能很多研究所都已經(jīng)不少，假如我們僅僅提供這么一個系統(tǒng)來支撐的，我們想出一個模型進行測試的時候，根本沒有辦法支持，你在多工程師都沒有辦法完成程序編寫，包括中間還涉及到測試一整套過程。即使這樣一個比較差的架構，實際上現(xiàn)在大多數(shù)公司

13、，包括你們用的很多股票軟件還是在前面這種方式，因為比較成熟，也比較穩(wěn)定。第二，這些軟件已經(jīng)很久，不管你看界面，后臺邏輯很久不用變化。因為對普通用戶來說，可能已經(jīng)比較足夠了，對于高端用戶還是很缺的。第二解決方案，我們現(xiàn)在知道上交所跟國內(nèi)公司在采用Timesten解決方案，比關系系 型數(shù)據(jù)庫能夠快10倍，這是一個Oracle類型數(shù)據(jù)庫解決方案，軟件和硬件成本會非常貴，因為他只支持通過Repllcation，沒有辦法解決橫向擴展問題。當我數(shù)據(jù)量增長的時候，我必須要做兩個處理，第一個是我可能內(nèi)存沒有那么大存那么多數(shù)據(jù)，我只能把過期歷史數(shù)據(jù)還要存到，持久化相應數(shù)據(jù)庫里去，或者其他存儲結構力。如果一旦放到

14、關于云數(shù)據(jù)庫之后，問題就來了，每天數(shù)十條問題處理起來非常，10年，20年，甚至再過30，50年之后這些數(shù)據(jù)怎么處理，最終又變成一個看起來我們都有存儲，實際上就沒有辦法可用的數(shù)據(jù)。在這種情況下，當然我們還要去做很多復雜的開發(fā)，我需要去寫代碼來實現(xiàn)，把Memary相應數(shù)據(jù)庫，相應結構，同時也要去解決一些，因為使用，當然我在提這個的時候，實際上已經(jīng)有一些解決方案能夠把數(shù)據(jù)庫同時寫到硬盤上。我相信Oracle的這項技術，了解的人都非常少，我們很難找到真正熟悉使用這個技術的人。我覺得這個方案也不是特別好，我需要自己寫程序來實現(xiàn)，寫非常復雜的邏輯就為了程序擴展，我覺得這個也不太好用。因此，在了解這個之后，

15、我們就知道，實際上目前我們的架構面臨的挑戰(zhàn)一個是應用的復雜性，也就是說這個復雜到，他首先需要一定高可用。因為當你客戶全部在拿著你的終端，或者你的產(chǎn)品炒股，或者在看數(shù)據(jù)的時候，如果你中間出現(xiàn)中斷，性能比較低下情況，很快你就會丟掉所有客戶。同時，如果是在一個投資公司里邊使用這個產(chǎn)品，出現(xiàn)商用不可用，或者效率低的情況，直接影響到可能就是投資收入。如果一個咨詢公司拿著這樣一個系統(tǒng)操作，我們都知道他們手上錢是非常多的，隨便是小點事故就可能導致大量損失。第二，由于目前金融工程，我們說的發(fā)展，我們會發(fā)現(xiàn)不同的金融工程師經(jīng)常會提出一些需求，對任意歷史和數(shù)據(jù)進行挖掘，這個挖掘需求出來之后，我們都知道不管你用什么

16、，可能你一個讀取會把很多硬件資源全部站掉，導致其他服務受影響，如果有大量用戶在做挖掘，不管我們系統(tǒng)怎么拆分其實都是很困難的。另外關于數(shù)據(jù)規(guī)模，剛才也提到，數(shù)據(jù)規(guī)模里面關于財務數(shù)據(jù)和金融一些歷史數(shù)據(jù)，他們規(guī)模不是很大，畢竟中國股市時間還不是太長，現(xiàn)在算起來也就40多個G，新聞咨詢與研報是文本數(shù)據(jù)，怎么來存。但是存在數(shù)據(jù)庫里也有公司這么做，現(xiàn)在實際上真正我們所謂高品質(zhì)數(shù)據(jù)，高頻交易數(shù)據(jù)，指的就是目前上交所和信交所所推出來，能夠真實把每一筆交易完全發(fā)送過來。前我們拿到都是一個每5秒一次的快照，自從06年上交所Level-2推出來之后，我們就能拿到完整交易名類，每天增長容量有1.5-2G之間，這個還在

17、不斷增長。所以，我們面臨問題如何能夠很好，先不說怎么挖掘這些數(shù)據(jù)，如何快速存儲這些數(shù)據(jù)，快速提取詩句，為挖掘做準備。在這個過程中我們做了很多方案，甚至我們也考慮自己來編寫相應的系統(tǒng)來實現(xiàn)，通過最終考察和我們對整個項目評估之后，我們選擇了以MongoDB作為高頻數(shù)據(jù)存儲。具體我們?yōu)槭裁磿x擇的原因？這個項目大家都可以從這個過程中知道，我們最關注的是性能。當我們看到當時是1.4版本的MongoDB漂亮的Benchmark，大概是在09年左右，我們可以發(fā)現(xiàn)他的性能非常強大，我們知道不穩(wěn)定性，丟數(shù)據(jù)的情況，我們項目構想非常相似，就希望把數(shù)據(jù)存到內(nèi)存中，在適當?shù)臅r候選擇硬盤，來保證數(shù)據(jù)實時性。至于安全性

18、方面，最好在這個過程當中，我們發(fā)現(xiàn)我們想法跟MongoDB不謀而合，已經(jīng)有一個很好產(chǎn)品沒有自己去造車輪，我們引進過來，不是說馬上使用，而是通過一步步探索甚至是研究，我們認為可以在產(chǎn)品使用的時候才引入。最早我們注意還是Benchmark，很多人推廣的時候不去提其性能，確實已經(jīng)非常好了。我們在發(fā)現(xiàn)，剛才講到非常符合我們業(yè)務需求系統(tǒng)特征，除了這些之外，我們發(fā)現(xiàn)其實有很多都是我們在構建這個系統(tǒng)的時候需要考慮的，這是第一個，而且MongoDB已經(jīng)做的非常好，他支持復制級，能夠自動Failover，第二能夠支持輕松刪除數(shù)據(jù)結點。意味著，當數(shù)據(jù)量不夠的時候，在一個復制結里面，或者說當我們數(shù)據(jù)壓力比較大的時候

19、，我們就能夠快速通過添加新的結點來解決分布讀取壓力，當然我們在復制級里通過刪除結點。第二是自對分片，在MongoDB也可以直接支持動態(tài)添加和刪除分片，而且能夠在添加和刪除分片自動進行遷移，這就實現(xiàn)了我們一直都需要的一個數(shù)據(jù)存在內(nèi)存里面，但是我們可以通過添加更多結點來實現(xiàn)數(shù)據(jù)橫向擴展特征。這個分片，MongoDB有自動分片機制，不需要寫代碼，只需要寫相應規(guī)則，就可以自動分配，而且過程當中會自動平衡，自動遷移不同的窗口。在數(shù)據(jù)管理還有一個更好的特性，對單個文檔做原子更新，我可能對文檔當中某一個屬性進行遞增，或者可以對文檔整個資料進行唯一變更，而不會擔心這個文檔會被多個線程，多數(shù)更新出現(xiàn)不一致情況，

20、一個文檔更新的時候一致性可以得到保證。因為這個數(shù)據(jù)每天20多億條逐筆，意味著都是很小數(shù)據(jù)，每一條數(shù)據(jù)大概在20-32個字節(jié)之間，這種小的數(shù)據(jù)，如果我們的存儲引擎不支持小數(shù)據(jù)量控制利用率，我們會發(fā)現(xiàn)非常浪費空間。也就是說，我們最后會發(fā)現(xiàn)一天下來之后，不說內(nèi)存，硬盤空間都很少用。還有數(shù)據(jù)擴展之后，考慮快速查詢，我們發(fā)現(xiàn)在MongoDB里面查詢語法是非常豐富，基本上可以跟我們使用有一拼，查詢習慣很一致，轉過來以后沒有很難的轉換過程。大家都用MongoDB，或者其他數(shù)據(jù)庫很多，我們發(fā)現(xiàn)他的監(jiān)控和優(yōu)化機制比較簡單，MongoDB我們除了看到有這些功能之外，還有整體數(shù)據(jù)庫緩存利用率，以及數(shù)據(jù)在磁盤，內(nèi)存中

21、命中效率，甚至可以跟蹤到具體某一個集合，或者某一個操作上導致問題，這對我們來說可以迅速定位到當數(shù)據(jù)庫產(chǎn)生問題的時候可以馬上找到，而不是做很多分析。當然還有一些理由，他的文檔非常完善。我們不需要去買任何書，也不需要去找任何資料，我們只需要在官方網(wǎng)站上就能找到我們所有要的答案，這可能是大多數(shù)開源產(chǎn)品做的不是特別好的地方。另外，最好他的客戶端API支持我們現(xiàn)在用的開發(fā)語言，也就是我們當時主要的開發(fā)語言是C+，同時有一大部分工作用其他來做，包括有一些net，js，有一些外部界面通過js展現(xiàn)給用戶，最好全部支持，而且官方提供，根本不用擔心穩(wěn)定性問題。另外版本更新速度一直非?？?，基本上2，3個月就有一次，

22、這在每一個開源上做的比較小，就因為更新比較快面對一些風險，有時候會帶來一些風險，但是這兩年已經(jīng)非常好了。另外對社區(qū)關注度非常高，我們都知道對整個社區(qū)非常關注，包括各種AK等等處理非常及時，回復也很全。另外我比較看好，實際上已經(jīng)獲得像紅杉比較著名投資機構投資，3千多萬美金，我們根本不用擔心后續(xù)項目會死掉，或者失去保障，讓我們用了這個產(chǎn)品之后會面臨很大的風險。這是我們在選擇他的時候，我們認為比較重要的理由，當然大家在自己實際業(yè)務當中也會自己一些想法，這個就需要根據(jù)實際情況來定了。在選擇了之后，我們經(jīng)過一些使用，總結一些經(jīng)驗，作為一些要點跟大家進行分享。因為這是一個分布式數(shù)據(jù)庫，我們在規(guī)劃的時候，基

23、本上目前還不能夠脫離CP，AP，CA的理論。我們到底要采用那種模式，我們數(shù)據(jù)采用什么方式來分布，而在我們MongoDB里面有三種方式可以通過配置。我打開replicaSet開啟SlaveOk查詢，設置寫入節(jié)點書等于replicaSet數(shù)據(jù)節(jié)點數(shù)，我們保持一致性。如果采用AP，可用性和分區(qū)容錯之間，只需要把W等于1，每次寫入數(shù)據(jù)至少只需要寫入一個節(jié)點，并且把查詢slaveOk打開，可以保證系統(tǒng)在任何時候都是可用的，而且我們是能夠達到。當他實現(xiàn)原則，當我們指數(shù)寫入為1，某一個節(jié)點失敗，我們可以通過slave功能，把第二個節(jié)點進行提供服務。在這種情況下，只要我們重節(jié)點足夠多，我們服務是一直可用的。而

24、且我們數(shù)據(jù)由于使用了replicaSet，數(shù)據(jù)有多份，達到了容錯標準。第三是關于CA要求一致性和可用性的時候是一樣的，只是我們在查詢的時候使用了slaveOk，在重節(jié)點上不做查詢，所有查詢都在主節(jié)點上完成。這就意味著我們一旦要求一致性，最終導致一致性和可用性的時候，我們性能就會下降。到底采用哪種模式，我們做系統(tǒng)的時候需要考慮好。當然我們可以看到在這里面AP和CA這兩種方式我們是可以通過在程序中動態(tài)切換，我一套系統(tǒng)只需要一個配置就能實現(xiàn)AP和CA兩模式，甚至兩種模式變形，這是我有的時候需要可用性，一致性，有的時候需要可用性和容錯。這一點對我們來說非常有幫助，當我想保持一些重要數(shù)據(jù)的時候就通過CA

25、的方式保存，在代碼里面寫下來就可以。第二個是關于系統(tǒng)容量規(guī)劃部分，在系統(tǒng)容量規(guī)劃，我們MongoDB有一個非常重要，索引要求全部都加入到內(nèi)存里，如果不能放到內(nèi)存中，我們發(fā)現(xiàn)也很多警告信息，甚至性能會急劇下降。第二是熱數(shù)據(jù)最好能全部裝載內(nèi)存，在MongoDB所有數(shù)據(jù)管理，如果說我們數(shù)據(jù)沒有有效，或者不是把數(shù)據(jù)放在內(nèi)存，會導致不停的切換內(nèi)存和硬盤的頁面，這時候就會導致，基本上系統(tǒng)就沒法正常工作。所以說，我們在做基于MongoDB系統(tǒng)優(yōu)化的時候，一定要考慮到哪些數(shù)據(jù)經(jīng)常使用，類似于容量一定要能夠覆蓋到內(nèi)存數(shù)據(jù)，使整個性能得到一定保證。還有很關鍵一定不能在性能和容量都達到瓶頸的時候去考慮增加資源，你再

26、去增加資源，在MongoDB里面已經(jīng)不行了，除非你停機不提供服務。因為他就已經(jīng)自動的分片機制，后臺在不停做相應數(shù)據(jù)，我們可以稱之為移動或者平衡，如果一旦市場壓力很大，沒有足夠空間提供使用，他就在數(shù)據(jù)移動和平衡過程中，分布過程中就會失敗，沒有辦法讓系統(tǒng)停止服務，這是我們在最初過程中，包括其他人也整理出來的一些經(jīng)驗。在我們剛開始之前，沒有之間把MongoDB拿到生產(chǎn)環(huán)境中去。我們最開始只是拿它來做廣告點擊的數(shù)據(jù)存儲和統(tǒng)計，最后我們拿它來做Web Server Session數(shù)據(jù)，在這個過程中都非常穩(wěn)定，效率非常高，逐步我們對MongoDB比較有信心，在這個過程中我們積累一些使用和運維經(jīng)驗。最后就開

27、始逐步利用到金融數(shù)據(jù)處理上去，我們可以看到，我們最開始的時候是有4臺服務器直接建立4個分片，在這過程中沒有使用任何冗余。我們追求把最近一個月數(shù)據(jù)高效放進去，能夠提供給數(shù)據(jù)挖掘的使用。當我們在使用接近一年左右時間時候，我們就切換到9個分片，27臺服務器組成，把我們之前采用文件系統(tǒng)加入完全拋棄了，在這樣一種情況下我們提供交易性能已經(jīng)非常高了，我們發(fā)現(xiàn)從我們兩次擴容達到27臺之后，我們對整個數(shù)據(jù)未來增長完全就放心了。對于一點，我們在說一下關于一些使用經(jīng)驗。這是我們搭建的架構，這個架構其實跟MongoDB官網(wǎng)推薦架構非常類似，我們有三臺來提供信息存儲，以及分片信息存儲，我們可以看到里面有復制集，里面有

28、9個，列了3個出來，每個集上有3臺服務器存儲，3臺服務器都是數(shù)據(jù)節(jié)點，直接在3臺服務器上跑數(shù)據(jù)。將來擴展只需要不停添加，復制集就行，基本上我們存儲就不會有任何問題，當然這也是相對的，畢竟我們現(xiàn)在還沒有跑到目前MongoDB官方所提供文檔里的極限，當然測試的時候因為建立測試數(shù)據(jù)的時間比較長，我們現(xiàn)在還沒有做很好環(huán)境測試，在目前環(huán)境下跑的比較流暢。還有關于每個應用集上對一些歷史數(shù)據(jù)進行緩存，這也是為了減少MongoDB本身數(shù)據(jù)壓力?？梢钥吹皆诿恳粋€應用服務器深都有Mongo進程，直接放在服務器上。整個這套系統(tǒng)是沒有任何單故障，不管是進程，還是數(shù)據(jù)節(jié)點等，我們隨時都可以換到N多個節(jié)點不影響整個系統(tǒng)服務。同時，這些節(jié)點并不是僅僅作為備份存在，當我們獲得高性能的時候所有人都會獲得服務，根本上沒有資源浪費。而這個東西搭起來非常容易，我覺得MongoDB相對來說最容易入手使用的數(shù)據(jù)庫。另外一個很關鍵，其實這也是我