沒有 Query Engine、沒有索引，這樣真的能叫「資料庫」嗎？

Day23 講了為什麼選 S3 存 JSON，這篇想更誠實地談這個決定的代價：S3 不是資料庫，它只是一個檔案儲存空間。

🧱 地基概念

資料庫比「檔案儲存」多做了什麼

可以用「檔案櫃」跟「有圖書館員的圖書館」來比喻。S3 像檔案櫃：你告訴它檔名，它把整份檔案拿給你。資料庫像圖書館員：你說「我要三百大卡以下的早餐」，它會幫你找出符合的那幾筆。這份「幫你找」的能力，主要來自三樣東西：

• 查詢引擎與索引：讓資料庫不用一筆一筆翻，就能快速找到符合條件的資料
• 交易（transaction）：一組操作要嘛全部成功、要嘛全部不算，不會做到一半
• 並行寫入的處理：好幾個人同時改資料時，不會互相蓋掉

線性掃描 vs 索引查詢

沒有索引的時候，找資料只能從頭一筆一筆看，這叫線性掃描。資料少的時候這件事很快，資料多到一個程度才會變成問題。

🔧 實際操作

這個方案實際上放棄了什麼

• 沒有查詢引擎：找資料的方式，是把整個 JSON 讀進記憶體，用陣列的 filter、find 一筆一筆掃，不是 SQL 那種索引查詢
• 沒有交易保證，也沒有並行寫入的機制：但這個專案本來就是「只讀、極少寫」的使用型態，目前不痛
• 有大小上限的思考：1915 筆全部塞進記憶體目前沒有壓力，但這不是可以無限成長的架構

那為什麼還是這樣做

因為在這個規模與讀寫型態下，S3 加 JSON 換來的簡單，遠大於它犧牲的查詢能力：不用設計 schema migration、不用管連線池、不用學新的查詢語法。「讀一個檔案、在記憶體裡篩選」這件事簡單到幾乎不會出錯，而這個food DB裡 1915 筆的線性掃描，在 Lambda 的執行時間內完全感覺不到延遲。專案裡依 mealSlot 與熱量篩選候選食物，就是用 filter 完成的。

什麼時候這個決定就不成立

我自己抓的分界線是「幾千筆以上」，或是「需要頻繁寫入、多個來源同時更新」的情境。到那個規模，記憶體佔用、掃描效能、資料一致性都會開始浮現問題，才是真的該換成 DynamoDB 之類資料庫的時候。

延伸補充一：Amazon Athena，讓界線變得更模糊

後來查資料才知道，AWS 有個服務叫 Amazon Athena，可以直接對放在 S3 裡的 JSON、CSV、Parquet 檔案下 SQL 查詢，不用先匯入資料庫。這是官方正式支援的用法（把 S3 當「資料湖 Data Lake」），某種程度上真的模糊了「檔案儲存」跟「資料庫」的界線。這個專案目前沒有用到，因為現在的查詢用 filter 就綽綽有餘，加 Athena 反而是不必要的複雜化。但如果之後資料大到記憶體裝不下、想用 SQL 查詢，它會是比直接跳去 DynamoDB 更輕量的中間選項。

延伸補充二：S3 也有一些類似資料庫的保護機制

S3 有 Versioning（版本控制）、Object Lock（防止刪除或覆寫）、MFA Delete（刪除需要雙重驗證）。不過這些解決的是「資料不小心被弄丟或改壞」，不是「交易一致性」，所以 S3 有資料庫的影子，但終究不是資料庫。

小結

這篇也是整個 Part 5 最大的體悟：技術選型不是選「正確答案」，是選「跟目前規模與需求相符的答案」。 同一個選擇，資料量變大十倍之後可能就不成立，重要的不是這次選對了，而是清楚知道「這個選擇的有效期限在哪裡」。

回頭看 Part 5：Day20 承認 AI 缺的是資料，Day21 設計資料的長相，Day22 把資料蒐集回來，Day23、Day24 決定放在哪裡以及它的代價。資料準備好了、後端也串起來了，下一個 Part 要進入使用者實際看到的畫面：Day25 從表單設計開始。