PostgreSQL के लिए अनुकूलन रेल अनुप्रयोग की सेवा

स्वास्थ्य सेवा उद्योग के लिए मैसेजिंग प्लेटफॉर्म बनाने वाली कंपनी के वरिष्ठ सॉफ्टवेयर इंजीनियर के रूप में, मैं हमारे आवेदन के प्रदर्शन के लिए अन्य कर्तव्यों सहित जिम्मेदार हूं। हम व्यावसायिक तर्क और API के लिए रूबी एप्लिकेशन पर रूबी का उपयोग करके सुंदर मानक वेब-सेवा विकसित करते हैं, उपयोगकर्ताओं के लिए सिंगल पेज एप्लिकेशन का सामना करने के लिए प्रतिक्रिया + Redux, डेटाबेस के रूप में हम PostgreSQL का उपयोग करते हैं। समान स्टैक में प्रदर्शन समस्याओं के सामान्य कारण डेटाबेस के लिए भारी प्रश्न हैं और मैं कहानी को बताना चाहूंगा कि हमने प्रदर्शन में सुधार के लिए गैर-मानक लेकिन काफी सरल अनुकूलन लागू किए।

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

मानक समाधान

लेख की शुरुआत में मैंने "गैर मानक अनुकूलन" वाक्यांश का उल्लेख किया क्योंकि सभी कम-फांसी वाले फल पहले से ही उठाए गए थे:

• हमने सभी एन + 1 प्रश्नों को हटा दिया। रूबी रत्न बुलेट प्राथमिक उपकरण था
• डेटाबेस पर सभी आवश्यक सूचक जोड़े गए थे, सभी आवश्यक नहीं हटाए गए थे, धन्यवाद pg_stat_statements के लिए
• कई जोड़ों के साथ कुछ प्रश्न बेहतर दक्षता के लिए फिर से लिखे गए थे
• हमने सजावट प्रश्नों से पृष्ठांकित संग्रह लाने के लिए प्रश्नों को अलग किया। उदाहरण के लिए, शुरू में हमने तालिकाओं में शामिल होकर प्रति संवाद संदेशों का काउंटर जोड़ा था, लेकिन परिणाम बढ़ाने के लिए इसे एक अतिरिक्त क्वेरी के साथ बदल दिया गया था। अगली क्वेरी इंडेक्स ओनली स्कैन और वास्तव में सस्ती है:

SELECT COUNT(1), dialog_id FROM messages WHERE dialog_id IN (1, 2, 3, 4) GROUP BY dialog_id; 

• कुछ कैश जोड़े। वास्तव में, यह अच्छी तरह से काम नहीं करता था क्योंकि एक संदेश अनुप्रयोग के रूप में हमारे पास कई अपडेट हैं

इन सभी चालों ने एक-दो महीने तक शानदार प्रदर्शन किया, जब तक कि हमें फिर से वही प्रदर्शन समस्या नहीं हुई - अधिक उपयोगकर्ता, अधिक भार। हम कुछ और ढूंढ रहे थे।

उन्नत समाधान

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

कस्टम समाधान

डेटा संपीड़ित करें

हमने मुख्य लक्षण - डिस्क IO पर ध्यान केंद्रित करने का निर्णय लिया। जितना कम डेटा हम स्टोर करते हैं, उतनी ही कम IO क्षमता हमें चाहिए, यह प्राथमिक विचार था। हमने डेटा को संपीड़ित करने के अवसरों की तलाश शुरू कर दी और पहले उम्मीदवार user_type द्वारा polymorphic संघों के साथ प्रदान किए गए user_type जैसे कॉलम थे। आवेदन में हम मॉड्यूल का उपयोग करते हैं, जो हमें Module::SubModule::ModelName जैसे Module::SubModule::ModelName लिए लंबे समय तक Module::SubModule::ModelName ले जाता है। हमने क्या किया - इन सभी स्तंभों के प्रकार को varchar से ENUM में बदल दिया। रेल प्रवास इस तरह दिखता है:

 class AddUserEnumType < ActiveRecord::Migration[5.2] disable_ddl_transaction! def up ActiveRecord::Base.connection.execute <<~SQL CREATE TYPE user_type_enum AS ENUM ( 'Module::Submodule::UserModel1', 'Module::Submodule::UserModel2', 'Module::Submodule::UserModel3' ); SQL add_column :messages, :sender_type_temp, :user_type_enum Message .in_batches(of: 10000) .update_all('sender_type_temp = sender_type::user_type_enum') safety_assured do rename_column :messages, :sender_type, :sender_type_old rename_column :messages, :sender_type_temp, :sender_type end end end 

उन लोगों के लिए इस प्रवास के बारे में कुछ नोट्स जो रेल से परिचित नहीं हैं:

• disable_ddl_transaction! लेन-देन को अक्षम करता है। यह करना बहुत जोखिम भरा है लेकिन हम लंबे लेनदेन से बचना चाहते थे। कृपया सुनिश्चित करें कि आप इसके लिए आवश्यकता के बिना माइग्रेशन पर लेनदेन को अक्षम नहीं करते हैं।
• पहले कदम पर हम PostgreSQL पर एक नया ENUM डेटा प्रकार बनाते हैं। ENUM पर सबसे अच्छी सुविधा एक छोटा आकार है, जो वास्तव में varchar की तुलना में छोटा है। ENUM को नए मान जोड़ने में कुछ कठिनाइयाँ हैं, लेकिन आमतौर पर हम अक्सर नए उपयोगकर्ता प्रकार नहीं जोड़ते हैं।
• user_type_enum के साथ एक नया स्तंभ प्रेषक_type_temp जोड़ें
• तालिका संदेशों पर लंबे लॉक से बचने के लिए नए कॉलम in_batches में मान भरें
• अंतिम चरण नए के साथ पुराने कॉलम को स्वैप करता है। यह सबसे खतरनाक कदम है क्योंकि यदि स्तंभ प्रेषक_टाइप प्रेषक_type_old में बदल गया है, लेकिन प्रेषक_type_temp प्रेषक_type बनने में विफल रहा है तो हमें बहुत सी परेशानियाँ मिलेंगी।
• safety_assured रत्न मजबूत_ प्रवासन से आता है जो माइग्रेशन लिखने पर गलतियों से बचने में मदद करता है। नाम बदलना कॉलम सुरक्षित संचालन नहीं है, इसलिए हमें यह पुष्टि करनी थी कि हम समझते हैं कि हम क्या कर रहे थे। वास्तव में, वहाँ एक सुरक्षित लेकिन लंबे समय तक तैनाती सहित रास्ता है।

यह कहने की आवश्यकता नहीं है कि हम उचित परीक्षण के साथ सबसे कम गतिविधि अवधि के दौरान सभी समान पलायन चलाते हैं।

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

अपने सेवा प्रदाता पर विश्वास न करें

एक और बात लेख में पाई गई कि कैसे एक एकल PostgreSQL कॉन्फिगरेशन में 50x तक सुचारू क्वेरी प्रदर्शन में सुधार हुआ है - हमारे PostgreSQL प्रदाता रैम, डिस्क और सीपीयू के अनुरोधित मात्रा के आधार पर सर्वर के लिए एक स्वचालित कॉन्फ़िगरेशन बनाता है, लेकिन जिस भी कारण से उन्होंने पैरामीटर random_03cost को छोड़ दिया डिफ़ॉल्ट मान जो HDD के लिए 4 अनुकूलित है। वे हमसे SSD पर डेटाबेस चलाने के लिए शुल्क लेते हैं लेकिन PostgreSQL को ठीक से कॉन्फ़िगर नहीं करते हैं। उनसे संपर्क करने के बाद हमें बेहतर निष्पादन योजना मिली:

 EXPLAIN ANALYSE SELECT COUNT(*) AS count_dialog_id, dialog_id as dialog_id FROM messages WHERE sender_type = 'Module::Submodule::UserModel1' AND sender_id = 1234 GROUP BY dialog_id; db=# SET random_page_cost = 4; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- HashAggregate (cost=76405.45..76411.92 rows=647 width=12) (actual time=2428.412..2428.420 rows=12 loops=1) Group Key: dialog_id -> Bitmap Heap Scan on messages (cost=605.90..76287.72 rows=23545 width=4) (actual time=82.442..2376.033 rows=79466 loops=1) Recheck Cond: ((sender_id = 1234) AND (sender_type = 'Module::Submodule::UserModel1'::user_type_enum)) Heap Blocks: exact=23672 -> Bitmap Index Scan on index_messages_on_sender_id_and_sender_type_and_message_type (cost=0.00..600.01 rows=23545 width=0) (actual time=76.067..76.068 rows=79466 loops=1) Index Cond: ((sender_id = 1234) AND (sender_type = 'Module::Submodule::UserModel1'::user_type_enum)) Planning time: 3.849 ms Execution time: 2428.691 ms (9 rows) db=# SET random_page_cost = 1; QUERY PLAN ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ HashAggregate (cost=21359.54..21366.01 rows=647 width=12) (actual time=97.905..97.913 rows=12 loops=1) Group Key: dialog_id -> Index Scan using index_messages_on_sender_id_and_sender_type_and_message_type on messages (cost=0.56..21241.81 rows=23545 width=4) (actual time=0.058..60.444 rows=79466 loops=1) Index Cond: ((sender_id = 1234) AND (sender_type = 'Module::Submodule::UserModel1'::user_type_enum)) Planning time: 0.277 ms Execution time: 98.070 ms (6 rows) 

डेटा दूर ले जाएं

हम एक विशाल तालिका को दूसरे डेटाबेस में ले गए। हमें कानून द्वारा प्रणाली में हर बदलाव के ऑडिट को रखना होगा और यह आवश्यकता रत्न पेपरट्रेल के साथ लागू की जाएगी । यह लाइब्रेरी उत्पादन डेटाबेस में एक तालिका बनाता है जहां निगरानी के तहत वस्तुओं के सभी परिवर्तन सहेजे जाते हैं। हम अपने रेल एप्लिकेशन के लिए एक और डेटाबेस उदाहरण को एकीकृत करने के लिए लाइब्रेरी मल्टीवर्स का उपयोग करते हैं। वैसे - यह रेल्स 6. की एक मानक विशेषता होने जा रही है। कुछ विन्यास हैं:

फ़ाइल config/database.yml में कनेक्शन का वर्णन config/database.yml

 external_default: &external_default url: "<%= ENV['AUDIT_DATABASE_URL'] %>" external_development: <<: *external_default 

अन्य डेटाबेस से ActiveRecord मॉडल के लिए बेस क्लास:

 class ExternalRecord < ActiveRecord::Base self.abstract_class = true establish_connection :"external_#{Rails.env}" end 

मॉडल जो पेपरट्रेल संस्करणों को लागू करता है:

 class ExternalVersion < ExternalRecord include PaperTrail::VersionConcern end 

ऑडिट के तहत मॉडल में केस का उपयोग करें:

 class Message < ActiveRecord::Base has_paper_trail class_name: "ExternalVersion" end 

सारांश

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

पुनश्च: अत्यधिक psql के लिए एक महान DBA ऐड-ऑन की सलाह देते हैं।