चूंकि सक्रिय इंस्टाग्राम उपयोगकर्ताओं की संख्या लगातार बढ़ने लगी थी, इसलिए उपयोगकर्ताओं द्वारा बनाए गए अधिकांश डेटा के लिए Postgres हमारा ठोस आधार और अपरिवर्तित डेटा वेयरहाउस बना हुआ है। और यद्यपि एक साल से भी कम समय पहले हमने लिखा था कि हम इंस्टाग्राम पर 90 सेकंड प्रति सेकंड में बड़ी मात्रा में डेटा कैसे स्टोर करते हैं, अब हम प्रति सेकंड 10,000 से अधिक लाइक्स प्रोसेस करते हैं - और हमारी मुख्य स्टोरेज तकनीक नहीं बदली है।
पिछले ढाई वर्षों में, हमने कुछ चीजों को समझा और पोस्टग्रेज को स्केल करने के लिए कुछ उपकरण उठाए और हम उन्हें साझा करना चाहते हैं - ऐसा कुछ जिसे हम इंस्टाग्राम शुरू करते समय जानना चाहेंगे। उनमें से कुछ Postgres के लिए विशिष्ट हैं, अन्य को अन्य डेटाबेस में भी प्रस्तुत किया गया है। यह जानने के लिए कि हम क्षैतिज रूप से पोस्टग्रेज कैसे करते हैं,
इंस्टाग्राम पर हमारी पोस्ट
शेयरिंग और आईडी देखें1. आंशिक सूचकांक
यदि आप अक्सर अपने प्रश्नों में एक विशिष्ट विशेषता के लिए फ़िल्टर का उपयोग करते हैं, और यह विशेषता आपके डेटाबेस की लाइनों के एक छोटे हिस्से में प्रस्तुत की जाती है, तो आंशिक अनुक्रमणिका आपकी गंभीरता से मदद कर सकती है।
उदाहरण के लिए, जब इंस्टाग्राम पर टैग की खोज की जाती है, तो हम उन टैगों को उठाने की कोशिश करते हैं जिनका उपयोग कई फ़ोटो खोजने के लिए किया जा सकता है। यद्यपि हम अपने आवेदन में अधिक पक्षपाती खोजों के लिए ElasticSearch जैसी तकनीकों का उपयोग करते हैं, लेकिन यह एकमात्र मामला है जब डेटाबेस अपने आप में एक अच्छा काम करता है। आइए देखें कि टैग के लिए खोज करते समय पोस्टग्रैज कैसे काम करते हैं, उन्हें तस्वीरों की संख्या से क्रमबद्ध करें:
EXPLAIN ANALYZE SELECT id from tags WHERE name LIKE 'snow%' ORDER BY media_count DESC LIMIT 10; QUERY PLAN Limit (cost=1780.73..1780.75 rows=10 width=32) (actual time=215.211..215.228 rows=10 loops=1) -> Sort (cost=1780.73..1819.36 rows=15455 width=32) (actual time=215.209..215.215 rows=10 loops=1) Sort Key: media_count Sort Method: top-N heapsort Memory: 25kB -> Index Scan using tags_search on tags_tag (cost=0.00..1446.75 rows=15455 width=32) (actual time=0.020..162.708 rows=64572 loops=1) Index Cond: (((name)::text ~>=~ 'snow'::text) AND ((name)::text ~<~ 'snox'::text)) Filter: ((name)::text ~~ 'snow%'::text) Total runtime: 215.275 ms (8 rows)
सूचना पोस्टग्रेज को सही परिणाम प्राप्त करने के लिए 15 हजार लाइनों को क्रमबद्ध करना होगा। और चूंकि टैग (उदाहरण के लिए) एक लंबी पूंछ वाला टेम्पलेट है, हम इसके बजाय पहले टैग दिखाने की कोशिश कर सकते हैं जिसके लिए 100 या अधिक फोटो हैं, इसलिए:
CREATE INDEX CONCURRENTLY on tags (name text_pattern_ops) WHERE media_count >= 100
और हमारी क्वेरी योजना अब इस तरह दिखती है:
EXPLAIN ANALYZE SELECT * from tags WHERE name LIKE 'snow%' AND media_count >= 100 ORDER BY media_count DESC LIMIT 10; QUERY PLAN Limit (cost=224.73..224.75 rows=10 width=32) (actual time=3.088..3.105 rows=10 loops=1) -> Sort (cost=224.73..225.15 rows=169 width=32) (actual time=3.086..3.090 rows=10 loops=1) Sort Key: media_count Sort Method: top-N heapsort Memory: 25kB -> Index Scan using tags_tag_name_idx on tags_tag (cost=0.00..221.07 rows=169 width=32) (actual time=0.021..2.360 rows=924 loops=1) Index Cond: (((name)::text ~>=~ 'snow'::text) AND ((name)::text ~<~ 'snox'::text)) Filter: ((name)::text ~~ 'snow%'::text) Total runtime: 3.137 ms (8 rows)
ध्यान दें कि Postgres को अब केवल 169 लाइनों को बायपास करना चाहिए, जो कि बहुत तेज है। पोस्टग्रैज का क्वेरी प्लानर बाधाओं की गणना करने में भी अच्छा है - यदि आप बाद में निर्णय लेते हैं कि आप केवल टैग प्राप्त करना चाहते हैं जिसके लिए कम से कम 500 तस्वीरें हैं, अर्थात्। सूचकांक के सबसेट से - यह अभी भी सही आंशिक सूचकांक का उपयोग करेगा।
2. कार्यात्मक सूचकांक
हमारी कुछ तालिकाओं के लिए, हमें स्ट्रिंग्स को अनुक्रमित करने की आवश्यकता है (उदाहरण के लिए, 64-वर्ण बेस 64 टोकन), बल्कि लंबे समय तक, उन पर एक इंडेक्स बनाने के लिए - इससे बहुत सारी जानकारी का दोहराव होगा। इस मामले में, पोस्टग्रैड्स कार्यात्मक सूचकांक बहुत उपयोगी हो सकते हैं:
CREATE INDEX CONCURRENTLY on tokens (substr(token, 0, 8))
इस प्रकार, अनुक्रमणिका का उपयोग करते हुए, उपसर्ग द्वारा रिकॉर्ड्स के सेट को ढूंढता है, और फिर उन्हें आपकी जरूरत के हिसाब से खोजने के लिए फ़िल्टर करता है। यदि हम पूरी पंक्ति के साथ एक सूचकांक कर रहे थे तो सूचकांक 10 गुना कम जगह लेता है।
3. संपीड़न के लिए pg_reorg
कुछ समय बाद, पोस्टग्रैज टेबल डिस्क पर खंडित हो सकते हैं (क्योंकि प्रतिस्पर्धी एमवीसी पोस्टग्रेज मॉडल, उदाहरण के लिए)। इसके अलावा, सबसे अधिक बार, पंक्तियों को सम्मिलित करना उस क्रम में नहीं है जिसमें आप उन्हें प्राप्त करना चाहते हैं। उदाहरण के लिए, यदि आप अक्सर एक उपयोगकर्ता द्वारा बनाई गई सभी पसंदों का अनुरोध करते हैं, तो यह अच्छा होगा यदि डिस्क खोज को कम करने के लिए डिस्क पर इन पसंदों को लगातार दर्ज किया गया हो।
इसका समाधान हमारे लिए pg_reorg उपयोगिता का उपयोग करना है, जो तालिका को अनुकूलित करने की प्रक्रिया में इन चरणों को पूरा करती है:
- एक विशेष टेबल लॉक हो जाता है
- परिवर्तनों को संचित करने के लिए एक अस्थायी तालिका बनाता है, और मूल तालिका में एक ट्रिगर जोड़ता है, जो इस अस्थायी तालिका में किसी भी परिवर्तन की प्रतिकृति करता है
- डिस्क से अनुक्रमित ... का चयन करके, जो बनाता है का चयन करें ... ORDER BY, का उपयोग कर बनाता है
- चयनात्मक FROM चलाने के बाद हुई अस्थायी तालिका से परिवर्तनों को सिंक्रनाइज़ करता है
- एक नई तालिका पर स्विच करता है
लॉक आदि प्राप्त करने में कुछ विशेषताएं हैं, लेकिन यह सामान्य दृष्टिकोण का विवरण है। हमने इस उपकरण का परीक्षण किया और इसे उत्पादन में लॉन्च करने से पहले कई परीक्षण किए, और हमने बिना किसी समस्या के सैकड़ों मशीनों पर कई पुनर्गठन किए।
4. वॉकिंग के लिए वॉक-ई और बैकअप वॉक
हम
वाल-ई के विकास के लिए उपयोग और योगदान करते हैं, वाल (राइट-अहेड लॉग) की निरंतर संग्रह के लिए हरोकू प्लेटफॉर्म टूलकिट फ़ाइलों को पोस्टग्रेज करता है। वाल-ई के उपयोग ने बैकअप की हमारी प्रक्रिया को बहुत सरल कर दिया और एक नया डेटाबेस प्रतिकृति लॉन्च किया।
संक्षेप में, वाल-ई एक ऐसा प्रोग्राम है जो आपके पीजी सर्वर द्वारा आर्काइव_कमांड पोस्टग्रेज का उपयोग करके अमेजन एस 3 पर उत्पन्न सभी वाल फाइलों को संग्रहीत करता है। डेटाबेस के बैकअप को इस बैकअप से शुरू करके, किसी भी बिंदु पर डेटाबेस को पुनर्स्थापित करने के लिए, इन वाल फाइलों का उपयोग किया जा सकता है। नियमित बैकअप और वाल फाइलों का संयोजन हमें एक नया रीड-ओनली प्रतिकृति या फेलओवर स्लेव (मुख्य डेटाबेस की विफलता के मामले में एक प्रतिकृति) को जल्दी से लॉन्च करने में सक्षम बनाता है।
हमने फ़ाइल संग्रह के दौरान आवर्ती दुर्घटनाओं की निगरानी के लिए एक सरल स्क्रिप्ट आवरण बनाया, और यह
GitHub पर उपलब्ध है ।
5. Psycopg2 में ऑटोकॉमिट मोड और एसिंक्रोनस मोड
कुछ समय बाद, हमने Psgropg2 की अधिक उन्नत सुविधाओं का उपयोग करना शुरू किया, पोस्टग्रेज के लिए पायथन ड्राइवर।
पहला है ऑटोकॉमिट मोड। इस मोड में, psycopg2 को किसी भी प्रश्न के लिए BEGIN / COMMIT की आवश्यकता नहीं होती है, इसके बजाय, प्रत्येक क्वेरी को एक अलग लेनदेन में लॉन्च किया जाता है। यह डेटाबेस से क्वेरी को क्वेरी करने के लिए विशेष रूप से उपयोगी है जिसके लिए लेनदेन का उपयोग करने का कोई मतलब नहीं है। मोड चालू करना बहुत सरल है:
connection.autocommit = True
इसने हमारे सर्वर और डेटाबेस के बीच संचार को काफी कम कर दिया, और डेटाबेस मशीनों पर सीपीयू की लागत को भी कम कर दिया। बाद में, हमने कनेक्शन वितरित करने के लिए PGBouncer का उपयोग किया, जिसने कनेक्शन को तेजी से पूल में लौटने की अनुमति दी।
यह कैसे Django में
यहाँ काम करता है पर अधिक जानकारी।
Psycopg2 में एक अन्य उपयोगी विशेषता रूटीन कॉल करने के लिए
Wait_callback रजिस्टर करने की क्षमता है। इसका उपयोग करने से आप एक समय में कई कनेक्शनों पर समानांतर प्रश्न बना सकते हैं, जो उन प्रश्नों के लिए उपयोगी है जो कई नोड्स को प्रभावित करते हैं - सॉकेट उठता है और प्रसंस्करण के डेटा के प्रकट होने पर सूचित करता है (हम जागरण को संसाधित करने के लिए पायथन चयन मॉड्यूल का उपयोग करते हैं)। यह सहकारी मल्टी-थ्रेडेड लाइब्रेरियों जैसे कि इवेंटलेट या जीवेंट के साथ भी अच्छा काम करता है। एक उदाहरण कार्यान्वयन
मानस है ।
कुल मिलाकर, हम पोस्टग्रेज के प्रदर्शन और विश्वसनीयता से बहुत संतुष्ट हैं। यदि आप सबसे बड़े पोस्टग्रेज बिल्ड में से एक पर काम करने में रुचि रखते हैं, तो बुनियादी ढांचे के हैकर्स की एक छोटी टीम के साथ, हम infrajobs <dog> instagram.com पर संपर्क में हैं
अनुवादक से:
मैं पीएम में अनुवाद त्रुटियों और वर्तनी के लिए पूछता हूं। और यदि आप सेंट पीटर्सबर्ग में स्थित एक छोटी लेकिन बहुत गर्व टीम में मोबाइल एप्लिकेशन पर काम करने में रुचि रखते हैं - हम भी प्रस्तावों पर संपर्क करते हैं और विचार करते हैं!