我們有個數據量很大的美國5+4位郵政編碼系列網站，一共4千5百多萬數據，分散到51個州的子網站，每個站少的幾萬，多的數百萬，平均大幾十萬，搭建的時候用的Drupal 6，好像有個Import模塊來進行導入成為node，導入就花了好長時間，後來要升級到Drupal 7的時候更是痛苦，經常因為數據量太大無法使用常規的升級方式遷移成功，中途總是中斷，後來一個一個站、甚至逐個字段編程進行轉移，前後進行了好幾個月。
數年後購買了新的來源數據，又進行比對、補充導入，也是花了幾個月時間，今年進行了重新分析改版處理，僅重新生成網站地圖就需要好些天。而這樣大數據量的網站也常常造成服務器負載過高，特别是阿裡雲的RDS數據庫IOPS常報警，網站打開速度受到限制。
從去年開始我們一些新搭建的站沒有使用導入node的傳統方式，而是自己建表來處理，這樣數據庫的處理效率高得多。也想到過對以前的網站進行類似改造，這次就用這個美國郵編系列站為第一個開刀。其實這個工作在5月份就開始籌劃了，下面是當時記錄的要點：
Zip 5+4系列node轉table
1、起因：
周末看ecs服務器狀态、rds狀态，還有不到2個月（2018-7-18到期，空間510G占用360G）rds-2到期，想到這上面隻有zip5+4系列的數據庫了，可以考慮搬遷合并到rds-1（2018-7-30到期，空間230G占用126G），但超過360G，需要減少到100G以内。這需要把drupal自帶的node、分類頁等訪問都轉為table形成的views的訪問。
這個系列如果能搬遷合并，還有很多好處如下：
2、好處：
- 采用訪問一個表的方式，訪問速度加快
- 以後如果購買更新數據，更新方式簡單、更新耗時更短
- 更清晰形成views頁面，替代3種老的頁面：
- node頁面(這種對用戶有用，但也可以使用新table的views來替代)
- 分類頁(這種對用戶沒有什麼用)
- 老的views頁面(目前views數量多，相當雜亂，其中一些term形成的列表鍊接到分類頁對用戶沒有什麼用)
- 隻訪問少量的表，RDS iops和cpu負載降低
- 可以删除以前的分類、内容類型，RDS空間占用大幅降低
下面看看目前幾種頁面的情況：
3、原Node頁面：
内容類型
- City
- County
- Page
- Story
- ZIP Code
- ZIP Code 5
例子：
https://ak.postcodebase.com/city/BIRD_CREEK （城市頁面是後面新增、改進過，以後可以保
留内容形式、跳轉對應新views頁面）
$city_zipcode = views_embed_view('city_zipcode', 'block_2', $CityName);//2018-4-23
$city_plus = views_embed_view('zip_code_5_4', 'block', $CityName);//2018-4-22
https://ak.postcodebase.com/county/02188 （縣頁面是後面新增、改進過，以後可以保留内容形式、跳轉對應新views頁面）
$county_city = views_embed_view('county_city', 'default', $CountyFIPS);
$county_zipcode = views_embed_view('county_zipcode5', 'default', $CountyFIPS);
https://ak.postcodebase.com/help_articles (page類頁面很少，可以保留)
https://ak.postcodebase.com/story （story類幾乎沒有，隻有測試的）
https://ak.postcodebase.com/zip_code/99918-9802 （9位郵編是最早的、改進過，以後可以保留内容形式、跳轉對應新views頁面）
https://ak.postcodebase.com/zipcode5/99950 （5位郵編是後面新增、改進過，以後可以保留内容形式、跳轉對應新views頁面）
$zipcode5_plus4 = views_embed_view('zipcode5_plus4', 'default', $ZIPCode);
4、原分類頁：
詞彙表
- zipcode5
- city_name
- county_fips
- state_abbr
Zipcode5
https://ak.postcodebase.com/category/zipcode5/99501
這種頁面對用戶無幫助，跳轉到對應的有用頁面
https://ak.postcodebase.com/zipcode5/99501
city name
https://ak.postcodebase.com/category/city_name/ARCTIC_VILLAGE
這種頁面對用戶無幫助，跳轉到對應的有用頁面
https://ak.postcodebase.com/city/ARCTIC_VILLAGE
county fips
https://ak.postcodebase.com/category/county_fips/02016
這種頁面對用戶無幫助，跳轉到對應的有用頁面
https://ak.postcodebase.com/county/02016
state abbr
https://zip.postcodebase.com/category/state_abbr/PR
這種頁面對用戶無幫助，跳轉到對應的有用頁面
目前還沒有這種views頁面，後面可以建，主要就用在zip.postcodebase.com總站，因為其它子站每個站隻有一個州，總站有多個美國海外州等
5、原Views頁：
比較多，有些雜亂，需要逐個清理，最後确定處理意見（是跳轉對應新views頁面、還是删除、保留等）
Type: Term
https://ak.postcodebase.com/city_name
link: https://ak.postcodebase.com/category/city_name/GOODNEWS_BAY
Type: Term(菜單State Abbr)
https://ak.postcodebase.com/state_abbr
Type: Content(菜單County)
https://ak.postcodebase.com/state_county
link:https://ak.postcodebase.com/county/02150
Type: Term
https://ak.postcodebase.com/zipcode5
link: https://ak.postcodebase.com/category/zipcode5/99505
Type: Content
https://ak.postcodebase.com/zip-code-5-4
Type: Content
https://ak.postcodebase.com/zipcode9-link
Type: Content
https://ak.postcodebase.com /zipcode_index/%
Type: Content
https://ak.postcodebase.com /county_index/%
Type: Content（菜單City Name）
https://ak.postcodebase.com/county_city
link: https://ak.postcodebase.com/city/ANCHORAGE
Type: Term(菜單)
https://ak.postcodebase.com/county_fips
link: https://ak.postcodebase.com/category/county_fips/02016
Type: Content(菜單zip code 5)
https://ak.postcodebase.com/city_zipcode
link: https://ak.postcodebase.com/zipcode5/99505
Type: Content
https://ak.postcodebase.com /city_index/%
6、新頁面：
需要結合用戶需求以及老頁面來綜合考慮，用table形成新的views頁面：
州列表
state-list
縣列表
county-list
市列表
city-list
5位郵編列表
zipcode5-list
州到縣：
county-of-state/%
聚合
縣到市：
city-of-county/%
聚合
州到市：
city-of-state/%
聚合
縣頁面：
county/%
聚合
市頁面：
city/%
聚合
5位郵編頁面：
/zipcode5/%
聚合
5+4位頁面：
/zipcode/%
可能包含不止一條數據，出現多條的時候都在同一個views頁面列出（共同的部分不重複列出、隻列出一次，不同的部分并列列出），以前的多個node頁面都跳轉到這同一個新views頁面（在.htaccess裡面設置，zip_code/12345-1234_0, zip_code/12345-1234_1等都跳轉到新的zip_code/12345-1234）
搜索頁面：
上次商量過一些，還提出自己的想法，需要花時間再商議、實現。
7、步驟：
後面幾周中安排時間來做下列事項：
- 商議辦法
- 在ak實驗生成新的table views頁面
- 在ak修改.htaccess進行跳轉
- 反複測試确認無誤後，删除ak以前的内容類型、分類、views
- 實施到其它子網站
最後，在rds-2（2018-7-18到期）到期前完成搬遷合并到（2018-7-30到期）rds-1。
另外，這個系列這樣做之後，總結經驗，還可以實施到國内外其它drupal站（現在看來我們以前的很多drupal站都對用戶來說不友好，特别是分類頁幾乎沒有用）。
上面是5月份的規劃，但實施起來比較麻煩就拖下來了，7月份RDS到期後網站改造還沒有進行隻得先續費，不過後來還是下決心要進行改造，在另外的服務器上搭建環境進行了一定測試後，轉移到實際服務器上來，再準備實施的時候又發現好多細節問題，例如：地址拼接方面的細節、多語言翻譯方面的問題、找不到内容跳轉處理等等，終于在上周進行了實施和切換。
主要隻對數據量最大的内容類型進行了替換，修改.htaccess跳轉到新建的Views網址。然後對保留的其它幾種數據量小的内容類型展示模闆進行了修改，以前嵌入的顯示zipcode5+4的views也從基于node替換為基于table。經過這兩種大的改進，數據庫服務器的負載有了驚人的變化：
特别是上面圖中的IOPS和InnoDB讀寫量，下降了大約兩個數量級！
再看ECS服務器的負載變化不大，查看Analytics後台的網頁速度指标也沒有明顯變化，Google Search Console中的爬取、收錄暫時也沒有明顯變化，待觀察。
現在真的後悔當初了解不深，數據量大于幾十萬以上的Drupal網站确實應該采用自建表的方式來進行，後面我們還會對以前的一些站點進行類型改造。
评论