सवाल MySQL: 1 9 2 ट्रिलियन रिकॉर्ड्स के साथ काम करना ... (हाँ, 1 9 2 ट्रिलियन)


सवाल यहाँ है ...

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

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

टेबल यहाँ है ...

    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 की तुलना में अधिक बार किया जाएगा। हालांकि, कभी-कभी मैं एक समय में कुछ सौ रिकॉर्ड जोड़ना चाहता हूं।
  • लोड-वार, घंटों के लिए कुछ भी नहीं होगा, फिर शायद कुछ हज़ार प्रश्न सभी एक साथ हो सकते हैं।
  • ऐसा मत सोचो कि मैं और अधिक सामान्य कर सकता हूं (संयोजन में पी मानों की आवश्यकता है)
  • पूरी तरह से डेटाबेस बहुत संबंधपरक है।
  • यह अब तक का सबसे बड़ा टेबल होगा (अगला सबसे बड़ा 900k है)

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

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

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

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

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

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

[संपादित करें] बस कुछ परीक्षण किए गए समाचारों की खबर मिली है - इस सेटअप के साथ 100 मिलियन पंक्तियां 0.0004 सेकेंड में क्वेरी लौटाती हैं [/ संपादित करें]


39
2017-08-08 14:15


मूल


इसके लिए MySQL का उपयोग करने पर आप कैसे सेट हैं? क्या आप किसी भिन्न डीबीएमएस पर स्विच करने के लिए आश्वस्त हो सकते हैं यदि कोई ऐसा करने के लिए ठोस तर्क प्रदान करता है? - kaerast
10 ^ 12 में या 10 ^ 18 में ट्रिलियन? - andol
1 9 2 ट्रिलियन रिकॉर्ड्स में आपके पास एक बजट होना चाहिए जो आपको कुछ चर्चा मंचों पर नहीं, MySQL Committers को प्रश्न पूछने की अनुमति देता है। - Remus Rusanu
डेटाबेस के साथ यह बड़ा (और स्पष्ट रूप से एक सभ्य बजट) क्यों नहीं जाता है और ओरेकल या एसक्यूएल सेरर समाधान जो बड़े डीबी को आसानी से संभालने के लिए साबित हुआ है? - Jim B
जब आप इसे कार्यान्वित करते हैं तो हमें अपडेट रखना सुनिश्चित करें। मुझे निश्चित रूप से दिलचस्पी होगी। आप इसे लिखना भी चाह सकते हैं highscalability.com - Tom O'Connor


जवाब:


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

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

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

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

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

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

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

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

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


30
2017-08-08 16:05



@ConcernedOfTunbridgeW - वे हमेशा इस तरह से जा सकते हैं: blog.backblaze.com/2009/09/01/... - SAN से कहीं अधिक मजेदार, केवल ~ 120-130 4 यू बक्से की जरूरत है ... लेकिन मुझे यकीन नहीं है कि 'व्यवसाय' खुश होगा .... - pQd
अनिवार्य रूप से एक बजट पर एक सन थम्पर और साझा-कुछ भी सिस्टम में नोड के लिए वास्तव में एक विकल्प का एक उदाहरण। मुझे यकीन है कि मैंने इसके लिए अन्य विकल्प भी देखे हैं, लेकिन मैं कहां नहीं सोच सकता। प्रश्न इतना हार्डवेयर नहीं है लेकिन डेटाबेस प्लेटफॉर्म क्या है। - ConcernedOfTunbridgeWells
हालांकि, उत्सुक पर्यवेक्षकों ने ध्यान दिया होगा कि इस तरह के किसी भी प्रकार का प्रत्यक्ष अनुलग्नक आधारित बॉक्स SAN पर आधारित किसी भी चीज़ की तुलना में टीबी प्रति बहुत सस्ता है, जो किसी साझा-कुछ प्लेटफ़ॉर्म पर काम करने के लिए डिज़ाइन किए गए किसी चीज़ के पक्ष में कम से कम एक महत्वपूर्ण तर्क नहीं है । - ConcernedOfTunbridgeWells
@ConcernedOfTunbridgeWells और आप उन सभी प्रश्नों / रखरखाव और कई अन्य समानांतर में अन्यथा [अन्यथा भूख लगी] बक्से चला सकते हैं। - pQd
@ConcernedOfTunbridgeWells - आपको सवालों के जवाब देने के लिए ... यदि संभव हो, तो मुझे एक सेकंड के नीचे लौटने के लिए लगभग 500 प्रश्नों की आवश्यकता है। मैं दिन में केवल कुछ सौ बार ऐसा करूँगा। जब कोई क्वेरी चलती है, तो पूर्ण तालिका को स्कैन करने की आवश्यकता होती है। इसके अलावा INSERT की चयन की तुलना में कम प्राथमिकता है, इसलिए इसे तुरंत कहीं भी नहीं होना चाहिए। मैं डेटाबेस में आने के लिए "नए" डेटा के लिए कुछ घंटे इंतजार कर सकता हूं। - Sarah


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

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

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

1 9 2 ट्रिलियन पंक्ति 40 बी प्रत्येक हमें लगभग 7 पीबी देता है

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

जवाब देने के लिए प्रश्न:

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

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


16
2017-08-08 14:42



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


कॉल Percona। "जाओ" पास न करें। $ 200 इकट्ठा मत करो।


8
2017-09-22 06:28





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


2
2017-08-11 11:35



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


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

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

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

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

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


2
2017-08-18 17:40



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


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

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

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

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


1
2017-08-08 14:47



अच्छी चीजें - इसके लिए धन्यवाद :) - Sarah
लेनदेन आवश्यकताओं के कारण मायिसम सवाल से बाहर है। - pQd


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

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

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


0
2017-12-27 20:34