Question 1

Canlı bir veritabanını kesintisiz nasıl taşıyorsunuz?

Accepted Answer

Değişikliği tek bir anahtar çevirme anı olmaktan çıkarıp geri alınabilir ve kademeli hale getirerek. Standart yaklaşım genişlet-daralt yöntemidir: yeni kolonu, tabloyu veya veritabanını eskisinin yanına ekle, bir süre ikisine birden yaz, geçmiş kayıtları tabloyu kilitlemeyecek partiler halinde doldur, veri doğrulandıktan sonra okumaları taşı ve eski yapıyı sonraki bir sürümde kaldır. Gerçek anlamda sıfır kesinti kullandığınız teknolojiye bağlıdır; bu yüzden sıfır vaat edip gece ikide aksini keşfetmek yerine gerçekçi ve kısa bir geçiş penceresi veririz.

Question 2

İyileştirme bir şeyleri bozar mı?

Accepted Answer

İndeks ve sorgu çalışması, değişiklikler tek tek gözden geçirilip uygulandığında genelde düşük risklidir; ancak gerçek tehlikeler vardır: büyük bir tabloya yanlış yöntemle indeks eklemek yazmaları kilitleyebilir, bir sorgunun yeniden yazımı ise NULL veya tekrar eden kayıtlar söz konusuysa sonucu fark ettirmeden değiştirebilir. Bu yüzden üretim boyutundaki bir kopyada test eder, motorun desteklediği yerde indeksi eşzamanlı (concurrently) oluşturur ve sonuçları eşdeğer varsaymak yerine öncesi-sonrası karşılaştırırız.

Question 3

Üretim veritabanımıza erişmeniz şart mı?

Accepted Answer

Teşhis için genelde sanılandan çok daha azı yeterlidir: çalıştırma planları, yavaş sorgu kayıtları, şema tanımları ve tablo istatistikleri çoğu zaman iş görür ve bunların hiçbiri müşteri kayıtlarını okumayı gerektirmez. Doğrudan erişim gerçekten gerekiyorsa isimli ve yalnızca okuma yetkili bir rolle çalışırız; kişisel veri içeren işlerde ise maskelenmiş ya da küçültülmüş kopya tercih ederiz. Üretime yazma yetkisi kalıcı olarak değil, belirli bir migrasyon penceresi için verilir.

Question 4

Trafiğimiz artmadığı halde hosting faturamız neden büyüyor?

Accepted Answer

Yönetilen PostgreSQL platformlarında veri transferi ve depolama çoğu zaman işlem gücünden ayrı faturalanır; üç kolona ihtiyaç duyduğu yerde tüm tabloyu okuyan ya da her istekte aynı satırları yeniden çeken bir uygulama, trafiğinin ima ettiğinden çok daha fazla transfer üretir. Bunu kendi platformumuzda birebir yaşadık: tam tablo okumalarını dar projeksiyonlarla değiştirerek, kayıtları toplu ekleyerek, satır satır sorguları toplu SQL'e çevirerek ve bilinçli geçersiz kılma kurgusu olan bir önbellek katmanı ekleyerek düşürdük.

Question 5

Serverless'a geçtikten sonra sürekli bağlantı limiti hatası alıyoruz, sorun ne?

Accepted Answer

Serverless fonksiyonlar yatay olarak çoğalır ve her örnek kendi bağlantılarını tutabilir; tek bir uzun ömürlü uygulama sunucusuna rahatça yeten bir veritabanı bu durumda bağlantı limitini hızla tüketir. Çözüm doğru konumlandırılmış bir bağlantı havuzlayıcı, buna göre yapılandırılmış istemci, kısa tutulan işlemler ve canlı bağlantı gerektirmeyen işlerin istek yolundan çıkarılmasıdır. Bu bir kapasite değil tasarım sorunudur; daha büyük paket almak nadiren çözer.

Question 6

Normalizasyon mu denormalizasyon mu, kararı neye göre veriyorsunuz?

Accepted Answer

Verinin neyi garanti etmesi gerektiğine ve nasıl okunduğuna göre. Normalizasyon çelişkili veriyi engeller ve işlemsel her şey için doğru varsayılandır; denormalizasyon ise bedeli güncelleme karmaşıklığı ve veri sapması riski olan bilinçli bir performans kararıdır. Sık kullanılan yollarda bir join'in pahalı olduğu ölçülerek gösterildiğinde denormalize eder, türetilmiş veriyi veritabanının ya da tek bir kod yolunun sorumluluğunda tutar ve neden böyle yapıldığını yazarız ki kimse yanlışlıkla geri almasın.

Question 7

Eksik indeksleri nasıl buluyorsunuz?

Accepted Answer

Tahminle değil gerçek iş yüküne bakarak: yavaş sorgu kayıtları, büyük tablolarda sıralı tarama gösteren çalıştırma planları ve hem kullanılmayan indeksleri hem de indeksi olmayan sıcak tabloları ortaya çıkaran indeks kullanım istatistikleri. Bileşik indekslerde kolon sırası en az hangi kolonların dahil edildiği kadar önemlidir; filtreli sorgularda kısmi indeksler çoğu zaman geniş indekslerden daha iyi sonuç verir. Yazma tarafını da kontrol ederiz, çünkü her indeks ekleme ve güncellemeyi pahalılaştırır.

Question 8

Sizinle çalışmayı bırakırsak verilerimize ne olur?

Accepted Answer

Zaten olduğu yerde, sizin hesabınızdaki veritabanında kalır. Özellikle talep etmediğiniz sürece müşteri üretim verisini bize ait bir altyapıda barındırmayız ve iş bittikten sonra devir için gerekenin ötesinde kopya tutmayız. Şema dokümantasyonunu, migrasyon geçmişini, indeks gerekçelerini ve kurtarma prosedürünü teslim eder, işi devralacak kişiye gerekirse aktarım toplantısı yaparız.

Question 9

KVKK açısından verinin nerede tutulduğu nasıl ele alınıyor?

Accepted Answer

Verinin hangi bölgede barındırılacağı, ne kadar süre saklanacağı ve kimin eriştiği baştan yazılı olarak kararlaştırılır; yurt içi barındırma isteyen müşteriler için bunu bir mimari kısıt olarak ele alır, yedeklerin ve replikaların da aynı bölgede kalmasına dikkat ederiz. Geliştirme ve test ortamlarına kişisel veri kopyalamayız; oralarda maskelenmiş veya üretilmiş veriyle çalışırız. Aydınlatma yükümlülükleri ve saklama süreleri konusunda hukuk danışmanınızın belirlediği çerçeveye uyarız.

Question 10

Yedekleme ve belirli bir ana geri dönüş nasıl kurgulanıyor?

Accepted Answer

Önce kabul edilebilir veri kaybı süresi ile hedef kurtarma süresini konuşuruz; çünkü diğer her şeyi bu iki rakam belirler. Ardından yedekleme ve saklama ayarlarını buna göre yapar, ayrı bir ortama gerçek bir geri yükleme yaparak doğrularız. Kurtarmayı kimin başlatabileceğini ve sizin veri hacminizde tam bir geri yüklemenin gerçekte ne kadar sürdüğünü de belgeleriz; bu ölçüm ilk kez olay anında yapılırsa hiçbir değeri kalmaz.

Question 11

Çok kiracılı yapıda veri izolasyonu yapıyor musunuz?

Accepted Answer

Evet ve bunu geliştirici disiplini değil şema meselesi olarak ele alırız. Kiracıya bağlı her tablo bir kiracı anahtarı taşır, erişim bu anahtarı atlayamayan sorgular üzerinden yapılır ve sınır, her geliştiricinin WHERE koşulunu hatırlamasına bırakılmadan satır seviyesi güvenlikle veritabanında zorlanır. Bu deseni ikas mağazaları için geliştirdiğimiz çok kiracılı yapay zekâ destek platformunda kiracı bazlı kullanım ve maliyet takibiyle birlikte uyguladık.

Nasıl yardımcı olabiliriz?

Veritabanı Hizmetleri
SSS

Yararlı
bilgiler

Başlarken

Zaman Çizelgesi

Fiyatlandırma

Destek

Hala sorularınız mı var?

Veritabanı HizmetleriSSS

Yararlıbilgiler