Kapasite planlama

Name: Orbtrace
Brand: Orbtrace
Availability: InStock

Dağıtımı yükünüze göre boyutlandırın — hesaplayıcıya günlük hacminizi, saklama sürenizi ve servis sayınızı girin; Helm boyutunu, Doris FE/BE sayısını, vCPU, bellek ve disk ihtiyacını alın. Apache Doris'in yayınlanmış dağıtım rehberine dayanır.

Orbtrace ne kadar donanım ister? Üç şeye bağlıdır: günde ne kadar telemetri gönderdiğiniz, ne kadar süre sakladığınız ve kaç servis çalıştırdığınız. Bu değerleri aşağıya girin; hesaplayıcı bir önerilen başlangıç yapılandırması döndürür — Helm boyutu, Doris FE/BE düğüm sayısı, toplam vCPU ve bellek, ayrılacak disk — ve dağıtımınıza doğrudan yapıştırabileceğiniz bir my-values.yaml eklentisi.

Önerilen başlangıç yapılandırması

Helm boyutu: mediumDoris profili: customrahatSoğuk katman: Gerekmez

Küme topolojisi

Doris FE

Doris BE

60 TiB BE başına

Orbtrace app

Toplam ayak izi

Pod / örnek

Sıcak disk (toplam) (TiB)

292.5

Blok depolama (toplam) (TiB)

300.2

PostgreSQL diski (GiB)

CPU ve bellek pod başınadır — her bileşenin Helm resources değerine birebir budur. Her hücre request → limit okunur: request Kubernetes'in rezerve ettiği (ve yerleşim kararını verdiği) miktar, limit ise üst tavandır (CPU'da throttle edilir, bellekte OOM ile öldürülür). O bileşenin toplamı için Adet ile çarpın; tüm kümenin toplamı aşağıdadır.

Bileşen	Adet	vCPU/pod (istek → limit)	Bellek/pod GiB (istek → limit)
Orbtrace app	3	1 → 3	2 → 6
Doris FE	3	1 → 2	8 → 16
Doris BE	5	4 → 8	8 → 16
PostgreSQL	1	0.5 → 2	1 → 2
Valkey	1	0.25 → 1	0.25 → 1

Küme toplam işlem gücü: 26.8–58 vCPU · 71.3–149 GiB (istek → limit)

Kurulumunuz için notlar

BE başına sıcak disk ~60 TiB çıkıyor. Bu çok büyük bir PVC — BE düğümü eklemeyi veya eski veriyi soğuk (S3) katmana taşımayı değerlendirin.

Helm values eklentisi

Bunları eşleşen ön ayarın üstüne values.yaml dosyanıza koyun, sonra canlı telemetriye göre ayarlayın.

# values-overlay.yaml — start from values-medium.yaml
orbtrace:
  replicaCount: 3
doris:
  profile:
    activeProfile: custom
    custom:
      base: small          # extend retention on a small/medium footprint
  fe:
    replicaCount: 3
  be:
    replicaCount: 5
    storagePvc:
      size: 60Ti
postgres:
  pvc:
    size: 50Gi

Kaba hesap, ±%25–50 doğrulukta. Doris temelli (tablet ≤ 20K replika/BE, 1–10 GB tablet, HA için ≥ 3 FE). İlk operasyon haftasında gerçek telemetriyle kalibre edin. · 7.384 tablets · 14.768 replicas @ RF2

Bunlar başlangıç noktasıdır, garanti değil

Çıktı yaklaşık ±%25–50 doğrulukta — donanım almak ve bir küme açmak için yeterli, ama kendi iş yükünüzü ölçmenin yerine geçmez. Orbtrace, boyutun tutup tutmadığını ilk operasyon haftasında söyleyen iki monitör (CardinalityMonitor, TombstoneMonitor) ile gelir; bunlara göre yeniden kalibre edin. Sayılar bilinçli olarak temkinlidir.

Girdiler ne anlama geliyor

On screen

Günlük veriGünde toplam log + iz + metrik, gzip açılmış, OpenTelemetry Collector çıkışında ölçülür — uygulamanın yayın tarafında değil. Yalnızca sıkıştırılmış hat hacmini biliyorsanız kabaca sıkıştırma oranlarıyla çarpın (loglar 8–12×, izler 4–6×, metrikler 3–5×).
ServislerFarklı service.name değerleri. Hacimden bağımsızdır — 5 TB/gün'de 50 servis ile 50 GB/gün'de 5000 servis ikisi de geçerlidir ve farklı boyutlanır. Düğüm sayısından çok kardinalite monitör kalibrasyonunu etkiler.
Sıcak saklamaHızlı BE diskinde, sık sorgulanan veri günü. Disk maliyetinin ve Doris tablet sayısının en büyük kaldıracıdır.
Soğuk saklamaS3 uyumlu nesne deposunda park edilen ek gün. Yalnızca-sıcak için 0 yapın. ~30 günden sonra soğuk katman çok sayıda pahalı blok depolamadan tasarruf ettirir.

CPU ve bellek pod başınadır; yalnızca depolama toplanır

Bileşen bazında dağılım tablosu CPU ve belleği pod başına listeler — her bileşenin Helm resources.requests / resources.limits değerine birebir budur. O bileşenin toplamı için Adet sütunuyla çarpın; küme toplam işlem gücü tablonun hemen altındadır. Toplam ayak izi kartları yalnızca küme genelinde anlamlı olanı toplar: pod sayısı ve depolama (bir app pod'u ile bir BE pod'unu tek bir "vCPU" değerinde toplamak yanıltıcı olurdu, o yüzden tek sayı olarak gösterilmez).

Hesaplayıcı Apache Doris'e nasıl dayanıyor

Orbtrace telemetriyi Apache Doris içinde saklar ve boyutlandırma matematiği tahmin yerine Doris'in kendi yayınlanmış dağıtım rehberini izler:

Düğüm şekilleri Doris'in donanım tabanından başlar — FE ve BE açılmak için en az 4 vCPU / 8 GiB ister ve üretim kümeleri düğüm başına 16 vCPU / 64 GiB önerilir (Cluster planning). Gönderilen values-large.yaml BE'si (8–16 vCPU / 32–64 GiB) tam bu banttadır.
FE sayısı. Doris, yüksek erişilebilir bir Raft çoğunluğu için en az 3 FE önerir ve bir FE'nin rahatça 10–20 BE yönettiğini belirtir — yani FE sayısı BE'den çok daha yavaş büyür.
BE sayısı tabanı yalnızca disk değil, bir tablet-sayısı bütçesidir. Tablet meta verisi FE belleğinde durur; bu yüzden Doris rehberi BE başına tablet replikasını birkaç on binde tutmaktır. Orbtrace < 20.000 replika/BE tavanına göre planlar. Hesaplayıcı, oturmuş tablet sayısını saklamanız × profilin bucket sayıları ve bölüm kadansından hesaplar (small/medium profilleri ham tabloları DAY, large profili HOUR ile bölümler — tablet ve bucket tasarımı), sonra bu tavana böler. Bu yüzden yüksek hacimli bir küme, yalnızca diskin gerektireceğinden daha çok BE isteyebilir — ve hesaplayıcı bu olduğunda uyarır.
Tablet boyutu. Doris'in en iyi pratiği her tableti 1–10 GB bandında ve bucket sayılarını BE sayısının katı tutar. Orbtrace'in gönderilen bucket sayıları (small 16, large 128) tabletlerin her katmanın hedef hacminde bu banda düşmesi için seçilmiştir.

Disk, replikasyon ve soğuk-katman kuralları, bu Doris rehberinin üstüne kurulu Orbtrace'in kendi kapasite-planlama çerçevesinden gelir.

Formüller

Yukarıdaki her sayı kaba hesaptır ve elle doğrulanabilir.

Sıcak disk

sicak_disk_TiB = gunluk_veri_TiB
               × sicak_saklama_gun
               × replikasyon_faktoru   (varsayılan 2; bir BE kaybına dayanır)
               × 1.5                    (sıkıştırma çalışma kümesi)
               × sikistirma_orani        (temkinli 0.5; 0.3 yalnızca oturmuş büyük tablolarda)
               × 1.3                     (veri patlaması + sıkıştırma payı)
be_basina_PVC  = sicak_disk_TiB / BE_sayisi

Sıkıştırma oranı en riskli girdidir — ölçün

Çerçeve varsayılanı, sık alıntılanan 0.3 değil, 0.5'tir (≈2:1). Gerçek bir OTel-Demo verisinde ölçülen tek-replika oranı küçük hacimde yalnızca ~2:1'di — tablolar büyüyüp sıkıştırma oturana kadar sabit kolon başına ters-indeks yükü baskındır. Diski 0.5 ile boyutlandırın, 0.3'e ancak oranı sürekli hacimde kendi verinizde ölçtükten sonra geçin (SHOW DATA FROM <db>.otel_traces ÷ yüklenen bayt ÷ replikasyon).

Tablet sayısı → minimum BE

tablet    = Σ tablolar üzerinde ( canlı_bölüm × bucket )
            canlı_bölüm = saklama_gun × (HOUR için 24, DAY için 1)
replika   = tablet × replikasyon_faktoru
min_BE    = ceil( replika / 20.000 )
BE_sayisi = max( onayar_BE, min_BE )      # disk ve tablet tabanından büyük olan kazanır

Soğuk katman (S3) ve PostgreSQL

s3_kova_TiB = gunluk_veri_TiB × soguk_saklama_gun × replikasyon × sikistirma × 1.2

PostgreSQL meta veriyi, denetimi, replay geçmişini ve zamanlayıcı kilitlerini tutar — telemetriyi değil. Hacme değil özellik kullanımına göre ölçeklenir, bu yüzden hesaplayıcı onu bir formül yerine boyut katmanına eşler (small 10 GiB → large 200 GiB).

Dağıttıktan sonra

Eşleşen ön ayardan başlayın (values-small.yaml / values-medium.yaml / values-large.yaml) ve yukarıdaki eklentiyi uygulayın. Bkz. Kurulum → Helm ile Kubernetes.
İlk haftayı izleyin. orbtrace.cardinality.trend.exceeded ya da orbtrace.tombstone.max_version tırmanıyorsa boyut dardır — BE sayısını artırın ya da soğuk katmanı genişletin.
Bir Collector ayağa kaldırın ve verinin aktığını doğrulayın — Entegrasyon desenleri.

İş yükünüz 100 TB/gün üzerindeyse, hesaplayıcı large ön ayarının üstüne bir custom taslak döndürür; hiperölçek dağıtımlar BE topolojisi ve S3 yaşam döngüsü planlaması için Orbtrace ekibiyle özel bir çalışma gerektirir.

ÖncekiKurulum hazırlığı SonrakiTek host (Docker Compose)