先簡單定義： 「資料庫 Database」就是一般的概念，「網路資料庫 Networked / Online Database」是透過網路來存取的資料庫，「分散式資料庫 Distributed Database」則是把同一個邏輯資料庫拆成多個節點分散儲存與運算的系統。
其實「資料庫」跟「網路資料庫」不容易區分開來，只能說某些資料庫更適合使用在網路上，提供使用者同時存取，就能夠稱為「網路資料庫」。
也就是「資料庫 Database」本身只是資料儲存與管理的系統，而「網路資料庫 Networked / Online Database」通常指的是部署在伺服器上，讓多個使用者可以透過網路「同時」連線存取的資料庫。也就是說，多數常見的資料庫系統，只要配合網路與伺服器架構，就可以成為網路資料庫。
早期使用的 Microsoft Access 資料庫，大多都使用在單機上，但是其實他也可以透過網路同時連線存取，只是連線存取的效能不一定可以滿足需求。
我們來嚴謹的定義一下「資料庫」與「網路資料庫」:
「資料庫」定義 : 資料庫是依照某種資料模型 (data model) 與結構化規則 (structured rule)，持久化儲存的一組相關資料及其描述(中介資料/詮釋資料，metadata)，它的目標是支援一致性、一體化管理、共享、查詢與更新。
「網路資料庫」定義 : 網路資料庫是一種部署與存取型態，指透過網路(含區域網路或網際網路，Internet)提供多用戶/多應用程式連線存取的資料庫。 通常採Client-Server架構，使用特定通訊協定與驅動程式(例如 JDBC/ODBC 等)。
因此可以說「網路資料庫」並不是一種有別於「資料庫」的新資料模型或新類別，而是指可透過網路存取的資料庫：也就是利用特定的部署方式與系統架構，讓既有的資料庫能經由網路提供給多位使用者或多個應用程式進行並行存取。
簡單來說，「網路資料庫」本質上是存取/部署型態的描述，而非資料庫邏輯型態的分類。
那麼「分散式資料庫」又跟以上兩者有何差別呢 ?
「分散式資料庫」也不是一種全新的資料模型名詞，而是更偏向「架構與資料放置方式」的分類。
「分散式資料庫」定義 : 資料實體分布在多個機器/站台，由分散式資料庫管理系統 (DDBMS, Distributed DBMS) 協調；對使用者或應用程式而言，理想狀態是呈現單一資料庫的使用體驗(常稱「分散透明性」，distribution transparency)，也就是物理上分散、邏輯上統一。
也就是說使用者或應用程式在使用分散式資料庫的時候，是不會感覺到有什麼「分散」的狀態，分散式資料庫重點是資料實際放哪裡、怎麼協調，由系統去管理一致性、容錯、同步。
我們來結論一下，資料庫、分散式資料庫、網路資料庫差別是什麼?
可以用以下表格來說明 :
| 名詞 |
分類的主軸 |
關鍵特徵 |
| 資料庫 |
概念/本體 |
有組織、可管理的持久資料集合 |
| 網路資料庫 |
存取方式 |
透過網路提供多用戶並行存取 |
| 分散式資料庫 |
架構/資料位置 |
多節點存放、由 DDBMS 協調、對外像一個整體 |
資料庫 (Database) 例子 : MySQL、PostgreSQL、Oracle Database、Microsoft SQL Server、SQLite (偏嵌入式)、MariaDB、MongoDB (文件型資料庫，Document Database)、Redis (鍵值資料庫，Key-Value Database)等。
網路資料庫 (Network-accessible / Online Database) 例子 : 以上資料庫的例子，除了SQLite之外，都可以放在伺服器上，透過 TCP 讓多台電腦連線。
分散式資料庫 (Distributed Database) 例子 : Google Spanner、CockroachDB、YugabyteDB、TiDB、Apache Cassandra、Amazon DynamoDB、HBase、ScyllaDB。
結論
資料庫 (Database)： 一套有組織、可管理、可長期保存的資料集合與管理機制。重點在「資料本體與管理能力」，不限定放在哪裡、用什麼方式被存取。
分散式資料庫 (Distributed Database)： 一種資料分散存放在多個節點，且由分散式資料庫管理系統 (DDBMS) 進行跨節點協調的架構。對使用者或應用程式來說，看起來像同一個整體資料庫。 重點在「天生就是多節點」以及「需要協調一致性、交易、查詢」。
網路資料庫 (Network Database / Web-Accessible Database)： 指可透過網路提供存取的資料庫部署/使用方式。 重點在「存取方式」，不是資料庫的內在架構。 所以它會和一般資料庫高度重疊，也可以包含分散式資料庫。
[後記]
大家經常會有的問題 : MySQL或是PostgreSQL可以達到分散式資料庫的效果嗎?
這個問題可以分成兩個 :
(1)使用傳統的MySQL或是PostgreSQL可以透過規劃，達到分散式資料庫的效果嗎?
(2)要讓MySQL或是PostgreSQL達到分散式資料庫的效果，有成熟的解決方案嗎?
第一個問題會發生在使用傳統的MySQL或是PostgreSQL很久了，但是碰到成效或是擴張的問題，想透過規劃讓MySQL或是PostgreSQL具有分散式資料庫的效果。
例如網路選課使用傳統的MySQL，原本選課規則是登記制，沒有先來後到的問題，然後登記結束後，由後台按照規則篩選。
後來選課規則改成搶課，這樣一來原本的資料庫就會因為瞬間流量衝進來而癱瘓。因此就必須把傳統的MySQL更改一下，來符合新的選課規則。
通常網路選課只會使用一個DB資料庫，頂多使用負載平衡兩三台AP伺服器，如果碰到瞬間流量暴衝，加再多台AP伺服器都沒用，因為瓶頸會在DB資料庫。如果把DB資料庫也變成多個，就會碰到資料如何彙整同步的問題。
但是並不是無解。
搶課規則可以變成有先來後到的登記制，登入使用的DB可以隨著多台負載平衡的AP伺服器而增加 (這樣就不會因為瞬間流量而癱瘓)，然後搶課是搶到一個帶有課號的時間標記，例如某同學在 2025-12-10 08:30:20:00 搶到課號0001的登記票，另外的同學在 2025-12-10 08:29:20:00 搶到課號0001的登記票，這些資料就存在多台伺服器上。
然後系統的程式每固定時間 (例如每十秒) 去收集這些登記票，依照課號排序，在未到達修課人數上限時，該登記票就成功選課，已經超過人數上限時，該登記票就變成候補，等待有人刪除選課再進行排序。
以上只是把傳統的MySQL或是PostgreSQL，用規劃的方式來達成類似分散式資料庫的效果，當然答案不會只有一個，還可以使用更多不同的規劃方式來做。
那麼MySQL或是PostgreSQL有沒有分散式資料庫的正式解決方案呢?
MySQL NDB Cluster 本身就定位為分散式資料庫，具有自動分割/多節點寫入等特性。
Citus 是知名的 PostgreSQL 分散式擴充，能把 Postgres 變成分片、分散、可水平擴展的架構。
(1)需要支撐不可預測的交易尖峰。
(2)透過叢集架構加速商家端大量資料彙整與資料移轉/同步。
(3)也規劃異地 active-active (雙主動叢集) 與災難復原。
更多應用後續再來討論了。
0 留言