Mysql: 192 ट्रिलियन रिकॉर्ड्स के साथ काम करना ... (हां, 192 ट्रिलियन)


39

ये रहा सवाल ...

192 ट्रिलियन रिकॉर्ड को ध्यान में रखते हुए, मेरे विचार क्या होने चाहिए?

मेरी मुख्य चिंता गति है।

यहाँ तालिका है ...

    CREATE TABLE `ref` (
  `id` INTEGER(13) AUTO_INCREMENT DEFAULT NOT NULL,
  `rel_id` INTEGER(13) NOT NULL,
  `p1` INTEGER(13) NOT NULL,
  `p2` INTEGER(13) DEFAULT NULL,
  `p3` INTEGER(13) DEFAULT NULL,
  `s` INTEGER(13) NOT NULL,
  `p4` INTEGER(13) DEFAULT NULL,
  `p5` INTEGER(13) DEFAULT NULL,
  `p6` INTEGER(13) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY (`s`),
  KEY (`rel_id`),
  KEY (`p3`),
  KEY (`p4`)
    );

ये रहा सवाल ...

SELECT id, s FROM ref WHERE red_id="$rel_id" AND p3="$p3" AND p4="$p4"

SELECT rel_id, p1, p2, p3, p4, p5, p6 FROM ref WHERE id="$id"

INSERT INTO rel (rel_id, p1, p2, p3, s, p4, p5, p6)
VALUES ("$rel_id", "$p1", "$p2", "$p3", "$s", "$p4", "$p5", "$p6")

यहां देखें कुछ नोट ...

  • चयन का INSERT की तुलना में अधिक बार किया जाएगा। हालांकि, कभी-कभी मैं एक बार में कुछ सौ रिकॉर्ड जोड़ना चाहता हूं।
  • लोड-वार, कुछ घंटों के लिए कुछ भी नहीं होगा, तो शायद कुछ हजार प्रश्न एक ही बार में।
  • मुझे नहीं लगता कि मैं किसी भी अधिक को सामान्य कर सकता हूं (संयोजन में p मान की आवश्यकता है)
  • एक पूरे के रूप में डेटाबेस बहुत ही संबंधपरक है।
  • यह अब तक की सबसे बड़ी तालिका होगी (अगली सबसे बड़ी लगभग 900k है)

अद्यतन (08/11/2010)

दिलचस्प है, मुझे एक दूसरा विकल्प दिया गया है ...

192 ट्रिलियन के बजाय मैं 2.6 * 10 ^ 16 (15 शून्य, 26 क्वाड्रिलियन) स्टोर कर सकता था ...

लेकिन इस दूसरे विकल्प में मुझे केवल एक बिंदी (18) को एक तालिका में सूचकांक के रूप में संग्रहीत करने की आवश्यकता होगी। वह यह है - सिर्फ एक कॉलम। तो मैं सिर्फ एक मूल्य के अस्तित्व के लिए जाँच कर रहा हूँ। कभी-कभी रिकॉर्ड जोड़ते हैं, कभी उन्हें हटा नहीं रहे हैं।

ताकि मुझे लगता है कि वहाँ एक बेहतर समाधान होना चाहिए तो mysql बस संख्या संचय के लिए ...

इस दूसरे विकल्प को देखते हुए, मुझे इसे लेना चाहिए या पहले के साथ रहना चाहिए ...

[संपादित करें] बस कुछ परीक्षण की खबर मिली है - इस सेटअप के साथ १०० मिलियन पंक्तियों में क्वेरी ०.०००४ सेकंड में वापस आती है [/ संपादित करें]


7
इसके लिए आप MySQL का उपयोग करने के लिए कितने तैयार हैं? यदि कोई व्यक्ति ऐसा करने के लिए ठोस तर्क प्रदान करता है, तो क्या आप एक अलग dbms में जाने के लिए आश्वस्त हो सकते हैं?
WheresAlice

3
ट्रिलियन 10 ^ 12 या 10 ^ 18 के रूप में?
औरोल

15
192 ट्रिलियन रिकॉर्ड में आपके पास एक बजट होना चाहिए जो आपको कुछ चर्चा मंचों पर MySQL कमिटर्स से सवाल पूछने की अनुमति देता है।
रेमुस रुसानु

5
एक डेटाबेस के साथ यह बड़ा (और स्पष्ट रूप से एक सभ्य बजट) क्यों नहीं साथ जाता है और ओरेकल या एसक्यूएल सीरर समाधान जो आसानी से बड़े DBs को संभालने के लिए सिद्ध किया गया है?
जिम बी

5
इसे लागू करते समय हमें अपडेट रखना सुनिश्चित करें। मुझे निश्चित रूप से दिलचस्पी होगी। आप इसे highscalability.com
टॉम ओ'कॉनर

जवाबों:


30

pPd का अनुमान 7PB उचित है, और यह RDBMS के लिए बहुत अधिक डेटा है। मुझे यकीन नहीं है कि मैंने कभी किसी को किसी साझा डिस्क सिस्टम के साथ 7PB करने के बारे में सुना है, अकेले MySQL चलो। किसी भी साझा डिस्क सिस्टम के साथ डेटा की इस मात्रा को छोड़ना असामान्य रूप से धीमा होने वाला है। सबसे तेज़ सैन हार्डवेयर बड़े स्ट्रीमिंग प्रश्नों के लिए ट्यून किए जाने पर भी 20GB / सेकंड में अधिकतम हो जाता है। यदि आप इस युक्ति के SAN हार्डवेयर को वहन कर सकते हैं, तो आप MySQL की तुलना में नौकरी के लिए कुछ बेहतर उपयोग करने के लिए इसे पंजीकृत कर सकते हैं।

वास्तव में, मैं एक ऐसे परिदृश्य की कल्पना करने के लिए संघर्ष कर रहा हूं, जहां आपके पास इस युक्ति के डिस्क सबसिस्टम के लिए बजट हो सकता है, लेकिन बेहतर DBMS प्लेटफॉर्म के लिए नहीं। यहां तक ​​कि 600GB डिस्क (बाजार पर वर्तमान में सबसे बड़ा 15K 'एंटरप्राइज ड्राइव) का उपयोग करके आप 7PB स्टोर करने के लिए 12,000 भौतिक डिस्क ड्राइव जैसी किसी चीज़ के लिए तैयार हैं। SATA डिस्क सस्ती होगी (और 2TB डिस्क के साथ आपको लगभग 1/3 नंबर की आवश्यकता होगी), लेकिन काफी धीमी।

EMC या हिताची जैसे प्रमुख विक्रेता से इस युक्ति का SAN कई मिलियन डॉलर तक चलेगा। पिछली बार जब मैंने एक प्रमुख विक्रेता से सैन उपकरणों के साथ काम किया था, तो आईबीएम डीएस 8000 पर अंतरिक्ष की हस्तांतरण लागत £ 10k / TB से अधिक थी, नियंत्रकों के लिए किसी भी पूंजी भत्ते को शामिल नहीं किया गया था।

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

आपको अपनी प्रदर्शन आवश्यकताओं के बारे में भी सोचना होगा।

  • क्वेरी के लिए स्वीकार्य रन समय क्या है?
  • आप अपने डेटासेट को कितनी बार क्वेरी करेंगे?
  • क्या अधिकांश प्रश्नों को एक इंडेक्स का उपयोग करके हल किया जा सकता है (यानी वे एक छोटे से अंश को देखने जा रहे हैं - कहते हैं: 1% से कम - डेटा का), या क्या उन्हें एक पूर्ण तालिका स्कैन करने की आवश्यकता है?
  • डेटाबेस में डेटा कितनी जल्दी लोड होने वाला है?
  • क्या आपके प्रश्नों को अप-टू-डेट डेटा की आवश्यकता है या क्या आप समय-समय पर ताज़ा रिपोर्टिंग तालिका के साथ रह सकते हैं?

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

नोट: यदि आप अपने परिचालन और रिपोर्टिंग डेटाबेस को विभाजित करते हैं, तो जरूरी नहीं कि आपको दोनों के लिए एक ही DBMS प्लेटफॉर्म का उपयोग करना पड़े। एक ही 7PB टेबल से तेजी से आवेषण और उप-दूसरी रिपोर्ट प्राप्त करना कम से कम एक तकनीकी चुनौती होने वाली है।

आपकी टिप्पणियों से कि आप रिपोर्टिंग में कुछ विलंबता के साथ रह सकते हैं, आप अलग कैप्चर और रिपोर्टिंग सिस्टम पर विचार कर सकते हैं, और आपको अपने परिचालन कैप्चर सिस्टम में सभी 7PB डेटा रखने की आवश्यकता नहीं हो सकती है। एक संचालन डेटा पर कब्जा के लिए इस तरह के ओरेकल के रूप में मंच (MySQL InnoDB के साथ ऐसा कर सकते हैं) (फिर से, डिस्क की लागत अकेले डीबीएमएस की लागत बौना होगा जब तक आप एक है पर विचार करें बहुत प्रयोक्ताओं की) और की तरह एक VLDB मंच Teradata, Sybase रिपोर्टिंग के लिए IQ, RedBrick, Netezza (नोट: मालिकाना हार्डवेयर) या Greenplum


1
@ConcernedOfTunbridgeW - वे हमेशा इस तरह से जा सकते हैं: blog.backblaze.com/2009/09/01/… - सैन की तुलना में बहुत अधिक मजेदार, केवल ~ 120-130 4U बक्से की जरूरत है ... लेकिन मुझे यकीन नहीं है कि अगर ' व्यापार 'खुश होगा ....
pQd

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

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

@ConcernedOfTunbridgeWells और आप उन सभी प्रश्नों / रखरखाव और किसी भी चीज को कई [अन्यथा बिजली भूखे] बक्से में समानांतर में चला सकते हैं।
pQd

1
@ConcernedOfTunbridgeWells - आपको सवालों के जवाब देने के लिए ... यदि संभव हो तो मुझे एक सेकंड के भीतर लौटने के लिए लगभग 500 प्रश्नों की आवश्यकता है। मैं दिन में केवल कुछ सौ बार ऐसा कर रहा हूँ। जब कोई क्वेरी चलती है, तो पूर्ण तालिका को स्कैन करने की आवश्यकता होती है। इसके अलावा INSERT की SELECT की तुलना में कम प्राथमिकता है, इसलिए इसे तत्काल कहीं भी नहीं होना चाहिए। मैं डेटाबेस में "नया" डेटा प्राप्त करने के लिए कुछ घंटों तक प्रतीक्षा कर सकता हूं।
सारा

16

इसे ठीक करो। इस आकार में एक बड़ा उदाहरण एक आत्महत्या है - संभावित बैकअप पुनर्स्थापना, टेबल स्पेस भ्रष्टाचारों के बारे में सोचें, नए कॉलम या किसी अन्य 'हाउस कीपिंग' प्रक्रियाओं को जोड़ना - उन सभी को इस पैमाने पर उचित समय में किया जाना असंभव है।

लिफाफा गणना की सरल पीठ - 64 बिट आईडी को छोड़कर सभी स्तंभों के लिए 32 बिट पूर्णांक ग्रहण करना; कोई सूचकांक शामिल नहीं:

8 * 4 बी + 8 बी = 40 बी प्रति पंक्ति [और यह बहुत आशावादी है]

192 ट्रिलियन पंक्तियाँ 40B प्रत्येक हमें लगभग 7 PB देता है

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

सवालों के जवाब देने के लिए:

  • क्या स्थिति सिस्टम क्रैश में स्वीकार्य डाउनटाइम / रिबूट हो जाता है?
  • जब आप बैकअप को पुनर्प्राप्त करने या नियोजित रखरखाव के लिए उत्पादन से सर्वर को बाहर निकालने की आवश्यकता हो, तो क्या पहुंच डाउनटाइम है।
  • आप कितनी बार और कहाँ बैकअप लेना चाहते हैं?

यादृच्छिक लिंक - आवेषण की गति:


मैं मानता हूं- 7PB बहुत भारी है। मैं फिर से सोचता हूँ और इसे हल्का हल ढूंढता हूँ, लेकिन मुझे पी फ़ील्ड्स के किसी विशेष संयोजन के अस्तित्व (या गैर-अस्तित्व) को खोजने की आवश्यकता है। तालिकाओं को विभाजित करने से मेरे दिमाग को पार कर गया - यह अधिक समझदार है, लेकिन फिर इसका मतलब है कि मुझे प्रत्येक तालिका को बदले में मिल गया है। रुचि से बाहर, आप यहां कितनी टेबल विभाजित करने की सलाह देंगे?
सारा

5
@ सार - मैं केवल तालिकाओं में ही नहीं बल्कि मशीनों में भी विभाजन की सिफारिश करूंगा। प्रदर्शन प्राप्त करने के लिए आप अपने प्रश्नों को समानांतर में चला सकते हैं [मैं इसे छोटे पैमाने पर करता हूं]। सर्वर रिबूट के बाद फाइल सिस्टम के भ्रष्टाचार या रूटीन चेकअप के बारे में क्या? मुझे यकीन नहीं है कि विशेष संयोजन खोजने से आपका क्या मतलब है ... शायद सरल कुंजी-मूल्य स्टोर मदद करेगा? तालिका का आकार - कुछ दसियों जीबी से अधिक नहीं; एकल सर्वर पर डेटा - अधिक नहीं तो कुछ टीबी। पर नज़र stackoverflow.com/questions/654594 को पता है कि सिर में दर्द बहुत छोटे पैमाने पर उम्मीद करने के लिए; innodb_file_per_table
pQd


2

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


दिलचस्प लगता है, हालांकि मैं झूठी नकारात्मक के साथ रह सकता था - लेकिन झूठी सकारात्मक नहीं :)
सारा

2

संपादित करें: वास्तव में यदि यह पूर्णता की श्रेणी में स्थान X पर "रिकॉर्ड" का केवल अस्तित्व या नहीं है, तो आप डेटास्टोर को समाप्त कर सकते हैं और बस बिटमैप का उपयोग कर सकते हैं ... इसलिए, डिस्क के 100 टीबी के साथ 10 या तो मशीनें (इसलिए आपके पास प्रदर्शन और बैकअप के लिए आपके बिटमैप की 10 प्रतियां हैं) और यदि आपने प्रति सर्वर 128 जीबी रैम किया है तो आप 26 क्वाड्रिलियन के बिट एक्स के लिए डिस्क को हिट करने से पहले पहली जांच करने के लिए एक उच्च रिज़ॉल्यूशन शीर्ष स्तर ब्लॉकग्रुप इंडेक्स को फिट कर सकते हैं। ।

मैं विकल्प # 2 के लिए जाऊंगा यदि आप लेते हैं:

64TB (32 2TB ड्राइव) के साथ 375 मशीनें (प्रत्येक विफलताओं के लिए वास्तविक रूप से 400 मशीनें) तो बस ZVOLs पर रिकॉर्ड मैप करें जो प्रत्येक 2TB हैं। एक या एक से अधिक इंडेक्स सर्वर पर, एक जूडी एरे या क्रिटबिट ऐरे या सिर्फ प्लेन बिटमैप में स्टोर करें, अगर आप 26 क्वाड्रिलियन स्थानों में से 1 में रिकॉर्ड जोड़ चुके हैं तो एक मैपिंग। सूचकांक 50 और 100TB के बीच होगा और आप एक दूसरे स्तर का इंडेक्स भी दे सकते हैं यदि कोई निश्चित 64k ब्लॉक के पते पर लिखा गया हो, जो 64 जीबी से कम रैम में फिट होगा और प्रारंभिक जांच का तेज स्तर प्रदान करेगा। यदि एक निश्चित "पड़ोस" खाली था या नहीं।

फिर उस रिकॉर्ड को पढ़ने के लिए आप पहली बार जांचेंगे कि क्या सूचकांक को देखकर कोई रिकॉर्ड है। अगर वहाँ है, तो मशीन पर जाएँ (#) (X) / ZOL # (Y) उस मशीन / रिकॉर्ड स्थान पर # (Z) उस 2TB बूँद के भीतर सरल सूचकांक गणना के आधार पर। सिंगल रिकॉर्ड लुक अप्स बहुत तेज़ होंगे और आप डेटास्टोर के कुछ हिस्सों को अलग-अलग डब में लोड कर सकते हैं (जबकि आप असली काम के लिए डेटास्टोर का उपयोग करते हैं) और प्रदर्शन परीक्षण कर रहे हैं कि वे आपके पूरे डेटाबेस का समर्थन करने में सक्षम हैं या नहीं - बस उस तरह से डेटा स्टोर का उपयोग करें।

ZOL एक ZFS चीज है जिसे अन्य फाइल सिस्टम में एक विरल फ़ाइल के बारे में सोचा जा सकता है, इसलिए इसी तरह की चीजें लागू होंगी। या आप किसी डिस्क पर एक निश्चित बाइट नंबर को अनुक्रमित कर सकते हैं, लेकिन अगर डिस्क अलग-अलग आकार की हो, तो आप डिस्क के प्रति बाइट्स की संख्या का उपयोग उस स्तर पर न करें जो सभी डिस्क के लिए काम करती है - यानी 1.75TB प्रति 2TB डिस्क । या मेटाडेविस बनाएं जो एक निश्चित आकार हैं, आदि।


हाय सारा - यकीन नहीं है कि आप अभी भी इस पर काम कर रहे हैं, लेकिन अगर आपको मदद की ज़रूरत है तो मैं आपके विचार को 100TB मशीन पर आपके लिए प्रोटोटाइप कर सकता हूं और यह भी (एक प्रमुख अमेरिकी डाटासेंटर पर) होस्ट करने और पूर्ण उत्पादन क्लस्टर का प्रबंधन करने के लिए तैयार होगा आवश्यकतानुसार 400-500 मशीनें। BTW, क्या आपने कभी SF में CNET में काम किया था?

1

पागल की तरह अपने DB params ट्यूनिंग के अलावा (मदद करने के लिए mysqltuner का उपयोग करें) की कोशिश करो और अपने चयनों को मानवीय रूप से जितना संभव हो सके रखने के लिए, एक चीज़ जिसकी आप जांच कर सकते हैं, वह है START TRANSACTION / CoMMIT (InnoDB मानकर) जब अपने कुछ सौ रिकॉर्ड्स डालने से बचें पंक्ति को ओवरहेड लॉक करके पंक्ति और अपने सम्मिलित समय को एक विशाल कारक द्वारा नीचे लाएं। मैं MyISAM और InnoDB दोनों के रूप में तालिका भी बनाऊंगा और उस पर परीक्षण चलाऊंगा जो देखने के लिए वास्तव में तेजी से एक बार जब आप कैचिंग को कस लें - यह हमेशा नहीं होता है कि MyISAM पढ़ने के लिए तेज होगा - इसे देखें:

http://www.mysqlperformanceblog.com/2007/01/08/innodb-vs-myisam-vs-falcon-benchmarks-part-1/

आपके परीक्षण के दौरान, समवर्ती थ्रेड्स की संख्या भी ऊपर और नीचे होनी चाहिए जब तक कि आपको यह पता न चले कि वह कितनी अच्छी जगह है जब आप कैश को ट्यूनिंग के लिए समर्पित करने के लिए सर्वर पर खर्च कर सकते हैं; आप पा सकते हैं कि जब आप गणित द्वारा अधिक थ्रेड्स का समर्थन कर सकते हैं, तो डीबी स्वयं वास्तव में खराब प्रदर्शन कर सकता है यदि थ्रेड काउंट बहुत अधिक हो जाता है।

इसके अलावा, यदि आप MyISAM और / या InnoDB फ़ाइल-प्रति-तालिका का उपयोग करते हैं, तो आप एक भिन्न फ़ाइल सिस्टम माउंट बिंदु / var / lib / mysql बनाने के लिए जाँच कर सकते हैं जो एक छोटे से ब्लॉक आकार में ट्यून किया गया था और fs-typeams को ट्यून किया था - अर्थात ext3 / ext4 / resiserfs आप जर्नल के लिए डेटा = राइटबैक का उपयोग कर सकते हैं और I / O गति के लिए फाइल सिस्टम पर एक्सेस समय को अपडेट करने को अक्षम कर सकते हैं।


1
लेनदेन की आवश्यकताओं के कारण myisam प्रश्न से बाहर लगता है।
pQd

0

दूसरे विकल्प के लिए, वास्तव में कितने नंबर दिए जाने की संभावना है?

यदि एक हजार, या 10K, 100K, आदि में केवल एक ही होगा, तो इस्तेमाल की गई (या अप्रयुक्त) संख्याओं के भंडारण की सीमाएँ खरबों प्रविष्टियों को बचा सकती हैं। जैसे: भंडारण ('मुक्त', 0,100000), ('लिया', 100000,100003), ('मुक्त', 100004,584234) - आवश्यकतानुसार दो या तीन पंक्तियों में पंक्तियों को विभाजित करना, और पहले नंबर पर अनुक्रमण करना, एक्स <= {सुई} की खोज यह देखने के लिए कि क्या खोजे गए नंबर वाली रेंज ली गई है, या मुफ्त है।

आपको दोनों स्थितियों की आवश्यकता भी नहीं हो सकती है। बस जो भी स्थिति हो कम से कम संभावना है।

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.