秋色園QBlog技術原了解析：性能優化篇：讀寫分離與文本資料庫(十八)

上節回顧：

本節概要：

雖然減壓方案頻繁出招，可是依舊沒能阻擋住access黃金4k的絕殺。

在壓力之下，夢幻潛能再次被激發。

本節内容：

1：分析尋找優化點：

首先觀察頁面這些語句，我們看到這裡涉及到幾條語句：

1：第一次的表架構擷取語句，即where 1=2的語句

2：部落格使用者的資訊讀取語句

3：友情連結的語句

ps：如果沒有緩存，當然還有很多和文章清單相關的語句，文章的下節重點再講。

然後我對着這些語句尋思了很久時間，最後得出結論，得把這些語句消滅掉。

2：步步分析并對可優化點進行優化：

2.1：消滅表架構讀取sql語句

這個其實關系不大，因為一個表僅讀一次，而且之後全局預設緩存30分鐘，是以出現頻繁非常低，不過了為追求首頁0語句，我還是比較嚴肅的把它給消滅了，怎麼消滅的？

消滅其實還是很好解決的，隻要首次讀取時，把表架構外置到文本中即可，于是架構的讀取順序就變成了：緩存->文本->資料庫。

下面給一張表架構外置文本和架構外置架構示例圖：

2.2：消滅使用者資訊的讀取sql語句

其實使用者表是個大問題，經常也會出現的4k，因為有太多的語句，可涉及到使用者表的讀取。

為此，雖然說使用者資訊每次讀取完後也會進行緩存，但是，使用者數量比較多，搜尋引擎來來回回，啥使用者也會扯到，是以總體來來回回就變的讀取相當相當的頻繁，為此，我想了一想，把它給消滅了，怎麼消滅的？

同理，第一次讀取時，我把使用者資訊外置到文本了，然後使用者背景更新資料的時候，也重新整理文本。

然後讀取自然的順序就變成了：緩存->文本->資料庫。

于是當然的，秋色園現在4000多的使用者，就産生了4000多個文本了，看似規模很龐大！

難免有人要發出感歎，要是你100萬使用者，不就産生100萬個文本了？我想說，求之不得啊！

下面給一張使用者資訊文本及使用者資訊以json格式存儲的示例圖：

2.3：消滅友情連結的讀取sql語句

使用者的友情連結，比起使用者資訊來說，不算重點，不過你會發現，使用者的每個頁面可都是也有友情連結的。

是以，我打算把它也給滅了，怎麼消滅的？

有了上面兩步的經驗，這步實施起來太easy了，同理，首次把使用者的友情連結轉存到檔案中，然後讀取就是文本讀取了，背景修改的時候，也是讀的文本的，不過寫的時候，先寫資料庫，再寫文本。

于是，4000多使用者，也會産生4000多的友情連結的文本。

下面給一張友情連結的文本及友情連結清單以json格式存儲的示例圖：

2.4：文章清單的sql語句呢？

這裡必須嚴肅的說一下，大量的文章清單的sql語句，并沒有使用文本的方式進行消滅。

為啥沒有呢？

原因也很簡單，因為文章清單涉及到查詢及排序還有分組等複雜語句，文本不太好操作這些事情。

總結：

經過一場應用之後，對文本有了第一印象：

優點：速度快，小資料量（10萬或10m上下）簡單的存儲與讀取非常友善。

缺點：删除，更新，查詢，分頁，排序及并發控制等操作複雜，而且資料量也不适合太多。

另外據網上搜尋“文本資料庫”的結果看來：

文本資料庫以前在php界很流行，多數論壇都采用文本資料庫，而且抗并發能力相當強，當然這背後相信有一定的技術手段在處理，然後後來的後來，php基本都統一mysql了。

至于.net界，文本資料庫卻從沒流行過，這是為什麼呢？

曆史文章回顧：

附章：

版權聲明：本文原創發表于部落格園，作者為路過秋天，原文連結：

http://www.cnblogs.com/cyq1162/archive/2011/08/07/2129785.html