|
1:關(guān)于TPC-C
TPC(Transactionprocessing Performance Council，事務(wù)處理性能委員會(huì))是由數(shù)十家會(huì)員公司創(chuàng)建的非盈利組織，總部設(shè)在美國(guó)。TPC的成員主要是計(jì)算機(jī)軟硬件廠家，而非計(jì)算機(jī)用戶(hù)，其功能是制定商務(wù)應(yīng)用基準(zhǔn)程序的標(biāo)準(zhǔn)規(guī)范、性能和價(jià)格度量，并管理測(cè)試結(jié)果的發(fā)布。
圖1:TPC組織成員構(gòu)成
TPC不給出基準(zhǔn)程序的代碼，而只給出基準(zhǔn)程序的標(biāo)準(zhǔn)規(guī)范。任何廠家或其他測(cè)試者都可以根據(jù)規(guī)范，最優(yōu)地構(gòu)造出自己的測(cè)試系統(tǒng)(測(cè)試平臺(tái)和測(cè)試程序)。為保證測(cè)試結(jié)果的完整性，被測(cè)試者(通常是廠家)必須提交給TPC一套完整的報(bào)告(Full Disclosure Report)，包括被測(cè)系統(tǒng)的詳細(xì)配置、分類(lèi)價(jià)格和包含5年維護(hù)費(fèi)用在內(nèi)的總價(jià)格。該報(bào)告必須由TPC授權(quán)的審核員核實(shí)(TPC本身并不做審計(jì))。 TPC在全球只有不到10名審核員，全部在美國(guó)。
作為一家非盈利性機(jī)構(gòu)，事務(wù)處理性能委員會(huì)（TPC）負(fù)責(zé)定義諸如TPC-C、TPC-H和TPC-W基準(zhǔn)測(cè)試之類(lèi)的事務(wù)處理與數(shù)據(jù)庫(kù)性能基準(zhǔn)測(cè)試，并依據(jù)這些基準(zhǔn)測(cè)試項(xiàng)目發(fā)布客觀性能數(shù)據(jù)。
TPC基準(zhǔn)測(cè)試采用極為嚴(yán)格的運(yùn)行環(huán)境，并且必須在獨(dú)立審計(jì)機(jī)構(gòu)監(jiān)督下進(jìn)行。委員會(huì)成員包括大多數(shù)主要數(shù)據(jù)庫(kù)產(chǎn)品廠商以及服務(wù)器硬件系統(tǒng)供應(yīng)商。
相關(guān)企業(yè)參與TPC基準(zhǔn)測(cè)試以期在規(guī)定運(yùn)行環(huán)境中獲得客觀性能驗(yàn)證，并通過(guò)應(yīng)用測(cè)試過(guò)程中所使用的技術(shù)開(kāi)發(fā)出更加強(qiáng)健且更具伸縮性的軟件產(chǎn)品及硬件設(shè)備。
TPC-C是一種旨在衡量聯(lián)機(jī)事務(wù)處理（OLTP）系統(tǒng)性能與可伸縮性的行業(yè)標(biāo)準(zhǔn)基準(zhǔn)測(cè)試項(xiàng)目。這種基準(zhǔn)測(cè)試項(xiàng)目將對(duì)包括查詢(xún)、更新及隊(duì)列式小批量事務(wù)在內(nèi)的廣泛數(shù)據(jù)庫(kù)功能進(jìn)行測(cè)試。許多IT專(zhuān)業(yè)人員將TPC-C視為衡量“真實(shí)”O(jiān)LTP系統(tǒng)性能的有效指示器。
TPC-C基準(zhǔn)測(cè)試針對(duì)一種模擬訂單錄入與銷(xiāo)售環(huán)境測(cè)量每分鐘商業(yè)事務(wù)（tpmC）吞吐量。特別值得一提的是，它將專(zhuān)門(mén)測(cè)量系統(tǒng)在同時(shí)執(zhí)行其它四種事務(wù)類(lèi)型（如支付、訂單狀態(tài)更新、交付及證券級(jí)變更）時(shí)每分鐘所生成的新增訂單事務(wù)數(shù)量。獨(dú)立審計(jì)機(jī)構(gòu)將負(fù)責(zé)對(duì)基準(zhǔn)測(cè)試結(jié)果進(jìn)行公證，同時(shí)，TPC將出據(jù)一份全面徹底的測(cè)試報(bào)告。
這份測(cè)試報(bào)告可以從TPC Web站點(diǎn)(http://www.)上獲得。
tpmC定義: TPC-C的吞吐量，按有效TPC-C配置期間每分鐘處理的平均交易次數(shù)測(cè)量，至少要運(yùn)行12分鐘。
1.1:TPC-C規(guī)范概要
TPC-C使用三種性能和價(jià)格度量，其中性能由tpmC（transactions per minute，tpm）衡量，C指TPC中的C基準(zhǔn)程序。它的定義是每分鐘內(nèi)系統(tǒng)處理的新訂單個(gè)數(shù)。TPC-C還經(jīng)常以系統(tǒng)性能價(jià)格比的方式體現(xiàn)，單位是＄/tpmC，即以系統(tǒng)的總價(jià)格（單位是美元）/tpmC數(shù)值得出。
TPC-C是專(zhuān)門(mén)針對(duì)聯(lián)機(jī)交易處理系統(tǒng)（OLTP系統(tǒng)）的，一般情況下我們也把這類(lèi)系統(tǒng)稱(chēng)為業(yè)務(wù)處理系統(tǒng)。
TPC-C測(cè)試規(guī)范中模擬了一個(gè)比較復(fù)雜并具有代表意義的OLTP應(yīng)用環(huán)境:假設(shè)有一個(gè)大型商品批發(fā)商，它擁有若干個(gè)分布在不同區(qū)域的商品庫(kù)；每個(gè)倉(cāng)庫(kù)負(fù)責(zé)為10個(gè)銷(xiāo)售點(diǎn)供貨；每個(gè)銷(xiāo)售點(diǎn)為3000個(gè)客戶(hù)提供服務(wù)；每個(gè)客戶(hù)平均一個(gè)訂單有10項(xiàng)產(chǎn)品;所有訂單中約1%的產(chǎn)品在其直接所屬的倉(cāng)庫(kù)中沒(méi)有存貨，需要由其他區(qū)域的倉(cāng)庫(kù)來(lái)供貨。
該系統(tǒng)需要處理的交易為以下幾種：
- New-Order：客戶(hù)輸入一筆新的訂貨交易；
- Payment:更新客戶(hù)賬戶(hù)余額以反映其支付狀況;
- Delivery:發(fā)貨(模擬批處理交易);
- Order-Status:查詢(xún)客戶(hù)最近交易的狀態(tài)；
- Stock-Level:查詢(xún)倉(cāng)庫(kù)庫(kù)存狀況，以便能夠及時(shí)補(bǔ)貨。
對(duì)于前四種類(lèi)型的交易，要求響應(yīng)時(shí)間在5秒以?xún)?nèi)；對(duì)于庫(kù)存狀況查詢(xún)交易，要求響應(yīng)時(shí)間在20秒以?xún)?nèi)。
邏輯結(jié)構(gòu)圖：
圖2：邏輯結(jié)構(gòu)圖
流程圖：
圖3：應(yīng)用流程圖
1.2:解讀tpmC
從TPC-C的定義不難知道，這套基準(zhǔn)程序是用來(lái)衡量整個(gè)IT系統(tǒng)的性能，而不是評(píng)價(jià)服務(wù)器或某種硬件系統(tǒng)的標(biāo)準(zhǔn)，而且tpmC 數(shù)值的高低直接受到各個(gè)環(huán)節(jié)的影響，右表大概可以說(shuō)明系統(tǒng)設(shè)置對(duì)tpmC測(cè)試的影響。此處的“IT系統(tǒng)”包括服務(wù)器、外設(shè)(如硬盤(pán)或RAID)、服務(wù)器端操作系統(tǒng)、數(shù)據(jù)庫(kù)軟件、客戶(hù)端及其操作系統(tǒng)、數(shù)據(jù)庫(kù)軟件和網(wǎng)絡(luò)連接等。因此，如何解讀tpmC數(shù)值會(huì)因不同的采購(gòu)需求有非常大的差異。
圖4：TPC-C檢測(cè)環(huán)境示意圖
圖5：tpmC測(cè)試指標(biāo)與硬件的關(guān)聯(lián)度
上述5種交易中，除付貨交易是事后批處理，其余4種皆為聯(lián)機(jī)交易。要注意的是，在處理新訂單的同時(shí)，系統(tǒng)還要處理其他4類(lèi)事務(wù)請(qǐng)求。通常而言，新訂單請(qǐng)求不可能超出全部事務(wù)請(qǐng)求的45%，因此，當(dāng)一個(gè)系統(tǒng)的性能為1000tpmC時(shí)，它每分鐘實(shí)際處理的請(qǐng)求數(shù)是2000多個(gè)。數(shù)據(jù)來(lái)源：www.
以服務(wù)器為例。在很多廠家的TPC測(cè)試系統(tǒng)中，服務(wù)器的價(jià)格只是系統(tǒng)總價(jià)格的25％或更小，而硬盤(pán)的價(jià)格有可能占到總價(jià)格的30％以上，因?yàn)門(mén)PC-C要求被測(cè)系統(tǒng)必須保存180天的事務(wù)記錄（這一趨勢(shì)從一些最新的TPC-C測(cè)試結(jié)果來(lái)看，會(huì)愈演愈烈）。如果同樣的服務(wù)器被用到用戶(hù)的環(huán)境中，廠家報(bào)的tpmC值就意義不大，因?yàn)橛脩?hù)的實(shí)際系統(tǒng)與廠家原來(lái)用于TPC測(cè)試的系統(tǒng)大不一樣。當(dāng)同樣的主機(jī)用在不同的系統(tǒng)中時(shí)，tpmC值可能有相當(dāng)大的變化，現(xiàn)在許多用戶(hù)還沒(méi)有意識(shí)到這一點(diǎn)。
尤其需要服務(wù)器采購(gòu)用戶(hù)注意的是，tpmC指標(biāo)更多的是衡量從Client到終端網(wǎng)絡(luò)的性能區(qū)域（如左圖所示），而不是通常誤認(rèn)為的服務(wù)器到企業(yè)端網(wǎng)絡(luò)的性能。由此可見(jiàn)，如果用戶(hù)是建立一套全新的業(yè)務(wù)系統(tǒng)，那么無(wú)妨多借鑒tpmC的性能指標(biāo)，如果只是采購(gòu)某種或某些硬件設(shè)備，則需要參考更多的指標(biāo)。
1.3:評(píng)測(cè)指標(biāo)
TPC-C測(cè)試規(guī)范經(jīng)過(guò)兩年的研制，于1992年7月發(fā)布。幾乎所有在OLTP市場(chǎng)提供軟硬件平臺(tái)的廠商都發(fā)布了相應(yīng)的TPC-C測(cè)試結(jié)果，隨著計(jì)算機(jī)技術(shù)的不斷發(fā)展，這些測(cè)試結(jié)果也在不斷刷新。
TPC-C的測(cè)試結(jié)果主要有兩個(gè)指標(biāo)：
●流量指標(biāo)(Throughput，簡(jiǎn)稱(chēng)tpmC)
按照TPC的定義，流量指標(biāo)描述了系統(tǒng)在執(zhí)行Payment、Order-status、Delivery、Stock-Level這四種交易的同時(shí)，每分鐘可以處理多少個(gè)New-Order交易。所有交易的響應(yīng)時(shí)間必須滿(mǎn)足TPC-C測(cè)試規(guī)范的要求。
流量指標(biāo)值越大越好！
● 性?xún)r(jià)比(Price/Performance，簡(jiǎn)稱(chēng)Price/tpmC)
即測(cè)試系統(tǒng)價(jià)格（指在美國(guó)的報(bào)價(jià)）與流量指標(biāo)的比值。
性?xún)r(jià)比越小越好！
1.4:結(jié)果發(fā)布
各廠商的TPC-C測(cè)試結(jié)果都按TPC組織規(guī)定的兩種形式發(fā)布：測(cè)試結(jié)果概要(Executive Summary)和詳細(xì)測(cè)試報(bào)告(Full Disclosure Report)。
測(cè)試結(jié)果概要中描述了主要的測(cè)試指標(biāo)、測(cè)試環(huán)境示意圖以及完整的系統(tǒng)配置與報(bào)價(jià)，而詳細(xì)測(cè)試報(bào)告中除了包含上述內(nèi)容外，還詳細(xì)說(shuō)明了整個(gè)測(cè)試環(huán)境的設(shè)置與測(cè)試過(guò)程。
P690 tpmC測(cè)試值：76,389,839.00
l $/tpmC：831.00
l 美國(guó)美金報(bào)價(jià)：6,349,223.0
l CPU數(shù)：32
l 數(shù)據(jù)庫(kù)：IBM DB2 UDB 8.1
l 操作系統(tǒng)：AIX 5L V5.2
l 中間件：TUXEDO 8.0
l 測(cè)試日期：2003.6.30
P690 TPC-C測(cè)試的配置：
(1)． 后臺(tái)：1 x eServer pSeries 690 with 32 x 1.7GHz POWER4+ processors with 128MB L3 cache per MCM (total of four MCMs), 512GB memory
(2)． 前端：30 x eServer pSeries 630 Model 6E4 each with 4 x 1.0GHz POWER4 CPUs with 32MB L3 cache, 16GB memory
2: TPC-W
TPC Benchmark? W (TPC-W) is a transactional web benchmark. The workload is performed in a controlled internet commerce environment that simulates the activities of a business oriented transactional web server. The workload exercises a breadth of system components associated with such environments, which are characterized by:
- Multiple on-line browser sessions
- Dynamic page generation with database access and update
- Consistent web objects
- The simultaneous execution of multiple transaction types that span a breadth of complexity
- On-line transaction execution modes
- Databases consisting of many tables with a wide variety of sizes, attributes, and relationships
- Transaction integrity (ACID properties)
- Contention on data access and update
The performance metric reported by TPC-W is the number of web interactions processed per second. Multiple web interactions are used to simulate the activity of a retail store, and each interaction is subject to a response time constraint.
TPC-W simulates three different profiles by varying the ratio of browse to buy: primarily shopping (WIPS), browsing (WIPSb) and web-based ordering (WIPSo). The primary metrics are the WIPS rate, the associated price per WIPS ($/WIPS), and the availability date of the priced configuration.
TPC-W Related Documents
TPC-W模擬面向商務(wù)的事務(wù)型Web服務(wù)器活動(dòng)。工作負(fù)載將在受控Internet商務(wù)環(huán)境中執(zhí)行，并且將對(duì)與此種環(huán)境相關(guān)的廣泛系統(tǒng)組件進(jìn)行測(cè)試。
通過(guò)TPC-W得到的性能指標(biāo)為每秒處理的Web交互次數(shù)。多種Web交互方式被用于模擬零售商店業(yè)務(wù)活動(dòng)，其中每種交互方式均有一定的響應(yīng)時(shí)間限制。商店規(guī)?？梢酝ㄟ^(guò)一套事先指定的比例因子加以選擇，這種比例因子為庫(kù)存貨物件數(shù)，其取值被控制在1,000件至10,000,000件之間。
例子：
|
基準(zhǔn)測(cè)試詳細(xì)信息: |
|
|
|
|
操作系統(tǒng) |
Windows Server 2003企業(yè)版 |
|
性能 |
每秒鐘處理21,139次Web交互（WIPS） |
|
性?xún)r(jià)比 |
每WIPS 32.62美元 |
|
硬件設(shè)備 |
IBM eServer xSeries 440 |
|
總體系統(tǒng)成本 |
689,477美元 |
|
系統(tǒng)可用日期 |
2003年3月31日 |
|
測(cè)試起始日期 |
2003年1月14日 |
3：TPC-H
TPC-H所報(bào)告的性能計(jì)量單位被稱(chēng)為“TPC-H復(fù)合式每小時(shí)查詢(xún)性能單位（QphH）”，反映出了系統(tǒng)處理查詢(xún)的多方面能力。
The TPC-H benchmark is widely used in the database community as a yardstick to assess the performance of database management systems against large scale decision support applications. The benchmark is designed and maintained by theTransaction Processing Counsel.
In Sep 2008 we ran this benchmark on our Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz with 8GB RAM and ample disk space (2x 500 GB SATA disk @ 7200 RPM as SW-RAID-0), running Fedora 8 (Linux kernel 2.6.24). The systems considered were PostgreSQL 8.2.9, MySQL 5.0.45, Ingres 2006 version 4 and MonetDB/SQL 2.25 on top of MonetDB/Server 5.7 (development version from CVS, dated Sat Jul 19 11AM). All systems were installed with their default settings, i.e. it mimics an out-of-the-box situation that end-users will experience. For PostgreSQL we called the statistics utility directly after loading. The query sequences were run one after the other in a single client session. The timings for MonetDB concern two runs: '2nd' [1st]. The other systems concern a single run. The same experiment was previously ran inOctober 2006.July 2008.
|
TPCH scale factor 2, timing in seconds |
|
|
|
MonetDB/SQL |
|
|
PostgreSQL |
MySQL |
|
|
stable |
current |
recycler |
|
|
|
Q1 |
6.2 [6.3] |
2.2 [2.2] |
0.8 [2.2] |
76 |
41 |
|
Q2 |
0.14 [0.2] |
0.07 [0.08] |
0.08 [0.16] |
1 |
26 |
|
Q3 |
2.6 [2.6] |
1.1 [1.0] |
0.01 [1.2] |
20 |
16 |
|
Q4 |
2.2 [2.2] |
0.9 [0.9] |
0.002 [0.9] |
1.2 |
2.6 |
|
Q5 |
1.3 [1.2] |
0.7 [0.8] |
0.002 [0.8] |
0.8 |
27 |
|
Q6 |
0.5 [0.5] |
0.2 [0.3] |
0.003 [0.3] |
5.2 |
7 |
|
Q7 |
1.8 [1.8] |
0.7 [0.8] |
0.2 [0.5] |
8.7 |
8 |
|
Q8 |
0.7 [0.7] |
0.4 [0.4] |
0.003 [0.2] |
6.9 |
1.5 |
|
Q9 |
1.7 [1.8] |
0.6 [0.6] |
0.04 [0.9] |
53 |
11 |
|
Q10 |
1.7 [1.7] |
0.7 [0.7] |
0.02 [0.8] |
0.9 |
18 |
|
Q11 |
0.2 [0.2] |
0.06 [0.06] |
0.06 [0.06] |
1.1 |
0.5 |
|
Q12 |
1.3 [1.3] |
0.6 [0.6] |
0.3 [0.7] |
7 |
6.9 |
|
Q13 |
8.1 [8.0] |
3.3 [3.3] |
1.0 [3.3] |
19.2 |
9.9 |
|
Q14 |
0.4 [0.3] |
0.2 [0.2] |
0.008 [0.2] |
5 |
38 |
|
Q15 |
0.3 [0.3] |
0.1 [0.2] |
0.03 [0.2] |
5 |
13 |
|
Q16 |
1.1 [1.1] |
0.5 [0.5] |
0.4 [0.5] |
12.9 |
11 |
|
Q17 |
1.3 [1.3] |
0.6 [0.6] |
0.006 [0.6] |
|
1.2 |
|
Q18 |
1.7 [1.7] |
0.9 [0.9] |
0.004 [0.9] |
52 |
|
|
Q19 |
3.6 [3.7] |
1.4 [1.4] |
1.3 [1.5] |
8 |
0.327 |
|
Q20 |
1.2 [1.2] |
0.4 [0.4] |
0.4 [0.4] |
|
0.4 |
|
Q21 |
7.6 [7.6] |
2.2 [2.2] |
2.0 [0.4] |
49 |
7.3 |
|
Q22 |
0.7 [0.7] |
0.3 [0.4] |
0.4 [0.4] |
119m |
0.5 |
|
load |
3m30 |
1m42 |
1m42 |
6m57 |
3m10 |
|
MonetDB is somewhat slower |
|
|
|
MonetDB is >10x faster |
|
|
|
Takes >1hr to run |
|
|
|
Error, empty result |
|
|
Although set out as a small-scale experiment to assess our SQL implementation functionality, we were pleasantly surprised by the performance and scalability. Some observations on the results shown:
- ConfirmationThe results obtained align with our experience in more detailed sciences studies (see ourscience library). Some additional results are available at theMySQL performance blogand thePostgresql performance blog.
- ScalabilityMonetDB was designed from a main-memory perspective, but its performance shows it is capable to grow well beyond the main memory capacity. Scale-factor 10 and 20 makes the database size larger than the available main memory. All systems experience dramatic increase in IO behavior.
- TuningThe performance figures of PostgreSQL and MySQL can be improved by throwing database expertise at the problem. Buffer spaces may be tuned, configuration files tweaked, additional indices may be introduced, etc.. However, such expertise does not belong to the average user. He will experience a fast system provided the database remains small and the queries are not too complex.
- Bulk loadingThe loading time is largely determined by the amount of data read/written. Turning the transaction logger off improves the performance significantly. Furthermore, PostgreSQL and MonetDB ensure database consistency by checking all referential constraints as well. This is ignored by MySQL.
- ValidationThe results produced by PostgreSQL for queries 4,5,6,10,12,14,15,20 do not conform. to the requirements of TPC-H. They produce erroneous or empty results.
The MonetDB system was built from CVS sources, using the same setup as for the binary release, i.e., configured with "--disable-debug --enable-optimize --disable-assert" and compiled with gcc 4.1.2. The SQL optimizer included the novel dataflow optimizer, but not the recycler. Each MonetDB series was run twice consecutively. The timings where obtained using mclient -lsql -t. For PostgreSQL and MySQL we ran the series once.
|
TPCH scale factor 0.01, timing in msec |
|
|
MonetDB/SQL |
PostgreSQL |
MySQL |
|
Q1 |
19 [135] |
385 |
207 |
|
Q2 |
4 [27] |
10 |
17 |
|
Q3 |
6 [73] |
29 |
78 |
|
Q4 |
7 [44] |
16 |
23 |
|
Q5 |
5 [14] |
19 |
133 |
|
Q6 |
2 [4] |
40 |
42 |
|
Q7 |
6 [13] |
26 |
33 |
|
Q8 |
4 [14] |
31 |
11 |
|
Q9 |
8 [55] |
82 |
48 |
|
Q10 |
6 [21] |
18 |
76 |
|
Q11 |
3 [5] |
18 |
9 |
|
Q12 |
6 [17] |
44 |
40 |
|
Q13 |
32 [59] |
35 |
52 |
|
Q14 |
2 [5] |
35 |
15 |
|
Q15 |
3 [7] |
52 |
75 |
|
Q16 |
5 [9] |
38 |
48 |
|
Q17 |
2 [28] |
11 |
6 |
|
Q18 |
6 [11] |
66 |
|
|
Q19 |
11 [23] |
47 |
9 |
|
Q20 |
8 [12] |
879 |
8 |
|
Q21 |
13 15] |
136 |
17 |
|
Q22 |
5 [8] |
659 |
9 |
|
load |
0m0.5 |
0m0.8 |
0m0.7 |
|
MonetDB is somewhat slower |
|
MonetDB is >10x faster |
|
Takes >1hr to run |
|
Error, empty result |
|
TPCH scale factor 1, timing in seconds |
|
|
MonetDB/SQL |
PostgreSQL |
MySQL |
|
Q1 |
1.2 [1.2] |
38.2 |
20.4 |
|
Q2 |
0.05 [1.4] |
0.5 |
0.7 |
|
Q3 |
0.5 [1.8] |
11.8 |
7.9 |
|
Q4 |
0.4 [1.6] |
0.6 |
1.3 |
|
Q5 |
0.3 [0.7] |
0.4 |
12.9 |
|
Q6 |
0.1 [0.1] |
2.7 |
3.6 |
|
Q7 |
0.2 [0.3] |
5.4 |
3.8 |
|
Q8 |
0.2 [0.8] |
3.2 |
0.8 |
|
Q9 |
0.5 [3.3] |
21.1 |
5.2 |
|
Q10 |
0.3 [1.8] |
0.5 |
7.7 |
|
Q11 |
0.03 [0.8] |
0.59 |
0.26 |
|
Q12 |
0.3 [0.8] |
3.7 |
3.4 |
|
Q13 |
3.1 [3.2] |
4.7 |
5.6 |
|
Q14 |
0.1 [0.1] |
2.7 |
18 |
|
Q15 |
0.1 [0.4] |
2.6 |
6.9 |
|
Q16 |
0.3 [0.6] |
5.1 |
5.3 |
|
Q17 |
0.2 [0.5] |
164m |
0.6 |
|
Q18 |
0.5 [0.7] |
27 |
|
|
Q19 |
0.7 [1.3] |
4.4 |
0.18 |
|
Q20 |
0.3 [0.3] |
255m |
0.2 |
|
Q21 |
0.9 [1.1] |
24 |
3.5 |
|
Q22 |
0.1 [0.3]0.9 |
29m |
0.27 |
|
load |
0m47 |
4m29 |
1m25 |
|
MonetDB is somewhat slower |
|
MonetDB is >10x faster |
|
Takes >1hr to run |
|
Error, empty result |
|
TPCH scale factor 2, timing in seconds |
|
|
|
MonetDB/SQL |
|
|
PostgreSQL |
MySQL |
|
|
stable |
current |
recycler |
|
|
|
Q1 |
6.2 [6.3] |
2.2 [2.2] |
0.8 [2.2] |
76 |
41 |
|
Q2 |
0.14 [0.2] |
0.07 [0.08] |
0.08 [0.16] |
1 |
26 |
|
Q3 |
2.6 [2.6] |
1.1 [1.0] |
0.01 [1.2] |
20 |
16 |
|
Q4 |
2.2 [2.2] |
0.9 [0.9] |
0.002 [0.9] |
1.2 |
2.6 |
|
Q5 |
1.3 [1.2] |
0.7 [0.8] |
0.002 [0.8] |
0.8 |
27 |
|
Q6 |
0.5 [0.5] |
0.2 [0.3] |
0.003 [0.3] |
5.2 |
7 |
|
Q7 |
1.8 [1.8] |
0.7 [0.8] |
0.2 [0.5] |
8.7 |
8 |
|
Q8 |
0.7 [0.7] |
0.4 [0.4] |
0.003 [0.2] |
6.9 |
1.5 |
|
Q9 |
1.7 [1.8] |
0.6 [0.6] |
0.04 [0.9] |
53 |
11 |
|
Q10 |
1.7 [1.7] |
0.7 [0.7] |
0.02 [0.8] |
0.9 |
18 |
|
Q11 |
0.2 [0.2] |
0.06 [0.06] |
0.06 [0.06] |
1.1 |
0.5 |
|
Q12 |
1.3 [1.3] |
0.6 [0.6] |
0.3 [0.7] |
7 |
6.9 |
|
Q13 |
8.1 [8.0] |
3.3 [3.3] |
1.0 [3.3] |
19.2 |
9.9 |
|
Q14 |
0.4 [0.3] |
0.2 [0.2] |
0.008 [0.2] |
5 |
38 |
|
Q15 |
0.3 [0.3] |
0.1 [0.2] |
0.03 [0.2] |
5 |
13 |
|
Q16 |
1.1 [1.1] |
0.5 [0.5] |
0.4 [0.5] |
12.9 |
11 |
|
Q17 |
1.3 [1.3] |
0.6 [0.6] |
0.006 [0.6] |
|
1.2 |
|
Q18 |
1.7 [1.7] |
0.9 [0.9] |
0.004 [0.9] |
52 |
|
|
Q19 |
3.6 [3.7] |
1.4 [1.4] |
1.3 [1.5] |
8 |
0.327 |
|
Q20 |
1.2 [1.2] |
0.4 [0.4] |
0.4 [0.4] |
|
0.4 |
|
Q21 |
7.6 [7.6] |
2.2 [2.2] |
2.0 [0.4] |
49 |
7.3 |
|
Q22 |
0.7 [0.7] |
0.3 [0.4] |
0.4 [0.4] |
119m |
0.5 |
|
load |
3m30 |
1m42 |
1m42 |
6m57 |
3m10 |
|
MonetDB is somewhat slower |
|
|
|
MonetDB is >10x faster |
|
|
|
Takes >1hr to run |
|
|
|
Error, empty result |
|
|
|
TPCH scale factor 5, timing in seconds |
|
|
MonetDB/SQL |
PostgreSQL |
MySQL |
|
Q1 |
8.3 [9.6] |
192 |
102 |
|
Q2 |
0.2 [2.4] |
23 |
629 |
|
Q3 |
4.3 [11] |
157 |
156 |
|
Q4 |
2.3 [6.8] |
16.6 |
13 |
|
Q5 |
2.1 [5.0] |
2.9 |
73 |
|
Q6 |
0.6 [0.6] |
62 |
18 |
|
Q7 |
3.2 [3.2] |
125 |
21 |
|
Q8 |
1.1 [3.8] |
93 |
4.2 |
|
Q9 |
3.0 [6.8] |
765 |
29 |
|
Q10 |
1.9 [15] |
3.3 |
135 |
|
Q11 |
0.2 [0.3] |
11.6 |
1.3 |
|
Q12 |
1.5 [3.8] |
78 |
17 |
|
Q13 |
17 [18] |
43 |
25 |
|
Q14 |
0.6 [0.6] |
73 |
93 |
|
Q15 |
0.4 [1.9] |
29 |
34 |
|
Q16 |
1.4 [1.7] |
56 |
28 |
|
Q17 |
1.5 [2.7] |
|
3 |
|
Q18 |
2.5 [3.3] |
351 |
|
|
Q19 |
3.9 [6.7] |
45 |
0.8 |
|
Q20 |
1.3 [1.4] |
|
1.4 |
|
Q21 |
5.6 [5.8] |
166 |
18 |
|
Q22 |
0.9 [1.1] |
|
1.3 |
|
load |
6m50 |
25m14 |
8m42 |
|
MonetDB is somewhat slower |
|
MonetDB is >10x faster |
|
Takes >1hr to run |
|
Error, empty result |
|
TPCH scale factor 10, timing in seconds |
|
|
MonetDB/SQL |
PostgreSQL |
MySQL |
|
Q1 |
40 [42] |
510 |
203 |
|
Q2 |
7 [5.3] |
54 |
1586 |
|
Q3 |
22 [24] |
798 |
393 |
|
Q4 |
11 [15] |
35 |
122 |
|
Q5 |
12 [12] |
5.5 |
15538 |
|
Q6 |
1.3 [1.2] |
172 |
62 |
|
Q7 |
6.1 [5.7] |
439 |
6680 |
|
Q8 |
9.3 [9.2] |
251 |
939 |
|
Q9 |
15.8 [16] |
2240 |
8169 |
|
Q10 |
19 [39] |
6.1 |
924 |
|
Q11 |
0.7 [0.7] |
25 |
689 |
|
Q12 |
9.6 [12] |
179 |
106 |
|
Q13 |
48[83] |
140 |
496 |
|
Q14 |
1.4[1.4] |
169 |
5850 |
|
Q15 |
3.1 [3.1] |
168 |
71 |
|
Q16 |
5.0 [4.4] |
115 |
58 |
|
Q17 |
6.5[5.7] |
|
8 |
|
Q18 |
17 [19] |
882 |
|
|
Q19 |
14 [15] |
218 |
5 |
|
Q20 |
4.4 [3.1] |
|
744 |
|
Q21 |
20 [48] |
477 |
4426 |
|
Q22 |
5.2 [3.3] |
|
4 |
|
load |
14m31 |
63m04 |
17m07 |
|
MonetDB is somewhat slower |
|
MonetDB is >10x faster |
|
Takes >1hr to run |
|
Error, empty result |
|
TPCH scale factor 20, timing in seconds |
|
|
MonetDB/SQL |
PostgreSQL |
MySQL |
|
Q1 |
326 [298] |
1009 |
|
|
Q2 |
21 [14] |
171 |
|
|
Q3 |
88 [95] |
424 |
|
|
Q4 |
38 [43] |
77 |
|
|
Q5 |
76 [64] |
10 |
|
|
Q6 |
36 [36] |
301 |
|
|
Q7 |
11 [9] |
1268 |
|
|
Q8 |
29 [25] |
639 |
|
|
Q9 |
257 [296] |
8098 |
|
|
Q10 |
180 [166] |
42 |
|
|
Q11 |
6.7 [5] |
68 |
|
|
Q12 |
61 [60] |
328 |
|
|
Q1, , 3 |
99 [90] |
357 |
|
|
Q14 |
80 [81] |
386 |
|
|
Q15 |
30 [29] |
429 |
|
|
Q16 |
13 [14] |
279 |
|
|
Q17 |
32 [85] |
|
|
|
Q18 |
88 [67] |
1521 |
|
|
Q19 |
47 [51] |
589 |
|
|
Q20 |
20 [37] |
|
|
|
Q21 |
115 [110] |
906 |
|
|
Q22 |
11 [11] |
|
|
|
load |
45m00 |
123m16 |
|
|
MonetDB is somewhat slower |
|
MonetDB is >10x faster |
|
Takes >1hr to run |
|
Error, empty result |
TPC-H是一種決策支持基準(zhǔn)。它包含一整套面向商業(yè)的特殊查詢(xún)和并發(fā)數(shù)據(jù)修改內(nèi)容。該基準(zhǔn)中選擇的查詢(xún)和數(shù)據(jù)庫(kù)中的數(shù)據(jù)都具有廣泛的全行業(yè)關(guān)聯(lián)性。這種測(cè)試基準(zhǔn)所描述的決策支持系統(tǒng)可檢查大量的數(shù)據(jù)，所執(zhí)行的查詢(xún)也具有很高的復(fù)雜度。
TPC-H所報(bào)告的性能計(jì)量單位被稱(chēng)為“TPC-H復(fù)合式每小時(shí)查詢(xún)性能單位”（TPC-H Composite Query-per-Hour Performance Metric - QphH@Size），反映的是系統(tǒng)處理查詢(xún)的多方面能力，包括查詢(xún)執(zhí)行時(shí)選定的數(shù)據(jù)庫(kù)大小、單個(gè)流提交查詢(xún)時(shí)的查詢(xún)處理能力，以及多個(gè)并發(fā)用戶(hù)提交查詢(xún)時(shí)的查詢(xún)吞吐量。TPC-H的價(jià)格/性能比計(jì)量單位的表達(dá)方式為$/QphH@Size。
4：TPC-E
TPC組織（交易處理性能委員會(huì)，Transaction Processing Performance Council）卻宣布推出新的TPC-E，以取代有14年歷史的TPC-C。TPC-E這一全新的數(shù)據(jù)庫(kù)服務(wù)器評(píng)測(cè)標(biāo)準(zhǔn)開(kāi)始受到越來(lái)越多人的關(guān)注.
“TPC-C與TPC-E相比，哪一個(gè)更權(quán)威、更實(shí)用？”這是一個(gè)縈繞在很多剛剛接觸TPC-E的人的腦海中的一個(gè)基本問(wèn)題。也許你會(huì)說(shuō)，如果TPC-E不夠好，TPC組織為什么要用它來(lái)取代TPC-C呢？但不可否認(rèn)的一個(gè)事實(shí)是，TPC-C從1992年起已經(jīng)實(shí)行了16年，而TPC-E從去年3月推出還只有一年半的時(shí)間，很多用戶(hù)知道TPC-C，卻不了解TPC-E。我想要解決這個(gè)問(wèn)題，首先得分析一下TPC組織為什么要用TPC-E來(lái)取代TPC-C。
原因主要有兩個(gè)：一是TPC-C的模型已經(jīng)老化，二是TPC-C的測(cè)試成本太高。
TPC-C的模型還是十幾年前的東西——過(guò)時(shí)的C/S架構(gòu)，模擬的是批發(fā)商系統(tǒng)，簡(jiǎn)單的數(shù)據(jù)庫(kù)和業(yè)務(wù)邏輯。而當(dāng)今WEB2.0時(shí)代的OLTP應(yīng)用，大多采用流行的B/S架構(gòu)，需要更大規(guī)模的并行處理能力，數(shù)據(jù)庫(kù)和業(yè)務(wù)邏輯也更加復(fù)雜。顯然，如果再用過(guò)去的模型來(lái)模擬今天的應(yīng)用環(huán)境，確實(shí)顯得有些不合時(shí)宜了。
為此，TPC-E對(duì)模型進(jìn)行大刀闊斧的創(chuàng)新——模擬證券經(jīng)紀(jì)公司而不是批發(fā)商的流量和交易模式，從C/S架構(gòu)過(guò)渡到B/S架構(gòu)，數(shù)據(jù)類(lèi)型從原來(lái)的3種擴(kuò)展到10種，事務(wù)類(lèi)型從原來(lái)的5種增加到12種，數(shù)據(jù)表由原來(lái)的9個(gè)增加到了33個(gè)，數(shù)據(jù)庫(kù)構(gòu)成更加復(fù)雜，也更加符合實(shí)際應(yīng)用，當(dāng)然對(duì)服務(wù)器的性能要求也更高了。
表1：TPC-E與TPC-C數(shù)據(jù)庫(kù)比較
再來(lái)看看TPC-C的測(cè)試成本。由于TPC-C的模型比較簡(jiǎn)單，服務(wù)器在測(cè)試時(shí)只是做一些簡(jiǎn)單的數(shù)據(jù)查詢(xún)、修改和刪除操作；而在多核計(jì)算盛行的今天，針對(duì)這種應(yīng)用，強(qiáng)大的服務(wù)器CPU容易處于等待數(shù)據(jù)的空閑狀態(tài)，I/O因而成為嚴(yán)重瓶頸。為了提升I/O，保證測(cè)試性能，服務(wù)器廠商往往需要?jiǎng)佑么罅康膬?nèi)存和磁盤(pán)。比如IBM和惠普公司在獲得最高分的TPC-C測(cè)試時(shí)都使用了7000塊硬盤(pán)。這使得參加TPC-C測(cè)試所需要的成本高達(dá)千萬(wàn)美元。如此巨額成本大大提高了TPC-C的門(mén)檻，將很多小型服務(wù)器廠商拒之門(mén)外。而且，從用戶(hù)角度來(lái)看，實(shí)際應(yīng)用可能并不需要如此海量的內(nèi)存和磁盤(pán)，TPC-C結(jié)果的適用性也受到了質(zhì)疑。
而TPC-E則不同。由于數(shù)據(jù)庫(kù)更加復(fù)雜，要執(zhí)行的事務(wù)處理更多——TPC-E標(biāo)準(zhǔn)中定義的事務(wù)有12種，每個(gè)事務(wù)對(duì)應(yīng)數(shù)據(jù)庫(kù)管理系統(tǒng)中的一個(gè)或多個(gè)帶輸入和輸出參數(shù)的存儲(chǔ)過(guò)程，而且會(huì)涉及到不同表間的關(guān)聯(lián)，這使得服務(wù)器CPU容易處在“有事可做”的狀態(tài)，因而對(duì)內(nèi)存和磁盤(pán)I/O的要求也相對(duì)小一些。浪潮服務(wù)器方案技術(shù)經(jīng)理喬鑫告訴IT168記者，TPC-C的硬件投入比TPC-E要高出3倍以上，由于TPC-E所需要的磁盤(pán)數(shù)量?jī)H是TPC-C的十分之一，從而大大降低了服務(wù)器廠商搭建硬件環(huán)境的成本。
圖6: TPC-E測(cè)試模型之物理結(jié)構(gòu)
TPC組織負(fù)責(zé)TPC-E推廣的安德里亞斯此前在接受媒體采訪時(shí)也曾表示，新測(cè)試費(fèi)用比較廉價(jià)的部分原因是對(duì)硬件的要求更加合理了，另外一個(gè)原因就是TPC將提供軟件的源代碼，取代了要求測(cè)試人員自己編寫(xiě)代碼。
可見(jiàn)，模型更新和成本降低讓我們看到了TPC-E新標(biāo)準(zhǔn)的魅力：更加逼近現(xiàn)實(shí)，更有代表性，會(huì)更具廣泛性。
TPC-E對(duì)用戶(hù)有什么參考價(jià)值
那么，對(duì)于用戶(hù)來(lái)說(shuō)，在實(shí)際采購(gòu)數(shù)據(jù)庫(kù)服務(wù)器過(guò)程中，又如何來(lái)理解和看待TPC-E的測(cè)試結(jié)果呢？
由于數(shù)據(jù)庫(kù)的應(yīng)用一般有兩種，一種是OLTP，即在線聯(lián)機(jī)事務(wù)處理，另一種是數(shù)據(jù)挖掘。就目前來(lái)說(shuō)，OLTP仍然是主流應(yīng)用。所以從一定程度來(lái)說(shuō)，TPC-E的結(jié)果對(duì)于數(shù)據(jù)庫(kù)系統(tǒng)采購(gòu)都有一定的參考價(jià)值，比如銀行、證券、稅務(wù)報(bào)稅系統(tǒng)、電子商務(wù)網(wǎng)站、電信業(yè)務(wù)等都是比較典型的OLTP應(yīng)用。英特爾服務(wù)器性能市場(chǎng)經(jīng)理高豐告訴IT168，雖然不同用戶(hù)的應(yīng)用環(huán)境各不相同，TPC-E無(wú)法提供一一對(duì)應(yīng)的方案，但其結(jié)果對(duì)采購(gòu)決策還是有重要的方向性指導(dǎo)意義。
與TPC-C一樣，TPC-E的測(cè)試結(jié)果也主要有兩個(gè)指標(biāo)：性能指標(biāo)（tpsE，transactions per second E)和性?xún)r(jià)比（成本/tpsE）。其中，前者是指系統(tǒng)在執(zhí)行多種交易時(shí)，每秒鐘可以處理多少交易，指標(biāo)值越大越好；后者則是指系統(tǒng)價(jià)格與前一指標(biāo)的比值，數(shù)值越小越好。
比如，某系統(tǒng)TPC-E測(cè)試值達(dá)到700tpsE，這意味著什么呢？對(duì)此，喬鑫告訴記者，700tpsE相當(dāng)于這樣一種應(yīng)用環(huán)境：有36萬(wàn)用戶(hù)同時(shí)在線，每分鐘處理42萬(wàn)個(gè)事務(wù)，每分鐘進(jìn)行107萬(wàn)個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)過(guò)程，每天（8小時(shí)）處理2億個(gè)事務(wù)，5.08億個(gè)數(shù)據(jù)庫(kù)存儲(chǔ)過(guò)程，90%以上的交易事務(wù)最長(zhǎng)也只需不到3秒就能完成，應(yīng)用的數(shù)據(jù)規(guī)模在3TB左右。
圖7:TPC-E測(cè)試模型之邏輯結(jié)構(gòu)
當(dāng)然，光有性能還不夠，畢竟用戶(hù)環(huán)境千差萬(wàn)別，這時(shí)可以借助“成本/tpsE”這樣一個(gè)性?xún)r(jià)比指標(biāo)，然后根據(jù)自己的預(yù)算和要求，計(jì)算出需要多大規(guī)模的系統(tǒng)。
對(duì)于OLTP應(yīng)用來(lái)說(shuō)，除了性能和性?xún)r(jià)比，系統(tǒng)的可靠性和可用性也是非常關(guān)鍵的因素。雖然TPC無(wú)法給出一個(gè)量化的指標(biāo)，但卻是通過(guò)測(cè)試過(guò)程規(guī)范機(jī)制來(lái)保障系統(tǒng)的可靠性。
英特爾高級(jí)服務(wù)器性能工程師汪亞光介紹說(shuō)，對(duì)于每個(gè)參加測(cè)試的廠商，TPC組織都會(huì)派出一位評(píng)審專(zhuān)家到現(xiàn)場(chǎng)監(jiān)督，審查系統(tǒng)是否進(jìn)行了數(shù)據(jù)保護(hù)，軟硬件配置是否正確，磁盤(pán)損壞的情況下能否保證業(yè)務(wù)正常運(yùn)行。比如有這樣一個(gè)環(huán)節(jié)，當(dāng)負(fù)載壓力達(dá)到95%峰值時(shí)，在沒(méi)有UPS保護(hù)的情況下，把所有服務(wù)器電源都拔掉，檢測(cè)系統(tǒng)還能否正常恢復(fù)，數(shù)據(jù)完整性能否得到保障，數(shù)據(jù)是否會(huì)丟失——這對(duì)于系統(tǒng)的穩(wěn)定可靠性是非常嚴(yán)峻的考驗(yàn)。
另外，要求保證測(cè)試結(jié)果穩(wěn)定、連續(xù)運(yùn)行兩個(gè)小時(shí)以上，性能指標(biāo)不能出現(xiàn)超出5%以上的波動(dòng)。要知道在實(shí)際應(yīng)用環(huán)境中，很少有系統(tǒng)會(huì)在峰值狀態(tài)下連續(xù)運(yùn)轉(zhuǎn)兩個(gè)小時(shí)。同時(shí)，高并發(fā)訪問(wèn)量和數(shù)據(jù)響應(yīng)時(shí)間等因素也有嚴(yán)格的限制，在10種業(yè)務(wù)處理中，系統(tǒng)延遲最大不能超過(guò)3秒。因此，能夠參加TPC-E測(cè)試，從側(cè)面也能夠證明服務(wù)器廠商在高端商用市場(chǎng)上的綜合技術(shù)實(shí)力。
表2：TPC-E測(cè)試模型
哪些因素會(huì)影響TPC-E測(cè)試結(jié)果
跟SPEC CPU這類(lèi)測(cè)試不同，TPC-E測(cè)試不僅僅是服務(wù)器某一方面的性能，而是評(píng)測(cè)整體方案的應(yīng)用性能，這個(gè)方案是包括服務(wù)器、存儲(chǔ)、OS、數(shù)據(jù)庫(kù)等軟硬件在內(nèi)的一整套系統(tǒng)。浪潮喬鑫表示，“為了保證系統(tǒng)性能，在服務(wù)器、存儲(chǔ)、操作系統(tǒng)、數(shù)據(jù)庫(kù)軟件等各個(gè)子系統(tǒng)上就不能出現(xiàn)短板。服務(wù)器廠商要做的是系統(tǒng)優(yōu)化，即怎么讓軟件和硬件可以更好的配合，怎么讓服務(wù)器和后端的存儲(chǔ)進(jìn)行更好的整合?！?/FONT>
也就是說(shuō)，不同廠商選擇不同的CPU、存儲(chǔ)、OS、數(shù)據(jù)庫(kù)，都有可能會(huì)對(duì)TPC-E的最終測(cè)試結(jié)果產(chǎn)生影響。這里，我們比較了參加TPC-E測(cè)試的幾套四路服務(wù)器系統(tǒng)，發(fā)現(xiàn)六核系統(tǒng)比四核性能表現(xiàn)好，8GB光纖SAN存儲(chǔ)比4GB光纖要好，操作系統(tǒng)和數(shù)據(jù)庫(kù)軟件的升級(jí)也會(huì)對(duì)TPC-E性能產(chǎn)生影響。
比如，四路服務(wù)器中，得分最高的三款采用的都是英特爾將在9月下旬正式發(fā)布的六核Dunnington至強(qiáng) X7460。大體來(lái)看，四路六核系統(tǒng)的TPC-E性能比四路四核要高出50%左右，比四路雙核更是高出3倍多。如Dell PowerEdge R900 四核版本的成績(jī)是451.29，六核版本是671.35，相比之下提高了48%。記者就此向英特爾高豐進(jìn)行求證，他表示，對(duì)于尚未發(fā)布的產(chǎn)品還不便于評(píng)論，但多核架構(gòu)對(duì)于大規(guī)模并行處理確實(shí)有很大幫助。
再來(lái)看看存儲(chǔ)方面。IBM System x3850 M2在去年和今年參加了兩次測(cè)試，服務(wù)器配置都是四路四核Xeon X7350 2.93GHz處理器和128GB內(nèi)存，但結(jié)果卻不一樣，從第一次的419.80 tpsE提升到了479.51tpsE，增長(zhǎng)了14%。究其原因就在于，這兩次參測(cè)方案使用了不同的存儲(chǔ)、數(shù)據(jù)庫(kù)軟件和服務(wù)器操作系統(tǒng)。第一次用的是4GB光纖SAN存儲(chǔ)、 SQL Server 2005 和Windows Server 2003，而第二次使用的是8GB光纖SAN存儲(chǔ)、 SQL Server 2008和Windows Server 2008。
又比如，浪潮NF520D2 和Dell PowerEdge R900 都是最新的四路六核系統(tǒng)，都使用了SQL Server 2008和Windows Server 2008，但前者使用了128GB內(nèi)存，后者使用了64GB內(nèi)存，在后端存儲(chǔ)的選擇上也有差異，使得浪潮NF520D2的性能高出了5%左右。
可見(jiàn)，TPC-E看的不僅僅是CPU的性能，服務(wù)器系統(tǒng)設(shè)計(jì)、操作系統(tǒng)與數(shù)據(jù)庫(kù)軟件、存儲(chǔ)架構(gòu)等都非常關(guān)鍵。
小結(jié)
盡管TPC-E的權(quán)威性和適用性已毋庸置疑，但畢竟只推出了一年半的時(shí)間。所以，現(xiàn)在參加TPC-E測(cè)試的廠商數(shù)量和軟硬件類(lèi)別還不夠豐富多樣，比如參加評(píng)測(cè)的16套系統(tǒng)采用的全是英特爾至強(qiáng)處理器，看不到AMD的平臺(tái)；HP、SUN等廠商還沒(méi)有參與進(jìn)來(lái)；操作系統(tǒng)選用的都是Windows，還沒(méi)有Linux；數(shù)據(jù)庫(kù)軟件也只有SQL Server，而沒(méi)有Oracle；很多用戶(hù)還不了解TPC-E。但不管怎樣，作為一個(gè)完全開(kāi)放的第三方平臺(tái)，我們有理由相信TPC-E會(huì)向TPC-C一樣發(fā)展和成熟起來(lái)。 | 
