狠狠色丁香婷婷综合尤物/久久精品综合一区二区三区/中国有色金属学报/国产日韩欧美在线观看 - 国产一区二区三区四区五区tv

LOGO OA教程 ERP教程 模切知識(shí)交流 PMS教程 CRM教程 開(kāi)發(fā)文檔 其他文檔  
 
網(wǎng)站管理員

如何使用分庫(kù)分表支持海量數(shù)據(jù)的寫(xiě)入

admin
2024年1月24日 23:1 本文熱度 1616

本講將要介紹如何存儲(chǔ)這些海量數(shù)據(jù),同時(shí)保證相對(duì)應(yīng)的寫(xiě)入和查詢的性能,以及業(yè)務(wù)流程不發(fā)生太大變化。

不管是打車的訂單、電商里的支付訂單,還是外賣(mài)或團(tuán)購(gòu)的支付訂單,都是后臺(tái)服務(wù)中最重要的一環(huán),關(guān)乎公司的營(yíng)收。因此,本講及本模塊都將以 訂單業(yè)務(wù) 作為案例進(jìn)行分析。

是否真的要分庫(kù)?

分庫(kù)當(dāng)然能夠解決存儲(chǔ)的問(wèn)題,假設(shè)原先單庫(kù)只能最多存儲(chǔ) 2 千萬(wàn)的數(shù)據(jù)量。采用分庫(kù)之后,存儲(chǔ)架構(gòu)變成下圖 1 所示的分庫(kù)架構(gòu),每個(gè)分庫(kù)都可以存儲(chǔ) 2 千萬(wàn)數(shù)據(jù)量,容量的上限一下提升了。


圖 1:分庫(kù)架構(gòu)圖

容量提升了,但也帶來(lái)了很多其他問(wèn)題。比如:

  1. 1. 分庫(kù)數(shù)據(jù)間的數(shù)據(jù)無(wú)法再通過(guò)數(shù)據(jù)庫(kù)直接查詢了。比如跨多個(gè)分庫(kù)的數(shù)據(jù)需要多次查詢或借助其他存儲(chǔ)進(jìn)行聚合再查詢。

  2. 2. 分庫(kù)越多,出現(xiàn)問(wèn)題的可能性越大,維護(hù)成本也變得更高。

  3. 3. 無(wú)法保障跨庫(kù)間事務(wù),只能借助其他中間件實(shí)現(xiàn)最終一致性。

所以在解決容量問(wèn)題上,可以根據(jù)業(yè)務(wù)場(chǎng)景選擇,不要一上來(lái)就要考慮分庫(kù),分表也是一種選擇。

分表是指所有的數(shù)據(jù)均存在同一個(gè)數(shù)據(jù)庫(kù)實(shí)例中,只是將原先的一張大表按一定規(guī)則,劃分成多張行數(shù)較少的表。它與分庫(kù)的區(qū)別是,分表后的子表仍在原有庫(kù)中,而分庫(kù)則是子表移動(dòng)到新的數(shù)據(jù)庫(kù)實(shí)例里并在物理上單獨(dú)部署。分表的拆分架構(gòu)如下圖 2 所示:


圖 2:分表架構(gòu)圖

以本模塊的訂單案例來(lái)說(shuō),假設(shè)訂單只是 單量多而每一單的數(shù)據(jù)量較小,這就適合采用分表。單條數(shù)據(jù)量小但行數(shù)多,會(huì)導(dǎo)致寫(xiě)入(因?yàn)橐獦?gòu)建索引)和查詢非常慢,但整體對(duì)于容量的占用是可控的。采用分表后,大表變成小表,寫(xiě)入時(shí)構(gòu)建索引的性能消耗會(huì)變小,其次小表的查詢性能也更好。如果采用了分庫(kù),雖然解決了寫(xiě)入和查詢的問(wèn)題,但每張表所占有的磁盤(pán)空間很少,也會(huì)產(chǎn)生資源浪費(fèi)。兩種方案的對(duì)比如下圖 3 所示:

圖 3:?jiǎn)伪硇袛?shù)多單數(shù)據(jù)量小的對(duì)比圖

在實(shí)際場(chǎng)景里,因?yàn)橐敿?xì)記錄用戶的提單信息,單個(gè)訂單記錄的數(shù)據(jù)量均較多,所以不存在行數(shù)多但單條數(shù)據(jù)量小的情況。但在其他寫(xiě)入服務(wù)里,經(jīng)常會(huì)出現(xiàn)上述場(chǎng)景,你可以優(yōu)先采用分表的方案。因?yàn)?分表除了能解決容量問(wèn)題,還能在一定程度上解決分庫(kù)所帶來(lái)的三個(gè)問(wèn)題。

  1. 1. 分表后可以通過(guò) join 等完成一些富查詢,相比分庫(kù)簡(jiǎn)單得多。

  2. 2. 分表的數(shù)據(jù)仍存儲(chǔ)在一個(gè)數(shù)據(jù)庫(kù)里,不會(huì)出現(xiàn)很多分庫(kù)。無(wú)須引入一些分庫(kù)中間件,因此維護(hù)成本和開(kāi)發(fā)成本均較低。

  3. 3. 因?yàn)樵谕粋€(gè)數(shù)據(jù)庫(kù)里,也可以很好地解決事務(wù)問(wèn)題。

接下來(lái)將介紹如何應(yīng)對(duì)行數(shù)多且單行數(shù)據(jù)量較大的場(chǎng)景。通過(guò)我們前面的分析,我想你已經(jīng)知道答案了——采用分庫(kù)的方案。

如何實(shí)現(xiàn)分庫(kù)?

在決定對(duì)數(shù)據(jù)庫(kù)進(jìn)行分庫(kù)后,首先要解決的問(wèn)題便是 如何選擇分庫(kù)維度。不同的分庫(kù)維度 決定了部分查詢是否能直接使用數(shù)據(jù)庫(kù),以及是否存在數(shù)據(jù)傾斜的問(wèn)題。

分庫(kù)維度選擇

下面以訂單為案例,介紹兩種常見(jiàn)不同維度的分庫(kù)方式:按 直接滿足最重要的業(yè)務(wù)場(chǎng)景劃分和最細(xì)粒度隨機(jī)分。

首先我們來(lái)看按 直接滿足最重要的業(yè)務(wù)場(chǎng)景劃分。在業(yè)務(wù)上,所有的訂單數(shù)據(jù)都是隸屬于某一個(gè)用戶的。在選擇分庫(kù)維度時(shí),可以按訂單歸屬的用戶 這個(gè)字段進(jìn)行分庫(kù)。按此維度分庫(kù)后,同一個(gè)用戶的訂單都在某一個(gè)分庫(kù)里。分庫(kù)后的場(chǎng)景如下圖 4 所示:


圖 4:按購(gòu)買(mǎi)用戶進(jìn)行分庫(kù)的架構(gòu)圖

訂單模塊除了提供提交訂單接口外,還會(huì)提供給售賣(mài)商家對(duì)自己店鋪的訂單進(jìn)行查詢及修改等功能。這些維度的查詢和修改需求,在采用了按購(gòu)買(mǎi)用戶進(jìn)行分庫(kù)之后,均無(wú)法直接滿足了。

這里請(qǐng)你思考一個(gè)問(wèn)題, 訂單模塊最重要的功能是什么?

答案是保證客戶(即買(mǎi)家)的各項(xiàng)訂單功能能夠正常使用,比如下單、下單后立刻(無(wú)延遲)查看已購(gòu)的訂單信息、待支付、待發(fā)貨、待配送的訂單列表等。相對(duì)來(lái)說(shuō),訂單里的商品售賣(mài)方(即賣(mài)家)所使用的功能并不是優(yōu)先級(jí)最高的。因?yàn)楫?dāng)我們要對(duì)賣(mài)家和買(mǎi)家的功能做取舍時(shí),賣(mài)家是愿意降低優(yōu)先級(jí)的,畢竟賣(mài)家是買(mǎi)賣(mài)的受益方。

按購(gòu)買(mǎi)用戶劃分后,用戶的使用場(chǎng)景都可以直接通過(guò)分庫(kù)支持,而不需要通過(guò)異構(gòu)數(shù)據(jù)(存在數(shù)據(jù)延遲)等手段解決,對(duì)用戶來(lái)說(shuō)體驗(yàn)較好。其次,在同一個(gè)分庫(kù)中,便于修改同一用戶的多條數(shù)據(jù),因此也不存在分布式事務(wù)問(wèn)題。

我們可以通過(guò)上述訂單案例抽象出一個(gè)分庫(kù)準(zhǔn)則,即 在確定分庫(kù)字段時(shí)應(yīng)該以直接滿足最重要的業(yè)務(wù)場(chǎng)景為準(zhǔn)。很多其他的業(yè)務(wù)都參考了這一準(zhǔn)則,比如:

  1. 1. 對(duì)于微博和知乎等用戶生產(chǎn)內(nèi)容(UGC)的業(yè)務(wù),均會(huì)按用戶進(jìn)行分庫(kù)。因?yàn)橛脩粜掳l(fā)布文章后就會(huì)去查看列表。

  2. 2. 支付系統(tǒng)里,也會(huì)按用戶的支付記錄進(jìn)行分庫(kù)。

  3. 3. 在技術(shù)上,比如一個(gè)微服務(wù)下的監(jiān)控?cái)?shù)據(jù),同樣會(huì)按微服務(wù)進(jìn)行劃分。同一個(gè)微服務(wù)的監(jiān)控?cái)?shù)據(jù)均存儲(chǔ)在一個(gè)分庫(kù)里,你可以直接在一個(gè)分庫(kù)里查看微服務(wù)下的所有監(jiān)控?cái)?shù)據(jù)。

上述劃分方法雖然直接滿足了最重要的場(chǎng)景,但可能會(huì)出現(xiàn)數(shù)據(jù)傾斜的問(wèn)題,比如出現(xiàn)一個(gè)超級(jí)客戶(如企業(yè)客戶),購(gòu)買(mǎi)的訂單量非常大,導(dǎo)致某一個(gè)分庫(kù)數(shù)據(jù)量巨多,就會(huì)重現(xiàn)分庫(kù)前的場(chǎng)景。這屬于最極端的情況之一。

對(duì)于傾斜的問(wèn)題,可以采用 最細(xì)粒度的拆分,即按數(shù)據(jù)的唯一標(biāo)示進(jìn)行拆分,對(duì)于訂單來(lái)說(shuō)唯一標(biāo)示即為訂單號(hào)。采用訂單號(hào)進(jìn)行分庫(kù)之后,用戶的訂單會(huì)按 Hash 隨機(jī)均勻地分散到某一個(gè)分庫(kù)里。這樣就解決了某一個(gè)分庫(kù)數(shù)據(jù)不均勻的問(wèn)題。

對(duì)于上個(gè)小節(jié)里的案例,也可以用此手段進(jìn)行處理。比如:

  1. 1. 按用戶的每一條微博隨機(jī)分庫(kù);

  2. 2. 按用戶的每一筆支付記錄隨機(jī)分庫(kù);

  3. 3. 同一個(gè)微服務(wù)里的每一個(gè)監(jiān)控點(diǎn)的數(shù)據(jù)隨機(jī)分庫(kù)。

采用最細(xì)粒度分庫(kù)后,雖然解決了數(shù)據(jù)均衡的問(wèn)題,但又帶來(lái)了其他問(wèn)題。

  1. 1. 首先便是除了細(xì)粒度查詢外,其他任何維度的查詢均不支持。這就需要通過(guò)異構(gòu)等方式解決,但異構(gòu)有延遲、對(duì)業(yè)務(wù)是有損的。

  2. 2. 其次采用最細(xì)粒度后,對(duì)于防重邏輯在數(shù)據(jù)庫(kù)層面已經(jīng)無(wú)法支持。比如用戶對(duì)同一個(gè)訂單在業(yè)務(wù)上只能支付一次這一訴求,在支付系統(tǒng)按支付號(hào)進(jìn)行分庫(kù)后便不能直接滿足了。因?yàn)樯鲜龇謳?kù)方式會(huì)導(dǎo)致不同支付單分散在不同的分庫(kù)里,此時(shí),期望在數(shù)據(jù)庫(kù)中通過(guò)訂單號(hào)的唯一索引進(jìn)行支付防重就不可實(shí)施了。

上述兩種分庫(kù)的方式,在解決問(wèn)題的同時(shí)又帶來(lái)一些新的問(wèn)題。在架構(gòu)中,沒(méi)有一種方案可以解決所有問(wèn)題的,更多的是根據(jù)場(chǎng)景去選擇更適合自己的方案。

全局唯一標(biāo)示

不管采用何種維度的分庫(kù)方式,使用原有單庫(kù)的數(shù)據(jù)庫(kù)自增主鍵生產(chǎn)數(shù)據(jù)標(biāo)示的方案已經(jīng)不可以使用了。對(duì)于全局的數(shù)據(jù)唯一標(biāo)示,有兩種常見(jiàn)的生成方式。

1. 使用算法隨機(jī)生成。

比如使用機(jī)器 IP、時(shí)間戳、隨機(jī)數(shù)等進(jìn)行組合,生成一個(gè)唯一編號(hào)。業(yè)界成熟的有 Twitter 推出的雪花算法。需要注意的是,為了保證唯一性,雪花算法增加了很多隨機(jī)因子,導(dǎo)致計(jì)算出來(lái)的唯一標(biāo)示特別長(zhǎng),達(dá)到 19 位。

在 JavaScript 里,數(shù)據(jù)精度和 Java 等語(yǔ)言不完全一致,太長(zhǎng)的雪花 ID 在前端存在溢出的問(wèn)題。因?yàn)檠┗ㄋ惴ㄉ傻?ID 為 Long 類型,可以采用類似 Base64 等算法,對(duì)原始 ID 進(jìn)行壓縮轉(zhuǎn)換為 String 類型,降低長(zhǎng)度并避免和 JavaScript 精度不統(tǒng)一導(dǎo)致的問(wèn)題。

2. 基于數(shù)據(jù)庫(kù)主鍵構(gòu)建一個(gè) ID 生成服務(wù)。

雖然不能在插入的時(shí)候使用數(shù)據(jù)庫(kù)唯一主鍵,但可以在插入前通過(guò)一個(gè)服務(wù)獲取全局唯一的 ID。ID 生產(chǎn)服務(wù)可以基于一張單表實(shí)現(xiàn),每一次外部請(qǐng)求時(shí),均生產(chǎn)一個(gè)新的 ID。通過(guò)此方式,可以獲得長(zhǎng)度較短且為數(shù)值類型的全局唯一編號(hào)。

但如果每次獲取 ID 時(shí),ID 生成服務(wù)都需要從數(shù)據(jù)庫(kù)實(shí)時(shí)獲取,性能會(huì)比較差。為了解決性能問(wèn)題,可以在生成 ID 的數(shù)據(jù)庫(kù)前置一個(gè)具備持久化功能的內(nèi)存緩存,預(yù)生成一批 ID。具體架構(gòu)如下圖 5 所示:

圖 5:預(yù)生成 ID 架構(gòu)圖

分庫(kù)中間件選擇

現(xiàn)在開(kāi)源提供分庫(kù)支持的中間件較多,如 MyCat 等, 整體上各類分庫(kù)中間件可以分為兩大類:一種是代理式、另外一種是內(nèi)嵌式。

代理式分庫(kù)中間件 對(duì)于業(yè)務(wù)應(yīng)用無(wú)任何侵入,業(yè)務(wù)應(yīng)用和未分庫(kù)時(shí)一樣使用數(shù)據(jù)庫(kù),分庫(kù)的選擇及分庫(kù)的維度對(duì)業(yè)務(wù)層完全隱藏,接入和使用成本極低。代理式的架構(gòu)如下圖 6 所示:

圖 6:代理式分庫(kù)架構(gòu)圖

代理式雖有使用成本低的好處,但也存在其他一些問(wèn)題。

  1. 1. 代理式在業(yè)務(wù)應(yīng)用和數(shù)據(jù)庫(kù)間增加了一層,導(dǎo)致了性能下降。

  2. 2. 代理式需要解析業(yè)務(wù)應(yīng)用的 SQL,并根據(jù) SQL 中的分庫(kù)字段進(jìn)行路由。它需要解析和適配所有 SQL 語(yǔ)法,增加了代理模塊復(fù)雜度和出錯(cuò)的可能性。

  3. 3. 代理層是單獨(dú)進(jìn)程,需要部署占用資源,帶來(lái)一定的成本。

內(nèi)嵌式分庫(kù)中間件 是將分庫(kù)中間件內(nèi)置在業(yè)務(wù)應(yīng)用中,它只負(fù)責(zé)分庫(kù)的選擇,并不會(huì)解析用戶的 SQL。在使用時(shí),業(yè)務(wù)應(yīng)用需將分庫(kù)字段傳遞給內(nèi)嵌中間件去計(jì)算具體對(duì)應(yīng)的分庫(kù)。它相比代理式性能更好。內(nèi)嵌式的架構(gòu)如下圖 7 所示:


圖 7:內(nèi)嵌式的分庫(kù)架構(gòu)圖

除了性能優(yōu)勢(shì)外,內(nèi)嵌式同樣存在問(wèn)題。

  1. 1. 有一定侵入性,業(yè)務(wù)應(yīng)用與原始單庫(kù)模式相比,需要進(jìn)行一定的改造去適配內(nèi)嵌式的 API。

  2. 2. 分庫(kù)在故障轉(zhuǎn)移、數(shù)據(jù)遷移等運(yùn)維工作時(shí),需要業(yè)務(wù)應(yīng)用感知。不過(guò)現(xiàn)在的一些內(nèi)嵌式代理,已經(jīng)具備非常良好的配置功能,在分庫(kù)運(yùn)維時(shí),業(yè)務(wù)應(yīng)用需要配合的內(nèi)容較少。

其他問(wèn)題

接下來(lái),再來(lái)看幾個(gè)常見(jiàn)問(wèn)題的應(yīng)對(duì)策略。

1. 是否一定需要進(jìn)行分表或者分庫(kù)呢?

不一定。雖然很多互聯(lián)網(wǎng)公司的體量很大,用戶非常多,但你千萬(wàn)不要被這些現(xiàn)象迷惑了。實(shí)際上,90% 以上的系統(tǒng)能夠發(fā)展到上百萬(wàn)、上千萬(wàn)數(shù)據(jù)量已經(jīng)很不錯(cuò)了。對(duì)于千萬(wàn)的數(shù)據(jù)量,開(kāi)源的 MySQL 都可以很好地應(yīng)對(duì),更別說(shuō)一些商業(yè)數(shù)據(jù)庫(kù)了。

另外,當(dāng)數(shù)據(jù)增長(zhǎng)到一定量級(jí)后,可以在業(yè)務(wù)層面做一些處理。比如根據(jù)業(yè)務(wù)特點(diǎn),對(duì)無(wú)效數(shù)據(jù)、軟刪除數(shù)據(jù),以及業(yè)務(wù)上不會(huì)再查詢的數(shù)據(jù)進(jìn)行統(tǒng)一歸檔,這也是一個(gè)成本低、效果明顯的方式了。

2. 使用業(yè)務(wù)字段分庫(kù)后,如何處理數(shù)據(jù)傾斜?

如果數(shù)據(jù)量不是特別大,可以在分庫(kù)基礎(chǔ)上,再進(jìn)行分表。針對(duì)數(shù)據(jù)量較大的場(chǎng)景,可以使用二次分庫(kù)的方式。對(duì)于訂單量較多的用戶,可以在用戶賬號(hào)基礎(chǔ)上再增加一個(gè)字段,做進(jìn)一步的分庫(kù),但此用戶的查詢就會(huì)有損了。

此外,還有另外兩個(gè)問(wèn)題,由于需要用到暫未講解的知識(shí),所以我將放在后面的章節(jié)結(jié)合相關(guān)知識(shí)詳細(xì)講解,今天僅做提及。

3. 如何滿足富查詢?

富查詢是一個(gè)無(wú)法回避的問(wèn)題,即采用分庫(kù)分表之后,如何滿足跨越分庫(kù)的查詢?對(duì)于此問(wèn)題,我將在“ 第 11 講”進(jìn)行詳細(xì)講解。

4. 如何解決跨多庫(kù)的修改導(dǎo)致的分布式事務(wù)?

跨多庫(kù)的修改及多個(gè)微服務(wù)間的寫(xiě)操作導(dǎo)致的分布式事務(wù)問(wèn)題,我將在“ 第 19 講”里集中講解。

總結(jié)

不斷進(jìn)行分庫(kù)分表一定能解決容量問(wèn)題,但“殺敵一千,自損八百”的事情少做為宜。使用分庫(kù)分表會(huì)將代碼和架構(gòu)的復(fù)雜度變高,帶來(lái)資源成本上升等問(wèn)題。另外,在使用系統(tǒng)時(shí),用戶(不管是客戶還是管理員)的查詢體驗(yàn)也存在一定的降級(jí)。

在使用分庫(kù)分表前,你需要確定這是否是最優(yōu)選擇,是否能通過(guò)其他更簡(jiǎn)單的手段處理無(wú)效數(shù)據(jù)清理?架構(gòu)是通過(guò)最小代價(jià)解決問(wèn)題,而不是技術(shù)工具的比拼。

最后,我再給你留一道討論題,你知道的分庫(kù)分表的問(wèn)題還有哪些或者上述問(wèn)題你還有哪些解決方案?


該文章在 2024/1/24 23:01:01 編輯過(guò)
關(guān)鍵字查詢
相關(guān)文章
正在查詢...
點(diǎn)晴ERP是一款針對(duì)中小制造業(yè)的專業(yè)生產(chǎn)管理軟件系統(tǒng),系統(tǒng)成熟度和易用性得到了國(guó)內(nèi)大量中小企業(yè)的青睞。
點(diǎn)晴PMS碼頭管理系統(tǒng)主要針對(duì)港口碼頭集裝箱與散貨日常運(yùn)作、調(diào)度、堆場(chǎng)、車隊(duì)、財(cái)務(wù)費(fèi)用、相關(guān)報(bào)表等業(yè)務(wù)管理,結(jié)合碼頭的業(yè)務(wù)特點(diǎn),圍繞調(diào)度、堆場(chǎng)作業(yè)而開(kāi)發(fā)的。集技術(shù)的先進(jìn)性、管理的有效性于一體,是物流碼頭及其他港口類企業(yè)的高效ERP管理信息系統(tǒng)。
點(diǎn)晴WMS倉(cāng)儲(chǔ)管理系統(tǒng)提供了貨物產(chǎn)品管理,銷售管理,采購(gòu)管理,倉(cāng)儲(chǔ)管理,倉(cāng)庫(kù)管理,保質(zhì)期管理,貨位管理,庫(kù)位管理,生產(chǎn)管理,WMS管理系統(tǒng),標(biāo)簽打印,條形碼,二維碼管理,批號(hào)管理軟件。
點(diǎn)晴免費(fèi)OA是一款軟件和通用服務(wù)都免費(fèi),不限功能、不限時(shí)間、不限用戶的免費(fèi)OA協(xié)同辦公管理系統(tǒng)。
Copyright 2010-2025 ClickSun All Rights Reserved