Kapasite planlama

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.

# 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: 4
    storagePvc:
      size: 75Ti
postgres:
  pvc:
    size: 50Gi

Girdiler ne anlama geliyor

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.
• Yazma CPU'su. Doris'in log iş yükü rehberi yazmayı BE çekirdeği başına 10 MB/s ile boyutlandırır (çekirdek başına yaklaşık 860 GB/gün). Hesaplayıcı günlük hacminizi alır, tepe için ikiye katlar, 10 MB/s'ye böler ve her BE'nin yarısı sorgulara ve compaction'a kalsın diye bir kez daha ikiye katlar. 100 TB/gün için bu ~480 BE çekirdeği eder — Doris rehberinin kendi örneğiyle aynı rakam. Bu, ön ayarın gönderdiğinden daha fazla BE gerektirdiğinde hesaplayıcı sayıyı yükseltir ve bunu söyler.
• 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ı (ham tablolar small 16, large 128; rollup tabloları v2.3.0'dan beri small ve medium 1, large 4) tabletlerin her katmanın hedef hacminde bu banda düşmesi için seçilmiştir. Rollup tabloları küçüktür ve Doris içinde zamanlanmış işlerle güncellenir; artık sayıya dakikalık yazma yükü eklemezler.
• Compaction thread'leri çekirdekleri izler. Ön ayarlar max_cumu_compaction_threads = çekirdek / 4 ile gelir; bellek limitinin %80'ini kullanan bir BE sağlıklıdır — Doris orayı tasarım gereği önbellekle doldurur.

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

Yazma CPU'su → minimum BE

ort_MB_s        = gunluk_bayt / 86 400
tepe_MB_s       = 2 × ort_MB_s
yazma_cekirdek  = tepe_MB_s / 10             (Doris log rehberi: çekirdek başına 10 MB/s)
BE_cekirdek     = 2 × yazma_cekirdek          (yarısı sorgu + compaction için ayrılır)
min_BE_yazma    = ceil( BE_cekirdek / BE_basina_cekirdek )

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, min_BE_yazma )   # en büyük taban 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

1. 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.
2. İ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.
3. 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.