一周以來的工作總結

2021-09-06 06:14:28 字數 1305 閱讀 3605

這周客戶的問題非常多,總是說我的資料不對。於是我對資料梳理了以後發現以前認為是重複資料的,其實並不是,而是我忽略了乙個維度。那麼這樣一來,我們的周詳單錶就會有500多萬的資料。乙個月按照4周計算,就要有2000萬條資料。而我大概計算了一下,每乙個周的分割槽要占用2g多的儲存空間,要知道電信給我們的空間不過是500g左右,我們大家都在用,我乙個人每週消耗2g,顯然不合適。

這個時候有如下幾個解決方案,第乙個,將乙個月或者幾個月以前的資料乾掉,以後客戶需要的時候從資料倉儲抽取資料,然後重新展現就好了。但是這個辦法並不是很靠譜,因為資料倉儲每一段時間會清理一些表,萬一那個時候資料沒有了,那群客戶一定會把我五馬分屍。第二種就是對資料本身進行處理,我想到的辦法就是壓縮表——compress。

--建立普通表

create

table

table1

( ......

) compress;

--

建立分割槽表

create

table

table1

( ...

) compress

partition

byrange(...)

( partition part_1

values

less than(...) compress,

partition part_2

values

less than(...) compress,

...)

如果是乙個已經存在的表要進行壓縮也很簡單:  

alter

table table1 move compress;

如果是乙個分割槽表的話會更加靈活,只需要壓縮你想要壓縮的表空間就可以了:

alter

table tables1 move partition part_1 compress;

在我遇到的這個情況中,我傾向於在另外乙個表空間新建一張分割槽壓縮表,然後在儲存過程每週重新整理資料的時候,把指定的歷史資料轉移到這個新的表中,然後清空該分割槽,這種處理方法不管過多久,表的大小基本上是不變的,不用擔心時間長了資料會把表空間佔滿。

根據我在網上查閱的資料,我發現壓縮表其實和平時用rar壓縮一大堆word檔案是差不多的道理,壓縮的時候需要耗費不少時間,壓縮以後效果非常明顯,占用空間只是以前的一半甚至不到一半,但是想查閱這些資料的時候,卻要消耗比平時多的時間。據網上的資料顯示,甚至會三倍於非壓縮表。所以,壓縮表並不適合儲存當月的新鮮資料,而比較適合歷史資料的儲存,因為客戶想看一年前的資料的情況基本不大,尤其是這種周詳單。

一周以來的工作總結

這周客戶的問題非常多,總是說我的資料不對。於是我對資料梳理了以後發現以前認為是重複資料的,其實並不是,而是我忽略了乙個維度。那麼這樣一來,我們的周詳單錶就會有500多萬的資料。乙個月按照4周計算,就要有2000萬條資料。而我大概計算了一下,每乙個周的分割槽要占用2g多的儲存空間,要知道電信給我們的空...

一周以來工作總結 關於高水位線

我們都知道,表中的資料其實是存在在資料塊中的,資料塊中有一部分是used,有一部分是freespace,在你插入若干條資料之後,資料塊就被占用了,因此會出現以下情況 我發現把自己已經掌握的知識像寫書一樣寫出來,會讓你的知識得到昇華,讓你系統的知道自己會什麼,不會什麼,什麼精通,什麼略懂。我最近就在整...

一周工作總結

一周又過去了,感覺時間過得快,又覺得慢。這不上次寫部落格離現在已經一周了,但上次寫部落格的情景還很清晰,故為快。這過去的幾天比較充實,也許因為這樣覺得時間也慢吧。下面簡要回顧下上週工作吧,做個小總結。上次還認為工作是嵌入式開發,會跟硬體打交道多,對硬體開發平台和軟體開發環境還只是初步了解。根據現在的...