首页 > 未命名 > 记录一次比较大型的ZBLOG数据库转换操作
2020
01-20

记录一次比较大型的ZBLOG数据库转换操作

千淘万漉博客阿里云大使推广链接

接客户的要求,4个ZBLOG ASP站点,合并到同一个ZBLOGPHP,要求文章URL保持不变。

大概介绍一下四个站的数据情况。

1、主站mssql,三个子站使用的是access。

2、文章大概加起来6000多

3、评论大概不到100万

4、标签大概不到一千。

5、分类总计十几个的样子。

最开始想的总是简单

接单的时候想法也是比较简单的,只是没想到数据量比较大的时候,官方提供的转换工具都沦陷了:

1、a2p  Z-BlogPHP转换工具 这组插件在导出数据的时候,随机抽风,乱码。无法使用。

2、MovableType数据格式导出,基本上如果100篇导出一次是可以的。但是数据太多的时候……无法使用。

好像只有这两个插件?

提出问题

然而更困扰的是,没人操作过多个ASP转入同一个PHP站的事情,这有很多需要引入的问题。

1、文章ID重复,多个站点ID都是从1开始累加的,分类、评论、tag、用户也有这个问题。

2、简单无脑的修改文章ID,会导致评论错乱,A文章的评论可能会跑到B文章下面去,分类和Tag也有这个问题。

3、ZBLOG的文章url,在没有设置文章的别名Alias的时候,是和文章ID强关联的,如果修改了文章ID,那么Url也会跟着变化。

解决问题

鉴于以上这些问题,经过思考和验证,可以通过以下方式来进行合并解决。

1、对四个站的数据库中的文章、分类、评论、标签,主ID进行备份。因为access可能无法一次执行多条sql语句,所以只能一条一条复制过去执行...

//备份文章ID
alter TABLE  blog_Article add COLUMN  log_ID_backup char(255);
update blog_Article set log_ID_backup = log_ID;

alter TABLE  blog_Article add COLUMN  log_from char(255);
update blog_Article set log_from = 'lusongsong';


//备份分类ID
alter TABLE  blog_Category add COLUMN  cate_ID_backup char(255);
update blog_Category set cate_ID_backup = cate_ID;

alter TABLE  blog_Category add COLUMN  cate_from char(255);
update blog_Category set cate_from = 'lusongsong';


//备份评论ID
alter TABLE  blog_Comment add COLUMN  comm_ID_backup char(255);
update blog_Comment set comm_ID_backup = comm_ID;

alter TABLE  blog_Comment add COLUMN  log_ID_backup char(255);
update blog_Comment set log_ID_backup = log_ID;

alter TABLE  blog_Comment add COLUMN  comm_from char(255);
update blog_Comment set comm_from = 'lusongsong';



//备份Tags ID
alter TABLE  blog_Tag add COLUMN  tag_ID_backup char(255);
update blog_Tag set tag_ID_backup = tag_ID;

alter TABLE  blog_Tag add COLUMN  tag_from char(255);
update blog_Tag set tag_from = 'lusongsong';

2、因为文章分类和发布用户数量比较少,手动搞定。需要对增加后的分类做一下修改和替换。

//从站点分类作为新增分类加入
blog
update blog_Article set log_CateID = 8 where log_CateID=1;
update blog_Article set log_CateID = 9 where log_CateID=2;
update blog_Article set log_CateID = 10 where log_CateID=3;
info
update blog_Article set log_CateID = 11 where log_CateID=1;
yulu
update blog_Article set log_CateID = 12 where log_CateID=1;
update blog_Article set log_CateID = 13 where log_CateID=2;
update blog_Article set log_CateID = 14 where log_CateID=3;
update blog_Article set log_CateID = 15 where log_CateID=4;
//从站点文章用户归属处理
update blog_Article set log_AuthorID = 15 where log_AuthorID=2;
update blog_Article set log_AuthorID = 19 where log_AuthorID=3;
update blog_Article set log_AuthorID = 18 where log_AuthorID=4;
update blog_Article set log_AuthorID = 20 where log_AuthorID=5;
update blog_Article set log_AuthorID = 21 where log_AuthorID=6;
update blog_Article set log_AuthorID = 22 where log_AuthorID=7;

3、扩展三个子站数据库中的文章、评论、标签的主ID,防止导入的时候发生覆盖。

update blog_Article set log_ID = log_ID + 3333 //注意要先将主键属性、自动编号去掉。
update blog_Comment set comm_ID2 = comm_ID + 555555 //新建一个字段,评论太多了,本地测试无法修改字段属性了...
update blog_Tag set tag_ID = tag_ID + 222

4、使用navicat将主站先导入mysql。

5、使用插件将对应数据库迁移至zblogphp的表(插件就不说怎么写了哈,主要是写数据库的思路)。插件主要要注意的问题是,几十万评论的操作,要分页处理,不要一口气都转完。本地测试的时候一口气直接转,不是内存爆也不是CPU爆,而是phpcgi直接挂了…………

6、对于三个子站的数据,重复4、5两个步骤,数据转换完成。对于转换后的数据做一下检查,没发现异常就可以了。

7、对于文章Url的处理,包含两个部分:

7.1 首先需要拦截Url输出的接口(目前的ZBLOGPHP 1.4版本还没有,只好先自己写一个),将输出的格式来源进行修改。

7.2 拦截系统的ViewAuto部分,当url无法匹配系统url规则的时候,把inpurl修改一下再丢给viewpost函数。

至此,数据转换完成,Url保持和原四个站点的Url相同。

总结

很少遇到有机会操作一次数据这么大的站,相对ZBLOG来说一般情况下遇到的都是小规模站点,尤其评论数量近百万的级别更是凤毛麟角。不过这也从侧面反应出一个问题,ZBLOG官方提供的工具包括官方应用中心其他的一些主题、插件,很少有对大数据专门做过优化的,一旦遇上这种数据量很大的问题,就都无法正常工作了。对于具体问题具体分析,掌握主要问题点,一一处理就行了。至于数据库的转换和Url的调整可能每个人都会有不同的方法,技术就是一层窗户纸嘛。


本文》有 0 条评论

留下一个回复