組態(tài)軟件內存實時數(shù)據(jù)庫性能測試
引言
伴隨著分布式控制系統(tǒng)DCS(DistributedControlSystem)的出現(xiàn)，以及其在工控領域的廣泛應用，組態(tài)軟件開始逐漸被廣大技術人員所熟悉。“組態(tài)”的概念最早來自英文Configuration，其含義是使用軟件工具對計算機及軟件的各種資源進行配置(包括進行對象的定義、制作和編輯，并設定其狀態(tài)特征屬性參數(shù))，達到使計算機或軟件按照預先設置,自動執(zhí)行特定任務，滿足使用者要求的目的。
組態(tài)軟件是應用在數(shù)據(jù)采集和過程控制層面的一種專用軟件，應用在分布式控制系統(tǒng)數(shù)據(jù)監(jiān)控層一級。通過使用組態(tài)軟件，可以為DCS工控系統(tǒng)提供良好的用戶開發(fā)界面以及簡潔的使用方法，可以非常容易地實現(xiàn)和完成對分布式工業(yè)控制系統(tǒng)各個模塊的模擬和監(jiān)控功能，使計算機圖形界面與工控系統(tǒng)真實設備聯(lián)系起來；通過集成各個硬件廠家的I/O接口以及設備接口，組態(tài)軟件能夠采集到工控設備的現(xiàn)場數(shù)據(jù),通過實時數(shù)據(jù)庫進行處理，并存儲到歷史數(shù)據(jù)庫供查詢使用；通過設置，可以對采集數(shù)據(jù)提供報警和報表功能；同時，組態(tài)軟件應該能支持各種工控設備和常見的通信協(xié)議，并且通常應提供分布式數(shù)據(jù)管理和網(wǎng)絡功能。
組態(tài)軟件產(chǎn)品于上世紀80年代初出現(xiàn)，并且得到了良好的發(fā)展，目前世界上的組態(tài)軟件有幾十種之多，其中主要包括美國Wonderware的Intouch、美國Intellution公司的Fix、澳大利亞Cit公司的Citech、德國Simens的Wince、北京亞控自動化軟件有限公司開發(fā)的組態(tài)王(Kingview)、大慶三維公司的ForceControl以及北京昆侖通態(tài)自動化軟件科技有限公司開發(fā)研制的MCGS等。伴隨著國家對工控領域的支持不斷加大,
收稿日期:2014-01-14
組態(tài)軟件將在工控信息化中扮演越來越重要的角色，未來發(fā)展的空間也會不斷擴大。
1內存實時數(shù)據(jù)庫
大批量生產(chǎn)、連續(xù)加工過程、高度自動化程度是流程工業(yè)的特點，這需要在過程監(jiān)控時提供高速的數(shù)據(jù)處理、長期的數(shù)據(jù)存儲。工業(yè)控制系統(tǒng)是一個實時系統(tǒng)，它實時地從外界采集數(shù)據(jù)進行運算、判斷后輸出控制量，因此對數(shù)據(jù)的管理呈現(xiàn)出實時特點［3］。因此,實時數(shù)據(jù)庫是組態(tài)軟件處理數(shù)據(jù)、組織數(shù)據(jù)和管理數(shù)據(jù)的核心，它能夠高效地處理和存儲工控系統(tǒng)生產(chǎn)過程中的實時數(shù)據(jù)，為優(yōu)化過程控制和企業(yè)的經(jīng)營決策提供完整的實時數(shù)據(jù)和完備的歷史信息叫
根據(jù)工控系統(tǒng)的特點，在工業(yè)組態(tài)軟件中需要應用內存實時數(shù)據(jù)庫，分以下幾種情況：內存實時數(shù)據(jù)庫整個數(shù)據(jù)庫常駐內存，對數(shù)據(jù)的存取不需要I/O操作；整個數(shù)據(jù)庫不用常駐內存，但存取數(shù)據(jù)時，應先進入內存，即數(shù)據(jù)庫的存取在內存中進行；數(shù)據(jù)庫常駐磁盤，增大緩沖區(qū)，在一個事務執(zhí)行之前，所有的數(shù)據(jù)都已經(jīng)取到內存，經(jīng)適當?shù)木彌_區(qū)管理減少甚至消除I/O［5］,這些特點決定了內存實時數(shù)據(jù)庫能夠及時有效地處理和維護大量的共享數(shù)據(jù)和控制數(shù)據(jù)，滿足工業(yè)組態(tài)軟件對于事務時間性方面的要求。
對于內存實時數(shù)據(jù)庫來說，由于已不再涉及I/O,所以在時間和空間矛盾的處理上，空間是第一位，系統(tǒng)的算法設計目標應該是內存空間和CPU的高效使用。為了達到這一目標,應該對內存實時數(shù)據(jù)庫的數(shù)據(jù)組織結構、事務處理和數(shù)據(jù)管理、并發(fā)控制及恢復技術、內存置換頁面以及緩存大小等方面進行研究與測試［5］,使其能夠提供更好的性能，滿足工業(yè)控制組態(tài)軟件的需求。
2內存實時數(shù)據(jù)庫性能測試
2.1測試目的
針對內存實時數(shù)據(jù)庫的特點和研究與測試方面的要求,設置內存實時數(shù)據(jù)庫的數(shù)據(jù)組織形式、內存置換頁面大小以及緩存大小，通過測試數(shù)據(jù)，得出不同的配置組合對內存實時數(shù)據(jù)庫性能上的影響，為下一步的研究工作打下基礎。2.2測試環(huán)境
測試對象采用BerkeleyDB內存實時數(shù)據(jù)庫系統(tǒng)。BerkeleyDB歷史悠久，主要應用在Unix/Linux操作系統(tǒng)上,其設計思想是簡單、小巧、可靠、高性能。它可為應用程序提供可伸縮的、高性能的、有事務保護功能的數(shù)據(jù)管理服務。同時BerkeleyDB為數(shù)據(jù)的存取和管理提供了一組簡潔的函數(shù)調用API接口。BerkeleyDB對接收到的實時數(shù)據(jù)采用關鍵詞(Key)和數(shù)據(jù)(Value)的存儲結構，這兩者構成的Key/Value對組成了數(shù)據(jù)庫中的一個基本結構單元，而整個數(shù)據(jù)庫實際上就是由許多這樣的結構單元所構成的。通過使用這種方式,簡化了實時數(shù)據(jù)的存儲邏輯關系，同時，簡便的數(shù)據(jù)庫查詢和訪問方式也能夠滿足工業(yè)組態(tài)軟件的需求。所以，在此測試中，所有的數(shù)據(jù)插入的都是Key=int,Value=int,在循環(huán)中遞增的。
本機配置如下：
OS為Windows7旗艦版；RAM=8GB；CPU=IntelCorei7-3770CPU3.4GHz；Disk=500GB；NTFS的默認簇大小為4KB。
測試的實際數(shù)據(jù)量為：
300*10000*2*sizeof(int)/1024/1024絲22.89MB；編譯器：VisualC++6.0；BerkeleyDB內存實時數(shù)據(jù)庫版本為db-5.3.21.NC2.3測試方法
循環(huán)插入int類型的數(shù)據(jù)，同時設置BerkeleyDB的參數(shù)，測試在不同存儲方循環(huán)插入int類型的數(shù)據(jù)，同時設置BerkeleyDB的參數(shù)，測試在不同數(shù)據(jù)組織形式、內存置換頁面大小以及Cache緩存大小的設置下，數(shù)據(jù)庫讀寫的性能,以確定組態(tài)軟件實時數(shù)據(jù)庫部分的存儲方式。
2.4測試代碼
內存實時數(shù)據(jù)庫性能的測試代碼如下：
#include“stdafx.h”
#include"db.h”
#include“db_cxx.h”
#include“windows.h”
#include“winbase.h”
intmain(intargc,char*argv[])
{
size_tpsize=1；//設置頁面大小，單位為KBsize_tcsize=10；//設置cache大小，單位為MBinttcount=300；//設置數(shù)據(jù)插入數(shù)量，單位為萬次Dbdb(NULL,0)；
db.set_pagesize(1024*psize)；
db.set_cachesize(0,1024*1024*csize,0)；u_int32_toFlags=DB_CREATE；try
{
db.open(NULL,"test.db",NULL,DB_
BTREE,oFlags,0)；
}
catch(DbException&e)
{
}
catch(std::exception&e)
{
}
//實時數(shù)據(jù)插入
Dbtkey,data；
inti,ret,count=10000*tcount；
longt1=GetTickCount()；//開始時間
for(i=0；i<count；i++)
{
Dbtkey(&i,sizeof(int))；
Dbtdata(&i,sizeof(int))；
db.put(0,&key,&data,DB_
NOOVERWRITE)；
}
longt2=GetTickCount()；//結束時間
printf("插入結束%d萬記錄，全部用時:%.2f秒\r\n",
tcount,(t2-t1)/(float)1000)；
longtick1=GetTickCount()；
try
{
Dbc*dbcp；
db.cursor(NULL,&dbcp,0)；
Dbtkey；
Dbtdata；
while(dbcp->get(&key,&data,DB_NEXT)==0)
{
key.get_data()；
data.get_data()；
}
dbcp->close()；
printf("遍歷結束%d萬記錄，全部用時：%.2f秒\r\n",tcount,(GetTickCount()-tickl)/(float)1000)；
db.sync(0)；
}
catch(DbException&dbe){}
db.close(0)；
return0；
}
2.5測試結果
代碼運行界面如圖1所示。
代碼運行后所得到的結果如表1――表3所列。
表1頁尺寸列表
(記錄數(shù)量:300萬，緩存尺寸：0MB單位：s)
|
讀寫 |
1KB |
2KB |
4KB |
8KB |
16KB |
32KB |
|
B+寫 |
33.71 |
30.28 |
26.85 |
28.30 |
34.09 |
50.59 |
|
HASH寫 |
50.92 |
46.32 |
48.64 |
54.10 |
67.44 |
91.39 |
|
B+讀 |
2.03 |
2.00 |
2.03 |
2.11 |
2.20 |
2.34 |
|
HASH讀 |
4.24 |
4.51 |
3.85 |
3.70 |
3.67 |
3.32 |
表2Cache緩存大小列表(1)
(記錄數(shù)量：300萬；頁尺寸：4KB;數(shù)據(jù)庫文件大?。?0.2MB;單位：s)
|
讀寫 |
0MB |
10MB |
20MB |
40MB |
80MB |
160MB |
320MB |
|
B+寫 |
31.78 |
17.04 |
16.04 |
15.12 |
11.50 |
11.37 |
11.33 |
|
HASH寫 |
46.85 |
30.39 |
22.2 |
16.49 |
12.65 |
12.92 |
13.39 |
|
B+讀 |
2.46 |
2.65 |
2.61 |
2.65 |
2.59 |
2.54 |
2.56 |
|
HASH讀 |
3.73 |
3.54 |
3.2 |
3.21 |
3.12 |
3.18 |
3.25 |
表3Cache緩存大小列表(2)
Cache緩存大小(記錄數(shù)量：600萬；頁尺寸：4KB;數(shù)據(jù)庫文件大?。?60MB;單位：s)
|
讀寫 |
0MB |
10MB |
20MB |
40MB |
80MB |
160MB |
320MB |
|
B+寫 |
71.07 |
44.60 |
43.41 |
41.95 |
36.13 |
24.77 |
24.49 |
|
HASH寫 |
102.21 |
85.82 |
67.00 |
52.56 |
43.51 |
28.24 |
27.75 |
|
B+讀 |
5.21 |
5.48 |
5.51 |
5.49 |
5.41 |
5.30 |
5.24 |
|
HASH讀 |
8.24 |
8.22 |
7.91 |
7.52 |
7.11 |
6.74 |
6.75 |
4 結 語
根據(jù)以上運行結果，可以看出組態(tài)軟件內存實時數(shù)據(jù)庫BerkeleyDB在采用B+樹存儲方式的時候，其寫入和讀取性能明顯高于HASH存儲方式；當頁面尺寸為4KB時,BerkeleyDB的存儲效率最高，隨著頁面尺寸的不斷增大，效率反而逐漸降低；當確定了頁面尺寸為4KB后，逐漸改變Cache緩存大小，比較300萬與600萬兩種記錄數(shù)量，發(fā)現(xiàn)無論是B+樹的存儲方式還是HASH的存儲方式，當緩存很小的時候，效率都很差，而當緩存大小大于等于數(shù)據(jù)庫文件大小時，效率最高，之后隨著緩存逐漸增大，對效率的影響很小。
通過該測試可以得出，不同的數(shù)據(jù)組織形式、內存置換頁面大小以及Cache緩存大小對內存實時數(shù)據(jù)庫的效率性能影響很大，本文只針對B+樹和HASH存儲方式進行了測試,測試的內容并不完善，下一步應該對數(shù)據(jù)的組織形式進行深入的研究，挖掘更適合鍵值對形式的工業(yè)組態(tài)軟件內存實時數(shù)據(jù)組織結構。
20211120_6197d95914a30__智能家居虛擬場景設1計與實現(xiàn)
下載文檔
