데이터베이스 군사 규정을 이해하는 데 도움이 되도록 MySQL을 예로 들어 보겠습니다.

데이터베이스는 항상 애플리케이션에서 가장 중요한 부분입니다. 동시에 높은 동시성 단계에 도달하면 데이터베이스 테이블과 인덱스가 처음에 잘 설계되지 않으면 나중에 수평 확장이 발생하는 경우가 많습니다. 데이터베이스와 하위 데이터베이스 및 테이블에 문제가 발생합니다.

인터넷 기업의 경우 일반적으로 MySQL 데이터베이스를 사용합니다.

1. 데이터베이스의 전체 아키텍처

먼저 MySQL 데이터의 전체 아키텍처를 다음과 같이 살펴보겠습니다.

이것은 매우 고전적인 MySQL 시스템 아키텍처 다이어그램을 통해 MySQL의 기능을 볼 수 있습니다. MySQL의 각 부분.

클라이언트가 데이터베이스에 연결되면 먼저 사용자 연결을 관리하고 특정 인증 및 권한 부여를 수행하는 데 사용되는 연결 풀에 직면합니다.

데이터베이스에 연결한 후 클라이언트는 SQL 문을 보내고 SQL 인터페이스 모듈은 사용자의 SQL 문을 수락합니다.

SQL 문은 엄격한 문법 규칙을 준수해야 하는 경우가 많으므로 문을 구문 분석하려면 문법 파서가 필요합니다. 구문 분석의 원리는 문에서 구문 트리까지 컴파일 원리에서 배운 대로입니다.

사용자가 속한 쿼리를 최적화하여 가장 빠른 쿼리 경로를 선택할 수 있는 것이 옵티마이저의 역할입니다.

쿼리 속도를 높이기 위해 쿼리 캐시 모듈이 있습니다. 쿼리 캐시에 적중 쿼리 결과가 있으면 쿼리 문이 쿼리 캐시에서 데이터를 직접 가져올 수 있습니다.

위의 모든 구성 요소는 데이터베이스 서비스 계층이고 그 다음에는 데이터베이스 엔진 계층이 있습니다. 현재 주류 데이터베이스 엔진은 InnoDB입니다.

데이터베이스에 대한 모든 수정 사항은 기본 및 보조 복제의 기초가 되는 데이터베이스 서비스 계층의 바이너리 로그에 기록됩니다.

데이터베이스 엔진 계층의 경우 유명한 다이어그램은 다음과 같습니다.

스토리지 엔진 계층에는 캐시와 로그도 있으며 최종 데이터는 디스크에 삭제됩니다.

스토리지 엔진 계층의 캐시도 성능 향상을 위해 사용되지만 데이터베이스 서비스 계층의 캐시는 쿼리 캐시인 반면, 데이터베이스 엔진 계층의 캐시는 다릅니다. 읽기와 쓰기 모두. 데이터베이스 서비스 계층의 캐시는 쿼리 논리를 기반으로 하는 반면, 데이터베이스 엔진의 캐시는 물리적이라고 할 수 있는 데이터 페이지를 기반으로 합니다.

데이터베이스 엔진 계층에서는 캐시에만 데이터가 기록되더라도 데이터베이스 서비스 계층에서는 지속된 것으로 간주됩니다. 물론 이로 인해 캐시 페이지와 하드 페이지 간의 데이터 불일치가 발생하게 됩니다. 이러한 불일치는 무결성을 보장하기 위해 데이터베이스 엔진 계층의 로그에 의해 보장됩니다.

그래서 데이터베이스 엔진 계층의 로그는 데이터베이스 서비스 계층의 로그와 다릅니다. 서비스 계층의 로그는 수정 논리를 하나씩 기록하는 반면, 엔진 계층의 로그는 캐시 페이지와 데이터 간의 물리적 차이를 기록합니다. 페이지.

2. 데이터베이스 워크플로우

쿼리를 수신하면 MySQL 아키텍처의 각 구성 요소는 다음과 같이 작동합니다.

클라이언트는 데이터베이스 서비스 계층과 TCP 연결을 설정하고 연결 관리 모듈이 설정됩니다. 연결 스레드를 요청합니다. 연결 풀에 유휴 연결 스레드가 있으면 이 연결에 할당되고, 없으면 새 연결 스레드가 생성되어 최대 연결 수를 초과하지 않고 이 클라이언트를 담당합니다.

실제 작동 전에 사용자 모듈을 호출하여 사용자에게 권한이 있는지 확인하는 권한 확인이 필요합니다. 통과 후 서비스가 제공되고 연결 스레드가 클라이언트로부터 SQL 문을 수신하여 처리하기 시작합니다.

연결 스레드는 SQL 문을 받은 후 구문 분석 및 의미 분석을 위해 SQL 문 구문 분석 모듈에 해당 문을 전달합니다.

쿼리문인 경우 먼저 쿼리 캐시에 결과가 있는지 확인할 수 있습니다. 결과가 있으면 클라이언트에 직접 반환할 수 있습니다.

쿼리 캐시에 결과가 없으면 실제로 데이터베이스 엔진 계층에 쿼리한 후 쿼리 최적화를 위해 SQL 최적화 프로그램으로 보내야 합니다. 테이블 변경인 경우 처리를 위해 삽입, 업데이트, 삭제, 생성 및 변경 처리 모듈로 전달됩니다.

다음 단계는 데이터베이스 엔진 계층을 요청하고, 테이블을 열고, 필요한 경우 해당 잠금을 획득하는 것입니다.

다음 처리 프로세스는 InnoDB와 같은 데이터베이스 엔진 계층으로 이동합니다.

데이터베이스 엔진 계층에서는 먼저 캐시 페이지에 해당 데이터가 있는지 쿼리해야 합니다. 존재하는 경우 직접 반환할 수 있으며, 그렇지 않은 경우 디스크에서 읽어야 합니다.

해당 데이터가 디스크에서 발견되면 캐시에 로드되어 후속 쿼리가 더 효율적으로 이루어집니다. 제한된 메모리로 인해 캐시된 페이지에 자주 액세스할 수 있도록 유연한 LRU 테이블을 사용하여 캐시 페이지를 관리하는 경우가 많습니다. 데이터.

데이터를 얻은 후 클라이언트에 반환하고 연결을 닫고 연결 스레드를 해제하면 프로세스가 종료됩니다.

3. 데이터베이스 인덱스의 원리

전체 과정에서 병목 지점이라고 가장 쉽게 부르는 것은 데이터 읽기 및 쓰기인데, 이는 디스크를 순차적으로 또는 무작위로 읽고 쓰는 경우가 많으며, 디스크를 읽고 쓰는 속도입니다. 상대적으로 느린 경우가 많습니다.

처리 속도를 높이면 어떨까요? 인덱스를 만드는 것이라고 다들 짐작하셨을 거라 믿습니다.

인덱싱을 통해 이 프로세스 속도를 높일 수 있는 이유는 무엇인가요?

음식의 도시에는 모두가 방문했다고 생각합니다. 서두르지 않고 배가 고프지 않으며 검색 성능에 대한 요구 사항이 없다면 쇼핑몰에서 시간을내어 하나하나 살펴볼 수 있습니다. 먹고 싶은 레스토랑을 찾을 때까지 하지만 배가 고프거나, 식당에 약속을 잡았을 때, 꼭 그 식당으로 바로 가고 싶을 때, 층별 지도를 보고 빠르게 목표 식당의 위치를 ​​찾아보는 경우가 많습니다. 찾으면 해당 주제로 바로 이동하면 시간이 많이 절약됩니다. 이것이 바로 색인의 역할입니다.

그래서 인덱스는 값을 통해 자신의 위치를 ​​빠르게 찾아 빠르게 접근할 수 있도록 하는 것입니다.

지수의 또 다른 기능은 실제로 데이터를 보지 않고도 몇 가지 판단을 내릴 수 있다는 것입니다. 예를 들어 쇼핑몰에 특정 레스토랑이 있으면 지수만 보면 알 수 없습니다. 모든 사천 레스토랑을 찾으려면 한 사천 레스토랑에서 다른 사천 레스토랑으로 이동하는 대신 색인만 보면 됩니다.

그럼 MySQL에서 인덱스는 어떻게 작동하나요?

MySQL의 인덱스 구조는 B+ 트리인 경우가 많습니다.

M차 B+ 트리에는 다음과 같은 속성이 있습니다.

1 노드는 인덱스 노드와 데이터 노드로 나뉩니다. 인덱스 노드는 B-트리의 내부 노드에 해당합니다. 모든 인덱스 노드는 B-트리를 구성하며 B-트리의 모든 특성을 갖습니다. 인덱스 노드에는 키와 포인터가 저장되며 특정 요소는 저장되지 않습니다. 데이터 노드는 B 트리의 외부 노드와 동일하며 B+ 트리에서 실제 데이터 요소를 저장하는 데 사용됩니다. 포인터가 없습니다.

2. 전체 인덱스 노드로 구성된 B-트리는 특정 키를 가진 데이터 요소가 어떤 외부 노드에 있는지 찾는 데에만 사용됩니다. 인덱스 노드에서 키를 찾은 후에도 문제는 끝나지 않습니다. 계속해서 데이터 노드를 찾은 다음 데이터 노드의 요소를 읽거나 이진 검색 또는 순차 스캔을 수행하여 실제 데이터를 찾아야 합니다. 강요.

3. M 순서는 인덱스 노드 부분의 정도를 제어하는 ​​데만 사용되며 각 데이터 노드에 포함된 요소 수는 M과 관련이 없습니다.

4. 모든 데이터 노드를 하나로 묶고 순차적으로 액세스할 수 있는 연결 목록도 있습니다.

이 정의는 비교적 추상적이므로 구체적인 예를 살펴보겠습니다.

그림에서 우리는 이것이 3차 B+ 트리이고 외부 데이터 노드에 최대 5개의 항목이 포함되어 있음을 알 수 있습니다. 삽입된 데이터가 데이터 노드에 있고 분할 및 병합이 발생하지 않는 경우 인덱스 노드로 구성된 B-트리는 변경되지 않습니다.

71번부터 75번까지 외부 노드에 항목 76을 삽입하면 분할이 발생하여 71, 72, 73이 데이터 노드가 되고, 인덱스 노드의 경우 74, 75, 76이 데이터 노드가 됩니다. , 이는 74개의 프로세스에 대해 키를 삽입하는 것과 같습니다.

외부 노드 41~43 중 43개를 삭제하면 41, 42, 61, 62, 63이 하나의 노드로 병합됩니다. 인덱스 노드의 경우 삭제 과정과 동일합니다. 열쇠 60.

검색할 때 B+ 트리 레이어 높이가 매우 작기 때문에 상대적으로 빠르게 위치를 찾을 수 있습니다. 예를 들어 값이 62인 경우 루트 노드에서 40보다 큰 값이 발견되면 70보다 작으면 왼쪽에 액세스하고, 60보다 크면 오른쪽에 액세스합니다. 두 번째 리프 노드에서는 62가 발견되어 성공적으로 위치되었습니다.

MySQL의 InnoDB에는 두 가지 유형의 B+ 트리 인덱스가 있는데, 하나는 클러스터형 인덱스라고 하고 다른 하나는 보조 인덱스라고 합니다.

클러스터형 인덱스의 리프 노드는 데이터 노드이며, 기본 키가 클러스터형 인덱스로 사용되는 경우가 많습니다. 보조 인덱스의 리프 노드는 KEY 필드와 기본 키 값을 저장합니다. 따라서 보조 인덱스를 통해 데이터에 액세스하려면 인덱스에 두 번 액세스해야 합니다.

여러 열에 대해 색인을 생성할 수 있는 복합 색인 또는 복합 색인이라는 색인 형태도 있습니다.

이런 종류의 인덱스 정렬 규칙은 첫 번째 열을 먼저 비교하고, 첫 번째 열이 같으면 두 번째 열을 비교하는 식입니다.

4. 데이터베이스 인덱스의 장점과 단점

데이터베이스 인덱스의 가장 확실한 장점은 I/O를 줄이는 것입니다. 아래에서는 몇 가지 시나리오를 분석합니다.

= 조건이 있는 필드의 경우 B+ 트리를 직접 검색할 수 있으며 매우 적은 수의 하드 디스크 읽기(B+ 트리 높이와 동일)로 리프 노드에 도달한 다음 위치를 직접 찾을 수 있습니다. 데이터의.

범위 필드의 경우 B+ 트리가 정렬되어 있으므로 트리를 통해 범위를 빠르게 찾을 수 있습니다.

마찬가지로 orderby, group by, independent/max, min의 경우에도 B+ 트리가 정렬되어 있으므로 결과를 빠르게 얻을 수 있습니다.

데이터를 포함하는 인덱스라는 일반적인 시나리오도 있습니다. 예를 들어 A, B 두 개의 필드가 조건 필드로 사용되는데 A=a AND B=b가 자주 나타나는 경우 C와 D를 동시에 선택하면 결합 인덱스(A, B)가 생성되는 경우가 많습니다. 보조 인덱스이므로 검색 시 해당 리프 노드와 레코드는 보조 인덱스의 B+ 트리를 통해 빠르게 찾을 수 있지만 일부 레코드에는 클러스터형 인덱스의 ID가 포함되어 있으므로 클러스터형 인덱스의 B+ 트리에서 검색해야 합니다. 한 번 테이블에서 실제 레코드를 찾은 다음 레코드에서 C와 D를 읽습니다. 조인트 인덱스를 설정할 때 조인트 인덱스가 (A, B, C, D)이면 모든 데이터는 보조 인덱스의 B+ 트리에 있고 직접 반환될 수 있어 트리 검색 과정이 줄어듭니다.

물론 색인 생성에는 대가가 따릅니다. 세상에 공짜 점심은 없습니다.

색인이 가져오는 이점의 대부분은 읽기 효율성 향상인 반면, 색인이 가져오는 가격은 쓰기 효율성 감소입니다.

데이터를 삽입하고 수정하면 인덱스가 변경될 수 있습니다.

삽입할 때 클러스터형 인덱스는 기본 키 위에 구축되는 경우가 많기 때문에 기본 키에 대해 자동 증가를 사용하는 것이 가장 좋습니다. 그래야 삽입된 데이터가 항상 마지막에 있고 순차적이므로 더 효율적입니다. . 기본 키에 UUID를 사용하지 마세요. 이렇게 하면 무작위 쓰기가 발생하고 효율성이 저하됩니다. 비즈니스와 관련된 기본 키는 사용하지 마십시오. 비즈니스와 관련된다는 것은 기본 키가 업데이트되고 삭제 및 재삽입되어 효율성이 저하된다는 의미이기 때문입니다.

위의 B+ 트리 원리 소개를 통해 B+ 트리에서 분할 비용이 여전히 상대적으로 높고 삽입 과정에서 분할이 자주 발생한다는 것을 알 수 있습니다.

데이터 수정은 기본적으로 삭제하고 다시 삽입하는 것과 동일하며 비용이 상대적으로 높습니다.

일부 문자열 열의 보조 인덱스는 종종 무작위 쓰기 및 읽기를 유발하여 I/O에 더 큰 부담을 줍니다.

5. 데이터베이스 군사 규정의 원리 해석

이 두 지표의 원리를 이해하면 소위 데이터베이스 군사 규정이 왜 이렇게 나타나는지 설명할 수 있습니다. 아래에서 하나씩 설명하겠습니다.

어떤 상황에서 별도의 인덱스가 아닌 결합된 인덱스를 사용해야 하나요?

조건문 A=a AND B=b가 있다고 가정합니다. A와 B가 두 개의 별도 인덱스인 경우 AND 조건에서는 하나의 인덱스만 작동하며 B의 경우 하나씩 판단해야 합니다. 인덱스(A, B)는 트리를 순회하기만 하면 효율성이 크게 향상됩니다. 그러나 A=a OR B=b의 경우 OR 관계로 인해 결합된 인덱스가 작동하지 않으므로, 이때 별도의 인덱스를 사용할 수 있습니다.

왜 지수를 차별화해야 하나요? 통합지수에서는 차별화된 지수를 먼저 배치해야 하나요?

성별을 사용하는 등 구별이 없으면 큰 테이블 전체를 두 부분으로 나누는 것과 같습니다. 데이터를 찾으려면 여전히 테이블의 절반을 탐색해야 하므로 인덱스가 의미가 없게 됩니다.

결합 인덱스가 있는 경우에도 단일 열 인덱스가 필요한가요?

결합 색인이 (A, B)인 경우 A=a 조건에 이 결합 색인을 사용할 수 있습니다. 결합 색인은 첫 번째 열부터 먼저 정렬되므로 별도의 색인을 만들 필요가 없습니다. A의 경우에는 사용하지만 B=b에는 사용하지 않습니다. 두 번째 열은 첫 번째 열이 동일한 경우에만 비교하므로 두 번째 열은 동일하고 다른 노드에 분산될 수 있으며 빠르게 확인할 방법이 없습니다. 그것을 찾으십시오.

인덱스는 많을수록 좋나요?

물론 꼭 필요한 곳에만 인덱스를 추가하면 됩니다. 인덱스는 삽입과 수정의 효율성을 떨어뜨릴 뿐만 아니라, 쿼리할 때 쿼리 최적화 프로그램이 너무 많으면 최적화 프로그램이 혼란스러워서 찾지 못할 수도 있습니다. . 쿼리 경로를 수정하여 느린 인덱스를 선택합니다.

자동 증가 기본 키를 사용하는 이유는 무엇인가요?

문자열 기본 키와 임의 기본 키를 사용하면 데이터가 무작위로 삽입되고 효율성이 상대적으로 떨어지기 때문에 B+ 트리와 빈번한 병합 및 분할을 방지하려면 기본 키를 덜 자주 업데이트해야 합니다.

NULL을 사용하지 않는 이유는 무엇인가요?

NULL은 B+ 트리에서 처리하기가 더 어렵고 종종 처리하는 데 특별한 논리가 필요하므로 결과적으로 효율성이 떨어집니다.

자주 업데이트되는 필드에 인덱스를 생성해 보는 것은 어떨까요?

필드를 업데이트한다는 것은 해당 인덱스도 업데이트해야 한다는 의미입니다. 인덱스는 원래 쓰기 단계에서 미리 특정 데이터 구조를 형성하여 읽기 단계를 더 효율적으로 만드는 방법입니다. 그러나 필드에 더 많이 기록되고 더 적게 읽는 경우에는 인덱스를 사용하지 않는 것이 좋습니다.

쿼리 조건에 함수를 사용하면 어떨까요?

예를 들어 ID+1=10인 조건에서는 미리 작성하면 인덱스가 생성됩니다. ID+1과 같은 작업 단계에서는 인덱스를 예로 사용할 수 없습니다. 먼저 모든 인덱스를 계산하는 방법입니다. 그런 다음 비교하면 비용이 너무 높으므로 ID=10-1을 사용해야 합니다.

NOT와 같은 부정 쿼리 조건을 사용하면 어떨까요?

B+ 트리의 경우 기본 노드가 40이라고 상상할 수 있습니다. 조건이 20이면 왼쪽으로 이동하여 조건이 50이면 오른쪽으로 이동하여 확인하세요. 은 66과 같지 않습니다. 인덱스는 어떻게 해야 합니까? 다 겪어보기 전까지는 알 수 없습니다.

퍼지 쿼리가 와일드카드 문자로 시작되지 않는 이유는 무엇입니까?

B+ 트리의 경우 루트가 문자 def이고 abc%와 같이 와일드카드가 뒤에 있으면 efg%와 같이 왼쪽에서 검색해야 하며, 다음과 같은 경우에는 오른쪽에서 검색해야 합니다. 와일드카드 문자가 앞에 있습니다(%abc). 어디로 가야 할지 모릅니다. 어느 쪽이든 모두 스캔해 보겠습니다.

OR을 IN으로 변경하거나 Union을 사용해야 하는 이유는 무엇인가요?

OR 쿼리 조건을 최적화하면 특히 OR 조건이 많은 경우 IN을 사용하는 것이 더 좋습니다. 이진 검색 방식을 통한 통합 처리. 다양한 필드의 경우 Union을 사용하면 각 하위 쿼리에서 인덱스를 사용할 수 있습니다.

데이터 유형이 가능한 작아야 하는 이유는 무엇입니까? 문자 유형 대신 정수 유형이 자주 사용됩니다. 긴 문자 유형에는 접두사 인덱스를 고려할 수 있습니다.

데이터베이스는 페이지 단위로 저장되기 때문에 각 페이지의 크기는 동일합니다. 데이터 유형이 클수록 페이지 수가 늘어나고 각 페이지에 배치되는 데이터가 작아지며 트리의 높이가 높아집니다. 높을수록 데이터 검색을 위해 읽어야 하는 I/O 수가 상대적으로 많고, 삽입 중에 노드가 쉽게 분할되어 효율성이 떨어집니다. 이것이 아마도 문자 대신 정수를 사용하는 이유일 것입니다. IP 주소와 같은 색인 생성에는 정수가 더 효율적입니다. 인덱스를 사용하여 쿼리해야 하는 긴 문자 유형이 있는 경우 인덱스가 너무 커지지 않도록 전체 필드 대신 필드의 접두사를 인덱스하는 것을 고려할 수 있습니다.

6. 쿼리 최적화 방법론

최적화가 필요한 SQL 문을 찾으려면 먼저 문제가 있는 SQL 문을 수집해야 합니다.

MySQL 데이터베이스는 Slow_query_log 매개변수를 통해 실행 시간이 특정 임계값을 초과하는 SQL 인용문 목록을 얻을 수 있는 느린 SQL 로그 기능을 제공합니다.

인덱스를 사용하지 않는 SQL 문은 long_queries_not_using_indexes 매개변수를 통해 활성화할 수 있습니다.

min_examined_row_limit, 이 값보다 큰 스캔 레코드 수가 포함된 SQL 문만 느린 SQL 로그에 기록됩니다.

문제가 있는 구문을 찾은 후 다음 단계는 explainSQL을 통해 SQL 실행 계획을 얻는 것입니다. 인덱스를 통해 레코드를 스캔할지 여부는 인덱스를 생성하여 실행 효율성을 최적화할 수 있습니다. 스캔 기록이 너무 많은지 여부. 잠금이 너무 오랫동안 유지되는지 여부 또는 잠금 충돌이 있는지 여부. 반환된 레코드 수가 많은지 여부.

맞춤형 최적화는 다음에 할 수 있습니다. 인덱스에 포함되지 않은 필터 조건과 관련된 필드의 경우 더 구분이 잘 되는 필드에 인덱스를 생성하세요. 여러 필드가 관련되어 있으면 결합 인덱스를 생성해 보세요.

스캔된 레코드 수는 매우 많지만 반환된 레코드 수는 적고 판별력이 좋지 않습니다. SQL 문에 포함된 필드를 다시 평가하고 판별력이 높은 필드를 여러 개 선택하여 인덱스를 만듭니다.

스캔된 레코드 수가 매우 많고, 반환되는 레코드 수도 매우 많습니다. 필터링 조건이 강력하지 않습니다. SQL 필터링 조건

schema_redundant_indexes을 추가하여 어떤 중복 인덱스가 있는지 확인하세요.

여러 인덱스에 동일한 순서의 필드가 포함된 경우 공동 인덱스 Schema_unused_indexes를 구성하여 어떤 인덱스가 절대 사용되지 않는지 확인할 수 있습니다.

7. 읽기-쓰기 분리의 원리

데이터베이스는 쓰기는 적게 하고 읽기는 많이 하는 경우가 많으므로 성능 최적화의 첫 번째 단계는 읽기와 쓰기를 분리하는 것입니다.

마스터-슬레이브 복제는 마스터 노드의 서비스 계층 로그를 기반으로 구현되며, 슬레이브 노드에는 이 로그를 읽고 로컬로 쓰는 IO 스레드가 있습니다. 다른 스레드는 로컬 로그에서 읽은 다음 슬레이브 노드에서 이를 다시 실행합니다.

그림은 마스터-슬레이브 비동기 복제의 흐름도를 보여줍니다. 마스터 인스턴스는 엔진에 쓴 후 성공을 반환한 다음 이벤트를 슬레이브 인스턴스로 보내고 슬레이브 인스턴스에서 실행합니다. 이 동기화 방법은 속도는 더 빠르지만, 마스터가 끊겼을 때 복제가 이루어지지 않으면 데이터 손실 문제가 발생할 수 있습니다.

슬레이브 노드가 다운로드된 후 클라이언트로 반환되는 방식도 다릅니다. 물론 NetEase 데이터베이스 팀은 그룹 제출, 병렬 복제 및 기타 기술을 통해 성능을 향상시킵니다. .

마스터-슬레이브 복제를 사용하면 데이터베이스 DAO 계층에서 읽기-쓰기 분리 전략을 설정할 수 있으며 이는 데이터베이스 미들웨어를 통해서도 수행할 수 있습니다.

실제로 데이터베이스 로그는 Canal(Alibaba 오픈 소스 프로젝트: MySQL 데이터베이스 Binlog 기반 증분 구독 및 소비)을 사용하여 캐시를 업데이트하는 데 사용할 수 있는 데이터베이스의 Binlog를 구독하는 등 다양한 용도로 사용됩니다. 등.