Slater

वर्तमान संस्करण: v0.25.2 — सभी रिलीज़.

एक पंक्ति में: Slater उन ग्राफ़ों को सेव करता है जो मेमोरी में फिट नहीं होते — करोड़ों नोड और अरबों एज, सिर्फ़ कुछ सौ MB RAM में — मानक Bolt प्रोटोकॉल पर, ताकि कोई भी neo4j ड्राइवर बिना बदलाव के काम करे, ग्राफ़ के बगल में डिस्क-नेटिव वेक्टर सर्च हो, और यह लाइव, स्थायी राइट्स भी स्वीकार करता है बिना उस सुविधा को छोड़े। रेज़िडेंट मेमोरी आपके चुने हुए कैश बजट से तय होती है, ग्राफ़ के आकार से नहीं।

---

शॉर्टकट

Slater क्यों मौजूद है	रीड्स और राइट्स	आपको क्या मिलता है	फ़ीचर्स
Docker के साथ चलाना	यह कैसे काम करता है	राइटेबल लेयर	स्टोरेज बैकएंड
माउंट्स	कॉन्फ़िगरेशन	ACL	हेल्थ चेक
काम का उदाहरण	डेवलपमेंट	परफ़ॉर्मेंस	लाइसेंस
Graphiti मेमोरी स्टोर के रूप में	📖 पूर्ण मैनुअल

Slater क्यों मौजूद है

एक ग्राफ़ डेटाबेस डेटा को चीज़ों (नोड्स) और उनके बीच के संबंधों (एज) के रूप में संग्रहीत करता है, जिसमें संबंध प्रथम श्रेणी के नागरिक होते हैं। यही वह चीज़ है जो आप चाहते हैं जब आपके प्रश्न कनेक्शन से संबंधित हों न कि पंक्तियों से — "इस खाते से तीन हॉप्स के भीतर कौन है?", "इस बिल्ड के पीछे पूरी डिपेंडेंसी चेन क्या है?", "कौन से खाते एक डिवाइस, एक पता और एक कार्ड साझा करते हैं?" — ऐसे क्वेरी जो SQL में रिकर्सिव जॉइन का दलदल बन जाते हैं लेकिन ग्राफ़ में स्वाभाविक रूप से निकल आते हैं।

ग्राफ़ डेटाबेस के बारे में सबसे आम शिकायत यह है कि वे RAM में जो समा सकता है उससे आगे स्केल नहीं करते। उनमें से कई (जैसे neo4j, Memgraph, FalkorDB, आदि) पूरे ग्राफ़ को रेज़िडेंट रखते हैं: एक 40 GB ग्राफ़ को 40 GB मेमोरी चाहिए — प्रति इंस्टेंस। प्रति क्षेत्र, प्रति टेनेंट, या प्रति पॉड एक रेप्लिका चाहिए? बिल को गुणा करें। और एक निश्चित आकार से आगे वे लोड ही नहीं होते: उदाहरण के लिए 90 मिलियन नोड / 1.5B-एज Wikidata ग्राफ़ को ~64–128 GiB रेज़िडेंट चाहिए, इसलिए इन-मेमोरी इंजन इसे खोल ही नहीं सकते।

Slater इसका जवाब है। ग्राफ़ को मेमोरी में लोड करने के बजाय, यह इसे एक बार, ऑफ़लाइन कंपाइल करता है: slater-build आपके डेटा को एक content-addressed, अपरिवर्तनीय ऑन-डिस्क इमेज में बदल देता है, और कोई भी संख्या में Slater सर्वर उस इमेज को Bolt पर सेव करते हैं (ताकि आपके मौजूदा neo4j ड्राइवर बस काम करें), ब्लॉक्स को मांग पर पेज करते हुए और केवल एक निश्चित कैश बजट रेज़िडेंट रखते हुए। इसी तरह वही 90M-नोड ग्राफ़ कुछ सौ MB RAM से सेव होता है — ग्राफ़ का आकार और मेमोरी बिल अलग हो जाते हैं। एक 4 GB ग्राफ़ और एक 400 GB ग्राफ़ को सेव करने के लिए समान RAM खर्च होती है, इसलिए आप सस्ते, स्टेटलेस रीड रेप्लिका फैला सकते हैं और ग्राफ़ को हीप के बजाय स्टोर में रख सकते हैं।

यह इसे RAG के पीछे नॉलेज ग्राफ़, रिकमेंडेशन और आइडेंटिटी ग्राफ़, डिपेंडेंसी ग्राफ़ — किसी भी बड़ी और जुड़ी हुई चीज़ के लिए स्वाभाविक फिट बनाता है जिसे आप सस्ते और बार-बार क्वेरी करना चाहते हैं। डिस्क-नेटिव वेक्टर सर्च ग्राफ़ के ठीक बगल में रहता है, इसलिए वही इंजन एम्बेडिंग के लिए भी रिट्रीवल लेयर है।

हालाँकि, एक बार कंपाइल होने का मतलब जमा हुआ नहीं है। वह इमेज एक बेस है, अंतिम स्थिति नहीं: उसके ऊपर एक ऑप्ट-इन राइट लेयर बैठती है, ताकि एक लाइव ग्राफ़ को बिना कुछ रीबिल्ड किए सही और विस्तारित किया जा सके।

रीड्स और राइट्स

कोर अपरिवर्तनीय है; ग्राफ़ नहीं है। राइटेबल लेयर चालू करें (delta.enabled) और आप Bolt पर लिखें — एक प्रॉपर्टी सही करें, एक नोड जोड़ें, एक एज वापस लें — और परिवर्तन स्थायी रूप से दर्ज हो जाता है, इमेज के किसी रीबिल्ड के बिना। रीड साइड पर इसे सस्ता रखने वाली चीज़ राइट्स कहाँ रहते हैं है।

राइट्स एक log-structured-merge (LSM) लेयर में अपरिवर्तनीय कोर के ऊपर जमा होते हैं: एक write-ahead log और एक इन-मेमोरी टेबल, जो अपरिवर्तनीय डेल्टा सेगमेंट में फैलती है, और एक आवधिक कंसोलिडेशन द्वारा एक नए कोर में वापस मोड़ दी जाती है। इससे आपको क्या मिलता है:

• एक अलिखित ग्राफ़ पर रीड्स की लागत बिल्कुल पहले जैसी ही होती है। एक खाली डेल्टा एक सिंगल पूर्वानुमानित शाखा है, मर्ज नहीं — रीड पाथ बाइट-समान है चाहे राइटेबल लेयर चालू हो या नहीं।
• एक राइट की रीड लागत डेल्टा के आकार के साथ बढ़ती है, ग्राफ़ के आकार के साथ नहीं। पूरे-ग्राफ़ के उत्तर — count(*), लेबल और रिलेशनशिप-टाइप मार्जिनल — राइट्स बकाया होने पर भी मेटाडेटा रीड्स बने रहते हैं: डेल्टा अपने स्वयं के काउंटर रखता है, इसलिए 91.6M-नोड कोर पर आधे मिलियन लंबित राइट्स के साथ count(*) अभी भी दसियों मिलीसेकंड में उत्तर देता है बिना एक भी ब्लॉक छुए।
• स्वीकृत का मतलब स्थायी है। एक एकल राइटर कतार को खाली करता है और SUCCESS केवल उस fsync के बाद लौटाता है जो राइट को कवर करता है। अपने राइट्स को समूहित करें और वे सस्ते होते हैं — एक write-UNWIND प्रति बैच एक fsync कमिट करता है न कि प्रति पंक्ति।
• बिज़नेस-की राइट्स, दोनों डायलेक्ट में। MERGE / MATCH … SET / DELETE (और CREATE / REMOVE, डिटैच डिलीट, रिलेशनशिप राइट्स) जो नोड की आइडेंटिटी प्रॉपर्टी पर की जाती हैं — या समकक्ष ISO GQL डेटा-संशोधित स्टेटमेंट (INSERT / SET / REMOVE / DELETE), जो उसी पाथ पर उतरते हैं। सही करें, इन्सर्ट करें, अपसर्ट करें और वापस लें, नोड्स और एज पर, उसी तरह संबोधित करें जैसे आपका डेटा पहले से है।

लेयर बंद होने पर — डिफ़ॉल्ट — Slater शुद्ध अपरिवर्तनीय कोर सेव करता है और राइट्स से इनकार करता है। पूर्ण मॉडल के लिए द राइटेबल लेयर देखें।

नाम पर। Slater का नाम Archer (एक बेहतरीन शो) में CIA एजेंट के नाम पर रखा गया है जो एक ही नाम से चलने पर ज़ोर देता है — "बस… Slater" — और मेरे पसंदीदा पात्रों में से एक है। देखें कैरेक्टर विकी पेज।

आपको क्या मिलता है