읽기 전용 데이터(Read-mostly data)

데이터베이스 확장성 패턴 중 하나인 read-mostly 데이터의 특성과 GitLab 개발에서의 모범 사례를 설명합니다.

이 문서는 데이터베이스 확장성 워킹 그룹 에서 도입된 read-mostly 패턴에 대해 설명합니다. read-mostly 데이터의 특성을 살펴보고, 이 맥락에서 GitLab 개발 시 고려해야 할 모범 사례를 제안합니다. read-mostly 데이터의 특성 # 이름에서 알 수 있듯이, read-mostly 데이터는 업데이트보다 읽기가 훨씬 더 자주 발생하는 데이터를 의미합니다. 업데이트, 삽입, 삭제를 통한 이 데이터의 쓰기는 읽기에 비해 매우 드문 이벤트입니다. 또한, 이 맥락에서 read-mostly 데이터는 일반적으로 작은 데이터셋입니다. 대용량 데이터셋은 "한 번 쓰고 자주 읽는" 특성을 가지는 경우가 많지만, 여기서는 대용량 데이터셋을 명시적으로 다루지 않습니다. 예시: 라이선스 데이터 # 대표적인 예시를 소개합니다: GitLab의 라이선스 데이터. GitLab 인스턴스에는 GitLab 엔터프라이즈 기능을 사용하기 위한 라이선스가 첨부될 수 있습니다. 이 라이선스 데이터는 인스턴스 전체에서 유지되며, 일반적으로 관련 레코드가 몇 개밖에 존재하지 않습니다. 이 정보는 매우 작은 licenses 테이블에 보관됩니다. 이 데이터를 read-mostly 데이터로 간주하는 이유는 위에서 설명한 특성을 따르기 때문입니다: 드문 쓰기 : 라이선스 데이터는 라이선스를 삽입한 후에는 쓰기가 거의 발생하지 않습니다. 빈번한 읽기 : 라이선스 데이터는 엔터프라이즈 기능 사용 여부를 확인하기 위해 매우 자주 읽힙니다. 작은 크기 : 이 데이터셋은 매우 작습니다. GitLab.com에서는 전체 관계 크기가 50 kB 미만인 5개의 레코드만 존재합니다. 대규모 환경에서 read-mostly 데이터의 영향 # 이 데이터셋은 작고 자주 읽히기 때문에, 데이터가 거의 항상 데이터베이스 캐시 및/또는 데이터베이스 디스크 캐시에 상주할 것으로 예상할 수 있습니다. 따라서 read-mostly 데이터의 문제는 일반적으로 데이터베이스 I/O 오버헤드에 관한 것이 아닙니다. 어차피 디스크에서 데이터를 읽지 않기 때문입니다. 그러나 높은 빈도의 읽기를 고려하면, 데이터베이스 CPU 부하 및 데이터베이스 컨텍스트 스위치 측면에서 오버헤드가 발생할 가능성이 있습니다. 또한 이러한 고빈도 쿼리는 전체 데이터베이스 스택을 통과합니다. 데이터베이스 연결 멀티플렉싱 구성 요소와 로드 밸런서에도 오버헤드를 유발합니다. 또한 애플리케이션은 쿼리를 준비하고 전송하여 데이터를 검색하고, 결과를 역직렬화하며, 수집된 정보를 나타내는 새 객체를 할당하는 데 사이클을 소비합니다. 이 모든 것이 고빈도로 발생합니다. 위의 라이선스 데이터 예시에서, 라이선스 데이터를 읽는 쿼리는 쿼리 빈도 측면에서 두드러진다고 확인 되었습니다. 실제로 피크 시간대에 클러스터에서 초당 약 6,000개의 쿼리(QPS)가 발생하는 것을 확인했습니다. 당시 클러스터 크기에서, 각 레플리카에서 약 1,000 QPS, 피크 시간대에 primary에서 400 QPS 미만이 발생했습니다. 이 차이는 순수한 읽기 전용 트랜잭션에