· 10분

데이터베이스 실험실 - CHAR vs NUMERIC vs TIME

POSQTGRESQL에 시간 데이터를 넣고 호출하는데 있어 어느 타입이 더 효율적일까?

HH:MM의 시간 포멧을 놓고 각각 CHAR, NUMERIC, TIME 세 가지 타입에 넣어 실험해보았다. POSQTGRESQL은 13 버전을 이용하였다.

조건 1. 

,ALARM_TIME char(4)

첫 번째 조건은 HH:MM의 시간 포멧을 네 개의 CHAR로 넣는 형태이다. 04:30의 경우 ‘0430’으로 들어간다.

조건 2. 

,ALARM_HOUR numeric(2, 0) NOT NULL
    CHECK (0 <= ALARM_HOUR and ALARM_HOUR <= 23)
,ALARM_MIN numeric(2, 0) NOT NULL
    CHECK (0 <= ALARM_MIN and ALARM_MIN <= 59)

두 번째 조건은 두 개의 NUMERIC 컬럼에 시간을 나누어 담는 형태이다. 04:30의 경우 앞의 컬럼에 ‘4’가, 뒤에 컬럼에 ‘30’이 각각 나뉘어 들어간다.

조건 3.

,ALARM_TIME time NOT NULL

POSQTGRESQL에서 지원하는 TIME 데이터 타입을 그대로 사용하는 형태이다. 04:30의 경우 ‘04:30:00’으로 저장이 된다. 뒤에는 반드시 ‘00’일 것을 전제하여 호출 시에는 ‘04:30:00’와 정확히 매칭되는 결과물을 가져온다.

동일한 조건으로 구성하되, 보다 사실적인 환경 구성을 위해 USER_ID 컬럼과 MODIFIED_TIME 컬럼을 추가하였다.

각각 5000개의 row를 무작위로 생성해 넣은 뒤 00시 00분 부터 23시 59분까지 전체의 시간을 질의하여 가져오는 시간을 가져온다. 한번 싸이클에 1440회의 질의가 발생한다. 각각의 조건에 대해 10번씩 시도하여, 전체 평균을 구하도록 하겠다.

결과

전체 결과
-- alarm table 1 --
count: 5000
try 1: 26.156119346618652
count: 5000
try 2: 26.675641775131226
count: 5000
try 3: 25.536415815353394
count: 5000
try 4: 26.134907960891724
count: 5000
try 5: 26.375614166259766
count: 5000
try 6: 26.147720336914062
count: 5000
try 7: 25.97940969467163
count: 5000
try 8: 26.59768557548523
count: 5000
try 9: 26.10726761817932
count: 5000
try 10: 25.555443286895752
average: 26.126652979850768
-- alarm table 2 --
count: 5000
try 1: 27.78176712989807
count: 5000
try 2: 28.27575707435608
count: 5000
try 3: 28.567619562149048
count: 5000
try 4: 27.774380207061768
count: 5000
try 5: 28.072192430496216
count: 5000
try 6: 27.556775093078613
count: 5000
try 7: 28.35179305076599
count: 5000
try 8: 27.923873901367188
count: 5000
try 9: 28.38708519935608
count: 5000
try 10: 28.01127815246582
average: 28.070282173156738
-- alarm table 3 --
count: 5000
try 1: 26.133213996887207
count: 5000
try 2: 26.16308617591858
count: 5000
try 3: 26.199642419815063
count: 5000
try 4: 26.07395052909851
count: 5000
try 5: 25.948384284973145
count: 5000
try 6: 26.366111516952515
count: 5000
try 7: 25.966031551361084
count: 5000
try 8: 25.623215198516846
count: 5000
try 9: 25.9598867893219
count: 5000
try 10: 26.27301859855652
average: 26.070684099197386

조건 1 average: 26.126652979850768

조건 2 average: 28.070282173156738

조건 3 average: 26.070684099197386

눈에 띄는 것은 ‘조건 2’에서 시간이 다른 조건에 비해 2초가 늦어지는 점이다. 조회하는 컬럼이 두 개라서 시간이 지연되는 것으로 짐작된다. 흥미로운 점은, 캐릭터 4만을 사용하는 조건 1보다도 TIME 데이터 타입을 사용하는 조건 3이 약 0.5초 정도 앞선다는 것이다.

이번에는 row의 개수를 십만개로 늘려 적용해보았다. 반복 횟수 역시 각각 20번으로 늘렸다.

전체결과
-- alarm table 1 --
try 1: 49.7254912853241
try 2: 46.3009729385376
try 3: 46.4652533531189
try 4: 45.91221594810486
try 5: 49.378690242767334
try 6: 49.91247344017029
try 7: 49.37316608428955
try 8: 49.696730852127075
try 9: 49.3984112739563
try 10: 48.69150996208191
try 11: 49.45136594772339
try 12: 50.06901669502258
try 13: 49.74210596084595
try 14: 49.26009392738342
try 15: 50.01587390899658
try 16: 50.19118285179138
try 17: 49.86866998672485
try 18: 50.08266472816467
try 19: 49.106056451797485
try 20: 49.522252559661865
average: 49.10826389789581
-- alarm table 2 --
try 1: 66.98592329025269
try 2: 66.49290442466736
try 3: 63.25885629653931
try 4: 64.06613063812256
try 5: 63.3563506603241
try 6: 64.6199848651886
try 7: 63.98414373397827
try 8: 64.18078875541687
try 9: 64.31526279449463
try 10: 64.02151012420654
try 11: 64.07046294212341
try 12: 63.84868574142456
try 13: 64.07298874855042
try 14: 64.08221626281738
try 15: 63.90463852882385
try 16: 63.61009621620178
try 17: 64.52658748626709
try 18: 62.94241213798523
try 19: 64.85735058784485
try 20: 63.55243444442749
average: 64.23751240968704
-- alarm table 3 --
try 1: 41.83094239234924
try 2: 44.932230949401855
try 3: 44.792407274246216
try 4: 44.53584957122803
try 5: 44.88702201843262
try 6: 44.57245588302612
try 7: 44.692646503448486
try 8: 43.89505863189697
try 9: 44.2195839881897
try 10: 44.22889471054077
try 11: 45.12163472175598
try 12: 44.2561240196228
try 13: 44.0642147064209
try 14: 45.43576169013977
try 15: 45.286035776138306
try 16: 43.428226947784424
try 17: 43.472302198410034
try 18: 44.39334988594055
try 19: 44.21790099143982
try 20: 43.478670597076416
average: 44.287118303775785
[Finished in 3152.7s]

조건 1 average: 49.10826389789581

조건 2 average: 64.23751240968704

조건 3 average: 44.287118303775785

5천개에서 10만개로 ‘스므배’ 정도로 분량을 늘리니, 조회 시간이 약 2배 정도 늘어났다. 분량이 늘어나면서 조회 시간에 대한 차이가 도드라지는데, 조건 1에 비해 조건 2가 15초나 더 늘어났다. 흥미로운 점은 조건 1에 비해 조건 3이 약 5초 정도 더 빠르다는 점이다.

결론1. 포스트그래스큐엘이 ‘시간 컬럼’은 알아서 최적화를 잘 해주니, 시간 관련해서는 시간 관련 데이터 타입을 사용하자.

결론2. 컬럼이 10만개 이상 쌓이는 환경이 아닌 이상, 실제 조회 시간에 대한 차이가 얼마 나지 않는다. 자료형 간의 차이는 실제로 소소한 범위이다.

홈으로