※ 引述《sadle (sadle)》之銘言： : 我覺得資料庫會垮, 應該不是上傳的問題 (每支 client 上傳大概都只是幾筆而已). : 相反的, 1支 client 下載資料庫會用到幾 mb 的流量, 再加上隔一陣子就要更新. : 感覺上 server 就像一直被輪暴再輪暴一樣. agree : 可是 dl 回去的 db, 以更新週期來算又只會用到幾十幾百筆, 非常不符合效益. : ( Ian 大神大概是想考驗參賽國的程度, 用這種方法把難度提高一些. ) : 這讓我想起, anti-SPAM 界也有相同的問題, mail server black list db 的傳送. : 也是傳多多, 用少少, 又要常更新. 後來這個問題被 realtime black list 技術所解決. 我們也許可以來考慮一件事，假如說我們真的來弄一個 db server 的話 如果它要撐到 500K clicks/min，每個人平均說成 500 clicks/次 考慮 click^3 server busy 使得要回來的 sec 作廢比率 (n-1):1 那每分鐘就要有 n*1000 query，每秒 16n query (n 可能是十到幾十那個 order) 也許是可以來硬幹看看 @@ 只傳 hash 的話，一個封包可能只有 20 bytes，流量應該是很小 然後把更新 hash 的東西作成另一個 utility，client 除了 get 也可以 push db server 再多一樣 item aging，一個 struct 大概 25~29 bytes 1M items 也不過佔用不到 30M 記憶體 : 這兩個問題有一點類似, 厲害的大大們可以考慮將 key-value(digest-text) 的 mapping : 擺到 DNS 的 RR 裡去, client 不用再 maintain 愈來愈吃人的資料庫, 查詢反應也不差. : server 也落得清鬆 ( DNS 本身就是一個超大的 cache system ). 只要專心接 case 就好. : 不用煩惱資料怎麼同步到 client. 這個可能是不同 scale 的東西喔 一台 DNS 負責的區域太大的時候往往會把子網域下放 可是現在可能只有一台 DNS 要負責幾萬筆 @@ 又，DNS 的 expire 是一整個 zone 在 expire 的 如果我們要作 aging 的話，也許還是自己寫一個小程式出來比較好 --

※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 61.31.163.51