数据库容量和内存测算的一些想法
數據庫容量和內存測算的一些想法
參考于:http://blog.itpub.net/12679300/viewspace-1443818/
參考于:http://blog.sina.com.cn/s/blog_1533f3fb90102wktx.html
一、數據庫容量估算
總體來說數據庫容量核心分析對象還是數據庫表,以及圍繞數據庫表的視圖、索引、日志等相關附屬信息。匯總這些信息后,再加上3--5年業務增長量給出數據庫容量的評估。
1、單表單行數據庫容量分析:
分析單表單行數據容量,就要分析各種數據庫和各種數據類型占用字節的情況,比如Oracle數據庫:
char類型多長就多少字節,Number類型最多按22個字節計算,平均按10個字節計算足夠,varchar類型按長度2/3計算,date型占有7個字節。
按如上假設,如果一個客戶表,有30個varchar(100),則一條客戶記錄是2k,10萬客戶信息則將近200M,每年30%的增長,則每年增加空間約60M。
2、索引空間評估:
一張表的索引空間一般是表空間的1/3,可以按照1/2表空間評估該表的索引存儲空間。
3、數據庫緩存容量:
數據庫緩存(內存空間)一般為數據庫空間的5%時性能較好。
4、內存容量空間需求分析:
首先根據數據庫容量算出所需的數據庫緩存大小,再估計出操作系統、系統軟件等所需內存,合計即是所需的內存容量。
5、機器系能:一般機器CPU達到70%系能較好,超出為過渡飽和,有系能隱患,低于的話,機器資源沒有達到合理利用。
除此之外,分析數據庫空間還有表日志空間、rollback空間、redo空間、臨時空間等。
6、另外一種計算的方法
當系統運行一段時間之后(比如三個月),這時候已經很清楚當前的數據總量和占用的總空間大小,通過對未來的業務估算可以很容易的計算出未來1年、3年的整體數據庫容量大小;
比如一個系統上線3個月后,數據庫的大小達到了300GB,如果這三個月的業務屬于正常范圍,那么很容易計算出每個月差不多增長100個Gb,但是行業之間總是有差異的,比我鞋服行業就有分春夏和秋冬的區別,一件衣服夏天的和冬天的主數據量是不一樣的,按這種方式會有比較大的誤差,但是數據量級別應該是正確的,對于這種系統運行完一年之后進行容量的評估將會比較正確;
這種方法計算容量有一個很明顯的弊端:需要在系統運行一段時間之后才能計算出來,但是這個時候相應的硬件和存儲都已經采購完畢了,只能在一段時間之后進行擴容。
7、參考同行業同系統之間的數據容量
這是一個最便捷的辦法,在上SAP之前公司內部最大的系統數據也才500GB左右,所以在腦子里面對數據容量的大小也是一直停留在百GB的水平,剛好同行業中的其他公司也上了SAP,經過了解他們上SAP的模塊和我們差不多,運行一段時間之后數據量已經達到了TB的水平了,每天數據的增長量是GB級別,這樣一下子對整個系統的數據量級別有了個很明顯的認識。在采購硬件的時候就不會有太大的偏差。
二、內存需求的計算
涉及到內存的緩存命中率的關系,數據庫系統的內存的分配跟數據庫總容量大小有很大的關系,行業的經驗是當緩存容量達到數據庫總容量的5%時性能較好,因此確定了數據庫的大小之后緩存的大小也就可以的出來了。
例如在aix平臺下面一個1TB的數據庫
1、操作系統本身所占用的內存 128MB
2、應用程序所占的內存 256MB
3、數據庫緩存 50GB
4、合理的內存利用率75%
總計 67GB
考慮到數據的保存時間5年(一般3到5年要做一個數據結轉),因此數據庫最大容量有可能達到5TB,所以該主機的內存達到300GB可以滿足未來5年的業務需求。
總結:站得高尿得遠,dba主動去考慮一下整體的it架構需求,當這種思考點多了站的高度也就高了。因為整個IT架構里面dba屬于一個很重要的崗位,性能的規劃、存儲容量的規劃只有dba最清楚,當dba不參與的時候,就變成了“猜”,根據系統的重要性去采買硬件、幾個cpu、多少內存、多少存儲,這些都是憑著系統的重要性和領導的重視程度、預算的多少,供應商當然也會提供相應的參考方案,但是他們提的方案肯定是越高越好的。
附:基本類型長度
(1)數值類型
| 類型 | 大小 | 范圍(有符號) | 范圍(無符號) | 用途 |
|---|---|---|---|---|
| TINYINT | 1 字節 | (-128,127) | (0,255) | 小整數值 |
| SMALLINT | 2 字節 | (-32 768,32 767) | (0,65 535) | 大整數值 |
| MEDIUMINT | 3 字節 | (-8 388 608,8 388 607) | (0,16 777 215) | 大整數值 |
| INT或INTEGER | 4 字節 | (-2 147 483 648,2 147 483 647) | (0,4 294 967 295) | 大整數值 |
| BIGINT | 8 字節 | (-9 233 372 036 854 775 808,9 223 372 036 854 775 807) | (0,18 446 744 073 709 551 615) | 極大整數值 |
| FLOAT | 4 字節 | (-3.402 823 466 E+38,-1.175 494 351 E-38),0,(1.175 494 351 E-38,3.402 823 466 351 E+38) | 0,(1.175 494 351 E-38,3.402 823 466 E+38) | 單精度 浮點數值 |
| DOUBLE | 8 字節 | (-1.797 693 134 862 315 7 E+308,-2.225 073 858 507 201 4 E-308),0,(2.225 073 858 507 201 4 E-308,1.797 693 134 862 315 7 E+308) | 0,(2.225 073 858 507 201 4 E-308,1.797 693 134 862 315 7 E+308) | 雙精度 浮點數值 |
| DECIMAL | 對DECIMAL(M,D) ,如果M>D,為M+2否則為D+2 | 依賴于M和D的值 | 依賴于M和D的值 | 小數值 |
(2)日期和時間類型
| 類型 | 大小 (字節) |
范圍 | 格式 | 用途 |
|---|---|---|---|---|
| DATE | 3 | 1000-01-01/9999-12-31 | YYYY-MM-DD | 日期值 |
| TIME | 3 | '-838:59:59'/'838:59:59' | HH:MM:SS | 時間值或持續時間 |
| YEAR | 1 | 1901/2155 | YYYY | 年份值 |
| DATETIME | 8 | 1000-01-01 00:00:00/9999-12-31 23:59:59 | YYYY-MM-DD HH:MM:SS | 混合日期和時間值 |
| TIMESTAMP | 4 |
1970-01-01 00:00:00/2038 結束時間是第2147483647秒,北京時間2038-1-19 11:14:07,格林尼治時間 2038年1月19日 凌晨 03:14:07 |
YYYYMMDD HHMMSS | 混合日期和時間值,時間戳 |
(3)字符串類型
| 類型 | 大小 | 用途 |
|---|---|---|
| CHAR | 0-255字節 | 定長字符串 |
| VARCHAR | 0-65535 字節 | 變長字符串 |
| TINYBLOB | 0-255字節 | 不超過 255 個字符的二進制字符串 |
| TINYTEXT | 0-255字節 | 短文本字符串 |
| BLOB | 0-65 535字節 | 二進制形式的長文本數據 |
| TEXT | 0-65 535字節 | 長文本數據 |
| MEDIUMBLOB | 0-16 777 215字節 | 二進制形式的中等長度文本數據 |
| MEDIUMTEXT | 0-16 777 215字節 | 中等長度文本數據 |
| LONGBLOB | 0-4 294 967 295字節 | 二進制形式的極大文本數據 |
| LONGTEXT | 0-4 294 967 295字節 | 極大文本數據 |
總結
以上是生活随笔為你收集整理的数据库容量和内存测算的一些想法的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Cocoapods pod update
- 下一篇: 连通图/割点、割边