Ana içeriğe geç

Seçim Rehberi · Veritabanları

Tablo Partitioning Seçimi: Range, List, Hash veya Bölümsüz Tasarım

Partitioning büyük tabloyu mantıksal alt parçalara ayırır; bütün sorguları otomatik hızlandırmaz. Partition pruning sorgu koşuluyla gereksiz parçaları dışlar. Uygulama partition key…

Teknik gözden geçirme:

Mimari ve çalışma modeli

Partitioning büyük tabloyu mantıksal alt parçalara ayırır; bütün sorguları otomatik hızlandırmaz. Partition pruning sorgu koşuluyla gereksiz parçaları dışlar. Uygulama partition key kullanmıyorsa bütün parçalar taranabilir ve planlama yükü artabilir.

Range zaman bazlı saklamaya, list sınırlı ayrık iş alanlarına, hash daha dengeli dağıtıma uygun olabilir. Veri hacmi tek seçim ölçütü değildir; en sık sorgular, unique key koşulları, FK ve bakım süresi belirleyicidir. Motorun sürüme özgü kısıtlarını kontrol edin.

Zaman partition’ında gelecekteki parçaların önceden oluşması ve geç gelen verinin davranışı planlanmalıdır. Default partition varsa kontrolsüz büyümesini izleyin. Eski partition detach/drop hızlı retention sağlayabilir ama bağımsız yedek ve veri silme onayını ikame etmez.

  1. 1Sorgu ve retention
  2. 2Key ve granülarite
  3. 3Pruning ve index
  4. 4Bakım ve kabul
En sık sorguları çıkarın.

Tasarım parametreleri

Sorgu deseni
Filtre, join ve unique ihtiyaçlarının partition key ile örtüşmesini inceleyin.
Parça sayısı
Günlük/aylık granülariteyi planlama yükü ve retention ihtiyaçlarıyla dengeleyin.
Bakım
Parça oluşturma, attach/detach, index ve statistics adımlarını otomatik test edin.

Platformlardaki uygulama karşılıkları

Servis adları teknik karşılıklardır. Kapsam, varsayılanlar, bölge kullanılabilirliği ve işletim koşulları farklıdır; birebir aynı garanti anlamına gelmez.

ModelUygun desenRisk
RangeZaman/aralık filtresiEksik gelecek parça
ListSınırlı ayrık kategorilerKategori sayısının büyümesi
HashKey bazlı dağılımRetention parçaya denk gelmeyebilir
BölümsüzÖlçülü tablo/uygun indexBüyük bakım ve silme maliyeti

Hesap ve uygulama örneği

İki yıllık günlük olay verisi için aylık model 24, günlük model yaklaşık 730 partition üretir. Sorgular genellikle tek ay ve retention aylıksa aylık model daha basit olabilir; bu performans garantisi değildir. EXPLAIN’de yalnız ilgili parçaların okunduğunu ve uygulama unique koşullarının korunduğunu doğrulayın.

Hata teşhisi

BelirtiOlası neden / ayrımDoğrulama
Partition var, tarama aynıFiltre key’i kullanmıyor veya pruning koşulu yok.EXPLAIN ve taranan child tabloları inceleyin.
Yeni gün verisi eklenmiyorGelecek partition yok.Bound ve scheduler başarısını kontrol edin.

Kabul ve doğrulama kontrolleri

  1. En sık sorguları çıkarın.
  2. Key ile unique koşulunu doğrulayın.
  3. Pruning’i EXPLAIN ile gösterin.
  4. Gelecek parça oluşturmayı sınayın.
  5. Geç veri senaryosunu deneyin.
  6. Retention/restore’u birlikte planlayın.

İlgili kavramlar

İndeks ve sorgu planı

İndeks, uygun sorgularda taranacak veriyi azaltabilir; her yeni indeks yazma, bakım ve depolama maliyeti getirir. Sütun sırası, seçicilik, filtre ve sıralama gereksinimi birlikte değerlendirilir. Sorgu yavaşlığını yalnız indeks yokluğuna bağlamayın: yanlış tahmin, kilit beklemesi, disk gecikmesi veya gereksiz veri taşıma da neden olabilir. Temsilî sorgunun yürütme planını ve gerçek satır sayılarını inceleyin. Değişikliğin okuma kazancını, yoğun yazma sırasında oluşturduğu maliyetle birlikte ölçün; üretimde kontrolsüz bakım işlemleri başlatmayın.

Kapasite ve kullanılabilir pay

Ham kapasite ile uygulamanın kullanabileceği kapasite aynı değildir. RAID veya erasure coding, dosya sistemi, ayrılmış alan, metadata, snapshot ve büyüme payı ayrı kalemlerdir. TB ile TiB gösterimi de görünür sayıyı değiştirir. Hesabı birimleriyle yazın ve önce kullanılabilir korumalı kapasiteyi, sonra işletim rezervini çıkarın. Ortalama doluluğu izlemek kadar büyüme eğimini izlemek de önemlidir. Tahmini dolma tarihi, yeni kapasiteyi satın alma ve devreye alma süresinden daha uzakta tutulmalıdır.

Gecikme dağılımı

Gecikme, bir işlemin başlangıcı ile yanıtı arasındaki süredir. Ortalama değer, az sayıdaki çok yavaş işlemi gizleyebilir; medyan ile p95/p99 gibi yüzdelikler farklı sorulara cevap verir. Ağ RTT, disk bekleme, işlemci sırası ve uygulama işlemesi toplam süreye katkıda bulunur. Ölçümün istemci tarafında mı sunucuda mı yapıldığını yazın. Gecikme artışının trafik yükselmesine, bakım işine veya kapasite sınırına denk gelip gelmediğini karşılaştırın. Bir eşik seçmeden önce normal yük ve yoğun saat için temel davranışı kaydedin.

Saklama politikası ve kapasite

Retention, hangi kurtarma noktalarının ne kadar süre tutulacağını tanımlar. Günlük, haftalık ve aylık noktalar aynı veri değişim oranını temsil etmez; tam kopya üretme şekli ve zincir bağımlılığı fiziksel kapasiteyi değiştirir. Saklama kararı, iş gereksinimi ve geçerli yükümlülükler ile teknik kapasitenin birlikte değerlendirilmesini gerektirir. Daha uzun saklama, otomatik olarak daha iyi kurtarma anlamına gelmez: doğru noktanın bulunması ve okunabilmesi gerekir. Politika değiştirildiğinde mevcut noktaların hemen silinip silinmediğini ürün davranışı üzerinden sınayın.

Transaction sınırı

Transaction, uygulamanın belirli işlemleri birlikte başarılı veya başarısız kabul ettiği mantıksal birimdir. Veritabanı içindeki atomiklik, e-posta gönderimi veya farklı servislerdeki değişikliklerin otomatik olarak aynı atomik kapsamda olduğu anlamına gelmez. Commit noktası ve hata sonrasında tekrar denemenin davranışı açık olmalıdır. Aynı isteğin iki kez işlenmesini önlemek için idempotency gereksinimini değerlendirin. Testte ağ kesintisi ve bağlantı kopmasını commit öncesi ve sonrasında ayrı uygulayın; istemcinin hata alması işlemin kesinlikle başarısız olduğu anlamına gelmeyebilir.

Sürüm ve destek yaşam döngüsü

Bir ürünün kurulabilir olması üretim için desteklendiğini kanıtlamaz. İşletim sistemi, uygulama, sürücü, eklenti ve yönetim aracının uyumluluk zincirini birlikte kontrol edin. Güncelleme planında paket sürümü, destek bitişi, yeniden başlatma gereksinimi ve geri alma yöntemi bulunmalıdır. Test ortamı üretimdeki bağımlılıkları temsil etmezse sonuç yanıltıcı olabilir. Değişiklik sonrası yalnız sürüm numarasını değil, hizmet sağlığını ve önceki iş akışlarını doğrulayın. Bir sürümü sabitlemenin gelecekteki güvenlik düzeltmelerini engelleyebileceğini de dikkate alın.

Birincil teknik dokümantasyon

Doz Teknoloji teknik ekibi tarafından aşağıdaki birincil kaynaklar temel alınarak hazırlanmıştır. Hesaplar ve laboratuvar senaryoları varsayımlarını belirtir; uygulamadan önce kullanılan ürün sürümünü doğrulayın.

Bilgi Merkezi

Kurumsal IT Ürün Satışı, Lisanslama ve Kurulum
Kurumsal IT Proje & Çözüm Senaryoları
Tüm ilgili içerikleri görüntüleyin
WhatsApp'tan Yazın
Kopyalandı!