※ 引述《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