# 퍼프(Perf)만으로는 부족함

> Clean Markdown view of GeekNews topic #13761. Use the original source for factual precision when an external source URL is present.

## Metadata

- GeekNews HTML: [https://news.hada.io/topic?id=13761](https://news.hada.io/topic?id=13761)
- GeekNews Markdown: [https://news.hada.io/topic/13761.md](https://news.hada.io/topic/13761.md)
- Type: GN+
- Author: [neo](https://news.hada.io/@neo)
- Published: 2024-03-12T08:37:46+09:00
- Updated: 2024-03-12T08:37:46+09:00
- Original source: [motherduck.com](https://motherduck.com/blog/perf-is-not-enough/)
- Points: 2
- Comments: 1

## Topic Body

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

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

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

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

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

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

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

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

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

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

## Comments



### Comment 23649

- Author: neo
- Created: 2024-03-12T08:37:46+09:00
- Points: 1

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