Dosya Depolama

Her uygulama veri arka ucu, tablolarının yanı sıra özel bir nesne depolama alanıyla gelir. Veri arka ucu zaman serisi satırlarınızı tutarken, dosya depolama bir satıra sığmayan her şeyi tutar: kamera kareleri, PDF raporları, firmware blob’ları, ses klipleri, dışa aktarımlar.

İkisi birlikte kullanılmak üzere tasarlanmıştır. Bir dosyayı saklamak size bir kalıcı URL döndürür ve amaçlanan desen, bu URL’yi aynı anda bir tablo sütununa yazmaktır — böylece bir pano widget’ı görüntüyü başka hiçbir iş yapmadan görüntüler:

info = await ironflock.files.put("part-1.jpg", jpeg_bytes, content_type="image/jpeg")
await ironflock.publish_to_table("inspections", part_id="1", photo_url=info.url)

const info = await ironflock.files.put("part-1.jpg", jpegBytes, { contentType: "image/jpeg" });
await ironflock.publishToTable("inspections", [{ part_id: "1", photo_url: info.url }]);

Tam istemci API’si — okuma, listeleme, kullanım, paylaşım bağlantıları, büyük nesneler, hata kodları — SDK referansında belgelenmiştir. Bu sayfa platform tarafını ele alır: depolamanın nasıl tanımlandığı, yönetildiği, paylaşıldığı ve işletildiği.

Nasıl Çalışır

1. İsteğe bağlı olarak .ironflock/data-template.yml içinde bir files: bölümü tanımlayın.
2. Bir kullanıcı uygulamanızı bir projeye kurduğunda, IronFlock onun için özel bir depolama alanı sağlar — tıpkı proje veritabanını sağladığı gibi.
3. Edge kodunuz, SDK’nın files API’si aracılığıyla nesneleri saklar ve okur.
4. Uygulamayı kaldırmak, depolamasını tamamen kaldırır: tıpkı veritabanı şemasının silinmesi gibi, her nesne ve her kimlik bilgisi.

Veritabanı gibi depolama da proje bazlıdır. İki projeye kurulan aynı uygulama, tamamen ayrı iki depolama alanı edinir ve uygulama geliştiricisi olarak ikisine de erişiminiz yoktur — veriler, uygulamanızı çalıştıran kullanıcıya aittir.

Sıfır yapılandırma da geçerli bir yapılandırmadır: files: bölümü olmayan bir uygulama yine de default adında bir ad alanı edinir, dolayısıyla files.put(...) her uygulama için kutudan çıktığı gibi çalışır.

Veri Şablonunda Depolamayı Tanımlama

files: bölümü, data-template.yml içinde data: bölümünün yanında yer alır:

files:
  description: Camera frames and generated inspection reports.
  # Uygulamanın kendisi için ÖNERDİĞİ depolama bütçesi, bayt cinsinden (burada 5 GiB).
  # Proje kullanıcısı bunu geçersiz kılabilir; uygulanan, onların ayarıdır.
  quotaBytes: 5368709120
  namespaces:
    - name: frames
      description: Raw camera frames, one JPEG per inspected part.
      contentTypes: ["image/jpeg"]
      maxObjectBytes: 20971520
      retention: { deleteAfter: 30 days }
    - name: reports
      description: Generated PDF inspection reports.
      contentTypes: ["application/pdf"]
      private: true

Ad Alanları

Bir ad alanı (namespace), politika taşıyan bir anahtar önekidir. Ayrı bir depolama bucket’ı değildir — bir uygulamanın her ad alanı, uygulamanın tek depolama alanının içinde yer alır ve ad alanı adı, her nesnenin depolama yolunun ilk segmenti olur.

Bu ayrım, ne zaman bir tane tanımlamanız gerektiğini söyler:

• Dosyaları düzenlemek mi istiyorsunuz? default ad alanının içinde anahtar yolları kullanın — 2026/03/part-1.jpg. Klasör tarzı anahtarlar normal durumdur.
• Bir nesne kümesi için farklı kurallar mı gerekiyor? Bir ad alanı tanımlayın. Kurallar, bir ad alanının eklediği tek şeydir.

Bir ad alanının taşıyabileceği kurallar:

Depolama Bütçesi

quotaBytes, ad alanı başına değil, uygulamanın tamamı için bir kez tanımlanır. Bir ad alanı yalnızca bir anahtar önekidir, dolayısıyla önek başına bir bütçenin uygulanabileceği bir şey yoktur — kota, uygulamanın tek depolama alanına uygulanır ve nesne deposunun kendisi, doğrudan yüklemeler dahil her yazma yolunda bunu uygular.

İki sayı vardır ve aradaki fark bilinçlidir:

• Önerilen kota — şablonunuzun istediği değer. Uygulama ilk kez kurulduğunda uygulanır.
• Uygulanan kota — proje kullanıcısının belirlediği değer. Bir kullanıcı uygulamanın depolama ayarlarında bütçeyi değiştirdikten sonra onun değeri kazanır ve uygulamanızı yeniden dağıtmak bunu sıfırlamaz.

Şablonunuz hiçbir şey söylemezse, platform varsayılanı uygulanır (geliştirme arka uçları için 1 GiB, üretim arka uçları için 10 GiB).

Saklama

Ad alanının deleteAfter yaşını aşan nesneler otomatik olarak kaldırılır — tablo dropAfter politikasının dosya tarafındaki karşılığı. Saklama, deponun desteklediği yerlerde nesne deposunun içinde çalışır; desteklemediği yerlerde ise (yerinde (on-premises) appliance’lar) günlük bir platform işi olarak çalışır; böylece bildirilen saklama her yerde aynı şekilde davranır.

Kalıcı URL’ler ve Panolar

Saklanan her nesnenin https://files.ironflock.com/f/<backend>/<namespace>/<key> biçiminde kararlı bir URL’si vardır. Üç özellik onu bir tablo sütununa yazılacak doğru şey yapar:

• Hiçbir zaman sona ermez. URL saf bir adrestir; nesnenin ömrü boyunca geçerli kalır.
• Herkese açık bir bağlantı değildir. Her istek, istek sahibinin oturum açmış olduğunu ve bu veri arka ucu üzerinde READ erişimine sahip olduğunu denetleyen bir kimlik doğrulama proxy’sinden geçer — her tek istekte yeniden denetlenir. Bir kullanıcının erişimini iptal etmek, her dosyayı getirme yeteneğini anında iptal eder.
• Bir <img> içinde görüntülenir. Tarayıcı oturum çerezini otomatik olarak gönderir; böylece bir pano widget’ı URL’yi hiçbir JavaScript gerekmeden <img src>, <video src> veya bir indirme bağlantısında kullanabilir.

Bir dosyayı projenin dışındaki birine vermek için ise SDK’nın share_url işlevi bunun yerine süreli bir taşıyıcı (bearer) bağlantı üretir — hangisinin ne zaman kullanılacağı için bkz. nesneleri paylaşma.

Büyük Dosyalar

6 MiB’a kadar olan aktarımlar, mesajlaşma sistemi üzerinden tek bir çağrı olarak gerçekleşir. Daha büyük olan her şey, HTTPS üzerinden cihaz ile nesne depolama arasında doğrudan taşınır — SDK otomatik olarak geçiş yapar, diskten ve diske akış yapar ve çok gigabaytlık bir dosyanın belleğe sığması hiçbir zaman gerekmez. Tek seferlik yükleme tavanı 5 GiB’dır.

Doğrudan yol, cihazın yalnızca mesaj yönlendiricisine değil, nesne depolama sunucusuna da (s3.ironflock.com) erişebilmesini gerektirir. Bir fabrika proxy’si yalnızca yönlendiriciye izin veriyorsa, büyük aktarımlar genel bir hata yerine açık PRESIGN_UNREACHABLE koduyla başarısız olur — ve 15 dakikadan fazla sapmış bir cihaz saati CLOCK_SKEW ile başarısız olur; bu, kimlik bilgilerini değil, NTP’yi kontrol etmeniz gerektiğine işaret eder.

Uygulamalar Arasında Dosya Paylaşma

Uygulamalar arası dosya erişimi, uygulamalar arası tablo erişimiyle aynı onaya dayanır. Tek bir anahtar vardır: bir proje kullanıcısı, uygulama B’ye uygulama A’nın verilerine erişim verdiğinde (uygulamanın ayarlarındaki data_access onayı), bu yetki A’nın tablolarını ve A’nın özel olmayan dosya ad alanlarını kapsar. Onu iptal etmek her ikisini de iptal eder.

Uygulamanızın sağlayıcı olarak denetlediği şey, ad alanı başına private işaretidir:

• private: false (varsayılan) — veri erişim yetkisine sahip uygulamalar onu okuyabilir (asla yazamaz).
• private: true — yetki verilmiş olsa bile ad alanı diğer uygulamalara görünmez, nokta.

Bu, uygulama verilerini kullanma ile birebir aynıdır: ad alanları ve tablolar aynı varsayılana sahiptir. Proje kullanıcısının yetkisi olmadan hiçbir şey paylaşılmaz — private:, yalnızca zaten onay verilmiş bir okuyucunun gördüğünü daraltır; onayın kendisi değildir.

Kullanıcının Görünümü

Proje kullanıcıları uygulamanızın depolamasını iki yerde görür ve yönetir:

• Data görünümü, her uygulamanın tabloları ve görünümlerinin yanında bir Files girdisi gösterir — saklanan her nesnenin boyut, tür ve değiştirilme tarihiyle birlikte aranabilir bir listesi ve dosya başına indirme.
• Uygulamanın depolama ayarları, kullanımı (bayt ve nesne sayısı), uygulamanızın önerisinin yanında uygulanan bütçeyi, bütçeyi değiştirmek için bir denetimi ve bir Tüm dosyaları sil eylemini gösterir — tüm tabloları boşaltmanın dosya tarafındaki ikizi. Silme işlemi, uygulamanın adı yazılarak onaylanır ve geri alınamaz.
• Yapay zeka asistanı bu dosyaları bir kullanıcı adına listeleyebilir, arayabilir ve okuyabilir. Aynı DATABACKEND/READ denetimi geçerlidir; kullanıcının kendi açamayacağı bir dosyayı asla göstermez. Dosya içeriklerinde değil, dosya yollarında arama yapar ve metin dosyalarını, görüntüleri ve PDF’leri okur — arşivleri ve diğer ikili biçimleri okuyamaz.

Tablolarda olduğu gibi, bu kullanıcının verisidir: sizi işin içine katmadan inceleyebilir, sınırlayabilir ve silebilir.

Doğrudan S3 Erişimi

SDK’nın ötesindeki her şey için — DuckDB kullanan bir analist, gecelik bir rclone yedeklemesi, bir BI hattı — bir proje kullanıcısı, uygulamanın depolama ayarlarından uygulama başına salt okunur S3 kimlik bilgileri verebilir.

Her kimlik bilgisi, yalnızca o bir uygulamanın depolama alanıyla sınırlandırılmıştır: uygulama A için verilen bir kimlik bilgisi, uygulama B’nin dosyaları için yapısal olarak çalışmaz — B’nin depolama politikası onu asla adlandırmaz. Bir proje, uygulama başına birkaç kimlik bilgisi tutabilir (tüketici başına bir tane: bir CI işi, bir yedekleme betiği, bir dizüstü bilgisayar) ve birini iptal etmek diğerlerini çalışır durumda bırakır. Bu aynı zamanda rotasyon senaryosudur: bir anahtar sızarsa, ikinci bir kimlik bilgisi verin, tüketiciyi ona taşıyın, ilkini iptal edin — başka hiçbir tüketici etkilenmez.

Gizli anahtar, oluşturulurken bir kez gösterilir. Verme işlemi, ilgili uygulamanın veri arka ucuna okuma erişimi gerektirir — dosyaları en baştan okumanızı sağlayan iznin aynısı; dolayısıyla kimlik bilgisi hiç kimsenin erişim alanını genişletemez.

# rclone
rclone config create myapp s3 provider=Other \
  endpoint=https://s3.ironflock.com \
  access_key_id=ifs-key-3317-x7k2m secret_access_key=<shown once>
 
rclone ls myapp:if-1042-3317

# DuckDB
CREATE SECRET (TYPE S3, KEY_ID 'ifs-key-3317-x7k2m', SECRET '<shown once>',
               ENDPOINT 's3.ironflock.com');
SELECT * FROM read_parquet('s3://if-1042-3317/exports/*.parquet');

Depolama ayarları, bir istemciyi yönlendireceğiniz uç noktayı ve tam bucket adını gösterir. Üst düzey bir bucket listelemesinin (argümansız aws s3 ls) tasarımı gereği hiçbir şey döndürmediğine dikkat edin — kimlik bilgisi hiçbir bucket’a sahip değildir; birine erişim verilmiştir. Bucket’ı yukarıdaki gibi doğrudan adresleyin.

Yerinde (On-Premises) Appliance’lar

Dosya depolama, bir yerinde (on-premises) appliance üzerinde birebir aynı şekilde çalışır; appliance’ın tasarımından kaynaklanan üç farkla:

• Dosyalar, appliance’ın kendi adresi altında (/files/...) aynı köken (same-origin) olarak sunulur — ek DNS adı yok, ek sertifika yok ve düz HTTP kurulumlarında çalışır. Kalıcı URL’ler ve <img src> tıpkı buluttaki gibi davranır.
• Appliance’ın depolama arka ucu, dosya indirmelerini ayrı bir depolama sunucusuna yönlendirmek yerine platform üzerinden akış olarak gönderir; böylece depolama servisi hiçbir zaman ikinci bir köken olarak açığa çıkmaz.
• Appliance’larda doğrudan S3 kimlik bilgileri kullanılamaz — gömülü nesne deposu, kimlik bilgisi başına erişim yetkilerini ifade edemez. O bölüm oradaki depolama ayarlarında hiç görünmez. SDK üzerinden büyük dosya davranışı ve bildirilen saklama dahil diğer her şey aynı şekilde çalışır.

Hava boşluklu (air-gapped) bir appliance tüm dosya trafiğini yerel olarak sunar: uygulama logoları, pano görüntüleri ve dosya indirmeleri internet bağlantısı gerektirmez.

Bir Bakışta Limitler