osFoundry / Platform
प्रति-ऐप KV स्टोर
TTLs के साथ Redis-कम्पैटिबल KV। सेशन्स, कैश, काउंटर्स — आपके ऐप के आकार के अनुसार।
यह क्या है
प्रति-ऐप KV स्टोर osFoundry के भीतर आपकी बनाई हर ऐप को उसका अपना Redis-संगत की-वैल्यू बैकएंड देता है। अगर आप Redis जानते हैं, तो आप यह पहले से जानते हैं: एक की सेट करें, उसे वापस पढ़ें, एक काउंटर बढ़ाएं, और एक time-to-live जोड़ें ताकि एंट्री अपने आप एक्सपायर हो जाए। हर ऐप को उसका अपना अलग namespace मिलता है, इसलिए एक ऐप की सेशन कीज़ कभी दूसरी ऐप की कैश एंट्रीज़ से नहीं टकरातीं। प्रोविज़न, सुरक्षित या ज़िंदा रखने के लिए कोई अलग Redis सर्वर नहीं होता; स्टोर ऐप के रनटाइम का हिस्सा है और उसी ऐप के हिसाब से आकार लेता है जो इसे इस्तेमाल करती है।
TTL ही KV स्टोर का असली मकसद है, और यह ठीक वैसे ही काम करता है जैसा आप उम्मीद करते हैं। 30 मिनट की एक्सपायरी वाला सेशन टोकन लिखें और विंडो बंद होते ही वह गायब हो जाता है; किसी महंगी API रिस्पॉन्स को पांच मिनट कैश करें और उसे खुद रिफ्रेश होने दें; एक अल्पकालिक lock या rate-limit विंडो रखें जो अपने आप साफ हो जाए। चूंकि कीज़ बिना किसी क्लीनअप जॉब के एक्सपायर होती हैं, आप बिना कूड़ा जमा किए अस्थायी स्टेट रख पाते हैं। काउंटर भी पूरी तरह समर्थित हैं: atomic increment और decrement आपको read-modify-write रेस के बिना व्यू काउंट, कोटा ट्रैकिंग और सरल क्रम-संख्याएं देते हैं।
यह osFoundry के स्वरूप में फिट बैठता है, जो एक bring-your-own-key डेस्कटॉप वर्कस्पेस है जहां चैट, एजेंट, ऐप्स, कोड, ज्ञान और डेटा एक ही जगह रहते हैं। KV स्टोर वह तेज़, अस्थायी परत है जो आपकी ऐप के बाकी डेटा के साथ रहती है: जो कुछ भी गर्म, छोटा और अल्पकालिक हो उसके लिए इसका उपयोग करें, और टिकाऊ रिकॉर्ड कहीं और रखें। Redis-संगत होने का मतलब है कि मानसिक मॉडल और कमांड शब्दावली आपके पहले बनाए किसी भी काम से यहां आ जाती है, इसलिए सेशन और कैश चलाने के लिए आपको कोई नई API नहीं सीखनी पड़ती।
मुख्य क्षमताएँ
- Redis-संगत की-वैल्यू API: GET, SET, INCR, EXPIRE और वे कमांड जो आप पहले से जानते हैं, कोई नया क्लाइंट सीखने की ज़रूरत नहीं
- प्रति-की TTL ताकि सेशन, कैश एंट्रीज़ और lock अपने आप एक्सपायर हों, कोई क्लीनअप जॉब चलाने की ज़रूरत नहीं
- प्रति-ऐप अलग namespace: हर ऐप की कीज़ उसी ऐप तक सीमित रहती हैं और कभी दूसरी की कीज़ से नहीं टकरातीं
- increment/decrement के ज़रिए atomic काउंटर, व्यू काउंट, कोटा और rate-limit विंडो के लिए, बिना रेस कंडीशन
- osFoundry के भीतर ऐप के हिस्से के रूप में चलता है: प्रोविज़न करने को कुछ नहीं, और स्टोर उसी ऐप के हिसाब से आकार लेता है जो इसे इस्तेमाल करती है
उपयोग के मामले
- ऐप डेवलपर: sliding TTL के साथ लॉगिन सेशन रखें ताकि यूज़र साइन-इन बने रहें और पुराने टोकन खुद साफ हो जाएं
- बैकएंड बिल्डर: धीमी थर्ड-पार्टी API रिस्पॉन्स को कुछ मिनट कैश करें ताकि latency और बार-बार की कॉल कम हों
- एजेंट टूलिंग लेखक: एक expiring की के ज़रिए अपने आप रीसेट होने वाला प्रति-मिनट rate-limit काउंटर रखें
सामान्य प्रश्न
क्या यह सचमुच Redis है, या सिर्फ Redis जैसा?
यह Redis-संगत है, यानी यह वही की-वैल्यू कमांड और सेमेंटिक्स बोलता है जो आप पहले से इस्तेमाल करते हैं: एक्सपायरी वाला SET, GET, INCR, DEL, इसलिए आपकी मौजूदा आदतें और कोड पैटर्न सीधे यहां चलते हैं। खास बात यह है कि यह osFoundry के ऐप रनटाइम में ही बना है, इसलिए इसे पाने के लिए आपको कोई अलग Redis सर्वर खड़ा या सुरक्षित नहीं करना पड़ता।
KV स्टोर में क्या रखूं और असली डेटाबेस में क्या?
KV का उपयोग गर्म, छोटी और अल्पकालिक स्टेट के लिए करें: सेशन, कैश, काउंटर, rate-limit विंडो और lock, जो कुछ भी एक्सपायर होने पर आपको आपत्ति न हो। टिकाऊ रिकॉर्ड जिन्हें बचे रहना और क्वेरी होना चाहिए, उन्हें एक उचित डेटाबेस में रखें। KV स्टोर तेज़, अस्थायी परत है, आपका system of record नहीं।
क्या TTL कीज़ को अपने आप एक्सपायर कर देते हैं?
हां। जब आप किसी की पर time-to-live सेट करते हैं, तो वह विंडो बीतते ही हट जाती है, आपकी ओर से कोई क्लीनअप जॉब नहीं। यही इसे सेशन और कैश के लिए उपयुक्त बनाता है: जो डेटा अस्थायी होना चाहिए वह जमा होने के बजाय खुद साफ हो जाता है।