→ MOONRAKER:這樣只在一個方向勉強算有效率 反過來就超級沒效率 03/24 16:00
→ MOONRAKER:你想一下(1)我現在又按一次讚，怎麼避免我重覆。 03/24 16:01
→ MOONRAKER:(2)我現在要收回讚，怎麼把我收回。 03/24 16:01
→ MOONRAKER:(3)我現在想知道我按過哪些讚(FB界面沒提供，但是API有)03/24 16:02
→ MOONRAKER:要怎麼辦。你想一下在你設計中怎麼快速處理這三個功能。03/24 16:02
回覆 Moo大的建議，
這邊我自己思考了一下。
我會考慮把 like 獨立做成一個table
欄位可能就是.
post_id user_id
就這樣, post_id 表示 此like 跟隨哪一篇post , user_id 則是表明是誰按的讚
如此一來。
如果我需要知道 某篇post 有誰按過讚 就去搜尋 like TABLE , where post_id = XXX
同樣的我也可以在 like Table , where user_id = me
去找尋我like過哪些post
如果要收回like ， 只要delete 即可。
只是這樣一想，覺得fb是在是太威猛了。
如果每次都要讀寫回database 感覺會很消耗系統資源。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 119.77.136.156
→ MOONRAKER:MOONRAKER不是Moo 我拒絕這個簡寫 X( 03/24 23:30
→ MOONRAKER:去年我接觸一個站改版 他也有這種"A,B,C"式的資料欄位 03/24 23:31
→ MOONRAKER:雖然那只是分類 例如一張相片同時屬於人物,旅行,心情類 03/24 23:32
→ MOONRAKER:不會像「讚」那麼頻繁讀寫 仍然使我們幹得要死 XD 03/24 23:32
→ MOONRAKER:可那個站以前也還能夠營運那麼久還不出事情 可能的解釋 03/24 23:33
→ MOONRAKER:就是這樣設計對資料庫的壓力究竟如何 也不是那麼簡單 03/24 23:34
推 gpmm:推一個自己想，壓力這件事可以用 memcache 來解啊 XD 03/24 23:55
推 chenlarry:FB的效能是用錢砸出來的，他們買很多記憶體，但到底有多 03/25 00:31
→ chenlarry:少我不記得了，但我印象中很大，非常大... 03/25 00:31
→ chenlarry:剛剛查了一下資料，FB有800台伺服器，記憶體有28TB.... 03/25 00:37
推 sin282:AKER大 正名 03/25 14:08
→ alpe:FB印象中用了不少NoSQL的方案. 03/26 00:18