高性能架構模式8講16丨nosql

關系數(shù)據(jù)庫的表結構schema是強約束，操作不存在的列會報錯，業(yè)務變化時擴充列也比較麻煩，需要執(zhí)行DDL（datadefinitionlanguage，如CREATE、ALTER、DROP等）語句修改，而且修改時可能會長時間鎖表（例如，MySQL可能將表鎖住1個小時）。關系數(shù)據(jù)庫在大數(shù)據(jù)場景下I/OI/OlikeNoSQL應用場景下表現(xiàn)更好。但世上沒有免費的午餐，NoSQL方案帶來的優(yōu)勢，本質(zhì)上是犧牲ACID中的某個或者某幾個特性，因此我們不能盲目地NoSQL是銀彈，而應該將NoSQL作為SQL的一個有力補充，NoSQL!=NoSQL，而是NoSQL=NotOnly常見的NoSQL方案分為4K-V：解決關系數(shù)據(jù)庫無法數(shù)據(jù)結構的問題，以Redis為代表schemaMongoDB列式數(shù)據(jù)庫：解決關系數(shù)據(jù)庫大數(shù)據(jù)場景下的I/O問題，以HBase為代表。全文搜索引擎：解決關系數(shù)據(jù)庫的全文搜索性能問題，以Elasticsearch為代表。今天，我來介紹一下各種高性能NoSQL方案的典型特征和應用場景。K-VK-V的全稱是Key-Value，其中Key是數(shù)據(jù)的標識，和關系數(shù)據(jù)庫中的主鍵含義一樣，Value就是具體的數(shù)據(jù)。Redis是K-V的典型代表，它是一款開源（基于BSD）的高性能K-V緩存和存儲系統(tǒng)。RedisValuestring、hash、list、set、sortedset、bitmap和hyperloglog，所以常常被稱為數(shù)據(jù)結構服務器。LPOPkeyLLENkey（List）RPOPkey以上這些功能，如果用關系數(shù)據(jù)庫來實現(xiàn)，就會變得很復雜。例如，LPOP操作是移除并返回key對應的list的第一個元素。如果用關系數(shù)據(jù)庫來，為了達到同樣目的，需要進行每條數(shù)據(jù)除了數(shù)據(jù)編號（ID），還要有位置編號，否則沒有辦法判斷哪條數(shù)據(jù)是第一條。注意這里不能用行ID作為位置編號，因為我們會往列表頭部插入數(shù)據(jù)?？梢钥闯鲫P系數(shù)據(jù)庫的實現(xiàn)很麻煩，而且需要進行多次SQL操作，性能很低。RedisACID，Redis的事務和關系數(shù)據(jù)庫的事務不可同日而語，Redis的事務只能保證性和一致性（I和C），無法保證原子性和持久性（A和D）。雖然Redis并沒有嚴格遵循ACID原則，但實際上大部分業(yè)務也不需要嚴格遵循ACID原則。以上面關注操作為例，即使系統(tǒng)沒有將A加入B的粉絲列表，其實業(yè)務影響也非常小，因此我們在設計方案時，需要根據(jù)業(yè)務特性和要求來確定是否可以用Redis，而不能因為Redis不遵循ACID原則就直接放棄。為了解決關系數(shù)據(jù)庫schema帶來的問題，文檔數(shù)據(jù)庫應運而生。文檔數(shù)據(jù)庫最大的特點就是no-schema，可以和任意的數(shù)據(jù)。目前絕大部分文檔數(shù)據(jù)庫的數(shù)據(jù)格式是JSON（或者BSON），因為JSON數(shù)據(jù)是自描述的，無須在使用前定義字段，一個JSON中不存在的字段也不會導致SQL那樣的語法錯誤。文檔數(shù)據(jù)庫的no-schema業(yè)務上增加新的字段，無須再像關系數(shù)據(jù)庫一樣要先執(zhí)行DDL語句修改表結構，程序代碼JSON是一種強大的描述語言，能夠描述復雜的數(shù)據(jù)結構。例如，我們設計一個用戶管理系統(tǒng)，用戶的信息有D、、、、郵箱、地址、學歷信息。其中是列表（因為可以有多個）；地址是一個結構，包括省市區(qū)樓盤地址；學歷包括學校、專業(yè)、入學畢業(yè)年份信息等。如果我們用關系數(shù)據(jù)庫來，需要設計多張表，包括基本信息（列：D、、、郵箱）、（列：ID、）、地址（列：省、市、區(qū)、詳細地 "id":"name": ":"hobbies":" "": "address":"province":"city":"district":"detail":"YunRoad "education": "begin":"2000-09- "end":"2004-07-"school":""major":"ComputerScience& "begin":"2004-09- "end":"2007-07-"school":"major":"ComputerScience& JSON文檔數(shù)據(jù)庫的這個特點，特別適合和游戲這類的業(yè)務場景。以為例，不同商品的屬即使是同類商品也有不同的屬性。例如，LCD和LED顯示器，兩者有不同的參數(shù)指標。這種業(yè)務場景如果使用關系數(shù)據(jù)庫來數(shù)據(jù)，就會很麻煩，而使用文檔數(shù)據(jù)庫，會簡單、方文檔數(shù)據(jù)庫-sema的特性帶來的這些優(yōu)勢也是有代價的，最主要的代價就是不支持事務。例如，使用MongoDB來商品庫存，系統(tǒng)創(chuàng)建訂單的時候首先需要減扣庫存，然后再創(chuàng)建訂單。這是一個事務操作，用關系數(shù)據(jù)庫來實現(xiàn)就很簡單，但如果用MongoDB來實現(xiàn)，就無法做到事務性。異常情況下可能出現(xiàn)庫存被扣減了，但訂單沒有創(chuàng)建的情況。因此某些對事務要求嚴格的業(yè)務場景是不能使用文檔數(shù)據(jù)庫的。文檔數(shù)據(jù)庫另外一個缺點就是無法實現(xiàn)關系數(shù)據(jù)庫的join操作。例如，我們有一個用戶信息表和一個訂單表，訂單表中有買家用戶id。如果要查詢“了蘋果筆記本用戶中的女性用戶”，用關系數(shù)據(jù)庫來實現(xiàn)，一個簡單的join操作就搞定了；而用文檔數(shù)據(jù)庫是無法進行join查詢的，需要查兩次：一次查詢訂單表中了蘋果筆記本的用戶，然后再查詢顧名思義，列式數(shù)據(jù)庫就是按照列來數(shù)據(jù)的數(shù)據(jù)庫，與之對應的傳統(tǒng)關系數(shù)據(jù)庫被稱為“行式數(shù)據(jù)庫”，因為關系數(shù)據(jù)庫是按照行來數(shù)據(jù)的。業(yè)務同時多個列時效率高，因為這些列都是按行在一起的，一次磁盤操作就能夠能夠完成對一行中的多個列的寫操作，保證了針對行數(shù)據(jù)寫操作的原子性和一致性；否則如果采用列，可能會出現(xiàn)某次寫操作，有的列成功了，有的列失敗了，導致數(shù)據(jù)不一致。我們可以看到，行式的優(yōu)勢是在特定的業(yè)務場景下才能體現(xiàn)，如果不存在這樣的業(yè)務場景，那么行式的優(yōu)勢也將不復存在，甚至成為劣勢，典型的場景就是海量數(shù)據(jù)進行統(tǒng)計。例如，計算某個城市體重超重的人員數(shù)據(jù)，實際上只需要每個人的體重這一列并進行統(tǒng)計即可，而行式即使最終只使用一列，也會將所有行數(shù)據(jù)都出來。如果單行用戶信息有1KB，其中體重只有4個字節(jié)，行式還是會將整行1KB數(shù)據(jù)全部到內(nèi)存中，這是明顯的浪費。而如果采用列式，每個用戶只需要4字節(jié)的體重數(shù)據(jù)即可，I/O除了節(jié)省I/O，列式還具備更高的壓縮比，能夠節(jié)省的空間。普通的行式數(shù)據(jù)庫一般壓縮率在3:1到5:1左右，而列式數(shù)據(jù)庫的壓縮率一般在8:1到30:1左右，因同樣，如果場景發(fā)生變化，列式的優(yōu)勢又會變成劣勢。典型的場景是需要頻繁地更新多個列。因為列式將不同列在磁盤上不連續(xù)的空間，導致更新多個列時磁盤是隨機寫操作；而行式時同一行多個列都在連續(xù)的空間，一次磁盤寫操作就可以完成，列式的隨機寫效率要遠遠低于行式的寫效率。此外，列式高壓縮率在更新場景下也會成為劣勢，因為更新時需要將數(shù)據(jù)解壓后更新，然后再壓縮，最后寫入磁盤?；谏鲜隽惺降膬?yōu)缺點，一般將列式應用在離線的大數(shù)據(jù)分析和統(tǒng)計場景中，因為也為力，主要體現(xiàn)在：全文搜索的模糊匹配方式，索引，只能用like查詢，而like查詢是整表掃描，我舉一個具體的例子來看看關系型數(shù)據(jù)庫為何全文搜索的要求。假設我們做一個婚戀，其主要目的是幫助程序員找朋友，但模式與傳統(tǒng)婚戀不同，是“程序員發(fā)布自1PHPPHP1的搜索條件是“+PHP+”，其中“PHP”要用模糊匹配查詢“語2的搜索條件是“+鵝廠+旅游”，其中“旅游”要用模糊匹配查詢“愛3：我是一個“女程序員”，想在找一個貓廠的Java技術專家。3的搜索條件是“+貓廠++Java+技術專家”，其中“貓廠+”可帥哥4帥哥4的搜索條件是“+美麗+”，只能通過模糊匹配搜索“自我介紹”列全文搜索引擎的技術原理被稱為“倒排索引”（neredidex），也常被稱為反向索引、置入或反向，是一種索引方法，其基本原理是建立單詞到文檔的索引。之所以被稱為“倒排”索引，是和“正排“索引相對的，“正排索引”的基本原理是建立文檔到單詞的索引。我們通過一個簡單的樣例來說明這兩種索引的差異。假設我們有一個技術文章的，里面收集了各種技術文章，用戶可以在瀏覽或者搜索正排索引適用于根據(jù)文檔名稱來查詢文檔內(nèi)容。例如，用戶在上單擊了“面向?qū)ο罂▽毜涫鞘裁础?，根?jù)文章標題查詢文章的內(nèi)容展示給用戶。倒排索引適用于根據(jù)來查詢文檔內(nèi)容。例如，用戶只是想看“設計”相關的文章，網(wǎng)全文搜索引擎的索引對象是單詞和文檔，而關系數(shù)據(jù)庫的索引對象是鍵和行，兩者的術語差異很大，不能簡單地等同起來。因此，為了讓全文搜索引擎支持關系型數(shù)據(jù)的全文搜索，需要做一些轉(zhuǎn)換操作，即將關系型數(shù)據(jù)轉(zhuǎn)換為文檔數(shù)據(jù)。目前常用的轉(zhuǎn)換方式是將關系型數(shù)據(jù)按照對象的形式轉(zhuǎn)換為JSON文檔，然后將JSON文將前面樣例中的程序員表格轉(zhuǎn)換為JSON文檔，可以得到3個程序員信息相關的文檔，我以程序員1為例：1{21{2"id":3"":"多隆4"":"男5"地點":"6"單位":"貓廠7 ":"8"語言":"Java、C++、 ",9

"自我介紹":"技術專家，簡單，為人熱情——序列化成為JSON在Elasicsearch中，每個字段的所有數(shù)據(jù)都是默認被索引的。即每個字段都有為了快速檢索設置的倒排索引。而且，不像其他多數(shù)的數(shù)據(jù)庫，它能在相同的查詢中使用所有倒排索引，并以驚人的速度返回結果。（/elasticsearch/guide/current/data-in- 今天我為你講了為了彌補關系型數(shù)據(jù)庫缺陷而產(chǎn)生的NoSQLNoSQL為NoSQL=NoSQL，架構設計的時候無需再使用關系數(shù)據(jù)庫，對此你怎么看？ 不得售賣。頁面已增加防盜追蹤，將依法其上一 架構專欄特別放送|“華仔，放學別走！”第2下一 17|高性能緩存架鵝米豆 92關于NoSQL，看過一張圖，挺形象：“1970，WehavenoSQL”->“1980，KnowSQL”->“2000，NoSQL”->“2005，NotonlySQL”->“2015，No，SQL”。目 13NoSQL并非銀彈，如ACID方面就無法跟關系型數(shù)據(jù)庫相比，實際運用中，需要根據(jù)業(yè)務場景來分析，比較好的做法是，NoSQL+關系型數(shù)據(jù)庫結合使用，取長補短。如我們之前鈴蘭 …空檔滑 7所以就注定了NOSQL約書 7 但現(xiàn)在大多數(shù)應用的也許還是直接面對用戶，要求數(shù)據(jù)有一定可靠性，數(shù)據(jù)總量和并發(fā)小喵 孫振 4 你好，我有找到一張historyofnosql圖檔，給您 幻影霸 4 姜 4，我們公司剛起步的時候有2個應用，數(shù)據(jù)庫用的mysql,日志也在mysql,用戶增長很快，沒有專職架構師，現(xiàn)在準備重構以適應業(yè)務增長，考慮jhipsteronkubernetes昨天同事之間交流了一下方案: