NoSQL太火,冒出太多產(chǎn)品了,保守估計也成百上千了。
員工經(jīng)過長期磨合與沉淀,具備了協(xié)作精神,得以通過團隊的力量開發(fā)出優(yōu)質的產(chǎn)品。創(chuàng)新互聯(lián)堅持“專注、創(chuàng)新、易用”的產(chǎn)品理念,因為“專注所以專業(yè)、創(chuàng)新互聯(lián)網(wǎng)站所以易用所以簡單”。公司專注于為企業(yè)提供做網(wǎng)站、成都網(wǎng)站建設、微信公眾號開發(fā)、電商網(wǎng)站開發(fā),小程序設計,軟件按需制作等一站式互聯(lián)網(wǎng)企業(yè)服務。
互聯(lián)網(wǎng)公司常用的基本集中在以下幾種,每種只舉一個比較常見或者應用比較成功的例子吧。
1. In-Memory KV Store : Redis
in memory key-value store,同時提供了更加豐富的數(shù)據(jù)結構和運算的能力,成功用法是替代memcached,通過checkpoint和commit log提供了快速的宕機恢復,同時支持replication提供讀可擴展和高可用。
2. Disk-Based KV Store: Leveldb
真正基于磁盤的key-value storage, 模型單一簡單,數(shù)據(jù)量不受限于內存大小,數(shù)據(jù)落盤高可靠,Google的幾位大神出品的精品,LSM模型天然寫優(yōu)化,順序寫盤的方式對于新硬件ssd再適合不過了,不足是僅提供了一個庫,需要自己封裝server端。
3. Document Store: Mongodb
分布式nosql,具備了區(qū)別mysql的最大亮點:可擴展性。mongodb 最新引人的莫過于提供了sql接口,是目前nosql里最像mysql的,只是沒有ACID的特性,發(fā)展很快,支持了索引等特性,上手容易,對于數(shù)據(jù)量遠超內存限制的場景來說,還需要慎重。
4. Column Table Store: HBase
這個富二代似乎不用贅述了,最大的優(yōu)勢是開源,對于普通的scan和基于行的get等基本查詢,性能完全不是問題,只是只提供裸的api,易用性上是短板,可擴展性方面是最強的,其次坐上了Hadoop的快車,社區(qū)發(fā)展很快,各種基于其上的開源產(chǎn)品不少,來解決諸如join、聚集運算等復雜查詢。
關系數(shù)據(jù)庫經(jīng)過幾十年的發(fā)展,已經(jīng)非常成熟,但同時也存在不足:
表結構是強約束的,業(yè)務變更時擴充很麻煩。
如果對大數(shù)據(jù)量的表進行統(tǒng)計運算,I/O會很高,因為即使只針對某列進行運算,也需要將整行數(shù)據(jù)讀入內存。
全文搜索只能使用 Like 進行整表掃描,性能非常低。
針對這些不足,產(chǎn)生了不同的 NoSQL 解決方案,在某些場景下比關系數(shù)據(jù)庫更有優(yōu)勢,但同時也犧牲了某些特性,所以不能片面的迷信某種方案,應將其作為 SQL 的有利補充。
NoSQL != No SQL,而是:
NoSQL = Not Only SQL
典型的 NoSQL 方案分為4類:
Redis 是典型,其 value 是具體的數(shù)據(jù)結構,包括 string, hash, list, set, sorted set, bitmap, hyperloglog,常被稱為數(shù)據(jù)結構服務器。
以 list 為例:
LPOP key 是移除并返回隊列左邊的第一個元素。
如果用關系數(shù)據(jù)庫就比較麻煩了,需要操作:
Redis 的缺點主要體現(xiàn)在不支持完成的ACID事務,只能保證隔離性和一致性,無法保證原子性和持久性。
最大的特點是 no-schema,無需在使用前定義字段,讀取一個不存在的字段也不會導致語法錯誤。
特點:
以電商為例,不同商品的屬性差異很大,如冰箱和電腦,這種差異性在關系數(shù)據(jù)庫中會有很大的麻煩,而使用文檔數(shù)據(jù)庫則非常方便。
文檔數(shù)據(jù)庫的主要缺點:
關系數(shù)據(jù)庫是按行來存儲的,列式數(shù)據(jù)庫是按照列來存儲數(shù)據(jù)。
按行存儲的優(yōu)勢:
在某些場景下,這些優(yōu)勢就成為劣勢了,例如,計算超重人員的數(shù)據(jù),只需要讀取體重這一列進行統(tǒng)計即可,但行式存儲會將整行數(shù)據(jù)讀取到內存中,很浪費。
而列式存儲中,只需要讀取體重這列的數(shù)據(jù)即可,I/O 將大大減少。
除了節(jié)省I/O,列式存儲還有更高的壓縮比,可以節(jié)省存儲空間。普通行式數(shù)據(jù)庫的壓縮比在 3:1 到 5:1 左右,列式數(shù)據(jù)庫在 8:1 到 30:1,因為單個列的數(shù)據(jù)相似度更高。
列式存儲的隨機寫效率遠低于行式存儲,因為行式存儲時同一行多個列都存儲在連續(xù)空間中,而列式存儲將不同列存儲在不連續(xù)的空間。
一般將列式存儲應用在離線大數(shù)據(jù)分析統(tǒng)計場景,因為這時主要針對部分列進行操作,而且數(shù)據(jù)寫入后無須更新。
關系數(shù)據(jù)庫通過索引進行快速查詢,但在全文搜索的情景下,索引就不夠了,因為:
假設有一個交友網(wǎng)站,信息表如下:
需要匹配性別、地點、語言列。
需要匹配性別、地點、愛好列。
實際搜索中,各種排列組合非常多,關系數(shù)據(jù)庫很難支持。
全文搜索引擎是使用 倒排索引 技術,建立單詞到文檔的索引,例如上面的表信息建立倒排索引:
所以特別適合根據(jù)關鍵詞來查詢文檔內容。
上面介紹了幾種典型的NoSQL方案,及各自的適用場景和特點,您可以根據(jù)實際需求進行選擇。
在大數(shù)據(jù)時代,“多種架構支持多類應用”成為數(shù)據(jù)庫行業(yè)應對大數(shù)據(jù)的基本思路,數(shù)據(jù)庫行業(yè)出現(xiàn)互為補充的三大陣營,適用于事務處理應用的OldSQL、適用于數(shù)據(jù)分析應用的NewSQL和適用于互聯(lián)網(wǎng)應用的NoSQL。但在一些復雜的應用場景中,單一數(shù)據(jù)庫架構都不能完全滿足應用場景對海量結構化和非結構化數(shù)據(jù)的存儲管理、復雜分析、關聯(lián)查詢、實時性處理和控制建設成本等多方面的需要,因此不同架構數(shù)據(jù)庫混合部署應用成為滿足復雜應用的必然選擇。不同架構數(shù)據(jù)庫混合使用的模式可以概括為:OldSQL+NewSQL、OldSQL+NoSQL、NewSQL+NoSQL三種主要模式。下面通過三個案例對不同架構數(shù)據(jù)庫的混合應用部署進行介紹。
OldSQL+NewSQL 在數(shù)據(jù)中心類應用中混合部署
采用OldSQL+NewSQL模式構建數(shù)據(jù)中心,在充分發(fā)揮OldSQL數(shù)據(jù)庫的事務處理能力的同時,借助NewSQL在實時性、復雜分析、即席查詢等方面的獨特優(yōu)勢,以及面對海量數(shù)據(jù)時較強的擴展能力,滿足數(shù)據(jù)中心對當前“熱”數(shù)據(jù)事務型處理和海量歷史“冷”數(shù)據(jù)分析兩方面的需求。OldSQL+NewSQL模式在數(shù)據(jù)中心類應用中的互補作用體現(xiàn)在,OldSQL彌補了NewSQL不適合事務處理的不足,NewSQL彌補了OldSQL在海量數(shù)據(jù)存儲能力和處理性能方面的缺陷。
商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合部署方式搭建,OldSQL數(shù)據(jù)庫滿足各業(yè)務系統(tǒng)數(shù)據(jù)的歸檔備份和事務型應用,NewSQL MPP數(shù)據(jù)庫集群對即席查詢、多維分析等應用提供高性能支持,并且通過MPP集群架構實現(xiàn)應對海量數(shù)據(jù)存儲的擴展能力。
商業(yè)銀行數(shù)據(jù)中心存儲架構
與傳統(tǒng)的OldSQL模式相比,商業(yè)銀行數(shù)據(jù)中心采用OldSQL+NewSQL混合搭建模式,數(shù)據(jù)加載性能提升3倍以上,即席查詢和統(tǒng)計分析性能提升6倍以上。NewSQL MPP的高可擴展性能夠應對新的業(yè)務需求,可隨著數(shù)據(jù)量的增長采用集群方式構建存儲容量更大的數(shù)據(jù)中心。
OldSQL+NoSQL 在互聯(lián)網(wǎng)大數(shù)據(jù)應用中混合部署
在互聯(lián)網(wǎng)大數(shù)據(jù)應用中采用OldSQL+NoSQL混合模式,能夠很好的解決互聯(lián)網(wǎng)大數(shù)據(jù)應用對海量結構化和非結構化數(shù)據(jù)進行存儲和快速處理的需求。在諸如大型電子商務平臺、大型SNS平臺等互聯(lián)網(wǎng)大數(shù)據(jù)應用場景中,OldSQL在應用中負責高價值密度結構化數(shù)據(jù)的存儲和事務型處理,NoSQL在應用中負責存儲和處理海量非結構化的數(shù)據(jù)和低價值密度結構化數(shù)據(jù)。OldSQL+NoSQL模式在互聯(lián)網(wǎng)大數(shù)據(jù)應用中的互補作用體現(xiàn)在,OldSQL彌補了NoSQL在ACID特性和復雜關聯(lián)運算方面的不足,NoSQL彌補了OldSQL在海量數(shù)據(jù)存儲和非結構化數(shù)據(jù)處理方面的缺陷。
數(shù)據(jù)魔方是淘寶網(wǎng)的一款數(shù)據(jù)產(chǎn)品,主要提供行業(yè)數(shù)據(jù)分析、店鋪數(shù)據(jù)分析。淘寶數(shù)據(jù)產(chǎn)品在存儲層采用OldSQL+NoSQL混合模式,由基于MySQL的分布式關系型數(shù)據(jù)庫集群MyFOX和基于HBase的NoSQL存儲集群Prom組成。由于OldSQL強大的語義和關系表達能力,在應用中仍然占據(jù)著重要地位,目前存儲在MyFOX中的統(tǒng)計結果數(shù)據(jù)已經(jīng)達到10TB,占據(jù)著數(shù)據(jù)魔方總數(shù)據(jù)量的95%以上。另一方面,NoSQL作為SQL的有益補充,解決了OldSQL數(shù)據(jù)庫無法解決的全屬性選擇器等問題。
淘寶海量數(shù)據(jù)產(chǎn)品技術架構
基于OldSQL+NoSQL混合架構的特點,數(shù)據(jù)魔方目前已經(jīng)能夠提供壓縮前80TB的數(shù)據(jù)存儲空間,支持每天4000萬的查詢請求,平均響應時間在28毫秒,足以滿足未來一段時間內的業(yè)務增長需求。
NewSQL+NoSQL 在行業(yè)大數(shù)據(jù)應用中混合部署
行業(yè)大數(shù)據(jù)與互聯(lián)網(wǎng)大數(shù)據(jù)的區(qū)別在于行業(yè)大數(shù)據(jù)的價值密度更高,并且對結構化數(shù)據(jù)的實時處理、復雜的多表關聯(lián)分析、即席查詢、數(shù)據(jù)強一致性等都比互聯(lián)網(wǎng)大數(shù)據(jù)有更高的要求。行業(yè)大數(shù)據(jù)應用場景主要是分析類應用,如:電信、金融、政務、能源等行業(yè)的決策輔助、預測預警、統(tǒng)計分析、經(jīng)營分析等。
在行業(yè)大數(shù)據(jù)應用中采用NewSQL+NoSQL混合模式,充分利用NewSQL在結構化數(shù)據(jù)分析處理方面的優(yōu)勢,以及NoSQL在非結構數(shù)據(jù)處理方面的優(yōu)勢,實現(xiàn)NewSQL與NoSQL的功能互補,解決行業(yè)大數(shù)據(jù)應用對高價值結構化數(shù)據(jù)的實時處理、復雜的多表關聯(lián)分析、即席查詢、數(shù)據(jù)強一致性等要求,以及對海量非結構化數(shù)據(jù)存儲和精確查詢的要求。在應用中,NewSQL承擔高價值密度結構化數(shù)據(jù)的存儲和分析處理工作,NoSQL承擔存儲和處理海量非結構化數(shù)據(jù)和不需要關聯(lián)分析、Ad-hoc查詢較少的低價值密度結構化數(shù)據(jù)的工作。
當前電信運營商在集中化BI系統(tǒng)建設過程中面臨著數(shù)據(jù)規(guī)模大、數(shù)據(jù)處理類型多等問題,并且需要應對大量的固定應用,以及占統(tǒng)計總數(shù)80%以上的突發(fā)性臨時統(tǒng)計(ad-hoc)需求。在集中化BI系統(tǒng)的建設中采用NewSQL+NoSQL混搭的模式,充分利用NewSQL在復雜分析、即席查詢等方面處理性能的優(yōu)勢,及NoSQL在非結構化數(shù)據(jù)處理和海量數(shù)據(jù)存儲方面的優(yōu)勢,實現(xiàn)高效低成本。
集中化BI系統(tǒng)數(shù)據(jù)存儲架構
集中化BI系統(tǒng)按照數(shù)據(jù)類型和處理方式的不同,將結構化數(shù)據(jù)和非結構化數(shù)據(jù)分別存儲在不同的系統(tǒng)中:非結構化數(shù)據(jù)在Hadoop平臺上存儲與處理;結構化、不需要關聯(lián)分析、Ad-hoc查詢較少的數(shù)據(jù)保存在NoSQL數(shù)據(jù)庫或Hadoop平臺;結構化、需要關聯(lián)分析或經(jīng)常ad-hoc查詢的數(shù)據(jù),保存在NewSQL MPP數(shù)據(jù)庫中,短期高價值數(shù)據(jù)放在高性能平臺,中長期放在低成本產(chǎn)品中。
結語
當前信息化應用的多樣性、復雜性,以及三種數(shù)據(jù)庫架構各自所具有的優(yōu)勢和局限性,造成任何一種架構的數(shù)據(jù)庫都不能完全滿足應用需求,因此不同架構數(shù)據(jù)庫混合使用,從而彌補其他架構的不足成為必然選擇。根據(jù)應用場景采用不同架構數(shù)據(jù)庫進行組合搭配,充分發(fā)揮每種架構數(shù)據(jù)庫的特點和優(yōu)勢,并且與其他架構數(shù)據(jù)庫形成互補,完全涵蓋應用需求,保證數(shù)據(jù)資源的最優(yōu)化利用,將成為未來一段時期內信息化應用主要采用的解決方式。
目前在國內市場上,OldSQL主要為Oracle、IBM等國外數(shù)據(jù)庫廠商所壟斷,達夢、金倉等國產(chǎn)廠商仍處于追趕狀態(tài);南大通用憑借國產(chǎn)新型數(shù)據(jù)庫GBase 8a異軍突起,與EMC的Greenplum和HP的Vertica躋身NewSQL市場三強;NoSQL方面用戶則大多采用Hadoop開源方案。
您好,對于你的遇到的問題,我很高興能為你提供幫助,我之前也遇到過喲,以下是我的個人看法,希望能幫助到你,若有錯誤,還望見諒!。鍵值對存儲是數(shù)據(jù)庫最簡單的組織形式?;旧先康木幊陶Z言都帶有應用在內存中的鍵值對存儲。C++STL的映射容器(map container)和Java的HashMap以及Python的字典類型都是鍵值對存儲。鍵值對存儲通常都有例如以下接口:
Get( key ): 獲取之前存儲于某標示符“key”之下的一些數(shù)據(jù),或者“key”下沒有數(shù)據(jù)時報錯。
Set( key, value ): 將“value”存儲到存儲空間中某標示符“key”下。使得我們能夠通過調用同樣的“key”來訪問它。
假設“key”下已經(jīng)有了一些數(shù)據(jù),舊的數(shù)據(jù)將被替換。
Delete( key ): 刪除存儲在“key”下的數(shù)據(jù)。
大部分低層實現(xiàn)都是使用哈希表或者某種自平衡樹(比如B-樹或者紅黑樹)。有時候數(shù)據(jù)太大而不裝不進內存,或者必須維持數(shù)據(jù)謹防系統(tǒng)由于未知原因而崩潰。在這些情況下。就必須使用到文件系統(tǒng)。
鍵值對存儲是NoSQL運動的一部分。NoSQL將全部不使用基于關系型數(shù)據(jù)庫概念的數(shù)據(jù)庫系統(tǒng)組合在一起。
維基百科上的NoSQL詞條非常好的總結了這些數(shù)據(jù)庫的特征。
不使用SQL查詢語言
可不全面支持ACID(原子性、一致性、隔離性、持久性)。
可提供分布式、容錯強的結構非常感謝您的耐心觀看,如有幫助請采納,祝生活愉快!謝謝!
1 理解ACID與BASE的區(qū)別(ACID是關系型數(shù)據(jù)庫強一致性的四個要求,而BASE是NoSQL數(shù)據(jù)庫通常對可用性及一致性的弱要求原則,它們的意思分別是,ACID:atomicity, consistency, isolation, durability;BASE:Basically Available, Soft-state, Eventually Consistent。同時有意思的是ACID在英語里意為酸,BASE意思為堿)
2 理解持久化與非持久化的區(qū)別。這么說是因為有的NoSQL系統(tǒng)是純內存存儲的。
3 你必須意識到傳統(tǒng)有關系型數(shù)據(jù)庫與NoSQL系統(tǒng)在數(shù)據(jù)結構上的本質區(qū)別。傳統(tǒng)關系型數(shù)據(jù)庫通常是基于行的表格型存儲,而NoSQL系統(tǒng)包括了列式存儲(Cassandra)、key/value存儲(Memcached)、文檔型存儲(CouchDB)以及圖結構存儲(Neo4j)
4與傳統(tǒng)關系數(shù)據(jù)庫有統(tǒng)一的SQL語言操作接口不同,NoSQL系統(tǒng)通常有自己特有的API接口。
5 在架構上,你必須搞清楚,NoSQL系統(tǒng)是被設計用于成百上千臺機器的集群中的,而非共享型數(shù)據(jù)庫系統(tǒng)的架構。
6在NoSQL系統(tǒng)中,可能你得習慣一下不知道你的數(shù)據(jù)具體存在何處的情況。
7 在NoSQL系統(tǒng)中,你最好習慣它的弱一致性。”eventually consistent”(最終一致性)正是BASE原則中的重要一項。比如在Twitter,你在Followers列表中經(jīng)常會感受到數(shù)據(jù)的延遲。
8 在NoSQL系統(tǒng)中,你要理解,很多時候數(shù)據(jù)并不總是可用的。
9 你得理解,有的方案是擁有分區(qū)容忍性的,有的方案不一定有。
分享名稱:nosql支持acid嗎,nosql類型
網(wǎng)頁網(wǎng)址:http://aaarwkj.com/article16/dsshcgg.html
成都網(wǎng)站建設公司_創(chuàng)新互聯(lián),為您提供標簽優(yōu)化、網(wǎng)站收錄、網(wǎng)頁設計公司、響應式網(wǎng)站、ChatGPT、商城網(wǎng)站
聲明:本網(wǎng)站發(fā)布的內容(圖片、視頻和文字)以用戶投稿、用戶轉載內容為主,如果涉及侵權請盡快告知,我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場,如需處理請聯(lián)系客服。電話:028-86922220;郵箱:631063699@qq.com。內容未經(jīng)允許不得轉載,或轉載時需注明來源: 創(chuàng)新互聯(lián)