▲

GN⁺: 그냥 Postgres 쓰세요

 (mccue.dev)
43P by neo 1달전 | favorite | 댓글 18개
  • 대부분의 웹 애플리케이션은 지속적인 데이터 저장이 필요하므로, 새로운 애플리케이션을 만들 때 기본적으로 Postgres를 선택하는 것이 좋음

왜 sqlite가 아닌가?

  • sqlite는 좋은 DB지만, 데이터가 하나의 파일에 저장됨
  • 이는 애플리케이션이 한 대의 기기에서만 실행된다는 것을 의미함
  • 데스크탑 또는 모바일 앱에는 적합하지만, 웹사이트에는 적합하지 않을 수 있음
    • 웹사이트에 sqlite를 사용한 성공 사례가 있지만, 대개 자체 서버와 인프라를 직접 구축한 경우임
  • 플랫폼 제공 자동 데이터베이스 백업 및 여러 애플리케이션 서버를 구성하는 기능을 포기해야 할 수도 있음

왜 DynamoDB, Cassandra, 또는 MongoDB가 아닌가?

  • 이 데이터베이스들은 뛰어난 성능을 발휘하지만, 전제 조건이 많음:
    • 애플리케이션이 수행해야 할 작업과 접근 패턴을 정확히 알고 있어야 함
    • 매우 큰 데이터 규모로 확장할 필요가 있는 경우
    • 일관성의 일부를 포기할 수 있는 경우
  • 이 데이터베이스들은 분산 해시 맵과 유사한 방식으로 작동하므로, 데이터 저장 방식에 쿼리 패턴 지식을 반영해야 함
  • 접근(쿼리) 패턴이 바뀌면 데이터 전체를 다시 처리해야 할 수도 있음
  • 관계형 데이터베이스는 쉽게 인덱스를 추가하여 쿼리를 수행할 수 있지만, NoSQL 데이터베이스는 그러기 어려움
  • 분석 쿼리에는 부적합함
  • 대학생이나 신입 개발자가 MongoDB를 사용한다면 도움이 필요할 것임

왜 Valkey가 아닌가?

  • Redis로 알려진 이 데이터베이스는 매우 효율적인 캐시로 잘 알려져 있음
  • 주 데이터베이스로 사용할 수 있지만 다음과 같은 문제가 있음:
    • 모든 데이터를 RAM에 저장하므로 빠르지만, RAM 용량이 제한적임
    • 데이터 모델링에 있어 타협이 필요함

왜 Datomic이 아닌가?

  • 이걸 이미 알고 계시다면 "금색 별"을 드리겠음
  • Datomic은 관계형 NoSQL 데이터베이스로 "사전 설계(Up-front Design)" 문제가 없고, 몇가지 깔끔한 속성을 가지고 있음
    • 데이터를 테이블 대신 EAVT(entity-attribute-value-time) 쌍으로 저장하고, 범용 인덱스를 사용함
    • 쿼리를 작성할 때 작성자와 조율할 필요가 없음. 주어진 시간에 '현재 시점'의 데이터베이스를 쿼리하면 됨. 새 데이터, 심지어 삭제(또는 '철회/retractions'라고도 함)도 실제로 이전 데이터를 삭제하지는 않음
  • 하지만 몇 가지 단점이 있음:
    • JVM 언어에서만 작동함
    • Clojure 외의 언어에서는 API가 좋지 않음
    • 잘못된 구조의 쿼리로 인해 발생하는 에러 메시지가 매우 불친절함
    • SQL 도구 생태계 같은 것이 없어서 도구가 부족함

왜 XTDB가 아닌가?

  • Clojure 사용자들은 많은 데이터베이스를 만듦
  • Datomic과 비슷하지만 다음과 같은 특징이 있음:
    • HTTP API를 제공하여 JVM에 종속되지 않음
    • "시스템 시간"과 "유효 시간"의 두 축으로 쿼리 가능함
    • SQL API를 지원함
  • 하지만 가장 큰 문제는, 아직 "신생"임. SQL API는 작년에 나왔고, 최근에 전체 스토리지 모델을 변경했음
    • 10년 후에도 살아남을수 있을까? 장기적인 지원 여부가 불확실함

왜 Kafka가 아닌가?

  • Kafka는 아주 좋은 "추가 전용(Append-Only)" Log로, TB 단위 데이터 처리에 적합함
  • 여러 팀에서 관리하는 여러 서비스에서 유입되는 데이터로 이벤트 소싱 유형의 작업을 수행하려는 경우 놀랍도록 잘 작동gka
  • 그러나
    • 작은 규모에서는 Postgres의 테이블로 충분히 대체 가능함
    • Kafka 컨슈머를 만드는 것은 생각보다 오류가 발생하기 쉬움. 결국 로그에서 자신의 위치를 추적해야 하기 때문
    • 추가적인 인프라를 관리해야 함

왜 ElasticSearch가 아닌가?

  • 데이터 검색이 제품의 주요 기능이라면 ElasticSearch는 적합한 제품임
    • 데이터를 ETL하고 전체 프로세스를 관리해야 하지만 ElasticSearch는 검색을 위해 만들어졌고, 검색을 잘 수행함
  • 하지만 검색이 주된 기능이 아닌 경우 Postgres의 내장 텍스트 검색 기능으로도 충분함
    • 나중에 전용 검색 엔진을 추가할 수 있음

왜 MSSQL 또는 Oracle DB가 아닌가?

  • 스스로에게 물어봐야 할 진짜 질문: "가격 대비 가치가 있나요?"
  • 라이선스 비용뿐만 아니라 락인 비용도 고려해야 함
  • 오라클에 데이터를 저장하면 영구히 Oracle에 비용을 지불하고, 개발자를 계속 교육시켜야 함
    • 엔터프라이즈 기능과 지갑중에서 하나를 영원히 선택해야 함
  • 특정 기능이 반드시 필요한 경우가 아니라면 사용을 피하는 것이 좋음
    • MSSQL 없이는 살 수 없는 킬러 기능이 있지 않는한 사용하지 말 것

왜 MySQL이 아닌가?

  • 이 부분은 약간 독자의 도움이 필요함
  • MySQL은 Oracle이 소유하고 있으며, 일부 기능은 엔터프라이즈 에디션에 잠겨 있음
    • 물론, MySQL은 오랫동안 사용되어 왔으며, 널리 사용되는 무료 에디션이 있음
  • 나는 Postgres가 더 나은 선택이라고 믿고 있지만, MySQL에 대한 추가적인 정보가 필요함

왜 AI 벡터 DB가 아닌가?

  • 대부분의 AI 벡터 DB는 신생 기술로, 사용에 리스크가 있음
    • AI 버블에 기반한 비즈니스는 신중히 접근해야 함
  • 당신의 비즈니스가 또다른 AI grift(사기)일지라도, 그냥 import openai정도면 될 것

왜 Google Sheets가 아닌가?

  • 특별한 단점이 없음 필요하다면 사용해도 됨
▲
koxel 31일전  [-]

Mysql 엔터프라이즈 진짜 문제는 라이선스가 아니라 유료 구입자도 장애 터질 시 지원이 정말 ㅈ같다는 거에요.
이전에 mysql 인넥스가 깨져서 구동 안되는걸 지원 요청해도 오라클에서 지원 티켓 끓어서 요청하면 전화지원 해주겠다가 다였고.
결국 고객사에서 안되겠다 해서 우리가 해결해야 했던지라.
오라클 믿고 엔터프라이즈 쓰기보다 무료가 최고..

답변달기
▲
neo 1달전  [-]
Hacker News 의견

  • MongoDB에 대한 부정적인 의견이 많지만, 대부분 틀린 정보임

    • MongoDB는 초기 단계에서 잘 맞음
    • 데이터 크기가 커질 때도 문제없이 작동함
    • 일관성 문제도 잘 해결됨
    • MongoDB는 Dynamo와 같은 분산 해시 맵이 아님
    • MongoDB의 집계 기능을 잘 모르는 사람들이 많음
    • 신입 개발자가 SQL을 배워야 한다는 이유로 MongoDB를 사용하지 말라는 것은 부당함

  • SQLite의 장점

    • 파일 기반이라서 백업이 쉬움
    • ORM을 사용하면 SQLite에서 Postgres로 쉽게 업그레이드 가능함

  • 기술적 결함을 지적하는 것은 의미가 없음

    • MongoDB의 Rick Houlihan이 현재 MongoDB에서 일하고 있음

  • MySQL에서 Postgres로의 마이그레이션 이유

    • Oracle 소유의 MySQL은 비즈니스 리스크가 있음
    • Postgres는 데이터 일관성을 유지하는 도구가 더 많음
    • Postgres의 확장 기능이 개발 시간을 절약해줌
    • Postgres의 도구 생태계가 더 성숙하고 완전함

  • Postgres의 시간 테이블 지원이 부족함

    • SQL:2011 시스템 시간 및 애플리케이션 시간 "이중 시간" 버전 관리가 필요함
    • 복잡한 보고 요구사항이 있는 규제 산업에서는 시간 테이블이 이상적임

  • SQLite를 사용하는 이유를 이해하지 못함

    • Postgres 설치가 어렵지 않음
    • SQLite와 Postgres의 차이점에 대한 설명 필요함

  • Rick Houlihan의 이름을 잘못 언급한 것에 대한 사과

    • DynamoDB/Cassandra와 MongoDB 비교는 그의 강연에서 나온 것임
    • MongoDB는 비정규화된 정보를 저장하는 데이터베이스로, 접근 패턴 변경에 유연하지 않음

  • 아는 것을 사용하고 유용한 것을 배포하는 것이 중요함

  • MySQL은 Javascript와 같음

    • 나쁜 결정과 위험 요소가 많음
    • 잘 작동하지만, Postgres가 존재하는데 굳이 사용할 이유가 없음
답변달기
▲
touguy 31일전  [-]

Postgres는 데이터 일관성을 유지하는 도구가 더 많음
=> 혹시 예시가 있을까요?

답변달기
▲
leftliber 31일전  [-]

Postgres 대비 SQLite의 한 가지 단점은 schema 를 지원하지 않는다는 것이더라구요. 테이블이 수십 개 이상으로 많아지면 schema 단위로 테이블을 구분 설계하는 것이 깔끔한데, SQLite가 그게 안되다 보니 테이블명에 모든 구분을 다 넣어야 해서요.

답변달기
▲
wedding 30일전  [-]

이렇게 단언하는 아티클들은 대체로 주니어들이 하는 실수인데..

답변달기
▲
composite 31일전  [-]

이정도면 해커뉴스 공식 장작이네요

답변달기
▲
nemorize 30일전  [-]

대신귀
여운C
SV를
드리겠
습니다

답변달기
▲
bus710 30일전  [-]

좋은 정보를 얻기 위해서는 어그로를 끌어라… 라는 우스개가 왠지 떠오르네요 ㅎㅎ
어쨌거나 대부분의 백엔드 개발자들이 제일 처음 쓰게 되는건 postgresql 이다보니…

답변달기
▲
dicebattle 30일전  [-]

나는 Postgres가 더 나은 선택이라고 믿고 있지만, MySQL에 대한 추가적인 정보가 필요함

ㅋㅋㅋ;;;;

답변달기
▲
kaydash 31일전  [-]

왜 mariadb, impala,hive,kudu가 아닌가

답변달기
▲
koxel 31일전  [-]

Mysql 엔터프라이즈 기능은 자체 커넥션 풀 처럼 굳이 필요하지 않은 기능이고..
진짜 엔터프라이즈면 이걸 쓰느니 앞단에 sql proxy 설치하는게 부하분산에 더 효과적이에요.
Pgsql 좋아하지만.. mysql은 알아보지도 않고 아몰랑 시전이라니.. ㅋㅋㅋ

답변달기
▲
iolothebard 31일전  [-]

그냥 MySQL 쓰세요…

  • 왜 Postresql이 아닌가? 이 부분은 약간의 도움이 필요합니다.
답변달기
▲
aer0700 31일전  [-]

매우 큰 논쟁거리가 될만한 포스팅이네요...

답변달기
▲
aer0700 31일전  [-]

Sqlite를 쓰는 이유는 단순하면서도, 왠만한 규모에선 그냥 잘 작동한다는 건데,
그냥 sqlite로 먼저 구현해두고 나중에 필요하면 postgres로 가도 별 어려움 없을텐데요.

답변달기