• <fieldset id="8imwq"><menu id="8imwq"></menu></fieldset>
  • <bdo id="8imwq"><input id="8imwq"></input></bdo>
    最新文章專題視頻專題問答1問答10問答100問答1000問答2000關(guān)鍵字專題1關(guān)鍵字專題50關(guān)鍵字專題500關(guān)鍵字專題1500TAG最新視頻文章推薦1 推薦3 推薦5 推薦7 推薦9 推薦11 推薦13 推薦15 推薦17 推薦19 推薦21 推薦23 推薦25 推薦27 推薦29 推薦31 推薦33 推薦35 推薦37視頻文章20視頻文章30視頻文章40視頻文章50視頻文章60 視頻文章70視頻文章80視頻文章90視頻文章100視頻文章120視頻文章140 視頻2關(guān)鍵字專題關(guān)鍵字專題tag2tag3文章專題文章專題2文章索引1文章索引2文章索引3文章索引4文章索引5123456789101112131415文章專題3
    問答文章1 問答文章501 問答文章1001 問答文章1501 問答文章2001 問答文章2501 問答文章3001 問答文章3501 問答文章4001 問答文章4501 問答文章5001 問答文章5501 問答文章6001 問答文章6501 問答文章7001 問答文章7501 問答文章8001 問答文章8501 問答文章9001 問答文章9501
    當(dāng)前位置: 首頁 - 科技 - 知識(shí)百科 - 正文

    SQL到NOSQL的思維轉(zhuǎn)變的具體分析

    來源:懂視網(wǎng) 責(zé)編:小采 時(shí)間:2020-11-09 20:11:29
    文檔

    SQL到NOSQL的思維轉(zhuǎn)變的具體分析

    SQL到NOSQL的思維轉(zhuǎn)變的具體分析:NOSQL系統(tǒng)一般都會(huì)宣傳一個(gè)特性,那就是性能好,然后為什么呢關(guān)系型數(shù)據(jù)庫發(fā)展了這么多年,各種優(yōu)化工作已經(jīng)做得很深了,NOSQL系統(tǒng)一般都是吸收關(guān)系型數(shù)據(jù)庫的技術(shù),然后,到底是什么因素束縛了關(guān)系型數(shù)據(jù)庫的性能呢我們從系統(tǒng)設(shè)計(jì)的角度看這個(gè)問題。 1,
    推薦度:
    導(dǎo)讀SQL到NOSQL的思維轉(zhuǎn)變的具體分析:NOSQL系統(tǒng)一般都會(huì)宣傳一個(gè)特性,那就是性能好,然后為什么呢關(guān)系型數(shù)據(jù)庫發(fā)展了這么多年,各種優(yōu)化工作已經(jīng)做得很深了,NOSQL系統(tǒng)一般都是吸收關(guān)系型數(shù)據(jù)庫的技術(shù),然后,到底是什么因素束縛了關(guān)系型數(shù)據(jù)庫的性能呢我們從系統(tǒng)設(shè)計(jì)的角度看這個(gè)問題。 1,

      NOSQL系統(tǒng)一般都會(huì)宣傳一個(gè)特性,那就是性能好,然后為什么呢?關(guān)系型數(shù)據(jù)庫發(fā)展了這么多年,各種優(yōu)化工作已經(jīng)做得很深了,NOSQL系統(tǒng)一般都是吸收關(guān)系型數(shù)據(jù)庫的技術(shù),然后,到底是什么因素束縛了關(guān)系型數(shù)據(jù)庫的性能呢?我們從系統(tǒng)設(shè)計(jì)的角度看這個(gè)問題。

      1, 索引支持。關(guān)系型數(shù)據(jù)庫創(chuàng)立之初沒有想到今天的互聯(lián)網(wǎng)應(yīng)用對(duì)可擴(kuò)展性提出如此高的要求,因此,設(shè)計(jì)時(shí)主要考慮的是簡化用戶的工作,SQL語言的產(chǎn)生促成數(shù)據(jù)庫接口的標(biāo)準(zhǔn)化,從而形成了Oracle這樣的數(shù)據(jù)庫公司并帶動(dòng)了上下游產(chǎn)業(yè)鏈的發(fā)展。關(guān)系型數(shù)據(jù)庫在單機(jī)存儲(chǔ)引擎支持索引,比如Mysql的Innodb存儲(chǔ)引擎需要支持索引,而NOSQL系統(tǒng)的單機(jī)存儲(chǔ)引擎是純粹的,只需要支持基于主鍵的隨機(jī)讀取和范圍查詢。NOSQL系統(tǒng)在系統(tǒng)層面提供對(duì)索引的支持,比如有一個(gè)用戶表,主鍵為user_id,每個(gè)用戶有很多屬性,包括用戶名,照片ID(photo_id),照片URL,在NOSQL系統(tǒng)中如果需要對(duì)photo_id建立索引,可以維護(hù)一張分布式表,表的主鍵為

      2, 事務(wù)并發(fā)處理。關(guān)系型數(shù)據(jù)庫有一整套的關(guān)于事務(wù)并發(fā)處理的理論,比如鎖的粒度是表級(jí),頁級(jí)還是行級(jí),多版本并發(fā)控制機(jī)制MVCC,事務(wù)的隔離級(jí)別,死鎖檢測,回滾,等等。然而,互聯(lián)網(wǎng)應(yīng)用大多數(shù)的特點(diǎn)都是多讀少些,比如讀和寫的比例是10 : 1,并且很少有復(fù)雜事務(wù)需求,因此,一般可以采用更為簡單的copy-on-write技術(shù):單線程寫,多線程讀,寫的時(shí)候執(zhí)行copy-on-write,寫不影響讀服務(wù)。NOSQL系統(tǒng)這樣的假設(shè)簡化了系統(tǒng)的設(shè)計(jì),減少了很多操作的overhead,提高了性能。

      3, 動(dòng)態(tài)還是靜態(tài)的數(shù)據(jù)結(jié)構(gòu)。關(guān)系型數(shù)據(jù)庫的存儲(chǔ)引擎總是一顆磁盤B+樹,為了提高性能,可能需要有insert buffer聚合寫,query cache緩存讀,經(jīng)常需要實(shí)現(xiàn)類似Linux page cache的緩存管理機(jī)制。數(shù)據(jù)庫中的讀和寫是互相影響的,寫操作也因?yàn)闀r(shí)不時(shí)需要將數(shù)據(jù)flush到磁盤而性能不高。簡而言之,關(guān)系型數(shù)據(jù)庫存儲(chǔ)引擎的數(shù)據(jù)結(jié)構(gòu)是通用的動(dòng)態(tài)更新的B+樹,然而,在NOSQL系統(tǒng)中,比如Bigtable中采用SSTable + MemTable的數(shù)據(jù)結(jié)構(gòu),數(shù)據(jù)先寫入到內(nèi)存的MemTable,達(dá)到一定大小或者超過一定時(shí)間才會(huì)dump到磁盤生成SSTable文件,SSTable是只讀的。如果說關(guān)系型數(shù)據(jù)庫存儲(chǔ)引擎的數(shù)據(jù)結(jié)構(gòu)是一顆動(dòng)態(tài)的B+樹,那么SSTable就是一個(gè)排好序的有序數(shù)組。很明顯,實(shí)現(xiàn)一個(gè)有序數(shù)據(jù)比實(shí)現(xiàn)一個(gè)動(dòng)態(tài)B+樹且包含復(fù)雜的并發(fā)控制機(jī)制要簡單高效地多。

      4, Join操作。關(guān)系型數(shù)據(jù)庫需要在存儲(chǔ)引擎層面支持Join,而NOSQL系統(tǒng)一般根據(jù)應(yīng)用來決定Join實(shí)現(xiàn)的方式。舉個(gè)例子,有兩張表:用戶表和商品表,每個(gè)用戶下可能有若干個(gè)商品,用戶表的主鍵為

      關(guān)系型數(shù)據(jù)庫的性能瓶頸往往不在SQL語句解析上,而是在于需要支持完備的SQL特性。互聯(lián)網(wǎng)公司面臨的問題是應(yīng)用對(duì)性能和可擴(kuò)展性要求很高,并且DBA和開發(fā)工程師水平比較高,可以通過犧牲一些接口友好性來換取更好的性能。NOSQL系統(tǒng)的一些設(shè)計(jì),比如通過寬表實(shí)現(xiàn)Join操作,互聯(lián)網(wǎng)公司的DBA和開發(fā)工程師也做過,NOSQL系統(tǒng)只是加強(qiáng)了這種約束。從長遠(yuǎn)來看,可以總結(jié)一套約束集合,并且定義一個(gè)SQL子集,只需要支持這個(gè)SQL子集就可以在不犧牲可擴(kuò)展性的前提下支持比如90%以上的互聯(lián)網(wǎng)應(yīng)用。我想,NOSQL技術(shù)發(fā)展到這一步的時(shí)候就算是比較成熟了,這也是我們最終想做的事情。我們?cè)谠O(shè)計(jì)和使用NOSQL系統(tǒng)的時(shí)候也可以適當(dāng)轉(zhuǎn)化一下思維,如下:

      1, 更大的數(shù)據(jù)量。很多人在使用Mysql的過程遇到記錄條數(shù)超過一定值,比如2000W的時(shí)候,數(shù)據(jù)庫性能開始下降,這個(gè)值的得出往往需要經(jīng)過大量的測試。然而,大多數(shù)的NOSQL系統(tǒng)可擴(kuò)展性都比較好,能夠支持更大的數(shù)據(jù)量,因此也可以采用一些空間換時(shí)間的做法,比如通過寬表的方式實(shí)現(xiàn)Join。

      2, 性能預(yù)估更加容易。關(guān)系型數(shù)據(jù)庫由于復(fù)雜的并發(fā)控制,insert buffer及類似page cache的讀寫優(yōu)化機(jī)制,性能估算相對(duì)較難,很多時(shí)候需要憑借經(jīng)驗(yàn)或者經(jīng)過測試才能得出系統(tǒng)的性能。然后,NOSQL系統(tǒng)由于存儲(chǔ)引擎實(shí)現(xiàn),并發(fā)控制機(jī)制等相對(duì)簡單,可以通過硬件的性能指標(biāo)在系統(tǒng)設(shè)計(jì)之處大致預(yù)估系統(tǒng)的性能,性能預(yù)估可操作性相對(duì)更強(qiáng)

    聲明:本網(wǎng)頁內(nèi)容旨在傳播知識(shí),若有侵權(quán)等問題請(qǐng)及時(shí)與本網(wǎng)聯(lián)系,我們將在第一時(shí)間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com

    文檔

    SQL到NOSQL的思維轉(zhuǎn)變的具體分析

    SQL到NOSQL的思維轉(zhuǎn)變的具體分析:NOSQL系統(tǒng)一般都會(huì)宣傳一個(gè)特性,那就是性能好,然后為什么呢關(guān)系型數(shù)據(jù)庫發(fā)展了這么多年,各種優(yōu)化工作已經(jīng)做得很深了,NOSQL系統(tǒng)一般都是吸收關(guān)系型數(shù)據(jù)庫的技術(shù),然后,到底是什么因素束縛了關(guān)系型數(shù)據(jù)庫的性能呢我們從系統(tǒng)設(shè)計(jì)的角度看這個(gè)問題。 1,
    推薦度:
    標(biāo)簽: 轉(zhuǎn)換 sql 思維
    • 熱門焦點(diǎn)

    最新推薦

    猜你喜歡

    熱門推薦

    專題
    Top
    主站蜘蛛池模板: 精品免费人成视频app| 夜色www国产精品资源站| 91精品国产综合久久精品| 久久久久久青草大香综合精品| 精品精品国产自在久久高清| 无码精品人妻一区二区三区漫画| 国产精品尹人在线观看| 欧美日韩精品一区二区在线播放| 国精品午夜福利视频不卡| 亚洲无码日韩精品第一页| 国产精品 综合 第五页| 九九热在线精品视频| 久久精品国产亚洲av影院| 在线亚洲精品自拍| 久久久久国产日韩精品网站| 国产A∨免费精品视频| 久久精品国产半推半就| 国产精品兄妹在线观看麻豆| 色久综合网精品一区二区| 亚洲精品宾馆在线精品酒店| 国产亚洲精品高清在线| 国产精品午夜免费观看网站| 99久久精品免费| 91午夜精品亚洲一区二区三区| 国产精品视频一区二区三区| 国产精品igao视频网网址| 日本午夜精品一区二区三区电影| 亚洲欧美日韩国产精品| 在线观看亚洲精品国产| 亚欧乱色国产精品免费视频| 欧美黑人巨大videos精品| 青春草无码精品视频在线观| 天天爽夜夜爽夜夜爽精品视频| 久久精品一区二区三区中文字幕| 国内精品久久久久久不卡影院| 国产精品日韩欧美久久综合| 99久久精品国产毛片| 国产精品热久久毛片| 精品人妻少妇一区二区三区在线 | 亚洲精品无码你懂的网站| 日本一区二区三区精品国产|