Hacker News 의견

• "database-per-tenant" 방식을 약 100만 명의 사용자와 함께 사용 중임

  • 이 방식은 읽기 중심의 앱에 적합하며, 대부분의 테넌트는 작고 테이블에 많은 레코드가 없어 복잡한 조인도 매우 빠름
  • 주요 문제는 개별 데이터베이스를 하나씩 마이그레이션해야 하므로 릴리스 시간이 크게 증가할 수 있음
  • 스키마나 데이터 드리프트가 발생하면 릴리스가 중단되고, 일부 테넌트에서 기능이 작동하지 않는 이유를 찾아야 함

• SQLite를 좋아하지만, 기존 OLTP 데이터베이스가 인덱스의 일부를 메모리에서 언로드할 필요가 있는지 궁금함

  • 사용자별 데이터베이스를 사용하면 비활성 사용자나 다른 인스턴스에서만 활성화된 사용자를 위해 메모리에 아무것도 유지하지 않음
  • 이는 Mongo의 JSON 상황과 유사하며, Postgres가 Mongo보다 두 배 빠름

• 대부분의 사람들은 테넌트별 데이터베이스가 필요하지 않으며, 이는 일반적인 방식이 아님

  • 마이그레이션과 스키마 드리프트와 같은 단점을 상쇄해야 하는 특정 사례가 있음
  • 사용할 수 있다고 해서 반드시 사용해야 하는 것은 아님
  • 주의해서 진행하고 테넌트별 데이터베이스가 필요하다는 사실을 알아야 함

• 중간 접근 방식으로 다음을 고려할 수 있음

  • 상위 N개의 테넌트를 식별함
  • 이 테넌트를 위한 DB를 분리함
  • 상위 N개는 IOPS, 중요도(수익 측면) 등을 기준으로 결정됨
  • 데이터 모델은 각 테넌트에 해당하는 행을 추출할 수 있도록 설계되어야 함

• 우연히도 Elixir를 위한 FeebDB를 작업 중임

  • 이는 Ecto의 대체물로 볼 수 있으며, 수천 개의 데이터베이스가 있을 때 잘 작동하지 않음
  • 주로 재미있는 실험으로 시작했지만, 과거에 일했던 모든 곳에서 이러한 아키텍처가 큰 도움이 될 것임
  • 데이터베이스-테넌트 접근 방식의 일반적인 문제점을 제거하거나 줄이는 것이 목표임
  • 각 데이터베이스에 단일 작성자 보장
  • 모든 테넌트에 대한 향상된 연결 관리
  • 필요 시 마이그레이션 및 백업 지원
  • 여러 DB에 대한 맵/리듀스/필터 작업 지원
  • 클러스터 배포 지원

• Forward Email은 각 메일박스/사용자별로 암호화된 sqlite db를 사용하여 유사한 작업을 수행함

  • 사용자별 보호를 차별화하는 훌륭한 방법임

• 이름이 매우 훌륭함. Sean Connery를 연상시킴

• "database per tenant" 워크플로우는 이제 시작임

  • James Edward Gray가 2012년 RailsConf에서 이에 대해 이야기함

• 과거에 유사한 것을 사용했으며, 매우 만족했음

  • 사용자가 데이터를 원하면 전체 데이터베이스를 제공할 수 있음
  • 사용자가 계정을 삭제하면 rm username.sql로 간단히 처리 가능
  • 컴플라이언스가 매우 쉬워짐

• 데이터가 서로 격리되고 단일 테넌트 내에서 확장 문제가 없을 때 잘못된 설계를 하기 어려움

  • 거의 모든 것이 작동할 것임