#1 - 2017-11-16 20:22
Willian
排序似乎和相關度沒有關係:




結果和標籤一點關係都沒有吧。


推薦用「 BM25 」做排序, 效果應當會好很多。
好處是既能考慮到標籤在一個作品中的重要性, 又能考慮到作品本身的人氣。
詳見: https://en.wikipedia.org/wiki/Okapi_BM25
#2 - 2017-11-16 21:24
(いいんです)
先不管排序的问题
tag是用户自己打的
#2-1 - 2017-11-16 21:42
Willian
正因為是用戶自己打的,用BM25才有意義。

作為解釋:
BM25 會用一種辦法權衡 TF 和 IDF
TF 指的是 用戶打tag的多少
IDF 指的是 同一個tag被作品使用的情況

簡單得總結起來就是:
用戶對一個作品的同一個某個Tag打得越多,在這個Tag的排名越靠前
但是同一個作品中其他Tag的數目越多,那麼在這個Tag的排名越靠後
總體來說一個作品被用戶Tag的數目越多,那麼這個作品會越靠前

其他還有對多Tag的支持等現在的tag頁面不支持的功能,不過「能做到的先做到,為未來做好準備」順手加上去也不錯。

BM25 的確不會產生很好的結果, 但比起「按照時間」「按照名稱」這樣的排列要有意義得多。
在此之上的修正會有許多,例如「根據發布時間調整權重」,「根據人氣 Rank 調整權重」,如果首先讓結果變的有意義起來,那這些錦上添花的修正再加上也是非常不錯的吧。
#2-2 - 2017-11-16 21:45
Willian
忘了解釋一點,「為什麼這是排序問題?」

因為點開一個標籤頁面的時候, 相當於是在標記著這個標籤的千千萬萬個作品中挑出20個。
那麼也就是實際上是:
對千千萬萬個作品按照一定標準排序,然後挑出前20個。
#2-3 - 2017-11-16 21:52
Rくん
willian 说: 忘了解釋一點,「為什麼這是排序問題?」

因為點開一個標籤頁面的時候, 相當於是在標記著這個標籤的千千萬萬個作品中挑出20個。
那麼也就是實際上是:
對千千萬萬個作品按照一定標準排序,然後挑出前20個...
看网页上方:按排名/日期/名称排序,已经告诉你是怎么排的了。
#2-4 - 2017-11-16 22:03
Willian
Rくん 说: 看网页上方:按排名/日期/名称排序,已经告诉你是怎么排的了。
非常抱歉,我的說明不足。

「為什麼這是排序問題?」
是在自問自答地解釋
「為什麼『頁面的結果質量不好』實際是一個排序問題?」
並不是質疑「為什麼Bandumi不提供排序?」。

這邊並沒有這樣的質疑。
為了解除可能的疑慮,事先聲明:我也沒有在質疑現有的3個排序方法存在意義。
事實上我認為有名稱排序、時間排序、總體排名排序對於想要把整個Tag下所有內容都整理/看一遍的用戶來說,存在意義是很有必要的。
#3 - 2017-11-16 21:55
(请不要在未经许可时在本站外引用我在本站的留言 ... . ...)
是的,标签是用户加的,效果很迷。但我觉得大概并没有改进的计划(bgm38)
有人做了多标签搜索功能,不知道你想不想用。
#3-1 - 2017-11-16 22:05
Willian
非常有用的信息。
我去看了一下找到了這裡不存在的功能:
「按评价数排序」
#3-2 - 2017-11-16 22:10
Willian
不過似乎結果雖然比起原來有不少改進,依然比較糟糕。

我想 BM25 一定會是一個不錯的開始。
#3-3 - 2017-11-16 22:11
Rくん
Willian 说: 不過似乎結果雖然比起原來有不少改進,依然比較糟糕。

我想 BM25 一定會是一個不錯的開始。
别想了,要不自己做一个出来,要不这个功能就不会有。我真不是说着玩的(bgm38)
#3-4 - 2017-11-16 22:12
Willian
Rくん 说: 别想了,要不自己做一个出来,要不这个功能就不会有。我真不是说着玩的
嗯, 我去問問那邊的作者。 順帶考慮一下吧。
#3-5 - 2017-11-18 07:08
dhzy
Willian 说: 嗯, 我去問問那邊的作者。 順帶考慮一下吧。
别考虑了,快做吧
#3-6 - 2017-11-24 04:16
Willian
dhzy 说: 别考虑了,快做吧
最後還是決定自己做了。
雖然會加上一點額外的功能,但是考慮到一些原因,在中國的訪問可能速度不快。
請不要期待地敬請期待吧。
#4 - 2017-11-18 04:20
(A.T.Field)
加功能,改需求,最需要的是给钱(bgm38)
#5 - 2017-11-18 11:47
(媛娇系是检验大法的唯一标准)
sai可以考虑卖数据啊,三年前的免费开放,vip的可以看一年以前的,年费会员可以看实时的(bgm38)
#5-1 - 2017-11-18 11:54
君寻
Sai老板会缺这点钱?(bgm83)
#5-2 - 2017-11-18 13:34
lhb5883-污喵王VIP⑩
君寻 说: Sai老板会缺这点钱?
但是也没钱买好服务器啊,三天两头被爬爬虫爬挂还不如主动把数据开放出来。
#5-3 - 2017-11-18 13:45
Rくん
污喵王你又说笑了(bgm38)
#5-4 - 2017-11-18 13:48
A.one
其实那些条目包括人物的图 班固米都是没有被授予使用权的
这个网站不会被告很大程度上是因为不是盈利性质的
如果直接产生利益的话可能就会有版权问题了...
#5-5 - 2017-11-18 13:49
windrises
lhb5883-污喵王VIP⑩ 说: 但是也没钱买好服务器啊,三天两头被爬爬虫爬挂还不如主动把数据开放出来。
-哼,本小姐会缺那点钱吗(Sai酱拨动了一下自己的双马尾恶狠狠地瞪了我一眼
几天后...
-喂喂!这些脏兮兮的虫子都爬烂我的衣服了,快让他们走开!呜呜呜...
#5-6 - 2017-11-19 19:29
Willian
windrises 说: -哼,本小姐会缺那点钱吗(Sai酱拨动了一下自己的双马尾恶狠狠地瞪了我一眼
几天后...
-喂喂!这些脏兮兮的虫子都爬烂我的衣服了,快让他们走开!呜呜呜...
在「是否做這個的」考慮時,我也有相同的顧慮呢。
想以每小時更新的頻率來爬取內容,但又擔心負載會對服務器造成壓力。
#5-7 - 2017-11-24 08:50
此间的少年x
Willian 说: 在「是否做這個的」考慮時,我也有相同的顧慮呢。
想以每小時更新的頻率來爬取內容,但又擔心負載會對服務器造成壓力。
每小时更新完全没必要吧,标签这玩意又不会在短时间内有什么大变动(除了一季结束新一季开始的时候),一天更新一次都嫌多
#5-8 - 2017-11-24 08:58
Rくん
此间的少年x 说: 每小时更新完全没必要吧,标签这玩意又不会在短时间内有什么大变动(除了一季结束新一季开始的时候),一天更新一次都嫌多
我觉得3个月更新一次标签都不嫌少(bgm38)
#5-9 - 2017-11-24 12:32
Willian
此间的少年x 说: 每小时更新完全没必要吧,标签这玩意又不会在短时间内有什么大变动(除了一季结束新一季开始的时候),一天更新一次都嫌多
頻繁的更新是為了獲得更精準的歷史趨勢,來提升標籤的結果質量。
BM25 ⬅️單是這口感覺還是有些稀薄。
參考 Google 搜索的響應時間在半小時內(能夠搜索到半小時內互聯網上發生的事情), 我想它們爬蟲的最高頻率應該更高吧。(不論主動被動)

Google 能做到更好當然還有其他史詩級魔法的幫助,不過我相信(能夠做到)高頻率也是其中一個非常有影響力的因素。
#5-10 - 2017-11-24 15:05
Vincent
Willian 说: 頻繁的更新是為了獲得更精準的歷史趨勢,來提升標籤的結果質量。
BM25 ⬅️單是這口感覺還是有些稀薄。
參考 Google 搜索的響應時間在半小時內(能夠搜索到半小時內互聯網上發生的事情), 我想它們...
看下来之后,先说结论吧,就你现在的做法,我持「反对」意见,主要因为你对于「度」的把握所以后面口气可能也会有点问题(bgm120)

- 首先关于你的内容
「最坏情况128条/秒」以及「虽然不想造成压力,但是因为懒可能还是不管速度」这两条,你是否还没意识到这请求频率过高了?参照7月以来大概有3500活人的说法(来源),这一个功能就相当于全部活人每30秒请求一次,24小时不间断。或者你可以算下一天你会占掉服务器多少流量和带宽。

- 其次关于「人少的时间」
参考人的作息时间以及程序判断(后面会说)

- 然后关于频率
30分钟刷新一次,你这么做的结果就是发现没几个条目标签会有变化。你自己也提到了可以根据 timeline 来判断,每分钟更新的动态都没几条,如果只刷新这部分标签,每秒1次都过于浪费。另外有编辑的条目可以以 wiki 页面为判断,只刷新被编辑条目。两者加起来,每分钟也很难到上百条目,即:每秒请求1个条目都可能比较浪费服务器资源。
补:不在 timeline 和 wiki 这两者之间直接点tag的小概率(个人觉得)可以靠低频更新冷条目解决,如 Rくん 所说,3个月一轮问题都不大。虽然你说了增量,不过我怕你一懒就全部刷一遍了

- 关于不想造成压力
我随便说几个,比如可以按照「响应时间」、「出错概率」、「更新的命中率」等来参考。
「响应时间」就不用说了,要是慢了就请降低频率。
「出错概率」同理,要是频繁502等报错,即使不是你的关系,也请降低频率,因为对服务器来说总压力是不小的(也可能是其他非服务器因素)。
「更新的命中率」是比较重要的,你半小时刷新一轮,结果发现就改了几条,emmmm,wtf。所以至少做到请求要是发现没变化,请该条目更新降低频率。
更多的可以自己优化,向着「服务器有什么样的反应是压力大导致的」这个方向即可

最后说一句(以下出于个人主观)
出发点是好的,但要注意做法。「好的出发点」并不能成为「因做法问题而导致的不好的结果」的辩解理由
补:蛮期待标签搜索的优化,现在的体验确实(bgm38)
#5-11 - 2017-11-24 15:44
Willian
Vincent 说: 看下来之后,先说结论吧,就你现在的做法,我持「反对」意见,主要因为你对于「度」的把握所以后面口气可能也会有点问题

- 首先关于你的内容
「最坏情况128条/秒」以及「虽然不想造成压力,但是因为懒可能...
這邊的說法讓你產生了誤解深感抱歉。
我想解開一些誤會:

# 30分鐘更新完畢
並沒有在說「30分鐘內把整站都爬一遍」
而是指「30分鐘將本地更新到最新」
所以假設真的「发现没几个条目标签会有变化」, 那樣的話,最佳情況是,在30分鐘之內滿足只有那些條目被(向本地)更新。(後面討論為什麼是「最佳」而不是「固定」)
至於「30分鐘」概念提出的意圖並非設立一個跑分標準,而是為了量化與初步訂下可以確定的指標。


# 對於速度的把握
我發現 BGM 在用 CloudFlare 做反向代理,有預期到 CF 那邊*可能*設置了緩存。
如果是這種情況,總之對於 <1kps 的請求來說, CF 應該可以無痛不養接受下來吧。
這也是考察期的一個重點。
除此之外我也有在觀察 BGM 在那些層面做了緩存。一個發現是「timeline 應該是存在緩存機制的」(後面討論更多)
#5-12 - 2017-11-24 16:07
Willian
Vincent 说: 看下来之后,先说结论吧,就你现在的做法,我持「反对」意见,主要因为你对于「度」的把握所以后面口气可能也会有点问题

- 首先关于你的内容
「最坏情况128条/秒」以及「虽然不想造成压力,但是因为懒可能...
# Timeline 的七七八八
根據觀察 timeline 的更新似乎存在週期,而且內容會發生聚合/變化。
最糟糕的是 Timeline 並不支持 Paging,也就是說短期內如果發生了大量 events, 那麼就一定會 miss 掉一些 event。
這些增加了難度於,甚至完全阻斷了通過 timeline 來準確獲得更新條目的方法。
這也是為什麼我之前提到 timeline 的時候用的是「參考」的原因。

# 「魔法」
我設想,將 timeline 看作一部分,使用帶有 heuristic 的方法或者使用 ML 的一些辦法來獲取「更新判斷」,不過這些需要時間,我不想在爬蟲的問題上滯留太久是這裡的糾結點。

# 「响应时间」、「出错概率」
都是非常好的建議,非常適合放入「魔法」中呢 (試著插入一個表情但是沒有找到於是括開一點描述一下大概是「安楽が」的感覺)

# 關於「正確請求量」的初期判斷
基準判斷是,對於普通 PC 級別的伺服器來說,10ms 的響應時間應當已經是非常奢侈的請求了。

一個還未考量的因素是 Tag 是否存在緩存。哪怕是數據庫級別的緩存,只要不存在運算,那熱門作品就不會造成很多傷害,較為一般的設計在 2ms 內能夠完整(在伺服器)渲染完畢頁面也是常理中。(即使 PHP 也如此吧)

但是奢侈地認為瓶頸不在流量上也是不當的,雖然除去了很多靜態文件(CSS/JS)的請求,但網頁本身也有不少的流量。這裡有我的另一個糾結點:是否要/怎樣做 Benchmark?
#5-13 - 2017-11-24 17:20
Vincent
Willian 说: # Timeline 的七七八八
根據觀察 timeline 的更新似乎存在週期,而且內容會發生聚合/變化。
最糟糕的是 Timeline 並不支持 Paging,也就是說短期內如果發生了大量 eve...
关于CF部分没有去考究过,不过压力虽然不在服务器,也会在站长的账单上wwwwww

这个先不说,Timeline 会整合一定数据这点,大多数情况下达不到需要 miss 的量,每页最远的条目也是好几分钟之前,所以每分钟一次 timeline 再去重即可。(个人印象中整合了也会简略的显示条目,所以根据条目的 url 还是可以知道作品条目)

即使发现有miss的,你可以到对应用户的 timeline 里面去找,至少用户不会被整合掉,本身这种情况就很少了所以这部分并不会丢失多少数据。

然后加上 wiki 是 5min 刷一次,但是 5min 内新的条目并没多少,列表大多数还是前 5min 甚至更早的时候编辑的,所以反倒是去重比较重要。

至于标签缓存,现在说可能没什么可信度,你做了就会发现,缓存几天关系都不大,根本不会变多少,倒是我觉得自动提取有效的标签比较难。

除去以上部分,剩下你担心遗漏的,通过更新的命中率(每次更新有变化次数/总更新次数)来调整刷新频率即可。

对了,那个初始数据可以让服务器计划任务凌晨两三点开始到早上五六点之间,反正都是睡一觉就好的事,还能减轻负担。好像混入了什么糟糕的言辞
#5-14 - 2017-11-24 17:50
Rくん
Willian 说: # Timeline 的七七八八
根據觀察 timeline 的更新似乎存在週期,而且內容會發生聚合/變化。
最糟糕的是 Timeline 並不支持 Paging,也就是說短期內如果發生了大量 eve...
标签信息变动不会太快的,已经完结的三个月更新一次都没啥问题的。新番开播时我觉得顶多一周更新一次也够了...(bgm38)
至于用户信息,那个太多了,而且没用,不要爬了(bgm38)
#5-15 - 2017-11-24 18:37
Willian
Rくん 说: 标签信息变动不会太快的,已经完结的三个月更新一次都没啥问题的。新番开播时我觉得顶多一周更新一次也够了...
至于用户信息,那个太多了,而且没用,不要爬了。
標籤信息的更新更多是指計數器、BM25算法的有效性就依賴這點了。
更新的需要在於獲得變化趨勢,這一數據在算法的後續改進(其實也是我想做這個的主要目的)上有意義。
用戶信息是在以上都還不夠好的情況下再加強的(並非主要考慮、計畫上會去做的可能性比較低)

總之目標的最終效果是:
點開標籤第一頁就有想要看卻一直沒發現的作品(目標作品)。
更高目標是:
前三項就是目標作品。
#5-16 - 2017-11-24 18:50
Willian
Vincent 说: 关于CF部分没有去考究过,不过压力虽然不在服务器,也会在站长的账单上wwwwww

这个先不说,Timeline 会整合一定数据这点,大多数情况下达不到需要 miss 的量,每页最远的条目也是好几分钟...
這裡需要解釋/討論的地方比較多、後ほど改て回覆你。
#5-17 - 2017-11-29 06:20
Willian
Vincent 说: 关于CF部分没有去考究过,不过压力虽然不在服务器,也会在站长的账单上wwwwww

这个先不说,Timeline 会整合一定数据这点,大多数情况下达不到需要 miss 的量,每页最远的条目也是好几分钟...
1.
关于CF部分没有去考究过,不过压力虽然不在服务器,也会在站长的账单上wwwwww
CF 如果沒有特別的要求的話應該是免費的那一個級別,即使要付費也是不按照流量來算的。詳見這裡
不過不管怎樣我應該不打算經過 CF 訪問了,我找到了 BGM 所在的伺服器,準備從他家旁邊直接接一根管子插進去 OwO

2.
大多数情况下达不到需要 miss 的量,每页最远的条目也是好几分钟之前,所以每分钟一次 timeline 再去重即可。
問題在於 miss 發生了就是不可忽視的,因為一旦發生了意味著這段時間內有大量的活動發生,很可能是某個重要的 event 導致的。
而且 miss 發生了就沒有除了整站爬取以外的 有保證的 獲取方法。
不過不管怎樣,根據「timeline 有 cache」這一觀察, 存在可能: miss 不管使用什麼頻率獲取 timeline 都無法避免。
如果是上述情況,就需要 timeline 以外的方法來獲得 updates。
(此處跳出 timeline 話題)

3.
即使发现有miss的,你可以到对应用户的 timeline 里面去找,至少用户不会被整合掉,本身这种情况就很少了所以这部分并不会丢失多少数据。
按照2 所說的,一旦 miss 了 連用戶都不知道是哪一位 update 了, 也就不可知了。

4.
然后加上 wiki 是 5min 刷一次,但是 5min 内新的条目并没多少,列表大多数还是前 5min 甚至更早的时候编辑的,所以反倒是去重比较重要。
wiki 與2,3的問題對比,不存在擔心的地方。 因為 wiki 是有 paging 的, 刷新速度不影響完整性。

5.
至于标签缓存,现在说可能没什么可信度,你做了就会发现,缓存几天关系都不大,根本不会变多少,
updates for tags 重要的地方並不在 name of tag 而在於 count of tagging, 因為 count 是 構成算法的基礎,也是 Trending 方法 關注的部分。

6.
倒是我觉得自动提取有效的标签比较难。
標籤的有效性是由算法保證的,並不在當前問題下。
至於「為什麼少的標籤不需要去掉」,見我對基礎的 BM25 算法原理解釋: #1-2

7.
除去以上部分,剩下你担心遗漏的,通过更新的命中率(每次更新有变化次数/总更新次数)来调整刷新频率即可。
我很認同你的觀點。
之前我自己說到的 updates 可能需要用 ML 的方法來做, 我仔細思考覺得這樣並不正確。
有簡單的方法可以預測 trends,包括對歷史 update 的 smoothing 。
現在我的考慮是用較慢的速度全體爬來保證更新能夠被獲得,用一些 timeline 來獲得 updates。
當 timeline 發生 possible miss 的時候, 再用預測來 cover。

以上
感謝你的建議與反饋,我將在近日內儘快展開計畫。
#5-18 - 2017-11-29 06:40
Willian
雖然以上說了那麼多關於爬蟲的事情,不過依然強調:
我的重點不在爬蟲上,也不想在爬蟲上。
#5-19 - 2017-11-29 09:51
Vincent
Willian 说: 雖然以上說了那麼多關於爬蟲的事情,不過依然強調:
我的重點不在爬蟲上,也不想在爬蟲上。
很高兴看到你对这些问题都有不少自己的考虑,那么,祝你顺利:)
#6 - 2017-11-24 04:21
== 進度匯報 ==
#6-1 - 2017-11-24 04:22
Willian
# 總體
預計3天後開始

# 現在的步驟:
- 爬蟲的各種實驗
- 成本的核算

# 預期的目標
- 在半個小時內將所有作品頁面爬下來

# 正在躊躇的計劃
使用「魔法」製作出支持較為智能的增量抓取爬蟲
#6-2 - 2017-11-24 08:49
Rくん
Willian 说: # 總體
預計3天後開始

# 現在的步驟:
- 爬蟲的各種實驗
- 成本的核算

# 預期的目標
- 在半個小時內將所有作品頁面爬下來

# 正在躊躇的計劃
使用「魔法」製作出支持較為智能的增量抓取...
网站服务器比较脆,半小时爬完受的了吗?
#6-3 - 2017-11-24 08:55
此间的少年x
Rくん 说: 网站服务器比较脆,半小时爬完受的了吗?
bgm动画词条不到13000,也就是每秒7.2条,感觉还行,当然如果楼主是指所有词条那当我没说…
#6-4 - 2017-11-24 10:30
Vincent
此间的少年x 说: bgm动画词条不到13000,也就是每秒7.2条,感觉还行,当然如果楼主是指所有词条那当我没说…
(bgm38) 当初 3-4/min 还在考虑是不是太高了,尽量不要加压力,这每秒那么多次要是我肯定 ban 掉
#6-5 - 2017-11-24 10:52
Willian
此间的少年x 说: bgm动画词条不到13000,也就是每秒7.2条,感觉还行,当然如果楼主是指所有词条那当我没说…
嗯。。。所有詞條√
#6-6 - 2017-11-24 10:52
Willian
Vincent 说:  当初 3-4/min 还在考虑是不是太高了,尽量不要加压力,这每秒那么多次要是我肯定 ban 掉
分佈式√
#6-7 - 2017-11-24 10:59
Vincent
Willian 说: 分佈式√
emmm...和分布式有什么关系?最终这些请求都是要在半小时内打到网站的服务器上的,对BGM来说压力没差
(bgm38)还是你想说躲开 ban 的策略...总觉得不太好
当然如果你没打算改变想法的话,我希望你选个没什么人访问的时间,以免影响其他用户体验
#6-8 - 2017-11-24 12:17
Willian
Vincent 说: emmm...和分布式有什么关系?最终这些请求都是要在半小时内打到网站的服务器上的,对BGM来说压力没差
还是你想说躲开 ban 的策略...总觉得不太好
当然如果你没打算改变想法的话,我希望你选个没...
做個計算吧:
現在是 230714 條,半個小時全部爬完的話 就是一秒 128 條。
#6-9 - 2017-11-24 12:22
Willian
Vincent 说: emmm...和分布式有什么关系?最终这些请求都是要在半小时内打到网站的服务器上的,对BGM来说压力没差
还是你想说躲开 ban 的策略...总觉得不太好
当然如果你没打算改变想法的话,我希望你选个没...
其實 「是不是要半個小時爬完」的問題在於「要不要每小時更新」。
關於這個必要性的討論放到 #5 裡吧,這裡保持在「需要每小時更新的情況」。


雖說「半小時更新完」是一個比較嚴苛的要求,不過也只是把它當作「最壞的情況來看」因為:
- 對於一次性爬完,並不需要那麼嚴格的時間條件。
- 對於之後的「更新」可以使用魔法(增量更新)完全不需要整站重爬。
#6-10 - 2017-11-24 12:27
Willian
Willian 说: 其實 「是不是要半個小時爬完」的問題在於「要不要每小時更新」。
關於這個必要性的討論放到 #5 裡吧,這裡保持在「需要每小時更新的情況」。


雖說「半小時更新完」是一個比較嚴苛的要求,不過也只是把它...
那樣的話,問題就在「魔法有多麼神奇」上了:
魔法越神奇(更新選擇越精準),需要爬的內容越少。

只是魔法的神奇也就意味著更加複雜。

現在魔法的核心屬性是:
「哪些作品會被頻繁地修改 tag?」
有的輔助信息是整站的時間線(https://bgm.tv/timeline)。
#6-11 - 2017-11-24 12:31
Rくん
Willian 说: 其實 「是不是要半個小時爬完」的問題在於「要不要每小時更新」。
關於這個必要性的討論放到 #5 裡吧,這裡保持在「需要每小時更新的情況」。


雖說「半小時更新完」是一個比較嚴苛的要求,不過也只是把它...
没有必要,3个月更新一回都毫无问题(bgm38)!!!
#6-12 - 2017-11-24 12:34
Willian
Rくん 说: 没有必要,3个月更新一回都毫无问题!!!
我們去 #5 聊! (拽
#6-13 - 2017-11-24 13:45
Willian
Vincent 说:  当初 3-4/min 还在考虑是不是太高了,尽量不要加压力,这每秒那么多次要是我肯定 ban 掉
雖然很希望自己不會對 BGM 造成壓力。
但要是一不小心心癢手抖偷懶不想寫限速, 不,我是說萬一的情況,可以給我一個參考的「人少」的時間段嘛?

萌新剛來不怎麼了解行情。
#7 - 2017-11-24 12:43
@Sai 看看能不能召喚到
#8 - 2017-11-24 16:03
半个小时,突然想起之前爬用户信息花了快一周(bgm38)
#8-1 - 2017-11-24 16:10
Willian
我也有考慮是否要爬用戶信息,但是這是後期的考慮了。
用戶信息可以很大程度上完善檢索結果,但是涉及到的隱私問題以及「技術設計可能花費太久」的問題就暫時放下了。

如果初期的檢索結果不佳的話還是會繼續考慮的吧。

對了,雖然我前兩天剛註冊,ID 應當是 378785。
比起總作品數目要多呢。(未能插入的表情:😊)
#8-2 - 2017-11-24 16:30
Willian
Willian 说: 我也有考慮是否要爬用戶信息,但是這是後期的考慮了。
用戶信息可以很大程度上完善檢索結果,但是涉及到的隱私問題以及「技術設計可能花費太久」的問題就暫時放下了。

如果初期的檢索結果不佳的話還是會繼續考...
不過一個星期就算是全站也是太久了。(感覺像是在給自己立死亡Flag
#8-3 - 2017-11-24 17:57
CrazyScientist
Willian 说: 不過一個星期就算是全站也是太久了。(感覺像是在給自己立死亡Flag
就是最普通的抓取,没有任何的优化,爬了好像接近700w的页面,我仿佛听到了mysql在痛苦的哀嚎,再也不敢玩第二次了(bgm38)
#8-4 - 2017-11-24 18:05
CrazyScientist
CrazyScientist 说: 就是最普通的抓取,没有任何的优化,爬了好像接近700w的页面,我仿佛听到了mysql在痛苦的哀嚎,再也不敢玩第二次了<img src="/img/smiles/tv/15.gif" smileid="...
拖慢速度的大概是因为我把存数据和提取链接放一块了,开一个线程存数据大概就好了吧
#8-5 - 2017-11-29 06:25
Willian
CrazyScientist 说: 就是最普通的抓取,没有任何的优化,爬了好像接近700w的页面,我仿佛听到了mysql在痛苦的哀嚎,再也不敢玩第二次了
一些對爬蟲優化的建議:
速度可能卡在 MySQL 的 IO 上, 如果使用 NoSQL 系列效果可能會更好。
不過這一點也要看你存儲多少數據,如果IO量非常大,比如將整個頁面存取下,你可能不能使用數據庫,要使用別的方法。