इस लेख में, हम इस बात पर विस्तृत चर्चा करेंगे कि वितरित अपाचे इग्नाइट डेटाबेस में B + ट्री कैसे बनाया जाता है।

एच-पेड़ों पर बी-पेड़ों ( एक , दो ) पर पहले से ही कुछ लेख हैं, लेकिन वे अधिक संभावना सैद्धांतिक हैं और यहां तक ​​कि अगर उनमें कार्यान्वयन होता है, तो वे उत्पादन के लिए तैयार नहीं हैं। इससे जीवन में उपयोग होने वाले कार्यान्वयन को देखने के लिए एक रुचि है।

लेख को आगे पढ़ने से पहले, मैं आपको मैक्सिम बेबेंको का एक व्याख्यान देखने की सलाह देता हूं, अगर आपको अभी भी नहीं पता है कि बी-ट्री सिद्धांत में क्या है। लेकिन मुझे जावा को गहराई से या अपाचे इग्नाइट प्रोजेक्ट को जानने की आवश्यकता नहीं है - मैं या तो विवरण स्पष्ट रूप से लिखूंगा या इसे बिगाड़ने के तहत छिपाऊंगा।

जब आप प्रज्वलित स्रोतों को पढ़ते हैं, तो मैं आपको सलाह देता हूं कि आप अपने दिमाग में विधियों के तर्कों को छोड़ दें, जिसका अर्थ बहुत स्पष्ट नहीं है और कार्यों के नामों को पढ़ना है - यदि आप अग्रिम में जानते हैं कि फ़ंक्शन के शरीर को पढ़ना बहुत आसान है।

कृपया ध्यान दें कि मैं अपाचे इग्नाइट का प्रमुख डेवलपर नहीं हूं और कोड से कुछ गलत समझ सकता था। इसलिए, मैंने वाक्यांश "जहां तक ​​मैं समझता हूं" को बाहर रखा, जिसे प्रत्येक सकारात्मक वाक्य से पहले मानसिक रूप से जोड़ा जाना चाहिए।

क्यों अपाचे में बी + पेड़ प्रज्वलित

अपाचे इग्नाइट एक इन-मेमोरी डेटाबेस है, लेकिन संस्करण 2.1 के बाद से इसमें एक निरंतर डेटा स्टोर है - डिस्क को डेटा बचाने के लिए एक फ़ंक्शन ( लगातार डेटा संरचना के साथ कुछ भी नहीं करना है) । इसलिए, यह स्पष्ट है कि बाहरी स्मृति के लिए एक संरचना की आवश्यकता क्यों है, यह समझने के लिए बनी हुई है कि उन्होंने दूसरे को क्यों नहीं चुना।

के साथ शुरू करने के लिए, बी + पेड़ बी-पेड़ का एक अनुकूलन है, जहां मूल्यों को केवल पत्तियों में संग्रहीत किया जाता है। इस अनुकूलन में, अधिक कुंजी एक नोड में फिट होती हैं, जिससे ब्रांचिंग की डिग्री बढ़ जाती है। इसलिए, क्लासिक बी-ट्री का उपयोग करने का बहुत कारण नहीं है।

बी * और बी + * - डिस्क पर सघन हैं, लेकिन उनका प्रदर्शन खराब है, क्योंकि हम रैम से डेटा स्टोर करते हैं, प्रदर्शन हमारे लिए अधिक महत्वपूर्ण है।

बेंचमार्क से देखते हुए , एक एलएसएम पेड़ लिखने में तेज है, लेकिन पढ़ने में धीमा है। इसके अलावा, पढ़ने में नुकसान लेखन में लाभ से अधिक है, इसलिए एक काल्पनिक सामान्य मामले के लिए, मैं बी + पेड़ भी ले जाऊंगा।

वहाँ भी अजीब भग्न पेड़ हैं , हालांकि, जाहिरा तौर पर, वे केवल टोकुबीडी में पेटेंट और कार्यान्वित किए जाते हैं ।

व्यक्तिगत रूप से, मुझे इस बात में अधिक दिलचस्पी है कि क्यों लेवलबैंक की तरह रेडीमेड डिस्क बैकएंड लेना असंभव था? एक आंशिक उत्तर यह है कि पीडीएस तीसरे पक्ष के भंडारण का समर्थन करता है।

बड़े सेल कार्यान्वयन

प्रारंभ में, ग्रिडगैन ने अपाचे इग्नाइट को विकसित किया, लेकिन ओपन-सोर्स के लिए जाने से पहले, इसने कंपनी का नाम बोर कर दिया, इसलिए कुछ घटकों के नाम Grid शुरू होते हैं, और अन्य लोग Ignite साथ। इसलिए GridCursor , लेकिन IgniteTree । यहां कोई और तर्क नहीं है।

अपाचे इग्नाइट कोड जावा सर्वोत्तम प्रथाओं पैटर्न में लिखा गया है, और प्रत्येक वर्ग एक इंटरफ़ेस प्राप्त करता है, यदि एक नहीं। IgniteTree इंटरफ़ेस से और नृत्य शुरू करें। मैं javadoc के बिना कोड देता हूं, संक्षेप में।

 public interface IgniteTree<L, T> { public T put(T val) throws IgniteCheckedException; public void invoke(L key, Object x, InvokeClosure<T> c) throws IgniteCheckedException; public T findOne(L key) throws IgniteCheckedException; public GridCursor<T> find(L lower, L upper) throws IgniteCheckedException; public GridCursor<T> find(L lower, L upper, Object x) throws IgniteCheckedException; public T findFirst() throws IgniteCheckedException; public T findLast() throws IgniteCheckedException; public T remove(L key) throws IgniteCheckedException; public long size() throws IgniteCheckedException; interface InvokeClosure<T> { void call(@Nullable T row) throws IgniteCheckedException; T newRow(); OperationType operationType(); } enum OperationType { NOOP, REMOVE, PUT } } 

IgniteTree इंटरफ़ेस ऑपरेशन के एक मानक सेट का वर्णन करता है। कृपया ध्यान दें कि सीमा खोज करने के लिए आपको एक सूची में पत्तियों को बुनना पड़ता है। बोनस एक मनमाना रिकॉर्ड ऑपरेशन का समर्थन करता है - invoke ।

put ऑपरेशन बिना चाबी के केवल T का एक तर्क लेता है। आपको इसके लिए IgniteTree में स्पष्टीकरण नहीं मिलेगा, हालांकि इसका जवाब BPlusTree हेडर में छिपा है।

 public abstract class BPlusTree<L, T extends L> extends DataStructure implements IgniteTree<L, T> 

जैसा कि आप देख सकते हैं, मूल्य कुंजी को विरासत में मिला है, इसलिए, पुट ऑपरेशन में, मूल्य से कुंजी की गणना की जाती है। यह पेड़ की कार्यक्षमता को सीमित नहीं करता है। मेरी धारणा यह है कि यह स्टोर करने के लिए अधिक कॉम्पैक्ट है।

आमतौर पर वे मूल्य से स्थिर कचरा संलग्न करके नक्शे से बाहर सेट करते हैं। हालांकि, बी + पेड़ में, केवल चाबियाँ नोड्स में संग्रहीत की जाती हैं, यदि मूल्य भी कुंजी संग्रहीत करता है, तो पत्तियों में यह केवल मूल्यों को संग्रहीत करने के लिए पर्याप्त है। और अगर पेड़ एक सेट है, तो यह स्वचालित रूप से निकलता है कि पत्तियों में कचरा मूल्यों के बिना केवल चाबियाँ होंगी।

अब तत्व खोज कोड को देखते हैं।

 /** * @param g Get. * @throws IgniteCheckedException If failed. */ private void doFind(Get g) throws IgniteCheckedException { for (;;) { // Go down with retries. g.init(); switch (findDown(g, g.rootId, 0L, g.rootLvl)) { case RETRY: case RETRY_ROOT: checkInterrupted(); continue; default: return; } } } /** * @param g Get. * @param pageId Page ID. * @param fwdId Expected forward page ID. * @param lvl Level. * @return Result code. * @throws IgniteCheckedException If failed. */ private Result findDown(final Get g, final long pageId, final long fwdId, final int lvl) throws IgniteCheckedException { long page = acquirePage(pageId); try { for (;;) { // Init args. g.pageId = pageId; g.fwdId = fwdId; Result res = read(pageId, page, search, g, lvl, RETRY); switch (res) { case GO_DOWN: case GO_DOWN_X: assert g.pageId != pageId; assert g.fwdId != fwdId || fwdId == 0; // Go down recursively. res = findDown(g, g.pageId, g.fwdId, lvl - 1); switch (res) { case RETRY: checkInterrupted(); continue; // The child page got split, need to reread our page. default: return res; } case NOT_FOUND: assert lvl == 0 : lvl; g.row = null; // Mark not found result. return res; default: return res; } } } finally { if (g.canRelease(pageId, lvl)) releasePage(pageId, page); } } 

बी-ट्री ट्रैवर्सल एल्गोरिथ्म का आधार अपरिवर्तित रहा है: वे पुन: पेड़ को वांछित पत्ती तक ले जाते हैं: यदि मूल्य मौजूद है, तो वे परिणाम वापस करते हैं, और यदि नहीं, तो null । पुनरावृत्ति स्पष्ट रूप से सुविधा के लिए छोड़ दी गई थी, वैसे भी, बी-पेड़ गहरे नहीं हैं।

मैं आश्चर्यचकित था क्योंकि मेरे सिर में एक स्पष्ट स्थापना थी: पुनरावृत्ति हमेशा एक वास्तविक परियोजना में हटा दी जाती है ( जावा में कोई पूंछ पुनरावृत्ति अनुकूलन नहीं है , अन्य भाषाओं में परियोजनाओं में पुनरावृत्ति स्वीकार्य है)। लेकिन वास्तव में, बी-पेड़ की ऊंचाई इकाइयों में मापा जाता है, क्योंकि ऑर्डर ब्लॉक का आकार $$$2 ^ {10}$, और आदेश के डेटा की संख्या $$$2 ^ {40}$और ऊंचाई होगी $$$\ frac {लॉग (2 ^ {40})} {लॉग (2 ^ {10})} = 4$।

अपाचे इग्नाइट को कॉन्सर्ट पसंद है । इसलिए, पेड़ प्रतिस्पर्धी संशोधन का समर्थन करता है। ऑपरेशन के समय, एक पृष्ठ अवरुद्ध है, लेकिन एक और धागा बाकी पेड़ को संशोधित कर सकता है ताकि एक दूसरे पढ़ने की आवश्यकता हो। और इसलिए प्रक्रिया जड़ तक पहुंच सकती है।

सबसे पहले, मुझे इस तरह की कार्यक्षमता का अर्थ समझ में नहीं आया, क्योंकि डिस्क धीमी है और एक धागा शांति से सभी I / O संचालन की प्रक्रिया करेगा। यह स्पष्ट है कि डिस्क से लोड नोड में खोज की थोड़ी लागत होती है और इस दौरान आप डिस्क को दूसरे ऑपरेशन के साथ लोड कर सकते हैं, लेकिन बार-बार प्रयास करने से लाभ प्राप्त होगा। हालांकि, तब यह मुझ पर हावी हो गया कि इस कार्यान्वयन में नोड्स को संशोधन के बाद तुरंत डिस्क में नहीं डाला गया था, लेकिन वे कुछ समय के लिए मेमोरी में लटका रहे थे, फिर तुरंत कई संशोधनों को लागू करने के लिए। कोई डेटा नहीं लिखा है धन्यवाद लिखने के लिए धन्यवाद लॉग करें। इसके बारे में अधिक लेख के अंत में होगा।

अब एक आइटम जोड़ने के लिए कोड देखते हैं।

 private T doPut(T row, boolean needOld) throws IgniteCheckedException { checkDestroyed(); Put p = new Put(row, needOld); try { for (;;) { // Go down with retries. p.init(); Result res = putDown(p, p.rootId, 0L, p.rootLvl); switch (res) { case RETRY: case RETRY_ROOT: checkInterrupted(); continue; case FOUND: // We may need to insert split key into upper level here. if (!p.isFinished()) { // It must be impossible to have an insert higher than the current root, // because we are making decision about creating new root while keeping // write lock on current root, so it can't concurrently change. assert p.btmLvl <= getRootLevel(); checkInterrupted(); continue; } return p.oldRow; default: throw new IllegalStateException("Result: " + res); } } } catch (IgniteCheckedException e) { throw new IgniteCheckedException("Runtime failure on row: " + row, e); } catch (RuntimeException e) { throw new IgniteException("Runtime failure on row: " + row, e); } catch (AssertionError e) { throw new AssertionError("Assertion error on row: " + row, e); } finally { checkDestroyed(); } } /** * @param p Put. * @param pageId Page ID. * @param fwdId Expected forward page ID. * @param lvl Level. * @return Result code. * @throws IgniteCheckedException If failed. */ private Result putDown(final Put p, final long pageId, final long fwdId, final int lvl) throws IgniteCheckedException { assert lvl >= 0 : lvl; final long page = acquirePage(pageId); try { for (;;) { // Init args. p.pageId = pageId; p.fwdId = fwdId; Result res = read(pageId, page, search, p, lvl, RETRY); switch (res) { case GO_DOWN: case GO_DOWN_X: assert lvl > 0 : lvl; assert p.pageId != pageId; assert p.fwdId != fwdId || fwdId == 0; res = p.tryReplaceInner(pageId, page, fwdId, lvl); if (res != RETRY) // Go down recursively. res = putDown(p, p.pageId, p.fwdId, lvl - 1); if (res == RETRY_ROOT || p.isFinished()) return res; if (res == RETRY) checkInterrupted(); continue; // We have to insert split row to this level or it is a retry. case FOUND: // Do replace. assert lvl == 0 : "This replace can happen only at the bottom level."; return p.tryReplace(pageId, page, fwdId, lvl); case NOT_FOUND: // Do insert. assert lvl == p.btmLvl : "must insert at the bottom level"; assert p.needReplaceInner == FALSE : p.needReplaceInner + " " + lvl; return p.tryInsert(pageId, page, fwdId, lvl); default: return res; } } } finally { if (p.canRelease(pageId, lvl)) releasePage(pageId, page); } } 

अंतर केवल इतना है कि स्थिति का पता लगने के बाद, कोड replace और insert । remove कोड को अब नहीं देखा जा सकता है। बुनियादी तंत्र यह है कि ऑपरेशन के आधार पर एक विशेष वस्तु के साथ पेड़ के माध्यम से पुनरावृत्ति से चलने का बार-बार प्रयास: Get , Put या Remove ।

उसी तरह से काम करता है, केवल ऑपरेशन रिकॉर्ड की एक प्रति के साथ होता है, फिर इसका प्रकार निर्धारित किया जाता है: पढ़ने के लिए NOOP , REMOVE लिए REMOVE और अद्यतन करने या जोड़ने के लिए PUT , और फिर संबंधित Put या Remove ऑब्जेक्ट उत्पन्न होता है, जो पेड़ में रिकॉर्ड पर लागू होता है।

के उपयोग

नीचे मैं दो BPlusTree पर करीब से नज़र BPlusTree : CacheDataTree और PendingEntriesTree । ओवरबोर्ड इंडेक्स का कार्यान्वयन है - यह एक अलग चर्चा का विषय है, जिसके लिए मैं अभी तैयार नहीं हूं।

आगे बढ़ने से पहले, मैं स्पष्ट कर दूंगा कि स्थानीय वितरित नक्शे में IgniteCache कार्यक्षमता है और इसे IgniteCache कहा जाता है - इसके बाद केवल एक कैश।

CacheDataTree

CacheDataTree डिस्क के लिए कई IgniteCache की मैपिंग है। सॉर्टिंग बहु-स्तरीय है: पहले कैश में समूह कुंजी में कैश आईडी और फिर हैश द्वारा सॉर्ट करें।

CacheDataTree सीमा से अधिक पुनरावृत्त नहीं होती है, चूंकि H2Tree extends BPlusTree के वारिस में अनुक्रमणिका को कार्यान्वित किया H2Tree extends BPlusTree , इसलिए H2Tree extends BPlusTree , इसलिए विशिष्ट प्रकार की छंटाई महत्वपूर्ण नहीं है: कोई भी put लिए पर्याप्त है और संचालन get करता है। बराबरी की तुलना में हैश की तुलना अधिक तेज है। लेकिन इससे भी महत्वपूर्ण बात, एक समान हैश पेड़ को अधिक घनी रूप से भर देगा।

पेड़ संतुलन बनाते हैं ताकि वे एक सूची में न घटें। लेकिन यदि आप खोज ट्री में समान रूप से वितरित कुंजियाँ जोड़ते हैं, तो यह स्वचालित रूप से संतुलित हो जाएगा। चूंकि बी-पेड़ समस्याएँ पैदा करना शुरू कर देते हैं, और हैश मिक्स कीज़ भी समान रूप से होती हैं, हैश द्वारा छाँटने से संतुलन की आवृत्ति कम हो जाती है।

खोज के पेड़ में हैश का उपयोग करना इतना अजीब विचार नहीं है क्योंकि ऐसा लगता है, इसके तार्किक विकास से हैश एरे मैप्ड ट्राई होगा ।

PendingEntriesTree

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

समझें कि यह अलग साहसिक काम कैसे करता है।

 @Override public boolean expire( GridCacheContext cctx, IgniteInClosure2X<GridCacheEntryEx, GridCacheVersion> c, int amount ) 

 private final IgniteInClosure2X<GridCacheEntryEx, GridCacheVersion> expireC = new IgniteInClosure2X<GridCacheEntryEx, GridCacheVersion>() { @Override public void applyx(GridCacheEntryEx entry, GridCacheVersion obsoleteVer) { boolean touch = !entry.isNear(); while (true) { try { if (log.isTraceEnabled()) log.trace("Trying to remove expired entry from cache: " + entry); if (entry.onTtlExpired(obsoleteVer)) touch = false; break; } catch (GridCacheEntryRemovedException ignore) { entry = entry.context().cache().entryEx(entry.key()); touch = true; } } if (touch) entry.context().evicts().touch(entry, null); } }; 

 cctx.cache().removeEntry(this); 

कार्यान्वयन का विवरण

Offheap में पृष्ठों के साथ काम करें

ऑफशेयर एक कचरा कलेक्टर के साथ भाषा में मैनुअल मेमोरी प्रबंधन के अनुकूलन के लिए एक तकनीक है।

यह एक मिथक है कि कचरा इकट्ठा करने वाले के कारण सब कुछ धीमा हो जाता है, आमतौर पर कलेक्टरों के प्रदर्शन का दयनीय प्रतिशत होता है । यहां तक ​​कि अपने आप में बड़े ढेर भी एक समस्या नहीं है, क्योंकि कलेक्टर प्रतिस्पर्धी रूप से काम करते हैं (उदाहरण के लिए, जावा में सीएमएस और जी 1), और सर्वरों में दर्जनों कोर हैं । बेशक, कलेक्टर आवेदन में अप्रत्याशित ठहराव जोड़ता है, जो खेल के लिए महत्वपूर्ण है, लेकिन डेटाबेस के लिए सहनीय है।

लेकिन वास्तव में समस्या क्या होगी यह एक बड़े ढेर पर उत्पत्ति संबंधी परिकल्पना का उल्लंघन है।

और यहां यह ऐसी बात है कि पीडीएस के आगमन से पहले, अपाचे इग्नाइट को मुख्य रूप से सेवाओं और एक डिस्क डेटाबेस (उदाहरण के लिए, हडोप ) के बीच कैश के रूप में तैनात किया गया था। इसलिए, IgniteCache में मैप्स को इग्नाइटेचे कहा जाता है और इसमें एक्सट्रूज़न की कार्यक्षमता होती है। और कैश सिर्फ पीढ़ीगत परिकल्पना का उल्लंघन करते हैं - उनमें, समय के साथ किसी वस्तु के नष्ट होने की संभावना बढ़ जाती है। इसलिए, इस मामले में, उपयोगकर्ता डेटा को संग्रहीत करने के लिए ऑफश प्रदर्शन में सुधार करता है।

अधिक बोनस:

• Offheap, Integer.MAX_VALUE तत्वों से अधिक संरचनाओं को लागू करना आसान बनाता है।
• यदि आप 32 जीबी से कम का एक गुच्छा रखते हैं, तो लिंक 4 बाइट्स का वजन करेंगे , जो कुछ गीगाबाइट बचाता है।
• चूंकि कलेक्टर वस्तुओं का एक ग्राफ बनाता है, इसलिए यह उनकी संख्या के अनुपात में मेमोरी का उपभोग करता है। और वस्तुओं की संख्या ढेर के समानुपाती होती है। कलेक्टर एक सीपीयू भी खाते हैं, जो डेटा संपीड़न के लिए बेहतर खर्च होता है, उदाहरण के लिए।
• बहुत बड़े ढेर पर, भले ही पीढ़ीगत परिकल्पना का समग्र रूप से उल्लंघन नहीं किया जाता है, फिर भी पूर्ण मूल्य में बहुत सारी पुरानी वस्तुएं होंगी जो इसका उल्लंघन करेगी।

चूंकि डेटा को डिस्क में भेजा जाता है, वस्तुओं को सीधे unsafe माध्यम से मेमोरी में क्रमबद्ध किया unsafe , और फिर इस मेमोरी क्षेत्र का उपयोग I / O बफर के लिए किया जाता है।

आगे लॉग लॉग करें

लिखें आगे लॉग एक रैखिक संरचना के साथ संचालन का एक लॉग है, इसे जोड़ने के लिए एक पेड़ के विपरीत एक स्थिर लागत होती है। पेड़ को कम बार अद्यतन किया जाता है, और यदि डेटा गिरने के कारण खो जाता है, तो उन्हें अंतिम सहेजे गए राज्य से शुरू होने वाले संचालन को लागू करके लॉग से पुनर्स्थापित किया जाता है। विश्वसनीयता में सुधार के बिना परिणाम बेहतर प्रदर्शन होता है। मैं आपको IgniteWriteAheadLogManager इंटरफ़ेस पर एक नज़र डालने की सलाह देता हूं - विस्तृत प्रलेखन है।

नोड बाईपास

चूंकि बी-पेड़ों में नोड्स छोटे नहीं हैं, वे बाइनरी खोज द्वारा बाईपास किए गए हैं। इसके लिए, BPlusTree.GetPageHandler वर्ग के वंशज का BPlusTree.GetPageHandler , और विभिन्न ऑपरेशनों के लिए वे अलग-अलग होते हैं।

 private int findInsertionPoint(int lvl, BPlusIO<L> io, long buf, int low, int cnt, L row, int shift) throws IgniteCheckedException { assert row != null; int high = cnt - 1; while (low <= high) { int mid = (low + high) >>> 1; int cmp = compare(lvl, io, buf, mid, row); if (cmp == 0) cmp = -shift; // We need to fix the case when search row matches multiple data rows. //noinspection Duplicates if (cmp < 0) low = mid + 1; else if (cmp > 0) high = mid - 1; else return mid; // Found. } return -(low + 1); // Not found. } 

 if (cmp == 0) cmp = -shift; 

चादरों की सूची

कुशलता से सीमा के आसपास पाने के लिए, चादरें एक सूची से बंधी होती हैं। BPlusTree.ForwardCursor , जो शीट से शीट पर जाता है, एक खोज परिणाम के रूप में वापस आ जाता है। जाहिर है, कर्सर पास पेड़ में अन्य संचालन से अलग नहीं है, क्योंकि पास करते समय, लॉक केवल एक पृष्ठ पर लिया जाता है। मुझे एक तुल्यकालन तंत्र नहीं मिला जो कर्सर विधियों तक पहुंच की रक्षा करता है।

निष्कर्ष

चूंकि अपाचे इग्नाइट में B + ट्री अन्य रिलेशनल डेटाबेस की तुलना में युवा है, इसलिए हमें प्रोडक्शन के लिए आवश्यक सेट B + ट्री मिलता है:

• वाल सस्ती सुरक्षा देता है, परिणामस्वरूप, डिस्क पर पेड़ को शायद ही कभी अपडेट किया जाता है।
• क्रमबद्ध रूप में डेटा के साथ ऑफशिप ।
• कंसीडर - स्मृति में लदे पेड़ के हिस्सों के लिए।