性能優化篇：讀寫分離與文本數據庫(十八)

　　1：分析尋找優化點：

　　通過 CYQ.Data 的 AppDebug(即將發布的V4.5.5版本包含此類)，打印出頁面的SQL語句：

　　PS：關于打印頁面SQL語句的優化，可見之前的文章：秋色園QBlog技術原理解析：性能優化篇：全局的SQL語句優化(十三)

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

　　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語句，并沒有使用文本的方式進行消滅。

　　為啥沒有呢?

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

　　那文章列表是如何進行的優化，這是個大工程，當時我在外散步連續思考了3天，也是秋色園QBlog 至今為止的最后一次優化，這么大工程，具體下節詳細介紹了。

　　復制代碼

　　總結：

　　秋色園QBlog 通過借助于文本，將大量的讀取數據庫轉移到文本讀取中，有效的降低了數據庫的壓力，同時網站運行也順暢了很多。

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

　　優點：速度快，小數據量(10萬或10M上下)簡單的存儲與讀取非常方便。

　　缺點：刪除，更新，查詢，分頁，排序及并發控制等操作復雜，而且數據量也不適合太多。

　　復制代碼

　　另外據網上搜索“文本數據庫”的結果看來：

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

　　至于.net界，文本數據庫卻從沒流行過，這是為什么呢?

原文轉自：http://www.kjueaiud.com