數(shù)據(jù)庫本身功能非常單一,僅可作為數(shù)據(jù)的存儲(chǔ)介質(zhì),但錯(cuò)誤的數(shù)據(jù)庫選型帶來的代價(jià)可能就是項(xiàng)目
性能的大幅下降,對(duì)于很多企業(yè)應(yīng)用來說這也是致命的傷害,另外,選擇不同數(shù)據(jù)庫類型同樣會(huì)決定系統(tǒng)中其他模塊的設(shè)計(jì),因此,數(shù)據(jù)庫選型對(duì)于整個(gè)項(xiàng)目非常重要,我們通常也稱這種需求為
非功能性需求(NFRs,non-functional requirements),對(duì)于數(shù)據(jù)庫,主要需要考慮如下三點(diǎn)因素:
- 數(shù)據(jù)結(jié)構(gòu)
- 查詢模式
- 數(shù)據(jù)規(guī)模
目前,市面上已經(jīng)有各類存儲(chǔ)解決方案了,本文我們就來討論一下如何在這些方案中選擇最適合自己的方案。
緩存
如果項(xiàng)目需要
頻繁調(diào)用數(shù)據(jù)庫 API 或者一些高延遲的遠(yuǎn)程服務(wù),那么可能需要最先考慮在客戶端和數(shù)據(jù)庫之間使用緩存來降低延遲。目前,常用的緩存方案有 Memcached,Hazelcast,Redis,這些方案大同小異,但 Redis 使用最廣泛且穩(wěn)定,是目前國(guó)內(nèi)最常用的數(shù)據(jù)庫緩存解決方案。
文件存儲(chǔ)
如果需要開發(fā)一款抖音、B 站之類的產(chǎn)品,就
需要存儲(chǔ)大量圖像、視頻等數(shù)據(jù),僅僅一個(gè)數(shù)據(jù)庫可能并不能滿足我們的需求,因?yàn)檫@時(shí)需要存儲(chǔ)的是文件而非一般的數(shù)據(jù)信息,數(shù)據(jù)庫本質(zhì)依然只能用來查詢信息數(shù)據(jù)而已,而文件本身也并不用“查詢”,只需要按需拿到這整個(gè)文件即可,這種情況下,符合項(xiàng)目要求的解決方案就是
對(duì)象(Blob)存儲(chǔ)方案,如 Amazon S3,通常,Blob 存儲(chǔ)方案還可以與 CDN 結(jié)合使用來減少延遲,這樣就可以實(shí)現(xiàn)無地理位置差異提供內(nèi)容服務(wù)。
提供文本搜索功能
淘寶、京東這些大型應(yīng)用都會(huì)提供內(nèi)容的搜索功能,這樣就可以方便用戶按照商品類型、品牌對(duì)數(shù)據(jù)進(jìn)行分類搜索,這種功能通常會(huì)使用
Solr 或
Elasticsearch 之類的搜索引擎服務(wù),這類搜索服務(wù)通常也會(huì)支持
模糊搜索,例如會(huì)考慮到用戶拼寫錯(cuò)誤的情況,這會(huì)很大程度上提升用戶體驗(yàn)。但是,搜索引擎不是是數(shù)據(jù)庫,并不能保證我們的數(shù)據(jù)不會(huì)丟失,因此我們不能使用 Elasticsearch 這類搜索引擎作為數(shù)據(jù)源,這里就需要我們配合兩者使用,將數(shù)據(jù)庫中的內(nèi)容加載到 Elasticsearch 中來降低搜索延遲,然后在以此為基礎(chǔ)提供搜索功能。
時(shí)序數(shù)據(jù)庫(TSDB,Time series database)
時(shí)序數(shù)據(jù)庫全稱為時(shí)間序列數(shù)據(jù)庫(Time series database),是關(guān)系型數(shù)據(jù)庫的一種,
主要用于處理帶時(shí)間標(biāo)簽(按照時(shí)間的順序變化,即時(shí)間序列化)的數(shù)據(jù),帶時(shí)間標(biāo)簽的數(shù)據(jù)也稱為時(shí)間序列數(shù)據(jù)。如果我們要開發(fā)的系統(tǒng)對(duì)時(shí)間特別敏感,如股票交易、財(cái)務(wù)分析系統(tǒng),此時(shí)就需要經(jīng)常對(duì)一定時(shí)間的內(nèi)數(shù)據(jù)分析,如過去 1周,10天,1個(gè)月,1 年等等,TSDB 會(huì)以毫秒級(jí)的速度給出這些我們需要的數(shù)據(jù),傳統(tǒng)數(shù)據(jù)庫很難做到這一點(diǎn)。
目前,市面上常用的時(shí)序數(shù)據(jù)庫有
OpenTSDB、InfluxDB 等。
數(shù)據(jù)倉庫
很多項(xiàng)目也會(huì)需要一類能夠
存儲(chǔ)巨量數(shù)據(jù)的數(shù)據(jù)庫,如滴滴需要存儲(chǔ)所有訂單信息來分析哪個(gè)城市、那個(gè)時(shí)間段為使用率最高,這些系統(tǒng)通常和常規(guī)用戶可感知的交易不同,可以使用脫機(jī)類型的數(shù)據(jù)倉庫。
Hadoop 是目前主流的數(shù)據(jù)倉庫解決方案。
如文章開頭所述,數(shù)據(jù)結(jié)構(gòu)是我們用來做數(shù)據(jù)庫選型時(shí)的重要因素之一,如果我們要存儲(chǔ)結(jié)構(gòu)化或者可以表格形式表示的數(shù)據(jù),則可以使用關(guān)系型數(shù)據(jù)庫。
同時(shí),我們還將考慮數(shù)據(jù)庫是否需要擁有
ACID 性質(zhì),即原子性(Atomicity),一致性(Consistency),隔離型(Isolation),持久性(Durability)四大性質(zhì)。
- 原子性,保證所有操作要么全有要么全無。
- 一致性,保證操作前后數(shù)據(jù)庫狀態(tài)一致。
- 隔離性,意味著多個(gè)事務(wù)單獨(dú)進(jìn)行,一個(gè)事務(wù)將不受另一正在進(jìn)行的并行事務(wù)的影響。這能保證數(shù)據(jù)庫應(yīng)該能夠處理并發(fā)事務(wù)而不會(huì)導(dǎo)致數(shù)據(jù)不一致的情況。
- 持久性,保證一旦事務(wù)完成,更改將被永久寫入磁盤,并且不會(huì)因系統(tǒng)故障而丟失。
如果我們的項(xiàng)目需要 ACID,則需要使用關(guān)系數(shù)據(jù)庫(RDBMS),如 MySQL,Oracle,Postgres 等,但是,如果不需要 ACID,那么也可以
非關(guān)系性數(shù)據(jù)庫。例如,項(xiàng)目中需要為商品建立目錄索引,每個(gè)商品通常會(huì)有不同的屬性和信息,如藥品有保質(zhì)期,冰箱有節(jié)能等級(jí)等等,再例如我們的用戶表單中每位用戶也可能會(huì)有不同的屬性值,在這種情況下我們的數(shù)據(jù)就不能夠以表格形式表示,可以選擇使用
NoSQL 數(shù)據(jù)庫。
另外,除了儲(chǔ)存,我們通常還需要查詢這些類型的得到數(shù)據(jù),這就需要考慮
查詢模式這個(gè)要素,我們會(huì)根據(jù)存儲(chǔ)的數(shù)據(jù)類型和查詢類型來決定最終使用哪種數(shù)據(jù)庫。如果項(xiàng)目中會(huì)含有大量數(shù)據(jù),包括各種各樣的屬性和各種各種的查詢請(qǐng)求,就需要使用文檔型數(shù)據(jù)庫(
Document DB),如
Couchbase、MongoDB。
Elasticsearch 和 Solr 也是特殊文檔型數(shù)據(jù)庫。
如果我們的數(shù)據(jù)并沒有各種各樣的屬性,查詢類型也很有限,簡(jiǎn)單增刪改查足以,但是數(shù)據(jù)庫的存儲(chǔ)量很大,如滴滴司機(jī)的位置,這類數(shù)據(jù)每時(shí)每刻都會(huì)增加,這種情況下,我們通常會(huì)使用柱狀存儲(chǔ)模型的數(shù)據(jù)庫,也稱
列型(Columnar DBs)數(shù)據(jù)庫,如
Cassandra、HBase。這類數(shù)據(jù)庫每個(gè)列都有一個(gè) column key 標(biāo)識(shí),每個(gè) column key下對(duì)應(yīng)若干 value,可以很輕松的獲得包含某個(gè)列的數(shù)據(jù)。
在個(gè)人的小型項(xiàng)目我們通常會(huì)選擇 Cassandra,因?yàn)榉浅]p量而且部署起來非常方便,性能也完全不亞于 HBase,而 HBase 基于 Hadoop 顯得過于臃腫。因此,我們可以說在數(shù)據(jù)查詢時(shí)可以直接通過 where 語句指定 key 查詢時(shí),可以選擇 Cassandra。如果我們將滴滴中與打車相關(guān)的訂單數(shù)據(jù)存儲(chǔ)在 Cassandra 后,司機(jī)的 id 可以作為每個(gè)列分區(qū)的 column key,當(dāng)我們想要查詢特定時(shí)間段內(nèi)該司機(jī)的路程,Cassandra 就可以立即幫我們?cè)趯?duì)應(yīng)列中查詢到這些數(shù)據(jù),但這時(shí),當(dāng)我們想要查詢某個(gè)日期內(nèi)乘客的乘車記錄,由于客戶 ID 并不是分區(qū) column key,因此 Cassandra 就需要查詢整個(gè)分區(qū),這時(shí) Cassandra 性能就會(huì)大打折扣!這種情況下,我們可以使用不同的分區(qū) key 將相同的數(shù)據(jù)復(fù)制到另一個(gè)表或列中,這時(shí),當(dāng)我們收到有關(guān)客戶 ID 和日期的查詢時(shí),我們可以將其直接定向到分區(qū) kay 為客戶 ID 的表中,這就是
查詢的種類少但數(shù)據(jù)量大的意思,只要查詢的類型相似,Cassandra(和 HBase)就可以無限擴(kuò)展,但如果查詢的種類非常多的話,我們就必須為每個(gè)分區(qū) key 一次又一次地復(fù)制,直到達(dá)到一定的限制。如果我們不能控制查詢的類型,還是選擇采用 MongoDB 之類的方案,但是,如果我們只需要針對(duì)少數(shù)幾種查詢的大規(guī)模擴(kuò)展,那么 Cassandra 就是完美的解決方案。
現(xiàn)在,我們大概知道了基本的方向了,如果存儲(chǔ)結(jié)構(gòu)化數(shù)據(jù)并且需要 ACID 性質(zhì),則使用關(guān)系數(shù)據(jù)庫(如 MySQL),如果存儲(chǔ)具有許多屬性的海量數(shù)據(jù),則可以使用文檔數(shù)據(jù)庫(如 Mongo DB),如果數(shù)據(jù)非常簡(jiǎn)單,查詢種類較少,則使用列式數(shù)據(jù)庫(如 Cassandra),但是實(shí)際項(xiàng)目中,還并不這么簡(jiǎn)單。
混合使用
我們?cè)僖蕴詫殲槔瑢?duì)于一個(gè)商品來說,庫存中只有一件,但是很多用戶想要買,那么最終應(yīng)該只能賣給一個(gè)用戶,這就需要我們的數(shù)據(jù)庫擁有 ACID 性質(zhì),因此,需要 MySql 這類關(guān)系型數(shù)據(jù)庫,但是淘寶中的商品數(shù)據(jù)也在不斷增加,屬性也多種多樣,我們也需要使用 Cassandra 這種列存儲(chǔ)模型的
NoSQL 數(shù)據(jù)庫。我們應(yīng)該選擇哪一種?在實(shí)際項(xiàng)目中,我們通常會(huì)混合使用這兩種數(shù)據(jù)庫,例如,將尚未交付的訂單數(shù)據(jù)存儲(chǔ)在 MySQL 數(shù)據(jù)庫中,一旦訂單完成,我們就可以將其移至 Cassandra 進(jìn)行永久存儲(chǔ)。我們的需求還會(huì)變得更復(fù)雜,假如我們需要為購買商品的客戶構(gòu)建一個(gè)報(bào)告系統(tǒng),淘寶上的商品通常會(huì)由不同品牌、不同版本向不同的客戶出售,因此,報(bào)告也不能針對(duì)單個(gè)產(chǎn)品,而應(yīng)針對(duì)產(chǎn)品的子集,這類需求可以使用 Cassandra 或 MySQL 實(shí)現(xiàn),但是更好的方案是使用 Mongo DB 這類文檔型
數(shù)據(jù)庫,我們可以將訂單數(shù)據(jù)的子集保存在 MongoDB 中,這些數(shù)據(jù)可以告訴我們哪些用戶在什么時(shí)候,什么日期購買了某種商品的數(shù)量。因此,如果我們要查詢有多少人在上個(gè)月購買了 MacBook,我們可以從 MongoDB 中獲得訂單 ID,并使用此訂單 ID 來從 Cassandra 或 MySQL 中查詢其他的數(shù)據(jù)。