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