大約在2009年創造出來的NoSQL名字標志著從“傳統”關系模型的轉變。 在2009年之前，有相當多的非關系數據庫，但是在最近幾年中，我們看到了許多新產品（例如， 我在上一篇文章中可以看到“ NoSQL格局” ）。 一般而言，這里的一切都是瘋狂的概括，因為并非所有解決方案都是平等創建的，并且存在多種類型的解決方案-NoSQL解決方案主要意味著放寬了ACID約束，并且顧名思義，刪除了“結構化查詢”語言（SQL）既作為數據定義語言，更重要的是作為數據操作語言，尤其是SQL的查詢功能。

ACID和SQL損失很多，而NoSQL解決方案主要提供一些好處：

• 可伸縮性–作為相對可伸縮性，意味著在相同的規模上，其規模要比同類RDBMS便宜； 或絕對–在規模上比RDBMS更好。 可伸縮性通常是通過在Eric Brewer的CAP定理中偏重分區容忍性而不是一致性并依靠“最終一致性”來實現的（稍后會詳細介紹）
• 更簡單的模型-即將編程結構映射到存儲結構是直接的，因此避免了整個“對象/關系映射的泥潭”（或被Ted Neward稱為“ 計算機科學的越南” ）。 我不得不說，根據我的經驗，這僅是一個事實，因為它只適用于一點，當您需要擴展和/或具有高性能要求時，您需要仔細設計架構，但它并不總是“簡單” ”。
• 后期綁定模式–這是真正的靈活性，因為您可以將數據存儲在與原始表單接近的表單中，并在讀取時應用這些模式，因此您可以交付多結構數據并輕松處理半結構化數據。

最終的一致性和簡單的查詢機制可以在一段時間和某些用例中起作用，但是隨著NoSQL解決方案的采用變得越來越普遍，我們可以看到市場需要更多。

最終一致性

最終的一致性意味著，如果新讀取在一段時間后停止流入，則所有讀取將返回最后的更新值-由于新更新很少停止，并且“一段時間后”的定義不明確-這是一個相當微弱的保證，我們將付出一些努力做出更強有力的保證。 彼得·貝利斯（Peter Bailis）和阿里·戈德西（Ali Ghodsi）發表了一篇很好的論文，名為“ 今天的最終一致性：局限性，擴展性和超越性 ”，他們在其中討論了一些選項。 NoSQL領域太寬泛，無法說到處都是這種情況，但是有些解決方案朝這個方向發展，例如，在HBase（我過去幾年中使用最多的NoSQL）中，我們看到了“多版本” “并發控制” ，它為單行操作提供ACID保證 （可以調低性能）

但是，在真實條件下提供真實保證可能會非常棘手。 我強烈建議閱讀Jepsen上的Kyle Kingsbury系列精彩文章 ，他將探討Postgres，MongoDB，Redis和Riak如何處理網絡分區下的寫入。

查詢

當我們看NoSQL空間時，我們發現很多技術都變得更好，更高級的查詢語言，例如mongoDB找到了一些不錯的功能 ； cassandra的查詢語言是第三版，但是Hadoop是Hadoop的一種技術，該技術在一般情況下引入查詢，特別是SQL，這已成為踩踏的一種趨勢。 Hadoop具有一個多供應商，多發行版的生態系統（與Linux不同），似乎每個人都想引入自己SQL解決方案：Cloudera提供了Impala ，Hortonworks正在進行Stinger計劃，以增強Hive，Pivotal（nee EMC） greenplum）有Hawq ，IBM正在開發BigSQL ，甚至SalesForce.com（不提供發行版）也為HBase提供了一個名為PhoenixSQL皮膚。 上屆Hadoop峰會 設有一個小組 ，其中一些參與者討論了各自平臺的優點，值得一聽。

我上面給出的示例主要是關于hadoop的-自然，因為這是我一直在使用的環境，因此我對此更加熟悉，但是更重要的是，似乎Hadoop已成功地將自己定位為主要的NoSQL（大規模） （又名大數據）解決方案，因此這種reSQL趨勢在該處更加明顯，它將（并且確實）也影響其他NoSQL產品。

事實是NoSQL為了簡化而放棄了SQL功能-廣泛采用會降低所有功能和復雜性，我想主要的問題是，當我們還要處理大數據及其含義（例如后期綁定）時，情況甚至更加復雜。模式與（結構化）查詢語言的模式需求；固定或難以移動的數據與聯接等）

參考： ReSQL？ 從我們的JCG合作伙伴 Arnon Rotem Gal Oz在Cirrus Minor博客上獲得。

翻譯自: https://www.javacodegeeks.com/2013/07/resql.html

創作挑戰賽新人創作獎勵來咯，堅持創作打卡瓜分現金大獎

總結

以上是生活随笔為你收集整理的ReSQL的？的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。