我们有个数据量很大的美国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网站确实应该采用自建表的方式来进行，后面我们还会对以前的一些站点进行类型改造。
评论