溫馨提示×

溫馨提示×

您好,登錄后才能下訂單哦!

密碼登錄×
登錄注冊×
其他方式登錄
點擊 登錄注冊 即表示同意《億速云用戶服務條款》

用NOSql給高并發(fā)系統(tǒng)加速是一種多厲害的技術

發(fā)布時間:2020-04-22 11:55:16 來源:億速云 閱讀:168 作者:三月 欄目:編程語言

下文內(nèi)容主要給大家?guī)碛?a title="NOSql" target="_blank" href="http://kemok4.com/mongodb">NOSql給高并發(fā)系統(tǒng)加速是一種多厲害的技術,所講到的知識,與書籍不同,都是億速云專業(yè)技術人員在與用戶接觸過程中,總結出來的,具有一定的經(jīng)驗分享價值,希望給廣大讀者帶來幫助。

隨著互聯(lián)網(wǎng)大潮的到來,越來越多網(wǎng)站,應用系統(tǒng)需要海量數(shù)據(jù)的支撐,高并發(fā)、低延遲、高可用、高擴展等要求在傳統(tǒng)的關系型數(shù)據(jù)庫中已經(jīng)得不到滿足,或者說關系型數(shù)據(jù)庫應對這些需求已經(jīng)顯得力不從心了。關系型數(shù)據(jù)庫經(jīng)過幾十年的發(fā)展已經(jīng)很成熟,強大的sql語句支持,完美的ACID屬性的支持,使得關系型數(shù)據(jù)庫廣泛應用于各種各樣的應用系統(tǒng)中,但是應用的場景廣泛并非意味著完美。

- 由于關系型數(shù)據(jù)庫是按行進行存儲的,在某些只統(tǒng)計一列的需求場景下,也需要把整行讀入內(nèi)存,導致了一個小小的統(tǒng)計需求高IO的缺點

- 關系型數(shù)據(jù)庫無法存儲數(shù)據(jù)結構,比如:一個商品可以從屬于多個分類,業(yè)務上的從屬關系體現(xiàn)到存儲上是一個列表而已,但是關系型數(shù)據(jù)庫需要把這些關系存儲為多行,無法直接存儲為一個列表。

- 關系型數(shù)據(jù)庫中的存儲單位表的架構是強約束,操作不存在的列會報出異常,而且添加、更新、刪除列必須執(zhí)行DDL語句,如果表的現(xiàn)存數(shù)據(jù)量比較大,會出現(xiàn)長時間鎖表的現(xiàn)象。

- 關系型數(shù)據(jù)庫全文搜索功能普通比較弱,用like去匹配關鍵詞的時候,數(shù)據(jù)量比較大的情況下會出現(xiàn)慢查詢的現(xiàn)象。

- 關系型數(shù)據(jù)庫基于表格的關系模型使得很難添加新的或不同種類的關聯(lián)信息。

由于以上這些諸多問題,便誕生了以“NOSQL”為口號的很多解決方案。在某些關系型數(shù)據(jù)庫不擅長的領域,Nosql表現(xiàn)的很出色。上天是公平的,給你打開了一扇窗戶,必會給你關上半扇門,NoSql是以犧牲ACID某個或者某些特性為代價的。

NoSQL并不是銀彈,更多的時候是關系型數(shù)據(jù)庫一個有力補充,或者是特定場景下優(yōu)于關系型數(shù)據(jù)庫的一種解決方案

NoSQL

NoSQL,泛指非關系型的數(shù)據(jù)庫?,F(xiàn)在大家更喜歡翻譯成:not only sql

用NOSql給高并發(fā)系統(tǒng)加速是一種多厲害的技術

根據(jù)NoSQL的存儲等特性,大體可以分為以下幾類

- 鍵值(Key-Value)存儲數(shù)據(jù)庫。相關的產(chǎn)品:Redis、Riak、SimpleDB、Chordless、Scalaris、Memcached。主要解決關系數(shù)據(jù)庫無法存儲數(shù)據(jù)結構的問題。

- 列存儲數(shù)據(jù)庫。相關產(chǎn)品:BigTable、HBase、Cassandra、HadoopDB、GreenPlum、PNUTS。解決關系數(shù)據(jù)庫大數(shù)據(jù)場景下的 I/O 問題

- 文檔數(shù)據(jù)庫。相關產(chǎn)品:MongoDB、CouchDB、ThruDB、CloudKit、Perservere、Jackrabbit。解決關系數(shù)據(jù)庫強 schema 約束的問題。

- 圖形數(shù)據(jù)庫。相關產(chǎn)品:Neo4J、OrientDB、InfoGrid、GraphDB。主要解決大量復雜、互連接、低結構化的圖結構場合,如社交網(wǎng)絡、推薦系統(tǒng)等

- 全文搜索引擎。相關產(chǎn)品:Elasticsearch。主要解決關系數(shù)據(jù)庫的全文搜索性能問題。

由此可見,沒有哪一種NoSql是完美的,每一種Nosql都有自己擅長的領域,這也是我們做系統(tǒng)架構中要考慮的重要因素。

場景1

電商的商品設計過程中,每種商品的屬性都不同,屬性數(shù)目不同,屬性名不同,同一個商品有可能會屬于多個分類,而且隨著業(yè)務的發(fā)展,很多商品會增加新的屬性,而且最令程序員頭疼莫過于每種屬性都有可能有搜索的可能性(當然搜索可以利用搜索引擎來實現(xiàn))。遇到這樣的需求場景,如果利用關系型數(shù)據(jù)庫來存儲的話,表的字段會非常多,而且字段的定義非常令人頭疼。

這樣的場景非常適合NOsql中的文檔型數(shù)據(jù)庫,比如MongoDB。文檔型數(shù)據(jù)庫新增字段非常簡單,不像關系型數(shù)據(jù)庫需要先執(zhí)行DDL來增加字段,直接可以利用程序來進行讀寫,歷史數(shù)據(jù)就算是沒有相應的字段也不會有異常的情況發(fā)生。最重要的一點,文檔型數(shù)據(jù)庫很擅長存儲復雜結構的數(shù)據(jù),一般情況下業(yè)務上可以利用表現(xiàn)能力很強的json數(shù)據(jù)結構。

{
    "Id":1,
    "ProductName":"杜蕾斯加強版",
    "Price":100,
    "Type":[
        1,
        2,
        4
    ],
    "Length":20,
    "Height":2

}

如果所有商品信息都用mongodb來存儲的話,有的場景并不是十分完美。比如商品被成功購買之后扣庫存的問題,聯(lián)合查詢的問題,由于Nosql天生對ACID支持不足的原因,一個事務性的操作很難在Nosql中實現(xiàn),所以設計系統(tǒng)的時候在很多情況下是關系數(shù)據(jù)庫+Nosql 來共同實現(xiàn)業(yè)務。

場景2

很多具體的業(yè)務中都有記錄數(shù)據(jù)然后進行統(tǒng)計的需求場景,比如那些統(tǒng)計uv,pv的系統(tǒng)。日志型的數(shù)據(jù)量非常大,而且還有可能有峰值的出現(xiàn),如果用關系型數(shù)據(jù)庫來存儲,很有可能在IO上會出現(xiàn)瓶頸,而且有可能會影響其他正常的業(yè)務,更不幸的是當執(zhí)行統(tǒng)計語句的時候,性能更是差強人意。這樣的日志型統(tǒng)計業(yè)務很適合HBase這樣的列式Nosql,業(yè)務上要統(tǒng)計一天的uv,pv數(shù)據(jù),HBase很適合統(tǒng)計某一列數(shù)據(jù)的場景,因為只需要把對應的列進行統(tǒng)計即可,不像關系型數(shù)據(jù)庫那樣需要把所有行都加載進內(nèi)存,而且列式存儲一般比行式存儲擁有更大的壓縮比例,占用的磁盤空間會更少。

用NOSql給高并發(fā)系統(tǒng)加速是一種多厲害的技術

列式存儲的應用場景有一定的限制,一般用于統(tǒng)計和大數(shù)據(jù)的分析中。

場景3

在多數(shù)高并發(fā)系統(tǒng)中都存在緩存的設計,而緩存的一般數(shù)據(jù)結構都是K-V結構。緩存是一種提高系統(tǒng)性能的有效手段,因其需要提供快速訪問的特性,一般緩存都放置于內(nèi)存當中。比如現(xiàn)在我們要設計一個用戶管理系統(tǒng),每個用戶信息可以做緩存以便提供高速的訪問,由于很多系統(tǒng)都采用分布式的部署方式,所以采用進程內(nèi)的緩存方式并不可取,這個時候就需要有一種高速的外部存儲來提供這種業(yè)務,這正是kv型Nosql的典型應用場景之一。其中以redis為代表,具體的業(yè)務中可以以用戶id為key,用戶的信息為value存儲在redis中,而且redis在3.0之后可以做集群了,在高可用和擴展上更能助力業(yè)務方。redis支持的數(shù)據(jù)類型很多,在不同的場景下選擇不同的數(shù)據(jù)類型。

場景4

當一個系統(tǒng)有搜索的業(yè)務時候,如果搜索的條件是一些簡單的類型搜索,關系型數(shù)據(jù)庫還可以滿足,但是如果有全文搜索,就是我們平時sql寫的like ‘%xx%’這樣的搜索,關系型數(shù)據(jù)庫可能并不是最好的選擇,全文搜索引擎類型的Nosql也許是一個更好的解決方案,其中以Elasticsearch 為代表。全文搜索引擎的搜索的條件可以隨意排列組合,并且可以實現(xiàn)關系型數(shù)據(jù)庫like方式的模糊匹配。

全文搜索引擎的技術原理稱為“倒排索引”(inverted index),是一種索引方法,其基本原理是建立單詞到文檔的索引。與之相對是,是“正排索引”,其基本原理是建立文檔到單詞的索引。

場景5

在社交系統(tǒng)中最常見例子就是社會網(wǎng)絡中人與人之間的關系。關系型數(shù)據(jù)庫用于存儲“關系型”數(shù)據(jù)的效果并不好,其查詢復雜、緩慢、超出預期,而圖形數(shù)據(jù)庫的獨特設計恰恰彌補了這個缺陷,解決關系型數(shù)據(jù)庫存儲和處理復雜關系型數(shù)據(jù)功能較弱的問題。其中以Neo4j為代表。想深入研究的同學請移步百度。

對于以上關于用NOSql給高并發(fā)系統(tǒng)加速是一種多厲害的技術,如果大家還有更多需要了解的可以持續(xù)關注我們億速云的行業(yè)推新,如需獲取專業(yè)解答,可在官網(wǎng)聯(lián)系售前售后的,希望該文章可給大家?guī)硪欢ǖ闹R更新。

向AI問一下細節(jié)

免責聲明:本站發(fā)布的內(nèi)容(圖片、視頻和文字)以原創(chuàng)、轉載和分享為主,文章觀點不代表本網(wǎng)站立場,如果涉及侵權請聯(lián)系站長郵箱:is@yisu.com進行舉報,并提供相關證據(jù),一經(jīng)查實,將立刻刪除涉嫌侵權內(nèi)容。

AI