NoSQL技術的示例分析

這篇文章主要介紹了NoSQL技術的示例分析，具有一定借鑒價值，感興趣的朋友可以參考下，希望大家閱讀完這篇文章之后大有收獲，下面讓小編帶著大家一起了解一下。

關系型數據庫幾乎是許多開發者和DBA對于傳統三層架構應用的唯一選擇。使用這一場景有很多原因，數據建模方法，查詢語言與數據交互，保證數據的一致性部署，并能夠為復雜的應用服務。 

然而，這不是解決所有數據存儲問題的唯一方案，也是NoSQL 產生的原因。NoSQL 提供了新的方法而不是采用面向標準SQL的范式。 

NoSQL 技術與高伸縮性無縫融合，很多技術同時具備了高分布性和高性能,是大數據分析的存儲基石。大多數時間里，它們使 現有RDBMS 技術所實現的架構更加完整，例如 作為緩存服務器，搜索引擎，非結構化存儲，易變信息存儲等。主要分為4類：

1. Key/value

2. 列存儲

3. 面向文檔的存儲

4. 圖存儲

現在深入到各種技術，選擇最適用于使用場景的技術。

Key/Value

第一個也是最早的 NoSQL 數據存儲就是key/value. 這些數據就像字典一樣根據key來匹配value，通常使用在需要高性能的基本信息存儲，例如需要快速讀寫的session信息，這些存儲在這樣的情景非常高效，也通常具有高伸縮性。

Key/value也經常被用于上下文的隊列化來保證數據不丟失，例如日志架構或搜索引擎的索引架構。Redis 和Riak KV 是非常有名的key/value數據存儲； Redis 使用的更加廣泛，因為它有著一個內存型 K/V 存儲，并且持久化是可選的。Redis 經常用于web應用中來存儲session相關的數據，例如node或者- 
PHP的 web應用 ; 每秒鐘可以提取成千上萬的session信息而沒有性能損失。另一個典型場景是后面要講到的序列化：Redis位于 Logstash 和 ElasticSearch 之間來存儲t ElasticSearch 查詢中的索引。

Column

由于要存儲超大量的記錄信息 到達了key/value存儲限制的時候就需要用到列存儲。列存儲技術對于RDBMS世界的工程師可能不太容易理解，但事實上非常簡單。RDBMS 中數據是按行存儲的，而列存儲中是按列的。使用列數據庫的主要好處是能高速訪問海量數據。 RDBMS的一行在硬盤上是一個連續的存儲，多行可能存儲在硬盤不同的位置，使訪問稍顯復雜，在列數據庫中的一列數據是連續存儲的。

舉個例子，考慮在RDBMS中查詢索引博客的標題，尤其是有數百萬數據的時候，需要大量的IO操作，而在列數據庫中，這樣的查詢只是一次訪問。這樣的數據庫在從特定簇提取海量數據中非常順手，但此消彼長的是缺乏靈活性。使用最多的列存儲數據庫是 
Google Cloud Bigtable, 但開源的列存儲數據庫是Apache HBase 和Cassandra. 
列存儲數據庫的另一個好處是容易伸縮，這些列在海量存儲時具有高伸縮性。這就是為什么它們主要用于保存非易變且長久保留信息的原因。

Document

列存儲數據庫對于含有比較深嵌套結構的結構化數據的存儲不是最好的，這種場景需要使用面向文檔的數據存儲。數據實際上以key/value 存儲,但是所有壓縮的數據叫做文檔。 文檔依賴于一個結構或者編碼例如XML, 但更多時候是 JSON (JavaScript Object Notation).

盡管文檔型數據庫對于數據的結構化存儲和表達都非常有用，但也有其脆弱的一面，特別是與數據的交互性操作。它們基本上要遍歷整個文檔，例如當讀取某個特定字段的時候，遍歷可能會影響性能。

當需要存儲嵌套信息的時候，可以采用文檔型數據庫。例如，考慮怎樣表達應用中的一個賬戶，大概有以下信息：

• 基礎信息:姓名，生日，照片 ，URL, 創建日期等等

• 復雜信息: 地址，認證方法(password, Facebook, 等第三方認證),興趣等等。

這也是NoSQL 文檔型數據庫經常用到web應用的原因: 表達嵌套對象非常容易，由于都使用JSON，還可以與前端的JavaScript技術無縫集成。

使用最多的文檔型數據庫是MongoDB, Couchbase, 和 Apache CouchDB，都非常容易安裝和啟動，有很好的文檔說明，而且都是可伸縮的，除此之外，它們也是開放現代web應用的明確選擇。

Graph

Graph 數據庫與其它數據庫有著本質的區別。它使用了不同的范式來表達數據——樹結構，節點和邊連接起來叫做關系。這些數據庫是隨著社交網絡而誕生的，例如表達用戶的好友網絡，他們的好友關系等等。對于其它類型的數據存儲，可能把一個用戶的好友關系存儲在一個文檔中，但是，存儲好友關系還依然非常復雜；使用圖數據庫就非常簡單，為每個好友創建節點，通過關系連接他們，依賴查詢的需要和范圍瀏覽圖。

最著名的圖數據庫是Neo4j, 象前面所說的，主要使用場景是處理復雜的關系信息，例如實體間的連接，也可以用于分類的場景。 
Figure 2-1 展示了在圖數據庫中3個實體是如何連接的。

圖中的兩天賬戶節點Jane 和 John, 它們之間的每一條邊定義了他們的關系，在某天相互認識，另一組節點連接的兩個賬戶展示了Jane 和 Joh在某天后都成為了足球組的成員。

使用場景中的NoSQL

根據使用場景，首先需要一個文檔型的 NoSQL數據庫，將存儲在關系型數據庫中的數據結構化的一個 JSON 文檔. 如前所述，傳統的RDBMSs 將數據存儲到多個有關系的表，當得到一個完整對象時變得比較復雜和低效。在Figure 2-2. 中可以看到一個賬戶被分割成多個表的例子。

如果要獲得所有的賬戶信息，基本上需要join兩到三個表。現在考慮這樣的情形: 需要處理所有用戶在應用中的每一次連接，這些連接有著不同的商業邏輯。 最后,想要賬戶自身的視圖。通過傳遞一個賬戶標識通過API從全部用戶視圖中得到一個怎樣的文檔呢？

{
    "id": "account_identifier",
    "email": "account@email.com",
    "firstname": "account_firstname",
    "lastname": "account_lastname",
    "birthdate": "account_birthdate",
    "authentication": [{
        "token": "authentication_token_1",
        "source": "authenticaton_source_1",
        "created": "16-12-12"

    }, {

        "token": "authentication_token_2",
        "source": "authenticaton_source_2",
        "created": "16-12-12"

    }],
    "address": [{
        "street": "address_street_1",
        "city": "address_city_1"
        "zip": "address_zip_1"
        "country": "address_country_1"
        "created": "16-12-12"
    }]}
  
  
  

好處顯而易見: 通過保持一個實體的 JSON 表達,可以更快更好的訪問數據。進一步，將這一方法通用化，從NoSQL數據庫讀取所有的讀操作，而讓所有的寫操作 (create, update,delete) 還在RDBMS上 .但必須實現一個邏輯來維持 RDBMS到NoSQL 的數據同步，如果沒在緩存中的話還要創建一個關系型數據庫的對象。

在NoSQL高效可伸縮地創建文檔時為什么還要保持 RDBMS呢？因為這不是應用的真正目的。我不想產生一個Big Bang 的影響. 假設RDBMS已經準備好了，但因為RDBMS缺乏靈活性而集成了一個NoSQL存儲。希望充分利用兩個最好的技術 —— 特別是RDBMS的數據一致性和NoSQL的伸縮性 。

感謝你能夠認真閱讀完這篇文章，希望小編分享的“NoSQL技術的示例分析”這篇文章對大家有幫助，同時也希望大家多多支持億速云，關注億速云行業資訊頻道，更多相關知識等著你來學習!