当前位置

大数据量Drupal网站改造数据结构

James Qi 在 2018年8月8日 - 10:15 提交

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

添加新评论

Plain text

  • 不允许使用HTML标签。
  • 自动将网址与电子邮件地址转变为链接。
  • 自动断行和分段。