Citus 11.0 베타 버전 테스트 드라이브

https://www.citusdata.com/blog/2022/03/26/test-drive-citus-11-beta-for-postgres/

Citus 11.0 베타 버전의 가장 큰 변화는 스키마와 Citus 메타데이터가 이제 전체 데이터베이스 클러스터에서 자동으로 동기화된다는 점입니다. 이는 Citus 클러스터의 어떤 노드에서든 분산 테이블을 쿼리할 수 있음을 의미합니다!

Citus를 사용하는 가장 간단한 방법은 코디네이터 노드에 연결하여 스키마 변경 및 분산 쿼리에 사용하는 것이지만, 매우 높은 요구 사항을 가진 애플리케이션의 경우, 다른 연결 문자열을 사용하고 일부 제한 사항을 고려하여 애플리케이션(일부)의 워커 노드 간에 분산 쿼리를 로드 밸런싱할 수 있는 옵션을 선택할 수 있습니다.

또한 11.0 베타 버전에서는 개발을 가속화하기 위해 일부 기능을 더 이상 사용하지 않도록 설정했습니다. 하지만 대부분의 사용자에게는 영향을 미치지 않기를 바랍니다.

이 11.0 베타 버전 블로그 게시물에서는 다음 내용을 알아볼 수 있습니다:

Citus 11.0 베타 버전의 새로운 자동 메타데이터 동기화 기능
Citus 11.0 베타 버전 클러스터를 구성하는 방법
워커 노드 간에 쿼리를 로드 밸런싱하는 방법
11.0 베타 버전으로 업그레이드하는 방법
개선된 클러스터 활동 뷰
트랜잭션 블록에서의 메타데이터 동기화
더 이상 사용하지 않는 기능

새로운 Citus 11.0 베타 버전을 시험해 보고 애플리케이션이 어떻게 사용할 수 있는지 확인하거나 새로운 기능을 시도해 볼 수 있습니다. 설치 지침에서 이러한 소프트웨어 패키지를 찾을 수 있습니다.

https://docs.citusdata.com/en/v11.0-beta/installation/multi_node.html

우리는 방금 11.0 베타 버전의 새로운 릴리스 노트를 출시했습니다. 오픈소스 GitHub 저장소를 자세히 살펴보고 이 버전에서 해결한 문제를 확인하려면 이것이 유용할 것입니다. 도움이 된다면 Slack에서 알려주세요! 우리는 출시 예정인 Citus 버전에 대해 이러한 릴리스 노트를 게시할 계획입니다. Citus 웹사이트 상단 탐색에서 "UPDATES" 링크를 통해 이러한 릴리스 노트를 찾을 수 있습니다.

자동 메타데이터 동기화를 통해 모든 노드에서 쿼리 가능

Citus는 PostgreSQL 데이터베이스를 확장하는 최고의 방법일 수 있습니다. 테이블을 분산할 때 Citus는 큰 PostgreSQL 서버 클러스터 전체에서 복잡한 쿼리를 라우팅하고 병렬화할 수 있습니다. 초기 설정 외에는 분산이 애플리케이션에 투명합니다: 애플리케이션은 여전히 단일 PostgreSQL 노드("코디네이터"라고 함)에 연결되며, 코디네이터는 애플리케이션이 보낸 PostgreSQL 쿼리를 백그라운드에서 분산합니다.

그림 1: Citus 10.2 이전 버전의 Citus 클러스터에서 users와 projects는 분산 테이블이며, 해당 메타데이터는 코디네이터에만 있습니다.

단일 코디네이터 아키텍처에는 많은 이점이 있으며 성능이 매우 우수하지만, 일부 고성능 워크로드의 경우 코디네이터가 병목 지점이 될 수 있습니다. 실제로 Citus 코디네이터가 상대적으로 적은 작업을 수행하기 때문에 애플리케이션 개발자가 코디네이터의 병목 현상에 직면하는 경우는 거의 없습니다. 하지만 확장성 측면에서 미리 대비하고 싶어하는 애플리케이션 개발자가 있으며, 일부 매우 높은 요구 사항을 가진 기업 애플리케이션이 있습니다.

https://www.citusdata.com/blog/2022/03/12/how-to-benchmark-performance-of-citus-and-postgres-with-hammerdb/

오랫동안 Citus는 분산 테이블 스키마와 메타데이터를 동기화하여 워커 노드를 통해 분산 쿼리를 실행할 수 있었습니다. 과거에는 때로 이 기능을 "MX"라고 불렀습니다. 하지만 MX 기능은 시퀀스(sequences), 함수(functions), 스키마(schemas) 및 기타 데이터베이스 객체 사용에 다양한 제한 사항이 있었습니다—즉, 모든 테이블이 메타데이터 동기화를 지원하지는 않았습니다.

Citus 11.0 베타 버전은 새로운 작동 모드로 변경됩니다: 이제 모든 Citus 데이터베이스 클러스터는 항상 메타데이터 동기화를 사용합니다. 이는 Citus 11.0 베타 버전과 모든 향후 버전을 사용하면 항상 어떤 노드에서든 분산 PostgreSQL 쿼리를 실행할 수 있음을 의미합니다.

그림 2: Citus 11.0 베타 클러스터에서 users와 items는 분산 테이블이며, 새로운 자동 메타데이터 동기화 기능을 사용하여 해당 메타데이터가 모든 노드로 동기화됩니다.

Citus 11.0 베타 버전을 시작할 때 새로운 메타데이터 동기화 기능을 활성화하기 위해 아무 작업도 수행할 필요가 없습니다. 각 분산 테이블, 데이터베이스 객체 및 스키마 변경 사항은 모든 Citus 워커 노드로 자동 전파됩니다. 스키마 변경 및 노드 관리는 여전히 Citus 코디네이터에 전송해야 하며, 애플리케이션의 연결 문자열을 변경하여 분산 PostgreSQL 쿼리를 코디네이터 또는 다른 노드 중 하나로 보낼 수 있습니다.

Citus 11.0 베타 클러스터 구성 방법

PostgreSQL 데이터베이스에서 초당 많은 쿼리를 실행해야 하는 경우 상대적으로 많은 수의 연결을 사용해야 할 수 있습니다. 최종적으로 총 처리량은 [연결 수]/[평균 응답 시간]이며, 각 연결에 대해 한 번에 하나의 쿼리만 수행할 수 있기 때문입니다.

애플리케이션이 Citus 노드 중 하나에 연결을 열 때 해당 연결은 분산 테이블의 샤드를 쿼리하기 위해 다른 노드와 내부 연결을 설정해야 하는 PostgreSQL 프로세스를 생성합니다. 이러한 내부 연결은 응답 시간을 최소화하기 위해 캐시됩니다. 이는 클라이언트의 각 연결이 결국 다른 노드와 추가 내부 연결을 생성함을 의미하므로 각 노드는 결국 클라이언트가 전체 데이터베이스 클러스터에 대한 연결 수만큼 내부 연결을 얻게 됩니다. 다행히 PostgreSQL 14에서 연결 확장성에 대한 큰 개선을 했으며, 이를 통해 Postgres(및 Citus)가 높은 연결 수에서도 좋은 성능을 유지할 수 있습니다.

https://www.citusdata.com/blog/2020/10/25/improving-postgres-connection-scalability-snapshots/

애플리케이션에서 워커 노드에 연결하여 분산 쿼리를 실행하도록 결정하는 경우 클라이언트 연결이 기술적으로 내부 연결과 경쟁합니다. 클라이언트 연결을 처리하는 각 PostgreSQL 프로세스가 모든 다른 노드와 내부 연결을 설정할 수 있도록 하려면 citus.max_client_connections 설정을 추가했습니다. 이 설정은 외부 클라이언트 연결 수를 제한하면서 Citus 노드 간의 내부 연결은 계속 허용합니다. 일반적인 설치 지침 외에도 많은 클라이언트 연결을 처리할 수 있도록 각 Citus 노드(코디네이터 및 모든 워커)의 postgresql.conf에 다음 설정을 추가하는 것을 권장합니다:

https://docs.citusdata.com/en/v11.0-beta/installation/multi_node.html

-- 노드가 처리할 수 있는 클라이언트 + 내부 연결의 최대 수
-- 모든 노드의 총 클라이언트 연결 수는 이 수를 초과해서는 안 됩니다
max_connections = 6000

-- 개별 노드가 처리할 수 있는 클라이언트 연결 수
-- 노드 수(코디네이터 포함)로 나눈 max_connections 이하여야 합니다
citus.max_client_connections = 500

이러한 설정을 사용하면 각 노드는 애플리케이션으로부터 최대 500개의 연결을 수락할 수 있으므로 10개의 워커 노드와 1개의 코디네이터가 있는 경우 애플리케이션은 총 5500개의 연결을 설정할 수 있습니다. pgbouncer와 같은 연결 풀을 사용하여 각 노드에서 이 숫자를 더 늘릴 수 있습니다.

https://www.pgbouncer.org/

또한 워커 노드가 코디네이터에도 연결할 수 있도록 메타데이터에 Citus 코디네이터를 추가하는 것이 좋습니다. 코디네이터가 메타데이터에 있을 때만 일부 Citus 기능을 사용할 수 있습니다. 향후 필요한 코디네이터를 추가할 수도 있습니다.

-- 모든 노드에서:
CREATE EXTENSION citus;
-- 코디네이터에서만: 코디네이터를 메타데이터에 추가
SELECT citus_set_coordinator_host('<코디네이터 자체 호스트 이름>', 5432);
-- 코디네이터에서만: 워커 노드를 메타데이터에 추가
SELECT citus_add_node('<워커 1 호스트 이름>', 5432);
SELECT citus_add_node('<워커 2 호스트 이름>', 5432);
-- 코디네이터에서만:
CREATE TABLE products (id integer, name text);
SELECT create_distributed_table('products', 'id');
-- 어떤 노드에서든:
INSERT INTO products VALUES (1, 'laptop');

Citus 11.0 베타에서 워커 노드 간 로드 밸런싱 쿼리

Citus 11.0 베타 클러스터가 실행되면 2가지 선택지가 있습니다:

애플리케이션을 코디네이터에 연결하거나,
JDBC 또는 Npgsql과 같은 로드 밸런싱을 지원하는 클라이언트 및 사용자 정의 연결 문자열을 사용하여 PostgreSQL 쿼리를 워커 노드 간에 로드 밸런싱할 수 있습니다. 기존 애플리케이션에서도 로드 밸런싱을 수행할 수 있어야 합니다.
https://jdbc.postgresql.org/
https://www.npgsql.org/

2개의 워커 간 로드 밸런싱을 위한 예제 JDBC 연결 문자열:

https://jdbc.postgresql.org/documentation/head/connect.html

jdbc:postgresql://user@worker1.host:5432,worker2.host:5432/postgres?loadBalanceHosts=true

2개의 워커 간 로드 밸런싱을 위한 예제 Npgsql 연결 문자열:

https://www.npgsql.org/doc/connection-string-parameters.html

Host=worker1.host,worker2.host;Database=postgres;Username=user;Load Balance Hosts=true

다른 방법은 모든 워커 노드 IP를 포함하는 DNS 레코드를 설정하는 것입니다. DNS를 사용하는 한 가지 단점은 로컬 DNS 캐시로 인해 동시에 열리는 연결이 동일한 IP를 사용하는 경우가 많다는 것입니다. 또 다른 선택지는 HAProxy와 같은 전용 로드 밸런서를 설정하는 것입니다.

https://severalnines.com/resources/database-management-tutorials/postgresql-load-balancing-haproxy

11.0 베타에서 Citus 워커 노드를 통해 PostgreSQL 쿼리를 실행할 때 몇 가지 제한 사항에 유의해야 합니다:

애플리케이션을 구성하여 스키마 변경은 코디네이터를 통해 실행하고 쿼리는 어떤 노드를 통해 실행할 수 있도록 해야 합니다.
워커 노드 중 하나에서 테이블을 생성하면 다른 워커 노드에 연결한 경우 해당 테이블이 표시되지 않습니다.
citus.use_citus_managed_tables 설정을 활성화하거나 참조 테이블에 대한 외래 키를 생성하면 코디네이터의 로컬 테이블은 워커 노드에만 나타납니다.
https://www.citusdata.com/blog/2021/06/18/foreign-keys-between-local-ref-tables/
bigint를 생성하는 시퀀스는 연결된 노드의 ID를 앞 16비트에 포함하므로 시퀀스 번호는 여전히 고유하지만 단조롭지는 않습니다.
워커 노드에서 삽입을 시도할 때 int/smallint를 생성하는 시퀀스는 오류를 발생시킵니다.

우리는 향후 Citus 버전에서 위의 제한 사항을 해결하기를 바랍니다.

기존 Citus 데이터베이스 클러스터를 Citus 11.0 베타로 업그레이드

기존(비프로덕션) 클러스터를 Citus 11.0 베타로 업그레이드하려면 새 소프트웨어 패키지를 설치한 후 업그레이드를 완료하는 함수를 호출해야 합니다:

-- 모든 노드에서
ALTER EXTENSION citus UPDATE;

-- 코디네이터에서만
select citus_finalize_upgrade_to_citus11();

업그레이드 기능은 모든 워커 노드에 올바른 스키마와 메타데이터가 있는지 확인합니다. 또한 파티션 테이블 샤드의 이름 지정 문제를 해결하는 데 도움이 됩니다.

메타데이터 동기화를 방해하는 문제(예: 워커 노드에 권한 누락 또는 충돌 객체 존재)가 있는 경우 업그레이드 기능은 오류를 발생시킵니다. 문제를 해결하고 업그레이드를 완료할 때까지 기존의 Citus 데이터베이스 클러스터를 코디네이터를 통해 계속 사용할 수 있지만 일부 새로운 11.0 베타 기능은 사용할 수 없습니다.

개선된 클러스터 통찰력 뷰

Citus 사용자가 자주 요청하는 기능 중 하나는 데이터베이스 클러스터에서 발생하는 일에 대한 더 나은 이해입니다. 일부 쿼리가 워커 노드를 통해 들어오면 이것이 더 중요해집니다.

citus_dist_stat_activity 뷰를 개선했으며, 이를 통해 모든 노드의 모든 클라이언트 세션에서 pg_stat_activity 정보를 표시하고 global_pid(또는 gpid)를 표시합니다. gpid는 클라이언트 세션과 해당 세션과 연결된 모든 내부 연결을 고유하게 식별합니다. gpid는 쿼리를 시작한 노드의 노드 ID, 즉 클라이언트 연결 노드로 시작합니다.

SELECT nodeid, global_pid, query FROM citus_dist_stat_activity where application_name = 'psql';
┌────────┬─────────────┬────────┬────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ nodeid │ global_pid  │ state  │                                                 query                                                  │
├────────┼─────────────┼────────┼────────────────────────────────────────────────────────────────────────────────────────────────────────┤
│      1 │ 10000001303 │ active │ SELECT nodeid, global_pid, state, query FROM citus_dist_stat_activity where application_name = 'psql'; │
│      2 │ 20000001346 │ active │ select count(*), pg_sleep(300) from test;                                                              │
└────────┴─────────────┴────────┴────────────────────────────────────────────────────────────────────────────────────────────────────────┘

특정 쿼리를 취소하려면 global_pid를 pg_cancel_backend에 전달하기만 하면 됩니다. 이는 어떤 노드에서든 작동합니다.

SELECT pg_cancel_backend(20000001346);

새로운 citus_stat_activity 뷰를 사용하면 클러스터에서 발생하는 모든 것(분산 쿼리 및 내부 쿼리 모두)을 볼 수도 있습니다:

SELECT nodeid, global_pid, state, query, is_worker_query FROM citus_stat_activity WHERE global_pid = 20000001500;
┌────────┬─────────────┬────────┬──────────────────────────────────────────────────────────────────────────────────────────────────┬─────────────────┐
│ nodeid │ global_pid  │ state  │                                              query                                               │ is_worker_query │
├────────┼─────────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┼─────────────────┤
│      2 │ 20000001500 │ active │ select count(pg_sleep(300)) from test;                                                           │ f               │
│      2 │ 20000001500 │ active │ SELECT count(pg_sleep('300'::double precision)) AS count FROM public.test_102153 test WHERE true │ t               │
│      2 │ 20000001500 │ active │ SELECT count(pg_sleep('300'::double precision)) AS count FROM public.test_102155 test WHERE true │ t               │
│      3 │ 20000001500 │ active │ SELECT count(pg_sleep('300'::double precision)) AS count FROM public.test_102156 test WHERE true │ t               │
│      3 │ 20000001500 │ active │ SELECT count(pg_sleep('300'::double precision)) AS count FROM public.test_102154 test WHERE true │ t               │
└────────┴─────────────┴────────┴──────────────────────────────────────────────────────────────────────────────────────────────────┴─────────────────┘

특정 노드에서 pg_stat_activity를 사용하는 경우 이제 application_name에서 워커 쿼리가 속한 gpid를 찾을 수도 있습니다:

select pid, application_name, state, query from pg_stat_activity where query like '%count%' and application_name <> 'psql';
┌──────┬─────────────────────────────────┬────────┬──────────────────────────────────────────────────────────────────────────────────────────────────┐
│ pid  │        application_name         │ state  │                                              query                                               │
├──────┼─────────────────────────────────┼────────┼──────────────────────────────────────────────────────────────────────────────────────────────────┤
│ 1548 │ citus_internal gpid=10000001547 │ active │ SELECT count(pg_sleep('300'::double precision)) AS count FROM public.test_102153 test WHERE true │
│ 1550 │ citus_internal gpid=10000001547 │ active │ SELECT count(pg_sleep('300'::double precision)) AS count FROM public.test_102155 test WHERE true │
└──────┴─────────────────────────────────┴────────┴──────────────────────────────────────────────────────────────────────────────────────────────────┘

각 노드가 Citus 클러스터의 다른 모든 노드에 연결할 수 있어야 하므로 모든 가능한 경로의 연결성을 확인하는 새로운 상태 확인 기능도 도입했습니다. 결과 열은 연결 시도가 성공했는지 여부를 나타냅니다.

select * from citus_check_cluster_node_health();
┌───────────────┬───────────────┬─────────────┬─────────────┬────────┐
│ from_nodename │ from_nodeport │ to_nodename │ to_nodeport │ result │
├───────────────┼───────────────┼─────────────┼─────────────┼────────┤
│ localhost     │          1400 │ localhost   │        1400 │ t      │
│ localhost     │          1400 │ localhost   │        1401 │ t      │
│ localhost     │          1400 │ localhost   │        1402 │ t      │
│ localhost     │          1401 │ localhost   │        1400 │ t      │
│ localhost     │          1401 │ localhost   │        1401 │ t      │
│ localhost     │          1401 │ localhost   │        1402 │ t      │
│ localhost     │          1402 │ localhost   │        1400 │ t      │
│ localhost     │          1402 │ localhost   │        1401 │ t      │
│ localhost     │          1402 │ localhost   │        1402 │ t      │
└───────────────┴───────────────┴─────────────┴─────────────┴────────┘
(9 rows)

이러한 기능을 사용하면 코디네이터를 통해 모든 쿼리를 실행하더라도 클러스터에서 발생하는 일에 대한 더 나은 이해를 얻을 수 있어야 합니다.

트랜잭션 블록에서 엄격하고 즉각적인 메타데이터 동기화

분산 데이터베이스에서는 일관성, 내결함성, 병렬성 및 기타 분산 시스템 측면에서 균형을 맞춰야 하는 경우가 많습니다. Citus는 PostgreSQL의 대화형 다문장 트랜잭션 블록을 지원해야 하며, 이는 분산 환경에서 특히 어렵습니다.

예를 들어, Citus는 일반적으로 비싼 작업—예: 분석 쿼리 및 create_distributed_table()—을 샤드 전체에 병렬화합니다. 데이터베이스 객체를 생성할 때 Citus는 각 워커의 단일 연결을 통해 워커 노드로 전파합니다. 단일 다문장 트랜잭션에서 이 두 작업을 결합하면 병렬 연결이 단일 연결을 통해 생성되었지만 아직 커밋되지 않은 객체를 볼 수 없게 될 수 있습니다.

유형 생성, 테이블 생성, 데이터 로드 및 테이블 분산을 포함하는 트랜잭션 블록을 고려해 보세요:

BEGIN;
-- 단일 연결을 통한 유형 생성:
CREATE TYPE coordinates AS (x int, y int);
CREATE TABLE positions (object_id text primary key, position coordinates);
-- 따라서 데이터 로딩은 단일 연결을 통해 이루어집니다:
SELECT create_distributed_table('positions', 'object_id');
\COPY positions FROM 'positions.csv'
…

Citus 11.0 베타 이전에는 Citus가 워커 노드에서 유형 생성을 지연시키고 create_distributed_table을 실행할 때 별도로 커밋했습니다. 이렇게 하면 create_distributed_table의 데이터 복제가 병렬로 발생할 수 있습니다. 하지만 이로 인해 해당 유형이 Citus 워커 노드에 항상 나타나지 않거나 트랜잭션이 롤백되면 워커 노드에만 나타날 수 있습니다. 이러한 불일치를 숨길 수는 있었지만 결국 문제를 일으킬 수 있습니다.

Citus 11.0 베타에서 기본 동작은 코디네이터와 워커 노드 간의 스키마 일관성을 우선시하도록 변경되었습니다. 이는 다음 코드 블록의 ERROR 강조 표시와 같이 객체 전파가 동일 트랜잭션의 병렬 명령 후에 발생하면 해당 트랜잭션이 더 이상 완료될 수 없다는 단점이 있습니다:

BEGIN;
CREATE TABLE products (id integer, name text);
-- 병렬 데이터 로딩:
SELECT create_distributed_table('products', 'id');
\COPY products FROM 'products.csv'
CREATE TYPE coordinates AS (x int, y int);
ERROR:  분산 테이블에서 병렬 작업이 있었기 때문에 유형 명령을 실행할 수 없습니다

이 문제가 발생하면 2가지 간단한 해결 방법이 있습니다:

set citus.create_object_propagation to deferred;를 사용하여 이전 객체 전파 동작으로 되돌립니다. 이 경우 다른 노드에 어떤 데이터베이스 객체가 있는지에 대한 일부 불일치가 있을 수 있습니다.
set citus.multi_shard_modify_mode to sequential을 사용하여 각 노드의 병렬성을 비활성화합니다. 동일 트랜잭션의 데이터 로딩은 더 느려질 수 있습니다.

문장 기반 샤드 복제 변경 사항

2016년에 우리는 고가용성(HA)을 위해 문장 기반 샤드 복제를 더 이상 사용하지 않도록 설정하고 스트리밍 복제를 지원하기로 발표했습니다. Azure Database for PostgreSQL에서 Hyperscale (Citus)의 고가용성을 사용하도록 설정하면 각 노드에는 핫 스탠바이가 있게 됩니다—즉, 해당 노드의 모든 샤드는 스트리밍 복제를 통해 복제됩니다. 고가용성을 사용하지 않더라도 데이터는 내부적으로 관리 디스크에 의해 복제되어 데이터 손실을 방지합니다.

더 이상 사용하지 않도록 설정했음에도 불구하고 문장 기반 복제는 삭제하지 않았습니다... 특정 시나리오에서 읽기 처리량을 확장하는 데 계속 사용할 수 있지만, 더 이상 사용하지 않는 HA 관련 로직은 종종 문제를 일으키고 복제 테이블에 대한 메타데이터 동기화를 구현하는 것을 방해했습니다. 따라서 Citus 11.0 베타의 일부로 다음과 같이 동작을 변경합니다:

Citus 11.0 베타 이전에는 복제 샤드의 쓰기가 하나의 샤드 위치에서 실패하면 Citus가 해당 위치를 무효로 표시했습니다—그 후에는 샤드를 다시 복제해야 합니다. 이 기능은 제대로 작동하지 않았습니다. 일시적인 쓰기 실패가 배치를 무효화하고 비싼(쓰기 차단) 재복제를 유발할 수 있기 때문입니다.

Citus 11.0 베타부터 복제 샤드의 쓰기는 항상 2PC를 사용합니다—즉, 모든 배치가 시작될 때만 성공할 수 있습니다. 또한 복제 테이블의 메타데이터는 동기화되므로 어떤 노드에서든 쿼리할 수 있습니다.

오늘 오픈소스에서 문장 기반 샤드 복제를 사용하는 사용자는 Citus 11.0 베타로 업그레이드할 수 있습니다—하지만 샤드에 대한 쓰기를 계속 수락하려면 노드 중 하나에서 장애가 발생할 때 citus_disable_node 함수를 통해 장애 노드를 비활성화해야 합니다. 노드를 교체하거나 다시 활성화한 후에는 여전히 replicate_table_shards를 사용하여 샤드를 다시 복제할 수 있습니다.

읽기 처리량을 확장하기 위해 문장 기반 복제를 사용하려면:

분산 테이블을 생성하기 전에 citus.shard_replication_factor를 2로 설정하고
citus.task_assignment_policy를 "round-robin"으로 설정하여 복제본 간에 쿼리를 로드 밸런싱합니다.

읽기 처리량을 확장하기 위해 문장 기반 복제를 사용하는 단점은 쓰기가 더 높은 응답 시간을 가지며 업데이트 및 삭제가 복제본을 동기화하기 위해 직렬화됩니다.

더 이상 사용하지 않는 기능: 거의 사용되지 않는 기능과 작별

PostgreSQL과 마찬가지로 Citus는 장기적인 하위 호환성을 유지합니다. 우리는 Citus를 업그레이드할 때 애플리케이션이 계속 작동하도록 최선을 다합니다. 하지만 때로는 특정 기능이 더 이상 Citus의 사용 방식에 맞지 않고 개발을 방해할 때가 있습니다. 우리는 Citus 11.0 베타에서 일부 Citus 기능을 삭제하기로 결정했습니다:

무효 샤드 배치: 위 섹션에서 설명한 바와 같이 쓰기 실패 시 더 이상 샤드가 무효로 표시되지 않습니다. 이 동작은 문장 기반 복제를 사용할 때 일부 결함이 있으며 신뢰성을 낮추기 때문입니다.
추가 분산 테이블 함수: Citus의 초기 분산 방법은 "추가" 분산이었으며 추가 전용 데이터에 최적화되었습니다. 해시 분산 테이블은 더 쉽게 사용할 수 있으며 더 많은 기능을 가지며 파티셔닝을 통해 추가 전용 데이터도 잘 처리할 수 있습니다. Citus 11.0 베타는 추가 분산 테이블을 생성하고 새 데이터를 로드하는 기능을 삭제했습니다. 추가 분산 테이블 사용자가 없다고 생각하지만 혹시 모를 경우: 여전히 11.0 베타로 업그레이드할 수 있지만 이러한 테이블은 읽기 전용이 됩니다. 기본 해시 분산을 사용하는 새 분산 테이블을 생성하고 INSERT .. SELECT 명령을 사용하여 데이터를 이동하는 것이 좋습니다.
https://docs.citusdata.com/en/latest/develop/reference_ddl.html
분산 cstore_fdw 테이블(열 액세스 방식으로 전환해야 함): 10.0 버전부터 Citus에는 내장 열 저장소가 포함되어 있습니다. Citus 10.0 이전에는 더 이상 사용되지 않는 cstore_fdw 확장을 사용하여 Citus를 열 저장소와 함께 사용할 수 있었습니다. 하지만 cstore_fdw는 스트리밍 복제 및 백업과 같은 중요한 PostgreSQL 기능을 지원하지 않으므로 Citus 10 이전에는 Citus 고객이 열 저장소를 거의 사용하지 않았습니다. 많은 회사가 현재 Citus의 내장 열 저장소를 사용하여 시계열 데이터를 저장하고 있으므로 분산 cstore_fdw 테이블을 생성하거나 사용하는 지원을 중단했습니다. 분산 cstore_fdw 테이블을 분산한 경우 11.0 베타로 업그레이드하기 전에 열 액세스 방식으로 변환하는 것이 좋습니다.
https://github.com/citusdata/cstore_fdw
https://www.citusdata.com/blog/2021/10/22/how-to-scale-postgres-for-time-series-data-with-citus/

Citus 11.0 베타로 확장성의 새로운 차원으로 나아가기

Citus는 PostgreSQL 확장으로 완전히 구현된 트랜잭션 및 분석 워크로드의 유일한 분산 데이터베이스이므로 Citus는 PostgreSQL의 강력한 기능을 대규모로 지원하고 PostgreSQL의 안정성, 성능, 다기능성, 확장성 및 방대한 도구 생태계와 확장을 상속받습니다.

https://github.com/citusdata/citus

Citus 오픈소스 11.0 베타의 자동 메타데이터 동기화 기능을 통해 이제 Citus 클러스터에서 어떤 노드에서든 쿼리를 선택하여 Citus의 확장성을 더욱 향상시킬 수 있습니다.

새로운 Citus 11.0 베타를 시험해 볼 관심이 있다면 Citus 문서에서 베타 버전의 설치 지침을 찾을 수 있습니다. Citus를 설치한 후 시작 페이지에는 시작하는 방법에 대한 좋은 내용이 많이 있으며, 튜토리얼과 비디오도 포함되어 있습니다. 마지막으로 Citus 내부 작동 방식에 대해 더 알고 싶다면 SIGMOD 논문을 확인하세요.

더 알아보기

Python/Django를 사용하여 Postgres+Citus와 같은 분산 다중 테넌트 데이터베이스 지원 탐색

태그: citus PostgreSQL 분산 데이터베이스 메타데이터 동기화 로드 밸런싱

6월 17일 16:46에 게시됨

괴물 클럽