사용 사례 : InfluxDB 대 Prometheus

사용 사례 : InfluxDB 대 Prometheus

---

다음 프로 메테우스를 웹 페이지 프로 메테우스와 InfluxDB 사이에 하나의 주요 차이점은 유스 케이스입니다 : 프로 메테우스 저장 시간 시리즈 전용 InfluxDB 더 나은 개별 이벤트를 저장 맞된다. InfluxDB의 스토리지 엔진에 대한 몇 가지 주요 작업이 있었기 때문에 이것이 여전히 사실인지 궁금합니다.

시계열 데이터베이스를 설정하고 싶습니다. 푸시 / 푸시 모델 (및 성능 차이)과는 별도로 두 프로젝트를 구분하는 큰 것은 없습니다. 누군가 사용 사례의 차이점을 설명 할 수 있습니까?

---

InfluxDB CEO 및 개발자는 여기에 있습니다. 다음 버전의 InfluxDB (0.9.5)에는 새로운 스토리지 엔진이 있습니다. 이 엔진을 사용하면 단일 이벤트 데이터 또는 정기적으로 샘플링 된 시리즈를 효율적으로 저장할 수 있습니다. 즉 불규칙하고 규칙적인 시계열.

InfluxDB는 각각 다른 압축 체계를 사용하여 int64, float64, bool 및 string 데이터 유형을 지원합니다. Prometheus는 float64 만 지원합니다.

압축의 경우 0.9.5 버전은 Prometheus와 압축 경쟁력이 있습니다. 어떤 경우에는 우리가 보는 것에 따라 타임 스탬프의 압축을 변경하기 때문에 더 나은 결과를 볼 수 있습니다. 최상의 시나리오는 정확한 간격으로 샘플링 된 정규 시리즈입니다. 기본적으로 1k 포인트 타임 스탬프를 8 바이트 시작 시간, 델타 (지그재그 인코딩) 및 카운트 (지그재그 인코딩)로 압축 할 수 있습니다.

데이터의 형태에 따라 압축 후 포인트 당 평균 2.5 바이트 미만을 보았습니다.

타임 스탬프, 데이터 유형 및 데이터 모양을 기반으로 한 YMMV. 예를 들어, 가변 델타가 큰 나노초 스케일 타임 스탬프가있는 임의의 부동 소수점은 최악입니다.

타임 스탬프의 가변 정밀도는 InfluxDB의 또 다른 기능입니다. 초, 밀리 초, 마이크로 초 또는 나노초 스케일 시간을 나타낼 수 있습니다. Prometheus는 밀리 초로 고정됩니다.

또 다른 차이점은 InfluxDB에 대한 쓰기는 성공 응답이 클라이언트에 전송 된 후에도 지속된다는 것입니다. Prometheus 버퍼는 메모리에 기록하고 기본적으로 5 분마다 플러시하므로 잠재적 인 데이터 손실 창이 열립니다.

0.9.5의 InfluxDB가 출시되면 Prometheus 사용자가 Prometheus와 함께 장기 메트릭 저장소로 사용하는 것이 좋은 선택이되기를 바랍니다. Prometheus에 이미 지원이 있다고 확신하지만 0.9.5 릴리스가 떨어질 때까지 약간 불안정 할 수 있습니다. 분명히 우리는 함께 일하고 많은 테스트를해야하지만 그것이 내가 바라는 바입니다.

단일 서버 메트릭 수집의 경우 Prometheus가 더 제한적인 데이터 모델과 인덱스를 쓰기 전에 디스크에 쓰기를 추가하지 않기 때문에 더 나은 성능을 기대합니다 (여기서는 테스트를 수행하지 않았고 숫자도 없음). .

둘 사이의 쿼리 언어는 매우 다릅니다. 나는 그들이 우리가 아직 지원하지 않거나 그 반대의 경우 무엇을 지원하는지 확신하지 못하므로 둘 다에 대한 문서를 파헤쳐 필요한 것이 있는지 확인해야합니다. 장기적으로 우리의 목표는 InfluxDB의 쿼리 기능이 Graphite, RRD, Prometheus 및 기타 시계열 솔루션의 상위 집합이되도록하는 것입니다. 나중에 더 많은 분석 기능에 추가하여 다루고 싶기 때문에 수퍼 세트라고합니다. 거기에 도착하려면 분명히 시간이 걸릴 것입니다.

마지막으로 InfluxDB의 장기적인 목표는 클러스터링을 통해 고 가용성 및 수평 확장 성을 지원하는 것입니다. 현재 클러스터링 구현은 아직 기능이 완전하지 않으며 알파 버전입니다. 그러나 우리는 그것에 대해 작업하고 있으며 프로젝트의 핵심 디자인 목표입니다. 우리의 클러스터링 설계는 데이터가 최종적으로 일관성이 있다는 것입니다.

내가 아는 한 Prometheus의 접근 방식은 HA에 이중 쓰기를 사용하고 (따라서 최종 일관성 보장이 없음) 수평 확장 성을 위해 페더레이션을 사용하는 것입니다. 페더레이션 된 서버에서 쿼리가 어떻게 작동하는지 잘 모르겠습니다.

InfluxDB 클러스터 내에서 네트워크를 통해 모든 데이터를 복사하지 않고도 서버 경계를 넘어 쿼리 할 수 ​​있습니다. 각 쿼리는 즉석에서 실행되는 일종의 MapReduce 작업으로 분해되기 때문입니다.

아마 더 많을 것 같지만 그게 제가 지금 생각할 수있는 것입니다.

---

다른 답변에는 두 회사의 마케팅 메시지가 있습니다. 이제 그것을 무시하고 시간 데이터 시리즈의 슬픈 현실 세계로 돌아 갑시다.

일부 역사

InfluxDB와 prometheus는 과거 시대의 오래된 도구 (RRDtool, graphite)를 대체하기 위해 만들어졌습니다.

InfluxDB는 시계열 데이터베이스입니다. Prometheus는 일종의 메트릭 수집 및 경고 도구이며이를 위해 작성된 스토리지 엔진이 있습니다. (실제로 스토리지 엔진을 다른 용도로 재사용 할 수 있는지 여부를 잘 모르겠습니다.)

한계

안타깝게도 데이터베이스 작성은 매우 복잡한 작업입니다. 이 두 도구가 무언가를 제공하는 유일한 방법은 고 가용성 및 클러스터링과 관련된 모든 어려운 기능을 삭제하는 것입니다.

솔직히 말하면 단일 노드 만 실행하는 단일 애플리케이션입니다.

Prometheus는 클러스터링과 복제를 지원할 목표가 없습니다 . 장애 조치를 지원하는 공식적인 방법은 " 2 개 노드를 실행하고 두 노드 모두에 데이터를 전송 "하는 것입니다. 아야. (진지하게 가능한 유일한 현존하는 방법이며 공식 문서에 무수히 쓰여 있습니다.)

InfluxDB 는 3 월에 공식적으로 폐기 될 때까지 수년간 클러스터링에 대해 이야기 해 왔습니다. InfluxDB에 대한 클러스터링은 더 이상 테이블에 없습니다 . 그냥 잊어 버려. 완료되면 (그렇다고 가정 할 경우) Enterprise Edition에서만 사용할 수 있습니다.

https://influxdata.com/blog/update-on-influxdb-clustering-high-availability-and-monetization/

향후 몇 년 내에 복제, 장애 조치, 데이터 안전, 확장 성, 백업 등 데이터베이스와 관련된 모든 어려운 문제를 처리하는 잘 설계된 시계열 데이터베이스를 갖게되기를 바랍니다.

현재로서는 총알이 없습니다.

해야 할 일

예상되는 데이터의 양을 평가하십시오.

100 개의 메트릭 * 100 개의 소스 * 1 초 => 초당 10000 개의 데이터 포인트 => 하루에 864 개의 메가 데이터 포인트.

시계열 데이터베이스의 좋은 점은 압축 형식을 사용하고 잘 압축하고 데이터 포인트를 집계하며 오래된 데이터를 정리한다는 것입니다. (또한 시계열과 관련된 기능이 제공됩니다.)

데이터 포인트가 4 바이트로 취급된다고 가정하면 하루에 몇 기가 바이트에 불과합니다. 운 좋게도 10 개의 코어와 10TB 드라이브를 즉시 사용할 수있는 시스템이 있습니다. 아마도 단일 노드에서 실행될 수 있습니다.

대안은 클래식 NoSQL 데이터베이스 (Cassandra, ElasticSearch 또는 Riak)를 사용한 다음 애플리케이션에서 누락 된 비트를 엔지니어링하는 것입니다. 이러한 데이터베이스는 이러한 종류의 저장소에 최적화되지 않을 수 있습니다 (또는 최신 데이터베이스는 너무 복잡하고 최적화되어 벤치 마크하지 않는 한 확실하지 않습니다).

응용 프로그램에 필요한 용량을 평가해야합니다 . 이러한 다양한 데이터베이스로 개념 증명을 작성하고 사물을 측정합니다.

InfluxDB의 한계에 해당하는지 확인하십시오. 그렇다면 아마도 최선의 방법 일 것입니다. 그렇지 않다면 다른 것 위에 자신 만의 솔루션을 만들어야합니다.

---

InfluxDB simply cannot hold production load (metrics) from 1000 servers. It has some real problems with data ingestion and ends up stalled/hanged and unusable. We tried to use it for a while but once data amount reached some critical level it could not be used anymore. No memory or cpu upgrades helped. Therefore our experience is definitely avoid it, it's not mature product and has serious architectural design problems. And I am not even talking about sudden shift to commercial by Influx.

Next we researched Prometheus and while it required to rewrite queries it now ingests 4 times more metrics without any problems whatsoever compared to what we tried to feed to Influx. And all that load is handled by single Prometheus server, it's fast, reliable, and dependable. This is our experience running huge international internet shop under pretty heavy load.

---

IIRC current Prometheus implementation is designed around all the data fitting on a single server. If you have gigantic quantities of data, it may not all fit in Prometheus.

참고URL : https://stackoverflow.com/questions/33350314/usecases-influxdb-vs-prometheus