Apache Doris vs Elasticsearch : 비교 분석
Big Data Analytics 분야에서 Apache Doris와 Elasticsearch (ES)는 실시간 분석 및 검색 작업에 자주 사용됩니다. 그러나 그들의 디자인 철학과 기술 초점은 크게 다릅니다.
이 기사는 핵심 아키텍처, 쿼리 언어, 실시간 기능, 응용 프로그램 시나리오, 성능 및 엔터프라이즈 관행의 6 가지 차원에서 상세한 비교를 제공합니다.
1. 핵심 설계 철학 : MPP 아키텍처 대 검색 엔진 아키텍처
Apache Doris는 전형적인 MPP (대규모 병렬 처리) 분산 아키텍처를 사용하며, 대기 시간이 낮은 실시간 실시간 온라인 분석 프로세싱 (OLAP) 시나리오에 맞게 조정되었습니다. 대규모 데이터 세트를 효율적으로 관리하기 위해 다중 노드 병렬 컴퓨팅 및 원주 스토리지를 활용하여 프론트 엔드 및 백엔드 구성 요소로 구성됩니다. 이 디자인을 통해 Doris는 쿼리 결과를 초에 전달할 수 있으므로 대형 데이터 세트의 복잡한 집계 및 분석 쿼리에 이상적입니다.
대조적으로, Elasticsearch는 신속한 텍스트 검색 및 필터링을 우선시하는 샤딩 및 역 색인 디자인을 사용하여 전체 텍스트 검색 엔진 아키텍처를 기반으로합니다. ES는 데이터를 문서로 저장하고 각 필드는 역 색인을 통해 색인되어 키워드 검색 및 로그 쿼리가 뛰어납니다. 그러나 복잡한 분석 및 대규모 집계 계산으로 어려움을 겪고 있습니다.
핵심 아키텍처 차이는 다음과 같습니다.
건축 철학 |
Apache Doris (MPP 분석 데이터베이스) |
Elasticsearch (분산 검색 엔진) |
---|---|---|
디자인 의도 |
실시간 데이터웨어 하우징/BI를 대상으로, 고 처리량 병렬 컴퓨팅 OLAP 엔진을 지원합니다. 강조합니다 고음용 집계 쿼리 그리고 낮은 대기 시간 |
Lucene의 반전 인덱스에 구축 된 전체 텍스트 검색/로그 검색에 중점을 두었습니다. 탁월합니다 키워드 검색 그리고 필터링, 주로 구조화 된 쿼리 지원에도 불구하고 검색 엔진 |
데이터 저장 |
원주 저장 컬럼 인코딩 압축을 사용하여 공간을 절약하기 위해 높은 압축 비율 (5-10 ×)을 달성합니다. 쓰기 중에 사전 응집으로 여러 테이블 모델 (중복, 집계, 고유)을 지원합니다. |
문서 저장 필드 당 역 지수 (낮은 압축 비율, ~ 1.5 x); 스키마 변경은 인덱스 이후 생성에 어려움을 겪고 있으며, 현장 추가 또는 수정을 위해 다시 표시해야합니다. |
확장 성과 탄력성 |
쉬운 선형 스케일링을위한 공유되지 않은 노드 설계; 엄격한 읽기 쓰기 분리 및 다중 테넌트 분리를 지원합니다. 버전 3.0 소개 저장 담보 분리 탄성 스케일링의 경우 |
샤드 복제품을 통한 스케일이지만 단일 노드 메모리 및 JVM GC 한계에 의해 제한되며, 큰 쿼리 중에 메모리 부족이 위험에 처해 있습니다. 스레드 풀 모델은 제한된 분리를 제공합니다 |
일반적인 기능 |
완전 오픈 소스 (Apache 2.0), MySQL 프로토콜 호환; 외부 의존성, 제안 구체화 된 견해 향상된 분석을위한 풍부한 SQL 기능 |
Elastic (시간이 지남에 따라 라이센스 변경)에 의해 개발 된 핵심은 기본적으로 지원합니다. 전체 텍스트 검색 그리고 거의 실시간 인덱싱; 풍부한 생태계 (Kibana, Logstash), 유료 플러그인이 필요한 일부 고급 기능 |
분석: Doris의 MPP 아키텍처는 빅 데이터 집계 분석에서 자연스러운 에지를 제공하여 원주민 저장 및 벡터 실행을 활용하여 IO 및 CPU 사용을 최적화합니다. 사전 응집, 구체화 된 뷰 및 확장 가능한 디자인과 같은 기능으로 인해 대규모 데이터 분석에서 ES를 능가합니다.
반대로, Elasticsearch의 검색 엔진 뿌리는 인스턴트 검색 및 기본 메트릭에 우수하지만 복잡한 SQL 분석에 빠지고 합류합니다. Doris는 또한 더 큰 스키마 유연성을 제공하여 실시간 열/인덱스 수정을 허용하는 반면 ES의 고정 스키마에는 종종 비용이 많이 드는 다시 표시가 필요합니다.
전반적으로 Doris는 분석력과 유용성을 강조하는 반면 ES는 검색을 우선시하여 Doris가 복잡한 엔터프라이즈 분석에서 이점을 제공합니다.
2. 쿼리 언어 : SQL vs. DSL 사용 편의성 및 표현성
Doris와 ES는 쿼리 인터페이스에서 급격히 분기됩니다. Doris는 표준 SQL을 기본적으로 지원하는 반면 Elasticsearch는 JSON DSL (도메인 별 언어)을 사용합니다. Doris는 MySQL 프로토콜과 일치하며 Select, Where, Group By, Order, Multi-Table 조인, 하위 쿼리, 창 함수, UDFS/UDAF 및 구체화 된 뷰와 같은 강력한 SQL 92 기능을 제공합니다. 이 포괄적 인 SQL 지원을 통해 분석가와 엔지니어는 새로운 언어를 배우지 않고 친숙한 구문을 사용하여 복잡한 쿼리를 수행 할 수 있습니다.
그러나 Elasticsearch는 SQL과 구별되는 독점적 인 JSON 기반 DSL을 사용하여 필터링 및 집계를 위해 중첩 된 구조가 필요합니다. 이는 새로운 사용자에게 가파른 학습 곡선을 제시하고 기존 BI 도구와의 통합을 복잡하게합니다.
비교는 다음과 같습니다.
쿼리 언어 |
Apache Doris (SQL 인터페이스) |
Elasticsearch (JSON DSL) |
---|---|---|
구문 스타일 |
표준 SQL (MySQL 유사), 직관적이고 읽기 쉬운 |
독점적 인 DSL (JSON), 중첩되고 덜 직관적입니다 |
표현력 |
복잡한 논리를위한 다중 테이블 조인, 하위 쿼리, 뷰, UDF를 지원합니다. 직접 연관성 분석을 활성화합니다 |
단일 인덱스 쿼리로 제한되며 원시 조인 또는 하위 쿼리가 없습니다. 복잡한 분석에는 사전 처리 된 데이터 모델이 필요합니다 |
학습 비용 |
SQL은 널리 알려져 있고 낮은 진입 장벽입니다. 성숙한 디버깅 도구를 사용할 수 있습니다 |
DSL은 맞춤형, 높은 학습 임계 값입니다. 오류 문제 해결은 어려운 일입니다 |
생태계 통합 |
MySQL 프로토콜 호환성, BI 도구 (예 : Tableau, Grafana)와 완벽하게 통합 |
플러그인없이 BI 도구와 통합하기 어려운 폐쇄 생태계; 키바나는 기본 시각화를 제공합니다 |
분석: Doris의 SQL 인터페이스는 유용성과 효율성이 탁월하여 친숙한 구문을 활용하여 항목 임계 값을 낮 춥니 다. 예를 들어, DORIS에서 여러 차원으로 로그 데이터를 집계하려면 간단한 SQL 그룹이 필요하지만 ES는 복잡한 중첩 된 DSL 응집체를 요구하여 개발 효율을 줄입니다.
Doris의 조인 및 하위 쿼리에 대한 지원은 데이터웨어 하우스 모델링 (예 : Star Schemas)에 적합하지만 ES의 조인 부족은 사전 정규화 된 데이터 또는 응용 프로그램 계층 처리가 필요합니다. 따라서 Doris는 쿼리의 용이성과 힘을 능가하여 분석 생태계와의 통합을 향상시킵니다.
3. 실시간 데이터 처리 메커니즘 : 구조 및 데이터 업데이트 작성
Doris와 ES는 실시간 데이터 수집 및 쿼리에 대한 뚜렷한 접근 방식을 채택합니다. Elasticsearch는 문서 별 문서 별 기록 및 빈번한 인덱스 새로 고침으로 거의 실시간 검색을 우선시합니다. 데이터는 REST API (예 : 대량)를 통해 섭취하고 토큰 화 및 인덱싱되어 주기적으로 새로 고침 후 검색 가능합니다 (기본값 : 1 초). 이를 통해 빠른 로그 검색을 보장하지만 CPU 집약적 인덱싱은 단일 코어 처리량을 ~ 2MB/s로 제한하여 종종 피크 동안 병목 현상을 유발합니다.
Apache Doris는 반대로 높은 처리량 배치 쓰기 아키텍처를 사용합니다. 데이터는 작은 배치 (Kafka와 같은 대기열의 스트림 부하 또는 일상적인로드를 통해)로 가져 오는데, 여러 복제본에서 주름 형식으로 효율적으로 작성됩니다. 필드 당 인덱싱을 피하면서 Doris는 ES 랠리 벤치 마크 당 ES보다 5 배 높은 속도를 달성하고 파이프 라인을 단순화하는 직접 대기열 통합을 지원합니다.
업데이트 및 실시간 기능의 주요 차이점에는 다음이 포함됩니다.
-
스토리지 메커니즘: Doris의 Collect Storage는 동일한 데이터를 위해 ES의 ~ 20%를 사용하여 5 : 1 ~ 10 : 1 압축을 달성하여 IO 효율을 향상시킵니다. ES의 반전 인덱스는 스토리지가 팽창하여 ~ 1.5 : 1 압축 비율을 산출합니다.
-
데이터 업데이트: Doris의 고유 한 키 모델은 최소한의 성능 손실로 기본 키 업데이트를 지원합니다 (
쿼리 가시성: ES는 즉시 로그 검색에 이상적으로 재림 후 두 번째 수준의 가시성을 제공합니다. Doris는 대부분의 실시간 분석에 충분한 배치 가져 오기를 통해 하위 1 차 가시성을 달성하며 메모리-완충 데이터는 적시에 쿼리 액세스를 보장합니다.
분석: Doris는 고 처리량이 많고 일관된 분석을 통해 탁월한 반면 ES는 밀리 초 쓰기 및 거의 실시간 검색에 중점을 둡니다. Doris의 배치는 쓰기 성능 (5x), 쿼리 속도 (2.3x) 및 스토리지 효율 (1/5 위)에서 ES를 능가하고 압축을 능가하여 고주파 쓰기 및 빠른 분석에 이상적이며 유연한 스키마 진화는 실시간 기능을 향상시킵니다.
4. 일반적인 응용 시나리오 비교 : 로그 분석, BI보고 등
Doris와 Es는 건축 강점으로 인해 다양한 시나리오에서 빛을 발합니다.
대본
아파치 도리스
Elasticsearch
로그 분석
큰 로그의 저장 및 다차원 분석에서 탁월합니다. 장기 보존 및 빠른 집계/조인을 지원합니다. 기업 보고서
10 배 더 빠른 분석 및 60% 비용 절감, 반전 인덱스 지원과 검색 및 분석을 통합
실시간 로그 검색 및 간단한 통계에 이상적입니다. 빠른 키워드 검색은 모니터링 및 문제 해결 (예 : ELK)입니다. 비용 및 성능 제한으로 인한 복잡한 집계 및 장기 분석으로 어려움
BI보고
대화식보고 및 임시 분석에 적합합니다. 전체 SQL 및 조인 데이터웨어 하우징 및 대시 보드를 지원합니다. 물류 회사는 5-10 배 빠른 쿼리와 2 배 동시성을 보았습니다.
BI에는 거의 사용되지 않습니다. 조인 및 강력한 SQL이 부족하여 복잡한보고를 제한합니다. 풍부한 BI 논리가 아닌 모니터링의 간단한 메트릭에 가장 적합합니다.
분석 : 로그 분석에서 Doris와 ES는 서로를 보완합니다. ES는 실시간 검색을 처리하고 Doris는 장기적이고 복잡한 분석을 관리합니다. BI의 경우 Doris의 SQL 및 성능은 훨씬 우수하며 엔터프라이즈 데이터웨어 하우스 및보고를 직접 지원합니다.
5. 성능 벤치 마크 비교
ES Rally Benchmarks는 Doris의 가장자리를 강조합니다.
-
로그 분석: Elasticsearch vs Apache Doris -Apache Doris
-
성능 비교: 쓰기 처리량, 스토리지, 쿼리 응답 시간
Doris는 550MB/s 쓰기 속도 (5x ES)를 달성하고 스토리지의 1/5를 사용하며 2.3 배 빠른 쿼리 (예 : 40m 로그 집계의 경우 1S 대 6-7S)를 제공합니다. MPP 아키텍처는 메모리 제한으로 어려움을 겪는 ES와 달리 높은 동시성에서 안정성을 보장합니다.
6. 엔터프라이즈 실무 사례
-
360 보안 브라우저: ES를 Doris로 대체하여 분석 속도를 10 배, 저장 비용 절감 60%.
-
Tencent 음악: 스토리지가 80% (697GB ~ 195GB) 감소하고 Doris와 함께 4 배를 늘 렸습니다.
-
큰 은행: 로그 분석 효율이 향상되어 중복성을 제거합니다.
-
지불 회사: 4 배의 쓰기 속도, 3 배 쿼리 성능 및 50% 저장 저장을 달성했습니다.
이 사례는 대규모 저술과 복잡한 쿼리에서 Doris의 우월성을 강조하며, 종종 ES의 검색 강점을 보완합니다.
요약
Doris는 복잡한 분석, SQL 유용성 및 효율성에 탁월하며 통합 실시간 플랫폼에 이상적이며 ES는 전체 텍스트 검색 및 실시간 쿼리를 지배합니다. 기업은 분석을위한 도리, 검색을위한 ES를 결합하여 가치를 극대화 할 수 있으며, Doris는 지능형 검색에서 분석과 ES를 확장 할 준비가되어 있습니다.
Post Comment