NoSQL (Not only SQL)

一個資料庫在最基礎的層次上需要完成兩件事情：當你把資料交給資料庫時，它應當把資料儲存起來；而後當你向資料庫要資料時，它應當把資料返回給你。

如果要了解 SQL 為什麼重要，我們需要從 NoSQL (Not only SQL) 開始出發。NoSQL 其實是資料庫使用觀念的復古運動、正確觀念的復興運動。 也就是關聯式資料庫並不是唯一且最適的解法，要根據資料的使用特性，選擇適當的儲存機制，所謂的 NoSQL (Not only SQL)。

規模可伸縮性優先考慮是那些必須具備無限可伸縮性的應用，能夠不受限制的擴展比更豐富的功能更加重要。 這些應用包括很多需要高可伸縮性的網站，如 Facebook。 有些網站使用了關聯型資料庫系統，而有些並未採用之。 這些服務的共通性在於對規模可伸縮性的需求比功能更重要，他們無法將應用使用一個單一 RDBMS 解決。 因此，要怎麼處理資料仍然是要不要採用 NoSQL 資料庫的重點（傳統 row-based 的 RDBMS 也有叢集的解決方案， 只是擴張節點相對於某些類型 NoSQL 資料庫而言，比較沒有彈性，不過目前分散式的 RDBMS 解決方案已經出現並且已經有應用實例）， 而不是因為某個 NoSQL "awesome" 所以採用，使用了錯誤的資料模型在專案上將容易導致專案的失敗。

比較流行的 NoSQL 資料庫有下列的形式：

• Key/Value store: map (key, value)，是一種簡單的資料模型，適用的情況通常是作為 cache 使用。
• Document-store: The central concept of a document store is the notion of a "document". 目前比較常見的是 JSON 和 XML 文件。文件模式的資料庫在處理關聯性時反而比較弱， 因為文件應該是 self-contained 的，所以資料之間會有關聯性的情況下儘量不要考慮這個資料模型。
• Wide column store: For software developers, it can sometimes be helpful to think of them as a key-value collection where each value in the collection is either a simple data type or another key-value collection. For example: map (key, map (key, value))，與傳統的 RDBMS 資料庫（例如 PostgreSQL, CUBRID, MariaDB, MySQL）相比， 適用的範圍是需要良好的可伸縮性與大量資料範圍查詢時的情況。 另外，就是可能會有一個解決方案是使用 SQL 或者是類似的查詢語言來處理與管理 Wide column store 的資料。
• Graph: This kind of database is designed for data whose relations are well represented as a graph (elements interconnected with an undetermined number of relations between them)， 適用於多對多關係（例如社群網站）的情況。與其它模式相比，資料模式十分複雜。 但是注意，多對多關係也不一定只能使用 Graph 資料庫，例如臉書一開始是使用 MySQL 實作。
• Search Engines：搜尋引擎並不是資料庫，但是可以用來檢索資料並且作為資料庫的輔助工具。 有些搜尋引擎結合文件資料庫或者是 RDBMS 而成為一個完整的資料庫產品。

關聯式資料庫一般而言可以分為二個類型， OLTP (Online transaction processing) 與 OLAP (Online analytical processing)， 當然也有試著融合二者的 HTAP 資料庫，不過一般而言還是按照 OLTP 與 OLAP 來分類。 NoSQL 資料庫的使用情況也可以按照這二個類型來分類。

SQL 是為了存取或操作關聯式資料庫所設計的語言。SQL 的出現，解決了以往程式與資料庫相依性過高的問題， 透過 SQL 存取資料庫使得後端資料庫較容易更換（雖然有語法上的相容問題，還是比 NoSQL 資料庫之間的切換簡單）， 因此達成資料庫的獨立性，而前端的介面也可獨立使用不同的開發工具。如此將資料層分離出來，儲存到資料庫伺服器， 對於維護與安全都更有保障。

對我來說，過度強調 RDBMS 缺乏良好的可伸縮性是一種 FUD (Fear, Uncertainty, Doubt)， 如果一個 RDBMS 其儲存層是建立在分布式系統之上，而且使用 Raft 算法來解決一致性的問題， 那就你就有一個具有良好的可伸縮性的 RDBMS，例如 TiDB。 另外，有一些 SQL solution 使用了 NoSQL 資料庫作為存儲層（雖然有可能不支援或者是僅是有限度的支援 transaction， 不過也不是所有的關聯式資料庫都支援 transaction，一些 OLAP 類型的可能就不支援）， 例如 Apache Phoenix 就是建立在 Apache HBase 之上，在這個情況下使用者一樣可以使用 SQL 語言存取 NoSQL 資料庫。

並不是 NoSQL 資料庫就表示有良好的可伸縮性，至少以我所認知的各種資料庫來說， 一般而言為 Wide column store 具有良好的可伸縮性（也就是 Apache HBase 與 Apache Cassandra，以及其它類似技術的資料庫）， 其餘形式的資料庫大多數也都是使用傳統 RDBMS 橫向拓展的方法，在可伸縮性這點而言並未具有優勢明顯。 因此對比 RDBMS 來說，NoSQL 資料庫通常是為了解決一些特定的問題而使用，缺點就是程式與資料庫相依性過高（有可能造成被廠商綁定的問題）， 缺少一部份 RDBMS 提供的功能而需要自己再造一次輪子，以及安全性上的考量。大部份的情況下還是應該先考慮 RDBMS 是否可以適用。

最後一點，就是用 SQL 代稱某種類型的資料庫是不夠好的說法，畢竟 SQL 是一個查詢語言，因此不應該作為某種資料庫的代稱。 就我個人來說，SQL 這個查詢語言是個很好用的工具，而目前的發展也證明他是個歷久彌新的查詢語言。