Okuma/yazma yolları, gecikme, tutarlılık ve büyüme ihtiyaçlarına göre veritabanı seçmenin pratik rehberi—trendlerin gereksiz teknik borç yaratmasına izin vermeyin.
“Popüler” olduğu için bir veritabanı seçmek, ihtiyacınız olup olmadığını kontrol etmeden bir araç almak gibidir—scooter mı, kamyonet mi yoksa otobüs mü gerektiğini anlamadan. Trendler başkalarının ürününde, ekip büyüklüğünde, bütçesinde ve risk toleransında işe yarayanı yansıtır. Veritabanınız sizin iş yükünüze uymalı: uygulamanızın gün boyunca gerçekten ne yaptığına.
İş yükü, sisteminizin üretimdeki gerçek davranışıdır:
Bu davranışlar sizin erişim desenlerinizdir—uygulamanızın veriye dokunuşunun tekrarlayan yolları. Erişim desenlerini açıkça tanımlayabilirseniz, veritabanı seçimi çok daha az gizemli hale gelir.
Tek beden nadiren herkese uyar. Birçok başarılı sistem hibrit bir yaklaşım kullanır: işlemler için optimize edilmiş bir veritabanı, analiz için başka bir veritabanı ve bazen özel bir arama motoru veya önbellek. Bu, “gereksiz karmaşıklık” değil—farklı erişim desenlerinin farklı depolama ve sorgu motorlarından yararlandığını kabul etmektir.
“SQL vs NoSQL” karşılaştırmasına ya da moda olanı kovalamadan önce en önemli 5–10 okuma ve yazınızı yazın. Oradan başlayın; gerisi ayrıntıdır.
Bir erişim deseni, uygulamanızın günlük olarak veriye nasıl dokunduğunun pratik tarifidir: neyi okur, neyi yazar, ne sıklıkla, ne kadar hızlı ve hangi biçimlerde. Bu, verinizin ne olduğundan (“siparişler” veya “kullanıcılar”) çok, onunla ne yaptığınızla (“ID ile 10.000 defa sipariş getir” veya “geçen ayın tüm siparişlerini tarayıp rapor oluştur”) ilgilidir.
Çoğu okuma trafiği birkaç tanınabilir kovaya girer:
Bir sosyal akış, karışık okuma şekilleri için iyi bir örnektir: profiller için nokta sorguları, “son gönderiler” için aralık okumaları ve sayımlar için agregasyonlar yapılabilir.
Yazma desenleri de en az okumalar kadar önemlidir:
Loglar genellikle “yazma-ağırlıklı ve eklemeye dayalıdır” (çok sayıda insert, az güncelleme). Siparişler genellikle “önce yazma sonra güncelleme” şeklindedir (oluşturma, sonra durum değişiklikleri).
Birçok ürün her şeyi aynı anda ister: uygulama için hızlı nokta okumaları, müşteri desteği için karmaşık sorgular ve analiz için büyük taramalar. Tek bir veritabanı bazı karışımları iyi idare edebilir, fakat belirli kombinasyonlar birbirleriyle çatışır—örneğin ağır analitik taramalar, checkout veya bir akışı besleyen düşük gecikmeli küçük okumaları yavaşlatabilir.
Erişim desenlerinizi açıkça adlandırabildiğinizde, veritabanlarını popülerlik yerine gerçek davranışa göre değerlendirebilirsiniz.
Veritabanı markalarını karşılaştırmadan önce gerçekte hangi işi yaptığınızı adlandırın. Çoğu ürün tek bir “iş yükü” değildir—aynı anda yan yana duran birkaç farklı iş yüküdür (ve bazen rekabet halindedir). Bu sınıflandırmayı erken doğru yapmak, veritabanını hiç optimize edilmediği bir işe zorlamamanızı sağlar.
OLTP çoğu uygulamanın günlük ritmidir: birçok küçük okuma ve yazma, çok sayıda eşzamanlı kullanıcı ve kısa sürede bitmesi gereken istekler.
Düşünün: “sepete ürün ekle”, “sipariş oluştur”, “adres değiştir”, “stok kontrol et”. Bu işlemler kısa, hedefe yönelik ve doğruluk açısından hassastır. Bir ödeme alındıysa kaybolmamalı; bir koltuk rezerve edildiyse iki kişiye aynı koltuk verilmemeli.
OLTP genellikle yüksek eşzamanlılığı iyi idare eden ve işlemler ile veri bütünlüğü konusunda net garantiler veren sistemlere yönlendirir.
Analitik işi tersine çevirir: daha az sorgu, ama her biri çok daha fazla veriye dokunur.
Düşünün: “geçen çeyrekte bölgeye göre gelir”, “kanala göre dönüşüm”, “kategori başına en iyi ürünler”, “günlük aktif kullanıcı trendi”. Bu sorgular genellikle çok sayıda satır tarar, grupla, agregasyon yapar ve sıralar. Gecikme beklentileri daha gevşek olabilir (saniyeler uygun olabilir), ancak ağır taramaların maliyeti önemlidir—özellikle panolar gün boyu çalışıyorsa.
OLAP tarzı taramaları checkout'u besleyen aynı sistemde çalıştırmaya kalkarsanız genellikle ikisinden biri zarar görür.
Zaman serisi ve loglar genellikle eklemeye dayalıdır: yeni olaylar sürekli gelir ve çoğunlukla zaman aralıklarına göre sorgulanır.
Düşünün: metrikler, tıklama akışları, cihaz telemetri, denetim logları. Yaygın ihtiyaçlar arasında saklama politikaları (eski veriyi silme/sona erdirme), rollup'lar (ham olayları kısa süre saklama, özetleri uzun süre saklama) ve zirvelerde hızlı yazma bulunur.
Bu iş yükü karmaşık joinlardan ziyade çok sayıda zaman damgalı kaydı verimli biçimde ingest etmek ve zaman içinde depolamayı öngörülebilir kılmak üzerinedir.
Arama sadece “satırı bulmak” değildir. Metin eşleştirme, alaka sıralaması, kısmi eşleşmeler ve kullanıcı dostu filtreleme gerektirir.
Düşünün: ürünleri anahtar kelimelere göre arama, biletleri ifadelerle bulma, facetler ile filtreleme (marka, fiyat aralığı, renk) ve “en iyi eşleşme”ye göre sıralama. Bu özellikler genellikle özel indeksleme ve sorgu yetenekleri gerektirir; genel amaçlı veritabanları bunları taklit edebilir ama nadiren mükemmel olur.
Arama temel ürün özelliği ise başlangıçtan itibaren ayrı bir iş yükü olarak değerlendirin; “sonradan ekleyeceğiz” detay olarak bırakmayın.
Performans tek bir sayı değildir. İki veritabanı ikisi de “hızlı” görünse de kullanıcılara ve işletmecilere tamamen farklı hissiyat verebilir. İyi seçim yapmak için insanların deneyimlediği şeyi (gecikme) sistemin sürdürmesi gereken şeyi (throughput) ayırın ve varsayımlarınızı zirvelerle stres testine tabi tutun.
Gecikme, tek bir isteğin ne kadar sürdüğüdür—“butona tıkla, sonucu al.” Kullanıcılar gecikmeyi doğrudan hisseder.
Throughput ise saniyede kaç isteği işleyebileceğinizdir—sistem toplamda ne kadar trafik kaldırabilir.
Bir veritabanı işleri verimli gruplandırarak yüksek throughput sağlayabilir, ama hala isteğe özel gecikme hissedilebilir. Diğeri hızlı nokta okumalar için optimize edebilir ama çok sayıda yazı geldiğinde zorlanabilir.
Ortalama gecikme acıyı gizler. Eğer 99 istek 50 ms'de bitip 1 istek 2 saniye sürüyorsa, ortalama iyi görünse de o %1 “uygulama yavaş” anıdır.
İşte P99 gecikmesi bunun anlamıdır: en yavaş %1 isteğin süresi. Kullanıcıya dönük özellikler (checkout, giriş, arama) için P99 sıklıkla veritabanı tasarımınızın güvenilir olup olmadığını belirleyen metriktir.
Çoğu sistem ortalama trafikte başarısız olmaz; zirvelerde başarısız olur: bir pazarlama e-postası, önemli haber anı, maaş günü, ay sonu raporlaması.
Zirveler veritabanı konuşmasını değiştirir:
Önbellekleme, okuma-ağırlıklı iş yüklerini küçük gösterir—ta ki cache miss olana kadar.
Eğer çoğu okuma cache'e düşüyorsa, veritabanınız esasen yazmaları ve ara sıra pahalı okumaları sunuyor demektir. Bu, her okumanın veritabanına düştüğü bir sisteme göre farklı seçimleri tercih ettirir. Soğuk cache olaylarını ve miss'lerin kuyruğunu planlayın, sadece ideal yolu değil.
Veritabanı seçimi sadece hızla ilgili değildir. Ne kadar yanlış olmasına izin verildiği, ne kadar kesinti tolere edilebileceği ve kullanıcılarınızın nerede olduğu da önemlidir.
Her zaman doğru olması gereken verileri tanımlayarak başlayın. Ödemeler, hesap bakiyeleri ve stok sayımları klasik örneklerdir. Bir müşteri iki kez ücretlendirilirse veya stok aşımı olursa maliyet sadece yavaş bir uygulama değil; geri ödemeler, destek talepleri ve güven kaybıdır.
Bu parçalar için genellikle güçlü garantiler istersiniz: yazmalar onaylanmadan tamamlanmış sayılmamalı ve okuyucular yarım kalmış güncellemeler görmemelidir. Güçlü doğruluk esnekliği azaltır: bazı ölçeklendirme stratejileri zorlaşır ve bölgeler arası yazmalar yavaşlayabilir.
Sonra veritabanı 5 dakika kullanılamazsa ne olur karar verin.
Eğer kesinti “siparişler durur ve gelir durur” anlamına geliyorsa daha yüksek erişilebilirlik gerekir: otomatik failover, iyi yedeklemeler ve uygulamayı çevrimdışı yapmadan bakım planı. Kesinti “iç panolar gecikir” anlamına geliyorsa daha basit kurulumlar kabul edilebilir.
Daha yüksek erişilebilirlik genellikle maliyeti ve işletme karmaşıklığını artırır (daha fazla replika, daha fazla izleme, daha dikkatli yükseltmeler). Önemli olan bu yatırımı iş etkisine göre eşleştirmektir.
Kullanıcılarınızın çoğu tek bir bölgede ise veriyi tek yerde tutmak daha ucuz ve hızlı olabilir. Kullanıcılar kıtalar arasıysa veya veri yerel düzenlemeleri varsa çok bölgeli replikasyon gerekebilir.
Çok bölgeli tasarımlar kullanıcı deneyimini ve dayanıklılığı artırır, ama zorlu seçimler getirir: biraz eski okumalara izin mi vereceksiniz yoksa her şeyi mükemmel senkron tutmak için yazmaları mı yavaşlatacaksınız? Doğru cevap iş yükünüzün toleransına bağlıdır.
Çoğu “veritabanı tartışması” aslında sorgu biçimleri hakkındadır. Uygulamanızın sorması gereken soruları—joinler, agregasyonlar, filtreler, zaman pencereleri—biliyorsanız, veritabanı seçeneklerini genellikle hızla daraltabilirsiniz.
İlişkisel model, esnek filtreleme ve birden çok varlık arasında join gerektiğinde parlak olur (müşteriler → siparişler → ürünler), özellikle de gereksinimler evrildikçe. Ürününüz “X satan ve Y iade eden tüm müşterileri göster” gibi ad-hoc raporlama gerektiriyorsa SQL ve joinler zaman içinde daha basit kalır.
Sorgularınız öngörülebilir ve çoğunlukla birincil anahtarla okunuyorsa (“user_id ile profili al”), belge ya da anahtar-değer modeli iyi çalışabilir—genellikle okuma sırasında kullanılan şekilde veriyi birlikte depolayarak. Takas şu ki, joinlerden kaçınmak için veri çoğaltma gerekebilir ve bu yazma tarafında ve güncellemelerde karmaşıklığı artırır.
İndeksler veritabanına, “bunlar benim erişim desenlerim” der. Mockup'ta iyi görünen bir sorgu, indexlenmemiş alanlarda filtreleme veya sıralama yaparsa yavaşlayabilir.
Yardımcı bir kural: sık yapılan her filtre, sıralama veya join anahtarı için bir indeks planı olmalıdır. Ama indeksler bedava değildir: depolama tüketir ve yazmaları ağırlaştırır.
“Hızlı yazma” iddiaları genellikle ikincil indeksler, compaction, replikasyon veya denormalize edilmiş verinin birden fazla kopyasını güncelleme gibi ek işler (yazma amplifikasyonu) göz ardı eder. Okumaları optimize etmek için indeks eklemek veya dokümanları çoğaltmak, yüksek yazma iş yükünü sessizce tıkanıklığa dönüştürebilir.
Şemasız olmak yapısız olmak demek değildir. Esnek şemalar erken yinelemeyi hızlandırır, ama kural koyulmazsa tutarsız alanlar, zor debuglanan sorgular ve ileride pahalı migration'lar yaratır. Birçok ekip, çok sayıda özellik veya uzun saklama bekleniyorsa, daha sıkı bir şema ve net kısıtlar toplam maliyeti azaltır—başta daha yavaş hissettirse bile.
Popüler olduğu için bir veritabanı seçmek genellikle sahip olmanın sıkıcı yanlarında ters teper: çalışır halde tutmak, güvenli tutmak ve aylık faturayı ödemek. Aynı fonksiyonel gereksinimi karşılayan iki veritabanı işletme çabası ve toplam maliyet açısından çok farklı olabilir.
Erken sorun: kim bu sistemi gece 2'de çalıştıracak? Yedekler, zaman içinde geri alma, yükseltmeler, patchleme, failover tatbikatları ve izleme “sonra” işleri değildir—riskinizi ve kadroyu şekillendirir.
Managed servisler yükü azaltabilir ama sıfırlamaz. Bazı sistemler düzenli compaction, hassas tuning veya yavaşlamaları önlemek için derin uzmanlık ister. Diğerleri şema değişikliklerini zorlaştırır veya özel migration kitaplıkları gerektirir. Küçük bir ekip için işletmesi daha kolay bir veritabanı, kağıt üzerinde “mükemmel” görünen bir tercihten daha iyi olabilir.
Veritabanı maliyetleri genellikle şunlardan gelir:
İndeksler ve yoğun yazma I/O ve depolamayı çoğaltabilir, veri seti küçük olsa bile.
Tescilli sorgu dilleri, benzersiz tutarlılık özellikleri veya serverless “sihr-i” hızla teslimatı artırabilir—ama gelecekte taşınmayı zorlaştırabilir. Verileri dışa aktarabiliyor musunuz, lokal test için çalıştırabiliyor musunuz veya sağlayıcı değiştirmeden uygulamayı yeniden yazmadan çalıştırabiliyor musunuz düşünün.
En azından şunları doğrulayın: transit/depolama şifreleme, anahtar yönetimi seçenekleri, denetleme, erişim kontrolleri ve saklama politikaları. Uyumluluk gereksinimleri çoğu zaman trend kararı yerine “kabul edilebilir” kararını belirler.
Erişim desenlerinizi (ne okuduğunuz, ne yazdığınız, ne sıklıkta ve hangi zirvelerle) tanımladıktan sonra “doğru” veritabanı ailesi genellikle daha net olur. Amaç en popüler aracı seçmek değil—iş yükünüz altında doğru kalan en basit sistemi seçmektir.
Güçlü tutarlılık, belirgin ilişkiler ve güvenilir işlemler gerektiğinde bir ilişkisel veritabanı seçin—siparişler, ödemeler, stoklar, izinler, zamanlama. Sık sık varlıklar arasında sorgulama yapıyorsanız (“açık faturası olan müşteriler son 30 gün”), SQL genellikle uygulama karmaşıklığını azaltır.
Bir sezgi: ekibiniz joinleri, kısıtları ve işlemleri kodda yeniden yazmaya başlıyorsa muhtemelen ilişkisel bir veritabanı istersiniz.
Doküman veritabanı, genelde tüm nesneleri bütün halinde okuyup yazdığınız, yapısı değişken objeler için uygundur: kullanıcı profilleri, içerik sayfaları, isteğe bağlı alanlı ürün katalogları veya ayarlar. Tipik sorgu “user_id ile profili getir” ise dokümanlar veriyi birlikte tutarak iyi çalışır.
Sorgularınız çok ilişkisel hale geliyorsa (çoklu doküman arası sorgular) veya çoklu varlık için işlem garantilerine ihtiyaç duyuyorsanız dikkatli olun.
Anahtar-değer sistemler, önbellekleme, oturumlar, hız sınırlama, feature flagler ve erişim deseni “anahtarla al/ata” olan kısa ömürlü durum için uygundur. Genellikle birincil kalıcı kayıt değil, tamamlayıcı sistemdir.
Dayanıklı iş verisi saklıyorsanız, tahliye (eviction), yeniden başlatmalar veya replikasyon gecikmeleri durumunda ne olacağını sorun.
Analitik—panolar, kohort tutma, gelir rollupları, büyük tarihsel verilerde “group by” sorguları—için kolon bazlı/warehouselar üstün gelir çünkü çok sayıda satırı tarayıp agregasyon yapmaya optimize edilmiştir.
Pratik bir ayrım: OLTP yazmalarınızı birincil veritabanında tutun ve raporlama için veriyi bir ambar besleyin. Bu, müşteriye yönelik sorguları BI yükleriyle yavaşlatmaktan kaçınır.
Birçok başarılı ürün “bir veritabanı seçmez.” Her büyük erişim desenini en iyi şekilde karşılayan en basit depoya eşler; bu bazen iki veya üç veritabanı anlamına gelir.
Bir online mağaza genellikle üç çok farklı iş yüküne sahiptir:
Ürün birleşik hissedilir, ama depolama erişim desenine göre uzmanlaşmıştır.
Bir B2B SaaS aracı temel varlıkları (projeler, faturalar, ticketlar) işlem veritabanında tutabilir, ama yine de ihtiyaçları olabilir:
IoT platformları telemetri patlamaları ingest eder, sonra zaman penceresi panoları için geri okur.
Yaygın bir ayrım: yakın dönemin hızlı ingest'i için hızlı bir depolama, daha ucuz uzun vadeli saklama için arşiv, ve agregatlar için bir analiz motoru.
Ana fikir: erişim desenleri ayrıştığında farklı bileşenler genellikle farklı veritabanları kullanmalıdır.
Veritabanı uyumsuzluğu genellikle biriken küçük “yama”larla kendini gösterir. Eğer ekibiniz veritabanıyla uğraşmaya ürün özellikleri geliştirmekten daha fazla zaman harcıyorsa dikkat edin—bunlar genellikle tuning değil, erişim deseni sorunlarıdır.
Y tekrarlanan işaretler:
Eğer veritabanını normal işletme için süper kahraman çabası gerekiyorsa, iş yükü ile veritabanı ailesi muhtemelen uyuşmuyor.
Popüler olduğu için veritabanı seçmek uzun vadeli maliyetlere yol açabilir:
Fatura ölçek arttığında ya da gereksinimler değiştiğinde gelir ve gerçek çözüm genellikle ağrılı bir re-platform olur.
Mükemmel gözlemlere ihtiyacınız yok, ama birkaç sinyale ihtiyacınız var:
En sık erişim desenlerini (okumalar/yazmalar, ana sorgular, tepe oranlar), veri hacmi varsayımlarını ve “vazgeçilemezleri” (tutarlılık, erişilebilirlik, bölge kısıtları) yazın. Panolara ve en kötü sorgulara örnekler ekleyin. Kısa bu kayıt gelecekte karar vermeyi hızlandırır ve veritabanının ne zaman gerçeği yansıtmadığının netleşmesini sağlar.
Veritabanı seçmek, popülerlik yarışması değil, gereksinim toplama işi olarak ele alındığında kolaylaşır. Bu kontrol listesini kullanarak muğlâk “ölçeklenebilir bir şey” ihtiyacını somut girdilere dönüştürün.
Önce düz dille cevaplayın, sonra mümkünse sayılar ekleyin:
Sol tarafa kriterleri, üst tarafa adayları koyan tek sayfalık bir tablo yapın. Her kriteri zorunlu veya olması iyi olarak işaretleyin, sonra her veritabanını 0–2 arası puanlayın.
En azından şunları dahil edin: sorgu uyumu, ölçek yaklaşımı, tutarlılık ihtiyaçları, işletme çabası, ekosistem/araçlar ve maliyet öngörülebilirliği.
Temsili veri ve gerçek sorgularla test edin, oyuncak örneklerle değil. En önemli sorguları ve gerçekçi bir yazma desenini (zirveler dahil) yeniden oluşturun.
Eğer hızlı ürün denemeleri yapıyorsanız, Koder.ai gibi bir ortam size React ön yüzü, Go + PostgreSQL arka ucu oluşturup “en önemli 5 sorgunuzun” nasıl davrandığını ölçmenizi sağlar: kaynak kodu dışa aktarabilme ve şema/migration kontrolü, sizi köşeye sıkıştıracak yanlış adımları engeller.
“Geçti”nin ne demek olduğunu baştan yazın: gecikme hedefleri, kabul edilebilir hata oranları, gereken operasyon adımları (yedek, şema değişikliği) ve beklenen aylık maliyet tahmini. Bir aday PoC'de bir zorunlu gereksinimi karşılayamıyorsa erken elen.
Geleceğe hazırlık, ilk günden “en ölçeklenebilir” veritabanını seçmek değildir. Erişim desenleri değiştiğinde çevik kalmanızı sağlayacak bilinçli seçimler yapmaktır.
İş yükünüz çoğunlukla işlemsel okuma/yazma ve basit sorgulardan oluşuyorsa, ilişkisel veritabanı genellikle güvenilir bir ürün çıkarma yoludur. Amaç hızlı gönderimdir: tahmin edilebilir performans, net doğruluk garantileri ve ekibin zaten bildiği araçlar.
“Geleceğe hazırlık” burada erken geri döndürülemez taahhütlerden kaçınmak demektir—özellikle ihtiyacınız kanıtlanmadan uzmanlaşmış bir depoya geçmemek.
Açık bir veri erişim katmanı (veya servis sınırı) oluşturun ki uygulamanın geri kalanı veritabanına özgü takıntılara bağlı kalmasın. Sorgu mantığını merkezileştirin, sözleşmeler (girdi/çıktı) tanımlayın ve şema değişikliklerini normal geliştirme sürecinin bir parçası olarak görün.
Bazı pratik alışkanlıklar:
Birçok ürün sonunda iki yola ihtiyaç duyar: gün içi işlemler için OLTP ve raporlama/analiz için OLAP. Analitik sorgular üretimi etkilemeye başladığında ya da farklı saklama/partition ihtiyaçları ortaya çıktığında ayırın.
Bu iki sistemi hizalı tutmak için olay/ veri tanımlarını standardize edin, pipeline'ları otomatikleştirin ve sistemler arasındaki toplamları (ör. günlük satışlar) uzlaştırın ki “gerçek” parçalanmasın.
Eğer somut bir sonraki adım istiyorsanız, ekibinizin yeniden kullanabileceği hafif bir migration plan şablonu oluşturun: /blog/database-migration-checklist.
Bir erişim deseni, uygulamanızın üretimde veriye dokunuşunun tekrarlanabilir tanımıdır: ne okur/yazar, ne sıklıkla, ne kadar hızlı ve hangi sorgu biçimleriyle (nokta sorguları, aralık taramaları, joinler, agregasyonlar, zaman pencereleri vb.). "Kullanıcılar ve siparişlerimiz var" demekten daha uygulanabilir çünkü doğrudan indekslere, şema seçimlerine ve veritabanı uyumuna bağlanır.
Çünkü “popüler” olan başkasının kısıtlarını ve ihtiyaçlarını yansıtır, sizinkileri değil. Aynı veritabanı bir iş yükü için harika olabilir (ör. OLTP) ama başka bir iş yükü (ör. ağır analiz taramaları) için eziyet olabilir. Önce en önemli 5–10 okuma ve yazmayı listeleyin, sonra veritabanlarını bu davranışlara göre değerlendirin; marka momentumu yerine gerçek ihtiyaçlara bakın.
Bu doküman, seçenekleri karşılaştırmak için gereksinimleriniz olur.
OLTP, birçok küçük, eşzamanlı ve doğruluk hassasiyeti yüksek işlemdir (checkout, stok güncelleme, hesap değişiklikleri) — işlemler ve kısıtlar önemlidir.
OLAP/analitik ise daha az sayıdaki, fakat çok daha fazla veriye dokunan sorgulardır (taramalar, group-by, dashboardlar) — saniye düzeyinde gecikme kabul edilebilir, fakat ağır okumalar pahalıdır.
Bu iki tip aynı sistemde karıştırılırsa genellikle analitik taramalar kullanıcıya dönük gecikmeyi kötü etkiler.
p95/p99 gecikmesini inceleyin; ortalamalar yanıltıcıdır. En yavaş %1 istek saniyeler alıyorsa, kullanıcılar uygulamayı güvenilmez olarak algılar. Kritik uç noktalar (giriş, ödeme, arama) için p95/p99'u ayrı takip edin ve bunları veritabanı metrikleriyle (kilitler, replikasyon gecikmesi, I/O doygunluğu) korele edin.
Çoğu durumda ihtiyaçlar çakışır:
Her erişim deseni için uzmanlaşmış depolar kullanmak, hepsini tek veritabanında zorlamak yerine genellikle daha basittir.
Önbellekleme veritabanının üzerindeki okuma iş yükünü küçültmüş gibi gösterebilir—ta ki cache miss veya purge olana dek.
Önbellek problemleri geçici olarak sorunları gizleyebilir ama miss'ler veritabanını boğarsa uç noktada çöküşlere sebep olabilir.
Güçlü doğruluk, işlemler ve güncellemelerin görünürlüğü konusunda garanti ister (yarım kalmış güncellemeler olmamalı). Bu özellikle ödemeler, bakiye, stok ve rezervasyonlar için önemlidir.
Takaslar şunları getirebilir:
Hangi verinin “asla yanlış olmaması” gerektiğini açıkça tanımlayın; geri kalanlar tutarsız/ gecikmeli olabilir.
İndeksleme, iş yükünüz ile veritabanı arasındaki performans sözleşmesidir. Sık olan şunlara indeks planı olmalı:
Ancak indeksler depolama kullanır ve yazmaları ağırlaştırır (yazma amplifikasyonu). Amacınız gerçekten sık yaptığınız şeyleri indekslemek olmalı, her şeyi değil.
İyi bir PoC mini bir üretim provası gibidir:
Bir aday must-have gereksinimi PoC'de karşılamıyorsa, erken elleyin.
