為什麼在區網搜尋檔案，總是那麼慢？
不論是個人作業或辦公環境，終端工作站單純化是近年來的趨勢。辦公室座位上不必再建置笨重的電腦主機或佈線，用行動性高的筆電來取代桌機，開會時也方便許多。
然而，為了兼顧行動力，大部份商用筆電在體積、 I/O 及擴充能力上會以精簡的形式現身。部份機種甚至會跟 Macbook 一樣採用封閉式架構，只留一至兩個 USB Type-C 外接擴充，內建的儲存空間亦十分有限，資料一多時，在管理上便會非常拗手。
此時，透過無線網路連接區網的儲存空間會是較理想的作法，比如在 NAS 上建立共享資料夾，甚至將其當作延伸的資料儲存裝置，只要網路環境允許，在一般的辦公文件應用情境是絕對可行。
存取檔案很方便，找檔案呢？
把資料放在區域網路內的公用槽上，大家都會，痛點在於，找檔案不是很方便。Windows 使用者習慣開檔案總管，Mac 玩家會透過 Finder 或 Spotlight 翻查資料，如果是尋找本機端的檔案，沒啥問題，但若是透過 SAMBA 協定掛載了網路磁碟機，這種作法雖然一樣有效，速度卻會慢上不少。
原因在於，本機 OS 內建的檔案管理工具，在查找本機資料及區網檔案的作法上存在實質差異，即使都是在檔案總管裡打關鍵字搜尋，背後運作的機制卻截然不同。要了解為什麼在區網找檔案效率總是那麼低、以及如何加速此工作，我們要先了解，作業系統裡檔案的搜尋是如何運作的。
本機檔案的查找原理
不同的作業系統，會習慣使用不同的檔案系統，磁碟區在使用前，會先格式化成對應的檔案系統，才能進行讀寫。比如 Windows 的 NTFS、Mac 的 APFS，以及 Linux 的 ext4 、ZFS 等，都是一般單機常見的檔案系統，有些雲端主機或伺服器會採用更複雜的格式來做存取的加速及備援，於此就不贅述。
大部份的檔案系統，都會以樹狀結構存在，可想像成是實際生活中存在的郵政地址。比如新北市有五股區及新莊區，新莊區又有中正路及中華路等等，如果我們把某個住戶比喻成檔案，那麼他的戶籍地址就是檔案所在位置。
現在我們可以想像，如果某個行政單位（電腦使用者）想要查找某個人住在哪（檔案放在什麼位置），會如何找起？
舊一點的檔案系統，比如 FAT，會採用非常愚蠢的線性作法。如果今天要找「王小明」住哪，就會從台北市的第一個行政區開始找，遍歷過市內的所有下轄戶藉資料後，再往新北市找，找不到再往桃園市找，一直到找到王小明三個字為止。
到了 NTFS，作法相較有效率些。檔案系統至少會記錄王小明住在新北市新莊區，所以查找的過程會先檢查新北市這個資料夾是否存在，在的話再檢查新莊區，然後在新莊區這個資料夾查找王小明是否還住在中正路的某個住址。比起上一段所述的線性作法，會節省不少時間。
事實上，現代檔案系統通常會結合作業系統或第三方工具實現更有效率的查找方式，預先建立索引就是其中一種。如果我們能在檔案建立或搬移時，就把它的最終位置紀錄下來，比如戶政系統中會記錄「王小明最後搬到了新莊後建國一路 xxx 號」，那麼日後就直接按址索驥即可，不必再一層一層的翻查。
比如 MacOS 的 Spotlight，或者是 linux 的 locate 命令，會事先透過背景程式建立檔案地址的索引資料庫，在鍵入檔名的同時，就列出檔案路徑，找尋任何已經建立索引的檔案，根本就花不上幾秒。使用 NTFS 的 Windows 則是可以透過 Everything 這一套第三方工具，一樣有異曲同工之妙。
遠端搜尋的先天限制
不管是透過線性搜尋、樹狀查找、或是直接讀取索引資料，在本機硬碟上都是相較簡單的事，尤其在固態硬碟普及之後，就算是再怎麼低效率的檔案搜尋作法，也不會耗用到太誇張的工時。
至於查找網芳上的檔案，就不是這麼一回事了。比如我們在本機 Windows 掛載了一個網路磁碟機，稱之為 Z 槽，在 Z 槽裡找尋 abc.txt，此時檔案總管會不斷的與遠端主機往返資料，遍歷 Z 槽裡的資料夾。找到了第一個 abc.txt，不代表沒有第二個，所以仍得繼續找，使用者會看到滑鼠的遊標一直呈現工作狀態，好像有找不完的資料一樣。
區網間的資料傳輸，在 IOPs 及隨機資料的存取上，與本機硬碟的效能差異是非常巨大的。就算是使用有線網路，不計較傳輸的穩定性，指令的轉譯就會耗用掉不少資源。加上資料傳輸的往返，無形中會浪費不少時間。
那麼，為什麼不在本機建立遠端磁碟機的檔案索引呢？確實可以這麼做。然而要進行這件事，一樣要先遍歷一次遠端硬碟，而且索引後的資料會有時效性，尚未被索引到的檔案變更，一樣有可能會搜尋不到。
透過遠端本機搜尋，才是最快
折衷的作法，反而是直接與遠端主機的檔案搜尋服務溝通。比如在 Linux 系統下，我們在本機掛載了遠端的資料夾，接著在本機執行 find 指令來搜尋這個資料夾，絕對不會比 SSH 登入遠端主機後，在遠端直接執行 find 來得快。
問題在於，在得到了搜尋結果之後，該如何把遠端的本機路徑轉換成本地端看得懂、找得到的路徑，以便做後續的檔案存取。比如當遠端的的搜尋結果跑出檔案位於「/mnt/dev1/dir1」時，本地端的服務可否把這個路徑掛載起來，透過 samba 來存取。
能夠搜尋檔案內容，更加分
前文所提的，都是透過搜尋檔案名稱來找到路徑，如果能夠同時搜尋檔案內容，應用上會更為方便。比如 MacOS 的 Spotlight 一直有此功能，在找尋文字檔時，能夠有很精準的結果，就算忘了檔案名稱也沒關係。
綜合以上幾點需求，配合 QNAP NAS 做為網路磁碟機，我們可以由淺入深的透過幾個作法來達成遠端的快速檔案搜尋及存取。
一、FileStation 5
QNAP NAS QTS 介面內建的 FileStation 5 是網頁化的檔案管理介面，透過它來搜尋檔案，就跟在遠端本機搜尋的作法一樣快速。在找到的檔案上按右鍵，可以直接下載，所以如果只是要「把檔案從 NAS 抓到本機」，透過 FileStation 5 會是最簡單、不需要進行任何工程化處理的作法。
目前新版 QuTS Hero 6 、5.x 作業系統，也提供 FileStation 6 ，介面略有不同，但功能大致類似。
二、Qsirch 智慧 AI 搜尋
Qsirch 是加強型的智能檔案搜尋，透過 AI 的加持，可以支援 RAG、語意搜尋、圖片內容搜尋、甚至是 OCR 等機能。簡單的說，它比一般能夠檢索檔案文字內容的搜尋引擎更強大，更夠搜索到更細部的資料。
Qsirch 一樣可經過 QTS 介面開啟，或是下載 Windows 的本地端應用程式。
三、整合 Qsirch API，打造客製化的搜尋工具
Qsirch 其實是有提供 API 的，此舉可大幅度的簡化本地端與 NAS 端的應用程式溝通。我們只要透過 API 中的參數設定，就可以取得各種不同的檔案搜尋結果，這些結果會以 json 格式回傳，把回傳的結果路徑進行轉譯，即可於本地端掛載並存取。
使用 Qsirch API 之前，必須先取得 NAS 的登入憑證 (sid)：
curl -X POST “http://NAS IP:NAS 埠口/qsirch/latest/api/login/” \ -H “Content-Type: application/json” \ -d ‘{“account”: “你的帳號”, “password”: “你的密碼”}’
成功後，會取得一組 SID，如下圖：
把 SID 再填入如下網址，即可進行搜尋：
curl -X GET “http://NAS IP:NAS 埠口/qsirch/api/v1/search?q=report&sid=xxxxxx&limit=5”
可使用的參數如下：
query – 搜尋關鍵字
start – 起始位置(分頁用)
limit – 回傳結果數量
file_type – 檔案類型(image, video, document, audio)
start_date / end_date – 日期範圍
folder – 指定搜尋資料夾
回傳的結果，大概會是像這樣子：
既然回傳的結果是 json，要使用工具來梳理就簡單多了。有興趣的玩家甚至可以寫個工具，在搜尋列直接帶入要餵給 api 的關鍵字，並且用列表的形式來呈現搜尋結果，相信有了 Vibe Coding，這些都不是難事。
如此一來，要在區網搜尋檔案，就快速簡單多了。我們可以放心的把檔案放在 NAS 上，享受幾乎與本機同樣快速的檔案查詢速度，不必再像以往般大海撈針。
首圖由Google Gemini AI 生成，配圖由AI 生成及自行產製
