"Dosyalarımı nereye koyayım?" sorusunun cevabı, uygulamanız büyümeye başlayana kadar hep aynıdır: sunucunun diskine. Sonra bir gün kullanıcı yüklemeleri 400 GB'a çıkar, ikinci bir web sunucusu eklersiniz ve o dosyaların iki makinede birden görünmesi gerektiğini fark edersiniz. İşte tam bu noktada nesne depolama ile blok depolama arasındaki fark, akademik bir konu olmaktan çıkıp mimari bir karar hâline gelir.
Bu rehberde iki depolama modelini gerçek kullanım senaryolarıyla karşılaştıracağım: verinin nasıl adreslendiğini, hangisinin dosya sistemi kabul ettiğini, gecikme ve verim (throughput) farklarını, maliyet yapılarının neden bu kadar farklı olduğunu ve hangi iş yükünün hangisine ait olduğunu göreceksiniz. Ayrıca "veritabanımı nesne depolamaya koyayım" gibi baştan yanlış giden fikirlerin neden çalışmadığını da açıklayacağım.
Blok Depolama Nasıl Çalışır#
Blok depolama, adından anlaşılacağı gibi diski sabit boyutlu ham bloklar dizisi olarak sunar. İşletim sistemi bu bloklara doğrudan erişir; hangi bloğun hangi dosyaya ait olduğunu bilen taraf depolama değil, üzerine kurduğunuz dosya sistemidir (ext4, XFS, ZFS...). Sunucunuzdaki /dev/sda, bir SAN üzerinden gelen LUN veya bulut sağlayıcınızın eklediğiniz sanal disk — hepsi blok depolamadır. İşletim sistemi açısından hepsi "bir disk"tir.
Bu modelin en belirgin özelliği, üzerine dosya sistemi kurulabilmesidir. Yani mkfs.ext4 çalıştırır, /mnt/veri altına bağlar ve sıradan bir dizinmiş gibi kullanırsınız:
# Yeni eklenen blok cihazı gör
lsblk
# Dosya sistemi oluştur ve kalıcı bağla
sudo mkfs.ext4 /dev/sdb
sudo mkdir -p /mnt/veri
sudo mount /dev/sdb /mnt/veri
# UUID ile fstab'a ekle (cihaz adı değişebilir, UUID değişmez)
sudo blkid /dev/sdb
Blok depolamanın güçlü yanı düşük gecikmedir. POSIX semantiği tamdır: dosyanın ortasındaki 4 KB'lık bir bloğu tek başına güncelleyebilir, dosyayı açık tutup üzerine yazabilir, fsync ile kalıcılığı garantileyebilirsiniz. Veritabanları, sanal makine imajları ve işletim sistemi diskleri tam olarak bu davranışa ihtiyaç duyar. Zayıf yanı ise ölçek ve paylaşımdır: bir blok cihaz normalde tek seferde tek bir sunucuya bağlanır. İki web sunucusunun aynı blok diski aynı anda yazmak üzere bağlaması, üzerinde küme dosya sistemi yoksa dosya sistemini bozar. Kalıcı bağlama ayrıntıları için disk bağlama, mount ve fstab yazısına bakabilirsiniz.
Nesne Depolama Nasıl Çalışır#
Nesne depolama tamamen farklı bir soyutlama sunar. Burada blok yoktur, dosya sistemi yoktur, dizin ağacı da aslında yoktur. Her veri parçası bir nesne (object) olarak saklanır ve üç şeyden oluşur: verinin kendisi, benzersiz bir anahtar (key) ve isteğe bağlı metadata. Nesnelere HTTP üzerinden, genellikle S3 uyumlu bir API ile erişilir — GET, PUT, DELETE gibi.
En kritik davranış farkı şudur: nesneler yerinde güncellenmez. 500 MB'lık bir video dosyasının içindeki bir baytı değiştirmek isterseniz, dosyanın tamamını yeniden yüklemeniz gerekir. Bu kısıt, sistemin ölçeklenebilmesini sağlayan şeyin ta kendisidir; kilit yönetimi ve blok düzeyinde tutarlılık derdi olmadığı için nesne depolama yatay olarak neredeyse sınırsız büyüyebilir.
# S3 uyumlu bir kovaya (bucket) dosya yükle
aws s3 cp rapor-2026.pdf s3://firmaniz-belgeler/raporlar/rapor-2026.pdf
# Kovanın içeriğini listele
aws s3 ls s3://firmaniz-belgeler/raporlar/
# Bir klasörü özyinelemeli senkronize et
aws s3 sync ./yuklemeler s3://firmaniz-belgeler/yuklemeler/
Buradaki raporlar/ bir dizin değildir; anahtarın bir parçasıdır. Nesne depolama bunu yalnızca listeleme sırasında önek (prefix) olarak yorumlar. Bu ayrım ilk başta kafa karıştırır ama alışınca mantığı oturur: nesne deposu düz bir anahtar-değer havuzudur, dizin ağacı görüntüsü sadece bir sunum kolaylığıdır. Protokolün ayrıntıları için S3 uyumlu nesne depolama nedir yazısı iyi bir devam noktasıdır.
Temel Farklar: Erişim, Tutarlılık ve Ölçek#
İki modeli yan yana koyduğumuzda farklar çok net görünür:
| Özellik | Blok Depolama | Nesne Depolama |
|---|---|---|
| Erişim yolu | Çekirdek (kernel) blok cihazı | HTTP / S3 API |
| Adresleme | LBA (blok numarası) | Anahtar (key) + kova |
| Dosya sistemi | Siz kurarsınız (ext4, XFS) | Yok, gerekmiyor |
| Kısmi güncelleme | Evet, blok düzeyinde | Hayır, nesne tamamen yeniden yazılır |
| Eşzamanlı çoklu erişim | Genelde tek sunucu | Sınırsız istemci, paralel |
| Tipik gecikme | Mikrosaniye–milisaniye | Onlarca milisaniye |
| Ölçek sınırı | Cihaz/dizi kapasitesi | Pratikte petabayt seviyesi |
| Metadata | Dosya sisteminde, sınırlı | Nesne başına özel etiketler |
Tabloda dikkat çekmek istediğim satır gecikme satırı. Nesne depolamada her istek bir HTTP çağrısıdır: TLS el sıkışması, kimlik doğrulama imzası, yönlendirme. Tek bir 10 MB'lık dosyayı okurken bu maliyet hiç önemli değildir; ama saniyede binlerce küçük okuma yapan bir veritabanı için felakettir. Blok depolamada aynı işlem çekirdek içinde, ağ katmanına hiç çıkmadan tamamlanabilir.
Buna karşılık dayanıklılık modeli nesne depolamanın lehinedir. Ciddi nesne depolama sistemleri her nesneyi birden çok düğüme çoğaltır ya da silme kodlaması (erasure coding) ile parçalayıp dağıtır. Yani tek bir sunucunun ya da tek bir diskin ölmesi veriyi etkilemez. Blok depolamada aynı güvenceyi elde etmek için altta RAID seviyeleri kurmanız ve bunu ayrıca yönetmeniz gerekir.
Performans ve Maliyet Karşılaştırması#
Maliyet yapıları da farklıdır ve bu fark bütçeyi doğrudan etkiler. Blok depolamada genellikle ayırdığınız kapasite için ödeme yaparsınız: 500 GB'lık bir disk eklediyseniz, 40 GB kullansanız da 500 GB'ın parasını ödersiniz. Nesne depolamada ise kullandığınız kapasite ölçülür; ayrıca istek sayısı ve dışarı çıkan trafik (egress) ayrı kalemler olabilir.
Bu iki modeli somut bir örnekle karşılaştıralım. Diyelim ki bir e-ticaret sitesinin 800 GB ürün görseli var ve bunlara ayda 5 milyon okuma isteği geliyor:
| Kriter | Blok disk üzerinde | Nesne depolamada |
|---|---|---|
| Ödenen kapasite | Ayrılan disk (ör. 1 TB) | Gerçek kullanım (800 GB) |
| Büyüme | Disk büyütme, yeniden boyutlandırma | Otomatik, işlem gerekmez |
| Çoklu sunucu erişimi | NFS/paylaşım katmanı gerekir | Doğrudan mümkün |
| CDN entegrasyonu | Ek yapılandırma | Genelde yerleşik |
| Ek maliyet kalemi | Yok | İstek sayısı ve egress trafik |
Pratikte gördüğüm en yaygın hata, egress maliyetini hesaba katmamaktır. Görselleri nesne depolamaya taşıyıp doğrudan tarayıcıya sunarsanız her görüntüleme dışarı trafik üretir. Doğru yaklaşım nesne deposunun önüne bir CDN koymaktır: CDN veriyi bir kez çeker, milyonlarca kez kendi kenar sunucularından servis eder. Trafik planı yaparken bant genişliği hesaplayıcı aracımız kaba bir tahmin çıkarmanıza yardımcı olur.
Hangi İş Yükü Hangisine Gider#
Karar aslında tek bir soruya indirgenebilir: veriye rastgele ve kısmi olarak mı yazıyorsunuz, yoksa bütün olarak mı yazıp bütün olarak mı okuyorsunuz?
Blok depolamayı şu durumlarda seçin:
- Veritabanları. MySQL, PostgreSQL, MongoDB — hepsi rastgele blok erişimi ve
fsyncgarantisi ister. - İşletim sistemi diski. Kök dosya sistemi her zaman blok cihaz üzerindedir.
- Sanal makine imajları. Sanallaştırma katmanı disk imajını blok cihaz gibi kullanır.
- Sürekli yazılan log ve kuyruk dosyaları. Eklemeli yazma blokta ucuz, nesnede pahalıdır.
- Düşük gecikme kritik olan her şey. Önbellek katmanları, oturum verisi.
Nesne depolamayı şu durumlarda seçin:
- Kullanıcı yüklemeleri. Profil fotoğrafı, ürün görseli, PDF belgeler, video.
- Yedekler ve arşivler. Bir kez yazılır, nadiren okunur, uzun süre saklanır.
- Statik site varlıkları. CSS, JS ve görselleri CDN ile birlikte servis etmek.
- Çoklu sunucudan paylaşılan içerik. Üç web sunucusu da aynı kovayı görebilir.
- Veri gölü / analitik ham veri. Büyük hacimli, sıralı okunan dosyalar.
Ölçeklenmeye başlayan bir uygulamada tipik mimari ikisinin birlikte kullanılmasıdır: veritabanı ve uygulama kodu VDS veya bulut sunucu üzerindeki blok diskte, kullanıcı yüklemeleri ise nesne depolamada durur. Bu ayrım aynı zamanda sunucuyu "durumsuz" (stateless) hâle getirir; makineyi silip yeniden kurmak artık veri kaybı riski taşımaz.
Dosya Depolama Bu Resmin Neresinde#
Aslında üçüncü bir model daha var ve karşılaştırmayı eksik bırakmamak için değinmek gerekiyor: dosya depolama, yani NFS ve SMB gibi ağ dosya sistemleri. Bu model blok ile nesne arasında durur. Blok depolama gibi POSIX semantiği sunar — dosyayı açar, ortasına yazar, kilitlersiniz — ama nesne depolama gibi aynı anda birden çok sunucudan erişilebilir.
Dosya depolamanın tatlı noktası, kod değiştirmeden paylaşımlı erişim istediğiniz durumlardır. Eski bir PHP uygulaması yüklemeleri /var/www/uploads altına yazıyorsa ve siz ikinci bir web sunucusu eklemek istiyorsanız, o dizini bir NFS paylaşımına dönüştürmek en hızlı çözümdür; uygulamaya tek satır dokunmazsınız. Nesne depolamaya geçiş ise uygulamanın S3 API'sini konuşacak şekilde değiştirilmesini gerektirir.
Bedeli ise ölçek ve dayanıklılıktır: NFS sunucusu tek noktadan arıza (single point of failure) hâline gelir ve ağ gecikmesi her dosya işlemine eklenir. Kurulum adımları için NFS paylaşımı kurulumu yazısına, Windows istemcileri de olan karma ortamlar için Samba ile dosya paylaşımı rehberine bakabilirsiniz.
| Model | Semantik | Paylaşım | Tipik protokol |
|---|---|---|---|
| Blok | POSIX, blok düzeyi | Tek sunucu | SCSI, iSCSI, NVMe |
| Dosya | POSIX, dosya düzeyi | Çok sunucu, LAN | NFS, SMB |
| Nesne | Anahtar-değer, HTTP | Sınırsız, internet | S3 API |
Sık Yapılan Hatalar ve Tuzaklar#
Veritabanını nesne depolamaya koymaya çalışmak. InnoDB veri dosyası sürekli rastgele güncellenir; nesne depolamada her güncelleme tüm nesnenin yeniden yazılması demektir. Teknik olarak s3fs gibi araçlarla bir kovayı dosya sistemi gibi bağlayabilirsiniz ama bu, POSIX davranışını taklit eden yavaş ve tutarsız bir katmandır. Veritabanı orada çalışmaz; çalışıyor gibi görünüp ilk yük altında bozulur.
Nesne deposunu dosya sistemi gibi kullanmak. s3fs, goofys ve benzeri FUSE sürücüleri okuma ağırlıklı, büyük dosyalı senaryolarda işe yarar. Ama ls komutu bile arka planda bir API çağrısıdır; 50 bin dosyalı bir dizinde listeleme dakikalar sürebilir. Uygulamanızı doğrudan S3 API'siyle konuşacak şekilde yazmak her zaman daha hızlı ve daha ucuzdur.
Kovayı yanlışlıkla herkese açık bırakmak. Nesne depolamada erişim kontrolü kova politikası ve imzalı URL'lerle yapılır. Varsayılanı "public-read" bırakılmış kovalar, veri sızıntılarının klasik kaynağıdır. Özel dosyaları süreli imzalı bağlantılarla (presigned URL) sunun.
Küçük dosya sayısını hafife almak. Nesne depolamada 1 KB'lık bir milyon dosya, 1 GB'lık tek dosyadan çok daha pahalı ve yavaştır; çünkü ücretlendirme ve gecikme istek başınadır. Küçük dosyaları arşivleyip (tar, zip) tek nesne olarak yüklemek çoğu zaman doğru yaklaşımdır.
Blok diskin dolmasını izlememek. Nesne depolama kendiliğinden büyür, blok disk büyümez. Disk doluluğunu izlemeyi ihmal ederseniz bir gece uygulamanız durur; disk kullanımı ölçme yazısındaki komutları düzenli izlemeye alın.
Sıkça Sorulan Sorular#
Nesne depolama blok depolamadan daha mı ucuz#
Genellikle depolanan gigabayt başına daha ucuzdur, çünkü sadece gerçekten kullandığınız alanı ödersiniz ve altta ucuz, yoğun disk raflarına dayanır. Ancak toplam maliyet sadece kapasiteden ibaret değildir: istek sayısı ve dışarı çıkan trafik ayrı ücretlendirilebilir. Yoğun okunan içerikte egress kalemi kapasiteyi geçebilir; bu yüzden önüne CDN koymak hem hızı hem maliyeti iyileştirir.
Nesne depolamaya veritabanı kurabilir miyim#
Hayır, pratikte kurulamaz. Veritabanları dosyanın belirli bir bölümünü yerinde güncellemek ve yazma sırasını garanti etmek zorundadır; nesne depolama ise nesneyi bütün olarak değiştirir ve bu garantileri sunmaz. FUSE sürücüleriyle zorlandığında sistem ya çok yavaş çalışır ya da güç kesintisinde tutarsız veri bırakır. Veritabanı her zaman blok depolama üzerinde durmalıdır.
İki web sunucusu aynı dosyalara nasıl erişir#
Üç seçeneğiniz var. En az kod değişikliği gerektireni NFS ya da SMB gibi bir ağ dosya sistemi kurmaktır; uygulamanız dizini yerelmiş gibi görür. En ölçeklenebilir olanı yüklemeleri nesne depolamaya taşımaktır, ancak uygulamanın S3 API'sini kullanacak şekilde güncellenmesi gerekir. Üçüncüsü dosyaları rsync ile senkronize etmektir ki bu sadece nadiren değişen içerik için uygundur.
S3 uyumlu depolama ile Amazon S3 aynı şey mi#
Aynı değil ama aynı dili konuşurlar. S3, Amazon'un servisinin adıdır; "S3 uyumlu" ise o servisin API'sini uygulayan diğer sistemleri tanımlar. MinIO, Ceph RGW ve pek çok sağlayıcının depolama servisi S3 uyumludur. Bu sayede aws s3 komutu ya da uygulamanızın SDK'sı, yalnızca uç nokta adresi (endpoint) değiştirilerek farklı bir sağlayıcıya yönlendirilebilir.
Blok depolamada kapasiteyi sonradan artırabilir miyim#
Çoğu sanallaştırma ve bulut platformunda evet, ancak iki aşamalı bir işlemdir. Önce blok cihazın kendisi büyütülür, sonra üzerindeki bölüm ve dosya sistemi genişletilir (growpart ve ardından resize2fs veya xfs_growfs). Küçültme genellikle desteklenmez ya da çok risklidir. Bu yüzden başlangıçta kapasiteyi biraz geniş tutmak, sonradan küçültmeye çalışmaktan daha güvenlidir.
Yedeklerimi hangisinde tutmalıyım#
Yedekler nesne depolamanın en doğal kullanım alanıdır: bir kez yazılır, nadiren okunur, uzun süre saklanır ve üretim sunucusundan tamamen ayrı bir hata alanında durur. Ayrıca sürüm (versioning) ve nesne kilidi (object lock) özellikleriyle fidye yazılımına karşı ek koruma sağlayabilirsiniz. Yedeği aynı sunucunun ikinci diskinde tutmak, sunucu tamamen kaybolduğunda hiçbir işe yaramaz.
Kapanış#
Nesne ve blok depolama rakip değil, farklı işler için tasarlanmış iki araçtır. Blok depolama düşük gecikme ve tam POSIX semantiği verir; veritabanları, işletim sistemi diskleri ve sanal makine imajları oraya aittir. Nesne depolama ise sınırsıza yakın ölçek, çoklu erişim ve dayanıklılık verir; kullanıcı yüklemeleri, yedekler ve statik varlıklar oraya aittir. Aklınızda kalması gereken üç alışkanlık: durumu (state) uygulama sunucusundan ayırın, nesne deposunun önüne CDN koyun ve blok disk doluluğunu izlemeye alın.
Uygulama ve veritabanı katmanınız için tam root erişimli VDS ya da esnek ölçeklenen bulut sunucu paketlerimize bakabilirsiniz. Yedeklerinizi üretim sunucusundan ayrı tutmak için yedekleme çözümlerimiz, mevcut kurulumunuzu bu mimariye taşımak için de site taşıma ve sunucu yönetimi hizmetlerimiz işi sizin yerinize üstlenebilir.