[QOTD]事實上只要掌握得住每一次計算都不會跟前一
次計算有任何資料與程序的相依性，這樣就可
以很輕易的擴展成平行計算系統。
*1
在上次說到要如何平行運算，因此就把系統分成
四部份，第一部份是同步機制，第二部份是資料庫，
第三部份是計算單位，另一個是控制單位，在第一次
的計算，第一部份用兩台，第二部份用三台，第三部
份用四台，第四部份當時還是獨立的，總共用四台去
計算，因為這些機器通常可以不必要扮演一個角色。
而當時花了約 9 天算了 21000 筆資料，而這次
則是第一部份用兩台，第二部份用四台，第三部份用
三台，第四部份就只有一台來作控制的工作。
原本預估應該是在 10 天應該可以算完 34000
筆資料，但今天將資料庫作調整，資料庫效率快了約
五倍以上，所以我想應該可以輕鬆的在 7 天算完
34000 筆資料，若是依照這進度來看，似乎一個星期
算一次不是不可能。
原本把同步機分成兩台，是怕造成瓶頸，因為之
前的瓶頸是在資料庫，所以分了好幾台去計算，而現
在來看，應該瓶頸會在計算單元上面，且說要一個星
期算一次的自動化執行已經是相當可行了。
在這次的平行運算，並沒有用特殊的語言或環境
去計算，而只是用單純的 PHP/Apache 跟 MySQL 來
計算。
*2
基本上把系統拆成這四部份，最主要也是可以將
資源獨立，而沒必要寫成一個完整的程序，因為若只
寫成一隻程式的話，就很難分工，但相對的，複雜度
就提高。
0. 停掉crontab job。
1. 把同步機制與中間資料庫全部清空。
2. 平時每5分鐘就會去主資料庫抓購物記錄。
3. 取一個時間點萃取出依消費者與商品的兩個中介
計算資料庫。
4. 將中間資料庫 dump( 倒出 )後傳給各第二部份
DBMS，後還原到各資料庫。
5. 回復crontab job，開始計算。
6. 計算完畢後，將結果資料庫回傳到線上使用的資
料庫。
目前回傳到線上資料庫是清空後再寫入，應該改
成用更新的方式，這樣可以保持舊資料，也可以在算
到一半時就更新，這樣也不會有一個中空時間。
以這次來看，21000 個產品真的太少了，但事實
上也是要算 35000 件產品，還多不到一倍，但在實
務上覺得這樣的 alsobuy 還是相當常遇到空的資料
，但若把週期降低的話，我想就會好很多，且事實上
我在懷疑前一次的計算似乎只要購買超過 500 件就
會算不出來，而我將參數調整後就很明顯的沒有算出
來的資料，更何況在提升資料庫的效率後，我想除非
這商品賣超過 50000 件才會遇到下一個瓶頸，但現
在來看應該是不用擔心才對。
因此從第一次的 1000 件到第二次的 21000 件
到第三次終於到合理的 35000 件我想 alsobuy 第一
階段才算是真的完成。
有人問我為甚麼不用一些系統來輔助做平行運算
，我是認為像我這樣的工程師，了解數學模型，知道
演算法，可以規劃系統，並自己寫程式，在某方面就
可以設計一個自己就可以完成平行計算的系統，而不
用靠其他的工具達成，因為其他工具只能就部份做平
行運算的最加化，沒辦法做整體考量。
事實上只要掌握得住每一次計算都不會跟前一次
計算有任何資料與程序的相依性，這樣就可以很輕易
的擴展成平行計算系統。
*3
**********************************************
*1
8/13/03 7:51 pm，到民權西路站了，就繼續寫
alsobuy 2 吧。
*2
8/14/03 9:05 am，雖然昨晚在 3:00 才睡著，
但很奇怪的 8:00 就起來了，因此今天是很輕鬆的來
坐車，坐上 8:45 的捷運，我想應該在 9:40 前就可
以進辦公室吧。
*3
8/14/03 9:31 am，到後山毗了，就寫到這邊。
文章定位：
