This page contains information related to upcoming products, features, and functionality. It is important to note that the information presented is for informational purposes only. Please do not rely on this information for purchasing or planning purposes. The development, release, and timing of any products, features, or functionality may be subject to change or delay and remain at the sole discretion of GitLab Inc.
Status Authors Coach DRIs Owning Stage Created
proposed @mikolaj_wawrzyniak @jdrpereira @pskorupa @DylanGriffith @nhxnguyen workinggroup clickhouse 2023-02-23

ClickHouse 또는 대체재와 상호 작용하기 위한 추상화 레이어 고려

목차

요약

ClickHouse를 설치하지 않을 GitLab 설치에 대한 ClickHouse 또는 대체재에 대한 표준화된 읽기 액세스 솔루션을 제공합니다. 다양한 오픈 소스 도구를 분석하고 내부적 솔루션 구축 옵션과 비교한 후, 현재 권장되는 접근 방식은 각 데이터 소스에 연결하기 위해 전용 데이터베이스 수준의 드라이버를 사용하는 것을 제안합니다. 또한, 리포지터리 패턴의 사용을 제안하여 선택적으로 데이터베이스의 가용성 복잡성을 단일 응용프로그램 레이어로 제한하는 것을 제안합니다.

동기

ClickHouse를 실행하려면 상당한 리소스가 필요하며, GitLab의 작은 설치는 제공된 성능 향상으로부터 수익을 얻을 수 없을 수 있습니다. 이로 인해 ClickHouse가 모든 설치에 대해 전역적으로 사용 가능하지 않을 수 있으며 기능은 사용 가능한 다른 데이터 리포지터리 간에 번갈아야 할 수도 있습니다. 이미 제안된 현재 및 미래의 ClickHouse 사용 사례 중 10개 중 7개가 ClickHouse와 다른 데이터 리포지터리를 사용합니다. 이러한 맥락을 고려하면 ClickHouse를 채택하려는 그룹이 사용 가능한 데이터 리포지터리와 상호 작용을 표준화하여 지원하는 것이 중요합니다.

제안된 솔루션은 독립적으로 통합된 상호 작용을 제공하는 독립형 도구에서부터 상호 작용을 지원하는 각 데이터 리포지터리를 지원하는 라이브러리 세트로 다양한 형태로 나타날 수 있습니다. 이 때문에, 주어진 규칙 및 제약 사항을 기술하고 캡슐화의 경계를 그릴 수 있는 구현 가이드라인을 통해 각 데이터 리포지터리를 지원하는 방법에 대해 설명되어야 합니다.

목표

  • 전체 GitLab 애플리케이션 코드베이스에 대한 옵션으로 사용 가능한 데이터 리포지터리의 영향을 단일 추상화 레이어로 제한
  • 모든 데이터 리포지터리별 특정 기능 지원
  • 메인 GitLab 애플리케이션의 위성 서비스와의 통신 지원

비목표

  • 이 제안은 데이터베이스와 직접적으로 쓰기 통신을 고려하지 않습니다(보충 노력의 주제입니다).
  • 이 제안은 스키마 변경 및 데이터 이관 도전을 직접적으로 고려하지 않습니다.

위의 점이 비목표임에도 적용될 수 있는 경우 최종 솔루션에 일부 변경을 적용할 수 있음을 이 문서의 끝에 있는 오픈 질문 섹션에서 표현했습니다.

가능한 해결책

이전 단락에서 설명한 고수준의 목표는 내부에서 구축된 솔루션과 오픈 소스 도구 모두로 달성할 수 있습니다. 다음 절에서는 두 가지 접근 방식에 대해 더 자세히 살펴볼 것입니다.

권장 접근 방식

MVC와 반복의 정신을 고려하여 해당 솔루션이 목표를 달성하고 Motivation 섹션에 나열된 문제를 완화하는 데 필요한 경우, Ruby에서 ActiveRecord와 같은 해당 데이터 리포지터리와 직접 상호 작용하는 드라이버를 기반으로하는 솔루션으로 시작하는 것이 제안됩니다. 제한된 시간과 노력으로 비해 제한 사항이 그룹들이 ClickHouse 기능을 최대한 활용할 수 있도록 방해될 수 있음을 우려하는 워킹 그룹 다른 구성원들의 피드백을 받은 후, 이러한 드라이버들은 정적 코드 분석으로 적용된 개발 가이드라인 집합을 지원해야 합니다.

예를 들어, 이미 제안된 ClickHouse 문서에 따르면 Ruby와 Go에서 다음과 같은 드라이버가 있습니다

Ruby
  1. ClickHouse Ruby driver - Observability 그룹의 연구의 일환으로 GitLab의 일부로 사용하기 위해 이전에 선택됨(참조: issue)
  2. Clickhouse::Activerecord
Go
  1. ClickHouse/clickhouse-go - 공식 SQL 데이터베이스 클라이언트
  2. uptrace/go-clickhouse - 대체 클라이언트
제안된 클라이언트 아키텍처

코드베이스를 잘 구성하고 특정 데이터베이스 엔진에 결합을 제한하기 위해서 상호 작용, 쿼리 데이터를 응용프로그램 상위 레이어에서 나타낼 중요성이 있습니다(추상화 계층을 통한 ActiveRecord 인터페이스 전파 참조).

기본 데이터베이스 엔진을 캡슐화하면 권장 솔루션은 그룹들이 탐구하고 사용 사례를 이해할 수 있는 시간을 제공하면서 나중에 다른 도구를 소개할 수 있는 두 가지 선택이 가능한 문로 결정으로 좋은 솔루션이 됩니다.

최소 추상화 레이어에서는 ClickHouse 드라이버와 직접 상호 작용하는 클래스 패밀리가 기대됩니다. Rails에 의해 구현된 MVC 패턴을 따르는 이러한 클래스는 _모델_로 분류될 수 있습니다.

모델 수준의 추상화는 기존 패턴 및 가이드라인을 잘 설계하지만, Self-Managed형 인스턴스의 ClickHouse 데이터베이스의 선택적 가용성 도전을 해결하지 못합니다. 비즈니스 로직 요청에 최적의 데이터베이스를 선택하는 책임을 수행할 전용 엔터티를 설계하는 것이 필요합니다. 이미 언급된 기존 추상화 가이드라인 상에서 Finders가 주요 요구사항과 가장 유사한 이유 때문에 Finders는 상위 모든 레이어에서 데이터베이스 공급업체 세부 사항을 숨기는 자체 공개 API 뒤에서 데이터베이스 특정 상호 작용을 캡슐화하는 데 적합할 것으로 보입니다.

그러나 그들은 ActiveRecord ORM 프레임워크에 밀접하게 결합되어 있으며, 모든 레이어에게 자세한 데이터가 서로 다른 두 데이터베이스에서 올 수 있고 서로 호환되지 않을 수 있기 때문에 Finders는 ClickHouse의 선택적 가용성과 어울리지 않습니다.

상기 사항을 고려하면 ClickHouse의 선택적 가용성을 다루기 위해 Finders처럼 동일한 추상화 수준에 새 엔터티를 추가하는 것을 고려할 가치가 있습니다.

필요한 격리 수준은 리포지터리 패턴의 사용을 통해 달성될 수 있습니다. 리포지터리 패턴은 비즈니스/도메인 로직을 데이터 액세스 관심에서 분리하는 데 설계되어 있으며, 이것이 바로 이 제안이 찾고 있는 것입니다. 또한 리포지터리 패턴은 기본 데이터베이스에서 수행되는 작업을 제한하지 않으므로 기능을 완전히 활용할 수 있습니다.

리포지터리 패턴을 구현하기 위해 다음 사항이 있습니다:

  1. 각 지원되는 데이터베이스에 대한 전략. 예를 들어: MyAwesomeFeature::Repository::Strategies::ClickHouseStrategy 및 MyAwesomeFeature::Repository::Strategies::PostgreSQLStrategy. 전략은 쿼리를 구성하는 데이터베이스와의 통신을 구현하는 책임이 있습니다.
  2. 데이터베이스와 상호 작용하는 높은 수준의 인터페이스를 노출하는 리포지터리. 일부 사전 정의된 기준 및 데이터베이스 가용성과 같은 기준으로 선택된 가능한 전략을 사용하여 선택된 전략을 사용하며, 단일 리포지터리에서 사용되는 전략은 상호 교환 가능하도록 동일한 공개 인터페이스를 공유해야 합니다.
  3. 응용프로그램 레이어에 구현된 비즈니스 로직 데이터를 나타내는 Plain Old Ruby Object(PORO) 모델. 데이터베이스에 독립적이어야 합니다.

ErrorRepository은 선택적인 데이터베이스의 예를 보여주는 좋은 예입니다.

ErrorRepository는 두 가지 전략을 사용하고 있습니다:

  1. OpenApiStrategy를 사용하여 API 프록시 엔터티를 통해 ClickHouse와 상호 작용합니다.
  2. ActiveRecordStrategy를 사용하여 ActiveRecord 프레임워크를 통해 PostgreSQL와 상호 작용합니다.

또한, ErrorRepository는 리포지터리 패턴을 통해 지원되는 데이터 리포지터리 유형에 대한 비교적 유연성을 보여주는 좋은 예입니다.

이러한 모든 내용은 리포지터리 패턴에 기반한 솔루션이 이미 Observability 그룹에 의해 구현되었음을 보여줍니다.

Merge Request에서는 현재의 GitLab 아키텍처를 기반으로한 ActiveRecord Models, Services 및 Finders를 리포지터리 패턴으로 이전하는 데에 대한 변경 사항을 문서화합니다.

클라이언트 아키텍처를 강제로 적용하는 가능한 방법

클라이언트 측 아키텍처를 제안하는 것만으로는 일반적인 사례로 완전히 확립되기에는 충분하지 않습니다. 개발자가 무의식적으로 이를 위반하는 위험을 줄이기 위해 자동으로 강제하는 것이 필요합니다. 리포지터리 패턴 구현의 자동 확인을 위한 여러 가지 방법이 있습니다. 이를 통해 ClickHouse에서 Strategies 외부에서 실행된 쿼리를 감지하도록 하는 방법을 도입할 수 있습니다.

  1. Database::PreventCrossJoins와 비슷한 방식으로 ActiveRecord 쿼리 구독자를 활용하여 ClickHouse 드라이버의 사용을 지정된 Strategies 외부에서 감지합니다.
  2. ClickHouse 드라이버 사용을 Strategies 외부에서 모두 감지하도록 CodeReuse RuboCop 규칙을 확장합니다.
  3. ClickHouse 인스턴스의 존재 여부를 확인하는 유틸리티 메소드 호출을 감지하는 RuboCop 규칙을 생성합니다. (즉, CurrentSettings.click_house_enabled?와 같은 호출이 Repositories 외부에서 수행될 때)

이러한 개발 단계에서 저자들은 모든 나열된 옵션을 실행 가능하고 유망한 것으로 보고 있으므로 ClickHouse를 위한 첫 번째 리포지터리 패턴 구현이 나타날 때까지 사용할 옵션을 결정하기로 결정되었습니다.

오픈소스 도구 개요

이 섹션에서 저자들은 목표 달성을 위한 대체 접근 방식으로 고려된 기존 3rd 파티 오픈소스 솔루션에 대한 개요를 제공합니다.

평가 기준

1. 라이선스 (필수 사항)
  1. 해결책은 acceptable license에 따라 오픈 소스 여야 합니다.
2. 다른 데이터 리포지터리 지원 (필수 사항)
  1. 제안된 추상화 계층이 ClickHouse와 PostgreSQL을 모두 지원하는지에 중점을 둡니다 (필수 사항)
  2. 두 가지 필수 요구 리포지터리 이상을 지원하는지 여부도 고려하세요
  3. 해결책은 PostgreSQL의 minimum required versions을 지원해야 합니다.
3. 프로토콜 호환성

각 추상화 레이어에는 공통 추상화를 위해 도구 API에 비해 제한된 API가 포함되어 있습니다.

  1. PostgreSQL 및 ClickHouse를 통해 수행할 수 있는 읽기 작업 나열 (selects, joins, group by, order by, union 등)
  2. 제안된 추상화 계층에서 수행할 수 있는 작업 디렉터리, 해당 작업을 수행하는 정도, 그리고 네이티브로 작업을 실행할 때와 비교했을 때 성능에 대한 우려사항이 있는지 여부
  3. 해당 작업에 대한 추상화 계층에서 직접 데이터 소스에 액세스하도록 허용합니까? (예: ActiveRecord는 #execute로 원시 SQL 문자열을 실행할 수 있음)
4. 운영 노력
  1. 배포 프로세스: 얼마나 복잡한가? 제안된 도구는 스택에 추가되는 라이브러리 도구입니까, 아니면 GitLab 시스템과 별도로 배포해야 하는 추가 서비스가 필요합니까. 도구가 지원하는 배포 유형 (Kubernetes/VMs, SaaS/Self-Managed, 지원되는 OS, 클라우드 제공업체)는 무엇입니까. 오프라인 설치를 지원합니까.
  2. 작동에 필요한 하드웨어 리소스는 얼마나 되나요?
  3. 안정적이고 성능이 우수한 서비스를 보장하기 위해 복잡한 모니터링 및 운영이 필요합니까?
  4. 유지 관리 과정에 대한 성숙한 프로세스 및 문서화: 업그레이드, 백업 및 복원, 확장
  5. 고가용성 지원. 도구가 HA 클러스터를 구축하고 Self-Managed형용 장애 조치를 수행하는 방법에 대한 문서가 있습니까? 도구가 제로 다운 타임 업그레이드를 지원합니까?
  6. FIPS 및 FedRAMP 준수
  7. 복제 프로세스 및 새 도구를 GitLab Geo에 어떻게 통합시킬지 . 개발자 경험
  8. 솔루션이 채택을 용이하게 하고 학습曲線을 줄이기 위한 명확하고 철저하게 문서화된 API를 가져야 합니다.
6. 성숙도 (유용)
  1. 솔루션이 존재한 기간은 얼마입니까? 자주 사용되고 있나요? 안정된 커뮤니티가 있는가? 라이선스가 분기를 허용하는 경우 포크 도구도 고려할 만한 옵션입니다.
7. 기술 적합성
  1. 솔루션이 GitLab에서 사용하는 프로그래밍 언어 중 하나로 작성되었습니까? 버그 수정 및 새로운 기능 기여가 더욱 용이하게 할 수 있는지 확인할 수 있습니다.
8. 상호 운용성 (필수 사항)
  1. 솔루션이 루비 온 레일로 작성된 주요 GitLab 애플리케이션과 Go로 작성된 컨테이너 레지스트리와 같은 위성 서비스를 모두 지원할 수 있습니까?

오픈 소스 솔루션

1. Cube.dev

평가

  1. 라이선스 Apache 2.0 + MIT ✅
  2. 다른 데이터 리포지터리 지원 가능 ✅
  3. 프로토콜 호환성 OLAP 이론 개념을 사용하여 데이터를 집계합니다. 사용 사례에 따라 사용되지만 일부 사용사례에는 유용하지 않을 수 있습니다. SQL 쿼리와 해당 독자적인 쿼리 형식을 모두 사용합니다.
  4. 운영 노력 도커 또는 k8s를 사용하여 별도의 서비스로 배포합니다. 캐시 및 데이터 구조 리포지터리로 Redis를 사용합니다.
  5. 개발자 경험 좋은 문서
  6. 성숙도 Headless BI 도구 자체는 꽤 새로운 아이디어입니다. 그러나 Cube.js는 이 영역에서 선도하는 오픈 소스 솔루션으로 보입니다. 분석 섹션에서는 제품 분석 스택을 위해 내부적으로 사용됩니다.
  7. 기술 적합성 REST 및 GraphQL API를 사용합니다. 고유한 쿼리 및 데이터 스키마 형식이 있지만 잘 문서화되어 있습니다. YAML 또는 JavaScript에서 데이터 정의를 사용합니다.

코멘트

이 솔루션이 이미 ~"group::product analytics"에서 ClickHouse의 읽기 인터페이스로 사용되는데 대해 @mwoolf와의 대화가 있었습니다.

  1. “ClickHouse 드라이버”가 cube.dev에서는 커뮤니티 기반으로 제공되고 있으며 현재는 유지/보수자가 없으므로 현재 활발한 개발이 이루어지고 있지 않습니다. ClickHouse의 새로운 주요 버전이 몇 가지 파괴적인 변경이 포함될 때까지 적어도 약간 작동할 것으로 예상됩니다.
  2. Cube.dev는 GitLab 기술 스택의 일부인 Type Script 및 JavaScript로 작성되었으며 여기에 해당 기술에 대한 노하우가 있는 엔지니어가 있습니다. 그러나 Cube.dev는 주로 백엔드 개발자가 사용하도록 예상되며, 해당 기술에 대한 경험이 그리 많지 않습니다.
  3. 간단한 SQL에 대한 추상화 레이어는 작동하며, 백엔드에 따라 올바른 쿼리를 생성할 수 있습니다.
  4. 데이터 리포지터리별 기능 (예: ClickHouse의 window funnel)은 다른 엔진으로 변환되지 않으며, 동일한 데이터를 나타내기 위해 추가적인 cube 스키마를 구축해야 합니다.
  5. 지금까지 성능은 로컬 개발 및 AWS VPS에서의 수백만 개의 행을 불러오는 부하 테스트에서 문제가 되지 않았습니다.
  6. 대부분의 엔진에 대해 Postgres SQL과 유사한 인터페이스를 노출하지만, 안타깝게도 ClickHouse의 경우는 그렇지 않으므로 작동 그룹 사용 사례를 위해 JSON API가 더 적절할 수 있습니다.
  7. Cube.dev는 런타임에서 조건부로 사용할 수 있는 스키마를 자동으로 생성할 수 있으며, ClickHouse와 같은 옵션 컴포넌트를 처리하기 위해 사용할 수 있습니다.

그 대화에 대한 녹화도 있습니다. ##### 2. ClickHouse FDW

평가

PostgreSQL에서 ClickHouse 테이블을 질의할 수 있도록 하는 ClickHouse Foreign Data Wrapper입니다. PostgreSQL이 저장되었다고 가정하고 ClickHouse 테이블을 조회할 수 있도록 합니다. Postgres가 스케일링 중지 시 ClickHouse를 쉽게 도입할 수 있는 대안이 될 수 있습니다.

  1. 라이선스 Apache 2.0 ✅
  2. 다른 데이터 리포지터리 지원 PostgreSQL을 통해 ClickHouse를 호출함으로써 가능합니다. ✅
  3. 프로토콜 호환성 처음 눈에 띄는 대로 SELECT, INSERT 문을 지원합니다. 조인에 대해서는 확신할 수 없습니다. 정의에 따라 원시 SQL을 허용합니다.
  4. 운영 노력
    1. PostgreSQL 확장 기능입니다. 두 개의 DB 간 매핑이 필요합니다.
    2. 실행이 ClickHouse로부터의 응답을 기다릴 때 PostgreSQL 성능에 악영향을 줄 수 있습니다.
    3. PostgreSQL 및 ClickHouse 간의 연결을 노출하고 관리해야 합니다.
  5. 개발자 경험 결정되지 않음
  6. 성숙도 몇 년간 사용되어왔으며 ClickHouse 문서에 나와 있지만 널리 사용되는 것 같지는 않습니다.
  7. 기술 적합성 원시 SQL 문

코멘트

3. Clickhouse::Activerecord

평가

  1. 라이선스 MIT 라이선스 ✅
  2. 다른 데이터 리포지터리 지원 네, 응용 프로그램 레이어의 ActiveRecord에 Clickhouse 어댑터를 제공하여 PostgreSQL과 함께 쿼리할 수 있도록 지원됨. ✅
  3. 프로토콜 호환성 조인에 대해 확실하지 않음 - 예제 없음.
  4. 운영 노력 Ruby on Rails 라이브러리 도구 - ORM 인터페이스로 ActiveRecord 어댑터 형태로 구현됨.
  5. 개발자 경험 Rails에 익숙한 개발자들에게 쉽게 작업할 수 있음.
  6. 성숙도 몇 년간 사용 중이지만 레포 활동이 부족함 (이 자체로는 나쁜 것은 아님).
  7. 기술 적합성 Rails 라이브러리이므로 가능함.

의견

4. Metriql

평가

DBT를 사용하여 데이터를 소싱하는 헤들리스 BI 솔루션. 데이터에서 메트릭을 정의하고 집계로 변환하는 측면에서 Cube.dev와 유사함. 저자는 Metriql과 Cube.js와 같은 다른 BI 도구와의 차이점을 FAQ 항목에서 설명함.

  1. 라이선스 Apache 2.0 ✅
  2. 다른 데이터 리포지터리 지원 데이터 소스에서 DBT를 사용하여 CH와 PostgreSQL이 가능함.
  3. 프로토콜 호환성 데이터를 집계하는 OLAP 이론 개념을 사용함. REST API를 통해 즉석 SQL 쿼리를 허용함.
  4. 운영 노력 배포를 위한 별도의 서비스이며 DBT가 필요함.
  5. 개발자 경험 설정 및 사용을 위해 DBT 지식이 있어야 할 것으로 예상됨. 여기에서 문서화된 상당히 간단한 REST API가 있음.
  6. 성숙도 2021년 5월 첫 릴리스되었으나 레포 활동이 부족함 (이 자체로는 나쁜 것은 아님).
  7. 기술 적합성 REST API 또는 JDBC 어댑터를 통해 BI 도구와 연결함. SQL 또는 MQL(특정 SQL flavor/subset)을 사용하여 쿼리를 실행할 수 있음.

의견

5. 거부된 주목할만한 3rd 파티 솔루션

Airflow나 Meltano과 같은 ETL 솔루션 및 Tableau와 Apache Superset과 같은 시각화 도구와 같은 솔루션은 일반적으로 우리 기준을 벗어나기 때문에 잠재적 디렉터리에서 제외되었음.

pg2ch 논리 복제를 사용하여 PostgreSQL에서 ClickHouse로 미러링하는 솔루션입니다. 레포는 보관됨; 명시적으로 프로덕션용으로 표시되지 않음. PostgreSQL DB에서 성능 우려로 인해 사용하지 않음.

Looker BI 도구. 프로프리어터리하고 폐쇄적임.

Hasura 데이터베이스 소스를위한 GraphQL 인터페이스. 아직 ClickHouse 지원이 없음.

dbt Server dbt를위한 HTTP API. MariaDB 비즈니스 소스 라이선스 (BSL) ❌

오픈 질문

  1. 이 제안은 주로 읽기 인터페이스에 중점을 둠. 그러나 보완 작업 결과에 따라 작성 인터페이스에 대한 선택적 가용성에 대한 관련 우려은이 문서에서 제안된 리포지터리 패턴 구현에도 적용될 수 있으므로 작성 상호 작용을 포함하는 것이 고려될 수 있음.
  2. ClickHouse 스키마 변경 및 데이터 이관에 대한 우려는 기존 작업 그룹 기준에서 다루지 않음. 그러나이 문서의 범위를 벗어나 이러한 문제를 해결하는 것은 전체적으로 중요하므로 제안된 리포지터리 패턴 기반 구현에 대한 몇 가지 변경이 필요할 수 있다는 점을 인식시키는 것이 현명함.