Büyük veride zaman serileri: TimescaleDB ve bulut maliyeti

Milyarlarca ölçüm neden sıradan bir tabloya sığmakla çözülmez?

Bir enerji tesisinde her on saniyede gelen ölçüm, tek başına küçük bir kayıttır. Cihaz sayısı, kanal sayısı ve saklama süresi büyüdüğünde mesele yalnızca diske sığmak olmaktan çıkar: son değeri hızlı göstermek, geçmişteki olayı yeniden kurmak, eksik ölçümü fark etmek ve aynı anda rapor çalıştırmak gerekir. Zaman serisi, zamanla ilişkilendirilmiş gözlemler bütünüdür; TimescaleDB ise bu veriler için değerlendirilebilecek belirli bir PostgreSQL eklentisidir. Bu iki kavramı ayırmak, her zaman damgalı tablo için yeni bir platform satın alma hatasını önler.

Özel mimari; ölçülen yazma yükü, zaman aralıklı sorgular, yaşam döngüsü ve ekip kapasitesi bunu gerektirdiğinde anlam kazanır. Günlük birkaç bin kayıt, sınırlı eşzamanlı kullanıcı ve basit raporlar için iyi indekslenmiş PostgreSQL yeterli olabilir. Üretimde hangi sorgunun ne kadar beklediği görülmeden büyük veri etiketiyle sistem değiştirilmemelidir. Önce veri gecikmesi, kabul edilen kayıp, sorgu yanıtı ve kurtarma hedefi yazılır. SCADA kontrol çevrimi için gereken zaman davranışı ile aylık analitik raporun ihtiyacı da aynı değildir; veritabanı seçimi fiziksel kontrolün güvenliğini kendiliğinden sağlamaz.

Bölüm kaynakları: PostgreSQL · Table partitioning ↗Tiger Data · Create and configure a hypertable ↗

Boyutlandırma: cihaz sayısından günlük kayıt ve çalışma kümesine

Tamamen varsayımsal bir örnekte 10.000 cihaz, cihaz başına 10 metrik ve 10 saniyelik örnekleme, saniyede 10.000 tekil metrik kaydı üretir. Bu, günde 864 milyon kayıttır. Her metrik kaydı için varsayılan 80 bayt mantıksal içerik, günde 69,12 GB ve otuz günde 2,0736 TB eder; ondalık birimler kullanılmıştır. Bu hesap ağ paketini, PostgreSQL satır başlığını, indeksleri, WAL'ı, replikaları ve yedekleri içermez. On metriğin tek geniş satırda tutulması satır sayısını değiştirir; örnek sayısı ile fiziksel satır aynı şey sayılmamalıdır.

Ortalama hız başlangıçtır; bağlantı kesintisi sonrası biriken verinin yeniden gelişi, vardiya raporu ve arşiv aktarımı birlikte denenmelidir. Son bir saatin indeksi belleğe sığarken son bir yılın taranması tamamen farklı I/O gerektirebilir. İş yükü kartında tepe yazma, eşzamanlı sorgu, geç gelen veri oranı, değişiklik sıklığı, sıcak veri süresi ve arşive erişim sıklığı bulunur. Disk büyüme eğrisi kadar yeniden kurulum süresi de ölçülür. Küçük bir deneme dosyasının dizüstünde hızlı okunması, milyarlarca satırlık üretim kapasitesinin kanıtı değildir.

Veri modeli: olay zamanı, alım zamanı, birim ve tekrar kimliği

Ölçümün oluştuğu event_ts ile merkezin kabul ettiği received_ts ayrı tutulur. Geç gelen veriyi alım zamanına göre geçmişin içine yanlış yerleştirmek, analiz ile saha gerçeğini ayırır. Zaman damgası UTC temelli saklanır; yerel saat, vardiya ve yaz saati kuralları rapor sınırında açık uygulanır. Cihaz kimliği, metrik kimliği, birim, kalite bayrağı ve şema sürümü tanımlanır. Değerin sıfır olması ile ölçümün hiç gelmemesi farklı durumlardır. Bir sayaç sıfırlanması, negatif tüketim veya sensör arızası, boşluğu sıfırla doldurarak görünmez kılınmamalıdır.

Dar model her metrik için satır açar; farklı cihaz türleri için esnektir ama satır ve indeks sayısını artırır. Geniş model, birlikte ölçülen sabit kanalları aynı satırda tutabilir; seyrek ve değişken şemada başka maliyetler doğurur. Sorgulanan bütün alanları JSON içine koymak da otomatik esneklik kazancı değildir. Kaynak dönem kimliği ve sıra numarası yeniden gönderimi tanımlar; tenant kapsamı güvenilir oturumdan alınır. TimescaleDB'nin benzersizlik kuralları bölümleme alanını da içerir. Olay zamanı değişen bir yeniden gönderimin aynı anahtara çarpacağı varsayılmamalı; kaynak kimliği değişmezliği ve çakışma politikası ayrıca tasarlanmalıdır.

Bölüm kaynakları: Tiger Data · Primary keys, time and uniqueness ↗

TimescaleDB nasıl başlanmalı? Sınırları açık bir SQL örneği

Aşağıdaki taslak, TimescaleDB 2.13 ile gelen genel create_hypertable/by_range arayüzünü kullanır; hedef PostgreSQL ve eklenti sürümünün uyumluluğu doğrulanmalıdır. Boş tabloda bir günlük chunk ve cihaz/metrik/zaman indeksi seçilmiştir. Bunlar evrensel üretim ayarları değildir. Sorgu tenant ve zaman aralığını açık sınırlar; istemcinin gönderdiği tenant kimliğini yetkilendirme kontrolü olmadan kullanmaz. Bileşik anahtar, aynı değişmez kaynak kaydının tekrar eklenmesini sınırlamaya yardımcı olur; farklı içerikle gelen aynı anahtarın sessizce yutulması için gerekçe oluşturmaz.

Saatlik görünümde ortalamayı tek başına saklamak yerine toplam, adet, en düşük ve en yüksek değer tutulur. Böylece daha büyük aralık için ağırlıklı ortalama toplamların toplamı/adetlerin toplamı ile üretilebilir; eşit ağırlıklı ortalamaların ortalaması hatasına düşülmez. Kalite=0 kabul kuralı yalnızca örneğin sözleşmesidir. WITH NO DATA başlangıç geçmişini doldurmaz. İlk yükleme için sınırlı bir backfill ve refresh gerekir; son yedi gün dışındaki düzeltmeler de ayrıca işlenir. SQL bir veritabanı üzerinde burada yürütülmüş benchmark değildir; çalıştırılabilir maliyet hesabı sonraki bölümde ayrı verilmiştir.

-- Reference sketch: TimescaleDB 2.13+ generalized API.
-- Confirm extension/PostgreSQL compatibility in an isolated database.
CREATE TABLE measurement_sample (
  event_ts timestamptz NOT NULL,
  received_ts timestamptz NOT NULL,
  tenant_id bigint NOT NULL,
  device_id bigint NOT NULL,
  metric_id integer NOT NULL,
  source_epoch uuid NOT NULL,
  source_sequence bigint NOT NULL,
  value double precision NOT NULL,
  quality smallint NOT NULL CHECK (quality BETWEEN 0 AND 2),
  PRIMARY KEY (tenant_id, device_id, metric_id,
               event_ts, source_epoch, source_sequence)
);
SELECT create_hypertable('measurement_sample',
  by_range('event_ts', INTERVAL '1 day'));
CREATE INDEX measurement_lookup ON measurement_sample
  (tenant_id, device_id, metric_id, event_ts DESC);

-- One metric/unit per metric_id; quality=0 means accepted in this example.
CREATE MATERIALIZED VIEW measurement_hourly
WITH (timescaledb.continuous) AS
SELECT tenant_id, device_id, metric_id,
       time_bucket(INTERVAL '1 hour', event_ts) AS bucket,
       count(*) AS n, sum(value) AS total_value,
       min(value) AS low_value, max(value) AS high_value
FROM measurement_sample WHERE quality = 0
GROUP BY tenant_id, device_id, metric_id, bucket
WITH NO DATA;

SELECT add_continuous_aggregate_policy('measurement_hourly',
  start_offset => INTERVAL '7 days',
  end_offset => INTERVAL '1 hour',
  schedule_interval => INTERVAL '15 minutes');
-- Initial history needs an explicit, bounded backfill/refresh.
-- Retention is intentionally NOT enabled in this sketch.
-- Prepared query: tenant scope MUST come from authorized server context.
SELECT event_ts, value, quality FROM measurement_sample
WHERE tenant_id = $1 AND device_id = $2 AND metric_id = $3
  AND event_ts >= $4::timestamptz AND event_ts < $5::timestamptz
ORDER BY event_ts;

Bölüm kaynakları: Tiger Data · Create and configure a hypertable ↗Tiger Data · Refresh continuous aggregates ↗

Veri alımı: tek tek INSERT yerine kontrollü toplu yazma

Her ölçüm için yeni bağlantı açmak ve bağımsız transaction üretmek bağlantı, ağ ve günlük maliyetini artırabilir. Bağlantı havuzu ile sınırlandırılmış toplu ekleme veya uygun yükleme yolu değerlendirilir. Parti büyüklüğü yalnızca satır sayısıyla değil, bayt, bekleme süresi ve geri kazanılabilir hata sınırıyla seçilir. Çok büyük parti bellek ve kilit baskısı yaratabilir; çok küçük parti sabit işlem maliyetini büyütür. Şema doğrulama, geçersiz kayıt karantinası ve kabul edilen kaydın kalıcı yazımı aynı teslim sözleşmesinde açıklanır. Broker onayı, veritabanında commit kanıtıyla karıştırılmaz.

Yeniden oynatma, normal trafikle aynı sınırsız kuyruğa bırakılmamalıdır. Cihaz veya tenant bazında adalet, geri basınç ve deneme sınırları tanımlanır. Şebeke kesintisi sonrasında eski verinin gelmesi normal olabilir; aşırı gelecekteki saat veya eski format gibi bozuk kayıtlar farklı ele alınır. Sıralı ve sırasız geliş, indeks bakımını ve sıkıştırılmış geçmişe yazmayı farklı etkiler. Kabul edilen, yinelenen, karantinaya alınan ve kaybolduğu tespit edilen kayıtlar ayrı sayılır. Bu kayıtlar olmadan veritabanı hızlı görünürken hattın sessizce veri kaybettiği anlaşılmayabilir.

Chunk, indeks ve columnstore: aynı ayar her iş yüküne uymaz

Chunk aralığı, aktif yazmaların ve indekslerin çalışma kümesini etkiler. Çok geniş aralık sıcak indeksi büyütebilir; çok dar aralık fazla parça, planlama ve bakım işi üretebilir. Bir günlük değer yalnızca başlangıç hipotezidir. Bellek kullanımı, geç gelen verinin açtığı aktif chunk sayısı, sorgu planı ve I/O birlikte ölçülür. Her metriğe ve her etikete gelişigüzel indeks eklemek yazmayı pahalılaştırır. En sık sorgunun tenant, cihaz, metrik ve zaman filtresine uygun az sayıda indeksle başlanır; gerçekten kullanılanlar planlardan doğrulanır.

TimescaleDB'nin columnstore/Hypercore yaklaşımında segment ve sıralama seçimi sorgu ile veri dağılımına göre değerlendirilir. Her satırda farklı bir kimliği segment anahtarı yapmak büyük ve verimli grupları engelleyebilir. Yeni yazılan ve sık düzeltilen veriyle eski, çoğunlukla okunan veri için aynı fiziksel tercih gerekli değildir. Sıkıştırma oranı veri türü ve tekrarlılıkla değişir; tanıtımdaki en yüksek oran bütçe garantisi sayılmaz. Dönüşümün CPU ve I/O yükü, geç güncellemenin etkisi ve arşivden okuma gecikmesi pilotta kaydedilir. Buluta özel tiering özelliği, her self-hosted kurulumda varmış gibi anlatılmaz.

Bölüm kaynakları: Tiger Data · Create and configure a hypertable ↗Tiger Data · Columnstore compression methods ↗

Özetleme neyi korur, neyi kaybettirir?

Bir yıllık grafikte her ham ölçümü taramak yerine dakika veya saat özetleri kullanılabilir. Fakat bir dakikalık ortalama kısa tepeyi saklayamaz; olay incelemesi için min/max, adet, kalite ve gerektiğinde ham pencere gerekir. Düzensiz örneklenen güç verisinin basit ortalaması otomatik olarak enerji vermez; birim, zaman ağırlığı ve boşluk politikası tanımlanmalıdır. Yüzdelikler için yalnızca alt grupların p95 değerlerini ortalamak doğru birleşim değildir. Amaç, her veri türünü aynı AVG sorgusuna sokmak değil, kararın gerektirdiği istatistiği saklamaktır.

Continuous aggregate yenilemesi de anlık ve sınırsız değildir. Örnekte son saat dışarıda bırakılmıştır; dashboard'ın güncel ham kuyruğu nasıl göstereceği ayrıca seçilir. Son yedi gün için yenileme politikası tanımlamak daha eski düzeltmelerin kendiliğinden işlendiği anlamına gelmez. Veri silme politikası ile yenileme penceresi kesişirse silinen ham veriye göre eski özetler de yeniden hesaplanıp kaybolabilir. Bu nedenle ham saklama, özet saklama, geç geliş ve manuel yeniden hesaplama birlikte tasarlanır. Silme işi etkinleştirilmeden önce yedekten dönüş ve tarihsel rapor davranışı doğrulanır.

Bölüm kaynakları: Tiger Data · Refresh continuous aggregates ↗Tiger Data · Retention with continuous aggregates ↗

Hangi platform hangi probleme aday?

Seçim, tek bir saniyedeki yazma rekoruyla yapılmamalıdır. SQL join ihtiyacı, güncelleme davranışı, sorgu çeşitliliği, ekip deneyimi ve veri yerleşimi birlikte değerlendirilir. Aşağıdaki tablo 20 Ekim 2026 tarihli bir karar çerçevesidir; evrensel performans sıralaması değildir. PostgreSQL ve TimescaleDB ilişkisel bağlamla zaman serisini birleştirmeye adaydır; ClickHouse sütun odaklı analitik taramalar için değerlendirilir. InfluxDB ailesinde motor, sürüm ve hizmet biçimi açık yazılmalıdır; bir sürümün sorgu dili veya kapasite özelliği diğerinin garantisi sayılmaz.

Prometheus sistem metrikleri ve alarm bağlamında güçlü bir adaydır; eksiksiz iş olayı arşivi veya finansal kaynak kayıt sistemi olduğu varsayılmaz. Tarihsel model eğitimi ve seyrek toplu analiz için Parquet ile nesne depolama ve DuckDB gibi sorgu araçları değerlendirilebilir; bu katman tek başına düşük gecikmeli alım servisi değildir. AWS tarafında LiveAnalytics ile Timestream for InfluxDB aynı hizmet değildir. AWS belgesi LiveAnalytics'e yeni müşteri erişiminin 20 Haziran 2025'te kapandığını belirtiyor; yeni proje listesinde bu hizmeti koşulsuz kullanılabilir göstermek doğru olmaz. Güncel hizmet erişimi satın alma öncesi yeniden doğrulanır.

Bölüm kaynakları: PostgreSQL · Table partitioning ↗ClickHouse · MergeTree ↗InfluxDB 3 Core · Query languages and clients ↗DuckDB · Parquet reads and writes ↗AWS · LiveAnalytics new-customer availability ↗

Kardinalite ve arşiv: aynı veriyi her yere kopyalamayın

Etiket kardinalitesi farklı değer birleşimlerinin sayısıdır. Cihaz, metrik, yazılım sürümü ve sınırsız istek kimliğini birlikte etiketlemek, görünenden çok daha fazla seri yaratabilir. Prometheus belgeleri bu nedenle kullanıcı kimliği ve benzeri sınırsız değerleri etiket yapmama uyarısı verir. Bu sınırın her veritabanında aynı çalıştığı iddia edilemez; indeks, metadata ve bellek maliyeti motor bazında ölçülür. Kişisel bilgiyi etiket içine yerleştirmek güvenlik ve saklama kapsamını da büyütür. Hata ayıklama için gereken ayrıntı, sınırlı ömürlü olay kaydında daha uygun olabilir.

Sıcak operasyonel depo, özet deposu ve tarihsel arşivin amacı ayrılır. Her ham satırı hem veritabanında hem veri gölünde hem dashboard önbelleğinde süresiz saklamak maliyeti ve silme yükünü çoğaltır. Parquet arşivinde tarih veya uygun başka alanlara göre bölümleme ve dosya boyutu sorgu davranışını etkiler; çok küçük dosyalar listeleme ve açma işini artırabilir. Dosya manifesti, şema sürümü, veri kapsamı ve kontrol toplamı izlenir. Arşivin oluşması, yedekten kurtarma kanıtı değildir; geri okuma, yetki ve veri bütünlüğü ayrı sınanır.

Bölüm kaynakları: Prometheus · Metric and label naming ↗DuckDB · Parquet reads and writes ↗

Bulut faturası neden yalnızca GB × fiyat değildir?

Teklifte compute, sıcak disk, nesne depolama, yazma veya sorgu tüketimi, I/O, yedek, replikalar, veri çıkışı ve destek ayrı satırlara ayrılır. Otuz günlük saklama kapasitesi ile ay boyunca faturalandırılan ortalama kapasite aynı olmayabilir; yeni kurulumun dolma dönemi ve kararlı durum ayrı hesaplanır. GB ile GiB, sıkıştırılmış fiziksel bayt ile mantıksal veri boyutu karıştırılmaz. Replikaların disk ve compute etkisi, yüksek erişilebilirlik ile okuma ölçeklemenin farkı ve asgari hizmet boyutu teklif üzerinde açıklaştırılır. Bedava başlangıç katmanı üretim toplam maliyeti değildir.

20 Ekim 2026'da incelenen Tiger Cloud fiyat sayfası compute ve depolamayı ayırıyor; gösterilen efektif depolama fiyatı sıkıştırma varsayımı içeriyor. ClickHouse Cloud fatura belgesi kendi kaynak kalemlerini, InfluxDB fiyat sayfası ise farklı hizmet biçimlerini tanımlıyor. Bunların birimlerini eşitlemeden sadece başlangıç fiyatlarını yan yana koymak yanıltır. AWS Timestream ailesinde de seçilen motor/hizmet için geçerli fiyat modeli okunmalıdır. Bu makale güncel sayfalara bağlantı verir; üretim teklifi yerine hızla eskiyebilecek sabit fiyat listesi sunmaz. Aşağıdaki rakamlar sağlayıcı tarifesi değil, duyarlılık hesabı içindir.

Bölüm kaynakları: Tiger Cloud · Pricing and billing FAQ ↗ClickHouse Cloud · Billing overview ↗InfluxData · Deployment and pricing options ↗AWS · Timestream pricing ↗

Çalıştırılabilir maliyet örneği: veri çıkışı sıkıştırma kazancını silebilir

Örnek, otuz günlük kararlı saklama için yedi gün sıcak ve yirmi üç gün soğuk veri, soğuk bölümde varsayımsal 4:1 küçülme ve iki depolama kopyası kullanır. Compute iki düğüm ve otuz günlük ay için 720 saattir. Bütün USD birim fiyatları uydurulmuş eğitim girdileridir. Model yaklaşık 993,38 USD üretir; veri çıkışını 2.500 GB'den 10.000 GB'ye çıkarmak aynı varsayımsal tarifede 675 USD ekler. Böylece küçük bir disk indiriminin, sürekli dışarı taşınan büyük sonuç kümeleri yanında neden önemsiz kalabileceği görünür olur.

Mantıksal 80 baytın fiziksel yer ihtiyacına doğrudan çevrilmesi bu basit modelin bilinçli sınırlamasıdır. Gerçek hesapta ölçülen indeks/satır payı, WAL, geçici sorgu alanı, yedek artışları, istek sayıları, ağ topolojisi ve işçilik eklenir. Soğuk katmanda seçilen oran gerçekleşmezse tutar yeniden hesaplanır. Negatif giriş, sıfır örnekleme aralığı ve saklamadan uzun sıcak pencere örnekte reddedilir; sıfır cihazda ise sabit compute ücreti yine oluşabilir. Bütçe kararı bu kodun çıktısıyla tek başına verilmez; sağlayıcının hesaplayıcısı ve ölçülmüş tüketimle eşleştirilir.

const assert = require('node:assert/strict');
// Synthetic USD rates and storage assumptions; NOT any vendor's quote.
const rates = { nodeHour: 0.35, hotGBMonth: 0.20,
  coldGBMonth: 0.03, backupGBMonth: 0.02, egressGB: 0.09 };
function estimate(x) {
  for (const key of ['devices','metrics','intervalSeconds','bytesPerRecord',
    'retentionDays','hotDays','coldCompression','storageCopies','nodes',
    'hours','backupGB','egressGB','otherUSD'])
    assert(Number.isFinite(x[key]) && x[key] >= 0, key);
  assert(x.intervalSeconds > 0 && x.coldCompression >= 1);
  assert(x.hotDays <= x.retentionDays && x.storageCopies >= 1);
  const recordsPerDay = x.devices * x.metrics * 86400 / x.intervalSeconds;
  const logicalGBPerDay = recordsPerDay * x.bytesPerRecord / 1e9;
  // A steady-state arithmetic model, not measured database disk usage.
  const hotGB = logicalGBPerDay * x.hotDays * x.storageCopies;
  const coldGB = logicalGBPerDay * (x.retentionDays - x.hotDays)
    / x.coldCompression * x.storageCopies;
  const parts = {
    compute: x.nodes * x.hours * rates.nodeHour,
    hot: hotGB * rates.hotGBMonth,
    cold: coldGB * rates.coldGBMonth,
    backup: x.backupGB * rates.backupGBMonth,
    egress: x.egressGB * rates.egressGB,
    other: x.otherUSD
  };
  return { id: 'timeseries-cost-sensitivity', recordsPerDay,
    logicalGBPerDay, hotGB, coldGB, parts,
    totalUSD: Object.values(parts).reduce((a,b) => a+b, 0) };
}
const base = { devices:10000, metrics:10, intervalSeconds:10,
  bytesPerRecord:80, retentionDays:30, hotDays:7, coldCompression:4,
  storageCopies:2, nodes:2, hours:720, backupGB:600,
  egressGB:2500, otherUSD:35 };
const result = estimate(base);
assert.equal(result.recordsPerDay, 864000000);
assert.equal(result.logicalGBPerDay, 69.12);
assert(Math.abs(result.totalUSD - 993.3824) < 1e-8);
const moreEgress = estimate({...base, egressGB:10000});
assert(Math.abs(moreEgress.totalUSD-result.totalUSD-675) < 1e-8);
assert(estimate({...base, coldCompression:1}).totalUSD > result.totalUSD);
assert.equal(estimate({...base, devices:0}).logicalGBPerDay, 0);
assert.throws(() => estimate({...base, intervalSeconds:0}));
assert.throws(() => estimate({...base, hotDays:31}));
assert.throws(() => estimate({...base, egressGB:-1}));
console.log(result, moreEgress);

Dashboard, sorgu ve veri çıkışı için maliyet kontrolleri

Yüz kullanıcıya açık, on iki panelli ve on saniyede yenilenen bir dashboard, her panel ayrı sorgu çıkarıyorsa aynı ham geçmişi sürekli tarayabilir. Önce gerçekten gereken yenileme süresi, zaman aralığı ve çözünürlük belirlenir; ortak özet, önbellek ve sunucu tarafında sorgu sınırları değerlendirilir. Kullanıcının sınırsız tarih aralığı veya sınırsız sonuç almasına izin vermek yerine rol ve iş ihtiyacına göre sınır konur. Uygulama, aynı bulut ve bölgedeki veriyi gereksiz yere başka bölgeye veya dış ağa taşımamalıdır. Özel ağ bağlantısının da fiyatı ve erişim sorumluluğu ayrıca incelenir.

Sorgu başına tarama veya kapasite üzerinden ücretlenen analitik hizmetlerde aynı SQL farklı maliyet davranışı gösterebilir. BigQuery belgeleri sorgu öncesi tahmin, uygun kota ve maksimum faturalandırılabilir bayt gibi kontrolleri açıklar; yalnızca LIMIT eklemek genel bir tarama maliyeti sınırı değildir. Her sağlayıcı için kullanılabilir sınırlar ayrı doğrulanır. Bütçe uyarısı otomatik harcama kesici sanılmamalıdır. Tenant, iş türü ve ortam bazında tüketim izlenir; pahalı sorgu, yenileme işi ve arşiv okuması sahibine atanır. Alarmın gerektirdiği müdahale ve kritik operasyonun kesilmemesi de tasarımın parçasıdır.

Bölüm kaynakları: BigQuery · Estimate and control costs ↗

Pilot, tahmin modeli ve veri yerleşimi birlikte değerlendirilir

Pilot veri seti yalnızca kolay sıkışan sıralı ölçümlerden oluşmamalıdır. Gecikmiş geliş, cihaz saati kayması, bağlantı sonrası tekrar, bozuk kalite, farklı tenant büyüklükleri ve geçmiş düzeltmeleri eklenir. Yazma ve okuma aynı anda çalışırken p50/p95/p99 gecikme, hata, kaynak kullanımı, görev birikmesi ve faturalanabilir tüketim kaydedilir. Soğuk ve sıcak önbellek koşulları ayrı raporlanır. Bir sistemi daha az saklama, daha az güvenilirlik veya daha az sorguyla test edip daha ucuz ilan etmek anlamlı karşılaştırma oluşturmaz. Aynı doğruluk ve hizmet hedefi korunmalıdır.

Tahmin modeli için zaman serisini hızlı okumak yeterli değildir: eğitim/kontrol ayrımı zaman düzenini korumalı, sonradan düzeltilen verinin geçmişe bilgi sızdırması engellenmeli ve kullanılan veri sürümü izlenmelidir. Yerleşim şartı varsa veritabanı bölgesi kadar yedek, arşiv, anahtar ve destek yolu da incelenir. Yönetilen hizmetin uygun coğrafyada bulunması varsayılmaz; self-hosted seçeneğin işletim yükü de saklanmaz. Gokbilge Tech bu ihtiyacı veri ve gözlemlenebilirlik, SCADA/enerji, enerji yapay zekâsı ve tahmin modellerinin iyileştirilmesi kapsamında birlikte ele alabilir. Belirli bir üründe bu platformların teslim edilmiş olduğu iddiası kurulmaz.

• Örnek, mesaj, satır ve fiziksel bayt ayrımı ile tepe yük ölçüldü mü?
• Geç veri, çakışan tekrar, özet doğruluğu ve saklama/yenileme çakışması sınandı mı?
• Compute, kopyalar, yedek, sorgu, veri çıkışı ve işletim gideri birlikte hesaplandı mı?
• Kurtarma, dışa aktarım, veri yerleşimi ve lisans/sürüm sınırları belgelendi mi?