InfoGrab DocsInfoGrab Docs

배치로 테이블 반복 처리하기

요약

Rails는 행을 배치 단위로 반복 처리하는 데 사용할 수 있는 in_batches 메서드를 제공합니다. 안타깝게도 이 메서드는 쿼리와 메모리 사용 측면 모두에서 효율적이지 않은 방식으로 구현되어 있습니다. 이를 해결하기 위해 모델에 EachBatch 모듈을 포함한 후 each_batch 클래스 메서드를 사용할 수 있습니다.

Rails는 행을 배치 단위로 반복 처리하는 데 사용할 수 있는 in_batches 메서드를 제공합니다. 예시:

User.in_batches(of: 10) do |relation|
  relation.update_all(updated_at: Time.now)
end

안타깝게도 이 메서드는 쿼리와 메모리 사용 측면 모두에서 효율적이지 않은 방식으로 구현되어 있습니다.

이를 해결하기 위해 모델에 EachBatch 모듈을 포함한 후 each_batch 클래스 메서드를 사용할 수 있습니다. 예시:

class User < ActiveRecord::Base
  include EachBatch
end

User.each_batch(of: 10) do |relation|
  relation.update_all(updated_at: Time.now)
end

이는 다음과 같은 쿼리를 생성합니다:

User Load (0.7ms)  SELECT  "users"."id" FROM "users" WHERE ("users"."id" >= 41654)  ORDER BY "users"."id" ASC LIMIT 1 OFFSET 1000
  (0.7ms)  SELECT COUNT(*) FROM "users" WHERE ("users"."id" >= 41654) AND ("users"."id" < 42687)

이 메서드의 API는 in_batches와 유사하지만, in_batches가 지원하는 모든 인수를 지원하지는 않습니다. in_batches가 꼭 필요한 경우가 아니라면 항상 each_batch를 사용해야 합니다.

고유하지 않은 칼럼에 대한 반복 처리#

고유하지 않은 칼럼(관계 컨텍스트에서)에 each_batch 메서드를 사용하면 안 됩니다. 이는 무한 루프가 발생할 수 있습니다. 또한 고유하지 않은 칼럼에 대해 반복 처리할 때 일관되지 않은 배치 크기가 성능 문제를 일으킵니다. 특정 속성에 대해 최대 배치 크기를 적용하더라도 결과 배치가 해당 크기를 초과하지 않는다고 보장할 수 없습니다. 다음 스니펫은 id가 1에서 10,000 사이인 사용자에 대한 Ci::Build 항목을 선택하려 할 때 데이터베이스가 1 215 178개의 일치하는 행을 반환하는 상황을 보여줍니다.

[ gstg ] production> Ci::Build.where(user_id: (1..10_000)).size
=> 1215178

이는 구축된 관계가 다음 쿼리로 변환되기 때문에 발생합니다:

[ gstg ] production> puts Ci::Build.where(user_id: (1..10_000)).to_sql
SELECT "ci_builds".* FROM "ci_builds" WHERE "ci_builds"."type" = 'Ci::Build' AND "ci_builds"."user_id" BETWEEN 1 AND 10000
=> nil

WHERE "ci_builds"."user_id" BETWEEN ? AND ?와 같이 범위로 고유하지 않은 칼럼을 필터링하는 And 쿼리는 범위 크기가 특정 임계값으로 제한되어 있더라도(이전 예시에서 10,000) 이 임계값이 반환되는 데이터셋 크기로 변환되지 않습니다. 그 이유는 속성의 n개 가능한 값을 취할 때, 해당 값을 포함하는 레코드 수가 n보다 작다고 확신할 수 없기 때문입니다.

distinct_each_batch를 사용한 Loose-index scan#

고유하지 않은 칼럼에 대한 반복이 필요한 경우 distinct_each_batch 헬퍼 메서드를 사용하세요. 이 헬퍼는 loose-index scan 기법(skip-index scan)을 사용하여 데이터베이스 인덱스 내의 중복 값을 건너뜁니다.

예시: Issue 모델에서 고유한 author_id에 대한 반복 처리

Issue.distinct_each_batch(column: :author_id, of: 1000) do |relation|
  users = User.where(id: relation.select(:author_id)).to_a
end

이 기법은 데이터 분포에 관계없이 배치 간 안정적인 성능을 제공합니다. relation 객체는 지정된 column만 사용 가능한 ActiveRecord 스코프를 반환합니다. 다른 칼럼은 로드되지 않습니다.

기반이 되는 데이터베이스 쿼리는 재귀적 CTE를 사용하므로 추가 오버헤드가 발생합니다. 따라서 표준 each_batch 반복보다 작은 배치 크기를 사용하는 것을 권장합니다.

칼럼 정의#

EachBatch는 기본적으로 모델의 기본 키를 반복에 사용합니다. 대부분의 경우 이것으로 충분하지만, 경우에 따라 반복에 다른 칼럼을 사용하고 싶을 수 있습니다.

Project.distinct.each_batch(column: :creator_id, of: 10) do |relation|
  puts User.where(id: relation.select(:creator_id)).map(&:id)
end

위 쿼리는 프로젝트 생성자를 반복하고 중복 없이 출력합니다.

칼럼이 고유하지 않은 경우(고유 인덱스 정의가 없는 경우) 관계에서 distinct 메서드를 호출하는 것이 필요합니다. distinct 없이 고유하지 않은 칼럼을 사용하면 다음 이슈에서 설명한 것처럼 each_batch가 무한 루프에 빠질 수 있습니다.

데이터 마이그레이션에서 EachBatch 사용#

데이터 마이그레이션을 처리할 때 대량의 데이터를 반복하는 데 선호되는 방법은 EachBatch를 사용하는 것입니다.

데이터 마이그레이션의 특수한 경우로는 배치 백그라운드 마이그레이션이 있는데, 실제 데이터 수정은 백그라운드 job에서 실행됩니다. 데이터 범위(슬라이스)를 결정하고 백그라운드 job을 예약하는 마이그레이션 코드에서 each_batch를 사용합니다.

each_batch의 효율적인 사용#

EachBatch는 대용량 테이블을 반복하는 데 도움이 됩니다. EachBatch가 모든 반복 관련 성능 문제를 마법처럼 해결해 주지는 않으며, 일부 시나리오에서는 전혀 도움이 되지 않을 수 있다는 점을 강조해야 합니다. 데이터베이스 관점에서 EachBatch가 잘 작동하려면 올바르게 구성된 데이터베이스 인덱스도 필요합니다.

예시 1: 단순 반복#

users 테이블을 반복하고 User 레코드를 표준 출력에 출력하려는 경우를 생각해 봅시다. users 테이블에는 수백만 개의 레코드가 있으므로, 사용자를 가져오기 위해 하나의 쿼리를 실행하면 아마도 시간 초과가 발생할 것입니다.

이 테이블은 몇 개의 행을 포함한 users 테이블의 단순화된 버전입니다. 예시를 좀 더 현실적으로 만들기 위해 id 칼럼에 몇 가지 작은 간격이 있습니다(일부 레코드가 이미 삭제됨). id 필드에 하나의 인덱스가 존재합니다:

ID sign_in_count created_at
1 1 2020-01-01
2 4 2020-01-01
9 1 2020-01-03
300 5 2020-01-03
301 9 2020-01-03
302 8 2020-01-03
303 2 2020-01-03
350 1 2020-01-03
351 3 2020-01-04
352 0 2020-01-05
353 9 2020-01-11
354 3 2020-01-12

모든 사용자를 메모리에 로드(권장하지 않음):

users = User.all

users.each { |user| puts user.inspect }

each_batch 사용:

# Note: for this example I picked 5 as the batch size, the default is 1_000
User.each_batch(of: 5) do |relation|
  relation.each { |user| puts user.inspect }
end

each_batch 동작 방식#

첫 번째 단계로, 다음 데이터베이스 쿼리를 실행하여 테이블에서 가장 낮은 id(시작 id)를 찾습니다:

SELECT "users"."id" FROM "users" ORDER BY "users"."id" ASC LIMIT 1

[

](/19.1/development/database/img/each_batch_users_table_iteration_1_v13_7.png)

쿼리가 인덱스(INDEX ONLY SCAN)에서만 데이터를 읽는다는 점에 주목하세요. 테이블에는 접근하지 않습니다. 데이터베이스 인덱스는 정렬되어 있으므로 첫 번째 항목을 꺼내는 것은 매우 저렴한 연산입니다.

다음 단계는 배치 크기 설정을 준수하는 다음 id(종료 id)를 찾는 것입니다. 이 예시에서는 배치 크기로 5를 사용했습니다. EachBatch는 OFFSET 절을 사용하여 "이동된" id 값을 얻습니다.

SELECT "users"."id" FROM "users" WHERE "users"."id" >= 1 ORDER BY "users"."id" ASC LIMIT 1 OFFSET 5

[

](/19.1/development/database/img/each_batch_users_table_iteration_2_v13_7.png)

다시 쿼리는 인덱스만 조회합니다. OFFSET 5는 여섯 번째 id 값을 꺼냅니다. 이 쿼리는 테이블 크기나 반복 횟수에 관계없이 인덱스에서 최대 여섯 개의 항목을 읽습니다.

이 시점에서 첫 번째 배치의 id 범위를 알 수 있습니다. 이제 relation 블록에 대한 쿼리를 구성할 차례입니다.

SELECT "users".* FROM "users" WHERE "users"."id" >= 1 AND "users"."id" < 302

[

](/19.1/development/database/img/each_batch_users_table_iteration_3_v13_7.png)

< 기호에 주목하세요. 이전에 인덱스에서 여섯 개의 항목을 읽었고 이 쿼리에서 마지막 값은 "제외"됩니다. 쿼리는 인덱스를 보고 디스크에서 다섯 user 행의 위치를 얻은 후 테이블에서 행을 읽습니다. 반환된 배열은 Ruby에서 처리됩니다.

첫 번째 반복이 완료되었습니다. 다음 반복을 위해 이전 반복의 마지막 id 값이 재사용되어 다음 종료 id 값을 찾습니다.

SELECT "users"."id" FROM "users" WHERE "users"."id" >= 302 ORDER BY "users"."id" ASC LIMIT 1 OFFSET 5

[

](/19.1/development/database/img/each_batch_users_table_iteration_4_v13_7.png)

이제 두 번째 반복을 위한 users 쿼리를 쉽게 구성할 수 있습니다.

SELECT "users".* FROM "users" WHERE "users"."id" >= 302 AND "users"."id" < 353

[

](/19.1/development/database/img/each_batch_users_table_iteration_5_v13_7.png)

예시 2: 필터를 사용한 반복#

이전 예시를 기반으로, 로그인 횟수가 0인 사용자를 출력하고 싶다고 가정합시다. sign_in_count 칼럼에 로그인 횟수를 추적하고 있으므로 다음 코드를 작성합니다:

users = User.where(sign_in_count: 0)

users.each_batch(of: 5) do |relation|
  relation.each { |user| puts user.inspect }
end

each_batch는 시작 id 값에 대해 다음 SQL 쿼리를 생성합니다:

SELECT "users"."id" FROM "users" WHERE "users"."sign_in_count" = 0 ORDER BY "users"."id" ASC LIMIT 1

id 칼럼만 선택하고 id로 정렬하면 데이터베이스가 id(기본 키 인덱스) 칼럼의 인덱스를 사용하도록 강제합니다. 그러나 sign_in_count 칼럼에 대한 추가 조건도 있습니다. 해당 칼럼은 인덱스에 포함되어 있지 않으므로 데이터베이스는 첫 번째 일치하는 행을 찾기 위해 실제 테이블을 조회해야 합니다.

[

](/19.1/development/database/img/each_batch_users_table_filter_v13_7.png)

스캔된 행 수는 테이블의 데이터 분포에 따라 다릅니다.

  • 최선의 경우: 첫 번째 사용자가 한 번도 로그인하지 않은 경우. 데이터베이스는 하나의 행만 읽습니다.

  • 최악의 경우: 모든 사용자가 최소 한 번 이상 로그인한 경우. 데이터베이스는 모든 행을 읽습니다.

이 특정 예시에서 데이터베이스는 첫 번째 id 값을 결정하기 위해(배치 크기 설정에 관계없이) 10개의 행을 읽어야 했습니다. "실제 세계" 애플리케이션에서는 필터링이 문제를 일으키는지 예측하기 어렵습니다. GitLab의 경우 프로덕션 레플리카에서 데이터를 확인하는 것이 좋은 출발점이지만, GitLab.com의 데이터 분포는 GitLab Self-Managed 인스턴스와 다를 수 있다는 점을 유념하세요.

each_batch를 사용한 필터링 개선#

특수 조건 인덱스#
CREATE INDEX index_on_users_never_logged_in ON users (id) WHERE sign_in_count = 0

테이블과 새로 만든 인덱스의 모습은 다음과 같습니다:

[

](/19.1/development/database/img/each_batch_users_table_filtered_index_v13_7.png)

이 인덱스 정의는 id 및 sign_in_count 칼럼의 조건을 커버하므로 each_batch 쿼리를 매우 효율적으로 만듭니다(단순 반복 예시와 유사).

사용자가 한 번도 로그인하지 않은 경우는 드물기 때문에 인덱스 크기가 작을 것으로 예상됩니다. 인덱스 정의에 id만 포함하는 것도 인덱스 크기를 작게 유지하는 데 도움이 됩니다.

칼럼에 대한 인덱스#

나중에 다른 sign_in_count 값으로 필터링하면서 테이블을 반복하고 싶을 수 있습니다. 그런 경우 WHERE 조건이 새 필터(sign_in_count > 10)와 일치하지 않기 때문에 이전에 제안한 조건부 인덱스를 사용할 수 없습니다.

이 문제를 해결하기 위해 두 가지 옵션이 있습니다:

  • 새 쿼리를 커버하기 위한 또 다른 조건부 인덱스를 만듭니다.

  • 인덱스를 더 일반화된 구성으로 교체합니다.

동일한 테이블의 동일한 칼럼에 여러 인덱스가 있으면 데이터 쓰기 시 성능 병목이 발생할 수 있습니다.

다음 인덱스를 고려해 봅시다(권장하지 않음):

CREATE INDEX index_on_users_never_logged_in ON users (id, sign_in_count)

인덱스 정의가 id 칼럼으로 시작하기 때문에 데이터 선택성 관점에서 인덱스가 매우 비효율적입니다.

SELECT "users"."id" FROM "users" WHERE "users"."sign_in_count" = 0 ORDER BY "users"."id" ASC LIMIT 1

위 쿼리를 실행하면 INDEX ONLY SCAN이 됩니다. 그러나 쿼리는 여전히 인덱스에서 알 수 없는 수의 항목을 반복하고 sign_in_count가 0인 첫 번째 항목을 찾아야 합니다.

[

](/19.1/development/database/img/each_batch_users_table_bad_index_v13_7.png)

인덱스 정의에서 칼럼을 교체하면 쿼리를 크게 개선할 수 있습니다(권장).

CREATE INDEX index_on_users_never_logged_in ON users (sign_in_count, id)

[

](/19.1/development/database/img/each_batch_users_table_good_index_v13_7.png)

다음 인덱스 정의는 each_batch에서 잘 작동하지 않습니다(권장하지 않음).

CREATE INDEX index_on_users_never_logged_in ON users (sign_in_count)

each_batch는 id 칼럼을 기반으로 범위 쿼리를 작성하므로 이 인덱스를 효율적으로 사용할 수 없습니다. DB는 테이블에서 행을 읽거나 기본 키 인덱스도 읽는 비트맵 검색을 사용합니다.

"느린" 반복#

느린 반복은 좋은 인덱스 구성을 사용하여 테이블을 반복하고 생성된 관계에 필터링을 적용하는 것을 의미합니다.

User.each_batch(of: 5) do |relation|
  relation.where(sign_in_count: 0).each { |user| puts user inspect }
end

반복은 기본 키 인덱스(id 칼럼)를 사용하므로 구문 시간 초과로부터 안전합니다. 필터(sign_in_count: 0)는 id가 이미 제한된(범위) relation에 적용됩니다. 행 수가 제한됩니다.

느린 반복은 일반적으로 완료하는 데 더 많은 시간이 걸립니다. 반복 횟수가 더 많고 하나의 반복에서 배치 크기보다 적은 레코드를 생성할 수 있습니다. 반복에서 0개의 레코드가 생성될 수도 있습니다. 이것이 최적의 솔루션은 아니지만, 일부 경우(특히 대용량 테이블을 다룰 때) 이것이 유일한 실행 가능한 옵션입니다.

서브쿼리 사용#

each_batch 쿼리에서 서브쿼리를 사용하면 대부분의 경우 잘 작동하지 않습니다. 다음 예시를 고려해 봅시다:

projects = Project.where(creator_id: Issue.where(confidential: true).select(:author_id))

projects.each_batch do |relation|
  # do something
end

반복은 projects 테이블의 id 칼럼을 사용합니다. 배치 처리는 서브쿼리에 영향을 미치지 않습니다. 이는 각 반복마다 서브쿼리가 데이터베이스에서 실행된다는 것을 의미합니다. 이로 인해 쿼리에 일정한 "부하"가 추가되어 종종 구문 시간 초과가 발생합니다. 기밀 이슈의 수를 알 수 없으며, 실행 시간과 접근하는 데이터베이스 행은 issues 테이블의 데이터 분포에 따라 다릅니다.

서브쿼리는 서브쿼리가 소수의 행을 반환할 때만 사용합니다.

서브쿼리 개선#

서브쿼리를 다룰 때는 느린 반복 접근 방식이 효과적일 수 있습니다. creator_id에 대한 필터는 생성된 relation 객체의 일부가 될 수 있습니다.

projects = Project.all

projects.each_batch do |relation|
  relation.where(creator_id: Issue.where(confidential: true).select(:author_id))
end

issues 테이블 자체의 쿼리가 충분히 효율적이지 않은 경우 중첩 루프를 구성할 수 있습니다. 가능하면 피하도록 하세요.

projects = Project.all

projects.each_batch do |relation|
  issues = Issue.where(confidential: true)

  issues.each_batch do |issues_relation|
    relation.where(creator_id: issues_relation.select(:author_id))
  end
end

issues 테이블이 projects보다 훨씬 더 많은 행을 가지고 있다면 issues 테이블을 먼저 배치 처리하는 쿼리를 뒤집는 것이 합리적입니다.

JOIN과 EXISTS 사용#

JOINS를 사용해야 하는 경우:

  • 테이블 간에 1:1 또는 1:N 관계가 있고 조인된 레코드가 (거의) 항상 존재하는 경우. 이는 "확장 테이블" 형태에 잘 작동합니다:

projects - project_settings

  • users - user_details

  • users - user_statuses

  • LEFT JOIN이 이 경우에 잘 작동합니다. 조인된 테이블의 조건은 생성된 관계에 추가되어야 하며 조인된 테이블의 데이터 분포에 의해 반복이 영향을 받지 않습니다.

예시:

User.each_batch do |relation|
  relation
    .joins("LEFT JOIN personal_access_tokens on personal_access_tokens.user_id = users.id")
    .where("personal_access_tokens.name = 'name'")
end

EXISTS 쿼리는 each_batch 쿼리의 내부 relation에만 추가해야 합니다:

User.each_batch do |relation|
  relation.where("EXISTS (SELECT 1 FROM ...")
end

relation 객체에 대한 복잡한 쿼리#

relation 객체에 여러 추가 조건이 있으면 실행 계획이 "불안정"해질 수 있습니다.

예시:

Issue.each_batch do |relation|
  relation
    .joins(:metrics)
    .joins(:merge_requests_closing_issues)
    .where("id IN (SELECT ...)")
    .where(confidential: true)
end

여기서 relation 쿼리가 BATCH_SIZE의 사용자 레코드를 읽고 제공된 쿼리에 따라 결과를 필터링할 것으로 예상합니다. 플래너는 confidential 칼럼의 인덱스를 사용한 비트맵 인덱스 조회가 쿼리를 실행하는 더 좋은 방법이라고 결정할 수 있습니다. 이로 인해 예상치 못하게 많은 수의 행이 읽힐 수 있고 쿼리가 시간 초과될 수 있습니다.

문제: 관계가 최대 BATCH_SIZE의 레코드를 반환한다고 확신하지만, 플래너는 이것을 알지 못합니다.

범위 쿼리가 먼저 실행되도록 강제하는 CTE(Common Table Expression) 트릭:

Issue.each_batch(of: 1000) do |relation|
  cte = Gitlab::SQL::CTE.new(:batched_relation, relation.limit(1000))

  scope = cte
    .apply_to(Issue.all)
    .joins(:metrics)
    .joins(:merge_requests_closing_issues)
    .where("id IN (SELECT ...)")
    .where(confidential: true)

  puts scope.to_a
end

레코드 카운팅#

데이터가 대량인 테이블의 경우 쿼리를 통한 레코드 카운팅이 시간 초과를 일으킬 수 있습니다. EachBatch 모듈은 반복적으로 레코드를 카운팅하는 대안적인 방법을 제공합니다. each_batch를 사용하는 단점은 생성된 관계 객체에서 실행되는 추가 카운트 쿼리입니다.

each_batch_count 메서드는 추가 카운트 쿼리의 필요성을 제거하는 더 효율적인 접근 방식입니다. 이 메서드를 호출하면 반복 프로세스를 필요에 따라 일시 중지하고 재개할 수 있습니다. 이 기능은 Sidekiq 워커 내에서 카운팅 연산을 수행할 때와 같이 5분 후 오류 예산 위반이 발생하는 상황에서 특히 유용합니다.

설명을 위해, EachBatch를 사용한 레코드 카운팅은 다음과 같이 추가 카운트 쿼리를 호출합니다:

count = 0

Issue.each_batch do |relation|
  count += relation.count
end

puts count

반면에 each_batch_count 메서드는 추가 카운트 쿼리를 호출하지 않고 더 효율적으로(카운팅이 반복 쿼리의 일부) 카운팅 프로세스를 수행할 수 있습니다:

count, _last_value = Issue.each_batch_count # last value can be ignored here

또한 each_batch_count 메서드는 카운팅 프로세스를 어느 시점에서든 일시 중지하고 재개할 수 있습니다. 이 기능은 다음 코드 스니펫에서 보여줍니다:

stop_at = Time.current + 3.minutes

count, last_value = Issue.each_batch_count do
  stop_at.past? # condition for stopping the counting
end

# Continue the counting later
stop_at = Time.current + 3.minutes

count, last_value = Issue.each_batch_count(last_count: count, last_value: last_value) do
  stop_at.past?
end

EachBatch와 BatchCount 비교#

Service Ping을 위한 새 카운터를 추가할 때 레코드를 카운팅하는 선호되는 방법은 Gitlab::Database::BatchCount 클래스를 사용하는 것입니다. BatchCount에 구현된 반복 로직은 EachBatch와 유사한 성능 특성을 가집니다. BatchCount 개선을 위한 대부분의 팁과 제안은 BatchCount에도 적용됩니다.

키셋 페이지네이션으로 반복#

EachBatch가 작동하지 않는 몇 가지 특수한 경우가 있습니다. EachBatch는 하나의 고유한 칼럼(일반적으로 기본 키)이 필요하기 때문에 타임스탬프 칼럼이나 복합 기본 키가 있는 테이블에서는 반복이 불가능합니다.

EachBatch가 작동하지 않는 경우 키셋 페이지네이션을 사용하여 테이블이나 행 범위를 반복할 수 있습니다. 확장성과 성능 특성은 EachBatch와 매우 유사합니다.

예시:

  • 정렬에 사용되는 칼럼에 고유한 값이 없는 경우 타이-브레이커와 함께 특정 순서(타임스탬프 칼럼)로 테이블 반복.

  • 복합 기본 키가 있는 테이블 반복.

프로젝트의 이슈를 생성 날짜별로 반복#

키셋 페이지네이션을 사용하여 특정 순서(예: created_at DESC)로 임의의 데이터베이스 칼럼을 반복할 수 있습니다. created_at에 같은 값을 가진 반환된 레코드의 일관된 순서를 보장하기 위해 고유한 값의 타이-브레이커 칼럼을 사용하세요(예: id).

issues 테이블에 다음 인덱스가 있다고 가정합니다:

idx_issues_on_project_id_and_created_at_and_id" btree (project_id, created_at, id)

추가 처리를 위한 레코드 가져오기#

다음 스니펫은 지정된 순서(created_at, id)를 사용하여 프로젝트 내의 이슈 레코드를 반복합니다.

scope = Issue.where(project_id: 278964).order(:created_at, :id) # id is the tie-breaker

iterator = Gitlab::Pagination::Keyset::Iterator.new(scope: scope)

iterator.each_batch(of: 100) do |records|
  puts records.map(&:id)
end

쿼리에 추가 필터를 추가할 수 있습니다. 이 예시는 지난 30일 동안 생성된 이슈 ID만 나열합니다:

scope = Issue.where(project_id: 278964).where('created_at > ?', 30.days.ago).order(:created_at, :id) # id is the tie-breaker

iterator = Gitlab::Pagination::Keyset::Iterator.new(scope: scope)

iterator.each_batch(of: 100) do |records|
  puts records.map(&:id)
end

배치에서 레코드 업데이트#

복잡한 ActiveRecord 쿼리의 경우, .update_all 메서드는 잘못된 UPDATE 구문을 생성하기 때문에 잘 작동하지 않습니다. 배치에서 레코드를 업데이트하기 위해 원시 SQL을 사용할 수 있습니다:

scope = Issue.where(project_id: 278964).order(:created_at, :id) # id is the tie-breaker

iterator = Gitlab::Pagination::Keyset::Iterator.new(scope: scope)

iterator.each_batch(of: 100) do |records|
  ApplicationRecord.connection.execute("UPDATE issues SET updated_at=NOW() WHERE issues.id in (#{records.dup.reselect(:id).to_sql})")
end

반복을 안정적이고 예측 가능하게 유지하기 위해 ORDER BY 절의 칼럼 업데이트를 피하세요.

merge_request_diff_commits 테이블 반복#

merge_request_diff_commits 테이블은 복합 기본 키(merge_request_diff_id, relative_order)를 사용하므로 EachBatch를 효율적으로 사용하는 것이 불가능합니다.

merge_request_diff_commits 테이블을 페이지네이션하려면 다음 스니펫을 사용할 수 있습니다:

# Custom order object configuration:
order = Gitlab::Pagination::Keyset::Order.build([
  Gitlab::Pagination::Keyset::ColumnOrderDefinition.new(
    attribute_name: 'merge_request_diff_id',
    order_expression: MergeRequestDiffCommit.arel_table[:merge_request_diff_id].asc,
    nullable: :not_nullable
  ),
  Gitlab::Pagination::Keyset::ColumnOrderDefinition.new(
    attribute_name: 'relative_order',
    order_expression: MergeRequestDiffCommit.arel_table[:relative_order].asc,
    nullable: :not_nullable
  )
])
MergeRequestDiffCommit.include(FromUnion) # keyset pagination generates UNION queries

scope = MergeRequestDiffCommit.order(order)

iterator = Gitlab::Pagination::Keyset::Iterator.new(scope: scope)

iterator.each_batch(of: 100) do |records|
  puts records.map { |record| [record.merge_request_diff_id, record.relative_order] }.inspect
end

Order 객체 구성#

키셋 페이지네이션은 단순한 ActiveRecord order 스코프와 잘 작동합니다 (첫 번째 예시). 그러나 특수한 경우에는 기반이 되는 키셋 페이지네이션 라이브러리를 위해 ORDER BY 절의 칼럼을 기술해야 합니다(두 번째 예시). 키셋 페이지네이션 라이브러리가 ORDER BY 구성을 자동으로 결정할 수 없으면 오류가 발생합니다.

Gitlab::Pagination::Keyset::Order 및 Gitlab::Pagination::Keyset::ColumnOrderDefinition 클래스의 코드 주석은 ORDER BY 절 구성을 위한 가능한 옵션의 개요를 제공합니다. 키셋 페이지네이션 문서에서도 몇 가지 코드 예시를 찾을 수 있습니다.

배치로 테이블 반복 처리하기

GitLab v19.1
원문 보기
요약

Rails는 행을 배치 단위로 반복 처리하는 데 사용할 수 있는 in_batches 메서드를 제공합니다. 안타깝게도 이 메서드는 쿼리와 메모리 사용 측면 모두에서 효율적이지 않은 방식으로 구현되어 있습니다. 이를 해결하기 위해 모델에 EachBatch 모듈을 포함한 후 each_batch 클래스 메서드를 사용할 수 있습니다.

Rails는 행을 배치 단위로 반복 처리하는 데 사용할 수 있는 in_batches 메서드를 제공합니다. 예시:

User.in_batches(of: 10) do |relation|
  relation.update_all(updated_at: Time.now)
end

안타깝게도 이 메서드는 쿼리와 메모리 사용 측면 모두에서 효율적이지 않은 방식으로 구현되어 있습니다.

이를 해결하기 위해 모델에 EachBatch 모듈을 포함한 후 each_batch 클래스 메서드를 사용할 수 있습니다. 예시:

class User < ActiveRecord::Base
  include EachBatch
end

User.each_batch(of: 10) do |relation|
  relation.update_all(updated_at: Time.now)
end

이는 다음과 같은 쿼리를 생성합니다:

User Load (0.7ms)  SELECT  "users"."id" FROM "users" WHERE ("users"."id" >= 41654)  ORDER BY "users"."id" ASC LIMIT 1 OFFSET 1000
  (0.7ms)  SELECT COUNT(*) FROM "users" WHERE ("users"."id" >= 41654) AND ("users"."id" < 42687)

이 메서드의 API는 in_batches와 유사하지만, in_batches가 지원하는 모든 인수를 지원하지는 않습니다. in_batches가 꼭 필요한 경우가 아니라면 항상 each_batch를 사용해야 합니다.

고유하지 않은 칼럼에 대한 반복 처리#

고유하지 않은 칼럼(관계 컨텍스트에서)에 each_batch 메서드를 사용하면 안 됩니다. 이는 무한 루프가 발생할 수 있습니다. 또한 고유하지 않은 칼럼에 대해 반복 처리할 때 일관되지 않은 배치 크기가 성능 문제를 일으킵니다. 특정 속성에 대해 최대 배치 크기를 적용하더라도 결과 배치가 해당 크기를 초과하지 않는다고 보장할 수 없습니다. 다음 스니펫은 id가 1에서 10,000 사이인 사용자에 대한 Ci::Build 항목을 선택하려 할 때 데이터베이스가 1 215 178개의 일치하는 행을 반환하는 상황을 보여줍니다.

[ gstg ] production> Ci::Build.where(user_id: (1..10_000)).size
=> 1215178

이는 구축된 관계가 다음 쿼리로 변환되기 때문에 발생합니다:

[ gstg ] production> puts Ci::Build.where(user_id: (1..10_000)).to_sql
SELECT "ci_builds".* FROM "ci_builds" WHERE "ci_builds"."type" = 'Ci::Build' AND "ci_builds"."user_id" BETWEEN 1 AND 10000
=> nil

WHERE "ci_builds"."user_id" BETWEEN ? AND ?와 같이 범위로 고유하지 않은 칼럼을 필터링하는 And 쿼리는 범위 크기가 특정 임계값으로 제한되어 있더라도(이전 예시에서 10,000) 이 임계값이 반환되는 데이터셋 크기로 변환되지 않습니다. 그 이유는 속성의 n개 가능한 값을 취할 때, 해당 값을 포함하는 레코드 수가 n보다 작다고 확신할 수 없기 때문입니다.

distinct_each_batch를 사용한 Loose-index scan#

고유하지 않은 칼럼에 대한 반복이 필요한 경우 distinct_each_batch 헬퍼 메서드를 사용하세요. 이 헬퍼는 loose-index scan 기법(skip-index scan)을 사용하여 데이터베이스 인덱스 내의 중복 값을 건너뜁니다.

예시: Issue 모델에서 고유한 author_id에 대한 반복 처리

Issue.distinct_each_batch(column: :author_id, of: 1000) do |relation|
  users = User.where(id: relation.select(:author_id)).to_a
end

이 기법은 데이터 분포에 관계없이 배치 간 안정적인 성능을 제공합니다. relation 객체는 지정된 column만 사용 가능한 ActiveRecord 스코프를 반환합니다. 다른 칼럼은 로드되지 않습니다.

기반이 되는 데이터베이스 쿼리는 재귀적 CTE를 사용하므로 추가 오버헤드가 발생합니다. 따라서 표준 each_batch 반복보다 작은 배치 크기를 사용하는 것을 권장합니다.

칼럼 정의#

EachBatch는 기본적으로 모델의 기본 키를 반복에 사용합니다. 대부분의 경우 이것으로 충분하지만, 경우에 따라 반복에 다른 칼럼을 사용하고 싶을 수 있습니다.

Project.distinct.each_batch(column: :creator_id, of: 10) do |relation|
  puts User.where(id: relation.select(:creator_id)).map(&:id)
end

위 쿼리는 프로젝트 생성자를 반복하고 중복 없이 출력합니다.

칼럼이 고유하지 않은 경우(고유 인덱스 정의가 없는 경우) 관계에서 distinct 메서드를 호출하는 것이 필요합니다. distinct 없이 고유하지 않은 칼럼을 사용하면 다음 이슈에서 설명한 것처럼 each_batch가 무한 루프에 빠질 수 있습니다.

데이터 마이그레이션에서 EachBatch 사용#

데이터 마이그레이션을 처리할 때 대량의 데이터를 반복하는 데 선호되는 방법은 EachBatch를 사용하는 것입니다.

데이터 마이그레이션의 특수한 경우로는 배치 백그라운드 마이그레이션이 있는데, 실제 데이터 수정은 백그라운드 job에서 실행됩니다. 데이터 범위(슬라이스)를 결정하고 백그라운드 job을 예약하는 마이그레이션 코드에서 each_batch를 사용합니다.

each_batch의 효율적인 사용#

EachBatch는 대용량 테이블을 반복하는 데 도움이 됩니다. EachBatch가 모든 반복 관련 성능 문제를 마법처럼 해결해 주지는 않으며, 일부 시나리오에서는 전혀 도움이 되지 않을 수 있다는 점을 강조해야 합니다. 데이터베이스 관점에서 EachBatch가 잘 작동하려면 올바르게 구성된 데이터베이스 인덱스도 필요합니다.

예시 1: 단순 반복#

users 테이블을 반복하고 User 레코드를 표준 출력에 출력하려는 경우를 생각해 봅시다. users 테이블에는 수백만 개의 레코드가 있으므로, 사용자를 가져오기 위해 하나의 쿼리를 실행하면 아마도 시간 초과가 발생할 것입니다.

이 테이블은 몇 개의 행을 포함한 users 테이블의 단순화된 버전입니다. 예시를 좀 더 현실적으로 만들기 위해 id 칼럼에 몇 가지 작은 간격이 있습니다(일부 레코드가 이미 삭제됨). id 필드에 하나의 인덱스가 존재합니다:

ID sign_in_count created_at
1 1 2020-01-01
2 4 2020-01-01
9 1 2020-01-03
300 5 2020-01-03
301 9 2020-01-03
302 8 2020-01-03
303 2 2020-01-03
350 1 2020-01-03
351 3 2020-01-04
352 0 2020-01-05
353 9 2020-01-11
354 3 2020-01-12

모든 사용자를 메모리에 로드(권장하지 않음):

users = User.all

users.each { |user| puts user.inspect }

each_batch 사용:

# Note: for this example I picked 5 as the batch size, the default is 1_000
User.each_batch(of: 5) do |relation|
  relation.each { |user| puts user.inspect }
end

each_batch 동작 방식#

첫 번째 단계로, 다음 데이터베이스 쿼리를 실행하여 테이블에서 가장 낮은 id(시작 id)를 찾습니다:

SELECT "users"."id" FROM "users" ORDER BY "users"."id" ASC LIMIT 1

[

](/19.1/development/database/img/each_batch_users_table_iteration_1_v13_7.png)

쿼리가 인덱스(INDEX ONLY SCAN)에서만 데이터를 읽는다는 점에 주목하세요. 테이블에는 접근하지 않습니다. 데이터베이스 인덱스는 정렬되어 있으므로 첫 번째 항목을 꺼내는 것은 매우 저렴한 연산입니다.

다음 단계는 배치 크기 설정을 준수하는 다음 id(종료 id)를 찾는 것입니다. 이 예시에서는 배치 크기로 5를 사용했습니다. EachBatch는 OFFSET 절을 사용하여 "이동된" id 값을 얻습니다.

SELECT "users"."id" FROM "users" WHERE "users"."id" >= 1 ORDER BY "users"."id" ASC LIMIT 1 OFFSET 5

[

](/19.1/development/database/img/each_batch_users_table_iteration_2_v13_7.png)

다시 쿼리는 인덱스만 조회합니다. OFFSET 5는 여섯 번째 id 값을 꺼냅니다. 이 쿼리는 테이블 크기나 반복 횟수에 관계없이 인덱스에서 최대 여섯 개의 항목을 읽습니다.

이 시점에서 첫 번째 배치의 id 범위를 알 수 있습니다. 이제 relation 블록에 대한 쿼리를 구성할 차례입니다.

SELECT "users".* FROM "users" WHERE "users"."id" >= 1 AND "users"."id" < 302

[

](/19.1/development/database/img/each_batch_users_table_iteration_3_v13_7.png)

< 기호에 주목하세요. 이전에 인덱스에서 여섯 개의 항목을 읽었고 이 쿼리에서 마지막 값은 "제외"됩니다. 쿼리는 인덱스를 보고 디스크에서 다섯 user 행의 위치를 얻은 후 테이블에서 행을 읽습니다. 반환된 배열은 Ruby에서 처리됩니다.

첫 번째 반복이 완료되었습니다. 다음 반복을 위해 이전 반복의 마지막 id 값이 재사용되어 다음 종료 id 값을 찾습니다.

SELECT "users"."id" FROM "users" WHERE "users"."id" >= 302 ORDER BY "users"."id" ASC LIMIT 1 OFFSET 5

[

](/19.1/development/database/img/each_batch_users_table_iteration_4_v13_7.png)

이제 두 번째 반복을 위한 users 쿼리를 쉽게 구성할 수 있습니다.

SELECT "users".* FROM "users" WHERE "users"."id" >= 302 AND "users"."id" < 353

[

](/19.1/development/database/img/each_batch_users_table_iteration_5_v13_7.png)

예시 2: 필터를 사용한 반복#

이전 예시를 기반으로, 로그인 횟수가 0인 사용자를 출력하고 싶다고 가정합시다. sign_in_count 칼럼에 로그인 횟수를 추적하고 있으므로 다음 코드를 작성합니다:

users = User.where(sign_in_count: 0)

users.each_batch(of: 5) do |relation|
  relation.each { |user| puts user.inspect }
end

each_batch는 시작 id 값에 대해 다음 SQL 쿼리를 생성합니다:

SELECT "users"."id" FROM "users" WHERE "users"."sign_in_count" = 0 ORDER BY "users"."id" ASC LIMIT 1

id 칼럼만 선택하고 id로 정렬하면 데이터베이스가 id(기본 키 인덱스) 칼럼의 인덱스를 사용하도록 강제합니다. 그러나 sign_in_count 칼럼에 대한 추가 조건도 있습니다. 해당 칼럼은 인덱스에 포함되어 있지 않으므로 데이터베이스는 첫 번째 일치하는 행을 찾기 위해 실제 테이블을 조회해야 합니다.

[

](/19.1/development/database/img/each_batch_users_table_filter_v13_7.png)

스캔된 행 수는 테이블의 데이터 분포에 따라 다릅니다.

  • 최선의 경우: 첫 번째 사용자가 한 번도 로그인하지 않은 경우. 데이터베이스는 하나의 행만 읽습니다.

  • 최악의 경우: 모든 사용자가 최소 한 번 이상 로그인한 경우. 데이터베이스는 모든 행을 읽습니다.

이 특정 예시에서 데이터베이스는 첫 번째 id 값을 결정하기 위해(배치 크기 설정에 관계없이) 10개의 행을 읽어야 했습니다. "실제 세계" 애플리케이션에서는 필터링이 문제를 일으키는지 예측하기 어렵습니다. GitLab의 경우 프로덕션 레플리카에서 데이터를 확인하는 것이 좋은 출발점이지만, GitLab.com의 데이터 분포는 GitLab Self-Managed 인스턴스와 다를 수 있다는 점을 유념하세요.

each_batch를 사용한 필터링 개선#

특수 조건 인덱스#
CREATE INDEX index_on_users_never_logged_in ON users (id) WHERE sign_in_count = 0

테이블과 새로 만든 인덱스의 모습은 다음과 같습니다:

[

](/19.1/development/database/img/each_batch_users_table_filtered_index_v13_7.png)

이 인덱스 정의는 id 및 sign_in_count 칼럼의 조건을 커버하므로 each_batch 쿼리를 매우 효율적으로 만듭니다(단순 반복 예시와 유사).

사용자가 한 번도 로그인하지 않은 경우는 드물기 때문에 인덱스 크기가 작을 것으로 예상됩니다. 인덱스 정의에 id만 포함하는 것도 인덱스 크기를 작게 유지하는 데 도움이 됩니다.

칼럼에 대한 인덱스#

나중에 다른 sign_in_count 값으로 필터링하면서 테이블을 반복하고 싶을 수 있습니다. 그런 경우 WHERE 조건이 새 필터(sign_in_count > 10)와 일치하지 않기 때문에 이전에 제안한 조건부 인덱스를 사용할 수 없습니다.

이 문제를 해결하기 위해 두 가지 옵션이 있습니다:

  • 새 쿼리를 커버하기 위한 또 다른 조건부 인덱스를 만듭니다.

  • 인덱스를 더 일반화된 구성으로 교체합니다.

동일한 테이블의 동일한 칼럼에 여러 인덱스가 있으면 데이터 쓰기 시 성능 병목이 발생할 수 있습니다.

다음 인덱스를 고려해 봅시다(권장하지 않음):

CREATE INDEX index_on_users_never_logged_in ON users (id, sign_in_count)

인덱스 정의가 id 칼럼으로 시작하기 때문에 데이터 선택성 관점에서 인덱스가 매우 비효율적입니다.

SELECT "users"."id" FROM "users" WHERE "users"."sign_in_count" = 0 ORDER BY "users"."id" ASC LIMIT 1

위 쿼리를 실행하면 INDEX ONLY SCAN이 됩니다. 그러나 쿼리는 여전히 인덱스에서 알 수 없는 수의 항목을 반복하고 sign_in_count가 0인 첫 번째 항목을 찾아야 합니다.

[

](/19.1/development/database/img/each_batch_users_table_bad_index_v13_7.png)

인덱스 정의에서 칼럼을 교체하면 쿼리를 크게 개선할 수 있습니다(권장).

CREATE INDEX index_on_users_never_logged_in ON users (sign_in_count, id)

[

](/19.1/development/database/img/each_batch_users_table_good_index_v13_7.png)

다음 인덱스 정의는 each_batch에서 잘 작동하지 않습니다(권장하지 않음).

CREATE INDEX index_on_users_never_logged_in ON users (sign_in_count)

each_batch는 id 칼럼을 기반으로 범위 쿼리를 작성하므로 이 인덱스를 효율적으로 사용할 수 없습니다. DB는 테이블에서 행을 읽거나 기본 키 인덱스도 읽는 비트맵 검색을 사용합니다.

"느린" 반복#

느린 반복은 좋은 인덱스 구성을 사용하여 테이블을 반복하고 생성된 관계에 필터링을 적용하는 것을 의미합니다.

User.each_batch(of: 5) do |relation|
  relation.where(sign_in_count: 0).each { |user| puts user inspect }
end

반복은 기본 키 인덱스(id 칼럼)를 사용하므로 구문 시간 초과로부터 안전합니다. 필터(sign_in_count: 0)는 id가 이미 제한된(범위) relation에 적용됩니다. 행 수가 제한됩니다.

느린 반복은 일반적으로 완료하는 데 더 많은 시간이 걸립니다. 반복 횟수가 더 많고 하나의 반복에서 배치 크기보다 적은 레코드를 생성할 수 있습니다. 반복에서 0개의 레코드가 생성될 수도 있습니다. 이것이 최적의 솔루션은 아니지만, 일부 경우(특히 대용량 테이블을 다룰 때) 이것이 유일한 실행 가능한 옵션입니다.

서브쿼리 사용#

each_batch 쿼리에서 서브쿼리를 사용하면 대부분의 경우 잘 작동하지 않습니다. 다음 예시를 고려해 봅시다:

projects = Project.where(creator_id: Issue.where(confidential: true).select(:author_id))

projects.each_batch do |relation|
  # do something
end

반복은 projects 테이블의 id 칼럼을 사용합니다. 배치 처리는 서브쿼리에 영향을 미치지 않습니다. 이는 각 반복마다 서브쿼리가 데이터베이스에서 실행된다는 것을 의미합니다. 이로 인해 쿼리에 일정한 "부하"가 추가되어 종종 구문 시간 초과가 발생합니다. 기밀 이슈의 수를 알 수 없으며, 실행 시간과 접근하는 데이터베이스 행은 issues 테이블의 데이터 분포에 따라 다릅니다.

서브쿼리는 서브쿼리가 소수의 행을 반환할 때만 사용합니다.

서브쿼리 개선#

서브쿼리를 다룰 때는 느린 반복 접근 방식이 효과적일 수 있습니다. creator_id에 대한 필터는 생성된 relation 객체의 일부가 될 수 있습니다.

projects = Project.all

projects.each_batch do |relation|
  relation.where(creator_id: Issue.where(confidential: true).select(:author_id))
end

issues 테이블 자체의 쿼리가 충분히 효율적이지 않은 경우 중첩 루프를 구성할 수 있습니다. 가능하면 피하도록 하세요.

projects = Project.all

projects.each_batch do |relation|
  issues = Issue.where(confidential: true)

  issues.each_batch do |issues_relation|
    relation.where(creator_id: issues_relation.select(:author_id))
  end
end

issues 테이블이 projects보다 훨씬 더 많은 행을 가지고 있다면 issues 테이블을 먼저 배치 처리하는 쿼리를 뒤집는 것이 합리적입니다.

JOIN과 EXISTS 사용#

JOINS를 사용해야 하는 경우:

  • 테이블 간에 1:1 또는 1:N 관계가 있고 조인된 레코드가 (거의) 항상 존재하는 경우. 이는 "확장 테이블" 형태에 잘 작동합니다:

projects - project_settings

  • users - user_details

  • users - user_statuses

  • LEFT JOIN이 이 경우에 잘 작동합니다. 조인된 테이블의 조건은 생성된 관계에 추가되어야 하며 조인된 테이블의 데이터 분포에 의해 반복이 영향을 받지 않습니다.

예시:

User.each_batch do |relation|
  relation
    .joins("LEFT JOIN personal_access_tokens on personal_access_tokens.user_id = users.id")
    .where("personal_access_tokens.name = 'name'")
end

EXISTS 쿼리는 each_batch 쿼리의 내부 relation에만 추가해야 합니다:

User.each_batch do |relation|
  relation.where("EXISTS (SELECT 1 FROM ...")
end

relation 객체에 대한 복잡한 쿼리#

relation 객체에 여러 추가 조건이 있으면 실행 계획이 "불안정"해질 수 있습니다.

예시:

Issue.each_batch do |relation|
  relation
    .joins(:metrics)
    .joins(:merge_requests_closing_issues)
    .where("id IN (SELECT ...)")
    .where(confidential: true)
end

여기서 relation 쿼리가 BATCH_SIZE의 사용자 레코드를 읽고 제공된 쿼리에 따라 결과를 필터링할 것으로 예상합니다. 플래너는 confidential 칼럼의 인덱스를 사용한 비트맵 인덱스 조회가 쿼리를 실행하는 더 좋은 방법이라고 결정할 수 있습니다. 이로 인해 예상치 못하게 많은 수의 행이 읽힐 수 있고 쿼리가 시간 초과될 수 있습니다.

문제: 관계가 최대 BATCH_SIZE의 레코드를 반환한다고 확신하지만, 플래너는 이것을 알지 못합니다.

범위 쿼리가 먼저 실행되도록 강제하는 CTE(Common Table Expression) 트릭:

Issue.each_batch(of: 1000) do |relation|
  cte = Gitlab::SQL::CTE.new(:batched_relation, relation.limit(1000))

  scope = cte
    .apply_to(Issue.all)
    .joins(:metrics)
    .joins(:merge_requests_closing_issues)
    .where("id IN (SELECT ...)")
    .where(confidential: true)

  puts scope.to_a
end

레코드 카운팅#

데이터가 대량인 테이블의 경우 쿼리를 통한 레코드 카운팅이 시간 초과를 일으킬 수 있습니다. EachBatch 모듈은 반복적으로 레코드를 카운팅하는 대안적인 방법을 제공합니다. each_batch를 사용하는 단점은 생성된 관계 객체에서 실행되는 추가 카운트 쿼리입니다.

each_batch_count 메서드는 추가 카운트 쿼리의 필요성을 제거하는 더 효율적인 접근 방식입니다. 이 메서드를 호출하면 반복 프로세스를 필요에 따라 일시 중지하고 재개할 수 있습니다. 이 기능은 Sidekiq 워커 내에서 카운팅 연산을 수행할 때와 같이 5분 후 오류 예산 위반이 발생하는 상황에서 특히 유용합니다.

설명을 위해, EachBatch를 사용한 레코드 카운팅은 다음과 같이 추가 카운트 쿼리를 호출합니다:

count = 0

Issue.each_batch do |relation|
  count += relation.count
end

puts count

반면에 each_batch_count 메서드는 추가 카운트 쿼리를 호출하지 않고 더 효율적으로(카운팅이 반복 쿼리의 일부) 카운팅 프로세스를 수행할 수 있습니다:

count, _last_value = Issue.each_batch_count # last value can be ignored here

또한 each_batch_count 메서드는 카운팅 프로세스를 어느 시점에서든 일시 중지하고 재개할 수 있습니다. 이 기능은 다음 코드 스니펫에서 보여줍니다:

stop_at = Time.current + 3.minutes

count, last_value = Issue.each_batch_count do
  stop_at.past? # condition for stopping the counting
end

# Continue the counting later
stop_at = Time.current + 3.minutes

count, last_value = Issue.each_batch_count(last_count: count, last_value: last_value) do
  stop_at.past?
end

EachBatch와 BatchCount 비교#

Service Ping을 위한 새 카운터를 추가할 때 레코드를 카운팅하는 선호되는 방법은 Gitlab::Database::BatchCount 클래스를 사용하는 것입니다. BatchCount에 구현된 반복 로직은 EachBatch와 유사한 성능 특성을 가집니다. BatchCount 개선을 위한 대부분의 팁과 제안은 BatchCount에도 적용됩니다.

키셋 페이지네이션으로 반복#

EachBatch가 작동하지 않는 몇 가지 특수한 경우가 있습니다. EachBatch는 하나의 고유한 칼럼(일반적으로 기본 키)이 필요하기 때문에 타임스탬프 칼럼이나 복합 기본 키가 있는 테이블에서는 반복이 불가능합니다.

EachBatch가 작동하지 않는 경우 키셋 페이지네이션을 사용하여 테이블이나 행 범위를 반복할 수 있습니다. 확장성과 성능 특성은 EachBatch와 매우 유사합니다.

예시:

  • 정렬에 사용되는 칼럼에 고유한 값이 없는 경우 타이-브레이커와 함께 특정 순서(타임스탬프 칼럼)로 테이블 반복.

  • 복합 기본 키가 있는 테이블 반복.

프로젝트의 이슈를 생성 날짜별로 반복#

키셋 페이지네이션을 사용하여 특정 순서(예: created_at DESC)로 임의의 데이터베이스 칼럼을 반복할 수 있습니다. created_at에 같은 값을 가진 반환된 레코드의 일관된 순서를 보장하기 위해 고유한 값의 타이-브레이커 칼럼을 사용하세요(예: id).

issues 테이블에 다음 인덱스가 있다고 가정합니다:

idx_issues_on_project_id_and_created_at_and_id" btree (project_id, created_at, id)

추가 처리를 위한 레코드 가져오기#

다음 스니펫은 지정된 순서(created_at, id)를 사용하여 프로젝트 내의 이슈 레코드를 반복합니다.

scope = Issue.where(project_id: 278964).order(:created_at, :id) # id is the tie-breaker

iterator = Gitlab::Pagination::Keyset::Iterator.new(scope: scope)

iterator.each_batch(of: 100) do |records|
  puts records.map(&:id)
end

쿼리에 추가 필터를 추가할 수 있습니다. 이 예시는 지난 30일 동안 생성된 이슈 ID만 나열합니다:

scope = Issue.where(project_id: 278964).where('created_at > ?', 30.days.ago).order(:created_at, :id) # id is the tie-breaker

iterator = Gitlab::Pagination::Keyset::Iterator.new(scope: scope)

iterator.each_batch(of: 100) do |records|
  puts records.map(&:id)
end

배치에서 레코드 업데이트#

복잡한 ActiveRecord 쿼리의 경우, .update_all 메서드는 잘못된 UPDATE 구문을 생성하기 때문에 잘 작동하지 않습니다. 배치에서 레코드를 업데이트하기 위해 원시 SQL을 사용할 수 있습니다:

scope = Issue.where(project_id: 278964).order(:created_at, :id) # id is the tie-breaker

iterator = Gitlab::Pagination::Keyset::Iterator.new(scope: scope)

iterator.each_batch(of: 100) do |records|
  ApplicationRecord.connection.execute("UPDATE issues SET updated_at=NOW() WHERE issues.id in (#{records.dup.reselect(:id).to_sql})")
end

반복을 안정적이고 예측 가능하게 유지하기 위해 ORDER BY 절의 칼럼 업데이트를 피하세요.

merge_request_diff_commits 테이블 반복#

merge_request_diff_commits 테이블은 복합 기본 키(merge_request_diff_id, relative_order)를 사용하므로 EachBatch를 효율적으로 사용하는 것이 불가능합니다.

merge_request_diff_commits 테이블을 페이지네이션하려면 다음 스니펫을 사용할 수 있습니다:

# Custom order object configuration:
order = Gitlab::Pagination::Keyset::Order.build([
  Gitlab::Pagination::Keyset::ColumnOrderDefinition.new(
    attribute_name: 'merge_request_diff_id',
    order_expression: MergeRequestDiffCommit.arel_table[:merge_request_diff_id].asc,
    nullable: :not_nullable
  ),
  Gitlab::Pagination::Keyset::ColumnOrderDefinition.new(
    attribute_name: 'relative_order',
    order_expression: MergeRequestDiffCommit.arel_table[:relative_order].asc,
    nullable: :not_nullable
  )
])
MergeRequestDiffCommit.include(FromUnion) # keyset pagination generates UNION queries

scope = MergeRequestDiffCommit.order(order)

iterator = Gitlab::Pagination::Keyset::Iterator.new(scope: scope)

iterator.each_batch(of: 100) do |records|
  puts records.map { |record| [record.merge_request_diff_id, record.relative_order] }.inspect
end

Order 객체 구성#

키셋 페이지네이션은 단순한 ActiveRecord order 스코프와 잘 작동합니다 (첫 번째 예시). 그러나 특수한 경우에는 기반이 되는 키셋 페이지네이션 라이브러리를 위해 ORDER BY 절의 칼럼을 기술해야 합니다(두 번째 예시). 키셋 페이지네이션 라이브러리가 ORDER BY 구성을 자동으로 결정할 수 없으면 오류가 발생합니다.

Gitlab::Pagination::Keyset::Order 및 Gitlab::Pagination::Keyset::ColumnOrderDefinition 클래스의 코드 주석은 ORDER BY 절 구성을 위한 가능한 옵션의 개요를 제공합니다. 키셋 페이지네이션 문서에서도 몇 가지 코드 예시를 찾을 수 있습니다.