1.4 關系數據庫技術的局限性

傳統的關系數據庫技術假設數據具有很強的結構化特征。關系數據庫所存儲的數據特點可歸納為如下幾點：

1）結構統一。關系中的數據具有相同的結構（模式），具有很強的格式化特點。

2）面向記錄。在關系數據庫中，對于用戶而言，數據庫是一個記錄的集合，所有數據都是以記錄的形式存在的。

3）數據小。關系數據庫中的記錄一般都比較短。

4）原子屬性。關系數據庫中的每個屬性值都是無結構的，是不可分的原子值，滿足1NF定義。

隨著計算機技術的不斷發展，一些新的應用開始出現，例如GIS、多媒體、超媒體、CAD等。這些新型應用中的數據大都不具備傳統的數據特征，因此，使用傳統的關系數據庫技術來表達和存儲這些新型數據就遇到了困難。例如，在關系數據庫中如果要存儲一段視頻，現有的做法只能將視頻作為BLOB（大二進制對象）存儲在關系數據庫的某個字段中。但是，視頻上的一些操作，例如快進、后退、片段截取等，在SQL語言中難以得到支持。而且BLOB數據也無法使用傳統的SQL語言進行操作（Insert、Update等），必須借助其他方法才能實現。因此，雖然關系數據庫技術能夠支持新型復雜數據的存儲，但很難有效地支持對這些復雜數據的操作，更不用說支持其他的功能了，例如復雜數據的索引、查詢優化等。

另外，關系數據庫技術在數據表達方面也存在低效的問題。根據關系數據模型，現實世界中的實體對應著關系中的一個元組，但是1NF的要求容易導致關系中出現冗余數據。例如圖1-11所示的一個圖書關系的例子，由于1NF要求屬性值必須是不可分的原子值，因此出現了很多冗余的屬性值。

按照關系數據庫的規范化技術，可以將圖1-11所示的關系模式分解為三個關系模式，從而減少冗余，優化模式設計。規范化模式分解的結果如圖1-12所示。

模式分解結果雖然解決了冗余表達的問題，但仍然存在以下問題：

1）一本書在現實世界中是一個獨立對象，而在圖1-12所示的數據庫設計中被人為地分割成了幾個關系。也就是說，關系數據模型不得不通過多個實體集（關系）來表達現實世界中的一類實體（見圖1-13）。

2）不能表達作者之間的順序關系。

3）SQL可以執行分組操作，但只能返回單個的聚集函數值，不能返回一組結果。例如不能實現查詢所有作者及其所寫作的書列表。

關系數據庫技術的局限性還表現在缺乏對Web 2.0應用的有效支持方面。對于微博、微信等Web 2.0應用而言，關系數據庫的很多主要特性往往無用武之地，主要表現在：

（1）數據庫事務一致性需求

很多Web實時系統并不要求嚴格的數據庫事務，對讀一致性的要求很低，有些場合對寫一致性要求也不高。因此，數據庫事務管理成了數據庫高負載下一個沉重的負擔。

（2）無法滿足海量數據的管理需求

關系數據庫解決海量數據存取的主要手段是索引、緩存等技術，但在Web應用尤其是Web 2.0應用中，數據量往往以PB計算。面對如此海量的數據，關系數據庫系統的傳統優化技術往往難以取得理想的性能。目前一般的理解是，一個關系數據庫的基本表中的記錄數一般不能超過一千萬條，否則性能就很難保證，需要人工分庫分表。雖然MySQL等也提供了數據庫集群的支持，但是關系數據庫集群部署和配置復雜，主備之間備份和恢復不方便，動態擴容能力弱，而且動態數據遷移難以實現自動化。

（3）對復雜的SQL查詢，特別是多表關聯查詢的需求

任何大數據量的Web系統都非常忌諱多個大表的關聯查詢，以及復雜的數據分析類型的SQL報表查詢，特別是SNS類型的網站，從需求及產品設計角度，就避免了這種情況的產生。往往更多的只是單表的主鍵查詢，以及單表的簡單條件分頁查詢，SQL的功能被極大地弱化了。

（4）“One size fits all”模式很難適用于截然不同的業務場景

關系數據庫技術的核心思想是“統一”，即使用一個數據模型和一個數據庫統一存儲和管理所有的數據并且支持所有的應用。這種“One size fits all”的思路在互聯網時代很難適應快速發展的應用模式。例如，聯機數據分析（online analytical processing，OLAP）和聯機事務處理（online transaction processing，OLTP）這兩類應用一個強調高吞吐、一個強調低延時，已經演化出完全不同的架構，使用同一套模型來抽象顯然是不合適的。