Hacker News 의견

• 응용 프로그램 스택 간소화 시도에 대한 경험 공유

  한 사용자는 응용 프로그램 스택을 간소화하려는 시도를 자주 하지만, 응용 프로그램의 복잡성이 증가함에 따라 다양한 기술 스택의 필요성을 깨닫게 됨. 모든 것을 Postgres와 같은 단일 기술에 통합하려고 하면 불편함을 느낄 수 있음. 그럼에도 불구하고, 기존 기술을 확장하는 것이 새로운 계층을 추가하는 것보다 나을 수 있음. 예를 들어, Postgres를 메시지 큐로 사용하는 것이 별도의 메시지 큐를 유지하는 것보다 훨씬 쉬움. Postgres는 데이터베이스 중에서도 확장성이 뛰어나며, 이를 기반으로 기술을 구축하는 것이 매우 재미있음.

• ParadeDB 제작자의 Postgres 확장성에 대한 의견

  ParadeDB의 제작자 중 한 명으로, Postgres 확장을 통해 빠른 검색과 분석 기능을 제공함. 스타트업과 같이 작은 워크로드의 경우 가능한 한 오래 Postgres 내에서 작업하는 것이 합리적임. 그러나 규모가 커지면 Postgres만으로는 모든 것을 해결할 수 없음. Postgres 내에서 다양한 워크로드를 처리하려면 특정 요구 사항에 맞게 시스템을 분리하고 독립적인 확장성과 복원력을 확보해야 함. 이 시점에서 각 요구 사항에 맞는 전문화된 솔루션 스택이 필요함. Postgres 버전의 스택 구성 요소를 구축하는 움직임이 있지만, 각 솔루션은 Postgres를 넘어서며, 모든 스택 구성 요소에 대한 Postgres 기반 솔루션이 있을 것이라고는 생각하지 않음.

• 새 프로젝트 시작 시 sqlite 사용 결정에 대한 의견

  한 사용자는 새 프로젝트를 시작할 때마다 sqlite로 시작하고, 반드시 필요할 때까지 전환하지 않기로 결정함. Postgres가 90%의 경우에 적합하다면, sqlite는 80%의 경우에 적합하며, 시작하기 쉽고 성능도 좋음. 수직 확장이 실패할 때, 이미 구축한 것에 만족할 것임.

• 데이터베이스에 대한 C++ 전문가의 의문

  데이터베이스에 익숙하지 않은 C++ 전문가가 데이터베이스의 필요성에 대해 의문을 제기함. 사용자는 맞춤형 바이너리 파일 형식을 많이 사용하는 산업에서 왔으며, 데이터베이스가 표면적으로 많은 문제를 해결하는 것처럼 보이지만 실제로는 그렇지 않다고 느낌. 데이터 유형에 대한 제한, 업데이트 문제, 다른 SQL 엔진 간의 호환성 문제 등이 데이터베이스 사용을 나쁜 아이디어로 보이게 함. 대규모 데이터 볼륨에서의 상호 운용성 이점을 이해하지만, 그 외의 경우 데이터베이스의 필요성을 진지하게 묻고 있음.

• PostgreSQL 추가 기능에 대한 의견

  대부분의 추가 기능이 MariaDB에 이미 내장되어 있음을 지적하며, PostgreSQL HTTP 클라이언트의 동기 부여 중 일부를 인용함. 웹 서비스를 호출하는 트리거를 작성할 수 있다면 좋을 것이라는 아이디어에 대해, 사용자는 그런 작업을 자신보다는 다른 사람에게 맡기겠다는 의견을 표함.

• 고급 기능 사용 시 코드 관리 경험과의 결합 문제

  Postgres를 광범위하게 사용하지만, 고급 기능을 사용할 때마다 버전 관리, 코드 리뷰, 타입, 테스트, 정적 분석 등 코딩의 모든 좋은 점과 결합하는 문제가 발생함. 마이그레이션에 대한 질문을 함.

• 기존 스택으로 새 기능 프로토타입 제작의 장점

  새 기능을 프로토타입으로 먼저 제작하는 것이 새로운 것을 도입하는 것보다 낫다고 경험을 공유함. 신중한 큐레이션을 통해 초기 프로토타입을 동일한 스택으로 생산 코드로 전환할 수 있음. 하지만 시스템이 한계에 부딪히면 Redis나 다른 전문 도구가 필요하다고 느낄 수 있음. 중요한 것은 API 래퍼를 작성하고, 필요할 때 내부 구현만 변경하고 마이그레이션을 잘 테스트하는 것임. 기술 결정을 얼마나 오래 미룰 수 있는지 사람들이 놀랄 정도라고 언급함.

• Postgres, Redis, S3를 사용하는 사용자의 경험 공유

  Postgres, Redis, S3의 조합을 사용하며, 이 조합이 아직까지 잘못된 적이 없음을 밝힘. 가끔 Postgres로 Pub/Sub을 시도하고 싶지만, 어차피 캐싱과 sidekiq에 Redis가 필요하고, Redis도 뛰어나기 때문에 굳이 시도하지 않음.

• 대규모 데이터 분석에 대한 Postgres의 한계

  Postgres를 매우 좋아하지만, 데이터 규모가 매우 클 때 Postgres가 충분하지 않다고 느낀 경험을 공유함. OLTP 유형의 워크로드를 처리하는 데는 Postgres가 완벽하지만, OLAP 지원이 더 필요한 경우 StarRocks를 사용할 것을 권장함. 데이터 분석을 위해 Postgres에서 StarRocks로 데이터를 가져오는 경험이 훌륭하며, StarRocks는 데이터 레이크에서의 직접 쿼리도 지원함.

• Postgres의 jsonb 압축 기능에 대한 요구

  Mongo와 PG를 모두 사용하지만, PG가 훨씬 간단하여 Mongo를 단순화를 위해 포기하고 싶음을 표현함. 필요한 것은 단순히 압축된 jsonb 컬럼으로, 업데이트나 쿼리 없이 삽입, 선택, 삭제만 가능하면 됨. Mongo에서와 같이 반복적인 json 키에 대해 80-90% 압축률을 유지하면서 유지 관리가 필요 없음.