TPC-C 벤치마크는 tpc.org에서 표준으로 제정한 OLTP 트랜잭션 시스템에 대한 벤치마크 테스트입니다. 많은 DBMS 업체에서 이 TPC-C 벤치마크를 이용해서 OLTP 시스템에 대한 성능 평가를 진행합니다. tpc.org에 해당 문서를 살펴보면 약 130 페이지에 달하는 내용이 있는데 오늘은 이 내용에 대해서 정리해 보겠습니다.
Table Of Contents
1. 논리적인 데이터베이스 설계
TPC Benchmark™ C는 복잡한 OLTP 애플리케이션 환경을 대표하는 방식으로 시스템 기능을 실행하도록 설계된 일련의 기본 작업으로 구성되어 있습니다.
시스템 기능을 실행하도록 설계된 일련의 기본 작업으로 구성되어 있습니다. 이러한 기본 작업은 사용자가 벤치마크의 구성 요소를 직관적으로 이해할 수 있도록 도매 공급업체의 활동을 묘사하는 실제와 같은 컨텍스트가 부여되었습니다.
워크로드는 주문 처리 활동에 중점을 두고 있으며 논리적 데이터베이스 설계를 제공합니다,
TPC-C는 특정 비즈니스 부문의 활동이 아니라 제품이나 서비스를 관리, 판매 또는 유통해야 하는 모든 산업(예: 렌터카, 식품 유통, 부품 공급 등)을 대표합니다.
벤치마크에 묘사된 회사는 가상 회사로 지리적으로 분산된 여러 판매 지역과 관련 창고를 보유한 도매 공급업체입니다. 회사의 비즈니스가 확장됨에 따라 새로운 창고와 관련 판매 지역이 만들어집니다. 각 지역 창고는 10개 지역을 담당합니다. 각 지역은 3,000명의 고객에게 서비스를 제공합니다. 모든 창고는 회사가 판매하는 100,000개의 품목에 대한 재고를 유지합니다. 다음 다이어그램은 TPC-C의 비즈니스 환경의 창고, 지역구 및 고객 계층 구조를 보여줍니다.
고객은 회사에 전화하여 새 주문을 하거나 기존 주문의 상태를 요청합니다. 주문은 평균 10개의 주문 라인(order lines)(즉, 품목: line items)으로 구성됩니다. 전체 주문 라인의 1%는 지역 창고에 재고가 없어 다른 창고에서 공급해야 하는 품목에 대한 주문입니다.
또한 회사의 시스템은 고객의 결제를 입력하고, 배송 주문을 처리하고, 재고 수준을 조사하여 잠재적인 공급 부족을 파악하는 데 사용됩니다.
2. 데이터베이스 구성 요소 (ER-Diagram과 속성)
TPC-C 데이터베이스의 구성 요소는 9개의 개별적인 테이블로 구성되도록 정의되어 있습니다.
이러한 테이블 간의 관계는 아래에 표시된 엔티티 관계 다이어그램에 정의되어 있으며 다음과 같은 규칙이 적용됩니다.
- 표시된 모든 숫자는 데이터베이스 모집단 요구 사항을 나타냅니다(4.3절 참조).
- 엔티티 블록의 숫자는 테이블의 카디널리티(행 수)를 나타냅니다. 이 숫자는창고 수인 W를 곱하여 데이터베이스 사이즈가(scaleing factor) 결정될 수 있습니다. (4절 참조).
- 관계 화살표 옆의 숫자는 관계의 카디널리티(부모 레코드 당 평균 자식 레코드 수)를 나타냅니다.
- 더하기(+) 기호는 관계 또는 테이블의 카디널리티 뒤에 사용되어 행이 추가되거나 삭제될 때 이 숫자가 측정 간격 동안 초기 데이터베이스와 달라질 수 있음을 나타냅니다. (5.5절 참조).
3. 테이블 스키마 및 레이아웃
테이블 레이아웃
테이블 레이아웃을 소개하기전에 테이블 레이아웃 표기에 나타난 항목에 대한 설명을 아래에 먼저 설명드립니다.
- N unique IDs: 속성(컬럼,필드)이 최소 N개의 유니크 ID 집합 내에서 하나의 ID를 보유할 수 있어야 함을 의미합니다. 쉽게 이야기하면, N개의 레코드에서 유일값을 갖는 ID가 되어야 한다는 의미입니다.
- variable text, size N: 속성이 가변 길이의 문자 문자열을 포함할 수 있어야 함을 의미합니다.
만약 속성(컬럼)이 고정 길이 문자열로 저장되어 있다면 저장된 문자열이 N 문자보다 짧으면 보다 짧으면 공백으로 채워야 합니다. (*하지만, 일반적으로 varchar를 사용하는 경우에는 공백을 채울 필요는 없습니다. )
- fixed text, size N: 속성이 고정 길이 N의 모든 문자 문자열을 포함할 수 있어야 함을 의미합니다.
- date and time: 날짜 및 시간은 시간 구성 요소를 포함하는 날짜 값의 데이터 유형을 나타냅니다. 날짜 구성 요소는 1900년 1월 1일에서 2100년 12월 31일 사이의 날짜를 포함할 수 있어야 합니다. 시간 구성 요소는 다음과 같아야 합니다. 00:00:00~23:59:59의 시간 값 범위를 최소 1초 단위로 나타낼 수 있어야 합니다. 날짜 및 시간은 해당 용도에 맞게 DBMS에서 정의한 데이터 유형을 사용하여 구현해야 합니다.
- numeric(m [,n]): 총 소수점 자릿수가 m 이상인 부호 없는 숫자 값으로, 이 중 소수점 오른쪽(뒤)에 n 자리가 있는 값을 의미합니다. 이 속성은 numeric(m,n)으로 표현할 수 있는 모든 가능한 값을 포함할 수 있어야 합니다. numeric(m)에서와 같이 n을 생략하면 numeric(m,0)과 동일한 값을 나타냅니다. 화폐 값을 포함하는 숫자 필드(W_YTD, D_YTD, C_CREDIT_LIM, C_BALANCE, C_YTD_PAYMENT, H_AMOUNT, OL_AMOUNT, I_PRICE)는 DBMS에서 정확한 numeric 데이터 타입으로 정의하거나 정확한 숫자 표현의 ANSI SQL 표준 정의를 충족하는 데이터 타입을 사용해야 합니다.
- signed numeric(m [,n]): 양수 및 음수 값을 모두 나타낼 수 있다는 점을 제외하면 숫자(m [,n])와 동일합니다.
- null: 주어진 속성(컬럼)에 대해 유효한 값의 범위를 벗어난 것을 의미하며 항상 동일한 값을 의미합니다.
아래에 테이블 레이아웃과 주석이 있으니 참고하면 됩니다.
[ WAREHOUSE Table Layout ]
Field Name Field Definition Comments
W_ID 2*W unique IDs W Warehouses are populated
W_NAME variable text, size 10
W_STREET_1 variable text, size 20
W_STREET_2 variable text, size 20
W_CITY variable text, size 20
W_STATE fixed text, size 2
W_ZIP fixed text, size 9
W_TAX signed numeric(4,4) Sales tax
W_YTD signed numeric(12,2) Year to date balance
Primary Primary Key: W_ID
[ DISTRICT Table Layout ]
Field Field Definition Comments
D_ID 20 unique IDs 10 are populated per warehouse
D_W_ID 2*W unique IDs
D_NAME variable text, size 10
D_STREET_1 variable text, size 20
D_STREET_2 variable text, size 20
D_CITY variable text, size 20
D_STATE fixed text, size 2
D_ZIP fixed text, size 9
D_TAX signed numeric(4,4) Sales tax
D_YTD signed numeric(12,2) Year to date balance
D_NEXT_O_ID 10,000,000 unique IDs Next available Order number
Primary Key: (D_W_ID, D_ID)
D_W_ID Foreign Key, references W_ID
[ CUSTOMER Table Layout ]
Field Field Definition Comments
C_ID 96,000 unique IDs 3,000 are populated per district
C_D_ID 20 unique IDs
C_W_ID 2*W unique IDs
C_FIRST variable text, size 16
C_MIDDLE fixed text, size 2
C_LAST variable text, size 16
C_STREET_1 variable text, size 20
C_STREET_2 variable text, size 20
C_CITY variable text, size 20
C_STATE fixed text, size 2
C_ZIP fixed text, size 9
C_PHONE fixed text, size 16
C_SINCE date and time
C_CREDIT fixed text, size 2 GC=good, BC=bad
C_CREDIT_LIM signed numeric(12, 2)
C_DISCOUNT signed numeric(4, 4)
C_BALANCE signed numeric(12, 2)
C_YTD_PAYMENT signed numeric(12, 2)
C_PAYMENT_CNT numeric(4)
C_DELIVERY_CNT numeric(4)
C_DATA variable text, size 500 Miscellaneous information
Primary Key: (C_W_ID, C_D_ID, C_ID)
(C_W_ID, C_D_ID) Foreign Key, references (D_W_ID, D_ID)
[ HISTORY Table Layout ]
Field Name Field Definition Comments
H_C_ID 96,000 unique IDs
H_C_D_ID 20 unique IDs
H_C_W_ID 2*W unique IDs
H_D_ID 20 unique IDs
H_W_ID 2*W unique IDs
H_DATE date and time
H_AMOUNT signed numeric(6, 2)
H_DATA variable text, size 24 Miscellaneous information
Primary Key: none
(H_C_W_ID, H_C_D_ID, H_C_ID) Foreign Key, references (C_W_ID, C_D_ID, C_ID)
(H_W_ID, H_D_ID) Foreign Key, references (D_W_ID, D_ID)
Comment: Rows in the History table do not have a primary key as, within the context of
benchmark, there is no need to uniquely identify a row within this table.
Note: The TPC-C application does not have to be capable of utilizing the increased range of C_ID
values beyond 6,000.00
[ NEW-ORDER Table Layout ]
Field Field Definition Comments
NO_O_ID 10,000,000 unique IDs
NO_D_ID 20 unique IDs
NO_W_ID 2*W unique IDs
Primary Key: (NO_W_ID, NO_D_ID, NO_O_ID)
(NO_W_ID, NO_D_ID, NO_O_ID) Foreign Key, references (O_W_ID, O_D_ID, O_ID)
[ ORDER Table Layout ]
Field Field Definition Comments
O_ID 10,000,000 unique IDs
O_D_ID 20 unique IDs
O_W_ID 2*W unique IDs
O_C_ID 96,000 unique IDs
O_ENTRY_D date and time
O_CARRIER_ID 10 unique IDs, or null
O_OL_CNT numeric(2) Count of Order-Lines
O_ALL_LOCAL numeric(1)
Primary Key: (O_W_ID, O_D_ID, O_ID)
(O_W_ID, O_D_ID, O_C_ID) Foreign Key, references (C_W_ID, C_D_ID, C_ID)
[ ORDER-LINE Table Layout ]
Field Name Field Definition Comments
OL_O_ID 10,000,000 unique IDs
OL_D_ID 20 unique IDs
OL_W_ID 2*W unique IDs
OL_NUMBER 15 unique IDs
OL_I_ID 200,000 unique IDs
OL_SUPPLY_W_ID 2*W unique IDs
OL_DELIVERY_D date and time, or null
OL_QUANTITY numeric(2)
OL_AMOUNT signed numeric(6, 2)
OL_DIST_INFO fixed text, size 24
Primary Key: (OL_W_ID, OL_D_ID, OL_O_ID, OL_NUMBER)
(OL_W_ID, OL_D_ID, OL_O_ID) Foreign Key, references (O_W_ID, O_D_ID, O_ID)
(OL_SUPPLY_W_ID, OL_I_ID) Foreign Key, references (S_W_ID, S_I_ID)
[ ITEM Table Layout ]
Field Name Field Definition Comments
I_ID 200,000 unique IDs 100,000 items are populated
I_IM_ID 200,000 unique IDs Image ID associated to Item
I_NAME variable text, size 24
I_PRICE numeric(5, 2)
I_DATA variable text, size 50 Brand information
Primary Key: I_ID
[ STOCK Table Layout ]
Field Field Definition Comments
S_I_ID 200,000 unique IDs 100,000 populated per warehouse
S_W_ID 2*W unique IDs
S_QUANTITY signed numeric(4)
S_DIST_01 fixed text, size 24
S_DIST_02 fixed text, size 24
S_DIST_03 fixed text, size 24
S_DIST_04 fixed text, size 24
S_DIST_05 fixed text, size 24
S_DIST_06 fixed text, size 24
S_DIST_07 fixed text, size 24
S_DIST_08 fixed text, size 24
S_DIST_09 fixed text, size 24
S_DIST_10 fixed text, size 24
S_YTD numeric(8)
S_ORDER_CNT numeric(4)
S_REMOTE_CNT numeric(4)
S_DATA variable text, size 50 Make information
Primary Key: (S_W_ID, S_I_ID)
S_W_ID Foreign Key, references W_ID
S_I_ID Foreign Key, references I_IDmysql 또는 mariadb tpc-c 테이블 DDL
위의 테이블 레이아웃을 통해 작성된 실제 mariadb에 적용하는 테이블에 대한 DDL을 작성해 보았습니다.
CREATE TABLE IF NOT EXISTS WAREHOUSE (
W_ID SMALLINT DEFAULT '0' NOT NULL,
W_NAME VARCHAR(16) DEFAULT NULL,
W_STREET_1 VARCHAR(32) DEFAULT NULL,
W_STREET_2 VARCHAR(32) DEFAULT NULL,
W_CITY VARCHAR(32) DEFAULT NULL,
W_STATE VARCHAR(2) DEFAULT NULL,
W_ZIP VARCHAR(9) DEFAULT NULL,
W_TAX FLOAT DEFAULT NULL,
W_YTD FLOAT DEFAULT NULL,
CONSTRAINT W_PK_ARRAY PRIMARY KEY (W_ID)
);
CREATE TABLE IF NOT EXISTS DISTRICT (
D_ID TINYINT DEFAULT '0' NOT NULL,
D_W_ID SMALLINT DEFAULT '0' NOT NULL REFERENCES WAREHOUSE (W_ID),
D_NAME VARCHAR(16) DEFAULT NULL,
D_STREET_1 VARCHAR(32) DEFAULT NULL,
D_STREET_2 VARCHAR(32) DEFAULT NULL,
D_CITY VARCHAR(32) DEFAULT NULL,
D_STATE VARCHAR(2) DEFAULT NULL,
D_ZIP VARCHAR(9) DEFAULT NULL,
D_TAX FLOAT DEFAULT NULL,
D_YTD FLOAT DEFAULT NULL,
D_NEXT_O_ID INT DEFAULT NULL,
PRIMARY KEY (D_W_ID,D_ID)
);
CREATE TABLE IF NOT EXISTS ITEM (
I_ID INTEGER DEFAULT '0' NOT NULL,
I_IM_ID INTEGER DEFAULT NULL,
I_NAME VARCHAR(32) DEFAULT NULL,
I_PRICE FLOAT DEFAULT NULL,
I_DATA VARCHAR(64) DEFAULT NULL,
CONSTRAINT I_PK_ARRAY PRIMARY KEY (I_ID)
);
CREATE TABLE IF NOT EXISTS CUSTOMER (
C_ID INTEGER DEFAULT '0' NOT NULL,
C_D_ID TINYINT DEFAULT '0' NOT NULL,
C_W_ID SMALLINT DEFAULT '0' NOT NULL,
C_FIRST VARCHAR(32) DEFAULT NULL,
C_MIDDLE VARCHAR(2) DEFAULT NULL,
C_LAST VARCHAR(32) DEFAULT NULL,
C_STREET_1 VARCHAR(32) DEFAULT NULL,
C_STREET_2 VARCHAR(32) DEFAULT NULL,
C_CITY VARCHAR(32) DEFAULT NULL,
C_STATE VARCHAR(2) DEFAULT NULL,
C_ZIP VARCHAR(9) DEFAULT NULL,
C_PHONE VARCHAR(32) DEFAULT NULL,
C_SINCE TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
C_CREDIT VARCHAR(2) DEFAULT NULL,
C_CREDIT_LIM FLOAT DEFAULT NULL,
C_DISCOUNT FLOAT DEFAULT NULL,
C_BALANCE FLOAT DEFAULT NULL,
C_YTD_PAYMENT FLOAT DEFAULT NULL,
C_PAYMENT_CNT INTEGER DEFAULT NULL,
C_DELIVERY_CNT INTEGER DEFAULT NULL,
-- C_DATA VARCHAR(1000),
C_DATA TEXT(500),
PRIMARY KEY (C_W_ID,C_D_ID,C_ID),
UNIQUE (C_W_ID,C_D_ID,C_LAST,C_FIRST)
-- CONSTRAINT C_FKEY_D FOREIGN KEY (C_W_ID, C_D_ID) REFERENCES DISTRICT (D_W_ID, D_ID)
);
CREATE INDEX IDX_CUSTOMER ON CUSTOMER (C_W_ID,C_D_ID,C_LAST);
CREATE TABLE IF NOT EXISTS HISTORY (
H_C_ID INTEGER DEFAULT NULL,
H_C_D_ID TINYINT DEFAULT NULL,
H_C_W_ID SMALLINT DEFAULT NULL,
H_D_ID TINYINT DEFAULT NULL,
H_W_ID SMALLINT DEFAULT '0' NOT NULL,
H_DATE TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
H_AMOUNT FLOAT DEFAULT NULL,
H_DATA VARCHAR(32) DEFAULT NULL
-- CONSTRAINT H_FKEY_C FOREIGN KEY (H_C_W_ID, H_C_D_ID, H_C_ID) REFERENCES CUSTOMER (C_W_ID,C_D_ID,C_ID) ,
-- CONSTRAINT H_FKEY_D FOREIGN KEY (H_W_ID, H_D_ID) REFERENCES DISTRICT (D_W_ID, D_ID)
);
CREATE TABLE IF NOT EXISTS STOCK (
S_I_ID INTEGER DEFAULT '0' NOT NULL REFERENCES ITEM (I_ID),
S_W_ID SMALLINT DEFAULT '0 ' NOT NULL REFERENCES WAREHOUSE (W_ID),
S_QUANTITY INTEGER DEFAULT '0' NOT NULL,
S_DIST_01 VARCHAR(32) DEFAULT NULL,
S_DIST_02 VARCHAR(32) DEFAULT NULL,
S_DIST_03 VARCHAR(32) DEFAULT NULL,
S_DIST_04 VARCHAR(32) DEFAULT NULL,
S_DIST_05 VARCHAR(32) DEFAULT NULL,
S_DIST_06 VARCHAR(32) DEFAULT NULL,
S_DIST_07 VARCHAR(32) DEFAULT NULL,
S_DIST_08 VARCHAR(32) DEFAULT NULL,
S_DIST_09 VARCHAR(32) DEFAULT NULL,
S_DIST_10 VARCHAR(32) DEFAULT NULL,
S_YTD INTEGER DEFAULT NULL,
S_ORDER_CNT INTEGER DEFAULT NULL,
S_REMOTE_CNT INTEGER DEFAULT NULL,
S_DATA VARCHAR(64) DEFAULT NULL,
PRIMARY KEY (S_W_ID,S_I_ID)
);
CREATE TABLE IF NOT EXISTS ORDERS (
O_ID INTEGER DEFAULT '0' NOT NULL,
O_C_ID INTEGER DEFAULT NULL,
O_D_ID TINYINT DEFAULT '0' NOT NULL,
O_W_ID SMALLINT DEFAULT '0' NOT NULL,
O_ENTRY_D TIMESTAMP DEFAULT CURRENT_TIMESTAMP NOT NULL,
O_CARRIER_ID INTEGER DEFAULT NULL,
O_OL_CNT INTEGER DEFAULT NULL,
O_ALL_LOCAL INTEGER DEFAULT NULL,
PRIMARY KEY (O_W_ID,O_D_ID,O_ID),
UNIQUE (O_W_ID,O_D_ID,O_C_ID,O_ID)
-- CONSTRAINT O_FKEY_C FOREIGN KEY (O_W_ID, O_D_ID, O_C_ID) REFERENCES CUSTOMER (C_W_ID,C_D_ID,C_ID)
);
CREATE INDEX IDX_ORDERS ON ORDERS (O_W_ID,O_D_ID,O_C_ID);
CREATE TABLE IF NOT EXISTS NEW_ORDER (
NO_O_ID INTEGER DEFAULT '0' NOT NULL,
NO_D_ID TINYINT DEFAULT '0' NOT NULL,
NO_W_ID SMALLINT DEFAULT '0' NOT NULL,
CONSTRAINT NO_PK_TREE PRIMARY KEY (NO_D_ID,NO_W_ID,NO_O_ID)
-- CONSTRAINT NO_FKEY_O FOREIGN KEY (NO_W_ID, NO_D_ID, NO_O_ID) REFERENCES ORDERS (O_W_ID,O_D_ID,O_ID)
);
CREATE TABLE IF NOT EXISTS ORDER_LINE (
OL_O_ID INTEGER DEFAULT '0' NOT NULL,
OL_D_ID TINYINT DEFAULT '0' NOT NULL,
OL_W_ID SMALLINT DEFAULT '0' NOT NULL,
OL_NUMBER INTEGER DEFAULT '0' NOT NULL,
OL_I_ID INTEGER DEFAULT NULL,
OL_SUPPLY_W_ID SMALLINT DEFAULT NULL,
OL_DELIVERY_D TIMESTAMP DEFAULT NULL,
OL_QUANTITY INTEGER DEFAULT NULL,
OL_AMOUNT FLOAT DEFAULT NULL,
OL_DIST_INFO VARCHAR(32) DEFAULT NULL,
PRIMARY KEY (OL_W_ID,OL_D_ID,OL_O_ID,OL_NUMBER)
-- CONSTRAINT OL_FKEY_O FOREIGN KEY (OL_W_ID, OL_D_ID, OL_O_ID) REFERENCES ORDERS (O_W_ID, O_D_ID, O_ID )
-- CONSTRAINT OL_FKEY_S FOREIGN KEY (OL_I_ID, OL_SUPPLY_W_ID) REFERENCES STOCK (S_I_ID, S_W_ID)
);
--CREATE INDEX IDX_ORDER_LINE_3COL ON ORDER_LINE (OL_W_ID,OL_D_ID,OL_O_ID);
--CREATE INDEX IDX_ORDER_LINE_2COL ON ORDER_LINE (OL_W_ID,OL_D_ID);
CREATE INDEX IDX_ORDER_LINE_TREE ON ORDER_LINE (OL_W_ID,OL_D_ID,OL_O_ID);
구현 규칙
TPC-C 문서에 다음과 같이 구현 규칙이 설명되어 있습니다.
1. 데이터베이스 내에서 레코드의 물리적 클러스터링이 허용됩니다.
2. 논리적 읽기/쓰기를 피하기 위해 행을 다르게 표현하는 뷰(View)는 제외됩니다.
2번 조항의 목적은 애플리케이션이 보기를 사용하여 여러 연산을 하나로 결합하지 않고 트랜잭션 프로필에 정의된 의 논리 연산을 구현하도록 하는 것입니다.
3. 모든 테이블에는 데이터베이스 크기 요구 사항에 정의된 대로 적절하게 조정된 레코드 수가 있어야 합니다.
4. 테이블의 수평, 수직 분할, 즉 파티션이 허용됩니다. 테이블의 행 그룹을 다른 파일, 디스크 또는 영역에 할당할 수 있습니다. 이러한 파티셔닝을 구현하는 경우 해당 파티셔닝의 세부 정보를 공개해야 합니다.
위의 파티션에서 데이터의 논리적 구조에 대한 지식(예: 행 또는 속성 경계에 대한 지식)에 근거하지 않고 데이터를 다른 파일, 디스크 또는 영역에 할당하는 것은 파티셔닝으로 간주되지 않습니다. 예를 들어, 하나 이상의 논리 테이블을 저장하는 물리적 파일을 여러 디스크에 분산하거나 제거하는 것은 물리적 파일에 저장된 논리 구조에 대한 지식 없이 하드웨어 또는 운영 체제에 의해 수행되는 한 파티셔닝으로 간주되지 않습니다.
결론적으로, 데이터베이스에서 파티셔닝을 한 것을 제외하고는 파일을 분리하거나 하는 경우에는 파티셔닝으로 간주하지 않기 때문에 세부정보를 공개할 필요가 없습니다.
5. 모든 테이블에 대해 복제가 허용됩니다. 복제되는 테이블의 모든 사본 원자성, 일관성 및 격리 요건을 모두 충족해야 합니다. 복제가 구현된 경우 해당 복제에 대한 세부 정보를 공개해야 합니다.
복제된 테이블은 사본 중 하나만 지속성을 만족하면 됩니다.
6. 성능 개선과 관계없는 경우 속성(필드)을 추가하거나 중복시킬 수 있습니다.
7. 각 속성(필드)은 논리적으로 분리되어 있어야 하며 데이터 관리자가 독립적으로 액세스 할 수 있어야 합니다.
예를 들어, W_STREET_1과 W_STREET_2는 W_STREET로 합쳐질 수 없습니다.
또는, S_DATA는 S_DATA_1과 S_DATA_2로 나뉘어질 수 없습니다.
8. 각 테이블의 기본 키는 행의 물리적 디스크 주소나 그 오프셋을 직접 나타내서는 안 됩니다. 행은 단순히 저장 공간의 시작 부분에서 오프셋 되기 때문에 애플리케이션은 상대 주소 지정을 사용하여 행을 참조할 수 없습니다. 이는 일반적인 처리 과정에서 레코드를 추가, 삭제 및 수정하는 조항이 있는 해싱 체계 또는 기타 파일 조직을 배제하지 않습니다.
예외: History 테이블은 상대 주소 지정을 사용할 수 있지만 다른 모든 요구 사항이 적용됩니다.
이 조항의 의도는 트랜잭션을 실행하거나 트랜잭션 요청을 제출하는 애플리케이션 프로그램(2.1.7항 참조)이 모든 액세스에 물리적 ID 식별자가 아닌 논리적 식별자를 사용하고, 논리적 키를 관련 행의 테이블 내 위치로 번역하거나 번역을 보조하는 사용자 작성 코드를 포함하지 않도록 하는 것입니다.
예를 들어, 애플리케이션이 논리적 주소에서 물리적 주소로의 '번역 테이블'을 작성하여 성능 향상을 위해 사용하는 것은 합법적이지 않습니다.
내부 레코드 또는 행 식별자(예: 튜플 ID 또는 커서)는 다음과 같은 조건에서 사용할 수 있습니다.
실행된 각 트랜잭션에 대해 행에 대한 초기 액세스는 트랜잭션 프로필에 지정된 키를 통해 이루어져야 하며 다른 속성을 통해서는 안 됩니다. 초기 액세스에는 모든 행의 삽입, 삭제, 검색 및 업데이트가 포함됩니다.
9. 모든 테이블에서 삽입 및 삭제가 수행되는 것은 아니지만, 테스트 중에 이 사실을 특별히 활용하도록 시스템을 구성해서는 안 됩니다. 삽입은 본질적으로 구성된 시스템에서 사용 가능한 저장 공간에 의해 제한되지만, 테이블 카디널리티의 5%에 해당하는 최소 행 수와 해당 테이블에 존재하는 키 값 범위의 두 배 이상의 키 값을 사용하여 테이블에 삽입하는 데는 제한이 없어야 합니다.
추가 5% 테이블 카디널리티를 위한 공간은 테스트 실행을 위해 구성되고 그에 따라 가격이 책정되어야 합니다. 나중에 공간을 구성하고 동적으로 할당하는 시스템의 경우, 이 공간은 할당된 것으로 간주하고 가격을 책정할 때 정적 공간으로 포함해야 합니다.
10. 애플리케이션 프로그램의 일부로 수행되는 모든 계산의 최소 소수점 정밀도는 해당 계산의 모든 개별 항목의 최대 소수점 정밀도여야 합니다.
11. 테이블 속성 가변 텍스트, 고정 텍스트, 날짜 및 시간, 숫자는 해당 속성에 대해 정의된 유형의 데이터를 저장하는 것이 문서화된 목적인 데이터 관리 시스템(즉, 애플리케이션 프로그램이 아닌)의 기본 데이터 유형을 사용하여 구현해야 합니다. 예를 들어 날짜 및 시간은 날짜 및 시간 정보를 저장하도록 설계된 기본 데이터 유형으로 구현해야 합니다.
오늘은 데이터베이스의 성능을 측정하는 tpc.org의 표준 벤치마크인 tpc-c에 대해서 알아보았습니다.
해당 표준 문서는 130 페이지가량 되는데, 오늘은 그중 앞 부분의 개략적인 내용과 테이블 구조에 대해서 알아보았고, 구현 규칙까지 알아보았습니다.
전체 문서는 아래에 첨부하오니 참고하시고 추가 내용은 이어서 정리하도록 하겠습니다.
'IT' 카테고리의 다른 글
| 큐브리드(CUBRID) 로컬 접속시 Permission denied 에러 분석하고 처리하는 방법 (0) | 2024.03.25 |
|---|---|
| 레디스 오픈소스 종료 발표 - Redis 라이선스 변경 소식 Dual Source-Available Licensing에 대해서 (21) | 2024.03.22 |
| 파이썬을 활용한 NoSQL 몽고디비(MongoDB) 및 Redis TPCC 테스트 소개 및 python 코드 분석 과정 (0) | 2024.03.20 |
| 레디스(Redis) 서버 캐시 데이터베이스 데이터 타입의 이해와 명령어 예제 (파이썬 사용예) (0) | 2024.03.19 |
| 레디스(Redis) 파이프라이닝(Pipelining)이란? (0) | 2024.03.14 |
