Nesne depolama vs veritabanı blob'ları: hızlı, ucuz yüklemeler

Kullanıcı yüklemelerindeki asıl sorun

Kullanıcı yüklemeleri basit gözükür: bir dosya kabul et, kaydet, sonra göster. Az kullanıcı ve küçük dosyalarla bu işler. Sonra hacim artar, dosyalar büyür ve sorun yükleme düğmesiyle alakası olmayan yerlerde ortaya çıkar.

İndirmeler yavaşlar çünkü uygulama sunucunuz ya da veritabanınız ağır yükü taşıyor. Yedeklemeler devasa ve yavaş olur; geri yüklemeler, ihtiyaç duyduğunuz anda daha uzun sürer. Depolama faturaları ve bant genişliği (egress) faturaları, dosyalar verimsiz servis edildiğinde, çoğaltıldığında veya hiç temizlenmediğinde fırlayabilir.

İstediğiniz genellikle sıkıcı ama güvenilir bir şeydir: yük altında hızlı aktarım, net erişim kuralları, basit operasyonlar (yedek, geri yükleme, temizlik) ve kullanım arttıkça öngörülebilir kalan maliyetler.

Buna ulaşmak için sık karışan iki şeyi ayırın:

Meta veri dosya hakkında küçük bilgiler demektir: kimin dosyayı yüklediği, adı, boyutu, tipi, ne zaman yüklendiği ve nerede durduğu. Bunlar sorgulama, filtreleme ve kullanıcılar, projeler ve izinlerle join gerektirdiği için veritabanına (ör. Postgres) ait olmalı.

Dosya baytları dosyanın gerçek içeriğidir (fotoğraf, PDF, video). Baytları veritabanı blob'larında tutmak işe yarayabilir, ama veritabanını ağırlaştırır, yedekleri büyütür ve performansı öngörülmez kılar. Baytları nesne depolamada tutmak veritabanını en iyi yaptığı işe odaklı tutar; dosyalar ise bu iş için inşa edilmiş sistemler tarafından hızlı ve ucuz servis edilir.

Nesne depolama vs veritabanı blob'ları, sade bir dille

İnsanlar "yüklemeleri veritabanında saklayın" dediklerinde genellikle veritabanı blob'larını kastediyor: ya bir BYTEA sütunu (satır içinde ham bayt) ya da Postgres "large objects" (büyük değerleri ayrı saklayan bir özellik). İkisi de çalışır, ama ikisi de veritabanınızı dosya baytlarını servis etmekle sorumlu kılar.

Nesne depolama farklı bir fikir: dosya bir bucket içinde bir nesne olarak yaşar, bir anahtarla adreslenir (ör. uploads/2026/01/file.pdf). Büyük dosyalar, ucuz depolama ve akış halinde indirmeler için tasarlanmıştır. Ayrıca birçok eşzamanlı okumayı iyi idare eder, veritabanı bağlantılarınızı meşgul etmez.

Postgres sorgularda, kısıtlamalarda ve işlemlerde parlıyor. Kimin dosyaya sahip olduğu, dosyanın ne olduğu, ne zaman yüklendiği ve indirilebilir olup olmadığı gibi meta veriler için mükemmeldir. Bu meta veri küçüktür, indekslenmesi kolaydır ve tutarlılığı sağlamak basittir.

Pratik bir kural:

• Dosya meta verisi, izinler ve ilişkiler için Postgres kullanın.
• Dosyalar birkaç MB'ı aşabiliyorsa veya indirmeler sık oluyorsa baytlar için nesne depolama kullanın.
• Küçük ikon gibi işlemle tutarlı şekilde bir kayda bağlanması gereken çok küçük varlıklar için sadece DB blob'larını düşünün ve veritabanı büyümesinin sınırlı kalacağından emin olun.

Kısa bir akıl testi: yedekler, replikalar ve migration'lar dosya baytları dahil olduğunda zahmetli hale gelecekse, baytları Postgres dışında tutun.

Yönetilebilir kalan basit bir mimari

Çoğu ekip sonunda şu basit düzen ile ilerler: baytları nesne depolamada saklayın, dosya kaydını (kimin sahibi olduğu, ne olduğu, nerede durduğu) Postgres'te saklayın. API'niz koordinasyon ve yetkilendirme yapar, ama büyük yüklemeleri ve indirmeleri proxy etmez.

Bu size üç net sorumluluk verir:

• Postgres her dosya için küçük bir satır tutar: kalıcı bir file_id, sahibi, boyutu, içerik tipi ve nesne göstergesi.
• Nesne depolama gerçek baytları tutar, büyük dosyalar ve ucuz depolama için optimize edilmiştir.
• API'niz dosya kayıtlarını oluşturur ve yetkilendirir, depolamaya kısa ömürlü izinler dağıtır.

Bu stabil file_id her şey için birincil anahtar olur: ekine referans veren yorumlar, bir PDF'ye işaret eden faturalar, denetim logları ve destek araçları. Kullanıcı dosyayı yeniden adlandırabilir, siz bucket'lar arasında taşıyabilirsiniz; file_id aynı kalır.

Mümkünse kaydedilen nesneleri immutable (değişmez) olarak ele alın. Bir kullanıcı bir belgeyi değiştiriyorsa, genellikle mevcut baytları üzerine yazmak yerine yeni bir nesne (ve genellikle yeni bir satır veya yeni bir versiyon satırı) oluşturun. Bu önbellekleme basitliği sağlar, "eski link yeni dosyayı döndürüyor" sürprizlerini önler ve temiz bir rollback hikâyesi verir.

Gizliliğe erken karar verin: varsayılan olarak özel, istisna olarak genel. İyi bir kural: veritabanı bir dosyaya kimlerin erişebileceği konusunda gerçek kaynaktır; nesne depolama API'nizin verdiği kısa ömürlü izinleri uygular.

Postgres'te dosya meta verisini nasıl modellemeli

Temiz ayırmayla Postgres dosya hakkındaki gerçekleri tutar, nesne depolama baytları tutar. Bu veritabanınızı daha küçük, yedekleri daha hızlı ve sorguları daha basit tutar.

Pratik bir uploads tablosu gerçek soruları cevaplamak için birkaç alana ihtiyaç duyar: "bu kimin?", "nerede saklanıyor?" ve "indirilmeye uygun mu?"

CREATE TABLE uploads (
  id               uuid PRIMARY KEY,
  owner_id         uuid NOT NULL,
  bucket           text NOT NULL,
  object_key       text NOT NULL,
  size_bytes       bigint NOT NULL,
  content_type     text,
  original_filename text,
  checksum         text,
  state            text NOT NULL CHECK (state IN ('pending','uploaded','failed','deleted')),
  created_at       timestamptz NOT NULL DEFAULT now()
);

CREATE INDEX uploads_owner_created_idx ON uploads (owner_id, created_at DESC);
CREATE INDEX uploads_checksum_idx ON uploads (checksum);

Birkaç karar ileride ağrıdan kurtarır:

• Depolama göstericisi olarak bucket + object_key kullanın. Yüklendikten sonra değişmez tutun.
• Durumu takip edin. Bir kullanıcı yüklemeye başladığında pending bir satır ekleyin. Sistem nesnenin gerçekten var olduğunu ve boyutun (ve ideal olarak checksum'un) eşleştiğini onayladıktan sonra uploaded yapın.
• original_filename yalnızca gösterim içindir. Tür veya güvenlik kararları için buna güvenmeyin.

Eğer değişiklikleri destekliyorsanız (ör. kullanıcı bir faturayı yeniden yüklüyorsa), upload_versions gibi ayrı bir tablo ekleyin: upload_id, version, object_key ve created_at. Bu şekilde geçmişi tutabilir, hataları geri alabilir ve eski referansları kırmaktan kaçınabilirsiniz.

API'nizi tıkamadan yükleme akışı adım adım

API'nizin koordinasyon yapıp baytlarla uğraşmamasıyla yüklemeleri hızlı tutun. Veritabanınız yanıt verirken, nesne depolama bant genişliği yükünü taşır.

Her şey gönderilmeden önce bir yükleme kaydı oluşturarak başlayın. API'niz bir upload_id, dosyanın nerede duracağı (object_key) ve kısa ömürlü bir yükleme izni döndürsün.

Yaygın bir akış:

1. İstemci yüklemek isteğinde bulunur: API'niz beklemede (pending) bir satır oluşturur, beklenen boyutu ve hedeflenen içerik tipini kaydeder.
2. API bir presigned URL döndürür: büyük dosyalar için presigned upload URL oluşturun. Küçük dosyalar (ör. avatarlar) için daha basit istemci kodu isterseniz backend üzerinden proxy yapabilirsiniz.
3. İstemci doğrudan nesne depolamaya yükler: tarayıcı veya mobil uygulama baytları API üzerinden değil depolamaya gönderir.
4. Finalize: istemci upload_id ve depolama yanıtı alanlarını (örn. ETag) içeren finalize çağrısı yapar. Sunucunuz boyutu, checksum'u (kullanıyorsanız) ve içerik tipini doğrular, sonra satırı uploaded olarak işaretler.
5. Güvenli şekilde başarısız olma: doğrulama başarısız olursa failed yapın ve isteğe bağlı olarak nesneyi silin.

Tekrarlar ve kopyalar normaldir. Finalize çağrısını idempotent yapın: aynı upload_id iki kez finalize edilirse, başarı döndürün ve hiçbir şeyi değiştirmeyin.

Tekrarlardan ve yeniden yüklemelerden kaynaklanan kopyaları azaltmak için bir checksum saklayın ve "aynı sahip + aynı checksum + aynı boyut" durumunu aynı dosya olarak ele alın.

İndirme akışı adım adım (hızlı ve önbelleğe uygun)

İyi bir indirme akışı uygulamada tek bir stabil URL ile başlar; hatta baytlar başka yerde olsa bile. Düşünün: /files/{file_id}. API'niz file_id ile Postgres'te meta veriyi arar, izinleri kontrol eder, sonra dosyanın nasıl teslim edileceğine karar verir.

1. İstemci stabil URL'yi file_id ile ister.
2. API kullanıcının erişebileceğini ve dosyanın uploaded olduğunu doğrular.
3. API ya bir yönlendirme döndürür (çoğunlukla en iyi seçenek) ya da özel dosyalar için kısa ömürlü presigned GET URL verir.
4. İstemci dosyayı doğrudan nesne depolamadan indirir; böylece API'niz ve uygulama sunucuları sıcak yolun dışında kalır.

Yönlendirmeler, genel veya yarı-genel dosyalar için basit ve hızlıdır. Özel dosyalar için presigned GET URL'ler depolamayı gizli tutar ama tarayıcının yine de doğrudan indirmesine izin verir.

Video ve büyük indirmeler için nesne depolamanızın (ve varsa proxy katmanınızın) aralık isteklerini (Range header'ları) desteklediğinden emin olun. Bu, aramayı ve devam ettirilebilir indirmeyi mümkün kılar. Baytları API'niz üzerinden geçirirseniz, Range desteği genellikle bozulur veya pahalı olur.

Hızın kaynağı önbelleklemedir. Stabil /files/{file_id} uç noktanız genellikle önbelleğe alınmamalıdır (bu bir yetki kapısıdır), oysa nesne depolama yanıtı içeriğe göre önbelleğe alınabilir. Dosyalar immutable ise (yeni yükleme = yeni anahtar), uzun önbellek süresi ayarlayabilirsiniz. Dosyaları üzerine yazıyorsanız, önbellek sürelerini kısa tutun veya versiyonlanmış anahtarlar kullanın.

Küresel kullanıcılarınız veya büyük dosyalarınız varsa bir CDN yardımcı olur. Hedef kitleniz küçük veya tek bölgede yoğunsa, nesne depolama tek başına genellikle yeterli ve başlamak için daha ucuzdur.

Zaman içinde maliyetleri öngörülebilir tutmak

Sürpriz faturalar genellikle disk üzerinde duran ham baytlardan değil, indirmelerden ve churn'dan gelir.

Maliyeti etkileyen dört sürücüye fiyat verin: ne kadar depoluyorsunuz, ne sıklıkla okuma ve yazma yapılıyor (istekler), sağlayıcınızdan ne kadar veri çıkıyor (egress) ve tekrar eden origin indirmelerini azaltmak için CDN kullanıp kullanmadığınız. Kimse dokunmayan büyük bir dosyadan çok, küçük bir dosyanın 10.000 kez indirilmesi daha maliyetli olabilir.

Harcamayı sabit tutan kontroller:

• Upload başına dosya boyutu sınırı ve plana göre kullanıcı kotası koyun.
• Kötüye kullanım ve kazara döngüleri önlemek için yükleme ve indirme hızını sınırlayın.
• Eski dosyaların daha ucuz bir sınıfa taşınması veya artık ihtiyaç yoksa silinmesi için yaşam döngüsü kuralları kullanın.
• Tekrarlar veya yeniden yüklemeler ekstra kopya yaratmasın diye checksum ile dedupe edin.
• Faturalama ve uyarıları gerçek verilere dayandırmak için Postgres'te kullanım sayaçları saklayın.

Yaşam döngüsü kuralları genellikle en kolay kazanımdır. Örneğin: orijinal fotoğrafları 30 gün "sıcak" tutun, sonra daha ucuz bir depo sınıfına taşıyın; faturaları 7 yıl saklayın; başarısız yükleme parçalarını 7 gün sonra silin. Basit saklama politikaları bile depolama artışını durdurur.

Dedup basit olabilir: dosya meta veri tablonuzda bir içerik hash'i (örn. SHA-256) saklayın ve sahip başına benzersizliği zorunlu kılın. Kullanıcı aynı PDF'yi iki kere yüklediğinde mevcut nesneyi yeniden kullanabilir ve sadece yeni bir meta veri satırı oluşturabilirsiniz.

Son olarak, kullanım takibini zaten yaptığınız yerde tutun: Postgres. Her kullanıcı veya çalışma alanı için bytes_uploaded, bytes_downloaded, object_count ve last_activity_at saklayın. Bu, UI'da limitleri göstermek ve fatura gelmeden önce uyarı tetiklemek için işe yarar.

Yüklemeler için güvenlik ve uyumluluk temelleri

Yüklemeler için güvenlik iki şeye dayanır: bir dosyaya kim erişebilir ve bir şey ters giderse sonradan ne kanıtlayabilirsiniz.

Gerçek dünyaya uyan erişim kontrolü

Erişim modeline net başlayın ve bunu servisler arasında dağınık kurallarda değil Postgres meta verisinde kodlayın.

Çoğu uygulamayı kapsayan basit bir model:

• Sahip-sadece: yalnızca yükleyen (ve adminler) erişebilir.
• Paylaşılan: belirli kullanıcılar veya bir ekip/çalışma alanı tarafından erişilebilir.
• Genel: giriş gerektirmeden erişilebilir (az kullanın ve yine de takip edin).

Özel dosyalar için ham nesne anahtarlarını ifşa etmekten kaçının. Zaman sınırlı, kapsam sınırlı presigned yükleme ve indirme URL'leri verin ve bunları sık döndürün.

İleride işinizi kolaylaştıracak uyumluluk kontrolleri

Hem taşınma sırasında hem de dinlenirken şifrelemeyi doğrulayın. Taşınma sırasında HTTPS uçtan uca (doğrudan depolamaya yüklemelerde bile) kullanın. Dinlenme halinde depolama sağlayıcınızın sunucu tarafı şifrelemesini kullanın ve yedeklerin de şifrelendiğinden emin olun.

Güvenlik ve veri kalitesi için kontrol noktaları ekleyin: bir yükleme URL'si vermeden önce içerik tipi ve boyutu doğrulayın, sonra yüklemeden sonra (dosya adı yerine gerçek depolanan baytlara göre) tekrar doğrulayın. Risk profiliniz yüksekse, asenkron olarak kötü amaçlı yazılım taraması çalıştırın ve dosya temizlenene kadar karantinaya alın.

Olayları araştırmak ve temel uyumluluk ihtiyaçlarını karşılamak için denetim alanları saklayın: uploaded_by, ip, user_agent ve last_accessed_at pratik bir tabandır.

Veri bölgeliliği (data residency) gereksinimleriniz varsa, depolama bölgesini kasti seçin ve bunu hesaplama yaptığınız yerle tutarlı tutun.

Yavaşlamalara ve olaylara neden olan yaygın hatalar

Çoğu yükleme problemi ham hızla ilgili değildir. Erken aşamada kullanışlı görünen tasarım tercihleri, gerçek trafik, gerçek veri ve gerçek destek talepleriyle acı verir.

• Dosya baytlarını Postgres içinde saklamak: Küçük uygulamalar için çalışır; sonra yedekler şişer, geri yüklemeler uzar ve rutin bakım riskli hale gelir. Tek bir büyük tablo vacuum'u, replikasyonu ve basit sorguları yavaşlatabilir.
• Kullanıcı tarafından sağlanan dosya adını object_key olarak kullanmak: Çakışmalar olur (iki kullanıcı aynı ada sahip invoice.pdf yükleyebilir) ve garip karakterler uç durumlar yaratır. Dosya adlarını gösterim için saklayın, depolama için benzersiz bir anahtar üretin.
• Finalize zamanında doğrulamayı atlamak: İstemcide doğrulasanız bile sunucuda bitişte boyut, içerik türü ve sahipliği kontrol etmelisiniz.
• Nesneleri yanlışlıkla herkese açık yapmak ve erişimi döndürmemek: "Geçici" olarak yapılan bir bucket politikası veya uzun ömürlü URL'ler kalıcı hale gelme eğilimindedir. Kısa ömürlü indirme bağlantılarını tercih edin ve erişimi hızlıca iptal etme yolu sağlayın.
• Sadece bir tarafı (meta veri ya da baytları) silmek: Postgres satırını silip nesneyi bırakmak gizli maliyet sızıntılarına yol açar. Nesneyi silip meta veriyi bırakmak ise kırık indirmelere ve destek yüküne neden olur.

Somut bir örnek: bir kullanıcı profil fotoğrafını üç kez değiştirirse, eski üç nesne için ödeme yapıyor olabilirsiniz; temizleme planı yoksa bunlar sonsuza kadar kalabilir. Güvenli bir desen: Postgres'te yumuşak silme (soft delete) yapın, sonra arka plan işi nesneyi kaldırıp sonucu kaydetsin.

Hızlı lansman öncesi kontrol listesi

İlk büyük dosya geldiğinde, bir kullanıcı yükleme sırasında sayfayı yenilediğinde ya da bir hesap silindiğinde baytların arkada kalmasıyla çoğu problem ortaya çıkar.

Postgres tablonuzun dosyanın boyutunu, checksum'unu (bütünlüğü doğrulamak için) ve açık bir durum yolunu kaydettiğinden emin olun (örn: pending, uploaded, failed, deleted).

Son mil kontrol listesi:

• Tekrarların güvenli olduğundan emin olun: tekrarlanan denemeler ekstra nesneler veya eksik baytlarla "uploaded" satırları yaratmamalı.
• Yüklemeleri devam ettirilebilir (resumable) yapın ya da en azından yeniden başlatılabilir olsun (zaman aşımı ve mobil ağlar olacaktır).
• İndirmelerin aralık isteklerini (Range) desteklediğini doğrulayın ki büyük dosyalar hızlı başlasın ve bir duraklamadan sonra devam etsin.
• Silmeyi uçtan uca tanımlayın: meta veride mezar işareti (tombstone), nesne baytlarının silinmesi ve bir iş başarısızsa gecikmeli temizleme ile ilgilenme.
• Temel izleme ekleyin: yükleme/indirme hata oranı, depolama büyümesi ve ani egress sıçramaları.

Bir somut test: 2 GB'lık bir dosya yükleyin, %30'da sayfayı yenileyip sonra devam edin. Sonra yavaş bir bağlantıda indirin ve ortasına atlayın. Bu akışlardan biri zayıfsa, bunu lansmandan önce düzeltin.

Örnek senaryo: bir uygulamada fotoğraflar ve faturalar

Basit bir SaaS uygulaması genellikle iki çok farklı yükleme türüne sahiptir: profil fotoğrafları (sık, küçük, önbelleğe alınması güvenli) ve PDF faturalar (hassas, özel kalmalı). Meta veriyi Postgres'te, baytları nesne depolamada tutma ayrımı burada kendini ödüllendirir.

Aşağıda tek bir files tablosunda meta verinin nasıl görünebileceğine dair birkaç davranışı etkileyen alan örneği var:

Kullanıcı bir fotoğrafı değiştirdiğinde bunu üzerine yazma yerine yeni bir dosya olarak ele alın. Yeni bir satır ve yeni object_key oluşturun, sonra kullanıcı profilini yeni dosya ID'sine işaret edecek şekilde güncelleyin. Eski satırı replaced_by=<new_id> (veya deleted_at) ile işaretleyin ve eski nesneyi daha sonra arka plan işi ile silin. Bu geçmişi korur, rollback'i kolaylaştırır ve yarış durumlarını önler.

Destek ve hata ayıklama kolaylaşır çünkü meta veri bir hikâye anlatır. Birisi "yüklemem başarısız oldu" dediğinde destek status, insan tarafından okunabilir last_error, storage_request_id veya etag (depolama loglarında izlemek için), zaman damgaları (takıldı mı?), ve owner_id ile kind (erişim politikası doğru mu?) gibi alanlara bakabilir.

Aşırı inşa etmeden uygulamak için sonraki adımlar

Küçük başlayın ve mutlu yolu sıkıcı hale getirin: dosyalar yüklenir, meta veri kaydedilir, indirmeler hızlıdır ve hiçbir şey kaybolmaz.

İyi bir ilk kilometre taşı minimal bir Postgres meta veri tablosu artı bir doğrudan-depolama yükleme akışı ve bir indirime gating yapan indirme akışı olsun; bunu beyaz tahta üzerinde açıklayabileceğiniz şekilde kurun. Bu uçtan uca çalıştıktan sonra versiyonlar, kotalar ve yaşam döngüsü kuralları ekleyin.

Her dosya tipi için bir açık depolama politikası seçin ve yazılı hale getirin. Örneğin, profil fotoğrafları önbelleğe alınabilir, faturalar ise özel olmalı ve yalnızca kısa ömürlü indirme URL'leriyle erişilmeli. Bir bucket ön ekinin içinde politika karıştırmak veetkilenenleri yanlışlıkla açığa çıkarmak için iyi bir yoldur.

Erken enstrümantasyon ekleyin. İlk günden itibaren istediğiniz metrikler: finalize hata oranı, yetim oranı (DB satırı olmayan nesneler ve tam tersi), dosya türüne göre egress hacmi, P95 indirme gecikmesi ve ortalama nesne boyutu.

Bu deseni hızlı prototiplemek isterseniz, Koder.ai (koder.ai) sohbetten tam uygulamalar üretecek şekilde tasarlandı ve burada kullanılan yaygın yığınla (React, Go, Postgres) uyumludur. Şema, uç noktalar ve arka plan temizlik işlerini tekrardan yazmadan hızla yinelemenizi sağlar.

Bundan sonra yalnızca bir cümlede açıklayabileceğiniz şeyleri ekleyin: "eski sürümleri 30 gün tutuyoruz" veya "her çalışma alanına 10 GB veriyoruz." Gerçek kullanım sizi zorlayana kadar basit tutun.