后SQL時代，DBA們不用查詢語句用什么？
原創(chuàng)【51CTO外電頭條】今天對于傳統(tǒng)的數據庫解決方案，我們面臨著很多有關擴展性的問題，而 NoSQL 運動將這些問題的根源歸罪于 SQL 查詢語言。
我認為，如此多的人將 SQL 視為“萬惡之源”的主要原因在于這樣一個事實：查詢語言通常被緊密地融入了數據庫的部署之中。因此，當提到“NoSQL”時，我們本質上是在對非擴展的傳統(tǒng) RDBMS 部署說“不”（No）。
對于查詢語言大量的替代方案，這一說法也是適用的。這些替代語言中的每一個都致力于解決傳統(tǒng) SQL 查詢方案所欠缺的某一個方面，比如文檔模型，或者提供一種更為簡潔的方案，如鍵/值（Key/Value）程序。
曾與我交談過的大多數人對于這個話題都相當困惑，并且往往交替地使用查詢語言和結構。所以，我想通過本文拋磚引玉，希望能夠為 NoSQL 環(huán)境中每個查詢術語所表示的含義提供一個簡單快捷的概述。之后，我還會試圖通過講解來消除某些常見的誤解。
后 SQL 世界中常用的查詢語法
以下為 NoSQL 語境中一些常用的查詢語法。
鍵/值查詢：正如字面含義，鍵/值查詢應該是最為基本的查詢格式。每個數據項關聯一個唯一的標識符（鍵）。在 NoSQL 語境中，memcache 是這種接口最常用的部署方式之一。使用 memcache 執(zhí)行一個復雜的查詢時，最為常見的模式是將查詢延遲至用作搜索引擎的底層數據庫。這些查詢的結果是一個鍵或一組鍵，然后利用這些鍵通過 memecache 數據存儲來執(zhí)行相應的值提取。這種方式在后 SQL 語境中獲得了新的發(fā)展動力，原因在于它們自身能夠相當自然地與分區(qū)和分發(fā)概念相融合，而分區(qū)和分發(fā)正是使得數據存儲具有可擴展性的關鍵所在。換句話說，當人們別無選擇時，他們愿意用大多數傳統(tǒng) RDBMS 所提供的強大的查詢概念來交換可擴展性，即使只提供基本的查詢支持。
基于文檔的查詢：文檔查詢這種模型的主要用途在于搜索引擎，在這中環(huán)境中最常見的是存儲不同類型的溫度，即使每個文檔代表的是截然不同的對象。在 NoSQL 環(huán)境中，文檔并不是我們在搜索引擎中見到的那種典型的 Word 或 PowerPoint 文件，而是 Jason 或 XML 形式的對象，或者關聯一組鍵/值的二進制對象，比如 Cassandra。使用 SQL 術語來描述，文檔可視為一個 blob（一種數據類型），關聯著一組鍵，每一個鍵獨立地進行索引并且維持著至該 blob 的引用。每個 blob 可以是不同的類型（表），每個 blob 可以具有不同的關聯索引組（鍵）。通過關聯索引來完成匹配工作。結果組通常包含多種類型，每個又包含不同的數據組。由于索引和 blob 無需與行和表的嚴格結構保持一致，所以將其稱為“非結構的”（schemaless），也就是說，它可以具有同一類型的不同版本，并且向新的表中添加字段時無需修改任何表而且無需更新數據的舊版本。支持這種文檔模型的數據庫有 CouchDB 和 MongoDB。
模板查詢：模板查詢在 JavaSpaces 和 Hibernate 較新的版本中常常用到。利用基于模板的匹配，你可以根據類類型或遺傳等級抓取一個對象，以及該對象的屬性值。對于更為面向對象的模板匹配，你還可以根據圖標（graph）屬性中的特定項來執(zhí)行匹配任務。在支持 JavaSpaces 模板查詢模型的解決方案中，GigaSpaces 是較為知名的實現方式之一。
映射/化簡（Map/Reduce）：映射/化簡通常用于執(zhí)行分布式數據存儲上的聚集查詢。一個簡單的例子，比如 Max 或 Sum。對于這種情況，查詢全球需要在每個分區(qū)（映射）中獨立的執(zhí)行，然后進行聚集后返回客戶端（化簡）。隱式的映射/化簡可以進行某個查詢請求并隱式地傳播該查詢的執(zhí)行?？蛻舳双@取聚集查詢，就像它是一個單一查詢。顯式的模型運行用戶執(zhí)行自由格式（free-form）的代碼，你可以控制映射模型（哪個調用指向哪些數據）、每個節(jié)點（即任務）中運行的代碼以及結果。在一個常規(guī)的 Hadoop 部署中，映射/化簡常常通過顯式某些來進行。類似 Hive 和 Pig 的框架提供給了一個概要模型，可以隱式地處理進程。
SQL 查詢：讓我們思考一下，SQL 也算是另一種形式的動態(tài)語言，專門用于復雜的數據管理。使用 SQL，通?？稍诒砗托兄袑祿M行排序。SQL 中的某些查詢語法，比如 Join、分布式事務，以及為了獲得擴展性而較常用的反模式語法。大體上來講，正是 SQL 語法的這一點將 SQL 與有限的可擴展性關聯起來了。支持 SQL 的 NoSQL 實現有使用 JPA 的 Google Bigtable、Hive/Hadoop、MongoDB 和 GigaSpaces。有關具體含義我將在下文進一步詳述。
YeSQL：問題與 SQL 無關！
上文已經講述了查詢格式背后的某些概念，某個結論現在更為明朗了——過錯的確與 SQL 無關。與許多語言一樣，SQL 為你提供的是一根足夠長的繩子，如果你喜歡，甚至可以那它來做懸梁自盡之用。幾乎每種語言都是如此。如果想要將數據模型設計為與分布式模型相匹配，你會看到 SQL 在管理數據方面具有非常強大的功能。比如 Hive/Pig/Hbase 和谷歌的 JPA/Bigtable 就是很好的例子。對于這兩種情況，底層的數據存儲是基于可擴展的鍵/值存儲，但前端查詢語言剛好是基于 SQL 的。MongoDB 瞄準的也是類似的目標，主要的區(qū)別在于，這種數據庫提供類似 SQL 的支持但并不完全遵守任何現有的標準。
請注意：事關架構！
諸如 Hive/HBase 以及 JPA/Bigtable 之類的 NoSQL 實現，可以視為很好的示例：下一代數據庫如何同時支持線性擴展和 SQL API 接口。
關鍵之處在于將查詢語法與底層數據存儲剝離開來，如下圖所示：
谷歌的 Bigtable 在 NoSQL 數據存儲只是提供對 SQL API 的支持
融合正在發(fā)生
上周作者參加了 Hadoop summit 會議。Hadoop 提供的環(huán)境類似一個非常通用的培養(yǎng)基，這將為其帶來一個生機勃勃的微生物系統(tǒng)。今天已經存在許多新的框架，它們在查詢和處理方面對 Hadoop 數據管理方式進行了不同等級的萃取，比如 Hive、Cascading 和 Pig。許多框架提供的工具已經遠遠超出了 Hadoop 創(chuàng)建者最初的設想。
這讓我想到一點：我們可以利用上文提到的分離模式，從而在與 SQl 的連接中提供對穩(wěn)定模型的支持。也可以這樣表述，我認為大多數數據庫中領先者將支持所有上述語法，并且用戶將不用只是因為某個數據庫實現支持某種查詢語言而選擇它。
我們已經在動態(tài)語言上看到類似的趨勢。以前，一門語言必須提供完整的工具、編譯器、庫和支持該語言的開發(fā)工具，這讓選擇某種語言成為一種重要的戰(zhàn)略。而今天，Java 中的 JVM 或 .Net 中的 CLR 提供了相同的環(huán)境，能夠支持更多的同一 JVM 運行時之上的動態(tài)語言。類似的例子，比如：Groovy 和 Java 或 Jruby。
***的話
在本文中我一直在講，SQL 事實上是一個相當不錯的查詢語言并且將繼續(xù)在后 SQL 世界中發(fā)揮重大的作用。不過，一家通吃的情況不會繼續(xù)下去。數據管理的世界將建立在多種工具盒數據管理語言之上，每種語言或工具提供將某種特定的功能或服務。最為理想的情況，無論數據存儲方式如何，我們應能夠使用任何查詢語言來訪問任何數據。例如，我應能夠使用文檔模型來存儲 JSON 對象，而且，無論任何時候，我都應能夠使用 SQL 查詢語法或簡單的鍵/值 API 來查詢這個 JSON 對象。
原文標題：YeSQL: An Overview of the Various Query Semantics in the Post Onl
【編輯推薦】
