성능만으로는 부족함

 (motherduck.com)
2P by GN⁺ | ★ favorite | 댓글 1개
  • 데이터베이스 선택에서 원시 쿼리 속도와 범용 벤치마크만 보면 사용자가 질문에서 답까지 도달하는 전체 시간을 놓치기 쉬움
  • 2019년 GigaOm 벤치마크는 Azure Data Warehouse와 Redshift를 앞세웠지만, 실제 시장에서는 Snowflake와 BigQuery가 더 잘 팔리며 성능 외 요소의 힘을 보여줌
  • 서버 실행 시간을 줄여도 JDBC 드라이버, 결과 다운로드, CSV 파싱, SQL 작성 난이도 같은 주변 경로가 더 큰 병목이 될 수 있음
  • ClickBench, TPC-H, TPC-DS는 유용하지만 JOIN 유무, 단일 테이블 스캔, 스키마 튜닝, 정확성·ACID 보장 조건에 따라 결론이 달라짐
  • 데이터베이스 엔진 성능은 시간이 지나며 수렴하므로, 장기 선택 기준은 현재 순위보다 아이디어에서 답까지의 속도와 워크플로 통합성이어야 함

벤치마크가 놓치는 실제 대기 시간

  • 시애틀 집에서 샌프란시스코 사무실까지 4.5시간 걸리는 여정에서 비행기 순항 속도를 10배 높여도, 공항 이동·보안 검색·탑승·활주로 대기·수하물·도착지 이동 때문에 전체 시간은 약 20%만 줄어들 수 있음
  • 데이터베이스도 비슷함
    • 엔진이 빨라져도 사용자는 이상한 CSV 파일, SQL로 질문을 표현하기 어려운 문제, 도구 연결 문제를 함께 겪음
    • 벤치마크 전쟁에서 이긴 제품은 홍보하기 쉽지만, 그것이 사용자의 문제 해결 시간을 곧바로 줄인다는 뜻은 아님
  • 데이터베이스 선택에는 사용 편의성, 생태계, 업데이트 속도, 워크플로 통합성이 더 나은 판단 기준이 될 수 있음
  • 성능은 특정 시점의 특정 작업 시간만 보여주며, 잘못 잡은 병목을 열심히 최적화하게 만들 수 있음

2019년 GigaOm 결과와 시장의 엇갈림

  • 2019년 GigaOm은 클라우드 데이터 웨어하우스를 대상으로 TPC-H와 TPC-DS 벤치마크를 실행함
    • 대상은 3대 클라우드 벤더와 Snowflake였음
    • 결과는 Azure Data Warehouse가 가장 빨랐고 Redshift가 뒤를 이었으며, Snowflake와 BigQuery는 크게 뒤처졌음
  • 당시 BigQuery 사용자 평가에서는 Azure와 직접 비교한 고객들이 BigQuery를 선택하는 경우가 많았음
  • 시장 결과는 벤치마크 순위와 거의 반대였음
    • Snowflake와 BigQuery가 Redshift보다 많이 팔렸음
    • Redshift는 Azure보다 더 잘 팔렸음
  • TPC-H와 TPC-DS는 업계 표준이고 내부 성능 판단에도 쓰이던 테스트였지만, 좋은 성능 벤치마크에서 낮은 순위를 받은 시스템을 고객이 더 많이 샀다면 성능보다 중요한 요소가 있었다고 볼 수 있음

사용자가 체감하는 빠름은 서버 시간이 아님

  • 데이터베이스를 만드는 사람들은 사용자가 “run” 버튼을 누른 뒤 결과가 준비될 때까지의 서버 실행 시간에 집중하는 경향이 있음
  • 사용자에게 중요한 시간은 작업을 끝내는 데 걸리는 전체 시간이며, 이는 데이터베이스 서버가 쿼리를 실행하는 시간과 다름
  • BigQuery의 JDBC 드라이버 사례가 이 차이를 잘 보여줌
    • JDBC 드라이버는 프로그래머와 BI 도구가 데이터베이스에 연결할 때 쓰는 범용 인터페이스였음
    • BigQuery 쿼리는 1~2초 만에 실행됐지만, 드라이버의 완료 폴링과 결과 다운로드 방식 때문에 사용자에게는 몇 초 또는 몇 분 더 느리게 보였음
    • 결과가 많을 때 드라이버가 사용자가 필요로 하지 않는 데이터까지 페이지 단위로 모두 가져오며 지연이 커졌고, 메모리 부족으로 충돌하기도 했음
  • 엔지니어들은 쿼리 시간을 몇 분의 1초 줄이는 데 많은 시간을 썼지만, 실제 사용자가 많이 쓰던 커넥터가 더 큰 지연을 만들었음
  • 내부 벤치마크는 매일 돌았지만, 엔드투엔드 성능과 사용자 체감 시간은 보이지 않았음

성능은 단일 숫자로 고정되지 않음

  • 성능은 데이터베이스 관점이 아니라 사용자 관점에서 측정되어야 하며, UX처럼 하나의 숫자로 완전히 설명하기 어려움
  • 어떤 데이터베이스가 더 빠른지는 실제 워크로드에 따라 달라짐
    • Lamborghini가 Prius보다 빠르더라도 교통 체증에서는 출근 시간이 달라지지 않을 수 있음
    • ClickHouse와 Redshift의 성능 차이도 사용 방식에 따라 달라짐
  • ClickHouse의 ClickBench는 ClickHouse가 여러 데이터베이스보다 빠르다는 결과를 보였음
    • 벤치마크는 JOIN 없이 단일 테이블에서 동작했고, distinct 카운트에 많이 의존했음
    • 로그 분석이나 웹사이트 고유 사용자 계산에는 좋은 대리 지표가 될 수 있음
    • 전통적인 데이터 웨어하우스의 스타 스키마 워크로드에는 오해를 만들 수 있음
  • 벤더 벤치마크는 보통 벤더가 잘하는 부분에 초점을 맞춤
  • BigQuery는 벤치마크에서 낮게 보일 수 있지만, 노브가 거의 없고 대체로 자체 튜닝되기 때문에 실제 사용자 경험에서는 좋게 느껴질 수 있음
  • 고도로 튜닝된 SingleStore 인스턴스는 많은 작업에서 BigQuery를 압도할 수 있지만, 스키마 튜닝 시간과 새 워크로드 추가 시 대응이 필요함
  • 성능을 높이기 위해 안전장치나 정확성을 줄일 수도 있음
    • overflow check 제거
    • write flush 생략
    • 일부 연산에 근사 결과 제공
    • ACID 보장 미제공
  • 이런 단축은 통제된 환경을 제외하면 사용하고 싶지 않은 선택지가 될 수 있음

지금의 순위보다 개선 속도가 더 오래 감

  • DuckDB 기반 회사를 만들 때, DuckDB가 h2o.ai 벤치마크에서 크게 밀린다는 지적이 있었음
  • 우려하지 않은 이유는 두 가지였음
    • 성능은 2차적 요소였음
    • DuckDB는 매우 빠른 속도로 개선되고 있었음
  • DuckDB의 빠른 개선에는 일부 아키텍처 결정, 비교적 새롭고 깨끗한 코드베이스, 뛰어난 엔지니어들이 영향을 줌
  • 같은 벤치마크의 최신 DuckDB 릴리스 대상 공개 결과에서는 DuckDB가 중위권에서 큰 차이로 선두권으로 이동함
  • 데이터베이스 선택은 여러 해 지속되는 결정이므로 현재 성능과 기능만이 아니라 1년 뒤 가능한 능력도 중요함
  • 두 데이터베이스가 서로 다른 속도로 개선된다면, 더 빠르게 움직이는 쪽을 선택하는 편이 나을 가능성이 큼

성능 격차는 시간이 지나며 좁혀짐

  • 적극적으로 유지보수되는 여러 데이터베이스를 몇 년 반복 개선하면 성능은 수렴하는 경향이 있음
  • 한 제품의 성능 기법은 시간이 지나며 다른 제품에도 구현될 수 있음
    • ClickHouse가 스캔 속도에서 유리한 기법을 쓰면 Snowflake도 1~2년 안에 비슷한 기능을 가질 수 있음
    • Snowflake가 점진적 materialized view를 추가하면 BigQuery도 곧 따라올 수 있음
  • 데이터베이스마다 성능을 내는 기법은 다름
    • 쿼리를 머신 코드로 컴파일
    • 데이터를 로컬 SSD에 캐싱
    • 특수 네트워크 하드웨어로 shuffle 처리
  • 효과적인 기법은 시간이 주어지면 누구나 구현할 수 있고, 잘 작동하면 여러 시스템에 퍼질 가능성이 큼
  • Fivetran CEO George Fraser의 데이터 웨어하우스 성능 비교에서는 2020년 가장 빠른 시간이 8초, 가장 느린 시간이 18초였지만 2022년에는 세 벤더가 약 7초, 가장 느린 벤더가 9초로 가까워졌음
  • 단, 아키텍처 차이는 극복하기 어려움
    • shared nothing 데이터베이스는 shared disk 대비 불리할 수 있음
    • Redshift는 주로 shared disk 아키텍처로 전환하는 데 여러 해가 걸렸음
    • 오브젝트 스토어에 메타데이터를 저장하는 lakehouse는 빠른 업데이트에 어려움을 가질 수 있음
  • 이런 차이는 주로 경계 조건에서 나타나며, 장기적으로 Redshift가 Snowflake보다 본질적으로 빠르거나 느려야 할 이유는 없음

질문에서 답까지의 시간을 줄이는 기능들

  • 사용자에게 중요한 성능은 질문이 생긴 시점부터 답을 얻는 시점까지의 시간임
  • 이 시간을 줄이는 방법은 쿼리 계획 개선만이 아님
    • 질문을 더 쉽게 표현하게 만들 수 있음
    • 쿼리 결과를 이해하기 쉽게 바꿀 수 있음
    • 잘못된 질문을 할 때 피드백을 줄 수 있음
    • 데이터 문제를 이해하게 도울 수 있음
    • 필요한 데이터를 올바른 위치와 형태로 준비하게 만들 수 있음
  • Snowflake는 사용자가 SQL을 입력했을 때 “그냥 동작”하게 만드는 데 강점이 있었음
    • 날짜 차이를 계산할 때 DATEDIFF와 TIMEDIFF를 모두 사용할 수 있음
    • 합리적인 타입이면 둘 다 동작함
    • granularity를 지정하거나 생략할 수 있음
    • granularity에 따옴표를 쓰거나 쓰지 않아도 됨
  • DuckDB도 Friendlier SQL로 쿼리 작성과 유지보수를 쉽게 하는 기능을 추가함
    • GROUP BY ALL은 집계 쿼리에서 GROUP BY 절 필드 누락을 줄임
    • SELECT 목록만 바꾸면 되므로 쿼리 진화 시 여러 위치를 수정할 필요가 줄어듦
    • 이 기능이 유용해지자 여러 데이터베이스 벤더가 유사 기능을 추가했음
  • CSV 파일은 세계의 많은 데이터가 담긴 형식이지만, 많은 파일이 잘못 구성되어 있고 파싱은 실제로 어려움
    • BigQuery의 초기 CSV splitter는 inference를 하지 못했고, 파일 간 스키마가 조금 다르면 혼란을 겪었음
    • CSV 파싱은 생각보다 까다로운 문제임
  • 두 엔지니어가 CSV 데이터를 읽어 같은 결과를 계산해야 한다면, CSV를 더 쉽게 올바르게 ingest하는 쪽이 쿼리 엔진 속도와 무관하게 먼저 답을 얻을 수 있음
  • 결과 처리 방식도 사용자 경험에 큰 영향을 줌
    • SELECT *가 MySQL처럼 첫 페이지와 cursor를 반환하면 즉시 보일 수 있음
    • BigQuery처럼 서버 측에서 테이블 복사본을 만들어야 하면 큰 테이블에서 몇 시간이 걸릴 수 있음
    • 클라이언트가 모든 데이터를 내려받으려 하면 메모리 부족이 날 수 있음
    • 긴 연결은 네트워크 문제에 취약하고, 폴링은 쿼리가 폴링 간격 사이에 끝날 때 더 느려 보일 수 있음

DuckDB 벤치마크를 볼 때의 단서

  • DuckDB는 빠르며, 일부 machine size의 ClickBench에서 최상위권에 있음
    • 예시로 c6a.4xlarge 결과가 제시됨
  • DuckDB는 대부분의 h2o.ai 벤치마크에서도 좋은 성능을 보이며, TPC-H와 TPC-DS에서도 나쁘지 않음
  • 어떤 데이터베이스가 빠르다고 가정하기 전에는 자신의 워크로드에서 직접 시험해야 함

빠른 쿼리보다 빠른 문제 해결

  • 가장 성공적인 데이터베이스 회사들이 경쟁사보다 빠르다는 이유만으로 성공한 것은 아님
  • Redshift가 한동안 강했지만, Snowflake가 진입할 수 있었던 이유는 벤치마크 성능이 아니라 유지보수성이었음
  • 성능을 주요 판매 포인트로 삼은 데이터베이스는 시장에서 좋은 성과를 내지 못했고, 작업을 쉽게 끝내게 해준 데이터베이스가 더 잘 버텼음
  • 데이터베이스 선택에서 봐야 할 축은 더 넓음
    • 마법 같은 비밀 기법은 없으며, 아키텍처 차이를 제외하면 성능은 시간이 지나며 수렴함
    • 데이터베이스 엔진의 개선 속도는 크게 다르고, 빠르게 움직이는 쪽이 장기적으로 유리함
    • 성능에 가장 집착하는 데이터베이스 벤더는 장기적으로 느려질 수 있음
    • 데이터베이스 성능에는 단일 지표가 없고, 빠른 데이터베이스도 특정 워크로드에서는 나쁠 수 있음
    • 중요한 기능은 쿼리에서 결과까지가 아니라 아이디어에서 답까지 얼마나 빨리 갈 수 있느냐임
  • 느린 쿼리보다 빠른 쿼리가 낫지만, 데이터베이스 선택은 원시 속도 외의 요소를 기준으로 해야 함

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들

  • 몇 년 동안 고객 불만이 많았는데도 JDBC 드라이버 문제가 성능을 망치고 있다는 걸 “완전히 몰랐다”는 대목이 답답함
    Google 내부에서 실제 고객처럼 자기 제품을 쓰지도 않았고, 사용자가 보는 쿼리 시간이 내부에는 보이지 않아서 남의 문제로 취급했다는 얘기임

    • 여기서 배운 교훈도 조금 빗나간 듯함. “성능만으로는 부족하다”가 아니라, 고객이 실제로 쓰는 경로의 성능이 개별 구성요소 벤치마크보다 중요하다는 것임
      문제는 최적화에 너무 많은 노력을 쓴 게 아니라, 고객의 고통에서 출발해 근본 원인까지 추적하지 않았다는 데 있음. 실제 원인도 결국 성능 문제였음

  • JDBC 이야기가 정말 좋았음. Google은 내부에서 잘 돌아가는 데이터베이스를 만들었고, 외부 세계용 어댑터 계층은 하청으로 만들었는데 그게 제대로 동작하지 않아서 외부 사용자는 형편없는 데이터베이스를 쓰게 됨
    Google이 쓰는 정교한 핵심 위에 망가진 포장지를 씌워 전체 제품이 불필요하게 엉망이 된 셈이고, 내부에서는 아무도 눈치채지 못했으며 외부 사용자도 원인 파악이 어려웠음. Google의 오픈소스 전략을 아주 정확히 보여주는 사례처럼 보임

    • 관리 관점으로 보면 이해는 됨. “우리는 최고 컴퓨터과학 인재를 뽑았으니 핵심 컴퓨터과학 문제를 풀게 하고, JDBC 드라이버는 핵심 역량이 아니니 외주 주자”는 식임
      문제는 비핵심 영역을 충분히 망쳐 놓으면 핵심 역량이 뛰어나도 소용없어진다는 것임. 외주화는 공짜 점심이 아님
    • Google API용 Python 래퍼들이 전부 이런 이야기였음
    • 이건 수직 통합 부족 때문임. Apple이 여러 면에서 이기는 이유는 수직 통합을 아주 잘하기 때문임
    • Workspace 같은 비즈니스 계약도 딱 이 구조임. 훌륭한 핵심 제품 위에 세계 최악급 컨설팅 회사들이 15%쯤 떼어 가는, 쓸모없음을 넘어 해로운 “지원” 계약이 씌워져 있음

  • 글에서는 “성능은 주관적”이고 단순 측정만으로는 부족하다고 하지만, 정작 예시는 성능이 실제로 중요하고 객관적이었던 경우임. 다만 잘못된 대상을 측정했을 뿐임

    • 첫 문단부터 암달의 법칙에 딱 맞는 사례로 시작하는데, 글에서 한 번도 언급되지 않는 게 의외임

  • 이건 회사의 조직 문제처럼 들림. 최종 목표가 사람들이 클라우드를 쓰게 하고 가치를 제공하는 것이라면, 왜 고객이 중요하게 보는 것과 어긋나는 지표를 갖고 있는지 모르겠음
    Google 안에 고객과 직접 이야기하며 문제가 뭔지 파악하고, 엔지니어에게 전달해 무엇을 개선할지 알게 하는 사람이 있어야 함. 조직은 엔지니어가 필요한 지표를 받거나, 그 지표를 만드는 일 자체가 직무에 포함되도록 설계되어야 함

    • “일화와 지표가 서로 다를 때는 보통 일화가 맞다는 걸 알게 됐다” — Jeff Bezos. 안타깝게도 가끔 좋은 말을 하긴 했음
    • Google은 고객과 직접 이야기하는 일에 조금 알레르기가 있는 것처럼 보임
    • https://en.wikipedia.org/wiki/Seeing_Like_a_State
    • 우리 솔루션이 고객 문제를 해결하지 못한다면, 고객에게 다른 문제가 필요하거나 우리에게 다른 고객이 필요함
    • 완전히 동의함. 목표로 삼을 잘못된 지표를 고른 문제로 보임. 다만 엔지니어링 팀이 지연시간의 너무 좁은 부분만 측정한 수준을 넘어섬
      제품과 조직 리더십은 어떤 지표를 보고 있었길래 이런 고객 피드백을 놓쳤는지가 더 궁금함

  • “Seattle 집에서 San Francisco 사무실까지 문에서 문까지 4.5시간”이라는 대목을 보니, 요즘 창업자들이 더는 시속 179마일로 움직이지 않는 듯함. 연준이 금리를 올리면 이렇게 되는 모양임

    • 처음 읽었을 때는 운전한다는 줄 알았는데, 아마 비행기 + 공항 이동 + 보안검색까지 포함한 시간일 것임
    • 지금 실제로 Seattle 집에서 SF 사무실로 가는 중임. 48분 전에 출발했으니 도착하면 업데이트해서 여기 데이터 포인트 하나를 직접 추가하겠음

  • 좋은 지점들이 분명 있지만 결론은 조금 어긋난 느낌임. 성능은 여기서 말한 것처럼 부차적이라기보다 충분한가 아닌가에 가까움
    충분히 빠른가를 통과해야 그다음에 다른 요소를 판단할 수 있음. 그 전에는 경쟁 테이블에 앉지도 못함. 저자도 “DuckDB는 빠르다”고 말하는데, 빠르지 않았다면 적어도 그 체크박스를 채울 때까지는 성능으로 경쟁해야 했을 것임
    또한 “가장 빠르게 움직이는 데이터베이스 엔진이 결국 이긴다”는 말은 어느 정도 맞을 수 있지만 실용적이진 않음. 새 플레이어일 때는 진척이 빠르지만 Snowflake 같은 위치에 도달하면 속도는 느려질 수밖에 없음. 오늘 시스템을 고르는 입장에서 현재의 가속도를 미래까지 그대로 외삽할 수는 없음
    그래도 “쿼리에서 결과까지가 아니라, 아이디어에서 답까지 얼마나 빨리 가는가”라는 관점은 따로 깊게 탐구할 만해 보임

  • 성능은 “주관적”이라기보다 상대적임. 그 의미는 당면한 작업과 연결되어 있음
    다만 빠르게 움직이는 진행 표시처럼 사용자가 더 빠르다고 느끼게 만드는 사용자 인터페이스를 말한다면 별개의 이야기임. 그건 인터페이스 문제이지 데이터베이스 문제는 아님

    • “주관적”이 맞는 표현임. 어떤 작업이 관련 있는지는 주체에 달려 있음
      “상대적”이라고 하려면 시스템 간 비교 말고는 성능에 숫자를 붙일 방법이 없어야 하는데, 그건 사실이 아님

  • 처음 인기를 얻은 웹 앱은 모든 상태를 Python dict에 담고 몇 분마다 디스크에 덤프했음. 평생 본 것 중 가장 빠른 API였음
    Mongo로 옮긴 뒤에는 성능이 다시는 회복되지 않았음. 그래도 지금 웹사이트를 만들 때 “pickledb”를 집어 들지는 않음

    • fopen의 대체재로는 SQLite가 중간 지점임
    • 더 많은 사람이 처음부터 트랜잭션 데이터베이스 구조가 아니라 메모리 상주 + 스냅샷 구조를 고려해도 된다고 봄
      요청/응답식 사용자 상호작용에는 덜 맞지만, 큰 정적 데이터나 재생 가능한 스트리밍 데이터를 증분 또는 일괄 처리하는 경우에는 지금보다 더 흔해야 한다고 생각함

  • “공유 없음(shared nothing) 데이터베이스는 공유 디스크(shared disk)에 비해 불리하고, Redshift가 주로 공유 디스크 아키텍처로 전환하는 데 수년이 걸렸다. 객체 저장소에 메타데이터를 저장하는 Lakehouse는 빠른 업데이트가 어렵다”는 주제에 대한 좋은 자료를 찾고 있음

  • 좋은 글임. 지난 10년간 pandas가 강했던 이유 중 하나도 이것이라고 봄
    단일 머신 성능이 충분히 좋았고, 인류가 아는 CSV의 99%를 읽어 들일 수 있었음

답변달기