Document-Store on Tarragonhttps://tarrragon.github.io/blog/tags/document-store/Recent content in Document-Store on TarragonHugo -- gohugo.iozh-TWTarragon (CC BY 4.0)Fri, 22 May 2026 00:00:00 +0000MySQL Document Store / X Protocolhttps://tarrragon.github.io/blog/backend/01-database/vendors/mysql/document-store-x-protocol/Fri, 22 May 2026 00:00:00 +0000https://tarrragon.github.io/blog/backend/01-database/vendors/mysql/document-store-x-protocol/<p>MySQL Document Store / X Protocol 的核心責任是說明 MySQL 如何在 relational engine 內提供 JSON document workflow。<a href="https://tarrragon.github.io/blog/backend/knowledge-cards/document-store/" data-link-title="Document Store" data-link-desc="說明以 JSON 文件與彈性 schema 提供資料存取的模式，以及它仍需的治理邊界">Document Store</a> 讓 application 透過 X Protocol 與 CRUD API 操作 collection，但資料仍落在 MySQL 的 storage、transaction、backup 與 permission 模型裡。</p> <p>本文的判讀錨點是：Document Store 是 MySQL 內的 document access pattern，而非 MongoDB 等專用 document database 的完整替代。它適合 relational schema 旁邊的 flexible JSON，但不適合把主要資料模型都藏進無治理 JSON。</p> <p>官方文件路由的核心責任是固定 X Protocol claim。實作前先查 <a href="https://dev.mysql.com/doc/refman/en/document-store.html">MySQL 8.4 Document Store</a>；本文最後檢查日是 2026-05-22。</p> <h2 id="responsibility-boundary">Responsibility Boundary</h2> <p>Responsibility boundary 的核心責任是把 Document Store 和 SQL table 關係說清楚。</p> <table> <thead> <tr> <th>面向</th> <th>Document Store</th> <th>SQL table / JSON column</th> </tr> </thead> <tbody> <tr> <td>Access API</td> <td>X Protocol、CRUD-style API</td> <td>SQL、JSON function</td> </tr> <tr> <td>Storage</td> <td>MySQL InnoDB</td> <td>MySQL InnoDB</td> </tr> <tr> <td>Transaction</td> <td>MySQL transaction</td> <td>MySQL transaction</td> </tr> <tr> <td>Governance</td> <td>仍需 backup、role、audit、migration</td> <td>仍需 schema / index review</td> </tr> <tr> <td>Query power</td> <td>document-friendly access</td> <td>SQL join、index、optimizer</td> </tr> </tbody> </table> <p>Document Store 的價值是降低 flexible object 的開發摩擦。它不免除資料合約、index、migration、backup 與 audit 的責任。</p> <h2 id="suitable-use-cases">Suitable Use Cases</h2> <p>Suitable use cases 的核心責任是找出 document pattern 的合理位置。</p> <table> <thead> <tr> <th>情境</th> <th>適合原因</th> </tr> </thead> <tbody> <tr> <td>Profile / preference</td> <td>欄位變動快、查詢條件少</td> </tr> <tr> <td>Integration payload</td> <td>需要保存外部 JSON 原文</td> </tr> <tr> <td>Feature flag / config</td> <td>讀多寫少、schema 變化頻繁</td> </tr> <tr> <td>Hybrid relational + JSON</td> <td>主體 relational，局部 flexible</td> </tr> <tr> <td>Prototype</td> <td>先探索欄位，再逐步 relationalize</td> </tr> </tbody> </table> <p>Document Store 最適合局部 flexible data。若核心 query 需要大量 join、aggregation、transaction invariant，應把穩定欄位拉回 relational schema。</p> <h2 id="query-and-index">Query and Index</h2> <p>Query and index 的核心責任是避免 JSON 查詢變成不可觀測黑箱。</p> <table> <thead> <tr> <th>問題</th> <th>審查方向</th> </tr> </thead> <tbody> <tr> <td>常用 filter</td> <td>是否需要 generated column / functional index</td> </tr> <tr> <td>Sort / pagination</td> <td>是否能走 index</td> </tr> <tr> <td>Schema drift</td> <td>document version / validation</td> </tr> <tr> <td>Large document</td> <td>update amplification、network payload</td> </tr> <tr> <td>Analytics</td> <td>是否應 ETL 到 OLAP / warehouse</td> </tr> </tbody> </table> <p>MySQL JSON 查詢可以從 generated column 建 index。正式服務要把常用 JSON path 寫進 query contract，避免每次都掃完整 document。</p>MySQL Document Store / X Protocol 的核心責任是說明 MySQL 如何在 relational engine 內提供 JSON document workflow。Document Store 讓 application 透過 X Protocol 與 CRUD API 操作 collection，但資料仍落在 MySQL 的 storage、transaction、backup 與 permission 模型裡。

本文的判讀錨點是：Document Store 是 MySQL 內的 document access pattern，而非 MongoDB 等專用 document database 的完整替代。它適合 relational schema 旁邊的 flexible JSON，但不適合把主要資料模型都藏進無治理 JSON。

官方文件路由的核心責任是固定 X Protocol claim。實作前先查 MySQL 8.4 Document Store；本文最後檢查日是 2026-05-22。

Responsibility Boundary

Responsibility boundary 的核心責任是把 Document Store 和 SQL table 關係說清楚。

面向 Document Store SQL table / JSON column
Access API X Protocol、CRUD-style API SQL、JSON function
Storage MySQL InnoDB MySQL InnoDB
Transaction MySQL transaction MySQL transaction
Governance 仍需 backup、role、audit、migration 仍需 schema / index review
Query power document-friendly access SQL join、index、optimizer

Document Store 的價值是降低 flexible object 的開發摩擦。它不免除資料合約、index、migration、backup 與 audit 的責任。

Suitable Use Cases

Suitable use cases 的核心責任是找出 document pattern 的合理位置。

情境 適合原因
Profile / preference 欄位變動快、查詢條件少
Integration payload 需要保存外部 JSON 原文
Feature flag / config 讀多寫少、schema 變化頻繁
Hybrid relational + JSON 主體 relational，局部 flexible
Prototype 先探索欄位，再逐步 relationalize

Document Store 最適合局部 flexible data。若核心 query 需要大量 join、aggregation、transaction invariant，應把穩定欄位拉回 relational schema。

Query and Index

Query and index 的核心責任是避免 JSON 查詢變成不可觀測黑箱。

問題 審查方向
常用 filter 是否需要 generated column / functional index
Sort / pagination 是否能走 index
Schema drift document version / validation
Large document update amplification、network payload
Analytics 是否應 ETL 到 OLAP / warehouse

MySQL JSON 查詢可以從 generated column 建 index。正式服務要把常用 JSON path 寫進 query contract，避免每次都掃完整 document。

Migration Boundary

Migration boundary 的核心責任是讓 document data 可演進。Document 欄位雖然 flexible，但 application 仍會依賴某些 key；這些 key 一旦進入 workflow，就要有版本與 validation。

最小治理：

  1. Document version field。
  2. Required key validation at application boundary。
  3. Backfill script for new required key。
  4. Index review for promoted key。
  5. Export / backup restore validation。

當 JSON key 變成 join key、permission key 或 reporting key，應評估搬到 relational column。

No-Go Conditions

No-go conditions 的核心責任是指出 Document Store 的邊界。

訊號 建議路由
主要資料都是 nested document MongoDB / document database evaluation
大量 document aggregation OLAP / search / document-oriented engine
JSON path 已成核心 index relationalize key 或 generated column
需要跨 document complex join relational schema
需要 schema governance migration + validation

Document Store 要服務於 flexible edge，而非取代資料建模。當 flexible area 穩定下來，就把它納入 schema governance。

下一步路由

Document Store / X Protocol 完成後，JSON 與 SQL 能力讀 Modern SQL Features；若主要資料模型是 document，讀 MongoDB；migration 到 PostgreSQL JSONB 可讀 MySQL to PostgreSQL。

]]>