@Rocky Starrocks Fe 3, CN 10 개로 insert작업을 수행하는데, 곧바로 조회하면 데이터가 안나오고 몇초 뒤에 조회하면 데이터가 나오는데, 이게 왜그런거야?? 그리고, 모든 fe로 캐시가 반영 된 뒤에 commit되는건지, 하나라도 캐시되면 commit되는건지 실제 완료되는 시점이 언젠지도 알려줘

StarRocks에서

INSERT

수행 후 데이터가 즉시 조회되지 않는 현상은 주로 트랜잭션 가시성(Visibility) 및 *FE 간의 메타데이터 동기화 방식*과 관련이 있습니다. 요청하신 내용에 대해 단계별로 설명해 드립니다. 1. 데이터가 몇 초 뒤에 나오는 이유 StarRocks의 데이터 적재는 크게 `Write(쓰기) -> Commit(커밋) -> Publish(발행)`의 단계를 거칩니다. 데이터가 즉시 보이지 않는 이유는 주로 다음 두 가지 때문입니다. * 트랜잭션 가시성 (Publish 단계): StarRocks는 트랜잭션이 *커밋*된 이후에, 해당 데이터를 읽을 수 있는 상태로 만드는 Publish 과정을 거칩니다. • Primary Key 테이블: StarRocks 3.2 버전부터

enable_sync_publish

설정이 추가되었습니다. 이 값이 `false`(기본값인 경우도 있음)라면, 트랜잭션 성공 응답을 보낸 후 백그라운드에서 데이터를 유효화(Apply)하므로 짧은 시간 동안 데이터가 안 보일 수 있습니다. • Shared Data (공유 저장소) 모드: StarRocks 3.x에서 CN(Compute Node)을 사용하는 공유 저장소 구조라면, 성능 최적화를 위해 여러 트랜잭션을 묶어서 처리하는

lake_enable_batch_publish_version

기능이 동작할 수 있습니다. 이 경우 설정된 배치 조건이 충족될 때까지 데이터 노출이 수 초간 지연될 수 있습니다. * FE Leader와 Follower 간의 동기화 지연: INSERT 명령은 항상 *Leader FE*에서 처리됩니다. 반면, 조회(SELECT) 시 로드밸런서 등을 통해 *Follower FE*로 연결될 수 있습니다. • StarRocks의 메타데이터 동기화(BDBJE)는 비동기 혹은 복제 방식으로 이루어지므로, Leader에서 커밋된 정보가 Follower FE의 메모리(캐시)까지 반영되는 데 아주 짧은(수 ms ~ 수 초) 시간 차이가 발생할 수 있습니다. ────────── 2. 완료 시점 및 FE 캐시 반영 메커니즘 모든 FE에 캐시가 반영되어야 커밋되는지, 혹은 하나라도 반영되면 되는지에 대한 답변입니다. * 커밋 결정 (Quorum 방식): StarRocks FE는 Quorum(과반수) 합의 방식을 사용합니다. 3대의 FE가 있다면, *Leader를 포함하여 최소 2대의 FE*에 메타데이터 로그(Edit Log)가 기록되면 트랜잭션은 성공적으로 커밋된 것으로 간주합니다. • 3대 중 3대 모두에 반영될 때까지 기다리지 않습니다. 2대에 기록되는 즉시 사용자에게 'OK'를 반환합니다. * 실제 완료(조회 가능) 시점: 사용자 입장에서 데이터가 실제로 조회 가능해지는 시점은 *Leader FE가 해당 트랜잭션을

VISIBLE

상태로 변경한 직후*입니다. • 만약 조회 쿼리가 Leader FE로 전달된다면 커밋 즉시(혹은 Publish 직후) 데이터를 볼 수 있습니다. • 만약 조회 쿼리가 아직 로그를 전달받지 못한 Follower FE로 전달된다면, 해당 FE가 Leader로부터 최신 Edit Log를 동기화하여 자신의 메타데이터 캐시를 갱신할 때까지 데이터가 보이지 않습니다. 3. 해결 및 확인 방법 현상을 개선하거나 확인하려면 다음 설정을 점검해 보세요. 1. 동기화 발행 설정 (Primary Key 테이블인 경우):

sql
    -- FE 설정 확인
    ADMIN SHOW FRONTEND CONFIG LIKE 'enable_sync_publish';
    -- true로 설정하면 Publish까지 완료된 후 응답을 줍니다. (지연 발생 가능)

2. 세션 변수 조정: 데이터 가시성 대기 시간을 제어하는

tx_visible_wait_timeout

(기본 10초) 변수를 통해, 트랜잭션이 Visible 상태가 될 때까지 쿼리가 기다리도록 제어할 수 있습니다. 3. 조회 FE 확인: 테스트 시 INSERT를 수행한 바로 그 FE(Leader일 가능성이 높음)에서 조회를 수행해도 동일한 지연이 발생하는지 확인해 보세요. 특정 FE에서만 지연된다면 메타데이터 동기화 속도 문제입니다. 요약하자면: 모든 FE에 반영된 후 완료되는 것이 아니라, *과반수(2대)에 기록되면 완료*됩니다. 다만, 조회하는 FE가 최신 정보를 동기화하는 시점에 따라 수 초의 차이가 발생할 수 있습니다. References • administration/management/FE_configuration.md • loading/Flink-connector-starrocks.md • sql-reference/System_variable.md

@Rocky 너가 말한 lake_enable_batch_publish_version에 대해 상세하게 설명해주고 관련 문서를 제공해줘

`lake_enable_batch_publish_version`는 StarRocks *Shared Data(공유 저장소) 모드*에서 데이터 적재 성능을 극대화하기 위해 도입된 기능입니다. 사용자께서 겪으신 *"데이터가 몇 초 뒤에 조회되는 현상"*의 직접적인 원인이 바로 이 배치 처리 메커니즘일 가능성이 높습니다. 1. 기능 상세 설명 이 설정은 여러 개의 트랜잭션(INSERT 등)을 하나로 묶어서 한 번에 Publish(데이터 가시화) 처리를 수행하도록 합니다. * 배경: 공유 저장소 모드에서는 데이터 메타데이터를 업데이트할 때 객체 스토리지(S3 등)나 메타데이터 서비스와의 통신이 발생합니다. 매 트랜잭션마다 이 작업을 수행하면 부하가 크고 속도가 느려질 수 있습니다. * 동작 방식: `true`로 설정되면, 커밋 대기 중인 여러 트랜잭션을 배치(Batch)로 묶어 한 번의 RPC 호출로 처리합니다. * 장점: 대량의 동시 적재 작업이 있을 때 전체적인 처리량(Throughput)이 획기적으로 늘어납니다. * 단점(지연 발생): 배치가 형성될 때까지 혹은 내부 타이머가 동작할 때까지 기다려야 하므로, 개별

INSERT

직후에 조회하면 데이터가 아직 'Publish' 되지 않아 보이지 않을 수 있습니다. 2. 관련 주요 설정 (FE Config) 배치 동작의 세밀한 제어는 다음 파라미터들로 결정됩니다. 설정 항목 | 기본값 | 설명

lake_enable_batch_publish_version

|

true

| 배치 발행 기능 사용 여부 (v3.2.0+)

lake_batch_publish_min_version_num

|

1

| 배치를 만들기 위한 최소 트랜잭션 버전 수

lake_batch_publish_max_version_num

|

10

| 한 배치에 포함될 최대 트랜잭션 버전 수

lake_publish_version_max_threads

|

512

| 공유 저장소용 Publish 작업을 수행할 최대 스레드 수 3. 해결 방안 (즉시 조회가 중요한 경우) 만약 시스템의 전체 처리량보다 *데이터의 즉시 가시성(Latency)*이 더 중요하다면 다음과 같이 설정할 수 있습니다. * 배치 기능 끄기: (권장하지 않음, 성능 저하 가능성)

sql
    ADMIN SET FRONTEND CONFIG ("lake_enable_batch_publish_version" = "false");

* 기다리도록 설정 (세션 레벨): 쿼리 실행 시 데이터가 보일 때까지 대기하도록 세션 변수를 조정합니다.

sql
    SET wait_txn_visible_timeout = 10; -- 최대 10초 대기

4. 관련 문서 및 참조 이 기능은 StarRocks 3.2 버전부터 도입되었으며, 공식 문서의 FE 설정 페이지에서 상세 내용을 확인할 수 있습니다. * 공식 문서: StarRocks FE Configuration - Shared-data * 관련 블로그: StarRocks 공식 기술 블로그의 "Shared-data Batch Ingestion Optimization" 섹션에서 성능 벤치마크와 이 설정의 차이를 설명하고 있습니다. 요약하자면: 현재 겪고 계신 현상은 고성능 적재를 위한 *의도된 최적화 결과*입니다. 성능과 가시성 사이의 트레이드오프를 고려하여 위 설정을 조정해 보시길 권장합니다. References • administration/management/FE_configuration.md • knowledge/usage/load/shared_data_batch_ingestion.md • sql-reference/System_variable.md

@Rocky 근데 꼭 10개가 쌓여야 publish하는건 아니지않아??

네, 맞습니다. 무조건 10개가 쌓여야만 발행(Publish)되는 것은 아닙니다. `lake_batch_publish_max_version_num`은 어디까지나 *"한 번에 묶을 수 있는 최대치"*를 의미하며, 실제로는 다음과 같은 메커니즘에 의해 데이터가 노출됩니다. 1. 1개만 있어도 발행됩니다 (최소 조건) 기본 설정에서

lake_batch_publish_min_version_num

값은 *1*입니다. * 즉, 대기 중인 트랜잭션이 하나만 있더라도 시스템은 이를 즉시(혹은 다음 주기에) Publish 프로세스로 넘깁니다. * 10개가 쌓일 때까지 무한정 기다리는 구조가 아닙니다. 2. 왜 그런데 수 초가 걸릴까요? 1개여도 발행이 가능한데 왜 지연이 발생하는지는 다음 요인들 때문일 가능성이 큽니다. * Publish Daemon의 주기성: StarRocks 내부에서는 `PublishVersionDaemon`이라는 백그라운드 프로세스가 주기적으로 돌면서 커밋된 트랜잭션들을 확인하고 유효화합니다. 이 주기와 시스템 부하에 따라 아주 짧은 찰나의 지연이 발생할 수 있습니다. * 공유 저장소(S3 등)의 통신 오버헤드: Shared-data 모드에서는 데이터 메타데이터를 저장소에 기록하고 확정하는 과정이 필요합니다. 로컬 디스크를 쓰는 방식보다 네트워크/스토리지 응답 속도에 영향을 더 받습니다. * 복수의 CN 노드 처리: 10개의 CN 노드에 분산되어 적재된 데이터 조각들을 모두 확인하고 "이제 이 버전은 안전하다"라고 선언하는 과정에서 노드 간 통신 시간이 소요됩니다. * FE 동기화 (가장 유력): 앞서 말씀드린 대로, 3대의 FE 중 Leader가 "완료"라고 판단했더라도, 사용자가 접속한 Follower FE가 그 소식을 전달받는 데 약간의 시차가 발생할 수 있습니다. 3. "실제 완료 시점"에 대한 명확한 답변 질문하신 "언제 실제 완료되는가"에 대한 정확한 기준은 다음과 같습니다. 1. 커밋 시점: Leader FE를 포함하여 *과반수(Quorum)의 FE*가 해당 트랜잭션 로그를 기록했을 때. (이때 사용자에게는 INSERT 성공 응답이 나갑니다.) 2. 조회 가능 시점 (Visible): `PublishVersionDaemon`이 해당 트랜잭션을 처리하여 상태를 `VISIBLE`로 변경하고, 사용자가 쿼리를 보낸 FE가 이 상태 정보를 알고 있을 때. 요약 * 10개가 안 쌓여도 발행됩니다. (최소 1개부터 가능) * 지연이 발생하는 이유는 *백그라운드 처리 주기*와 메타데이터 동기화 시간 때문입니다. * 즉시 조회가 반드시 필요하다면: * INSERT를 수행한 바로 그 FE(Leader)에서 조회를 시도해 보세요. * 또는 세션 설정에서

SET wait_txn_visible_timeout = 5;

처럼 설정하여, 데이터가 보일 때까지 쿼리가 잠시 기다리게 할 수 있습니다. References • administration/management/FE_configuration.md • sql-reference/System_variable.md References • administration/management/FE_configuration.md

실제로 보면 스레드가 512개인데, 몇초에 한번 수행해?

`PublishVersionDaemon`의 작동 주기와 가시성 지연이 발생하는 구체적인 이유는 다음과 같습니다. 1. 수행 주기 (Interval) StarRocks FE 내부에서 트랜잭션을 실제 데이터로 유효화(Publish)하는 데몬은 매우 빈번하게 작동합니다. *

publish_version_interval_ms

: 기본값은 *10ms(0.01초)*입니다. * 즉, 이론적으로는 거의 실시간(연속적)으로 커밋된 트랜잭션이 있는지 확인하고 발행 작업을 시도합니다. * 스레드가 512개(

lake_publish_version_max_threads

)라는 것은 이 작업을 동시에 병렬로 처리할 수 있는 능력이 매우 크다는 것을 의미합니다. 2. 그런데 왜 "수 초"가 걸릴까요? 수행 주기가 10ms임에도 불구하고 사용자가 느끼기에 수 초가 걸리는 이유는 *'데몬이 도는 주기'*가 아니라 '개별 작업의 완료 시간 및 동기화 시간' 때문입니다. 1. 공유 저장소(S3/객체 스토리지) 응답 속도: Shared Data 모드에서는 데이터의 메타데이터를 S3와 같은 원격 저장소에 기록하고 확정해야 합니다. 로컬 디스크 작업보다 네트워크 IO 오버헤드가 크기 때문에, 10ms마다 데몬이 작업을 시작하더라도 실제 완료까지는 수백 ms에서 1~2초가 소요될 수 있습니다. 2. CN 노드와의 통신: FE가 10개의 CN 노드에 "이 데이터를 이제 읽을 수 있게 준비하라"고 명령을 보내고 응답을 받는 과정(RPC)이 필요합니다. 노드 수가 많을수록 모든 노드의 상태를 확인하는 데 시간이 소요됩니다. 3. FE 간 메타데이터 동기화 (BDBJE): 이것이 가장 흔한 원인입니다. Leader FE에서 Publish가 완료되어도, 다른 2대의 Follower FE가 이 사실을 인계받는 데는 내부적인 복제 주기가 있습니다. 로드밸런서를 통해 Follower FE로 쿼리를 보냈다면, Leader로부터 최신 정보를 복제받을 때까지(수 초 이내) 데이터가 안 보일 수 있습니다. 4. Batch Publish의 대기 시간: `lake_enable_batch_publish_version`이 켜져 있으면, 처리 효율을 위해 아주 잠깐 동안(보통 1초 미만) 트랜잭션들을 모으는 과정에서 미세한 지연이 추가될 수 있습니다. 3. 실제 완료 시점 상세 * Leader FE 기준: `PublishVersionDaemon`이 작업을 마친 직후 즉시 조회가 가능합니다. * Follower FE 기준: Leader에서 생성된 *Edit Log*가 Follower FE로 복제되고, Follower가 이를 자신의 메모리에 반영(Replay)한 시점부터 조회가 가능합니다. 권장 확인 사항 만약 1~2초 수준이 아니라 그 이상의 지연이 발생한다면 다음 설정을 확인해 보세요: *

ADMIN SHOW FRONTEND CONFIG LIKE 'publish_version_interval_ms';

: 이 값이 혹시 너무 크게 설정되어 있는지 확인 (기본 10). *

wait_txn_visible_timeout

: SELECT 쿼리 전에 `SET wait_txn_visible_timeout = 5;`를 설정해 보세요. 이렇게 하면 쿼리가 "데이터가 나올 때까지 최대 5초간 대기"하므로 지연 현상을 사용자 레벨에서 해결할 수 있습니다. 결론적으로, 시스템은 0.01초마다 계속 일하고 있지만, 저장소 통신과 FE 간의 소식 전달 과정에서 발생하는 물리적인 시간이 수 초의 지연으로 나타나는 것입니다. References • administration/management/FE_configuration.md • sql-reference/System_variable.md • administration/management/BE_configuration.md References • administration/management/FE_configuration.md • knowledge/usage/load/shared_data_batch_ingestion.md