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