海量儲存系列之三

2021-09-25 07:16:45 字數 2044 閱讀 5122

2023年11月26日 20:05

首先是回答上次的問題。

假設有這麼一組資料,性別有4種,user_id是一對多的關係,如果我想查詢

select * from tabwhere user_id in (?,?,?,?) and 性別='不明'

如何進行索引構建能夠獲得比較好的效果呢?

我個人認為,應該建立的是以user_id作為前導列,性別作為輔助列的索引,在大量單值查詢時會有優勢。

理由如下

1. 假定總資料量為n,user_id的區分度為n/10000 而性別的區分度為n/4

那麼如果以user_id作為前導列,性別作為後列,那麼查詢的複雜度為o(logn+log(n/10000))。也就是說,第一次二分查詢之後,下一次是在第一次的二分查詢的基礎上再去查詢。而如果以性別作為前導,user_id作為後列,那麼複雜度為

o(logn+log(n/4));

效率略差。

然後進入本次正題。上次介紹了關係模型,那麼這次我們來介紹一下事務。

在一切之前,我想先給自己解嘲一下。。事務我自己也沒有辦法完全融匯貫通,因為每乙個小的選擇,都會導致效果的完全不同,所以有錯請在後面一起**。

那麼我們在這裡,主要以單機事務作為入手點,然後闡述一下多機事務相關的知識點。我在這裡只是想做乙個引導,讓大家能夠對整個的知識體系有乙個基本的認識,對於細節問題,會給出一些資料,而不會直接去進行講解,因為篇幅所限.

一般來說,我們一提起事務,就會想到資料庫,確實,事務是資料庫的最重要的乙個屬性。但這似乎不是事務的本源,那麼,讓我們從更深層次去對事務進行一次思考吧:

事務,本質來說就是一組由乙個人(或機器)發起的連續的邏輯操作,共同的完成一件事情,在完成整個事情之前,其所有的改動,都不應該對其他人可見和影響。而在事務結束之後,其一切的改動,都必須「全部」「立刻」對其他的人(或機器)可見。

然後,人們為了描述這一運作,使用了四個詞彙,這也是很多面試的同學們折戟沉沙之處。j 不過這個以前我也不會,後來發現,理解了以後,確實有點用,所以這裡也費一些筆墨吧。

原子性(atomicity):也就是說,一組操作,要不就都成功,要不就都失敗。不存在中間狀態。

一致性(consistency):一致性,也就是說,這個事務在提交或回滾的時候,對其他人(或機器)來說,資料的狀態是同一 的,不會出現中間的狀態。最理想的狀態下,就是說,資料提交後,所有的更改立刻同時生效,可惜,在計算機領域,這個做不到。。因為cpu運算,磁碟寫入, 記憶體寫入,都是要時間的,內部一定是個順序化的過程,所以不可能做到絕對的立刻同時生效。

所以一致性一般來說指代的是邏輯上的同時生效,比如,我要改a,b兩行資料,那麼,最簡單的一致性保證就是,對a,b加鎖,改a,b,然後對a,b解鎖。

這樣下乙個人讀到的一定是a,b的最新值啦。

(但這塊有很多種解釋,一般來說這是個最不明確的詞彙)。

隔離性(isolation):隔離,這是面試最容易掛的乙個問題,其實我認為不怪我們,而是因為本身這個隔離性,是依託鎖來進行設計的。

我們所知道的鎖,主要有以下幾種,1.讀寫鎖,2. 排他鎖

那麼這四種級別其實就和這兩種鎖的實現有關,之所以要定義四個級別,其實原因也是因為,鎖的範圍越大,並行效率越低。而範圍越小,那麼並行的效率就越高。

讀未提交: 其實就是什麼鎖也沒有,所以資料的中間狀態,是可能被其他人讀到的。

讀已提交:就是讀寫鎖實現,讀鎖在查詢之後會被釋放掉,所以這樣其他人可能會更改那些被釋放了讀鎖的資料,這樣當前事務再去讀取的時候,就可能讀取到被別人修改過的資料了,所以乙個人在事務中讀取到的某個資料,可能下次讀取就變成別的資料啦。這就是不可重複讀的意思。。

可重複讀:也是個讀寫鎖實現,讀鎖會阻塞其他人(或機器)的寫,於是,只要是事務中讀取到得資料,都被加了鎖,其他人沒辦法改他們,於是就實現了可重複讀咯。

最後是序列化,就是所有都順序,乙個大鎖全部鎖住j

永續性(durability):永續性就是,事務執行後,就丟不了了,就算是整個中國被淹了,機器都沒了,資料也不應該丟掉(不過基本做不到這個,也就是乙個機器掛了不會丟資料而已。。)所有機房沒了那資料也就沒了。。

海量儲存系列之三

首先是回答上次的問題。假設有這麼一組資料,性別有4種,user id是一對多的關係,如果我想查詢 select fromtabwhereuser idin and性別 不明 如何進行索引構建能夠獲得比較好的效果呢?我個人認為,應該建立的是以user id作為前導列,性別作為輔助列的索引,在大量單值查...

海量儲存系列之三 事務原理

首先是回答上次的問題。假設有這麼一組資料,性別有4種,user id是一對多的關係,如果我想查詢 select from tabwhere user id in and 性別 不明 如何進行索引構建能夠獲得比較好的效果呢?我個人認為,應該建立的是以user id作為前導列,性別作為輔助列的索引,在大...

海量儲存系列之十三

在上一章中,我們主要介紹了規則引擎中最重要的乙個部分,自動擴容,在今天的章節,我們主要還是介紹一下我們在 tddl中的工程實踐吧。首先從原理開始吧。規則引擎是什麼呢?對應在上述例子裡面,其實就是dbnum pk 3 這個規則。他的變化可能很多,比如對於一致性hash則變為乙個if else 的表示式...