본문 바로가기
개발일기/개발환경

Postgres만 사용해도 충분한 이유 (다른 SQL/DB/API 대비 장점)

by Daniel_Kevin 2024. 9. 21.
반응형

조언: 대부분의 웹 애플리케이션처럼 데이터의 지속적인 저장이 필요한 새로운 애플리케이션을 만들 때 기본 선택은 Postgres 이어야 합니다.

 

왜 안 돼 sqlite?

sqlite꽤 괜찮은 데이터베이스지만, 데이터가 단일 파일에 저장되어 있습니다.

이는 귀하의 애플리케이션이 무엇이든, 그것은 하나의 머신에서만 실행된다는 것을 의미합니다. 아니면 적어도 하나의 공유 파일 시스템.

데스크톱이나 모바일 앱을 만든다면 완벽합니다. 웹사이트를 만든다면 그렇지 않을 수도 있습니다.

 

웹사이트에 사용하는 데 성공한 사례는 많지만 sqlite, 대부분은 자체 서버와 인프라를 설정한 사람들이 관련됩니다. Heroku, Railway, Render 등과 같은 서비스로서의 플랫폼은 일반적으로 네트워크 경계를 통해 액세스하는 데이터베이스를 사용할 것으로 기대합니다.

 

이러한 플랫폼의 이점 중 일부를 포기하는 것은 잘못된 일이sqlite 아니지만, 플랫폼에서 제공하는 자동 데이터베이스 백업과 두 개 이상의 애플리케이션 서버를 프로비저닝하는 기능을 포기할 만한 이점이 있는지 고려하세요.

공식 문서에는 좀 더 구체적인 내용을 담은 유용한 가이드가 있습니다.

 

왜 안되나요 DynamoDB, Cassandra, 아니면 MongoDB?

릭 훌리한이 어디에 있든 좋은 하루 보내길 바랍니다.

저는 컨퍼런스 토크를 많이 보지만, 그의 2018 DynamoDB Deep Dive가 제가 가장 많이 본 토크일 수도 있습니다. 여러분 중 1시간짜리 토크를 볼 사람은 거의 없을 거라는 걸 알지만, 꼭 보세요. 좋은 토크입니다.

 

요점은 DynamoDB- 와 같은 장르에 속하는 데이터베이스는 - 를 포함하는 Cassandra경우 MongoDB환상적이라는 것입니다 . - 그리고 이는 다음과 같은 경우 부담이 됩니다.

 

  • 앱에서 무엇을 해야 하는지 정확히 알고 있습니다.
  • 당신은 당신의 접근 패턴이 정확히 무엇인지 미리 알고 있습니다
  • 정말 큰 크기의 데이터에 맞게 확장해야 할 필요성이 알려져 있습니다.
  • 일관성을 어느 정도 포기해도 괜찮습니다.

이런 종류의 데이터베이스는 기본적으로 거대한 분산 해시 맵이기 때문입니다. 전체 데이터베이스를 스캔할 필요 없이 작동하는 유일한 작업은 파티션 키에 의한 조회와 정렬 키를 사용하는 스캔입니다.

 

어떤 쿼리를 해야 하든, 저장하기 전에 해당 인덱스 중 하나에 해당 지식을 인코딩해야 합니다. 사용자를 저장하고 이름이나 성으로 조회하고 싶으신가요? 다음과 같은 정렬 키가 있는 것이 가장 좋습니다 <FIRST NAME>$<LAST NAME>. 액세스 패턴은 데이터를 저장하는 방법에 포함되어야 합니다. 액세스 패턴이 크게 변경되면 모든 데이터를 다시 처리해야 할 수 있습니다.

 

성가신 일인데, 특히 에서 MongoDB사람들은 그것이 더 "유연한" 데이터베이스라고 확신하고 그것을 사용하기 때문입니다. 네, 스키마를 제공할 필요가 없습니다. 네, 그냥 형식이 지정되지 않은 JSON을 컬렉션에 덤프할 수 있습니다. 아니요, 이것은 유연한 종류의 데이터베이스가 아닙니다. 효율적인 데이터베이스입니다.

 

관계형 데이터베이스를 사용하면 테이블에 인덱스 하나나 둘을 붙여서 사람의 모든 애완동물을 얻는 것에서 애완동물의 모든 주인을 얻는 것으로 갈 수 있습니다. 이 종류의 NoSQL에서는 그것은 엄청난 주문이 될 수 있습니다.

 

분석 쿼리를 실행해야 하는 경우에도 놀라운 일은 아닙니다. "지난달에 가입한 사용자 수"와 같은 임의의 질문은 SQL 쿼리를 작성하면 쉽게 답할 수 있으며, 고객 트래픽을 처리하는 동일한 머신에서 비싼 쿼리를 실행하는 것이 걱정된다면 읽기 복제본에 대한 답이 될 수 있습니다. 이런 종류의 데이터베이스의 범위를 벗어납니다. 처리하려면 데이터를 ETL해야 합니다.

 

대학생이나 신입 졸업생이 사용하는 것을 보면 MongoDB멈추세요. 그들은 도움이 필요합니다. 그들은 길을 잃었습니다.

왜 안 돼 Valkey?

이전에 로 알려진 아티스트는 Redis효율적인 프로세스 외부 캐시로 가장 잘 알려져 있습니다. 비싼 것을 한 번 계산하고 Valkey5개 정도의 HTTP 서버가 다시 계산할 필요가 없도록 넣습니다.

 

하지만, 기본 데이터베이스로 사용할 수 있습니다. 모든 데이터를 RAM에 저장하므로 그렇게 하면 꽤 빠릅니다.

 

명백한 문제들:

  • RAM은 그렇게 많이 가질 수 없습니다. 생각보다 훨씬 많이 가질 수 있지만, 하드 드라이브에 비하면 여전히 꽤 제한적입니다.
  • -likes 와 마찬가지로 DynamoDB데이터를 모델링하는 방법에 대해서도 양보가 필요합니다.

왜 안 돼 Datomic?

이미 이 사실을 알고 계신다면, 금상을 드립니다.

Datomic데이터베이스 NoSQL이지만 관계형 데이터베이스입니다. "사전 설계" 문제는 없고, 몇 가지 멋진 속성이 있습니다.

 

테이블에 데이터를 저장하지 않습니다. 모두 "엔터티-속성-값-시간"(EAVT) 쌍입니다. id, name, 를 포함하는 person 행 대신 와 를 age저장합니다. 그러면 쿼리가 "범용" 인덱스에서 작동합니다.1 :person/name "Beth"1 :person/age 30

 

질의를 할 때 작성자와 협력할 필요가 없습니다. 주어진 시간 "현재"에 대한 데이터베이스를 질의합니다. 새로운 데이터, 심지어 삭제(또는 그들이 "철회"라고 부르는 것)도 실제로 오래된 데이터를 삭제하지 않습니다.

 

하지만 몇 가지 심각한 문제가 있습니다

  • JVM 언어로만 작동합니다.
  • , 비교적 틈새 시장 언어인 것을 제외하면 ClojureAPI는 형편없습니다.
  • 쿼리를 제대로 구성하지 않으면 끔찍한 오류 메시지가 표시됩니다.
  • SQL에 필요한 도구 전체가 존재하지 않습니다.

왜 안 돼 XTDB?

Clojure사람들은 많은 데이터베이스를 만듭니다.

XTDB영적으로 유사하지만 Datomic:

  • HTTP API가 있으므로 JVM에 얽매이지 않습니다.
  • 여기에는 쿼리할 수 있는 두 가지 시간 축이 있습니다. "시스템 시간" - 레코드가 삽입된 시간 - 및 "유효 시간".
  • SQL API가 있습니다.

 

이에 대한 가장 큰 반대 의견은 다음과 같습니다.

  • 새로운 기능입니다. SQL API는 작년에 등장한 것입니다. 최근에 전체 스토리지 모델을 변경했습니다. 이 회사의 배후에 있는 회사가 앞으로 10년을 버틸 수 있을까요? 누가 알겠습니까!

 

좋아요, 그건 한 가지 요점일 뿐입니다. 더 많은 것을 생각해 낼 수 있겠지만, 최근에 개발된 데이터베이스의 대체물로 취급하세요. 무언가가 미래에도 계속 존재할지 예측하는 가장 좋은 방법은 그것이 얼마나 오랫동안 존재했느냐는 것입니다. COBOL은 수십 년 동안 존재해 왔고, 앞으로도 수십 년 동안 존재할 가능성이 큽니다.

 

영구 저장소가 있는 경우 가능한 한 긴 지원 기간을 원할 것입니다. 앱에 대해 새롭거나 실험적인 데이터베이스를 선택할 수는 있지만 기술적 속성과 관계없이 위험한 선택입니다. 기본이 되어서는 안 됩니다.

왜 안 돼 Kafka?

Kafka추가 전용 로그입니다. TB 단위의 데이터를 처리할 수 있습니다. 매우 좋은 추가 전용 로그입니다. 여러 인간 팀이 관리하는 여러 서비스에서 데이터가 유입되는 이벤트 소싱 유형의 작업을 수행하려는 경우 놀라울 정도로 잘 작동합니다.

 

하지만:

  • 일정 규모까지는 Postgres의 테이블은 추가 전용 로그로 완벽하게 작동합니다.
  • 귀하의 제품에는 수백 명의 사람이 일하고 있지 않을 것이고, 수 테라바이트 규모의 이벤트도 끊이지 않을 것입니다.
  • 카프카 소비자를 만드는 것은 예상보다 오류가 발생하기 쉽습니다. 결국 로그에서 자신의 위치를 ​​추적해야 합니다.
  • 클라우드 제공자가 유지 관리하는 경우(그리고 좋은 관리 Kafka서비스가 있습니다)에도 모니터링해야 할 또 다른 인프라입니다.

왜 안 돼 ElasticSearch?

데이터 검색이 귀하 제품의 주요 기능입니까?

그렇다면, ElasticSearch몇 가지 진짜 장점이 있을 겁니다. 데이터를 ETL해서 넣고 전체 프로세스를 관리해야 하지만 ElasticSearch검색을 위해 만들어졌습니다. 검색이 잘 됩니다.

 

아니요, Postgres괜찮습니다. 약간의 기능 ilike과 내장된 전체 텍스트 검색 기능 이 대부분 애플리케이션에 충분합니다. 나중에 전용 검색 기능을 볼트로 고정할 수도 있습니다.

왜 MSSQL안되나요 Oracle DB?

스스로에게 진지하게 물어봐야 할 질문입니다: 이게 가격대비 가치가 있을까요?

저는 라이선스에 드는 직접적인 비용뿐만 아니라 잠금 비용도 말합니다. 데이터가 들어오면 Oracle DB영원히 Oracle에 비용을 지불해야 합니다. 영원히 코더들에게 Oracle의 특성에 대해 교육해야 합니다. 영원히 엔터프라이즈 기능과 지갑 중에서 선택해야 합니다.

 

당신이 패치를 기여할 가능성은 매우 낮다는 것을 알고 있으므로 Postgres, 나는 어떤 마법의 "오픈 소스의 힘"이 일어나고 있다고 가장하지 않겠지만, 당신은 독점 DB를 선택하기 위해 매우 구체적인 필요성을 염두에 두어야 한다고 생각합니다. 당신이 없이는 살 수 없는 킬러 기능이 없다면 MSSQL, 그것을 사용하지 마세요.

왜 안 돼 MySQL?

이 부분은 청중의 도움이 필요합니다.

MySQLOracle이 소유하고 있습니다. Enterprise Edition 뒤에는 기능이 잠겨 있습니다. 어느 정도 다른 DB와 마찬가지로 잠금 문제가 있을 것입니다.

 

하지만 무료 버전 MySQL도 매우 광범위한 용도로 사용되었습니다. 오래 전부터 있었습니다. 그것을 다루는 방법을 아는 사람들이 있습니다.

 

제 문제는 제가 제 직업 경력 중 ~6개월만 이걸 다루었다는 것입니다. 저는 정말로 이걸 지능적으로 비교할 만큼 충분히 알지 못합니다 Postgres.

 

비밀리에 그렇게 나은 것은 아니라고 확신하는데, 내가 사람들에게 사용하라고 말함으로써 그들에게 해를 끼치고 있는 것이 사실 Postgres이고, 일반적으로 DB 자체에서 불변성을 적용하는 데 더 나은 지원을 한다는 것에 대한 글을 읽은 기억이 나지만 Postgres, 여기서 조금 더 교육을 받아도 좋을 것 같습니다.

AI 벡터 DB는 왜 안 될까?

  • 대부분은 새것입니다. 새로운 것을 사용하는 데에는 위험이 있다는 것을 기억하세요.
  • AI는 거품입니다. 부담을 주는 거품이지만, 거품입니다. 피할 수 있다면 그 위에 집을 짓지 마세요.
  • 귀하의 사업이 또 다른 AI 사기라 하더라도 아마도.만 하면 될 것입니다 import openai.

왜 Google 시트를 사용하지 않나요?

네 맞아요. 단점이 생각나지 않아요. 해보세요.

 

*참고한 원본 글 https://mccue.dev/pages/8-16-24-just-use-postgres

반응형
그리드형

댓글