iT邦幫忙

0

Google相簿背後的系統設計?

  • 分享至 

  • xImage

過去沒接觸過大量圖片的存儲
對於系統設計初學者等級而已
想請教大家

  1. 目前業界通常都是用甚麼在儲存大量圖片?特別像google相簿這樣,大量users、大流量場景的,都用什麼儲存?
  2. Google相簿背後的系統設計?

知道問題有點籠統,範圍也很廣
最近才剛學習,希望有接觸過的前輩們
分享一些相關經驗
比較有方向可以學習

初學者問太早~你先弄小型相簿再說@@..
基本上先要有一個資料庫,接下來就是爬蟲,要去爬頁面圖片的資訊,然後收到資料庫,接著根據 圖片的 ALT TITLE 去歸類,透過JS 儲存縮圖到DB,如果有需要提供特殊查詢分類,你也要用JS把相關資訊存進去,然後就是查詢,根據USER輸入的資訊去資料庫把資料查詢出來,這是基本的邏輯架構,細節表現,就看CODER的功力了
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中
5
froce
iT邦大師 1 級 ‧ 2021-12-15 08:09:04
  1. google目前使用的不知道,不過至少會是使用大型分散式存儲系統的方案
  2. 開源的有MinIO。
    https://min.io/
  3. 整個程式架構、使用的工具...這些都要能支援分散式、cache、DB...幾乎所有層面都要仔細考慮。

因為你問的太籠統,所以也只能回答得很籠統。
如果你還是網頁系統的初學者,那你問這還太早。

5575859 iT邦新手 5 級 ‧ 2021-12-15 14:45:04
【**此則訊息已被站方移除**】
3

目前業界通常都是用甚麼在儲存大量圖片?特別像google相簿這樣,大量users、大流量場景的,都用什麼儲存?

一般是屬於儲存服務的一種,典型的有像是AWS的S3之類的。GCP來說也有類同的東西存在。
觀念跟平常的硬碟或是NAS儲存體有點不太一樣,這是一種物件的概念。
其目的也是為了所謂讀檔不要發生鎖檔的情況。所以大量用戶存取也不會有問題。

Google相簿背後的系統設計?

我也不知道,這你要去問GOOGLE。不過沒意外因該是他們的語言才對。

5575859 iT邦新手 5 級 ‧ 2021-12-15 14:45:19 檢舉

10
海綿寶寶
iT邦大神 1 級 ‧ 2021-12-15 09:40:11

我有三種答案
看你喜歡那一個

1.實作派答案
a.先寫出一套圖書管理系統,只要單純「新增、刪除、修改、查詢」書本「基本資料」,一次查一本
b.在「基本資料」加一個欄位「封面圖檔名」,並加以下功能
新增:新增書本基本資料時「上傳圖檔」,儲存圖檔後記錄於「封面圖檔名」
刪除:修改書本基本資料時「刪除該圖檔」,並清除「封面圖檔名」
修改:修改書本基本資料時「上傳圖檔」,(先刪除原圖檔後)儲存圖檔取代原「封面圖檔名」
查詢:查詢書本資料時增加顯示「封面圖檔檔名」
c.把一次查一本改成一次查多本

2.理論派答案
Google 相簿我不知道,Instagram 的可以參考看看

3.酸民派答案

5575859 iT邦新手 5 級 ‧ 2021-12-15 14:46:39 檢舉

7
japhenchen
iT邦超人 1 級 ‧ 2021-12-15 11:35:19

如果沒有圖片搜尋功能,圖片也沒有過多的後端縮放的話,我會丟在資料庫(公司用MSSQL2019)的TABLE裡,用image欄位存放
因為我真的是受夠了硬碟單一資料夾裡有過多檔案(約超過100萬個檔案)時,會有讀寫檔案龜速的狀況,之前就出現過,硬碟SMART正常,掃描無壞軌,但就是IOPS超低不足2位數

另,研究人家的資料處理方式之前,先學會用小規模架構設計一個有很多很多照片的系統出來,哪怕只是圖書管理(電子化),或是做個小型的購物網站(先別管金流),到了一定程度之後再來想進一步,比如以圖片搜圖片的事,給你一個關鍵字【圖片指紋】比對法,你就能在網上或一堆博碩士論文裡,找到相關的討論及論文參考作法,或是用現成的ML庫來開發

看更多先前的回應...收起先前的回應...
firecold iT邦新手 1 級 ‧ 2021-12-15 11:56:44 檢舉

japhenchen大大請問一下
關於單一資料夾過多檔案得部份
如果用上傳日期區分建立多個子資料夾
會不會好一點?
目前遇過2x萬的這樣處理後正常很多
但百萬級別就不確定了

菩薩慈悲:
  末學存在MS Access資料庫裡的的經驗就是資料庫單一檔案過大,恐怕也有其上限乃至執行效能的問題。很難想像超過100萬張圖片存在一個資料庫會是怎樣的情況
 末學的做法可能會是由一個含索引的資料表去做圖檔名的對照,且圖檔名是有規則可循/尋的。資料夾也是分散處理,立有規則,單一個不要太多,到達某數或什麼規則會另立一個資料夾/路徑,以供檢索。檢索功能全由資料庫管理,找到路徑後再交由檔案總管讀寫/IO。……大抵是醬的構思。感恩感恩 南無阿彌陀佛

froce iT邦大師 1 級 ‧ 2021-12-15 12:58:55 檢舉

你這個狀況是windows?我在猜是OS要掃描檔案做預覽造成的。

圖片放在資料庫!!!!!!!
嗯~~~不與評論好了。

哈~~PASS

5575859 iT邦新手 5 級 ‧ 2021-12-15 14:46:16 檢舉

我見過動輒七八十GB的MDB檔,效能不會差,況且那些都不是圖片存TABLE的例子.....

我舉這個例也是我個人選擇,因為網頁用圖檔的尺寸並不大,還有4K磁區的問題,檔案愈多,碎片化也會愈加嚴重,還有Windows雞婆做縮圖跟索引,大家有空可以試試,在你的伺服器上做一個資料夾,上頭有上百萬個圖片檔,你可以用力的照時間檔名來區分子資料夾,看看速度會不會影響

我是放棄了實體檔案的做法,很多人說,MDB檔壞了,圖片也會壞光.....啊我是沒備份機制啊?我也遇過最上層資料夾掛了,裡面的檔案全部放生的鳥事啊....

重點還是,備份,備份,備份

這個問題,在stackoverflow上討論也好幾年了,在新的資料庫系統上,已經獲得效能及可靠度的測試,好多人遇到的,都不是百萬級別檔案數量的狀況,而是破萬就開始有干擾,再加上防毒軟體的掃描,不知道有多少效能耗費會出現........
https://stackoverflow.com/questions/348363/what-is-the-best-place-for-storing-uploaded-images-sql-database-or-disk-file-sy

BTW,這類問題只能CASE BY CASE,我也沒法一概而論,大檔VS好多好多檔,這些是作業系統層面的問題,誰的效能好?誰容易管理?哪天遇上要遷移時哪個容易?是不是會受到其他層面的干擾?

WHO KNOWS?交給系統建置的分析專業吧

感謝 @japhenchen 菩薩的慈悲賜教,聽君一席話,勝讀十年書,做十年事啊。感恩感恩您寶貴的經驗智慧 不吝撥冗分享 阿彌陀佛

孫守真任真甫
天啊,太詩意了。讓我不得不配服。

1
tw_hsu
iT邦新手 4 級 ‧ 2021-12-16 11:10:49

其實一切都是Server如何取得檔案位置的機制而已
以前的WebServer/WebService有個跟Client端相似的檔案路徑機制
(硬碟上,除了實體檔案以外,還有個檔案位置區。檔案列表或檔案管理程式都是讀取這裡的內容好知道有些什麼檔案在硬碟裡。)
雲端化後,Server/Service變成一堆Node,彼此之間檔案串連的方式跟我們在電腦上打開檔案管理員是完全不同的
(光是靠「實體檔案/檔案位置區」已經不夠了,可能還要「實體檔案/檔案位置區/關聯紀錄/關聯紀錄位置區」...這是舉例)

你問機制是什麼?
坦白說,那種等級的地方這裡是問不到答案的
就跟你問CPU實務設計用的技術跟概念是什麼一樣
大家知道個鳳毛菱角的原理,但講出來一定不能滿足你

但光是用過S3機制的檔案存儲服務,你大概就能掌握到雲端相簿這類服務的核心技術基礎了
剩下的就是如何做個操作介面而已

我要發表回答

立即登入回答