update more languages

Signed-off-by: Alex Jenkins <kjenkins60@gatech.edu>

docs/tech-specs/graphrag-performance-optimization.hi.md

@@ -11,12 +11,21 @@
 
 ## लक्ष्य
 
+<<<<<<< HEAD
 **डेटाबेस क्वेरी की मात्रा को कम करें**: बैचिंग और कैशिंग के माध्यम से कुल डेटाबेस प्रश्नों में 50-80% की कमी प्राप्त करें।
 **प्रतिक्रिया समय में सुधार**: सबग्राफ निर्माण और लेबल रिज़ॉल्यूशन में 3-5 गुना तेजी और 2-3 गुना तेजी लाने का लक्ष्य रखें।
 **स्केलेबिलिटी में वृद्धि**: बेहतर मेमोरी प्रबंधन के साथ बड़े नॉलेज ग्राफ का समर्थन करें।
 **सटीकता बनाए रखें**: मौजूदा ग्राफआरएजी कार्यक्षमता और परिणाम गुणवत्ता को संरक्षित करें।
 **समवर्तीता सक्षम करें**: एकाधिक समवर्ती अनुरोधों के लिए समानांतर प्रसंस्करण क्षमताओं में सुधार करें।
 **मेमोरी पदचिह्न को कम करें**: कुशल डेटा संरचनाओं और मेमोरी प्रबंधन को लागू करें।
+=======
+**डेटाबेस क्वेरी की मात्रा कम करें**: बैचिंग और कैशिंग के माध्यम से कुल डेटाबेस प्रश्नों में 50-80% की कमी प्राप्त करें।
+**प्रतिक्रिया समय में सुधार**: सबग्राफ निर्माण और लेबल रिज़ॉल्यूशन में 3-5 गुना तेजी और 2-3 गुना तेजी लाने का लक्ष्य रखें।
+**स्केलेबिलिटी बढ़ाएं**: बेहतर मेमोरी प्रबंधन के साथ बड़े नॉलेज ग्राफ का समर्थन करें।
+**सटीकता बनाए रखें**: मौजूदा ग्राफआरएजी कार्यक्षमता और परिणाम गुणवत्ता को संरक्षित करें।
+**समवर्तीता सक्षम करें**: एकाधिक समवर्ती अनुरोधों के लिए समानांतर प्रसंस्करण क्षमताओं में सुधार करें।
+**मेमोरी पदचिह्न कम करें**: कुशल डेटा संरचनाओं और मेमोरी प्रबंधन को लागू करें।
+>>>>>>> 82edf2d (New md files from RunPod)
 **अवलोकनशीलता जोड़ें**: प्रदर्शन मेट्रिक्स और निगरानी क्षमताओं को शामिल करें।
 **विश्वसनीयता सुनिश्चित करें**: उचित त्रुटि हैंडलिंग और टाइमआउट तंत्र जोड़ें।
 
@@ -27,9 +36,15 @@
 ### वर्तमान प्रदर्शन समस्याएं
 
 **1. अक्षम ग्राफ ट्रैवर्सल (`follow_edges` फ़ंक्शन, लाइनें 79-127)**
+<<<<<<< HEAD
 प्रत्येक इकाई प्रति गहराई स्तर के लिए 3 अलग-अलग डेटाबेस क्वेरी करता है।
 क्वेरी पैटर्न: प्रत्येक इकाई के लिए विषय-आधारित, विधेय-आधारित और ऑब्जेक्ट-आधारित क्वेरी।
 कोई बैचिंग नहीं: प्रत्येक क्वेरी एक समय में केवल एक इकाई को संसाधित करती है।
+=======
+प्रति इकाई प्रति गहराई स्तर के लिए 3 अलग-अलग डेटाबेस क्वेरी करता है।
+क्वेरी पैटर्न: प्रत्येक इकाई के लिए विषय-आधारित, विधेय-आधारित और ऑब्जेक्ट-आधारित क्वेरी।
+कोई बैचिंग नहीं: प्रत्येक क्वेरी केवल एक इकाई को संसाधित करती है।
+>>>>>>> 82edf2d (New md files from RunPod)
 कोई चक्र का पता नहीं: समान नोड्स को कई बार फिर से देख सकता है।
 मेमोइज़ेशन के बिना पुनरावर्ती कार्यान्वयन घातीय जटिलता की ओर ले जाता है।
 समय जटिलता: O(entities × max_path_length × triple_limit³)
@@ -42,7 +57,11 @@
 
 **3. आदिम कैशिंग रणनीति (`maybe_label` फ़ंक्शन, लाइनें 62-77)**
 आकार सीमा या टीटीएल के बिना एक साधारण शब्दकोश कैश।
+<<<<<<< HEAD
 कोई कैश निष्कासन नीति नहीं जिसके परिणामस्वरूप असीमित मेमोरी वृद्धि होती है।
+=======
+कोई कैश निष्कासन नीति असीमित मेमोरी वृद्धि की ओर ले जाती है।
+>>>>>>> 82edf2d (New md files from RunPod)
 कैश मिस व्यक्तिगत डेटाबेस क्वेरी को ट्रिगर करते हैं।
 कोई प्रीफ़ेचिंग या बुद्धिमान कैश वार्मिंग नहीं।
 
@@ -53,7 +72,11 @@
 
 **5. महत्वपूर्ण ऑब्जेक्ट लाइफटाइम मुद्दे (`rag.py:96-102`)**
 **प्रत्येक अनुरोध के लिए GraphRag ऑब्जेक्ट फिर से बनाया गया**: प्रत्येक क्वेरी के लिए एक नया उदाहरण बनाया जाता है, जिससे सभी कैश लाभ खो जाते हैं।
+<<<<<<< HEAD
 **क्वेरी ऑब्जेक्ट बहुत कम समय तक रहता है**: एकल क्वेरी निष्पादन के भीतर बनाया और नष्ट किया जाता है (लाइनें 201-207)।
+=======
+**क्वेरी ऑब्जेक्ट बहुत कम समय तक जीवित रहता है**: एक ही क्वेरी निष्पादन के भीतर बनाया और नष्ट किया जाता है (लाइनें 201-207)।
+>>>>>>> 82edf2d (New md files from RunPod)
 **प्रत्येक अनुरोध के लिए लेबल कैश रीसेट**: कैश वार्मिंग और संचित ज्ञान के बीच खो जाता है।
 **क्लाइंट पुन: निर्माण ओवरहेड**: प्रत्येक अनुरोध के लिए डेटाबेस क्लाइंट संभावित रूप से फिर से स्थापित होते हैं।
 **क्रॉस-रिक्वेस्ट अनुकूलन नहीं**: क्वेरी पैटर्न या परिणाम साझाकरण से लाभ नहीं उठाया जा सकता है।
@@ -61,6 +84,7 @@
 ### प्रदर्शन प्रभाव विश्लेषण
 
 एक विशिष्ट क्वेरी के लिए वर्तमान सबसे खराब स्थिति परिदृश्य:
+<<<<<<< HEAD
 **इकाई पुनर्प्राप्ति**: 1 वेक्टर समानता क्वेरी
 **ग्राफ ट्रैवर्सल**: entities × max_path_length × 3 × triple_limit क्वेरी
 **लेबल रिज़ॉल्यूशन**: subgraph_size × 3 व्यक्तिगत लेबल क्वेरी
@@ -77,17 +101,44 @@
 विशिष्ट क्वेरीज़ के लिए उप-सेकंड प्रतिक्रिया समय प्रदान करें
 सैकड़ों समवर्ती GraphRAG अनुरोधों को संभालें
 ग्राफ के आकार और जटिलता के साथ कुशलतापूर्वक स्केल करें
+=======
+**इकाई पुनर्प्राप्ति**: 1 वेक्टर समानता क्वेरी।
+**ग्राफ ट्रैवर्सल**: entities × max_path_length × 3 × triple_limit क्वेरी।
+**लेबल रिज़ॉल्यूशन**: subgraph_size × 3 व्यक्तिगत लेबल क्वेरी।
+
+डिफ़ॉल्ट मापदंडों के लिए (50 एंटिटीज, पथ लंबाई 2, 30 ट्रिपल सीमा, 150 सबग्राफ आकार):
+**न्यूनतम क्वेरीज़**: 1 + (50 × 2 × 3 × 30) + (150 × 3) = **9,451 डेटाबेस क्वेरीज़**
+**प्रतिक्रिया समय**: मध्यम आकार के ग्राफ के लिए 15-30 सेकंड
+**मेमोरी उपयोग**: समय के साथ असीमित कैश वृद्धि
+**कैश प्रभावशीलता**: 0% - प्रत्येक अनुरोध पर कैश रीसेट हो जाते हैं
+**ऑब्जेक्ट निर्माण ओवरहेड**: प्रति अनुरोध बनाए गए/विनाश किए गए ग्राफराग + क्वेरी ऑब्जेक्ट
+
+यह विनिर्देश इन कमियों को बैच क्वेरी, बुद्धिमान कैशिंग और समानांतर प्रसंस्करण को लागू करके संबोधित करता है। क्वेरी पैटर्न और डेटा एक्सेस को अनुकूलित करके, ट्रस्टग्राफ निम्न कार्य कर सकता है:
+लाखों एंटिटीज वाले एंटरप्राइज-स्केल नॉलेज ग्राफ का समर्थन करें
+विशिष्ट क्वेरीज़ के लिए उप-सेकंड प्रतिक्रिया समय प्रदान करें
+सैकड़ों समवर्ती ग्राफराग अनुरोधों को संभालें
+ग्राफ आकार और जटिलता के साथ कुशलतापूर्वक स्केल करें
+>>>>>>> 82edf2d (New md files from RunPod)
 
 ## तकनीकी डिज़ाइन
 
 ### आर्किटेक्चर
 
+<<<<<<< HEAD
 GraphRAG प्रदर्शन अनुकूलन के लिए निम्नलिखित तकनीकी घटकों की आवश्यकता होती है:
 
 #### 1. **ऑब्जेक्ट लाइफटाइम आर्किटेक्चरल रीफैक्टर**
    **GraphRag को लंबे समय तक चलने वाला बनाएं**: GraphRag इंस्टेंस को प्रोसेसर स्तर पर ले जाएं ताकि यह अनुरोधों के बीच बना रहे
    **कैश बनाए रखें**: लेबल कैश, एम्बेडिंग कैश और क्वेरी परिणाम कैश को अनुरोधों के बीच बनाए रखें
    **क्वेरी ऑब्जेक्ट को अनुकूलित करें**: Query को एक हल्के निष्पादन संदर्भ के रूप में रीफैक्टर करें, डेटा कंटेनर के रूप में नहीं
+=======
+ग्राफराग प्रदर्शन अनुकूलन के लिए निम्नलिखित तकनीकी घटकों की आवश्यकता होती है:
+
+#### 1. **ऑब्जेक्ट लाइफटाइम आर्किटेक्चरल रीफैक्टर**
+   **ग्राफराग को लंबे समय तक चलने वाला बनाएं**: ग्राफराग इंस्टेंस को प्रोसेसर स्तर पर ले जाएं ताकि यह अनुरोधों के बीच बना रहे
+   **कैश बनाए रखें**: लेबल कैश, एम्बेडिंग कैश और क्वेरी परिणाम कैश को अनुरोधों के बीच बनाए रखें
+   **क्वेरी ऑब्जेक्ट को अनुकूलित करें**: क्वेरी को एक हल्के निष्पादन संदर्भ के रूप में रीफैक्टर करें, डेटा कंटेनर के रूप में नहीं
+>>>>>>> 82edf2d (New md files from RunPod)
    **कनेक्शन दृढ़ता**: डेटाबेस क्लाइंट कनेक्शन को अनुरोधों के बीच बनाए रखें
 
    मॉड्यूल: `trustgraph-flow/trustgraph/retrieval/graph_rag/rag.py` (संशोधित)
@@ -101,7 +152,11 @@ GraphRAG प्रदर्शन अनुकूलन के लिए नि
    मॉड्यूल: `trustgraph-flow/trustgraph/retrieval/graph_rag/optimized_traversal.py`
 
 #### 3. **समानांतर लेबल रिज़ॉल्यूशन सिस्टम**
+<<<<<<< HEAD
    एक साथ कई एंटिटीज के लिए लेबल क्वेरीज़ को बैच करें
+=======
+   एक साथ कई एंटिटीज के लिए बैच लेबल क्वेरी
+>>>>>>> 82edf2d (New md files from RunPod)
    समवर्ती डेटाबेस एक्सेस के लिए एसिंक्रोनस/अवेट पैटर्न लागू करें
    सामान्य लेबल पैटर्न के लिए बुद्धिमान प्रीफ़ेटिंग जोड़ें
    लेबल कैश वार्मिंग रणनीतियों शामिल करें
@@ -109,10 +164,17 @@ GraphRAG प्रदर्शन अनुकूलन के लिए नि
    मॉड्यूल: `trustgraph-flow/trustgraph/retrieval/graph_rag/label_resolver.py`
 
 #### 4. **रूढ़िवादी लेबल कैशिंग लेयर**
+<<<<<<< HEAD
    प्रदर्शन बनाम स्थिरता को संतुलित करने के लिए केवल लेबल के लिए लघु TTL के साथ LRU कैश (5 मिनट)
    कैश मेट्रिक्स और हिट अनुपात निगरानी
    **कोई एम्बेडिंग कैशिंग नहीं**: पहले से ही प्रति-क्वेरी कैश किया गया है, कोई क्रॉस-क्वेरी लाभ नहीं
    **कोई क्वेरी परिणाम कैशिंग नहीं**: ग्राफ परिवर्तन स्थिरता संबंधी चिंताओं के कारण
+=======
+   केवल लेबल के लिए लघु TTL के साथ LRU कैश (5 मिनट) प्रदर्शन बनाम स्थिरता को संतुलित करने के लिए
+   कैश मेट्रिक्स और हिट अनुपात निगरानी
+   **कोई एम्बेडिंग कैशिंग नहीं**: पहले से ही प्रति-क्वेरी कैश किया गया है, कोई क्रॉस-क्वेरी लाभ नहीं
+   **कोई क्वेरी परिणाम कैशिंग नहीं**: ग्राफ उत्परिवर्तन स्थिरता संबंधी चिंताओं के कारण
+>>>>>>> 82edf2d (New md files from RunPod)
 
    मॉड्यूल: `trustgraph-flow/trustgraph/retrieval/graph_rag/cache_manager.py`
 
@@ -141,7 +203,11 @@ class TraversalState:
     query_batch: List[TripleQuery]
 ```
 
+<<<<<<< HEAD
 यह दृष्टिकोण निम्नलिखित सुविधाएँ प्रदान करता है:
+=======
+यह दृष्टिकोण निम्नलिखित कार्य करने की अनुमति देता है:
+>>>>>>> 82edf2d (New md files from RunPod)
 विज़िट किए गए एंटिटी को ट्रैक करके कुशल चक्र का पता लगाना
 प्रत्येक ट्रैवर्सल स्तर पर बैच में क्वेरी तैयार करना
 मेमोरी-कुशल स्थिति प्रबंधन
@@ -219,12 +285,20 @@ class CacheManager:
 
 **क्वेरी क्लास** - बैच प्रोसेसिंग के लिए पुनर्गठित:
 व्यक्तिगत इकाई प्रसंस्करण को बैच ऑपरेशनों से बदलें
+<<<<<<< HEAD
 संसाधन सफाई के लिए एसिंक्रोनस कॉन्टेक्स्ट मैनेजर जोड़ें
+=======
+संसाधन सफाई के लिए एसिंक्रोनस संदर्भ प्रबंधक जोड़ें
+>>>>>>> 82edf2d (New md files from RunPod)
 लंबे समय तक चलने वाले ऑपरेशनों के लिए प्रगति कॉलबैक शामिल करें
 
 ### कार्यान्वयन विवरण
 
+<<<<<<< HEAD
 #### चरण 0: महत्वपूर्ण आर्किटेक्चरल लाइफटाइम रिफैक्टर
+=======
+#### चरण 0: महत्वपूर्ण वास्तुशिल्प जीवनचक्र पुनर्गठन
+>>>>>>> 82edf2d (New md files from RunPod)
 
 **वर्तमान समस्याग्रस्त कार्यान्वयन:**
 ```python
@@ -327,7 +401,11 @@ class QueryExecutor:
 **कैश टीटीएल विंडो के भीतर क्रॉस-अनुरोध अनुकूलन**
 
 **महत्वपूर्ण कैश स्थिरता सीमा:**
+<<<<<<< HEAD
 दीर्घकालिक कैशिंग से अप्रचलन का जोखिम होता है जब अंतर्निहित ग्राफ में एंटिटीज/लेबल हटा दिए जाते हैं या संशोधित किए जाते हैं। एलआरयू कैश जिसमें टीटीएल है, प्रदर्शन लाभ और डेटा ताज़गी के बीच संतुलन प्रदान करता है, लेकिन यह वास्तविक समय में ग्राफ परिवर्तनों का पता नहीं लगा सकता है।
+=======
+दीर्घकालिक कैशिंग से पुरानी जानकारी का जोखिम होता है जब अंतर्निहित ग्राफ में एंटिटीज/लेबल हटा दिए जाते हैं या संशोधित किए जाते हैं। एलआरयू कैश, टीटीएल के साथ, प्रदर्शन लाभ और डेटा ताज़गी के बीच एक संतुलन प्रदान करता है, लेकिन यह वास्तविक समय में ग्राफ परिवर्तनों का पता नहीं लगा सकता है।
+>>>>>>> 82edf2d (New md files from RunPod)
 
 #### चरण 1: ग्राफ ट्रैवर्सल अनुकूलन
 
@@ -480,9 +558,15 @@ async def execute_with_timeout(self, query_func, timeout: int = 30):
 ## कैश कंसिस्टेंसी पर विचार
 
 **डेटा स्टेलनेस ट्रेड-ऑफ:**
+<<<<<<< HEAD
 **लेबल कैश (5 मिनट TTL)**: डिलीट किए गए/रीनेम किए गए एंटिटी लेबल को प्रदर्शित करने का जोखिम।
 **कोई एम्बेडिंग कैशिंग नहीं:** आवश्यक नहीं है - एम्बेडिंग पहले से ही प्रति-क्वेरी कैश किए गए हैं।
 **कोई परिणाम कैशिंग नहीं:** डिलीट किए गए एंटिटीज/रिलेशनशिप से पुराने सबग्राफ परिणामों को रोकता है।
+=======
+**लेबल कैश (5 मिनट TTL)**: हटाए गए/पुनर्नाम किए गए एंटिटी लेबल को प्रदर्शित करने का जोखिम।
+**कोई एम्बेडिंग कैशिंग नहीं:** आवश्यक नहीं है - एम्बेडिंग पहले से ही प्रति-क्वेरी कैश किए गए हैं।
+**कोई परिणाम कैशिंग नहीं:** हटाए गए एंटिटीज/रिलेशनशिप से पुराने सबग्राफ परिणामों को रोकता है।
+>>>>>>> 82edf2d (New md files from RunPod)
 
 **शमन रणनीतियाँ:**
 **रूढ़िवादी TTL मान:** प्रदर्शन लाभ (10-20%) को डेटा की ताजगी के साथ संतुलित करें।
@@ -490,7 +574,11 @@ async def execute_with_timeout(self, query_func, timeout: int = 30):
 **निगरानी डैशबोर्ड:** कैश हिट दरों बनाम स्टेलनेस घटनाओं को ट्रैक करें।
 **कॉन्फ़िगर करने योग्य कैश नीतियां:** उत्परिवर्तन आवृत्ति के आधार पर प्रति-तैनाती ट्यूनिंग की अनुमति दें।
 
+<<<<<<< HEAD
 **ग्राफ उत्परिवर्तन दर द्वारा अनुशंसित कैश कॉन्फ़िगरेशन:**
+=======
+**अनुशंसित कैश कॉन्फ़िगरेशन ग्राफ उत्परिवर्तन दर द्वारा:**
+>>>>>>> 82edf2d (New md files from RunPod)
 **उच्च उत्परिवर्तन (>100 परिवर्तन/घंटा):** TTL=60s, छोटे कैश आकार।
 **मध्यम उत्परिवर्तन (10-100 परिवर्तन/घंटा):** TTL=300s (डिफ़ॉल्ट)।
 **कम उत्परिवर्तन (<10 परिवर्तन/घंटा):** TTL=600s, बड़े कैश आकार।
@@ -502,21 +590,31 @@ async def execute_with_timeout(self, query_func, timeout: int = 30):
 सभी डेटाबेस इंटरैक्शन के लिए पैरामीटराइज़्ड क्वेरी का उपयोग करें।
 DoS हमलों को रोकने के लिए क्वेरी जटिलता सीमाएं लागू करें।
 
+<<<<<<< HEAD
 **संसाधन सुरक्षा:**
+=======
+**संसाधन संरक्षण:**
+>>>>>>> 82edf2d (New md files from RunPod)
 अधिकतम सबग्राफ आकार सीमाओं को लागू करें।
 संसाधन समाप्त होने से रोकने के लिए क्वेरी टाइमआउट लागू करें।
 मेमोरी उपयोग निगरानी और सीमाएं जोड़ें।
 
 **पहुंच नियंत्रण:**
 मौजूदा उपयोगकर्ता और संग्रह अलगाव बनाए रखें।
+<<<<<<< HEAD
 प्रदर्शन-प्रभावित करने वाले कार्यों के लिए ऑडिट लॉगिंग जोड़ें।
 महंगे कार्यों के लिए दर सीमित करना लागू करें।
+=======
+प्रदर्शन-प्रभावित संचालन के लिए ऑडिट लॉगिंग जोड़ें।
+महंगे संचालन के लिए दर सीमित करना लागू करें।
+>>>>>>> 82edf2d (New md files from RunPod)
 
 ## प्रदर्शन संबंधी विचार
 
 ### अपेक्षित प्रदर्शन सुधार
 
 **क्वेरी में कमी:**
+<<<<<<< HEAD
 वर्तमान: विशिष्ट अनुरोध के लिए ~9,000+ क्वेरी
 अनुकूलित: ~50-100 बैच क्वेरी (98% कमी)
 
@@ -527,6 +625,18 @@ DoS हमलों को रोकने के लिए क्वेरी
 
 **मेमोरी दक्षता:**
 बाउंडेड कैश आकार मेमोरी लीक को रोकते हैं।
+=======
+वर्तमान: विशिष्ट अनुरोध के लिए ~9,000+ क्वेरी।
+अनुकूलित: ~50-100 बैच क्वेरी (98% कमी)।
+
+**प्रतिक्रिया समय में सुधार:**
+ग्राफ ट्रैवर्सल: 15-20s → 3-5s (4-5x तेज़)।
+लेबल रिज़ॉल्यूशन: 8-12s → 2-4s (3x तेज़)।
+कुल क्वेरी: 25-35s → 6-10s (3-4x सुधार)।
+
+**मेमोरी दक्षता:**
+बंधी हुई कैश आकार मेमोरी लीक को रोकते हैं।
+>>>>>>> 82edf2d (New md files from RunPod)
 कुशल डेटा संरचनाएं मेमोरी पदचिह्न को ~40% तक कम करती हैं।
 उचित संसाधन सफाई के माध्यम से बेहतर कचरा संग्रह।
 
@@ -582,7 +692,11 @@ DoS हमलों को रोकने के लिए क्वेरी
 ## कार्यान्वयन योजना
 
 ### प्रत्यक्ष कार्यान्वयन दृष्टिकोण
+<<<<<<< HEAD
 चूंकि API में परिवर्तन की अनुमति है, इसलिए माइग्रेशन जटिलता के बिना अनुकूलन को सीधे लागू करें:
+=======
+चूंकि एपीआई में बदलाव की अनुमति है, इसलिए माइग्रेशन जटिलता के बिना अनुकूलन को सीधे लागू करें:
+>>>>>>> 82edf2d (New md files from RunPod)
 
 1. **`follow_edges` विधि को बदलें**: पुनरावृत्त बैच ट्रैवर्सल के साथ फिर से लिखें
 2. **`get_labelgraph` को अनुकूलित करें**: समानांतर लेबल रिज़ॉल्यूशन लागू करें
@@ -604,7 +718,11 @@ DoS हमलों को रोकने के लिए क्वेरी
 एक लेबल कैशिंग परत लागू करें
 
 **सप्ताह 2: परीक्षण और एकीकरण**
+<<<<<<< HEAD
 नए ट्रैवर्सल और कैशिंग तर्क के लिए यूनिट परीक्षण
+=======
+नए ट्रैवर्सल और कैशिंग लॉजिक के लिए यूनिट परीक्षण
+>>>>>>> 82edf2d (New md files from RunPod)
 वर्तमान कार्यान्वयन के खिलाफ प्रदर्शन बेंचमार्किंग
 वास्तविक ग्राफ डेटा के साथ एकीकरण परीक्षण
 कोड समीक्षा और अनुकूलन
@@ -617,7 +735,11 @@ DoS हमलों को रोकने के लिए क्वेरी
 ## खुले प्रश्न
 
 **डेटाबेस कनेक्शन पूलिंग**: क्या हमें कस्टम कनेक्शन पूलिंग लागू करनी चाहिए या मौजूदा डेटाबेस क्लाइंट पूलिंग पर भरोसा करना चाहिए?
+<<<<<<< HEAD
 **कैश दृढ़ता**: क्या लेबल और एम्बेडिंग कैश सेवा पुनरारंभों में बने रहने चाहिए?
+=======
+**कैश दृढ़ता**: क्या लेबल और एम्बेडिंग कैश सेवा पुनरारंभों में बने रहेंगे?
+>>>>>>> 82edf2d (New md files from RunPod)
 **वितरित कैशिंग**: मल्टी-इंस्टेंस परिनियोजन के लिए, क्या हमें Redis/Memcached के साथ वितरित कैशिंग लागू करनी चाहिए?
 **क्वेरी परिणाम प्रारूप**: क्या हमें बेहतर मेमोरी दक्षता के लिए आंतरिक ट्रिपल प्रतिनिधित्व को अनुकूलित करना चाहिए?
 **निगरानी एकीकरण**: मौजूदा निगरानी प्रणालियों (Prometheus, आदि) के लिए कौन से मेट्रिक्स उजागर किए जाने चाहिए?