우리 PostgreSQL은 언제부터 이뻤나?

아래 글을 읽으면서 메모하고 개인적인 생각을 적은 글

• 최근에 PostgreSQL을 사용해봤는데 뭐가 특별한지 모르겠다고 느끼던 차, 보이길래 읽었다.
• 그냥 아주아주 단순한 데이터 저장하는 용도로만 써서 몰랐지...
• 그나저나 사이트 OG image 웃기다 (제목에 딱 어울림)

When Did Postgres Become Cool?

 

 

crunchydata 라는 회사에 속한 분이 쓴 글이라 회사 홍보마냥 관련 참조 사이트가 다 crunchydata이다.

• 그렇다는 것은 PostgreSQL이 여기 사업과 관련이 있을 것.
• 읽기 전에 다짐: (거의) 무조건 PostgreSQL 칭찬만 할 것이기에 비판적으로 읽어야 한다.
• 나도 모든 참조 링크를 읽어보진 않았다.

 

딥하게 다루진 않고, 아 이런게 있었구나만 다룬다.

---

PostgreSQL은 어떻게?

PostgreSQL은 오픈소스 프로젝트로 25년 되었다.

• 이제 PostgreSQL 16버전이 곧 나온다.

 

어떻게 지금까지 이 위치까지 올라 왔을까? 사람들은 왜 사용할까?

 

아, PostgreSQL에 대해 잘 알지 못한다면, 이 글을 읽어보자.

• https://www.crunchydata.com/why-postgres

요약하면 이런 내용들

• Reliable and safe for your data
• Extremely feature rich
• No central owner means no lock-in
• More than "just a database", it's a data platform

 

PostgreSQL이 되기까지

Postgres는 Ingres 라는 프로젝트에서 시작되었음.

• 처음엔 버클리 대학에서 대화형 그래픽 검색 시스템(INterative Graphics REtrieval System)으로 개발했으나, Relational Database project로 변경되었다.
• 원래 언어는 SQL이 아닌 QUEL이었다. 1986년 ANSI가 SQL을 선택하자, 많은 관계형 데이터베이스 프로젝트들이 이동했다. 1995년 Postgres95가 출시되며 SQL을 지원하기 시작함.
  • QUEL?: https://www.wikiwand.com/en/QUEL_query_languages
  • ANSI?: 미국 국가표준 협회 (American National Standards Institute).
    • https://www.wikiwand.com/ko/%EB%AF%B8%EA%B5%AD_%EA%B5%AD%EA%B0%80%ED%91%9C%EC%A4%80_%ED%98%91%ED%9A%8C
• 1996년 PostgreSQL의 첫 번째 버전이 6.0으로 출시되고, 글로벌 개발팀이 설립되면서 학계에서 벗어나 개발되기 시작했다.
• 지금의 PostgreSQL을 만든 MVCC는 1999년 PostgreSQL 6.5와 함께 등장하였음.
  • MVCC?: Multi-Version Concurrency Control
    • https://devcenter.heroku.com/articles/postgresql-concurrency
    • 각 DB 별 MVCC + Vaccum 이란?: https://techblog.woowahan.com/9478/

 

성장의 시작

PostgreSQL은 2000년대 초 데이터베이스와 SQL에 중점을 두고 많은 핵심 기능들을 도입했음.

예를 들어,

• WAL (Write-Ahead-Log)
  • 간단히 설명하면 변경을 로깅한 후에만, 즉 변경 내용을 설명하는 로그 레코드를 영구적 저장소에 먼저 기록한 후에 데이터 파일(테이블과 인덱스가 있는)의 변경 내용을 작성
  • The changes are first recorded in the log, which must be written to stable storage, before the changes are written to the database.
• Outer joins
• TOAST
• 40억건 이상의 transaction
• Drop column
• Schemas
• IPv6

 

또한, 커뮤니티가 활성화되었고 초기 개발자들(유명한 개발자들)이 이에 많이 참여했음.

• 오라클과 달리 오픈소스의 강점이 있었다고 말함.

 

계속적인 발전

2005년 쯤 되면서 Postgres는 상당히 안정적인 데이터베이스로 간주되었음.

• 더 풍부한 트랜잭션 지원, 광범위한(board) SQL 지원, WAL/VACUUM 기능 향상 등
• 신뢰할 수 있는 데이터베이스였으나, 사용 편의성 측면에서는 아직 개선해야할 점들이 있었음

 

다른 사람들이 헤드라인 피쳐(headlining features)에 기여하기 시작했고, 다양하고 여러 기능들이 존재하기 시작

• Concurrent index creation
• Warn standby servers
• Query language improvements
• All data types - Arrays/UUID/ENUM/XML
• Two phase commit
• A richer role system

 

글쓴이는 2009년 PostgreSQL 8.4버전의 window functions and common table expressions(CTEs)가 나온 이후로 다른 데이터베이스로 돌아가지 않을 것이라고 함.

• https://www.crunchydata.com/developers/playground/ctes-and-window-functions
• 대충 보면, MySQL VIEW 같은 느낌인데...

내 생각이 맞았다.

CTE와 비교대상으로는 VIEW가 있다. VIEW는 만들기 위해 권한이 필요하고 사전에 정의를 해야한다. 반면, CTE는 권한이 필요 없고 하나의 쿼리문이 끝날때까지만 지속되는 일회성 테이블이다. CTE는 주로 복잡한 쿼리문에서 코드의 가독성과 재사용성을 위해 파생테이블 대신 사용하기에 유용하다.

• https://yahwang.github.io/posts/49

• MySQL에서도 8.0 버전 이후로 지원한다고 한다.
  • https://dev.mysql.com/doc/refman/8.0/en/with.html

 

이 무렵부터 Postgres는 탄탄한 기반이 만들어지면서 데이터베이스 생태계에 광범위하게 영향을 미치기 시작함.

• 탄탄한 코드 기반 + 라이선스 덕분에 여러 기업들이 채택하기 시작
• 포크해서 MPP(Massive Parallel Processing) 지원/OLAP 중심 워크로드를 더하기 시작했음. 여기에 window functions and common table expressions(CTEs) 사용하면서 강력해짐.
• 당시 나온 여러 파생 데이터베이스들은 Cisco, IBM 등에 인수되어 사용되어져왔음.

 

Postgres 행진

Postgres의 포크가 확산되었지만, Postgres는 자체적으로 계속 발전하고 있었음.

 

Postgres 9.0 ~ 9.1 / 2010

글쓴이 말로는 멋있어 지기 시작한 시기라고 함ㅋ.

• pg_upgrade가 만들어지면서 업그레이드가 쉬워짐.
  • 사실 말이 쉽지 좀 찾아보면 여러 오류 로그도 있는 듯. 뭐 근데 당시에는 DB 버전 업그레이드는 매우 어려운 일이지 않았을까 추측 (지금도 그렇지만).
  • 추가적으로 Transactional DDL 지원. 마이그레이션 시 오류나면 알아서 잘 롤백해준다고 함.
    • https://wiki.postgresql.org/wiki/Transactional_DDL_in_PostgreSQL:_A_Competitive_Analysis
• GIN/GiST 인덱스가 출시되며 표준 B-Tree 인덱스 이상의 기능을 갖추기 시작
  • 관련 국내 자료: https://www.slideshare.net/pgday_seoul/pgdayseoul-2017-6-gin-vs-gist
  • https://medium.com/vuno-sw-dev/postgresql-gin-%EC%9D%B8%EB%8D%B1%EC%8A%A4%EB%A5%BC-%ED%86%B5%ED%95%9C-like-%EA%B2%80%EC%83%89-%EC%84%B1%EB%8A%A5-%EA%B0%9C%EC%84%A0-3c6b05c7e75f
• 서로 다른 Postgres DB를 연결할 수 있도록 하는 Postgres foreign data wrapper가 개발됨.

 

JSON / 2012

NoSQL 데이터베이스(Mongo, Couchbase 등)가 부상하면서 개발자들은 데이터 작업 방식이 달라지길 원했음.

Postgres는 이러한 요구에 부응하기 위해 JSON을 지원하기 시작했음. (완벽한 지원은 아님)

• 유효성 검사를 지원했지만, 단순히 텍스트 필드를 이용했다고 함. 찾아보니 공백/객체 키 순서 등 원시형태로 JSON 데이터를 저장하는 형식임.

 

간편한 앱 배포를 위한 Heroku가 등장하고, 기본 데이터베이스인 Heroku Postgres가 등장하는 등 다양한 데이터베이스 인프라가 성장하기 시작.

• 기본 값으로 PostgreSQL 사용이었던 듯. Ruby on Rails가 핫했던 것으로? 아니 지금도 외국에서는 많이 사용한다고 들었던 것 같은데 당시 Heroku 많이 사용해서 PostgreSQL을 많이 접했다고 한다.

 

JSON for real, AWS RDS / 2014

Postgres 9.4에서 JSONB라고 하는 더 나은 JSON이 추가되었음.

• JSON을 바이너리로 표현한 것으로 GIN 인덱스를 이용하면 데이터를 쉽게 인덱싱할 수 있음.

 

JSON 타입은 입력받은 텍스트값을 DB에 그대로 저장한다. 그래서 쓰기 비용이 크지 않다. 그러나 읽기 비용이 있다.
반면 JSONB 타입은 입력받은 데이터를 바이너리 포맷으로 저장한다. 그래서 쓰기 비용이 크다.
그러나 인덱싱이 가능하고, 데이터 파싱 비용이 들지 않기 때문에 읽기 비용이 적다는 이점이 있다.

• https://americanopeople.tistory.com/300
• json 저장방식은 진짜 지금봐도 어색하면서 신박하다. 막상 현업에서 사용하는 곳이 있다면 어떻게 사용할지? => 인덱스 어떻게 설정해둘지...?

 

Logical decoding을 통해 CDC를 더 쉽게 할 수 있는 토대를 마련했음.

• https://www.postgresql.org/docs/current/logicaldecoding-explanation.html
• 대충보니깐 지금의 CDC 개념과 비슷한 듯?
  • 테이블의 변경사항을 일관되고 이해하기 쉬운 형식으로 추출하는 형식

Logical decoding is the process of extracting all persistent changes to a database's tables into a coherent, easy to understand format which can be interpreted without detailed knowledge of the database's internal state.

 

Postgres 9.3 쯤 Amazon이 Re:Invent에서 RDS - PostgreSQL을 지원한다고 발표.

• Re:Invent 에서 청중이 기립박수 친건 이게 유일하다고 함ㅋ
• 생각보다 최근이여서 놀랐음. Aurora에서도 2015년 부터? 지원하기 시작한 듯

 

9.5, 9.6, 10 / 2016

이 때부턴 헤드라인 기능은 줄어들기 시작했고, 꾸준한/지속적인 성능개선이 이뤄졌음.

JSONB 인라인 업데이트, 병렬 실행 같은 기능들이 추가되었고, 아래의 주요 기능들이 추가되었음.

• Row level security
  • https://www.crunchydata.com/blog/a-postgresql-row-level-security-primer-creating-large-policies
• Logical replication
  • https://www.crunchydata.com/blog/data-to-go-postgres-logical-replication
• Table partitioning
  • https://www.crunchydata.com/blog/native-partitioning-with-postgres

 

Extension - 확장 기능

postgres는 확장 기능을 지원했는데, 코드에서 라이브러리라고 생각하면 됨.
Postgres의 메인 코드에 기여하지 않아도 동작을 변경시킬 수 있는 것.

• JSONB가 등장하기 전에 hstore 라는 extension을 사용한다거나 등

 

PostGIS는 Postgres와 병행하면서 가장 강력한/기능이 풍부한 지리공간 데이터베이스로 탈바꿈 되었음.

• 새로운 연산자/함수/데이터 유형이 추가됨.
• PostGIS가 PostgreSQL extension인지는 처음 알았다.
  • PostGIS 위키에도 다음과 같은 내용이 있음.

 

Technically PostGIS was implemented as a PostgreSQL external extension.

• • https://www.postgresql.org/docs/current/external-extensions.html

 

결론

마지막엔 왜 많이 사용하는 기술이 되었는가에 대한 이야기가 나온다.

• Heroku의 기본 값으로 설정되면서 Rails 개발자들에게 시작하는 DB 였기에?
• 무시는 못하지만 풍부한 JSON 지원기능, 지속적인 개선, 데이터 작업의 유연성, 풍부한 SQL 지원 등이 있어서도 있지 않을까 하는 이야기들. 꾸준한 릴리즈 주기, 품질에 대한 집중 등...

 

DB에 대해서는 비즈니스 상황에 맞게 선택하고(RDB? NoSQL?), 인덱스를 어떻게 설정할지? 성능은 어떻게? 이런 것들만 고려해왔다. 그리고 몇 년전만 해도 RDB에서는 MySQL가 당연하지 않나?(일단 회사에서 쓰는게 이거니) 라는 생각 했는데 최근에 외국 글을 보면 사실 PostgreSQL이 더 흔히 사용되는 것 같기도 하다.

• 여러 Survey 참조
  • https://stateofdb.com/databases
  • https://survey.stackoverflow.co/2023/#section-most-popular-technologies-databases

국내는 배민이 제일 유명한 듯

• 대충 사용 예제도 나옴. jsonb를 hibernate/JPA로 사용하는 법이라던지: https://www.slideshare.net/pgday_seoul/pgdayseoul-2022-postgresql-254363748
• https://techblog.woowahan.com/6550/

 

다른 얘기지만, hibernate 6가면 외부 라이브러리 없이 사용 가능한 듯하다.

• https://jpa-buddy.com/blog/hibernate6-whats-new-and-why-its-important/
• 여기서 말하는 외부 라이브러리는 유명한 Vlad Mihalcea 아저씨의 라이브러리  
  • https://github.com/vladmihalcea/hypersistence-utils

 

역사는 잘모르지만 사실 데이터의 정합성을 위해서라면 (옛날엔) 오라클이 당연했던 것 같기도 하다.

• 오픈소스 데이터베이스, 은행 서비스에 첫발을 내밀다 (카카오 뱅크)
  • https://tv.naver.com/v/2293649

 

글을 읽어보니 간단하게 여러가지 살펴볼 수 있어서 좋았다.

• 이전에 MySQL Spatial Data Type을 사용해봤을 때도 '와 이런게 있었네. 왜 몰랐지.'하면서 재밌게 썼던 기억이 있다. 데이터베이스도 언어/프레임워크랑 비슷한 것 같다. 모르던 부분들이 참 많다.
  • 데이터베이스는 그냥 숫자/날짜/문자 저장하고 조회하는 곳 이라는 단순한 생각 때문에 딥하게 생각을 못했던 것 같기도 하다.
• 데이터베이스의 다양한 타입과 다양한 방법으로 서비스를 향상 시킬 수 있다. (물론 그만큼 공부를 해야겠지만)
  • 성능 뿐 아니라 개발자의 편의성도 !