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.
- 1Sorgu ve retention
- 2Key ve granülarite
- 3Pruning ve index
- 4Bakım ve kabul
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.
| Model | Uygun desen | Risk |
|---|---|---|
| Range | Zaman/aralık filtresi | Eksik gelecek parça |
| List | Sınırlı ayrık kategoriler | Kategori sayısının büyümesi |
| Hash | Key bazlı dağılım | Retention parçaya denk gelmeyebilir |
| Bölümsüz | Ölçülü tablo/uygun index | Bü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
| Belirti | Olası neden / ayrım | Doğ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 eklenmiyor | Gelecek partition yok. | Bound ve scheduler başarısını kontrol edin. |
Kabul ve doğrulama kontrolleri
- En sık sorguları çıkarın.
- Key ile unique koşulunu doğrulayın.
- Pruning’i EXPLAIN ile gösterin.
- Gelecek parça oluşturmayı sınayın.
- Geç veri senaryosunu deneyin.
- 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.