Çok kiracılı veritabanlarının güvenlik ve performansı nasıl etkilediğini, başlıca riskleri (izolasyon eksikliği, gürültülü komşular) ve kiracıları güvenli ve hızlı tutmak için uygulanabilir kontrolleri öğrenin.
Bir çok kiracılı veritabanı, birden fazla müşterinin (kiracıların) aynı veritabanı sistemini paylaştığı bir düzenlemedir—aynı veritabanı sunucusu, aynı temel depolama ve genellikle aynı şema—uygulama ise her kiracının yalnızca kendi verisine erişmesini sağlar.
Bunu bir apartmana benzetin: herkes binanın yapısını ve altyapısını paylaşıyor, ama her kiracının kendi kilitli ünitesi var.
Tek kiracılı yaklaşımda, her müşteriye ada özgü veritabanı kaynakları verilir—örneğin kendi veritabanı örneği veya sunucusu. İzolasyonu değerlendirmek daha kolaydır, ama müşteri sayısı arttıkça maliyetli ve işletme yükü ağır olabilir.
Çok kiracılılık ile kiracılar altyapıyı paylaşır; bu verimli olabilir—ancak sınırları kasıtlı olarak uygulamanız gerekir.
SaaS şirketleri pratik nedenlerle genellikle çok kiracılığı tercih eder:
Çok kiracılılık kendi başına otomatik olarak “güvenli” veya “hızlı” olmaz. Sonuçlar, kiracıların nasıl ayrıldığına (şema, satır veya ayrı veritabanı), erişim kontrolünün nasıl uygulandığına, şifreleme anahtarlarının nasıl yönetildiğine ve bir kiracının iş yükünün diğerlerini yavaşlatmasını nasıl önlediğinize bağlıdır.
Bu rehberin geri kalanı bu tasarım seçimlerine odaklanıyor—çünkü çok kiracılı sistemlerde güvenlik ve performans inşa edilen özelliklerdir, devraldığınız varsayımlar değil.
Çok kiracılılık tek bir tasarım seçimi değildir—altyapıyı ne kadar sıkı paylaştığınıza dair bir yelpazededir. Seçtiğiniz model izolasyon sınırınızı belirler (ne asla paylaşılmamalı) ve bu doğrudan veritabanı güvenliğini, performans izolasyonunu ve günlük operasyonları etkiler.
Her kiracı kendi veritabanını alır (genellikle aynı sunucu veya kümede).
İzolasyon sınırı: veritabanı. Bu genelde en temiz kiracı izolasyon hikayesidir çünkü kiracılar arası erişim tipik olarak bir veritabanı sınırını geçmeyi gerektirir.
Operasyonel takaslar: ölçeklendiğinde işletilmesi daha ağırdır. Yükseltmeler ve şema migration'ları binlerce kez çalıştırılmak zorunda kalabilir, bağlantı havuzlama karmaşıklaşabilir. Yedek/geri yükleme kiracı düzeyinde basittir, ama depolama ve yönetim yükü hızla büyüyebilir.
Güvenlik ve tuning: genelde müşteri bazında güvenli ve ayarlanması en kolay yaklaşımdır; farklı uyumluluk gereksinimleri olan kiracılar için uygundur.
Kiracılar bir veritabanını paylaşır, ama her kiracının kendi şeması vardır.
İzolasyon sınırı: şema. Anlamlı bir ayrım sunar, ancak doğru izinlere ve araçlara dayanır.
Operasyonel takaslar: upgrade ve migration'lar hala tekrarlıdır, ancak database-per-tenant kadar ağır değildir. Yedeklemeler daha karmaşıktır: birçok araç veritabanını yedek birimi olarak ele alır, bu yüzden kiracı düzeyinde işlemler şema düzeyinde dışa aktarma gerektirebilir.
Güvenlik ve tuning: paylaşılan tablolara kıyasla izolasyonu uygulamak kolaydır, ancak ayrı şemaya yanlışlıkla başvurmayı engelleyecek disiplin gerektirir.
Tüm kiracılar aynı veritabanı ve şemayı paylaşır, ancak her kiracı için ayrı tablolar vardır (ör. orders_tenant123).
İzolasyon sınırı: tablo kümesi. Az sayıda kiracı için çalışabilir, ancak ölçeklenmesi zordur: metadata şişmesi, migration script'leri zorlayıcı olur ve sorgu planlaması bozulabilir.
Güvenlik ve tuning: izinler hassas olabilir, ancak operasyonel karmaşıklık yüksektir ve yeni tablo/özellik eklerken hatalar yapmak kolaydır.
Tüm kiracılar aynı tabloları paylaşır; ayırt edici sütun genellikle tenant_id'dir.
İzolasyon sınırı: sorgu ve erişim kontrol katmanınız (genellikle satır düzeyinde güvenlik). Bu model operasyonel olarak verimli—tek şema migrate edilir, tek indeks stratejisi yönetilir—ancak veritabanı güvenliği ve performans izolasyonu açısından en zorlu olanıdır.
Güvenlik ve tuning: doğru yapmak en zor olanıdır çünkü her sorgunun kiracı farkındalığı olmalıdır; aksi halde gürültülü komşu problemi daha olasıdır ve kaynak sınırlama ile dikkatli indeksleme gerekir.
Yararlı bir kural: ne kadar çok paylaşırsanız, yükseltmeler o kadar basitleşir—ama kiracı izolasyonu ve performans izolasyonu kontrollerinde o kadar titiz olmanız gerekir.
Çok kiracılılık yalnızca "birden çok müşteri tek veritabanında" demek değildir. Tehdit modelinizi değiştirir: en büyük risk dışarıdan atlamalar yerine yetkili kullanıcıların kazara (veya kasıtlı) başka bir kiracının verisini görmesidir.
Kimlik doğrulama "sen kimsin?" cevabını verir. Yetkilendirme "neyi erişebilirsin?" sorusunu cevaplar. Çok kiracılı bir veritabanında kiracı bağlamı (tenant_id, account_id, org_id) yetkilendirme sırasında zorunlu olarak uygulanmalıdır—opsiyonel bir filtre gibi görülmemelidir.
Yaygın hata, bir kullanıcı kimlik doğrulandıktan sonra uygulamanın doğal olarak sorguları ayıracağını varsaymaktır. Pratikte ayrım açık ve tutarlı bir kontrol noktasında uygulanmalıdır (ör. veritabanı politikaları veya zorunlu sorgu katmanı).
En basit ve en önemli kural: her SELECT, UPDATE ve DELETE tam olarak bir kiracıya göre sınırlandırılmalıdır.
Bu şunları kapsar:
Kiracı kapsamı opsiyonelse, eninde sonunda atlanacaktır.
Çapraz-kiracı sızıntıları genellikle küçük, rutin hatalardan kaynaklanır:
tenant_id bağlayan yeniden kullanılan prepared statement'larTestler genellikle küçük veri setleri ve temiz varsayımlarla çalışır. Üretim, eşzamanlılık, retry'ler, önbellekler, karışık kiracı verisi ve gerçek kenar durumları ekler.
Bir özellik testleri geçebilir çünkü test veritabanında yalnızca bir kiracı vardır veya fixture'lar kiracılar arasında çakışan ID'leri içermez. En güvenli tasarımlar, yanlışlıkla kapsam dışı bir sorgu yazmayı zorlaştıran yapılardır; her seferinde gözden geçirilmesine güvenmek yerine bunun yazılmasını güçleştirin.
Çok kiracılı bir veritabanındaki temel güvenlik riski basittir: sorguda kiracı filtresini unutmak başka birinin verisini açığa çıkarabilir. Güçlü izolasyon kontrolleri hataların olacağını varsayar ve bu hataları zararsız hâle getirir.
Her kiracıya ait kayıt bir kiracı tanımlayıcı (tenant_id gibi) taşımalıdır ve erişim katmanınız okuma/yazma işlemlerini her zaman bununla sınırlandırmalıdır.
Pratik bir desen "önce kiracı bağlamı": uygulama kiracıyı (alt alan, org ID veya token beyanlarından) çözer, istek bağlamında saklar ve veri erişim kodunuz bu bağlam olmadan çalışmayı reddeder.
Yardımcı korumalar:
tenant_id zorunlu kılın (kiracılar arası çakışmayı önlemek için).tenant_id içerecek şekilde ekleyin, böylece çapraz-kiracı ilişkileri kazara oluşturulamaz.Desteklendiği yerlerde (özellikle PostgreSQL), satır düzeyinde güvenlik kiracı kontrollerini veritabanına taşıyabilir. Politikalar her SELECT/UPDATE/DELETE'i yalnızca o anki kiracıyla eşleşen satırlara kısıtlayabilir.
Bu, "her geliştirici WHERE koşulunu hatırladı" bağımlılığını azaltır ve bazı enjeksiyon veya ORM yanlış kullanımı senaryolarına karşı koruma sağlayabilir. RLS'i tek kilit olarak değil, ek bir kilit olarak değerlendirin.
Kiracılar daha hassas veya sıkı uyumluluk ihtiyaçlarına sahipse, şema veya veritabanı bazında ayırma patlama alanını azaltabilir. Takas, artan operasyonel yük ve karmaşıklıktır.
İzinleri "erişim yok" olacak şekilde tasarlayın:
Bu kontroller birlikte en iyi şekilde çalışır: güçlü kiracı kapsamı, mümkünse veritabanı tarafından zorlanan politikalar ve bir şey kaydığında zararı sınırlayan muhafazakar ayrıcalıklar.
Şifreleme, diğer izolasyon katmanları başarısız olsa bile yardımcı olan birkaç kontrolden biridir. Paylaşılan bir depoda amaç, veriyi taşınırken, beklerken ve uygulamanın hangi kiracı adına hareket ettiğini kanıtlaması sırasında korumaktır.
Taşınan veri için her adımda TLS zorunlu kılın: istemci → API, API → veritabanı ve iç servis çağrıları. Mümkünse veritabanı seviyesinde bunu zorlayın (örneğin TLS olmayan bağlantıları reddetmek) ki "geçici istisnalar" sessizce kalıcı olmasın.
Dinlenme verisi için veritabanı veya depolama seviyesinde şifreleme kullanın (yönetilen disk şifreleme, TDE, şifreli yedekler). Bu, kaybolan ortam, snapshot açıklığı ve bazı altyapı ihlali sınıflarına karşı korur—ama hatalı bir sorgunun başka bir kiracının satırlarını döndürmesini engellemez.
Tek bir paylaşılan şifreleme anahtarı işletilmesi daha basit olan yaklaşımdır (daha az anahtar döndürme, daha az hata modu). Dezavantajı patlama alanıdır: anahtar açığa çıkarsa tüm kiracılar etkilenir.
Kiracı başına anahtarlar patlama alanını azaltır ve bazı kurumsal müşterilerin gereksinimlerini karşılamaya yardımcı olur. Ancak karmaşıklık artar: anahtar yaşam döngüsü yönetimi, döndürme takvimleri ve destek iş akışları (ör. kiracı anahtarı devre dışı bırakırsa ne olur) gerekir.
Pratik bir orta yol, per-kiracı veri anahtarlarını şifrelemek için bir master anahtarın kullanıldığı zarflama (envelope encryption) yöntemidir; bu döndürmeyi yönetilebilir kılar.
Veritabanı kimlik bilgilerini uzun ömürlü yapılandırmalardaki ortam değişkenlerinde saklamak yerine bir sır yöneticisinde saklayın. Kısa ömürlü kimlik bilgileri veya otomatik döndürme tercih edin ve erişimi servis rolüne göre sınırlandırın ki bir bileşenin ele geçirilmesi otomatik olarak her veritabanına erişim sağlamasın.
Kiracı kimliğini güvenlik açısından kritik kabul edin. İstemciden gelen ham tenant_id değerini “doğru” olarak kabul etmeyin. Kiracı bağlamını imzalı token'lara ve sunucu tarafı yetkilendirme kontrollerine bağlayın ve her istekte veritabanı çağrısından önce doğrulayın.
Çok kiracılılık "normal"in ne olduğunu değiştirir. Sadece bir veritabanını izlemiyorsunuz—aynı sistemi paylaşan birçok kiracıyı izliyorsunuz; bir hata çapraz-kiracı açıklamaya dönüşebilir. İyi denetim ve izleme hem olay olasılığını hem de patlama alanını azaltır.
En azından, kiracı verisini okuyabilecek, değiştirebilecek veya erişim verebilecek her eylemi kaydedin. En faydalı denetim olayları şunları yanıtlar:
Ayrıca yönetici eylemlerini kaydedin: kiracı oluşturma, izolasyon politikalarını değiştirme, RLS kuralı düzenleme, anahtar döndürme ve bağlantı dizesi değişiklikleri.
İzleme, sağlıklı SaaS kullanımında beklenmeyen desenleri tespit etmelidir:
Uyarıları eyleme geçirilebilir çalışma kitapçıklarıyla bağlayın: ne kontrol edilmeli, nasıl izole edilmeli ve kimi çağırmalı.
Ayrıcalıklı erişimi bir üretim değişikliği gibi ele alın. En az ayrıcalık rolleri, kısa ömürlü kimlik bilgileri ve hassas operasyonlar (şema değişiklikleri, veri dışa aktarma, politika düzenleme) için onay süreçleri kullanın. Acil durum için bir break-glass hesabı tutun: ayrı kimlik bilgileri, zorunlu bilet/onay, zaman sınırlı erişim ve ekstra günlükleme.
Saklama süresini uyumluluk ve soruşturma ihtiyaçlarına göre ayarlayın, ama erişimi öyle sınırlandırın ki destek personeli sadece kendi kiracısının günlüklerini görebilsin. Müşteri denetim dışa aktarma talep ettiğinde, ham paylaşılan günlükler yerine kiracı filtreli raporlar sağlayın.
Çok kiracılılık, birçok müşterinin aynı veritabanı altyapısını paylaşmasına izin vererek verimliliği artırır. Takası, performansın da paylaşılan bir deneyim hâline gelmesidir: bir kiracı ne yaparsa yapsın diğerlerini etkileyebilir, veriler tamamen izole olsa bile.
"Gürültülü komşu", bir kiracının aktivitesinin o kadar yoğun (veya dalgalı) olmasıdır ki paylaşılan kaynakların adil payını tüketir. Veritabanı "bozulmuş" değildir—sadece o kiracının işini yürütmekle meşguldür, bu yüzden diğerleri daha uzun bekler.
Bir apartmanda ortak su basıncı gibi düşünün: bir birim birden fazla duşu ve çamaşır makinesini aynı anda çalıştırırsa diğerleri zayıf su akışı hisseder.
Her kiracı ayrı satırlar veya şemalar kullansa bile birçok performans-kritik bileşen paylaşılır:
Bu ortak havuzlar dolduğunda gecikme herkes için artar.
Birçok SaaS iş yükü ani patlamalarla gelir: bir içe aktarma, ay sonu raporları, pazarlama kampanyası, saat başında çalışan cron işi.
Patlamalar veritabanı içinde "trafik sıkışıklığı" yaratabilir:
Patlama sadece birkaç dakika sürse bile, kuyrukların boşalması gecikmelere neden olabilir.
Müşteri açısından gürültülü komşu sorunları rastgele ve haksızmış gibi hissedilir. Yaygın belirtiler:
Bu semptomlar, yalnızca daha fazla donanım eklemek yerine performans izolasyonu tekniklerine ihtiyaç duyduğunuzun erken uyarıcılarıdır.
Çok kiracılılık, bir müşterinin veritabanı kapasitesinin adil payından fazlasını alamayacağı gardrails olduğunda en iyi şekilde çalışır. Kaynak izolasyonu, ağır bir kiracının herkesi yavaşlatmasını engelleyen koruyuculardır.
Sık görülen hata, sınırsız bağlantılardır: bir kiracı trafiği aniden yüzlerce oturum açar ve veritabanını tüketir.
İki yerde sert sınırlar koyun:
Veritabanınız doğrudan "kiracı başına bağlantı" uygulayamıyorsa, her kiracıyı ayrılmış bir havuz veya havuz bölümü üzerinden yönlendirerek yaklaşık bir çözüm sunabilirsiniz.
Hız sınırlama, zaman içinde adalettir. Bunu kenara (API gateway/uygulama) yakın uygulayın ve destekleniyorsa veritabanı içinde de (resource groups/workload management) uygulayın.
Örnekler:
Veritabanını "kaçan" sorgulardan koruyun:
Bu kontroller nazikçe başarısız olmalı: net bir hata döndürüp yeniden deneme/geri çekilme önermelidir.
Okuma ağırlıklı trafiği primery'den uzaklaştırın:
Amaç yalnızca hız değil—kilit baskısını ve CPU rekabetini azaltarak gürültülü kiracıların başkalarını etkileme yollarını daraltmaktır.
Çok kiracılı performans sorunları genelde "veritabanı yavaş" gibi görünür, ama kök neden genellikle veri modeli: kiracı verisinin nasıl anahtarladığı, filtrelendiği, indekslendiği ve fiziksel olarak düzenlendiğidir. İyi modelleme kiracıya göre sorguları doğal olarak hızlı yapar; kötü modelleme veritabanını gereksiz yere zorlar.
Çoğu SaaS sorgusu bir kiracı tanımlayıcısı içermelidir. Bunu açık modelleyin (örneğin tenant_id) ve indeksleri bununla başlayacak şekilde tasarlayın. Pratikte (tenant_id, created_at) veya (tenant_id, status) gibi bileşik indeksler, sadece created_at veya status üzerinde indekslemeden çok daha faydalıdır.
Ayrıca benzersizlik için: eğer e-postalar sadece kiracı bazında benzersizse, bunu global email yerine (tenant_id, email) ile zorlayın.
Yavaş sorgu örüntülerinden biri kazara çapraz-kiracı taramasıdır: kiracı filtresi unutulur ve büyük bir kısmı taranır.
Güvenli yolu kolay yol yapın:
Partitioning, her sorgunun bakması gereken veri miktarını azaltabilir. Kiracılar büyük ve dengesizse tenant bazlı partition düşünün. Erişim çoğunlukla güncelse zamana göre partitioning tercih edin; her partition içinde tenant_id lider kolon olarak indekslenebilir.
Tek bir veritabanı peak throughput'u karşılayamıyorsa veya bir kiracının iş yükü herkesi tehdit ediyorsa sharding düşünün.
"Hot kiracılar" orantısız okuma/yazma hacmi, kilit çatışması veya aşırı büyük indekslerle ortaya çıkar.
Bunları kiracı başına sorgu süresi, okunan satır sayısı ve yazma oranını izleyerek tespit edin. Bir kiracı baskınsa onları izole edin: ayrı bir shard/veritabanına taşıyın, büyük tabloları kiracı bazında bölün veya diğer kiracıların hızını korumak için özel önbellekler ve oran sınırlamaları ekleyin.
Çok kiracılılık genelde veritabanının bunu yapamamasından değil, günlük operasyonların küçük tutarsızlıklara izin vermesinden başarısız olur. Amaç, her değişiklikte, işte ve deploy'da güvenli yolu varsayılan hâle getirmektir.
Tek bir canonical kiracı tanımlayıcı seçin (ör. tenant_id) ve bunu tablolar, indeksler, günlükler ve API'lerde tutarlı şekilde kullanın. Tutarlılık hem güvenlik hatalarını (yanlış kiracı sorgulama) hem de performans sürprizlerini (doğru bileşik indekslerin eksikliği) azaltır.
Pratik korumalar:
tenant_id zorunlu) gerektirtenant_id ile başlayan bileşik indeksler ekleyintenant_id içerecek şekilde veya check constraint'ler) ki hatalı yazmalar erken yakalansınAsync worker'lar genelde kiracı bağlamını isteği başlatan bağlamdan bağımsız yürüttükleri için çapraz-kiracı olaylarının kaynağıdır.
Yardımcı operasyonel desenler:
tenant_id'yi açıkça geçin; dolaylı bağlama güvenmeyintenant_id kaydedin ki soruşturma kolay olsunŞema ve veri migration'ları kusursuz, senkronize bir dağıtım olmadan deploy edilebilmelidir.
Rolling değişiklikleri kullanın:
Bilerek başka bir kiracının verisine erişmeyi deneyen otomatik negatif testler ekleyin. Bunları sürüm engelleyiciler olarak ele alın.
Örnekler:
tenant_id ile arka plan işlerini çalıştırıp sert hata aldığını doğrulayınYedekler "veritabanını kopyala" demek kolaydır ama çok kiracılı bir veritabanında güvenli şekilde uygulamak zor olabilir. Birçok müşteri tabloyu paylaştığında, tek bir kiracıyı nasıl kurtaracağınız konusunda bir planınız olmalıdır.
Tam veritabanı yedeği hâlâ felaket kurtarma için temel teşkil eder, ama günlük destek vakaları için yeterli değildir. Yaygın yaklaşımlar:
tenant_id ile filtrelenmiş mantıksal dump'lar) tek bir kiracıyı kurtarmak içinMantıksal dışa aktarmalara güveniyorsanız, dışa aktarma işini üretim kodu gibi ele alın: izolasyonu satır düzeyinde güvenlik veya benzeri mekanizmalarla zorlayın, tek bir WHERE koşuluna güvenmeyin.
Gizlilik talepleri (dışa aktarma, silme) hem güvenlik hem performansı etkileyen işlerdir. Tekrarlanabilir, denetlenebilir iş akışları inşa edin:
En büyük risk bir hacker değil—aceleci bir operatördür. İnsan hatasını azaltmak için korumalar:
tenant_id dağılımını doğrulayınBir DR tatbikatından sonra sadece "uygulama açık" demeyin. Otomatik kontroller çalıştırın: kiracılar arası örnek sorgular, denetim günlüklerinin gözden geçirilmesi ve şifreleme anahtarlarının ve erişim rollerinin doğru scoped olduğunun doğrulanması.
Çok kiracılılık genelde SaaS için iyi bir varsayımdır, ama kalıcı bir karar olmak zorunda değildir. Ürün ve müşteri karışımı değiştikçe, "tek paylaşılan depo" yaklaşımı iş riski veya teslimat hızını yavaşlatmaya başlayabilir.
Daha izole yaklaşıma geçmeyi düşünün:
Daha fazla izolasyon genelde daha yüksek altyapı gideri, daha fazla operasyonel yük (migration, izleme, on-call) ve daha fazla sürüm koordinasyonu anlamına gelir. Takas, daha net performans garantileri ve uyumluluk konuşmalarını kolaylaştırmaktır.
İzolasyon seçeneklerini değerlendiriyorsanız, ilgili rehberleri /blog'da inceleyin veya planlar ve dağıtım seçeneklerini /pricing üzerinde karşılaştırın.
Hızlıca bir SaaS prototipi oluşturup çok kiracılı varsayımlarınızı (kiracı kapsamı, RLS uyumlu şemalar, throttling ve operasyonel iş akışları) erken test etmek istiyorsanız, Koder.ai gibi bir platform sohbetten React + Go + PostgreSQL uygulaması oluşturmanıza, planlama modunda yinelemenize ve snapshot/rollback ile dağıtmanıza yardımcı olabilir—hazır olduğunuzda kaynak kodunu dışa aktarabilirsiniz.
Çok kiracılı bir veritabanı, birden fazla müşterinin aynı veritabanı altyapısını (çoğu zaman aynı şema dahil) paylaştığı bir düzenlemedir; uygulama ve/veya veritabanı her kiracının yalnızca kendi verisine erişebilmesini sağlar. Temel gereklilik, her okuma ve yazmanın katı kiracı kapsamı ile yapılmasıdır.
Çok kiracılılık genellikle şu sebeplerle tercih edilir:
Takas, izole etme ve performans korumaları kasıtlı olarak inşa edilmelidir; aksi halde riskler artar.
Yaygın modeller (daha fazla izolasyondan daha fazlasına doğru):
Seçiminiz izolasyon sınırını ve operasyonel yükü belirler.
Risk modeli, dışarıdan gelen saldırılardan çok kiracılar arası erişim ile ilgili hata olasılıklarına kayar. tenant_id gibi kiracı bağlamı bir yetkilendirme gereksinimi olarak ele alınmalı; isteğe bağlı bir filtre gibi davranılmamalıdır. Üretimde eşzamanlılık, önbellekler, retry'ler ve arka plan işleri gibi gerçekler de hesaba katılmalıdır.
En yaygın nedenler şunlardır:
tenant_id ile bağlanmasıKayıt dışı sorguların çalışmasını zorlaştıracak gardrails tasarlayın.
Satır düzeyinde güvenlik (RLS), kiracı kontrollerini veritabanının içine taşıyarak SELECT/UPDATE/DELETE'i yalnızca o anki kiracıyla eşleşen satırlara kısıtlayabilir. Bu, "her geliştirici WHERE koşulunu hatırladı" varsayımına daha az bağımlı olmanızı sağlar. Ancak RLS, uygulama katmanındaki kapsamla, en az ayrıcalık ilkesiyle ve sağlam testlerle desteklenmelidir; tek kilit olarak görülmemelidir.
Uygulanabilir bir temel şunları içerir:
tenant_idtenant_id içeren birleşik benzersizlik ve yabancı anahtarlarŞifreleme fayda sağlar ama farklı riskleri kapatır:
Ayrıca kiracı kimliğini güvenlik açısından kritik sayın: ham değerini istemciden doğrulanmamış biçimde kabul etmeyin; imzalı token'larla ve sunucu tarafı kontrollerle bağlayın.
Gürültülü komşu, bir kiracının paylaşılan kaynakların (CPU, bellek, I/O, bağlantılar) çoğunu tüketmesi sonucu diğerlerinin gecikme yaşamasıdır. Pratik önlemler:
Amaç sadece ham verim değil, adaleti sağlamaktır.
Ayrımlaşma artırmanın zamanı gelmiş olabilir:
Hibrit yaklaşımlar: üst düzey kiracıları ayrı veritabanlarına ayırmak, paylaşılan varsayılan model ile kurumsal için izole seçenekler sunmak veya işlem yükünü paylaşıp analitiği ayrı depolara taşımak.
Amaç, hataların güvenli bir şekilde başarısız olmasını sağlamaktır.
tenant_id