花褪殘紅青杏小。燕子飛時,綠水人家繞。

            記錄一次比較大型的ZBLOG數據庫轉換操作

            ZBLOG教程 十五樓的鳥兒 43658瀏覽 3評論

            接客戶的要求,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的調整可能每個人都會有不同的方法,技術就是一層窗戶紙嘛。

            轉載請注明:鳥兒網絡 ? 記錄一次比較大型的ZBLOG數據庫轉換操作

            游客
            發表我的評論 換個身份
            取消評論

            Hi,您需要填寫昵稱和郵箱!

            • 昵稱 (必填)
            • 郵箱 (必填)
            • 網址

            網友最新評論 (3)

            1. 訪客
              哈哈哈哈哈哈哈,這種事情真的難得碰上一回的。
              天興工作室 7年前 (2016-01-24)回復

            等待大佬打賞中~

            久久久精品2019免费观看,国产精品岛国久久久久,手机看片av免费看大片,好爽好紧好大的免费视频国产,免费黄色视频在线观看 <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <蜘蛛词>| <文本链> <文本链> <文本链> <文本链> <文本链> <文本链>