▲

GN⁺: 데이터베이스와 그 복잡성이 이제 불필요한 이유

 (blog.redplanetlabs.com)
2P by neo 11달전 | favorite | 댓글 1개

데이터베이스의 문제점과 그 복잡성이 불필요한 이유

  • 데이터베이스는 전역 가변 상태로, 코드가 복잡해지고 이해하기 어려움을 초래함.
  • 데이터 모델은 제한적이며, 모든 사용 사례를 지원할 수 없어 여러 데이터베이스 사용이 필요함.
  • 정규화 대 비정규화 문제는 데이터 일관성과 성능 사이의 긴장 관계를 만들어냄.
  • 제한적인 스키마는 도메인 표현을 데이터베이스에 맞추기 위한 복잡성을 초래함.
  • 복잡한 배포는 다양한 도구들의 조합과 통합으로 인한 비용과 복잡성을 증가시킴.

응용 프로그램 백엔드 구축을 위한 일관된 모델

  • 백엔드의 기본 기능은 새로운 데이터를 받고 그 데이터에 대한 질문에 답하는 것임.
  • 이상적인 백엔드 설계는 실제 제약 조건을 충족하면서 가능한 한 이상에 가까워야 함.

Rama

  • Rama는 백엔드 개발 플랫폼으로, Mastodon을 재구현하여 Twitter 규모의 서비스를 제공함.
  • Rama는 데이터, 인덱스, ETL, 쿼리 등 백엔드의 모든 요소를 일반적인 방식으로 구현함.
  • Rama는 복잡한 배포를 간소화하고, 모니터링을 통합하여 개발 및 유지보수 비용을 대폭 절감함.

GN⁺의 의견

  • 데이터베이스의 전역 가변 상태 문제는 코드의 복잡성과 오류 가능성을 높이며, 이는 개발자들이 흔히 직면하는 문제임.
  • Rama는 기존 데이터베이스의 한계를 극복하고, 백엔드 개발의 복잡성을 줄이는 새로운 접근 방식을 제시함.
  • 이 글은 데이터베이스와 백엔드 시스템의 복잡성을 줄이고자 하는 개발자들에게 흥미롭고 유익한 정보를 제공함.
▲
neo 11달전  [-]
Hacker News 의견

  • 소스의 진실을 나타내는 하나의 서브시스템과 그 소스에서 파생된 여러 인덱스 저장소를 구현하는 또 다른 서브시스템을 사용해야 한다. 이것은 이벤트 소싱과 머티리얼라이즈드 뷰의 결합이다.

    • 이벤트 소싱과 머티리얼라이즈드 뷰: 소스의 진실을 나타내는 시스템과 이를 기반으로 한 인덱스 저장소를 분리하여 관리하는 것이 해결책임.

  • 우리는 읽기 모델과 쓰기 모델을 분리한다: 쓰기 모델("소스의 진실")은 전통적인 관계형 도메인 모델로 구성되며, 거의 모든 명령은 공유 도메인 이벤트 큐에 게시되는 이벤트를 생성한다. 읽기 모델은 이벤트를 소비하고 뷰를 구축하는 워커들에 의해 구성된다.

    • 읽기/쓰기 모델 분리: 쓰기 모델은 관계형 도메인 모델로 구성되며, 명령은 이벤트를 생성하여 도메인 이벤트 큐에 게시함. 읽기 모델은 이벤트를 소비하여 뷰를 구축함.

  • 데이터 변동 시 머티리얼라이징은 제품이 하나의 작업을 매우 빠르게 수행해야 할 때 이득을 가져다줄 수 있다. 하지만 복잡한 트랜잭션이 필요하거나 다르게 조직된 데이터가 필요한 새로운 기능을 추가하려 할 때 문제가 발생한다.

    • 데이터 머티리얼라이징의 한계: 단일 작업에 최적화된 경우 유용하지만, 복잡한 트랜잭션이나 새로운 데이터 구조가 필요한 기능 추가 시 문제가 발생할 수 있음.

  • 이것이 "트위터 규모의 마스토돈 클라이언트"로 증명되었다고 주장하는 것은, 실제로 하루 4000만 사용자 웹사이트를 운영하지 않는 한 불가능하다.

    • 규모의 중요성: 실제 대규모 사용자 환경을 시뮬레이션하는 것은 불가능하며, 이를 주장하기 어려움.

  • 더 나은 접근 방식은 이벤트 소싱과 머티리얼라이즈드 뷰의 결합이다.

    • 이벤트 소싱과 머티리얼라이즈드 뷰의 결합: 복잡성 증가를 수반하지만, 더 나은 접근 방식으로 제시됨.

  • 단일 데이터 모델이 모든 사용 사례를 지원할 수는 없다.

    • 데이터 모델의 다양성: 단일 데이터 모델로 모든 사용 사례를 지원하는 것은 불가능함.

  • 데이터베이스에 대한 불만이 없다.

    • 데이터베이스의 유효성: 데이터베이스에 대한 불만이 없으며, 여전히 유효한 도구임.

  • 동시성, 격리, 제약 조건 등의 개념이 누락되었는가? "쿼리 토폴로지"가 정말로 개발자 환경에 우월한가?

    • 쿼리 토폴로지에 대한 의문: 동시성, 격리, 제약 조건 등의 중요한 개념이 누락되었으며, 쿼리 토폴로지가 개발자 환경에 우월하다는 주장에 의문을 제기함.

  • Rama에 대한 ELI5(쉽게 설명해달라)가 필요하다. 문서가 혼란스럽고, "패러다임 변화"나 "플랫폼"과 같은 유행어는 사용하지 말 것.

    • Rama에 대한 간단한 설명 요청: Rama에 대한 쉬운 설명과 유행어 사용을 피한 명확한 설명 요청.

  • 이벤트 소싱 (+ 머티리얼라이즈드 뷰와 인덱스)는 RDBMS를 버리는 것이 아니다. 둘을 함께 사용할 수 있다.

    • 이벤트 소싱과 RDBMS의 공존: 이벤트 소싱과 머티리얼라이즈드 뷰를 RDBMS와 함께 사용할 수 있음, 둘은 상호 배타적이지 않음.

배경 지식:

  • 이벤트 소싱(Event Sourcing): 시스템의 상태 변화를 이벤트로 기록하여, 이를 재생함으로써 시스템의 상태를 재구성할 수 있는 설계 패턴.
  • 머티리얼라이즈드 뷰(Materialized Views): 데이터베이스의 쿼리 결과를 물리적으로 저장하여, 데이터 읽기 성능을 향상시키는 기술.
  • RDBMS(Relational Database Management System): 관계형 데이터베이스를 관리하는 시스템.
답변달기