跳至主要内容

資料庫選型比較：NTFS、Access、SQLite、MySQL、LanceDB

背景​

釐清「檔案系統 vs 資料庫」與「嵌入式（檔案型） vs 伺服器型」的核心差異，並理解 Access / SQLite / MySQL 與 LanceDB 在儲存方式、運作方式、併發能力、典型用途上的不同。

結論​

  1. NTFS 管檔案；Access 管資料與關聯。Access 可存附件但通常不作大量檔案庫。補充：Windows 不內建 Access；要用需裝 Office 的 Access 或 Access Runtime（執行）。
  2. SQLite 與 MySQL 都是關聯式，但最本質差異在：
    • SQLite：嵌入式、直接操作 .db
    • MySQL：伺服器常駐、多連線集中管理
  3. 資料庫按部署方式可分「嵌入式 vs 伺服器型」
  4. 通用 OLTP：面向一般業務 CRUD + 交易一致性的通用交易負載。
  5. LanceDB 可被視為「部署哲學像 SQLite 的向量資料庫」，但功能面不等同通用 RDBMS。
面向AccessSQLiteMySQLLanceDB
核心定位桌面DB + 表單/報表/快速應用嵌入式RDBMS引擎伺服器型RDBMS向量檢索導向的資料庫/引擎
是否需常駐服務否（多為檔案）否是（mysqld）常見可不需（視模式）
主要儲存形態.accdb.db伺服器管理的資料目錄/檔本地目錄/檔（依實作）
強項UI、報表、快速交付輕量、可攜、離線多人併發、權限、集中管理向量相似度搜尋、RAG 檢索
常見情境部門小系統App 內嵌資料網站/企業系統RAG/語意檢索/embedding storage

1. NTFS 與 Access：都能放檔案，但不同​

  • NTFS 是 Windows 的檔案系統：目標是「管理檔案與資料夾」。用來存放任意檔案（PDF、PPT、Excel…）並提供目錄、權限、屬性（大小、時間戳）、檔名與路徑管理。

  • Access：資料庫 + 低程式碼應用平台 UI（桌面型關聯式資料庫 + 應用工具）

    • 重點在結構化資料（表格、欄位、索引、關聯、查詢）
    • 內建表單、報表、查詢設計器、巨集/VBA、匯入匯出
    • 常用於快速做部門/桌面小系統
    • Attachment（附件）欄位可把檔案「放進」資料庫，但通常不建議把大量/大型檔案直接塞進 Access（資料庫膨脹、備份慢、多人鎖定與效能風險）
    • 使用 Access 的常見路徑（Windows 不內建 Microsoft Access）：
      • Microsoft Access (Office/Microsoft 365 Apps)：可開發/設計（表單、報表、VBA、表結構）
      • 免費的 Access Runtime：但不能設計
      • 程式讀取 .accdb：可能透過 ACE OLEDB/ODBC 等驅動，也需相應元件

  • 常見架構：

    • 檔案放 NTFS/SharePoint/OneDrive
    • Access 只存「路徑/URL + metadata + 關聯」（例如：檔名、版本、類別、日期、上傳者、與案件/客戶的關聯）

2. 「伺服器型」 vs 「嵌入式」：部署型態差異​

伺服器型（MySQL）如何運作​

伺服器型：程式連線到 DB service（MySQL/PostgreSQL/SQL Server）

  • 有常駐的資料庫服務（例如 mysqld）。
  • 多用戶/多程式透過網路連線（即使同機也走 client/server 模式）。
  • DB 服務統一負責：連線管理、權限、併發控制（多人同時讀寫的協調）、交易一致性、備援等能力。

重點：你的程式不直接碰資料檔；一切由 DB server 管控。

嵌入式/檔案型（SQLite）如何運作​

嵌入式：程式打開 DB 檔或呼叫本地引擎（SQLite/Access/LanceDB）

  • 沒有必須常駐的 server。
  • 應用程式把 SQLite 當作函式庫載入，直接讀寫某個 .db 檔。
  • 適合：單機、行動裝置、輕量部署、離線情境。

重點：你的程式**「打開檔案」就能用**，部署像帶著一個資料庫檔走。

3. 「通用 OLTP」是什麼？​

  • OLTP 定義（Online Transaction Processing）：大量短交易、小筆 CRUD、頻繁寫入/更新、需要交易一致性（ACID1）。例：訂單新增、付款記錄、庫存扣減、帳務轉帳。

  • 「通用」的含義：指能處理多數一般業務系統需求，不是只針對某個特殊查詢領域（如全文檢索、向量近鄰搜尋）而生。

SQLite 被描述為「通用 OLTP 的嵌入式資料庫」，強在一般應用的本機資料儲存與交易操作。

4. LanceDB 是否是「向量資料庫版的 SQLite」？​

  • 按部署型態：LanceDB 更像 SQLite（嵌入式、本地資料）。
  • 按資料庫功能：LanceDB 更像「向量檢索引擎 + 表格化資料能力」，而非 SQLite 那種通用關聯式資料庫。

可以類比的部分（部署型態）​

LanceDB 常見使用方式偏「嵌入式/本地優先」：可用 SDK 指向本地路徑儲存資料與索引，部署簡單、可攜。在「像 SQLite 一樣容易帶著走」這點上，類比成立。

不等同的部分（功能取向）​

  • SQLite 是通用關聯式資料庫（RDBMS）取向：交易、通用查詢是主軸。
  • LanceDB 的核心強項是向量相似度搜尋（ANN/向量檢索），以及搭配 metadata 欄位過濾等能力。
  • 它不等於完整的「通用 RDBMS」（join、交易語義、完整 SQL 生態、企業級管理/權限/審計/複寫等通常不是主設計重心）。

補充：為什麼「向量庫不要拿來當主交易庫（主 OLTP DB）」？​

1. 兩者設計目標不同​

  • **主交易庫（OLTP）**的核心是：大量小筆寫入/更新、強一致交易（ACID）、嚴謹約束（PK/FK/Unique）、可靠復原、權限稽核、多人高併發。
  • 向量庫的核心是：用向量索引做近鄰搜尋（ANN），把「語意相近」的資料快速找出來；多數功能會圍繞索引建置、查詢、過濾與資料載入吞吐。

結果是：向量庫通常不是把「交易一致性 + 約束 + 複雜關聯查詢」放在第一優先序。

2. 常見風險（把向量庫當主交易庫時會遇到）​

(A) 交易一致性與跨表/跨集合更新困難
主交易庫常見需求：建立訂單要寫 order、寫 order_items、扣庫存、寫付款狀態，任何一步失敗要回滾。向量庫多半不以「跨多實體的強交易」為主；你可能做到一半失敗，留下半套資料，之後要靠應用層自己補償（compensation）。

(B) 約束與資料品質控管不足
OLTP 常依賴：UNIQUE（避免重複帳號/單號）、FK（避免孤兒資料）、CHECK（欄位合法性）。向量庫通常不強在這些「資料治理」能力，久了更容易髒資料、重複資料、關聯斷裂。

(C) 更新/刪除成本與索引重建
向量索引通常偏向「為查詢速度犧牲更新成本」：頻繁更新 embedding 或 metadata，可能導致索引維護成本高、碎片化、延遲上升。

(D) 正確性語意：ANN 是近似，不是精確查詢
OLTP 很多查詢需要「準確」：查 user_id = 123 的資料。向量檢索是「相似度前 K 名」，天生是近似與排序問題；把它當主查詢依據，結果隨索引參數/版本/更新而波動——在交易系統是災難（因為你需要確定性）。

(E) 權限、審計、備援/複寫、營運工具鏈常不完整
主交易庫常需要：權限模型（到 schema/table/row）、審計記錄、風控稽核、PITR（時間點回復）、異地備援、複寫、監控、線上 schema migration。不少向量庫在「AI 檢索」情境足夠，但在「金融級/核心交易」要求上，可能要自己補很多周邊。

3. 典型「錯誤用法」範例​

錯誤範例 1：把客戶主檔放向量庫
把 customer、address、contract、invoice 全放向量庫，然後用它當系統唯一資料源。問題：一旦需要嚴格唯一性、有效期限、狀態遷移、對帳與稽核，你會發現非常痛苦。

錯誤範例 2：用向量相似度來「找訂單」
用訂單描述 embedding 去找「那筆訂單」，試圖取代 order_id 精確查詢。問題：召回不保證、結果波動，且很難解釋與稽核。

4. 建議的正確架構：RDBMS 當主庫 + 向量庫當檢索副本​

  • 主交易庫（Source of Truth）：PostgreSQL/MySQL/SQL Server（或 SQLite 若是單機 app）
    • 存：結構化資料、狀態機、交易記錄、權限、約束
  • 向量庫（Retrieval Index / Serving Index）：
    • 存：embedding、文件切片、可用於過濾的 metadata、以及指回主庫的 key（例如 doc_id / row_id）

流程常見是：

  1. 主庫資料新增/更新
  2. 非同步產生/更新 embedding
  3. 寫入向量庫（當作索引/副本）
  4. 查詢時：先向量庫召回 doc_id → 再回主庫用 doc_id 精準取詳細資料與做權限判斷

結論：主庫負責「正確性與交易」；向量庫負責「相關性與召回」

5. 什麼情況「幾乎可以」讓向量庫當主要儲存？​

只有在下面這類情境才比較合理（仍不建議稱為主交易庫）：

  • 你的資料本質是「文件/段落/筆記」為主，不需要嚴格交易（例如純 RAG 知識庫）
  • 寫入不頻繁、資料更新以批次為主
  • 可接受 eventual consistency（晚一點同步沒關係）
  • 權限/稽核要求低，或你有額外系統補足

換句話說：它可以是「主要檢索來源」，但仍不應承擔「核心交易正確性」。

6. 實務檢核清單（判斷你是不是快把向量庫當主交易庫了）​

如果你有以下需求，主庫應該用傳統 RDBMS：

  • 需要多步驟交易（跨多表/多步操作要回滾）
  • 需要強約束（唯一性、外鍵、嚴格資料完整性）
  • 需要準確查詢與可重現結果（稽核、對帳）
  • 需要成熟的備援、權限、審計、治理工具鏈
  • 高併發頻繁更新（尤其是狀態欄位一直變）
  • A — Atomicity（原子性）：交易中的操作要麼全部成功，要麼全部失敗並回滾，不會只完成一半。
  • C — Consistency（一致性）：交易前後資料都必須符合資料庫定義的規則/約束（例如外鍵、唯一性、檢查條件），不會把資料帶到不合法狀態。
  • I — Isolation（隔離性）：多個交易同時進行時，彼此不應互相干擾；效果要像是依序執行（細節依隔離等級而定）。
  • D — Durability（持久性）：交易一旦提交（commit）成功，即使斷電或當機，資料也不會丟失（通常靠 WAL/redo log 等機制）。

Footnotes​

  1. ACID 是描述資料庫交易（transaction）可靠性的四個特性縮寫： ↩