문서번호 11-1706659
개요
이전 포스트에서 CC By 4.0 License 를 가지고 있는 Stefan Proell, Eva Zangerle, Wolfgang Gassler 가 만든 Flughafen DB가 원본인 airportdb 를 로딩했습니다.
이제 설치한 각 데이터베이스 별로 동일한 Query 를 수행하여 성능을 비교해 보겠습니다. 각 Query 는 Parsing 및 Buffer Cache miss 등의 성능상 오버헤드를 제거하고자 두 번씩 연속으로 수행하고 두번째 수행 결과를 확인합니다.
Query #1, Query #3, Query #4 는 MySQL Heatwave Quickstart Page 에서 예제로 사용하는 Query 이고 Query #2 는 Query #1 에서 필터 조건을 추가했습니다.
현재 장비의 사양은 8vCPU, 16GB Memory 입니다.
32GB Memory 사양에서의 동일한 테스트 결과는 아래 링크에서 확인할 수 있습니다.
Query #1
SELECT booking.price, count(*)
FROM booking WHERE booking.price > 500
GROUP BY booking.price
ORDER BY booking.price LIMIT 10;
SQL
복사
단위(s) | SingleStore | PostgreSQL | MySQL |
Query #1 | 0.29 | 2.766 | 19.34 |
Query #2
SELECT count(*)
FROM booking
WHERE booking.price > 500
AND seat like '24%';
SQL
복사
단위(s) | SingleStore | PostgreSQL | MySQL |
Query #1 | 0.03 | 2.628 | 15.45 |
Query #3
SingleStore / MySQL 용 SQL
SELECT airline.airlinename,
AVG(datediff(departure,birthdate)/365.25) as avg_age,
count(*) as nb_people
FROM booking, flight, airline, passengerdetails
WHERE booking.flight_id=flight.flight_id
AND airline.airline_id=flight.airline_id
AND booking.passenger_id=passengerdetails.passenger_id
AND country IN ("Germany", "Spain", "Greece")
GROUP BY airline.airlinename
ORDER BY airline.airlinename, avg_age
LIMIT 10;
SQL
복사
PostgreSQL 용 SQL
SELECT airline.airlinename,
AVG((departure-birthdate)/365.25) as avg_age,
count(*) as nb_people
FROM booking, flight, airline, passengerdetails
WHERE booking.flight_id=flight.flight_id
AND airline.airline_id=flight.airline_id
AND booking.passenger_id=passengerdetails.passenger_id
AND country IN ('Germany', 'Spain', 'Greece')
GROUP BY airline.airlinename
ORDER BY 1, 2
LIMIT 10;
SQL
복사
단위(s) | SingleStore | PostgreSQL | MySQL |
Query #1 | 1.06 | 3.032 | 37.63 |
Query #4
SingleStore / MySQL 용 SQLSELECT airline.airlinename,
SUM(booking.price) as price_tickets,
count(*) as nb_tickets
FROM booking, flight, airline, airport_geo
WHERE booking.flight_id=flight.flight_id
AND airline.airline_id=flight.airline_id
AND flight.from=airport_geo.airport_id
AND airport_geo.country = 'UNITED STATES'
GROUP BY airline.airlinename
ORDER BY 3 desc, 1
LIMIT 10;
SQL
복사
PostgreSQL 용 SQLSELECT airline.airlinename,
SUM(booking.price) as price_tickets,
count(*) as nb_tickets
FROM booking, flight, airline, airport_geo
WHERE booking.flight_id=flight.flight_id
AND airline.airline_id=flight.airline_id
AND flight.from_id=airport_geo.airport_id
AND airport_geo.country = 'UNITED STATES'
GROUP BY airline.airlinename
ORDER BY 3 desc, 1
LIMIT 10;
SQL
복사
단위(s) | SingleStore | PostgreSQL | MySQL |
Query #1 | 0.10 | 3.368 | 370.04 |
MySQL 조회 성능이 낮은 이유
각 Database 별 Query 실행 계획을 보면 MySQL 의 조회 성능이 낮게 나온 이유를 알 수 있습니다.
SingleStore 는 분산(Distributed) DB 이므로 원래 아키텍처상 병렬(Parallel) Query 가 기본적으로 수행됩니다. PostgreSQL 은 옵티마이저(Optimizer)가 병렬 쿼리 수행을 자동으로 결정하고 수행했습니다. MySQL 은 대량 데이터에 대해 Serial Scan 을 하기 때문에 Query 수행 속도가 늦을 수 밖에 없습니다.Query #2 의 각 데이터베이스별 실행 계획은 아래 그림과 같습니다.
마무리
16GB / 32GB Memory 장비에서의 동일한 테스트 결과입니다.
단위(s) | SingleStore | PostgreSQL | MySQL |
Query #1 (16GB) | 0.03 | 2.628 | 15.45 |
Query #1 (32GB) | 0.32 | 2.696 | 16.03 |
Query #2 (16GB) | 0.03 | 2.628 | 15.45 |
Query #2 (32GB) | 0.06 | 2.756 | 18.36 |
Query #3 (16GB) | 1.06 | 3.032 | 37.63 |
Query #3 (32GB) | 1.16 | 3.11 | 31.38 |
Query #4 (16GB) | 0.1 | 3.368 | 370.04 |
Query #4 (32GB) | 0.08 | 3.181 | 104.17 |
SingleStore 의 기본 Unit 크기는 Leaf Node 1개가 8 vCPU / 32GB Memory 입니다. 운영 환경의 최소 권장 크기는 4 Unit 으로 총 32 vCPU / 128GB Memory 입니다.
MySQL Heatwave Cluster 2-node (2*32 vCPU, 2*512GB Memory)를 사용했을 경우,
Query #1 은 0.0537초 정도 소요된다고 합니다. Query #3 은 0.1783초 정도 소요된다고 합니다. Query #4 는 0.2286초 정도 소요된다고 합니다.하지만 MySQL Heatwave Cluster node 하나의 컴퓨팅 파워(32vCPU, 512GB Memory) 를 고려해 보면 그보다 훨씬 작은 크기인 8vCPU, 16GB Memory 단일 장비에서 SingleStore 가 비슷한 성능을 기록하는 것을 볼 때, On-premises 에서 Commodity Server 설치 가능, 유연한 Scale In/Out 으로 인한 선형적인 성능 증가, AWS, Azure, GCP 등의 주요 CSP 에서 Managed Cloud 지원 등 비용, 성능, 관리 측면에서 SingleStore 의 장점이 많다고 생각됩니다.
이번 테스트는 16GB Memory 장비에 Master Aggregator 1개, Leaf Node 1개가 함께 설치된 Cluster-in-a-Box 형태에서 진행되었습니다. 권장 크기에 비해 현저하게 작은 크기의 클러스트 구성임에도 불구하고 대량 데이터 조회 성능이 다른 데이터베이스에 비해 크게 뛰어남을 알 수 있습니다.
다음 포스트에서는 http, https 프로토콜을 이용하여 SQL을 실행할 수 있게 하는 SingleStore 만의 Data API 에 대해 알아보겠습니다.
