라이브 방송 운영 플랫폼에 대한 Elasticsearch의 원칙과 실천

우한위안추앙휘 복귀, 4월 20일 대형모델 얘기하자”

소스팀｜Bytedance 라이브 운영 플랫폼

ES를 기반으로 하는 크로스 도메인 데이터 집계 서비스를 지속적으로 구축하면서 우리는 ES의 많은 기능이 MySQL과 같이 일반적으로 사용되는 데이터베이스와 상당히 다르다는 것을 발견했습니다. 이 기사에서는 ES의 구현 원칙, 생방송 플랫폼에서의 비즈니스 선택 제안을 공유합니다. , 그리고 실제로 사고에 직면하는 문제.

ES 도입 및 적용 시나리오

Elasticsearch는 실시간에 가까운 분산형 대규모 데이터 저장, 검색 및 분석 엔진입니다. 우리가 흔히 "ELK"라고 부르는 것은 수집, 저장, 검색 및 시각화가 가능한 Elasticsearch, Logstash/Beats, Kibana로 구성된 데이터 시스템을 의미합니다. ES는 유사한 데이터 시스템에서 데이터 저장 및 인덱싱, 데이터 검색 및 데이터 분석 역할을 합니다.

ES 기능

각 기술 선택에는 고유한 특성이 있으며 ES의 전반적인 특성도 기본 구현에 의해 영향을 받습니다. 이 문서의 두 번째 부분에서는 다음 특성의 근본 원인을 자세히 설명합니다.

장점:

1. 분산: 샤딩을 통해 최대 PB 수준의 데이터를 지원하고 샤딩 세부 정보를 외부로부터 보호할 수 있습니다.
2. 확장성: 수평 확장이 쉽고, MySQL처럼 데이터베이스와 테이블을 수동으로 나누거나 타사 구성 요소를 사용할 필요가 없습니다.
3. 빠른 속도: 각 샤드의 병렬 계산, 빠른 검색 속도;
4. 전체 텍스트 검색: 다양한 단어 분할 플러그인을 통한 다중 언어 전체 텍스트 검색 지원 및 의미 처리를 통한 정확성 향상과 같은 다중 대상 최적화
5. 풍부한 데이터 분석 기능.

단점：

1. 트랜잭션은 지원되지 않습니다. 각 샤드의 계산 프로세스는 병렬적이고 독립적입니다.
2. 거의 실시간: 데이터가 기록된 후 데이터를 쿼리할 수 있을 때까지 몇 초의 지연이 있습니다.
3. 기본 DSL 언어는 상대적으로 복잡하고 특정 학습 비용이 있습니다.

일반적인 용도

기능은 구성 요소의 응용 시나리오에 영향을 미칩니다. 문서 검색 및 분석 부분에서 라이브 방송 운영 플랫폼은 ES를 사용하여 수억 개의 앵커의 다양한 정보를 집계하고 이를 사용하여 해당 플랫폼에 다양한 목록을 표시합니다. Argos 오류를 검색하는 데 사용됩니다.

ES 구현 및 아키텍처

다음으로 위에서 언급한 ES의 장점이 어떻게 구현되고 단점이 어떻게 발생하는지 이해해야 합니다. ES에 대해 이야기할 때 Lucene에 대해 이야기해야 합니다. Lucene은 전체 텍스트 검색 Java 라이브러리로 Lucene을 사용하여 모든 것을 구현합니다. 다음은 주로 Lucene의 기능을 소개합니다. Lucene에 비해 ES에는 어떤 기능이 있고 어떤 새로운 기능이 있습니까?

Lucene은 단일 인스턴스에서 데이터 인덱싱 및 검색을 구현합니다. 데이터의 역인덱스 및 순차적 쓰기를 지원할 수 있지만 수정 및 삭제는 지원하지 않습니다. 배포를 지원할 수 없습니다.

따라서 ES는 Lucene에 비해 몇 가지 새로운 기능을 추가했습니다 . 주로 새로운 전역 기본 키 필드 "_id"를 포함하여 데이터 수정/삭제 및 샤드 라우팅을 가능하게 하고 삭제된 문서를 "새 문서 작성"으로 표시하는 별도의 파일을 사용합니다. 업데이트 작업은 문서에 새 버전 번호를 추가하여 "문서, 삭제된 문서로 표시"로 구현되며, 배포를 실현하는 프로세스는 읽기 및 라우팅을 위해 여러 Lucene 인스턴스를 실행하는 방식으로 지원됩니다. 기본 키 ID에 따라 요청을 작성하고 병합합니다. 쿼리 결과에 대한 정렬, 통계 등 분석을 구현할 수 있는 집계 분석도 추가되었습니다. 구체적인 구현 내용은 아래에서 단일 인스턴스부터 클러스터 순으로 소개하겠습니다.

단일 인스턴스

색인

인덱싱의 목적은 검색 프로세스 속도를 높이는 것입니다. 인덱스 선택은 모든 데이터베이스에서 피할 수 없는 문제입니다. ES 설계의 초기 대상 시나리오는 전체 텍스트 검색이므로 "역 인덱스"를 지원하고 이를 위해 많은 최적화를 수행했습니다. 또한 Block Kd Tree와 같은 다른 인덱스도 지원합니다. ES는 필드 유형에 따라 해당 인덱스 유형을 자동으로 일치시키고 인덱스가 필요한 필드에 대한 인덱스를 구축합니다.

Inverted index와 Block Kd Tree도 분석을 위해 흔히 사용되는 인덱스 유형입니다. 문자열의 경우 두 가지 일반적인 상황이 있습니다. 텍스트는 단어 분할 + 역색인을 사용하고, 키워드는 비단어 분할 + 역색인을 사용합니다. Long/Float와 같은 숫자 유형의 경우 일반적으로 Block Kd Tree가 사용됩니다.

반전된 인덱스

인덱스를 작성할 때 ES는 기본적으로 각 필드를 인덱스합니다. 이 프로세스에는 단어 분할, 의미 처리 및 매핑 테이블 구성이 포함됩니다. 먼저, 텍스트를 단어로 분할합니다. 단어 분할 방법은 영어에서 공백으로 잘라내는 것과 같은 언어와 관련이 있습니다. 그런 다음 의미 없는 단어를 삭제하고 의미 정규화를 수행합니다. 마지막으로 매핑 테이블을 구축합니다. 다음 예에서는 앵커 15의 이름 필드의 처리 과정을 간략하게 보여줍니다. 이 필드는 allen과 sara로 분할되고 소문자 및 기타 작업으로 변환되며 allen->15 및 sara->15의 매핑이 구성됩니다.

// 主播1 { "id": 1 "name":"ada sara" ... // 其他字段 } // 主播15 { "id": 15 "name":"allen sara" }

쿼리 프로세스

"allen sara"라는 앵커에 대한 쿼리를 예로 들면, 단어 분할 결과에 따라 두 개의 목록 [12, 15] 및 [1, 15]가 각각 발견됩니다(실제 응용 프로그램에서도 쿼리는 다음을 기반으로 함). 동의어) 목록과 점수를 병합하려면 누르세요. 우선순위는 결과 [15, 12, 1]을 얻는 것입니다(이것은 검색의 회상 단계이며 알고리즘에 따라 구체화됩니다).

최적화 항목

검색 속도를 높이고 메모리/하드 디스크 부담을 줄이기 위해 ES는 반전된 인덱스에 대해 다음과 같은 최적화를 수행합니다. 이는 다른 구성 요소에 비해 ES의 장점이기도 합니다. 여기서 주목해야 할 점은 저장 공간의 궁극적인 활용은 모든 데이터베이스의 공통 기능일 수 있다는 것입니다. Redis도 같은 방식으로 메모리 공간을 절약합니다. 다양한 방법으로 저장됩니다.

1. 용어 색인: 접두사 트리를 사용하여 "용어" 단어의 위치 지정 속도를 높이고 너무 많은 단어로 인해 검색 속도가 느려지는 문제를 해결합니다.
2. 용어 사전: 접두사가 동일한 단어를 데이터 블록에 넣고 [hello, head] -> [lo, ad]와 같이 접미사만 유지합니다.
3. 게시: 순서 + 증분 코딩 + 블록 저장소(예: [9, 10, 15, 32, 37] -> [9, 1, 5, 17, 5]), 각 요소는 5비트 저장소를 사용할 수 있습니다.
4. 게시 병합 최적화: Roaring Bitmap을 사용하여 공간을 절약하세요. 다중 조건 쿼리를 사용하는 경우 여러 게시를 병합해야 합니다.
5. 의미 처리: 유사한 의미를 가진 콘텐츠를 쿼리할 수 있습니다.

반전 인덱스의 특징:

1. 전체 텍스트 검색 지원: 중국어 전체 텍스트 검색을 구현하는 IK 단어 분할 플러그인과 같은 다양한 단어 분할 플러그인으로 여러 언어를 지원합니다.
2. 작은 인덱스 크기: 접두사 트리는 공간을 크게 압축하며 인덱스를 메모리에 배치하여 검색 속도를 높일 수 있습니다.
3. 범위 검색에 대한 지원 부족: 접두사 트리 선택으로 제한됩니다.
4. 적용 가능한 시나리오: 단어로 검색, 범위가 아닌 검색. 숫자가 아닌 ES 필드는 이 유형의 색인을 사용합니다.

B 잠금 K d 트리 인덱스

블록 Kd 트리 인덱스는 범위 검색에 매우 친숙합니다. ES 값, 지리 및 범위와 같은 필드 유형은 모두 이 인덱스 유형을 사용합니다. 비즈니스 선택 시 범위 검색이 필요한 숫자 필드는 Long과 같은 숫자 유형을 사용해야 합니다. 반전된 색인의 경우 전체 텍스트 검색이 필요하지 않은 필드는 키워드 유형을 사용해야 합니다.

지면의 제약으로 인해 이 글에서는 여기서는 많은 소개를 하지 않겠습니다. BKd Tree에 관심이 있는 친구들은 다음 내용을 참고하세요.

• https://www.shenyanchao.cn/blog/2018/12/04/lucene-bkd/
• https://www.elastic.co/cn/blog/lucene-points-6-0

데이터 저장고

이 부분에서는 주로 단일 인스턴스의 데이터가 메모리와 하드 디스크에 저장되는 방식을 설명합니다.

분할된 스토리지 세그먼트

단일 인스턴스의 데이터는 최대 수백 GB에 이르며 이를 파일에 저장하는 것은 명백히 부적절합니다. 추가 전용 데이터를 저장해야 하는 Kafka, Pulsar 및 기타 구성 요소와 마찬가지로 ES는 저장을 위해 데이터를 세그먼트로 분할하기로 선택합니다.

1. 세그먼트: 각 세그먼트에는 자체 인덱스 파일이 있으며 결과는 병렬 쿼리 후에 병합됩니다.
2. 세그먼트 생성 타이밍: 예약된 생성 또는 파일 크기에 따라 기간은 일반적으로 몇 초로 구성 가능합니다.
3. 세그먼트 병합: 세그먼트는 정기적으로 생성되고 일반적으로 상대적으로 작기 때문에 큰 세그먼트로 병합해야 합니다.

지연 시간 및 데이터 손실 위험

1. 검색 지연: 조건부 검색은 인덱스에 따라 달라지며, 인덱스는 세그먼트가 생성될 때만 사용할 수 있으므로 일반적으로 쓰기에서 검색까지 몇 초의 지연이 있습니다.
2. 데이터 손실 위험: 새로 생성된 세그먼트는 기본적으로 플러시하는 데 수십 분이 걸리며 데이터 손실 위험이 있습니다.
3. 데이터 손실 위험 감소: Translog는 쓰기 이벤트를 기록하는 데 추가로 사용됩니다. 기본적으로 디스크는 5초마다 플러시되지만 여전히 몇 초의 데이터가 손실될 위험이 있습니다.

삭제/업데이트 구현 방법

• 삭제: 각 세그먼트는 삭제된 ID를 기록하는 del 파일에 해당하며 검색 결과를 필터링해야 합니다.
• 업데이트: 새 문서를 작성하고 기존 문서를 삭제합니다.

무리

단일 머신 데이터베이스에는 제한된 용량 및 처리량, 취약한 재해 복구 기능 등의 문제가 있습니다. 이러한 문제는 일반적으로 샤딩 및 데이터 중복성을 통해 해결됩니다. 그러나 이 두 가지 작업에는 일반적으로 다음과 같은 문제가 발생합니다. 먼저 ES 샤드와 데이터 백업 방법을 살펴보고 다음 세 가지 질문을 해결하는 방법을 살펴보겠습니다. 읽기 및 쓰기 요청이 각 샤드로 어떻게 라우팅됩니까? 각 샤드의 검색 결과를 어떻게 병합하나요? 활성 인스턴스와 대기 인스턴스 중에서 마스터를 선택하는 방법은 무엇입니까?

분산 샤드

각 인덱스의 샤드 수는 독립적으로 구성할 수 있습니다. 다음 그림은 샤드가 3개인 인덱스를 예로 들어 수평 확장을 통해 전체 저장 용량을 늘리고, 각 샤드의 병렬 컴퓨팅을 통해 검색 속도를 향상시킵니다.

라우팅 정책은 기본 키를 기반으로 단일 문서를 읽고 씁니다. 해시 라우팅은 기본적으로 ID를 기본 키로 사용합니다. 쓰기 작업의 경우 비즈니스 당사자가 기본 키 ID를 지정하지 않으면 ES는 Guid 알고리즘을 사용하여 자동으로 생성합니다. 라우팅 정책 제한으로 인해 샤드 수를 늘리거나 줄이려면 모든 데이터를 마이그레이션해야 합니다. 조건부 검색을 기반으로 한 검색 요청은 협력자 좌표 및 쿼리 단계 쿼리 단계와 가져오기 단계 획득 단계의 두 단계를 통해 구현됩니다. 협력자는 임의의 인스턴스에 읽기 요청을 보내고, 인스턴스는 각 샤드에 병렬로 요청을 보냅니다. 각 샤드는 로컬 SQL을 실행하고 id와 uid를 포함하여 2000+100개의 데이터를 협력자에게 반환합니다. 협력자는 샤딩된 모든 데이터를 정렬하여 100개의 Document의 ID를 획득한 후, ID별로 데이터를 획득하여 클라이언트에게 반환한다.

단점은 위의 검색 방법이 클라이언트로부터 샤딩 개념을 보호하여 읽기 및 쓰기 작업을 크게 용이하게 한다는 것입니다. 그러나 MySQL과 같은 하위 데이터베이스 및 테이블을 인식할 필요는 없습니다. from+limit 크기의 공간. 깊은 페이지 넘김이 발생하면 공동작업자는 shard*(from+limit) 문서 및 기타 문제를 정렬해야 하므로 많은 공간이 필요합니다.

위의 문제에 대해 실제로는 Search After의 조건 항목에 요청마다 변경되는 uid>2200과 같은 매개변수를 추가하여 다른 형태의 Scroll에 대해 from+limit에서 Limit으로 정렬 횟수를 줄일 수 있습니다. Search After, ES 내부적으로 각 요청의 조건 항목을 유지하고 동시성을 지원합니다.

마스터-슬레이브 동기화 소득

이점에는 주로 데이터 중복성을 통한 고가용성 및 시스템 처리량 증가가 포함됩니다. 데이터 동기화 방법에는 일반적으로 쓰기 작업 속도를 높이기 위해 동일한 지역의 다른 컴퓨터실에 배포되는 클러스터 내의 마스터-슬레이브 동기화가 포함됩니다. 일관성은 단일, 전체 또는 쿼럼 중에서 선택할 수 있습니다. 또한 다중 클러스터 재해 복구 및 서로 다른 지역의 인근 액세스에 사용되는 클러스터 간 동기화(CCR)가 있으며, 인덱스 수준은 단방향 또는 양방향 데이터 복제가 가능합니다. .

적용 가능한 장면

ES의 구현 세부 사항은 ES의 전반적인 특성을 결정하고 이는 적용 가능한 시나리오에 영향을 미칩니다. 적용 가능한 시나리오는 다음과 같습니다. PB 수준 미만의 대용량 데이터, 전체 텍스트 검색, 다중 필드의 유연한 인덱싱 및 정렬 필요, 데이터 시각화(Kibana), 쓰기 후 쿼리 대기 시간에 대한 요구 사항 없음. 그러나 ES를 중요한 데이터의 유일한 저장소로 사용하는 것은 몇 초의 지연과 데이터 손실의 위험이 있기 때문에 권장하지 않으며, MySQL과 달리 고가용성은 모든 세부 사항에 대해 세심하게 최적화되어 있습니다.

생방송 운영 플랫폼을 위한 도메인 간 데이터 수집 시스템 실습

애플리케이션 시나리오

생방송 길드 및 앵커 운영 플랫폼에는 앵커 목록, 앵커 및 길드 작업 등과 같은 데이터 보기 및 분석을 위한 많은 시나리오가 있습니다. 이러한 유형의 데이터는 일반적으로 다음과 같은 특징을 갖습니다. 예를 들어 앵커의 인덱스 필드 수는 200에 가깝고 데이터 소스는 10개 이상(예: 데이터 플랫폼, 보안 플랫폼, 지갑 등)이며 검색 및 정렬과 같은 작업입니다. 여러 필드로 지원됩니다.

사용자가 데이터를 조회할 때 각 거래처로부터 실시간으로 데이터를 얻는 데 많은 시간이 소요되고, 여러 필드를 기반으로 한 조건부 쿼리 및 정렬이 어려우므로 해당 데이터를 사전에 단일 데이터베이스로 집계해야 합니다. . MySQL, Redis 등의 데이터베이스는 위의 특성을 충족하기 어려우며 ES가 이를 더 잘 지원할 수 있습니다. 따라서 우리는 ES 기반의 크로스 도메인 데이터 집계 서비스 시스템을 구축했습니다. 즉, 업스트림 데이터 소스의 변경 사항을 소비하고 이를 쿼리 요구 사항을 충족하는 ES 대형 인덱스입니다. 데이터 집계 모드를 설명하기 위해 "앵커 인덱스"를 예로 들어 보겠습니다.

도전

첫 번째 구현 버전에서는 단일 PSM을 소비자로 사용하여 업스트림 데이터를 읽고 이를 ES에 기록했습니다. 쓰기가 격리되지 않았기 때문에 많은 문제가 있었습니다. 첫째, 모든 접속 당사자는 동일한 PSM에 데이터 소비 로직을 작성하므로 데이터 처리 로직의 결합도가 높아지고 유지 관리가 어려워집니다. 둘째, 여러 비즈니스 당사자가 동일한 필드에 쓸 수 있어 비즈니스 예외가 발생할 수 있는 위험이 있습니다. 또한 풀 커버리지 ES 데이터 쓰기 모드에서는 데이터 처리 속도가 느리고 MQ 소비 속도도 낮습니다. 동시에 특정 업스트림과 연결할 수 없는 리소스 경쟁, 느린 쿼리 등의 문제도 여전히 존재합니다. 격월마다 약 5개의 새로운 필드가 추가되고 데이터가 계속해서 증가하고 있으므로 이러한 문제가 해결되지 않으면 앞으로 더 큰 과제가 발생할 것입니다.

위의 문제에 대한 분석은 세 가지 범주로 나눌 수 있습니다. 각 데이터 소스의 처리 로직은 고도로 결합되어 있으며 전체가 단일 비즈니스 당사자에 의해 쉽게 영향을 받습니다. 데이터 처리 속도가 느리고 리소스 경쟁이 심화됩니다. 거버넌스 기능 쓰기: 쓰기 격리, 느린 쿼리 통계.

해결책

아래 그림은 거버넌스 이후의 전체적인 구조를 소개하고 있으며, 이를 바탕으로 거버넌스 과정에서 직면하게 되는 문제점과 고려사항을 하나씩 분석해보겠습니다.

현재 이 콘텐츠는 Feishu 문서 외부에 표시될 수 없습니다.

문제 1: 각 데이터 소스의 소비 논리는 강력하게 결합되어 유지 관리가 어렵고, 서로 영향을 미치며 리소스를 점유합니다.

이 문제의 구체적인 표현은 동일한 PSM에서 10개가 넘는 MQ 데이터 소비 논리가 구현된다는 것입니다. 공유 데이터 처리 논리와 사소한 변경 사항이 다른 MQ 처리에 영향을 미쳐 서비스가 여러 MQ 이벤트를 모니터링하는 것이 불편해질 수 있습니다. 단일 MQ 이벤트의 리소스 경쟁과 불균등한 파티션 분포는 단일 시스템에서 불균등한 리소스 활용으로 이어지며 이는 시스템의 수평 확장으로는 해결할 수 없습니다. 따라서 단일 MQ의 코드 불안정성은 모든 MQ 주제의 소비에 영향을 미칩니다. 개별 MQ 주제의 파티션 분포가 고르지 않으면 개별 소비자 인스턴스의 CPU가 급증하여 다른 주제의 소비에 영향을 미칩니다.

최적화 전략:

1. 단일 이벤트의 소비 속도 향상: ES 부분 업데이트, 모든 주제의 현재 제한 구성 검토
2. 더 많은 데이터 작성 방법을 구축하고 비핵심 분야의 작성을 다양한 비즈니스 측면에 배포합니다. 예를 들어, 글쓰기 SDK를 제공하고 Dsyncer를 도입합니다.

문제 2: MQ 데이터 소비가 느리고 비즈니스 데이터 업데이트가 지연됩니다.

단일 MQ 메시지 처리에는 시간이 많이 걸립니다. 전체 적용 범위 ES 데이터 쓰기 모드를 예로 들면, 하나의 필드를 업데이트하려면 거의 200개의 필드 데이터를 얻어야 하기 때문에 함께 업데이트할 필요가 없는 나머지 필드를 써야 합니다. RPC를 통해 실시간으로 처리하는 데 시간이 오래 걸리고 일부 MQ 주제는 단일 인스턴스에서 1개의 Worker를 사용합니다. 가장 큰 영향은 데이터 업데이트 지연이 높고, 변경 후 사용자 정보가 다운스트림 플랫폼에 표시되는 데 시간이 걸린다는 것입니다. 그리고 각 업데이트에는 여러 비즈니스 당사자로부터 약 200개의 필드를 가져와야 합니다. 단일 데이터 소스의 이상으로 인해 전체 MQ 이벤트 소비가 실패하고 재시도됩니다.

최적화 전략:

1. ES 클러스터의 데이터 쓰기 모드를 전체 적용 범위에서 부분 업데이트로 변경합니다. 단일 필드는 요청 시 업데이트될 수 있으며 소비자는 더 이상 여러 비즈니스 당사자로부터 거의 200개 필드를 얻을 필요가 없습니다. 이는 데이터 처리 시간을 단축할 뿐만 아니라 코드 유지 관리의 어려움도 줄어듭니다.
2. 여러 작업자를 갖도록 모든 MQ 주제를 구성하고 순차적 소비가 필요한 항목은 기본 키 ID를 기반으로 동일한 작업자로 라우팅되도록 구성됩니다.

문제 3: 글쓰기가 격리/인증/제한되지 않습니다.

필드 쓰기에는 격리 및 인증이 부족하며 여러 비즈니스 당사자가 동일한 필드에 쓸 수 있어 비즈니스 이상이 발생할 수 있는 위험이 있습니다. 주된 이유는 작성 당사자가 리소스를 공유하기 때문입니다. 한 당사자가 너무 빨리 작성하면 다른 당사자의 리소스를 점유하여 작성 지연이 증가하게 됩니다. 따라서 사용자로부터 많은 양의 피드백을 유발하지 않도록 ES 스토리지의 핵심 필드 업데이트를 엄격하게 제어할 필요가 있습니다.

최적화 전략:

1. 필드 수준 쓰기 인증이 추가되어 인증된 PSM만 특정 필드 데이터를 쓸 수 있습니다.
2. PSM과 인덱스라는 두 가지 차원에서 트래픽 제한 전략을 수행하기 위해 일반 트래픽 관리 플랫폼에서 동적으로 구성 가능한 구성 요소가 사용됩니다.

문제 4: 느린 쿼리 통계 및 최적화 방법 부족

MySQL 및 기타 데이터베이스와 마찬가지로 비표준 SQL은 불필요한 스캔과 대규모 쿼리 지연을 초래합니다. ES는 시간이 많이 걸리는 SQL을 쿼리하는 기능을 제공하지만 업스트림 PSM, Logid 및 기타 정보를 연관시킬 수 없으므로 문제 해결이 어렵습니다.

최적화 전략: 읽기 에이전트는 임계값 이상을 차지하는 SQL, 업스트림 PSM, Logid 및 기타 메시지를 중간 계층 형태로 ES에 기록하고 느린 쿼리 조건을 매일 보고합니다.

질문 5: 사용 편의성

최적화 전략:

1. ES 클러스터에서 ES SQL 플러그인을 활성화합니다. ES SQL 구문은 MySQL SQL과 약간 다르기 때문에 읽기 에이전트 서비스를 통해 추가 지원이 제공됩니다. 사용자 측에서는 MySQL 구문을 사용하고 읽기 에이전트에서는 정규식을 사용하여 다시 작성합니다. SQL에서 ES SQL 표준으로, ScrollID를 ES SQL에 삽입하면 사용자 측에서는 스크롤 쿼리를 SQL로 표현하는 방법에 대해 신경 쓸 필요가 없습니다.
2. 사용자가 쿼리 데이터를 구조로 역직렬화하도록 돕습니다.

// es dsl查询样例 GET twitter/_search { "size": 10, "query": { "match" : { "title" : "Elasticsearch" } }, "sort": [ {"date": "asc"} ] } // 使用读sdk的等价sql select * from twitter where title="Elasticsearch" order by date asc limit 10

거버넌스 결과

위의 거버넌스를 통해 쓰기 링크의 누적이 완전히 제거되고 소비 용량이 150% 증가했습니다. 이는 시스템 성능 상한선에 도달하지 않고 비즈니스의 QPS를 4k에서 10k로 늘리는 데 구체적으로 반영됩니다. 피크 판독 QPS는 1500이고, SLA는 장기적으로 99.99%로 안정적입니다. 현재 다수의 사업자들이 SDK를 사용하고 있으며, 사업자들은 접속 시간이 원래 2일에서 0.5일로 단축되었다고 보고했습니다.

후속 계획

후속 계획에는 주로 개별 시나리오에서 모든 시나리오로 MVP 조정 기능을 확장하고, 느린 쿼리 통계를 기반으로 SQL의 업스트림 비즈니스 최적화를 촉진하고, FaaS와 같은 더 많은 데이터 쓰기 방법을 제공하는 것이 포함됩니다.

 

---

ByteDance 내부의 대규모 모범 사례 경험을 바탕으로 Volcano Engine은 외부적으로 일관된 ES 제품 , 즉 클라우드 검색 서비스 엔터프라이즈급 클라우드 제품을 제공합니다. 클라우드 검색 서비스는 Elasticsearch, Kibana 및 기타 소프트웨어와 일반적으로 사용되는 오픈 소스 플러그인과 호환됩니다. 다중 조건 검색, 통계, 구조화된 텍스트와 구조화되지 않은 텍스트에 대한 보고서를 제공하며 원클릭 배포, 탄력적인 확장, 운영 및 유지 관리를 단순화하고 로그 분석, 정보 검색 및 분석 및 기타 비즈니스 기능을 신속하게 구축합니다.

 

동료 치킨 "오픈 소스" deepin-IDE 및 마침내 부트스트랩을 달성했습니다! 좋은 친구, Tencent는 Switch를 "생각하는 학습 기계"로 전환했습니다. Tencent Cloud의 4월 8일 실패 검토 및 상황 설명 RustDesk 원격 데스크톱 시작 재구성 웹 클라이언트 WeChat의 SQLite 기반 오픈 소스 터미널 데이터베이스 WCDB의 주요 업그레이드 TIOBE 4월 목록: PHP 사상 최저치로 떨어졌고 FFmpeg의 아버지인 Fabrice Bellard는 오디오 압축 도구인 TSAC를 출시했으며 Google은 대규모 코드 모델인 CodeGemma를 출시했습니다 . 오픈소스라서 너무 좋아요 - 오픈소스 사진 및 포스터 편집기 도구

{{o.이름}}

{{이름}}