osFoundry / Platform
Penyimpanan KV per aplikasi
KV kompatibel Redis dengan TTL. Sesi, cache, counter — disesuaikan dengan aplikasi Anda.
Apa itu
KV store per aplikasi memberi tiap aplikasi yang Anda bangun di dalam osFoundry backend key-value kompatibel Redis miliknya sendiri. Jika sudah mengenal Redis, Anda sudah mengenal ini: set sebuah kunci, baca kembali, naikkan sebuah penghitung, dan lampirkan time-to-live agar entri kedaluwarsa dengan sendirinya. Tiap aplikasi mendapat namespace terisolasi sendiri, sehingga kunci sesi satu aplikasi tidak pernah bentrok dengan entri cache aplikasi lain. Tidak ada server Redis terpisah yang perlu disediakan, diamankan, atau dijaga tetap hidup: store ini bagian dari runtime aplikasi dan berukuran sesuai aplikasi yang memakainya.
TTL adalah inti dari sebuah KV store, dan ia bekerja seperti yang Anda harapkan. Tulis token sesi dengan masa kedaluwarsa 30 menit dan ia hilang saat jendela itu menutup; cache respons API yang mahal selama lima menit dan biarkan ia menyegarkan diri sendiri; simpan lock berumur pendek atau jendela rate-limit yang membersihkan diri secara otomatis. Karena kunci kedaluwarsa tanpa job pembersihan, Anda menyimpan state efemeral tanpa menumpuk sampah. Penghitung juga kelas satu: increment dan decrement atomik memberi Anda jumlah tampilan, pelacakan kuota, dan nomor urut sederhana tanpa race read-modify-write.
Ini cocok dengan bentuk osFoundry sebagai workspace desktop bring-your-own-key tempat chat, agen, aplikasi, kode, pengetahuan, dan data berada di satu tempat. KV store adalah lapisan cepat dan efemeral yang duduk berdampingan dengan data lain aplikasi Anda: pakai untuk apa pun yang panas, kecil, dan berumur pendek, dan simpan catatan tahan lama di tempat lain. Kompatibel dengan Redis berarti model berpikir dan kosakata perintah terbawa dari apa pun yang pernah Anda bangun, jadi Anda tidak perlu mempelajari API baru untuk menjalankan sesi dan cache.
Kemampuan utama
- API key-value kompatibel Redis: GET, SET, INCR, EXPIRE dan perintah yang sudah Anda kenal, tanpa klien baru yang harus dipelajari
- TTL per kunci sehingga sesi, entri cache, dan lock kedaluwarsa sendiri, tanpa job pembersihan yang perlu dijalankan
- Namespace terisolasi per aplikasi: kunci tiap aplikasi terbatas pada aplikasi itu dan tidak pernah bentrok dengan milik yang lain
- Penghitung atomik lewat increment/decrement untuk jumlah tampilan, kuota, dan jendela rate-limit tanpa race condition
- Berjalan sebagai bagian aplikasi di dalam osFoundry: tidak ada yang perlu disediakan, dan store berukuran sesuai aplikasi yang memakainya
Kasus penggunaan
- Pengembang aplikasi: simpan sesi login dengan TTL bergeser agar pengguna tetap masuk dan token usang membersihkan diri sendiri
- Pembangun backend: cache respons API pihak ketiga yang lambat selama beberapa menit untuk memangkas latensi dan panggilan berulang
- Penulis tooling agen: pelihara penghitung rate-limit per menit yang reset otomatis lewat kunci yang kedaluwarsa
Pertanyaan yang sering diajukan
Apakah ini benar-benar Redis, atau sekadar mirip Redis?
Ini kompatibel dengan Redis, artinya ia berbicara perintah dan semantik key-value yang sama seperti yang sudah Anda pakai: SET dengan kedaluwarsa, GET, INCR, DEL, sehingga kebiasaan dan pola kode yang ada terbawa langsung. Nilainya adalah ia sudah tertanam di runtime aplikasi osFoundry, jadi Anda tidak perlu menyiapkan atau mengamankan server Redis terpisah untuk memilikinya.
Apa yang sebaiknya disimpan di KV store dibandingkan database sungguhan?
Pakai KV untuk state yang panas, kecil, dan berumur pendek: sesi, cache, penghitung, jendela rate-limit, dan lock, apa pun yang Anda rela biarkan kedaluwarsa. Simpan catatan tahan lama yang harus bertahan dan dapat dikueri di database yang semestinya. KV store adalah lapisan cepat dan efemeral, bukan system of record Anda.
Apakah TTL mengedaluwarsakan kunci secara otomatis?
Ya. Saat Anda menetapkan time-to-live pada sebuah kunci, ia dihapus begitu jendela itu lewat, tanpa job pembersihan dari sisi Anda. Itulah yang membuatnya cocok untuk sesi dan cache: data yang seharusnya sementara membersihkan diri sendiri alih-alih menumpuk.