Re: [討論] 認證圖集中解碼
※ 引述《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
討論串 (同標題文章)