遇到的問(wèn)題

1、最初階段

系統(tǒng)中做了一個(gè)監(jiān)控功能，用于記錄所有的請(qǐng)求數(shù)據(jù)，數(shù)據(jù)插入頻繁，量非常大，比如一天1000萬(wàn)條?？紤]到數(shù)據(jù)插入的效率，就使用內(nèi)存KV緩存來(lái)保存。寫(xiě)入過(guò)程是在接收到請(qǐng)求后放入到線程池中，然后線程池異步處理后寫(xiě)入。到這問(wèn)題基本上沒(méi)什么事情。

2、新的需求

后面數(shù)據(jù)保存了，就需要在運(yùn)維系統(tǒng)中可以查詢到，所以這個(gè)緩存還必須是分布式的。于是就換成了redis，這樣系統(tǒng)都可以連接到。但是數(shù)據(jù)量太大，需要分頁(yè)查詢，這就有點(diǎn)頭痛了。還好redis是可以支持有序集合的，而且可以通過(guò)zrange來(lái)獲取指定范圍數(shù)據(jù)。

3、增加了需求

這些數(shù)據(jù)要在運(yùn)維界面里還要可以按條件過(guò)濾，這個(gè)就非常頭疼啦，redis沒(méi)有條件過(guò)濾啊。即使過(guò)濾出來(lái)了數(shù)據(jù)要顯示在界面上必須分頁(yè)。

問(wèn)題思考

最終突然發(fā)現(xiàn)如果存在數(shù)據(jù)庫(kù)里是不是很好解決？但是存在數(shù)據(jù)庫(kù)里就會(huì)有大量寫(xiě)操作的問(wèn)題，而且數(shù)據(jù)這么大，像Mysql單表很容易就破了。所以我想著是不是還是在nosql的基礎(chǔ)上解決。

這里就有幾個(gè)問(wèn)題：大數(shù)據(jù)量的排序、查找過(guò)濾、分頁(yè)。

先不管這么多，如果使用Mysql的話，除了大表保存問(wèn)題，查找、過(guò)濾、分頁(yè)功能都是直接使用sql實(shí)現(xiàn)的，開(kāi)發(fā)起來(lái)簡(jiǎn)單。

mysql

如果使用mysql存儲(chǔ)后，如果要查一些數(shù)據(jù)怎么整？先看下面的這段代碼：

SELECT t.*     from ofOffline1 t     ORDER BY t.creationDate desc  LIMIT 1300000,100

這里最直接的就體現(xiàn)了兩點(diǎn)：先排序，然后取分頁(yè)的數(shù)據(jù)。好了，這里有幾個(gè)問(wèn)題：

1、使用了*返回字段，全字段返回的問(wèn)題就是要掃描全表
2、進(jìn)行了ORDERBY排序，我測(cè)試的這個(gè)表只有幾百萬(wàn)數(shù)據(jù)
3、最后分頁(yè)是取的130萬(wàn)開(kāi)始的100條，等于是要掃描130萬(wàn)后才開(kāi)始

我隨便跑了一下執(zhí)行了：5.5秒左右。有沒(méi)有辦法讓它快一點(diǎn)呢？確實(shí)有，網(wǎng)上找找挺多的。

首先，看看只返回部分字段是不是快一些？

SELECT t.creationDate     from ofOffline1 t     ORDER BY t.creationDate desc  LIMIT 1300000,100

上面的SQL語(yǔ)句，改造后，只返回一個(gè)字段，再執(zhí)行。2.9秒了。

那么取1條數(shù)據(jù)的速度會(huì)不會(huì)快一些呢？

SELECT t.creationDate     from ofOffline1 t     ORDER BY t.creationDate desc  LIMIT 1300000,1

執(zhí)行上面的sql后發(fā)現(xiàn)時(shí)間還是2.9秒，這說(shuō)明取1條的數(shù)據(jù)也是這么慢，那慢的肯定就是排序啦。

然后使用這一條取出來(lái)的數(shù)據(jù)作為條件，直接在集合中定位到分頁(yè)數(shù)據(jù)

SELECT ofOffline1.* FROM ofOffline1 WHERE ofOffline1.creationDate <(SELECT t.creationDate     from ofOffline1 t     ORDER BY t.creationDate desc  LIMIT 1300000,1) ORDER BY ofOffline1.creationDate descLIMIT 100

這是網(wǎng)上查到的SQL，思路就是先使用子查詢定位到第130萬(wàn)條記錄，然后從它開(kāi)始取后面的99條。時(shí)間差不多3.9秒左右。這說(shuō)明這樣的優(yōu)化還是有效的。

使用一下索引
我想了想如果加個(gè)索引是不是可以提升性能呢？SQL中只使用了creationDate排序和過(guò)濾，那么就用它建個(gè)索引試試吧。

還是測(cè)試一下最簡(jiǎn)單的那條SQL

SELECT t.*     from ofOffline1 t     ORDER BY t.creationDate desc  LIMIT 1300000,100

結(jié)果是：5.5秒左右，沒(méi)變化

那么看看前面有子查詢的情況：

SELECT ofOffline1.* FROM ofOffline1 WHERE ofOffline1.creationDate <(SELECT t.creationDate     from ofOffline1 t     ORDER BY t.creationDate desc  LIMIT 1300000,1) ORDER BY ofOffline1.creationDate descLIMIT 100

不錯(cuò)，執(zhí)行結(jié)果：0.599秒。

好吧，本文先到這，后面再學(xué)習(xí)一下mangodb，按理它會(huì)比較適合我們的場(chǎng)景。