Hasura। SQL सर्वर आर्किटेक्चर के लिए उच्च प्रदर्शन रेखांकन

नमस्कार, हेब्र! मैं आपके लिए लेख "एसक्यूएल इंजन के लिए एक उच्च प्रदर्शन रेखांकन का आर्किटेक्चर" का अनुवाद प्रस्तुत करता हूं।

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

यह आपको एक मौजूदा डेटाबेस के आधार पर एक ग्राफक्यूएल स्कीमा उत्पन्न करने या एक नया बनाने की अनुमति देता है। यह पोस्टग्रेज ट्रिगर्स, डायनेमिक एक्सेस कंट्रोल, जॉइंट्स के ऑटोमैटिक जेनरेशन पर आधारित बॉक्स से ग्राफकलाइन सब्सक्रिप्शन सपोर्ट करता है, एन + 1 रिक्वेस्ट (बैचिंग) की समस्या को हल करता है और भी बहुत कुछ।


आप एक ही क्वेरी में पदानुक्रमित डेटा को पुनः प्राप्त करने के लिए PostgreSQL में विदेशी कुंजी बाधाओं का उपयोग कर सकते हैं। उदाहरण के लिए, आप इस क्वेरी को एल्बम और उनके संबंधित ट्रैक्स को प्राप्त करने के लिए निष्पादित कर सकते हैं (यदि "एल्बम" तालिका की ओर इशारा करते हुए "ट्रैक" तालिका में एक विदेशी कुंजी बनाई गई है)

{ album (where: {year: {_eq: 2018}}) { title tracks { id title } } } 

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

जीवन चक्र का अनुरोध करें

हसुरा को भेजा गया एक अनुरोध निम्नलिखित चरणों से गुजरता है:

1. सत्र प्राप्त करना : अनुरोध गेटवे में आता है, जो कुंजी (यदि कोई हो) की जांच करता है और विभिन्न हेडर जोड़ता है, उदाहरण के लिए, पहचानकर्ता और उपयोगकर्ता की भूमिका।
2. पार्सिंग अनुरोध : हसुरा अनुरोध प्राप्त करता है, उपयोगकर्ता के बारे में जानकारी प्राप्त करने के लिए हेडर को पार्स करता है, अनुरोध बॉडी के आधार पर ग्राफलाइन एएसटी बनाता है।
3. अनुरोधों की वैधता : एक चेक यह देखने के लिए किया जाता है कि क्या अनुरोध शब्दार्थ से सही है, तो उपयोगकर्ता की भूमिका के अनुरूप पहुँच अधिकार लागू होते हैं।
4. क्वेरी निष्पादन : क्वेरी SQL में कनवर्ट की जाती है और पोस्टग्रेज को भेजी जाती है।
5. प्रतिक्रिया पीढ़ी : SQL क्वेरी के परिणाम को संसाधित किया जाता है और क्लाइंट को भेजा जाता है ( यदि आवश्यक हो तो गेटवे gzip का उपयोग कर सकता है )।

लक्ष्यों

आवश्यकताएँ लगभग इस प्रकार हैं:

1. HTTP स्टैक को न्यूनतम ओवरहेड जोड़ना चाहिए और उच्च थ्रूपुट के लिए कई समवर्ती अनुरोधों को संभालने में सक्षम होना चाहिए।
2. ग्राफक्यूएल क्वेरी से फास्ट SQL पीढ़ी।
3. पोस्टग्रेज के लिए उत्पन्न SQL क्वेरी कुशल होनी चाहिए।
4. SQL क्वेरी का परिणाम प्रभावी रूप से Postgres से वापस पारित किया जाना चाहिए।

GraphQL क्वेरी प्रसंस्करण

ग्राफ़िकल क्वेरी के लिए आवश्यक डेटा प्राप्त करने के लिए कई दृष्टिकोण हैं:

परम्परागत रिसोल्वर

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

Postgres द्वारा किए गए अनुरोध होंगे:

 SELECT id,title FROM album WHERE year = 2018; 

यह अनुरोध सभी एल्बमों को हमें लौटा देगा। मान लें कि अनुरोध द्वारा लौटाए गए एल्बमों की संख्या N के बराबर है। फिर प्रत्येक एल्बम के लिए हम निम्नलिखित अनुरोध पर अमल करेंगे:

 SELECT id,title FROM tracks WHERE album_id = <album-id> 

कुल मिलाकर, आपको सभी आवश्यक डेटा प्राप्त करने के लिए एन + 1 क्वेरी मिलती है।

बैचिंग अनुरोध

Dataloader जैसे उपकरण बैचिंग का उपयोग करके N + 1 अनुरोधों की समस्या को हल करने के लिए डिज़ाइन किए गए हैं। एम्बेडेड डेटा के लिए SQL क्वेरी की संख्या अब प्रारंभिक नमूने के आकार पर निर्भर करती है, क्योंकि अब यह GraphQL क्वेरी में नोड्स की संख्या को प्रभावित करता है। इस स्थिति में, आवश्यक डेटा प्राप्त करने के लिए Postgres के 2 अनुरोध आवश्यक हैं:

हमें एल्बम मिलते हैं:

 SELECT id,title FROM album WHERE year = 2018 

हमें पिछले अनुरोध में प्राप्त एल्बमों के ट्रैक मिलते हैं:

 SELECT id, title FROM tracks WHERE album_id IN {the list of album ids} 

कुल में, 2 प्रश्न प्राप्त होते हैं। हमने प्रत्येक व्यक्तिगत एल्बम के लिए पटरियों पर SQL प्रश्नों को निष्पादित करने से परहेज किया, इसके बजाय, हमने एक ही बार में एक क्वेरी में सभी आवश्यक ट्रैक्स प्राप्त करने के लिए WHERE ऑपरेटर का उपयोग किया।

में शामिल

Dataloader को विभिन्न डेटा स्रोतों के साथ काम करने के लिए डिज़ाइन किया गया है और किसी विशेष की क्षमताओं का दोहन करने की अनुमति नहीं देता है। हमारे मामले में, Postgres एकमात्र डेटा स्रोत है और सभी संबंधपरक डेटाबेस की तरह, यह JOIN ऑपरेटर का उपयोग करके एक ही क्वेरी के साथ कई तालिकाओं से डेटा एकत्र करने की क्षमता प्रदान करता है। हम ग्राफ़िकल क्वेरी के लिए आवश्यक सभी तालिकाओं को निर्धारित कर सकते हैं और सभी डेटा प्राप्त करने के लिए JOINs का उपयोग करके एक एकल SQL क्वेरी उत्पन्न कर सकते हैं। यह पता चलता है कि किसी भी ग्राफक्यूएल क्वेरी के लिए आवश्यक डेटा किसी एकल SQL क्वेरी का उपयोग करके प्राप्त किया जा सकता है। ग्राहक को भेजे जाने से पहले यह डेटा परिवर्तित हो जाता है।

ऐसा निवेदन:

 SELECT album.id as album_id, album.title as album_title, track.id as track_id, track.title as track_title FROM album LEFT OUTER JOIN track ON (album.id = track.album_id) WHERE album.year = 2018 

हमें ऐसे डेटा लौटाएगा:

 album_id, album_title, track_id, track_title 1, Album1, 1, track1 1, Album1, 2, track2 2, Album2, NULL, NULL 

फिर इसे JSON में बदल दिया जाएगा और ग्राहक को भेजा जाएगा:

 [ { "title" : "Album1", "tracks": [ {"id" : 1, "title": "track1"}, {"id" : 2, "title": "track2"} ] }, { "title" : "Album2", "tracks" : [] } ] 

प्रतिक्रिया पीढ़ी का अनुकूलन

हमने पाया कि क्वेरी प्रसंस्करण में अधिकांश समय SQL क्वेरी के परिणाम को JSON में परिवर्तित करने के कार्य पर खर्च किया जाता है।

इस फ़ंक्शन को विभिन्न तरीकों से अनुकूलित करने के कई प्रयासों के बाद, हमने इसे पोस्टग्रेज में स्थानांतरित करने का निर्णय लिया। 9.4 पोस्ट ( हसुरा की पहली रिलीज के समय के आसपास जारी ) ने JSON एकत्रीकरण के लिए एक सुविधा जोड़ी, जिसने हमें अपना काम करने में मदद की। इस अनुकूलन के बाद, SQL प्रश्न इस तरह दिखने लगे:

 SELECT json_agg(r.*) FROM ( SELECT album.title as title, json_agg(track.*) as tracks FROM album LEFT OUTER JOIN track ON (album.id = track.album_id) WHERE album.year = 2018 GROUP BY album.id ) r 

इस क्वेरी के परिणाम में एक कॉलम और एक पंक्ति होगी, और यह मान क्लाइंट को बिना किसी और रूपांतरण के भेजा जाएगा। हमारे परीक्षणों के अनुसार, यह दृष्टिकोण हास्केल रूपांतरण फ़ंक्शन की तुलना में लगभग 3-6 गुना तेज है।

तैयार बयान

क्वेरी के नेस्टिंग के स्तर और उपयोग की शर्तों के आधार पर उत्पन्न SQL क्वेरी काफी बड़ी और जटिल हो सकती है। आमतौर पर, वेब एप्लिकेशन में क्वेरीज़ का एक सेट होता है जिसे बार-बार विभिन्न मापदंडों के साथ निष्पादित किया जाता है। उदाहरण के लिए, पिछली क्वेरी को 2018 के बजाय 2017 के लिए निष्पादित करने की आवश्यकता है। तैयार किए गए बयान उन मामलों के लिए सबसे उपयुक्त हैं जहां एक दोहराव वाली जटिल SQL क्वेरी है जिसमें केवल पैरामीटर बदले जाते हैं।

मान लें कि यह क्वेरी पहली बार निष्पादित की गई है:

 { album (where: {year: {_eq: 2018}}) { title tracks { id title } } } 

हम इसे निष्पादित करने के बजाय SQL क्वेरी के लिए एक तैयार स्टेटमेंट बनाते हैं:

 PREPARE prep_1 AS SELECT json_agg(r.*) FROM ( SELECT album.title as title, json_agg(track.*) as tracks FROM album LEFT OUTER JOIN track ON (album.id = track.album_id) WHERE album.year = $1 GROUP BY album. 

जिसके बाद हम तुरंत इसे निष्पादित करते हैं:

 EXECUTE prep_1('2018'); 

जब आपको 2017 के लिए GraphQL क्वेरी को निष्पादित करने की आवश्यकता होती है, तो हम बस एक ही तैयार किए गए स्टेटमेंट को एक अलग तर्क के साथ कहते हैं:

 EXECUTE prep_1('2017'); 

यह ग्राफ़िकल क्वेरी की जटिलता के आधार पर गति में लगभग 10-20% की वृद्धि देता है।

हास्केल

हास्केल कई कारणों से अच्छी तरह से काम करता है:

• उत्कृष्ट प्रदर्शन के साथ संकलित भाषा ( यहां अधिक विवरण )।
• बहुत कुशल HTTP स्टैक ( ताना , ताना की वास्तुकला )।
• हमारा पिछला भाषा अनुभव।

अंत में

ऊपर उल्लिखित सभी अनुकूलन परिणाम काफी गंभीर प्रदर्शन लाभ में हैं:



वास्तव में, PostgreSQL के लिए सीधे कॉल के साथ तुलना में कम मेमोरी की खपत और महत्वहीन देरी, ज्यादातर मामलों में ओआरएम को ग्राफकलाइन एपीआई कॉल के साथ बदलने की अनुमति देती है।

मानक:

टेस्ट स्टैंड:

1. 8GB रैम और i7 के साथ लैपटॉप
2. एक ही कंप्यूटर पर चलने वाले पोस्टग्रेट्स
3. wrk , एक तुलना उपकरण के रूप में इस्तेमाल किया गया था और विभिन्न प्रकार के अनुरोधों के लिए हमने "अधिकतम" आरपीएस की कोशिश की
4. हसुरा ग्रेफ्लिक्स इंजन का एक उदाहरण
5. कनेक्शन पूल का आकार: 50
6. डेटासट : चिनूक

अनुरोध 1: track_media_some

 query tracks_media_some { tracks (where: {composer: {_eq: "Kurt Cobain"}}){ id name album { id title } media_type { name } }} 

• प्रति सेकंड अनुरोध: 1375 req / s
• विलंब: 17.5 मी
• CPU: ~ ३०%
• RAM: ~ ३० एमबी (हसुरा) + ९ ० एमबी (पोस्टग्रेज)

अनुरोध 2: track_media_all

 query tracks_media_all { tracks { id name media_type { name } }} 

• अनुरोध प्रति सेकंड: 410 req / s
• विलंब: 59 मी
• CPU: ~ 100%
• RAM: ~ 30MB (हसुरा) + 130MB (पोस्टग्रेज)

निवेदन 3: album_tracks_genre_some

 query albums_tracks_genre_some { albums (where: {artist_id: {_eq: 127}}) { id title tracks { id name genre { name } } }} 

• प्रति सेकंड अनुरोध: 1029 req / s
• विलंब: 24ms
• CPU: ~ ३०%
• RAM: ~ ३० एमबी (हसुरा) + ९ ० एमबी (पोस्टग्रेज)

निवेदन ४: एल्बम_ट्रैक्स_जेनरे_ल

 query albums_tracks_genre_all { albums { id title tracks { id name genre { name } } } 

• प्रति सेकंड अनुरोध: 328 req / s
• विलंब: 73 मी
• CPU: 100%
• RAM: ~ 30MB (हसुरा) + 130MB (पोस्टग्रेज)