Firebird 성능 저하: 테스트, 신화와 진실
Alexey Kovyazin, 2014년 5월 16일
이 문서는 PDF 형식으로 다운로드할 수 있습니다.
최근 IBSurgeon에서 우리는 Firebird 2.5.2로 일련의 성능 테스트를 수행했습니다. Firebird 2.5.2는 Firebird 데이터베이스의 가장 인기 있는 버전이며, 사용자들은 Firebird 성능과 관련된 질문을 자주 합니다.
데이터베이스 성능과 관련된 가장 중요한 우려 사항 중 하나는 성능 저하입니다. 많은 사용자가 특정 임계값(3Gb, 5Gb, RAM 크기, 20Gb 등)에 도달하면 데이터베이스 애플리케이션에 성능 문제가 발생한다고 주장합니다. 가장 일반적인 주장은 “데이터베이스 크기가 RAM 크기보다 크다"는 것입니다. Firebird 데이터베이스 크기가 RAM 크기에 도달하면 매우 느려진다고 보고됩니다… 과연 그럴까요?
우리는 데이터베이스 성장과 관련된 이러한 성능 저하가 실제로 존재하는지 확인하기 위해 일련의 테스트를 수행하기로 결정했습니다. 동일한 하드웨어에서 동일한 부하로 데이터베이스의 수명 주기 성장을 시뮬레이션하기로 했으며, 이를 위해 9Gb에서 30Gb 사이의 크기를 가진 데이터베이스로 11개의 테스트를 실행했습니다:
그림 1. 테스트용 데이터베이스 크기
테스트 하드웨어 및 Firebird 구성
테스트 하드웨어의 주요 특성은 다음과 같습니다:
CPU AMD-FX8350, RAM 16GB, SATA 소프트웨어 RAID1 2x4Tb Seagate 드라이브, 운영 체제 Windows Server 2008R2 (2008R2는 64비트).
보시다시피, 이는 저사양 하드웨어 구성입니다. 현재(2014년 5월) 기준으로 USD 1000 미만으로 구매할 수 있으며, 대용량 SATA 드라이브를 제외하면 일반적인 저사양 구성으로 간주할 수 있습니다. 다만 제조업체 보고서에 따르면 1Tb와 4Tb SATA 드라이브의 속도는 거의 동일합니다.
테스트의 목표는 일반적인 시스템의 성능 변화를 측정하는 것이었으므로, 우리는 소규모 회사의 상황을 완전히 시뮬레이션하기 위해 Firebird (64비트) SuperServer 아키텍처를 사용했습니다. Classic이 아닌 SuperServer를 사용한 이유는 소규모 회사에서는 원래 설치된 것을 수년간 사용하기 때문입니다. 아시다시피 SuperServer는 CPU 코어 1개만 사용하므로, Classic이나 SuperClassic(모든 CPU 코어를 사용할 수 있음)이 성능 측면에서 더 나은 결과를 보여줄 수 있지만, 우리의 목표는 성능 튜닝이 아니었습니다.
그러나 우리는 모든 Firebird SuperServer 설치에 권장하는 명백한 변경 사항으로 firebird.conf를 튜닝했습니다: 페이지 버퍼를 10000으로 늘리고 정렬을 위한 임시 공간을 늘렸습니다.
모든 테스트 데이터베이스는 일관성을 위해 페이지 크기 16384로 생성되었습니다.
테스트
로딩
각 테스트는 2단계로 구성되었습니다: 로딩과 삽입, 업데이트, 삭제를 수행하는 20개 터미널의 시뮬레이션입니다.
로딩 단계는 여러 테이블에 데이터를 삽입하는 로더 애플리케이션(load.exe)에 의해 수행됩니다. 그림 2에서 볼 수 있듯이 데이터는 서로 다른 속도로 로드됩니다. 약 35Mb/초에서 1Mb/초까지 다양합니다.
그림 2. 데이터베이스 로딩 속도 (빨간색 그래프)
이는 Firebird가 아닌 로더 애플리케이션의 설계와 관련이 있습니다: 로더는 데이터베이스의 70%를 빠르게 삽입한 다음 나머지 데이터를 천천히 채웁니다. 이는 모든 크기의 데이터베이스에서 반복됩니다. 로더가 동일한 작업을 수행하는 것이 중요하므로 평균 속도를 사용하여 로딩 속도를 측정할 수 있습니다.
로더는 데이터만 삽입하고 인덱스는 로드가 완료된 후 생성된다는 점을 말하는 것이 중요합니다.
9Gb에서 30Gb 사이의 11개 데이터베이스에 대한 로딩 단계 결과 표를 살펴보겠습니다:
| # | 데이터베이스 크기, gb | 로드 시간, 초 | SATA 로드 속도, Mb/초 |
|---|---|---|---|
| 1 | 9,04 | 2535 | 3,65166075 |
| 2 | 10,80 | 3197 | 3,45924304 |
| 3 | 13,00 | 4057 | 3,281242297 |
| 4 | 15,50 | 4698 | 3,378458919 |
| 5 | 17,30 | 5455 | 3,24751604 |
| 6 | 19,90 | 6037 | 3,375451383 |
| 7 | 21,60 | 6473 | 3,417024564 |
| 8 | 24,20 | 7539 | 3,287014193 |
| 9 | 26,00 | 7779 | 3,422547885 |
| 10 | 28,60 | 8851 | 3,308823862 |
| 11 | 30,30 | 9266 | 3,348499892 |
그림 3. 로딩 시간 및 속도
또는 그림 4의 그래프로 표시하는 것이 더 좋습니다:
그림 4. 테스트 결과: 로딩 속도.
보시다시피 상당히 안정적인 그래프이며, 로딩 프로세스의 평균 속도는 약 3.3-3.4Mb/초로 다양합니다. 데이터베이스 크기가 RAM 크기보다 커질 때(17.3Gb 크기의 데이터베이스 #5 이후) 로딩 속도가 감소하는 징후도 없습니다.
성능
로딩 시간은 상당히 유망해 보입니다. 실제 성능 결과는 어떨까요?
성능 결과를 살펴보기 전에 시뮬레이션 프로세스를 간단히 검토해 보겠습니다.
시뮬레이션은 20개의 스레드를 실행하며, 각 스레드는 여러 비즈니스 작업(새 주문 생성, 결제 처리, 재고 제품 수 계산, 주문 배송 처리 등)을 무작위로 실행합니다(자세한 내용은 실제 저장 프로시저의 SQL 텍스트를 참조할 수 있습니다). 보시다시피 이는 추상적인 재고/판매 애플리케이션의 일반적인 비즈니스 작업 집합입니다.
테스트 애플리케이션은 초당 비즈니스 작업 수를 측정하고 평균 값을 보고합니다. 물론 이 숫자는 인위적인 매개변수이지만 비교하기에는 충분합니다.
성능 테스트 결과:
| # | 데이터베이스 크기, gb | SATA에서의 성능 |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
그림 5. 성능 테스트 결과 표.
또는 그래픽 표현으로 결과를 보는 것이 더 좋습니다:
그림 6. 성능 결과 그래프
보시다시피 데이터베이스 크기가 커질수록 성능이 천천히 저하됩니다 - 데이터베이스가 클수록 (동일한 하드웨어에서) 더 느리게 작동합니다. 데이터베이스 크기가 RAM보다 커질 때 큰 성능 저하도 없습니다. 데이터베이스가 9Gb에서 30Gb로 성장하면 약 20%의 성능 손실이 발생합니다.
30Gb Firebird 데이터베이스는 지금 어디에나 있으며 시간이 지남에 따라 계속 성장합니다. 그러나 데이터베이스가 더 커지면 성능은 어떻게 될까요? 우리는 더 크게! 데이터베이스가 정말 커지면 성능은 어떻게 될까요?
Mr.Big
이 질문에 답하기 위해 우리는 테스트 표의 맨 끝을 살펴보고 동일한 하드웨어, 동일한 설정으로 1.7Tb(1813Gb) 데이터베이스로 테스트를 수행하기로 결정했습니다.
로딩
그래서 우리는 그러한 데이터베이스를 만들었습니다:
그림 7. 데이터베이스 크기 - 이제 1813Gb 데이터베이스 포함
로딩에는 566448초 - 157시간, 6.55일이 걸렸습니다. 오랜 시간이지만 평균 로드 속도는… 3.28Mb/초였습니다!
| # | 데이터베이스 크기, gb | 로드 시간, 초 | SATA 로드 속도, Mb/초 |
|---|---|---|---|
| 12 | 1813,969025 | 566448 | 3,279214122 |
그림 8. 1.7Tb Firebird 데이터베이스의 로딩 시간 및 속도
그래프에서 매우 좋아 보입니다: 마지막 지점(#12). 따라서 Firebird는 삽입 알고리즘에서 매우 좋은 결과를 보여줍니다.
그림 9. 로딩 속도 - 지점 #12는 1.7Tb Firebird 데이터베이스용
Mr.Big의 성능
그런 다음 동일한 성능 테스트를 실행했습니다 - 12행은 1.7Tb 데이터베이스용입니다.
| # | 데이터베이스 크기, gb | SATA에서의 성능 |
|---|---|---|
| 1 | 9,04 | 494,73 |
| 2 | 10,80 | 491,94 |
| 3 | 13,00 | 480,36 |
| 4 | 15,50 | 469,11 |
| 5 | 17,30 | 446,42 |
| 6 | 19,90 | 431,61 |
| 7 | 21,60 | 426,85 |
| 8 | 24,20 | 424,5 |
| 9 | 26,00 | 414,04 |
| 10 | 28,60 | 409,14 |
| 11 | 30,30 | 407,97 |
| 12 | 1813,969025 | 169,33 |
그림 10. 성능 테스트 결과 - 12행은 1.7Tb 데이터베이스용
그래프에서:
그림 11. 성능, 포인트 #12는 1.7Tb 데이터베이스
결과는 Firebird에서 느리지만 안정적인 성능 저하가 있음을 확인합니다 - 데이터베이스 크기가 60배(30Gb에서 1813Gb로) 증가하는 동안 성능 손실은 2.4배(407에서 169포인트)였습니다.
동일한 저사양 하드웨어에서 데이터베이스가 30Gb에서 1.7Tb로 성장하는 것은 흔한 상황이 아니지만, Firebird는 이러한 상황에서도 작동할 것입니다.
대용량 데이터베이스 상세 분석
1.7Tb 데이터베이스를 더 잘 이해하기 위해 Mr.Big 데이터베이스의 통계를 수집하고 IBAnalyst에서 분석했습니다:
그림 12. IBAnalyst의 1.7Tb 데이터베이스 테이블
보시다시피, 2개의 큰 테이블이 있습니다 - 63억 개의 레코드가 있는 ORDER_LINE (~600Gb)과 21억 개의 레코드가 있는 STOCK (~680Gb)입니다.
그리고 이 테이블들에는 깊이 = 4인 인덱스 2개가 있습니다 - 이는 모든 요청이 실제 데이터를 읽기 전에 인덱스 페이지를 4번 읽는다는 것을 의미합니다. ORDER_LINE_PK 인덱스는 50Gb 크기입니다.
그림 13. Firebird 1.7Tb 데이터베이스의 인덱스
엄청난 수의 레코드에도 불구하고 데이터베이스 통계는 양호해 보이므로, Firebird가 저사양 하드웨어에서도 대용량 데이터베이스에 대해 꽤 좋은 결과를 보여주는 것은 놀라운 일이 아닙니다.
SSD 드라이브로 Firebird 테스트
저사양 하드웨어에서 일련의 Firebird 테스트를 완료한 후, 우리는 데이터 저장 기술의 다른 측면에서 결과가 어떨지 확인하기로 결정하고 동일한 서버에 SSD 드라이브를 설치했습니다.
Plextor PX-256M M5 Pro SSD 드라이브를 설치하고 동일한 설정으로 동일한 테스트 시리즈(1.7Tb 데이터베이스 제외)를 실행했습니다. 결과는 SATA 장치가 있는 그래프에 추가되었으며, 아래에서 확인할 수 있습니다.
로딩
보시다시피, SSD에서의 로딩 시간은 SATA와 동일합니다. 이는 예상된 결과입니다: 순차 쓰기 작업의 속도는 SATA와 SSD 드라이브에서 거의 동일합니다.
그림 14. SSD 및 SATA에서의 로딩
성능
성능 결과를 확인하세요:
그림 15. SSD 및 SATA에서의 성능
보시다시피, 무작위 IO 작업의 성능은 SSD 드라이브에서 약 8배 더 나은 결과를 보여줍니다. 우리는 고객 데이터베이스 경험을 통해 SSD가 실제 애플리케이션에서 30-50% 더 빠르다는 것을 알고 있었지만, 8배 증가는 매우 높은 수치입니다.
그러나 이 테스트는 인위적이며 많은 업데이트/삭제가 있지만 대량 페치가 없는 높은 부하의 OLTP 작업을 시뮬레이션하도록 특별히 설계되었습니다. 일반적인 데이터베이스 애플리케이션은 항상 이 모드로 작동하지 않습니다. 이것이 SSD가 이 특정 경우에如此 높은 결과를 보여주는 이유를 설명합니다.
요약
그렇다면, 이 테스트에서 우리가 배운 것은 무엇입니까?
우선 - Firebird의 성능은 특정 크기 제한과 관련된 큰 감소가 없습니다. 동일한 하드웨어에서 성능은 데이터베이스 크기가 증가함에 따라 천천히 감소합니다. 이러한 성능 저하는 Firebird 구성 튜닝이나 스마트한 하드웨어 업그레이드로 보완할 수 있습니다.
IBSurgeon이 Firebird 성능 최적화 서비스를 제공한다는 점을 언급하기 좋은 시점입니다 - 이와 같은 테스트에서 수집한 실험 데이터를 사용하여 Firebird 및 InterBase 데이터베이스의 성능을 크게 향상시킬 수 있습니다.
또한, 매우 큰 Firebird 데이터베이스(1.7테라바이트)도 저사양 하드웨어에서 상당하지만 허용 가능한 성능 손실로 작동한다는 것을 알게 되었습니다.
셋째, SSD는 OLTP 애플리케이션에 정말 좋습니다. 아마도 현재 데이터베이스 성능을 업그레이드하는 가장 저렴한 방법일 것입니다. 물론 SSD를 사용한다고 해서 잘못된 쿼리 계획이나 비효율적인 인덱스 문제가 해결되지는 않지만, 전반적인 성능을 향상시킬 수 있습니다.