GN⁺: 퍼프(Perf)만으로는 부족함

데이터베이스의 성능 집착 문화

• 데이터베이스 업계는 성능 향상에 집중하고 있으나, 실제 사용자 경험은 종종 다른 요소들에 의해 영향을 받음.
• 사용자가 데이터를 처리하는 데 있어 실제로 중요한 것은 쿼리 최적화보다는 데이터의 형식이나 SQL로 질문을 구성하는 능력일 수 있음.
• 데이터베이스의 성능은 중요하지만, 사용의 용이성, 생태계, 업데이트 속도, 워크플로우와의 통합성 등 다른 요소들을 기반으로 데이터베이스를 선택하는 것이 더 나을 수 있음.

벤치마크 전쟁의 종결

• 2019년 GigaOm이 클라우드 데이터 웨어하우스를 비교하는 벤치마크를 발표했으나, 실제 시장 결과와는 다른 양상을 보임.
• 벤치마크 결과가 사용자 경험과 일치하지 않는 경우, 벤치마크가 잘못되었거나, 잘못된 것을 테스트했거나, 성능이 그렇게 중요하지 않을 수 있음을 시사함.

빠름의 의미

• 클라우드 데이터베이스 분야에서는 사용자가 '실행' 버튼을 클릭하고 결과가 준비되는 시간에 초점을 맞추는 경향이 있음.
• 실제로 사용자에게 영향을 미치는 것은 작업을 완료하는 데 걸리는 시간이며, 이는 데이터베이스 서버 시간과 동일하지 않음.

성능은 주관적임

• 성능은 사용자의 관점에서 측정되어야 하며, UX 문제로 단일 숫자로 설명될 수 없음.
• 성능의 주관성은 데이터베이스가 어떻게 사용되는지에 따라 어느 것이 더 빠른지 결정됨을 의미함.

변화의 속도

• DuckDB는 빠른 속도로 개선되고 있으며, 이는 현재의 벤치마크를 무의미하게 만듦.
• 데이터베이스를 선택할 때 현재의 성능뿐만 아니라 미래의 성능과 기능 변화도 중요한 변수임.

마법의 콩은 없다

• 모든 데이터베이스가 활발히 유지되고 있다면, 성능은 시간이 지남에 따라 수렴할 것임.
• 중요한 성능 차이는 시간이 지나면서 지속되지 않을 가능성이 높음.

문제는 의자와 키보드 사이, 키보드와 데이터베이스 사이에 있음

• 사용자에게 중요한 성능의 척도는 질문을 가지고 답을 얻는 데 걸리는 시간임.
• 데이터베이스가 쿼리를 실행하는 시간이 아니라 아이디어에서 답변으로 가는 속도가 중요한 기능임.

신맛 나는 포도에 대하여

• DuckDB는 현재 ClickBench와 h20.ai 벤치마크에서 상위권에 있으며, TPC-H와 TPC-DS에서도 나쁘지 않은 성능을 보임.
• 데이터베이스가 빠르다고 가정하기 전에 실제 작업 부하에서 시도해보는 것이 중요함.

결론

• 가장 성공적인 데이터베이스 회사들은 경쟁사보다 더 빠른 성능으로 성공한 것이 아님.
• 성능을 주요 판매 포인트로 삼은 데이터베이스는 시장에서 성공하지 못함.
• 데이터베이스를 선택할 때는 원시 속도 이외의 다른 요소들을 기반으로 결정하는 것이 더 낫다고 조언함.

GN⁺의 의견

• 이 기사는 데이터베이스의 성능에만 초점을 맞추는 것이 아니라, 사용자 경험과 작업 흐름을 최적화하는 것이 중요하다는 점을 강조함. 이는 초급 소프트웨어 엔지니어에게도 데이터베이스를 선택할 때 단순한 성능 지표보다 사용자 중심의 접근 방식을 고려해야 한다는 중요한 교훈을 제공함.
• 데이터베이스의 성능은 시간이 지남에 따라 수렴하는 경향이 있으며, 이는 기술의 발전이 모든 플랫폼에 걸쳐 확산되기 때문임. 이는 기술 선택 시 단기적인 성능보다는 장기적인 지원과 개선 가능성을 고려해야 함을 시사함.
• DuckDB 같은 오픈소스 프로젝트는 빠른 개선 속도와 커뮤니티의 지원을 바탕으로 빠르게 발전할 수 있음. 이는 새로운 기술을 도입할 때 커뮤니티의 활성도와 프로젝트의 발전 속도를 고려해야 함을 의미함.
• 데이터베이스 선택 시 성능 벤치마크 결과에만 의존하지 말고, 실제 작업 부하에서의 성능을 테스트해보는 것이 중요함. 이는 실제 사용 사례에 더 적합한 데이터베이스를 선택하는 데 도움이 될 수 있음.
• 데이터베이스 기술의 선택은 단순히 기술적인 측면뿐만 아니라 비즈니스 요구, 유지 관리 용이성, 데이터 처리의 효율성 등 다양한 요소를 고려해야 함을 강조함.

[neo]

Hacker News 의견

• 고객의 불만이 많았던 몇 년 후, JDBC 드라이버의 버그가 성능을 저하시키고 있음을 깨달았음. 많은 엔지니어의 시간을 쿼리 속도를 빠르게 하는 데 투자했지만, 대부분의 사용자가 사용하는 커넥터가 절약한 시간보다 훨씬 더 많은 지연을 추가했음. 더욱이, 이 사실을 전혀 인지하지 못했음. 구글 내부에서 아무도 JDBC 드라이버를 사용하지 않았기 때문에 사용자가 경험하는 쿼리 시간을 볼 수 없었고, 이를 다른 사람의 문제로 여겼음.

  • 이 댓글은 구글이 고객의 불만에 대해 "완전히 눈이 멀었다"는 점과 자체 제품을 사용하지 않는다는 점에서 실망감을 표현함. JDBC 부분 이야기가 특히 인상적임.
• 구글은 내부적으로 잘 작동하는 데이터베이스를 구축했지만, 외부 세계를 위한 어댑터 레이어를 하청으로 만들었고, 이는 제대로 작동하지 않아 외부 세계는 불량한 데이터베이스를 사용하게 됨. 구글이 사용하는 정교한 핵심은 불완전한 어댑터로 둘러싸여 있어, 전체적으로 불필요하게 엉망인 결과물이 됨. 내부적으로는 이를 인지하지 못하고, 외부 사람들은 이를 파악하기 어려움.
  • 이 댓글은 구글의 오픈 소스 전략에 대해 매우 적절하다고 평가함.
• 블로그가 "성능은 주관적"이라고 주장하는 것이 이상하다고 생각함. 성능을 단순히 측정하는 것으로 충분하지 않지만, 주어진 유일한 예시에서는 성능이 중요하고 객관적임. 단지 잘못된 것을 측정했을 뿐임.
  • 이 댓글은 성능 측정에 대한 블로그의 주장에 대해 의문을 제기함.
• 이것은 회사 조직의 문제로 들림. 고객이 클라우드를 사용하게 하고 가치를 제공하는 것이 최종 목표라면, 고객이 중요하게 생각하는 것과 다른 메트릭을 가지고 있어서는 안 됨. 구글 내부에는 고객의 문제를 적극적으로 듣고 그것을 엔지니어에게 전달하여 무엇을 개선해야 할지 알려주는 사람이 있어야 함.
  • 이 댓글은 구글이 고객의 요구사항을 이해하고 이를 개선하기 위한 조직 구조의 필요성을 강조함.
• 시애틀에 있는 집에서 샌프란시스코 사무실까지 문 앞에서 문 앞까지 약 4.5시간이 걸림.
  • 이 댓글은 창업자들이 더 이상 빠른 속도로 움직이지 않는다는 점을 지적하며, 이는 연방준비제도이사회가 이자율을 올렸기 때문일 수 있다고 농담조로 언급함.
• 성능은 이차적이라고 여기에서 말하는 것처럼 생각하지 않음. 성능이 충분히 좋은지 확인한 후에 다른 모든 것을 평가해야 함. 저자 스스로 "DuckDB는 빠르다"고 언급했음. 그렇지 않다면 성능 경쟁을 해야 할 것임.
  • 이 댓글은 성능이 이차적이라는 주장에 동의하지 않으며, 성능이 충분히 좋은지 확인하는 것이 우선이라고 주장함.
• 성능은 "상대적"이지 "주관적"이 아님. 그 의미는 수행하는 작업과 관련이 있음.
  • 이 댓글은 성능의 상대성에 대해 설명하며, 사용자 인터페이스 설계와 관련된 성능의 느낌을 구분함.
• 첫 번째 인기 웹 앱은 모든 상태를 파이썬 dict에 저장하고 몇 분마다 디스크에 덤프함. 매우 빠른 API였지만, 몽고DB로 옮겼을 때 성능이 회복되지 않았음. 그럼에도 불구하고 오늘날 웹사이트를 만들 때 "pickledb"를 선택하지 않음.
  • 이 댓글은 초기 웹 앱의 성능과 데이터베이스 전환 후의 성능 저하 경험을 공유함.
• 자체 데이터베이스 시스템을 구축하고 다른 인기 있는 데이터베이스(Postgres, Sqlite, MySQL, SQL Server)와의 성능을 벤치마킹하고자 함.
  • 이 댓글은 사용자가 '실행 버튼'을 누르고 화면에 결과가 표시되는 시간까지 측정하여, 다양한 쿼리에 걸쳐 자신의 데이터베이스가 더 빠를 때까지 만족하지 않았다고 설명함.
• "물론, 이 규칙에는 예외가 있는데, 그것은 아키텍처 차이를 극복하기 어렵다는 것임. 공유 없는(shared nothing) 데이터베이스는 공유 디스크(shared disk)에 비해 불리하며, Redshift가 주로 공유 디스크 아키텍처로 전환하는 데 많은 년이 걸렸음. 객체 저장소에 메타데이터를 지속하는 레이크하우스는 빠른 업데이트에 어려움을 겪을 것임; 이는 모델에 내재되어 있음."
  • 이 댓글은 데이터베이스 아키텍처 차이와 관련된 문제점을 지적하며, 이 주제에 대한 좋은 문헌을 찾고 있음을 언급함.