PostgreSQL क्वेरीचे मोठ्या प्रमाणात ऑप्टिमायझेशन. किरिल बोरोविकोव्ह (टेन्सर)

अहवालात परवानगी देणारे काही दृष्टिकोन सादर केले आहेत दररोज लाखो क्वेरी असतात तेव्हा SQL क्वेरीच्या कार्यप्रदर्शनाचे निरीक्षण करा, आणि तेथे शेकडो निरीक्षण केलेले PostgreSQL सर्व्हर आहेत.

कोणते तांत्रिक उपाय आम्हाला अशा माहितीच्या मोठ्या प्रमाणावर कार्यक्षमतेने प्रक्रिया करण्यास अनुमती देतात आणि यामुळे सामान्य विकसकाचे जीवन कसे सोपे होते?

कोणाला स्वारस्य आहे? विशिष्ट समस्या आणि विविध ऑप्टिमायझेशन तंत्रांचे विश्लेषण SQL क्वेरी आणि PostgreSQL मध्ये ठराविक DBA समस्या सोडवणे - तुम्ही देखील करू शकता लेखांची मालिका वाचा या विषयावर.


माझे नाव किरिल बोरोविकोव्ह आहे, मी प्रतिनिधित्व करतो टेन्सर कंपनी. विशेषतः, मी आमच्या कंपनीतील डेटाबेससह काम करण्यात माहिर आहे.

आज मी तुम्हाला सांगेन की आम्ही क्वेरी कशी ऑप्टिमाइझ करतो, जेव्हा तुम्हाला एकाच क्वेरीचे कार्यप्रदर्शन "वेगळे" करण्याची आवश्यकता नसते, परंतु समस्या एकत्रितपणे सोडवा. जेव्हा लाखो विनंत्या असतात आणि तुम्हाला काही शोधण्याची आवश्यकता असते समाधानाकडे जाण्याचा दृष्टीकोन ही मोठी समस्या.

सर्वसाधारणपणे, आमच्या दशलक्ष क्लायंटसाठी टेन्सर आहे VLSI हा आमचा अर्ज आहे: कॉर्पोरेट सोशल नेटवर्क, व्हिडिओ कम्युनिकेशनसाठी उपाय, अंतर्गत आणि बाह्य दस्तऐवज प्रवाहासाठी, अकाउंटिंग आणि वेअरहाऊससाठी अकाउंटिंग सिस्टम,... म्हणजेच, एकात्मिक व्यवसाय व्यवस्थापनासाठी असे "मेगा-कम्बाइन", ज्यामध्ये 100 पेक्षा जास्त भिन्न आहेत. अंतर्गत प्रकल्प.

ते सर्व सामान्यपणे कार्य करतात आणि विकसित होतात याची खात्री करण्यासाठी, आमच्याकडे देशभरात 10 विकास केंद्रे आहेत, त्यापैकी अधिक आहेत 1000 विकसक.

आम्‍ही 2008 पासून PostgreSQL सोबत काम करत आहोत आणि आम्ही काय प्रक्रिया करतो - क्लायंट डेटा, सांख्यिकीय, विश्लेषणात्मक, बाह्य माहिती प्रणालींकडील डेटा - मोठ्या प्रमाणात जमा केले आहे. 400TB पेक्षा जास्त. एकट्या उत्पादनामध्ये सुमारे 250 सर्व्हर आहेत आणि एकूण सुमारे 1000 डेटाबेस सर्व्हर आहेत ज्यांचे आम्ही निरीक्षण करतो.

SQL ही घोषणात्मक भाषा आहे. आपण काहीतरी "कसे" कार्य करावे याचे वर्णन करत नाही, परंतु आपण "काय" प्राप्त करू इच्छिता. DBMS ला जॉइन कसे करायचे - तुमचे टेबल कसे जोडायचे, कोणती अटी लादायची, काय निर्देशांकातून जाईल, काय नाही...

काही डीबीएमएस इशारे स्वीकारतात: “नाही, या दोन टेबल्सला अशा आणि अशा रांगेत कनेक्ट करा,” परंतु PostgreSQL हे करू शकत नाही. अग्रगण्य विकासकांची ही जाणीवपूर्वक स्थिती आहे: "आम्ही विकासकांना काही प्रकारचे संकेत वापरण्याची परवानगी देण्यापेक्षा क्वेरी ऑप्टिमायझर पूर्ण करू इच्छितो."

परंतु, PostgreSQL "बाहेरील" स्वतःवर नियंत्रण ठेवू देत नाही हे असूनही, ते उत्तम प्रकारे परवानगी देते त्याच्या आत काय चालले आहे ते पहाजेव्हा तुम्ही तुमची क्वेरी चालवता आणि कुठे समस्या येत आहेत.

सर्वसाधारणपणे, विकासकाला [DBA ला] सहसा कोणत्या क्लासिक समस्या येतात? “येथे आम्ही विनंती पूर्ण केली, आणि आमच्याबरोबर सर्व काही मंद आहे, सर्व काही लटकले आहे, काहीतरी घडत आहे... काही प्रकारचा त्रास!”

कारणे जवळजवळ नेहमीच समान असतात:

• अकार्यक्षम क्वेरी अल्गोरिदम
  विकसक: "आता मी त्याला SQL मध्ये 10 टेबल्स देत आहे JOIN द्वारे..." - आणि अपेक्षा करतो की त्याची परिस्थिती चमत्कारिकरित्या प्रभावीपणे "उघडली" जाईल आणि त्याला सर्वकाही त्वरीत मिळेल. परंतु चमत्कार घडत नाहीत, आणि अशी परिवर्तनशीलता असलेली कोणतीही प्रणाली (एकामधून 10 टेबल) नेहमी काही प्रकारची त्रुटी देते. [लेख]
• कालबाह्य आकडेवारी
  हा मुद्दा विशेषतः PostgreSQL साठी अतिशय समर्पक आहे, जेव्हा तुम्ही सर्व्हरवर मोठा डेटासेट “ओतला” तेव्हा विनंती करा आणि ते तुमच्या टॅबलेटला “सेक्सकॅनिट” करते. कारण काल ​​त्यात 10 रेकॉर्ड होते, आणि आज 10 दशलक्ष आहेत, परंतु PostgreSQL ला अद्याप याची माहिती नाही, आणि आम्हाला त्याबद्दल सांगणे आवश्यक आहे. [लेख]
• संसाधनांवर "प्लग".
  तुम्ही कमकुवत सर्व्हरवर एक मोठा आणि जास्त लोड केलेला डेटाबेस स्थापित केला आहे ज्यामध्ये पुरेशी डिस्क, मेमरी किंवा प्रोसेसर कार्यप्रदर्शन नाही. आणि एवढेच... कुठेतरी कामगिरीची कमाल मर्यादा आहे ज्यावर तुम्ही आता उडी मारू शकत नाही.
• अवरोधित करणे
  हा एक कठीण मुद्दा आहे, परंतु ते विविध सुधारित प्रश्नांसाठी (INSERT, UPDATE, DELETE) सर्वात संबंधित आहेत - हा एक वेगळा मोठा विषय आहे.

योजना मिळत आहे

...आणि बाकी सर्व गोष्टींसाठी आम्ही योजना हवी आहे! सर्व्हरमध्ये काय चालले आहे ते पाहणे आवश्यक आहे.

PostgreSQL साठी क्वेरी एक्झिक्युशन प्लॅन हा टेक्स्ट रिप्रेझेंटेशनमधील क्वेरी एक्झिक्यूशन अल्गोरिदमचा एक ट्री आहे. हे तंतोतंत अल्गोरिदम आहे जे प्लॅनरच्या विश्लेषणाच्या परिणामी, सर्वात प्रभावी असल्याचे आढळले.

प्रत्येक ट्री नोड एक ऑपरेशन आहे: टेबल किंवा इंडेक्समधून डेटा पुनर्प्राप्त करणे, बिटमॅप तयार करणे, दोन टेबल्स जोडणे, जोडणे, एकमेकांना छेदणे किंवा निवडी वगळणे. क्वेरी कार्यान्वित करण्यासाठी या झाडाच्या नोड्समधून चालणे समाविष्ट आहे.

क्वेरी योजना मिळविण्यासाठी, विधान कार्यान्वित करणे हा सर्वात सोपा मार्ग आहे EXPLAIN. सर्व वास्तविक गुणधर्मांसह प्राप्त करण्यासाठी, म्हणजे, मूळवर क्वेरी कार्यान्वित करण्यासाठी - EXPLAIN (ANALYZE, BUFFERS) SELECT ....

वाईट भाग: जेव्हा तुम्ही ते चालवता, तेव्हा ते "येथे आणि आता" घडते, म्हणून ते केवळ स्थानिक डीबगिंगसाठी योग्य आहे. जर तुम्ही खूप लोड केलेला सर्व्हर घेतला जो डेटा बदलांच्या जोरदार प्रवाहाखाली असेल आणि तुम्हाला दिसेल: “अरे! येथे आमच्याकडे धीमे अंमलबजावणी आहेsya विनंती." अर्धा तास, एक तासापूर्वी - तुम्ही धावत असताना आणि लॉगमधून ही विनंती मिळवत असताना, ती सर्व्हरवर परत आणत असताना, तुमचा संपूर्ण डेटासेट आणि आकडेवारी बदलली. तुम्ही ते डीबग करण्यासाठी चालवा - आणि ते पटकन चालते! आणि आपण का, का समजू शकत नाही होते हळूहळू

जेव्हा सर्व्हरवर विनंती अंमलात आणली गेली तेव्हा नेमके काय झाले हे समजून घेण्यासाठी, हुशार लोकांनी लिहिले auto_explain मॉड्यूल. हे जवळजवळ सर्व सामान्य पोस्टग्रेएसक्यूएल वितरणांमध्ये उपस्थित आहे आणि कॉन्फिग फाइलमध्ये सक्रिय केले जाऊ शकते.

काही विनंती तुम्ही सांगितलेल्या मर्यादेपेक्षा जास्त काळ चालत असल्याचे लक्षात आल्यास, ते तसे होते या विनंतीच्या योजनेचा “स्नॅपशॉट” आणि लॉगमध्ये एकत्र लिहितो.

आता सर्व काही ठीक आहे असे दिसते, आम्ही लॉगवर जातो आणि तिथे पाहतो... [पाठ फुटक्लोथ]. परंतु आम्ही त्याबद्दल काहीही सांगू शकत नाही, ही एक उत्कृष्ट योजना आहे कारण ती अंमलात आणण्यासाठी 11ms लागली.

सर्व काही ठीक आहे असे दिसते - परंतु प्रत्यक्षात काय झाले ते काहीही स्पष्ट नाही. सामान्य वेळेव्यतिरिक्त, आम्हाला खरोखर काहीही दिसत नाही. कारण साध्या मजकुराच्या अशा "कोकरू" कडे पाहणे सामान्यतः दृश्यमान नसते.

परंतु जरी ते स्पष्ट नसले तरीही, ते गैरसोयीचे असले तरीही, आणखी मूलभूत समस्या आहेत:

• नोड सूचित करतो संपूर्ण उपवृक्षाच्या संसाधनांची बेरीज त्याच्या खाली. म्हणजेच, या विशिष्ट इंडेक्स स्कॅनमध्ये काही नेस्टेड स्थिती असल्यास, त्यावर किती वेळ घालवला गेला हे तुम्ही शोधू शकत नाही. आत “मुले” आणि कंडिशनल व्हेरिएबल्स, CTE आहेत की नाही हे पाहण्यासाठी आपण डायनॅमिकपणे पाहिले पाहिजे - आणि हे सर्व “आपल्या मनात” वजा केले पाहिजे.
• दुसरा मुद्दा: नोडवर दर्शविलेली वेळ आहे एकल नोड अंमलबजावणी वेळ. जर हा नोड एक परिणाम म्हणून कार्यान्वित झाला असेल, उदाहरणार्थ, टेबल रेकॉर्डद्वारे लूप अनेक वेळा, तर लूपची संख्या—या नोडचे चक्र—प्लॅनमध्ये वाढते. परंतु अणू अंमलबजावणीची वेळ स्वतःच योजनेच्या दृष्टीने समान राहते. म्हणजेच, हा नोड एकूण किती काळ चालला हे समजून घेण्यासाठी, तुम्हाला एक गोष्ट दुसर्‍याने गुणाकार करणे आवश्यक आहे - पुन्हा, "तुमच्या डोक्यात."

अशा परिस्थितीत, "सर्वात कमकुवत दुवा कोण आहे?" हे समजून घ्या. जवळजवळ अशक्य. म्हणून, अगदी विकसक स्वतः "मॅन्युअल" मध्ये लिहितात "योजना समजून घेणे ही एक कला आहे जी शिकली पाहिजे, अनुभवली पाहिजे...".

परंतु आमच्याकडे 1000 डेव्हलपर आहेत आणि तुम्ही प्रत्येकाला हा अनुभव सांगू शकत नाही. मी, तू, त्याला माहीत आहे, पण तिथल्या कोणाला तरी आता माहीत नाही. कदाचित तो शिकेल, किंवा कदाचित नाही, परंतु त्याला आता काम करणे आवश्यक आहे - आणि हा अनुभव त्याला कोठे मिळेल?

व्हिज्युअलायझेशनची योजना करा

त्यामुळे या समस्यांना तोंड द्यायचे असेल तर आपल्याला याची जाणीव झाली योजनेचे चांगले व्हिज्युअलायझेशन. [लेख]

आम्ही प्रथम "बाजारातून" गेलो - काय अस्तित्वात आहे ते पाहण्यासाठी इंटरनेटवर पाहू या.

परंतु असे दिसून आले की तुलनेने कमी "थेट" उपाय आहेत जे कमी-अधिक प्रमाणात विकसित होत आहेत - अक्षरशः, फक्त एक: explain.depesz.com ह्युबर्ट लुबॅझव्स्की द्वारे. जेव्हा तुम्ही "फीड" फील्डमध्ये प्लॅनचे मजकूर प्रतिनिधित्व प्रविष्ट करता, तेव्हा ते तुम्हाला विश्लेषण केलेल्या डेटासह एक टेबल दाखवते:

• नोडचा स्वतःचा प्रक्रिया वेळ
• संपूर्ण उपवृक्षासाठी एकूण वेळ
• पुनर्प्राप्त केलेल्या नोंदींची संख्या जी सांख्यिकीयदृष्ट्या अपेक्षित होती
• नोड शरीर स्वतः

या सेवेमध्ये दुव्यांचे संग्रहण सामायिक करण्याची क्षमता देखील आहे. तुम्ही तुमची योजना तिथे फेकली आणि म्हणाला: "अरे, वास्या, ही एक लिंक आहे, तिथे काहीतरी गडबड आहे."

पण लहान समस्या देखील आहेत.

प्रथम, मोठ्या प्रमाणात “कॉपी-पेस्ट”. तुम्ही लॉगचा एक तुकडा घ्या, तो तिथे चिकटवा आणि पुन्हा आणि पुन्हा.

दुसरे म्हणजे, वाचलेल्या डेटाचे कोणतेही विश्लेषण नाही — आउटपुट समान बफर EXPLAIN (ANALYZE, BUFFERS), आम्हाला ते येथे दिसत नाही. त्यांना कसे वेगळे करायचे, त्यांना समजून घेणे आणि त्यांच्याबरोबर कसे कार्य करावे हे त्याला फक्त माहित नाही. जेव्हा तुम्ही भरपूर डेटा वाचत असाल आणि तुम्ही डिस्क आणि मेमरी कॅशेचे चुकीचे वाटप करत आहात हे लक्षात येत असेल, तेव्हा ही माहिती खूप महत्त्वाची असते.

तिसरा नकारात्मक मुद्दा म्हणजे या प्रकल्पाचा अत्यंत कमकुवत विकास. कमिट खूप लहान आहेत, दर सहा महिन्यांनी एकदा असल्यास ते चांगले आहे आणि कोड पर्लमध्ये आहे.

परंतु हे सर्व "गीत" आहे, आम्ही यासह कसे तरी जगू शकतो, परंतु एक गोष्ट आहे जी आम्हाला या सेवेपासून मोठ्या प्रमाणात दूर करते. कॉमन टेबल एक्सप्रेशन (CTE) आणि InitPlan/SubPlan सारख्या विविध डायनॅमिक नोड्सच्या विश्लेषणात या त्रुटी आहेत.

जर तुम्हाला या चित्रावर विश्वास असेल, तर प्रत्येक वैयक्तिक नोडची एकूण अंमलबजावणी वेळ संपूर्ण विनंतीच्या एकूण अंमलबजावणी वेळेपेक्षा जास्त आहे. हे सोपं आहे - या CTE ची निर्मिती वेळ CTE स्कॅन नोडमधून वजा केली गेली नाही. त्यामुळे, CTE स्कॅनला किती वेळ लागला याचे योग्य उत्तर आम्हाला आता माहीत नाही.

मग आमच्या लक्षात आले की स्वतःचे लिहिण्याची वेळ आली आहे - हुर्रे! प्रत्येक विकसक म्हणतो: "आता आम्ही आमचे स्वतःचे लिहू, ते खूप सोपे होईल!"

आम्ही वेब सेवांसाठी विशिष्ट स्टॅक घेतला: Node.js + Express वर आधारित कोर, सुंदर आकृत्यांसाठी बूटस्ट्रॅप आणि D3.js वापरले. आणि आमच्या अपेक्षा पूर्णपणे न्याय्य होत्या - आम्हाला 2 आठवड्यांत पहिला प्रोटोटाइप मिळाला:

• सानुकूल योजना पार्सर
  म्हणजेच, आता आम्ही PostgreSQL द्वारे व्युत्पन्न केलेल्या कोणत्याही योजनेचे विश्लेषण करू शकतो.
• डायनॅमिक नोड्सचे योग्य विश्लेषण - CTE स्कॅन, InitPlan, SubPlan
• बफर वितरणाचे विश्लेषण - मेमरीमधून डेटा पृष्ठे कुठे वाचली जातात, कुठे स्थानिक कॅशेमधून, कुठे डिस्कवरून
• स्पष्टता मिळाली
  लॉगमध्ये हे सर्व “खणणे” नाही तर चित्रात लगेच “कमकुवत दुवा” पाहण्यासाठी.

सिंटॅक्स हायलाइटिंगसह आम्हाला असे काहीतरी मिळाले. परंतु सामान्यतः आमचे डेव्हलपर यापुढे योजनेच्या संपूर्ण प्रतिनिधित्वासह कार्य करत नाहीत, तर लहान योजनेसह. शेवटी, आम्ही आधीच सर्व संख्यांचे विश्लेषण केले आहे आणि त्यांना डावीकडे आणि उजवीकडे फेकले आहे आणि मध्यभागी आम्ही फक्त पहिली ओळ सोडली आहे, तो कोणत्या प्रकारचा नोड आहे: सीटीई स्कॅन, सीटीई जनरेशन किंवा सेक स्कॅन काही चिन्हानुसार.

हे संक्षिप्त प्रतिनिधित्व आहे ज्याला आपण म्हणतो योजना टेम्पलेट.

आणखी काय सोयीचे असेल? आमच्या एकूण वेळेचा कोणता वाटा कोणत्या नोडला दिला जातो हे पाहणे सोयीचे होईल - आणि फक्त "ते चिकटवा" पाय चार्ट.

आम्ही नोडकडे निर्देश करतो आणि पाहतो - असे दिसून आले की Seq स्कॅनला एकूण वेळेच्या एक चतुर्थांशपेक्षा कमी वेळ लागला आणि उर्वरित 3/4 CTE स्कॅनने घेतला. भयपट! CTE स्कॅनच्या "आग दर" बद्दल ही एक छोटी टीप आहे जर तुम्ही त्यांचा सक्रियपणे तुमच्या क्वेरींमध्ये वापर करत असाल. ते फार वेगवान नाहीत - ते नियमित टेबल स्कॅनिंगपेक्षाही निकृष्ट आहेत. [लेख] [लेख]

परंतु सामान्यत: अशा आकृत्या अधिक मनोरंजक, अधिक जटिल असतात, जेव्हा आपण ताबडतोब एका विभागाकडे निर्देश करतो आणि पाहतो, उदाहरणार्थ, अर्ध्याहून अधिक वेळा काही Seq स्कॅन "खाल्ले". शिवाय, आत एक प्रकारचा फिल्टर होता, त्यानुसार बरेच रेकॉर्ड टाकून दिले गेले होते... तुम्ही हे चित्र थेट विकसकाकडे टाकू शकता आणि म्हणू शकता: “वास्या, तुमच्यासाठी येथे सर्व काही वाईट आहे! हे समजून घ्या, पहा - काहीतरी चूक आहे!”

साहजिकच त्यात काही “रेक” गुंतलेले होते.

आमच्या समोर आलेली पहिली गोष्ट म्हणजे गोलाकार समस्या. योजनेतील प्रत्येक वैयक्तिक नोडची वेळ 1 μs च्या अचूकतेसह दर्शविली जाते. आणि जेव्हा नोड सायकलची संख्या ओलांडते, उदाहरणार्थ, 1000 - अंमलबजावणीनंतर PostgreSQL "अचूकतेमध्ये" विभाजित केले जाते, तेव्हा परत मोजताना आम्हाला "0.95ms आणि 1.05ms दरम्यान" एकूण वेळ मिळेल. जेव्हा मोजणी मायक्रोसेकंदमध्ये जाते, तेव्हा ते ठीक आहे, परंतु जेव्हा ते आधीपासूनच [मिली]सेकंद असते, तेव्हा "ज्याने किती वापरले" योजनेच्या नोड्सवर संसाधने "अनटाई" करताना तुम्हाला ही माहिती विचारात घ्यावी लागेल.

दुसरा मुद्दा, अधिक जटिल, डायनॅमिक नोड्समध्ये संसाधनांचे (त्या बफर) वितरण आहे. यासाठी आम्हाला प्रोटोटाइपचे पहिले 2 आठवडे आणि आणखी 4 आठवडे खर्च करावे लागले.

या प्रकारची समस्या येणे अगदी सोपे आहे - आम्ही CTE करतो आणि त्यात काहीतरी वाचतो. खरं तर, PostgreSQL "स्मार्ट" आहे आणि तेथे थेट काहीही वाचणार नाही. मग आम्ही त्यातून पहिला रेकॉर्ड घेतो आणि त्याच CTE मधील शंभर आणि पहिला रेकॉर्ड घेतो.

आम्ही योजना पाहतो आणि समजतो - हे विचित्र आहे, आमच्याकडे Seq स्कॅनमध्ये 3 बफर (डेटा पृष्ठे) “उपभोगलेले” आहेत, आणखी 1 CTE स्कॅनमध्ये आणि 2 आणखी CTE स्कॅनमध्ये आहेत. म्हणजेच, जर आपण सर्व गोष्टींची बेरीज केली तर आपल्याला 6 मिळतील, परंतु टॅब्लेटवरून आपण फक्त 3 वाचतो! CTE स्कॅन कुठूनही काहीही वाचत नाही, परंतु प्रक्रिया मेमरीसह थेट कार्य करते. म्हणजेच, येथे काहीतरी स्पष्टपणे चुकीचे आहे!

खरं तर, असे दिसून आले की येथे Seq स्कॅनकडून विनंती करण्यात आलेला सर्व 3 पृष्ठांचा डेटा आहे, प्रथम 1 ने 1 ला CTE स्कॅनसाठी विचारले, आणि नंतर 2 रा आणि आणखी 2 त्याला वाचण्यात आले. म्हणजेच एकूण 3 पृष्ठे डेटा वाचला होता, 6 नाही.

आणि या चित्रामुळे आम्हाला हे समजले की योजनेची अंमलबजावणी यापुढे झाड नाही, तर फक्त एक प्रकारचा अॅसायक्लिक आलेख आहे. आणि आम्हाला असा एक आकृतीबंध मिळाला, जेणेकरून आम्हाला समजेल की "पहिल्यांदा कुठून काय आले." म्हणजेच, येथे आम्ही pg_class मधून CTE तयार केले आणि ते दोनदा मागितले आणि दुसऱ्यांदा मागितल्यावर आमचा जवळजवळ सर्व वेळ शाखेत गेला. हे स्पष्ट आहे की 2 वी एंट्री वाचणे हे टॅब्लेटवरून फक्त 101ली एंट्री वाचण्यापेक्षा खूप महाग आहे.

आम्ही थोडा वेळ श्वास सोडला. ते म्हणाले: “आता, निओ, तुला कुंग फू माहित आहे! आता आमचा अनुभव तुमच्या स्क्रीनवर आहे. आता तुम्ही ते वापरू शकता." [लेख]

लॉग एकत्रीकरण

आमच्या 1000 विकासकांनी सुटकेचा नि:श्वास सोडला. परंतु आम्हाला समजले की आमच्याकडे फक्त शेकडो "लढाऊ" सर्व्हर आहेत आणि विकासकांसाठी हे सर्व "कॉपी-पेस्ट" अजिबात सोयीचे नाही. ते आपल्यालाच जमवायचे आहे हे लक्षात आले.

सर्वसाधारणपणे, एक मानक मॉड्यूल आहे जे आकडेवारी गोळा करू शकते, तथापि, ते कॉन्फिगरेशनमध्ये सक्रिय करणे देखील आवश्यक आहे - हे मॉड्यूल pg_stat_statements. पण तो आम्हाला शोभला नाही.

प्रथम, ते एकाच डेटाबेसमधील भिन्न योजना वापरून समान क्वेरीस नियुक्त करते भिन्न QueryIds. म्हणजेच, आपण प्रथम केले तर SET search_path = '01'; SELECT * FROM user LIMIT 1;आणि मग SET search_path = '02'; आणि तीच विनंती, नंतर या मॉड्यूलच्या आकडेवारीमध्ये भिन्न रेकॉर्ड असतील आणि मी योजना विचारात न घेता, विशेषत: या विनंती प्रोफाइलच्या संदर्भात सामान्य आकडेवारी गोळा करू शकणार नाही.

दुसरा मुद्दा ज्याने आम्हाला ते वापरण्यापासून रोखले योजनांचा अभाव. म्हणजेच कोणतीही योजना नाही, फक्त विनंती आहे. काय मंद होत आहे ते आम्ही पाहतो, पण का ते आम्हाला समजत नाही. आणि येथे आपण वेगाने बदलणाऱ्या डेटासेटच्या समस्येकडे परत येऊ.

आणि शेवटचा क्षण - "तथ्यांचा" अभाव. म्हणजेच, आपण क्वेरी अंमलबजावणीच्या विशिष्ट उदाहरणास संबोधित करू शकत नाही - तेथे काहीही नाही, फक्त एकत्रित आकडेवारी आहे. जरी यासह कार्य करणे शक्य असले तरी ते खूप कठीण आहे.

त्यामुळे आम्ही कॉपी-पेस्टशी लढा देण्याचा निर्णय घेतला आणि लिहायला सुरुवात केली जिल्हाधिकारी.

कलेक्टर SSH द्वारे जोडतो, प्रमाणपत्र वापरून डेटाबेससह सर्व्हरशी सुरक्षित कनेक्शन स्थापित करतो आणि tail -F लॉग फाइलमध्‍ये "चिकटते". त्यामुळे या अधिवेशनात आ आम्हाला संपूर्ण लॉग फाइलचा संपूर्ण "मिरर" मिळेल, जे सर्व्हर व्युत्पन्न करते. सर्व्हरवरील लोड स्वतःच कमी आहे, कारण आम्ही तेथे काहीही विश्लेषित करत नाही, आम्ही फक्त रहदारी मिरर करतो.

आम्ही आधीच Node.js मध्ये इंटरफेस लिहायला सुरुवात केली असल्याने, आम्ही त्यात कलेक्टर लिहिणे सुरू ठेवले. आणि या तंत्रज्ञानाने स्वतःला न्याय्य ठरवले आहे, कारण कमकुवत स्वरूपित मजकूर डेटासह कार्य करण्यासाठी JavaScript वापरणे खूप सोयीचे आहे, जे लॉग आहे. आणि बॅकएंड प्लॅटफॉर्म म्हणून स्वतःच Node.js इन्फ्रास्ट्रक्चर तुम्हाला नेटवर्क कनेक्शनसह आणि कोणत्याही डेटा प्रवाहासह सहज आणि सोयीस्करपणे कार्य करण्यास अनुमती देते.

त्यानुसार, आम्ही दोन कनेक्शन "स्ट्रेच" करतो: प्रथम लॉग स्वतः "ऐकणे" आणि ते स्वतःकडे घेऊन जाणे आणि दुसरे वेळोवेळी बेसला विचारणे. "परंतु लॉग दर्शविते की oid 123 सह चिन्ह अवरोधित केले आहे," परंतु याचा अर्थ विकासकाला काही अर्थ नाही आणि डेटाबेसला विचारणे चांगले होईल, "तरीही OID = 123 म्हणजे काय?" आणि म्हणून आम्ही वेळोवेळी बेसला विचारतो की आम्हाला स्वतःबद्दल काय माहित नाही.

"एकच गोष्ट आहे जी तुम्ही विचारात घेतली नाही, हत्तीसारख्या मधमाश्यांची एक प्रजाती आहे!.." आम्हाला 10 सर्व्हरचे निरीक्षण करायचे असताना आम्ही ही प्रणाली विकसित करण्यास सुरुवात केली. आमच्या समजुतीमध्ये सर्वात गंभीर, जिथे काही समस्या उद्भवल्या ज्यांना सामोरे जाणे कठीण होते. परंतु पहिल्या तिमाहीत, आम्हाला देखरेखीसाठी शंभर मिळाले - कारण सिस्टमने कार्य केले, प्रत्येकाला ते हवे होते, प्रत्येकजण आरामदायक होता.

हे सर्व जोडणे आवश्यक आहे, डेटा प्रवाह मोठा आणि सक्रिय आहे. खरं तर, आपण काय निरीक्षण करतो, आपण काय हाताळू शकतो, तेच आपण वापरतो. आम्ही डेटा स्टोरेज म्हणून PostgreSQL देखील वापरतो. आणि ऑपरेटरपेक्षा त्यात डेटा "ओतणे" जलद काहीही नाही COPY अजून नाही.

परंतु फक्त डेटा "ओतणे" हे खरोखर आमचे तंत्रज्ञान नाही. कारण जर तुमच्याकडे शंभर सर्व्हरवर प्रति सेकंद अंदाजे 50k विनंत्या असतील, तर हे दररोज 100-150GB लॉग जनरेट करेल. म्हणून, आम्हाला बेस काळजीपूर्वक "कट" करावा लागला.

प्रथम, आम्ही केले दिवसा विभाजन, कारण, मोठ्या प्रमाणावर, दिवसांमधील परस्परसंबंधात कोणालाही स्वारस्य नाही. काल तुमच्याकडे जे होते त्यात काय फरक पडतो, जर तुम्ही आज रात्री अनुप्रयोगाची नवीन आवृत्ती आणली - आणि आधीच काही नवीन आकडेवारी.

दुसरे म्हणजे, आम्ही शिकलो (जबरदस्ती केली) वापरून लिहिण्यासाठी खूप, खूप जलद COPY. म्हणजे फक्त नाही COPYकारण तो पेक्षा वेगवान आहे INSERT, आणि आणखी वेगवान.

तिसरा मुद्दा - मला करावे लागले अनुक्रमे ट्रिगर आणि परदेशी की सोडून द्या. म्हणजेच, आपल्याकडे संदर्भात्मक अखंडता अजिबात नाही. कारण तुमच्याकडे FK ची जोडी असलेली टेबल असेल आणि तुम्ही डेटाबेस स्ट्रक्चरमध्ये असे म्हणत असाल की "येथे एक लॉग रेकॉर्ड आहे ज्याचा FK द्वारे संदर्भित आहे, उदाहरणार्थ, रेकॉर्डच्या एका गटासाठी," तर तुम्ही ते टाकल्यावर, PostgreSQL ते कसे घ्यावे आणि ते प्रामाणिकपणे कसे करावे याशिवाय काहीही शिल्लक नाही SELECT 1 FROM master_fk1_table WHERE ... तुम्ही समाविष्ट करण्याचा प्रयत्न करत असलेल्या अभिज्ञापकासह - हा रेकॉर्ड तिथे उपस्थित आहे हे तपासण्यासाठी, तुम्ही ही विदेशी की तुमच्या इन्सर्टेशनसह "ब्रेक ऑफ" करत नाही.

लक्ष्य सारणी आणि त्‍याच्‍या निर्देशांकांच्‍या एका नोंदीऐवजी, आम्‍हाला ते संदर्भित असलेल्‍या सर्व सारणींमधून वाचण्‍याचा अतिरिक्त लाभ मिळतो. परंतु आम्हाला याची अजिबात गरज नाही - आमचे कार्य कमीतकमी लोडसह शक्य तितक्या लवकर आणि शक्य तितक्या लवकर रेकॉर्ड करणे आहे. तर एफके - खाली!

पुढील मुद्दा एकत्रीकरण आणि हॅशिंग आहे. सुरुवातीला, आम्ही ते डेटाबेसमध्ये लागू केले - सर्व केल्यानंतर, रेकॉर्ड आल्यावर ते ताबडतोब करणे सोयीस्कर आहे, ते एखाद्या प्रकारच्या टॅब्लेटमध्ये करा. ट्रिगरमध्ये "प्लस वन". बरं, हे सोयीस्कर आहे, परंतु तीच वाईट गोष्ट - आपण एक रेकॉर्ड घाला, परंतु दुसर्‍या टेबलवरून काहीतरी वाचण्यास आणि लिहिण्यास भाग पाडले जाईल. शिवाय, तुम्ही फक्त वाचता-लिहिता असे नाही तर प्रत्येक वेळी ते करता.

आता कल्पना करा की तुमच्याकडे एक सारणी आहे ज्यामध्ये तुम्ही विशिष्ट होस्टमधून गेलेल्या विनंत्यांची संख्या मोजता: +1, +1, +1, ..., +1. आणि आपल्याला, तत्वतः, याची आवश्यकता नाही - हे सर्व शक्य आहे कलेक्टर वर मेमरी मध्ये बेरीज आणि डेटाबेसला एकाच वेळी पाठवा +10.

होय, काही समस्यांच्या बाबतीत, तुमची तार्किक अखंडता "असून पडू शकते", परंतु हे जवळजवळ अवास्तव प्रकरण आहे - कारण तुमच्याकडे एक सामान्य सर्व्हर आहे, त्याच्या कंट्रोलरमध्ये बॅटरी आहे, तुमच्याकडे व्यवहार लॉग आहे, एक लॉग आहे. फाइल सिस्टीम... सर्वसाधारणपणे, त्याची किंमत नाही. ट्रिगर्स/एफके चालवण्यामुळे तुम्हाला होणारी उत्पादकता कमी होणे तुम्ही केलेल्या खर्चाचे मूल्य नाही.

हॅशिंगच्या बाबतीतही असेच आहे. तुमच्याकडे एक विशिष्ट विनंती उडते, तुम्ही डेटाबेसमध्ये त्यातून विशिष्ट अभिज्ञापकाची गणना करता, डेटाबेसवर लिहा आणि नंतर प्रत्येकाला सांगा. रेकॉर्डिंगच्या वेळी, दुसरी व्यक्ती तुमच्याकडे येईपर्यंत सर्व काही ठीक आहे ज्याला तीच गोष्ट रेकॉर्ड करायची आहे - आणि तुम्हाला अवरोधित केले जाईल आणि हे आधीच वाईट आहे. म्हणून, जर तुम्ही काही आयडीची निर्मिती क्लायंटकडे हस्तांतरित करू शकत असाल (डेटाबेसशी संबंधित), तर हे करणे चांगले आहे.

आमच्यासाठी मजकूर - विनंती, योजना, टेम्प्लेट,... मधून MD5 वापरणे अगदी योग्य होते... आम्ही त्याची कलेक्टरच्या बाजूने गणना करतो आणि डेटाबेसमध्ये तयार आयडी “ओततो”. MD5 ची लांबी आणि दैनंदिन विभाजन आम्हाला संभाव्य टक्करांबद्दल काळजी करू नका.

परंतु हे सर्व पटकन रेकॉर्ड करण्यासाठी, आम्हाला रेकॉर्डिंग प्रक्रियेतच बदल करणे आवश्यक होते.

तुम्ही सहसा डेटा कसा लिहिता? आमच्याकडे काही प्रकारचा डेटासेट आहे, आम्ही तो अनेक सारण्यांमध्ये विभाजित करतो आणि नंतर तो कॉपी करतो - प्रथम पहिल्यामध्ये, नंतर दुसऱ्यामध्ये, तिसऱ्यामध्ये... हे गैरसोयीचे आहे, कारण आम्ही तीन चरणांमध्ये एक डेटा प्रवाह लिहित आहोत असे दिसते. क्रमाक्रमाने. अप्रिय. ते जलद करता येईल का? करू शकता!

हे करण्यासाठी, हे प्रवाह एकमेकांच्या समांतर विघटित करणे पुरेसे आहे. असे दिसून आले की आमच्याकडे त्रुटी, विनंत्या, टेम्पलेट्स, ब्लॉकिंग्ज, ... स्वतंत्र थ्रेडमध्ये उडत आहेत - आणि आम्ही ते सर्व समांतर लिहितो. यासाठी पुरेसे आहे प्रत्येक वैयक्तिक लक्ष्य सारणीसाठी एक कॉपी चॅनेल सतत उघडे ठेवा.

म्हणजे कलेक्टर येथे नेहमीच एक प्रवाह असतो, ज्यामध्ये मी मला आवश्यक असलेला डेटा लिहू शकतो. परंतु डेटाबेस हा डेटा पाहतो आणि कोणीतरी हा डेटा लिहिण्याची वाट पाहत अडकू नये म्हणून, प्रत ठराविक अंतराने व्यत्यय आणणे आवश्यक आहे. आमच्यासाठी, सर्वात प्रभावी कालावधी सुमारे 100ms होता - आम्ही ते बंद करतो आणि लगेच त्याच टेबलवर पुन्हा उघडतो. आणि काही शिखरांदरम्यान आपल्याकडे एक प्रवाह पुरेसा नसल्यास, आम्ही एका विशिष्ट मर्यादेपर्यंत पूलिंग करतो.

याव्यतिरिक्त, आम्हाला आढळले की अशा लोड प्रोफाइलसाठी, बॅचेसमध्ये रेकॉर्ड गोळा केल्यावर कोणतेही एकत्रीकरण वाईट आहे. क्लासिक वाईट आहे INSERT ... VALUES आणि आणखी 1000 रेकॉर्ड. कारण त्या क्षणी तुमच्याकडे मीडियावर लेखनाचे शिखर आहे, आणि डिस्कवर काहीतरी लिहिण्याचा प्रयत्न करणारे इतर प्रत्येकजण वाट पाहत असेल.

अशा विसंगतीपासून मुक्त होण्यासाठी, फक्त काहीही एकत्रित करू नका, अजिबात बफर करू नका. आणि जर डिस्कवर बफरिंग होत असेल (सुदैवाने, Node.js मधील स्ट्रीम API तुम्हाला शोधण्याची परवानगी देते) - हे कनेक्शन पुढे ढकलू द्या. जेव्हा तुम्हाला एखादा इव्हेंट प्राप्त होईल की तो पुन्हा विनामूल्य आहे, तेव्हा जमा झालेल्या रांगेतून त्यावर लिहा. आणि ते व्यस्त असताना, पूलमधून पुढील विनामूल्य घ्या आणि त्यावर लिहा.

डेटा रेकॉर्डिंगसाठी हा दृष्टीकोन सादर करण्यापूर्वी, आमच्याकडे अंदाजे 4K लेखन ऑप्स होते आणि अशा प्रकारे आम्ही लोड 4 पट कमी केला. आता ते नवीन निरीक्षण केलेल्या डेटाबेसमुळे आणखी 6 पट वाढले आहेत - 100MB/s पर्यंत. आणि आता आम्ही गेल्या 3 महिन्यांचे लॉग सुमारे 10-15TB च्या व्हॉल्यूममध्ये संग्रहित करतो, या आशेने की केवळ तीन महिन्यांत कोणताही विकासक कोणतीही समस्या सोडविण्यास सक्षम असेल.

आम्हाला समस्या समजतात

पण फक्त हा सगळा डेटा गोळा करणे चांगले, उपयुक्त, समर्पक आहे, परंतु पुरेसे नाही - हे समजून घेणे आवश्यक आहे. कारण या दररोज लाखो वेगवेगळ्या योजना आहेत.

परंतु लाखो लोक अव्यवस्थित आहेत, आपण प्रथम "लहान" केले पाहिजे. आणि, सर्व प्रथम, आपण ही "छोटी" गोष्ट कशी आयोजित कराल हे ठरविणे आवश्यक आहे.

आम्ही तीन प्रमुख मुद्दे ओळखले आहेत:

• कोण ही विनंती पाठवली
  म्हणजेच, कोणत्या ऍप्लिकेशनमधून ते "आगमन" झाले: वेब इंटरफेस, बॅकएंड, पेमेंट सिस्टम किंवा काहीतरी.
• जेथे ते घडलं
  कोणत्या विशिष्ट सर्व्हरवर? कारण जर तुमच्याकडे एका अनुप्रयोगाखाली अनेक सर्व्हर असतील आणि अचानक एक "मूर्ख" झाला (कारण "डिस्क सडली", "मेमरी लीक झाली", इतर काही समस्या), तर तुम्हाला विशेषत: सर्व्हरला संबोधित करणे आवश्यक आहे.
• कसे समस्या एक प्रकारे किंवा दुसर्या प्रकारे प्रकट होते

आम्हाला विनंती "कोणी" पाठवली हे समजून घेण्यासाठी, आम्ही एक मानक साधन वापरतो - सत्र व्हेरिएबल सेट करतो: SET application_name = '{bl-host}:{bl-method}'; — आम्ही विनंती केलेल्या व्यवसाय लॉजिक होस्टचे नाव आणि ती सुरू करणाऱ्या पद्धतीचे किंवा अनुप्रयोगाचे नाव पाठवतो.

आम्ही विनंतीचा "मालक" पास केल्यानंतर, ते लॉगमध्ये आउटपुट असणे आवश्यक आहे - यासाठी आम्ही व्हेरिएबल कॉन्फिगर करतो log_line_prefix = ' %m [%p:%v] [%d] %r %a'. स्वारस्य असलेल्यांसाठी, कदाचित मॅन्युअल मध्ये पहाया सर्वांचा अर्थ काय आहे. असे दिसून आले की आम्ही लॉगमध्ये पाहतो:

• время
• प्रक्रिया आणि व्यवहार अभिज्ञापक
• डेटाबेस नाव
• ही विनंती पाठवलेल्या व्यक्तीचा आय.पी
• आणि पद्धतीचे नाव

मग आमच्या लक्षात आले की वेगवेगळ्या सर्व्हरमधील एका विनंतीचा सहसंबंध पाहणे फारसे मनोरंजक नाही. असे नाही की तुमच्याकडे अशी परिस्थिती असते जिथे एक अनुप्रयोग इकडे तिकडे तितकाच स्क्रू होतो. परंतु ते समान असले तरीही, यापैकी कोणतेही सर्व्हर पहा.

तर येथे कट आहे "एक सर्व्हर - एक दिवस" कोणत्याही विश्लेषणासाठी ते आमच्यासाठी पुरेसे असल्याचे दिसून आले.

पहिला विश्लेषणात्मक विभाग समान आहे "नमुना" - योजनेच्या सादरीकरणाचे संक्षिप्त रूप, सर्व संख्यात्मक संकेतकांपासून साफ ​​केलेले. दुसरा कट हा अनुप्रयोग किंवा पद्धत आहे आणि तिसरा कट हा विशिष्ट योजना नोड आहे ज्यामुळे आम्हाला समस्या निर्माण झाल्या.

जेव्हा आम्ही विशिष्ट उदाहरणांवरून टेम्प्लेटवर गेलो, तेव्हा आम्हाला एकाच वेळी दोन फायदे मिळाले:

• विश्लेषणासाठी वस्तूंच्या संख्येत अनेक घट
  आम्हाला यापुढे हजारो प्रश्न किंवा योजनांद्वारे नाही तर डझनभर टेम्पलेट्सद्वारे समस्येचे विश्लेषण करावे लागेल.
• टाइमलाइन
  म्हणजेच, एका विशिष्ट विभागात "तथ्ये" सारांशित करून, तुम्ही दिवसभरात त्यांचे स्वरूप प्रदर्शित करू शकता. आणि इथे तुम्ही समजू शकता की जर तुमच्याकडे काही प्रकारचे पॅटर्न असेल, उदाहरणार्थ, तासातून एकदा, पण ते दिवसातून एकदाच घडले पाहिजे, तर तुम्ही विचार केला पाहिजे की काय चूक झाली - हे कोणी केले आणि का, कदाचित ते येथे असावे करू नये. ही दुसरी अ-संख्यात्मक, पूर्णपणे दृश्य, विश्लेषणाची पद्धत आहे.

उर्वरित पद्धती आम्ही योजनेतून काढलेल्या निर्देशकांवर आधारित आहेत: असा नमुना किती वेळा आला, एकूण आणि सरासरी वेळ, डिस्कवरून किती डेटा वाचला गेला आणि मेमरीमधून किती...

कारण, उदाहरणार्थ, आपण होस्टसाठी विश्लेषण पृष्ठावर आलात, पहा - काहीतरी डिस्कवर खूप वाचू लागले आहे. सर्व्हरवरील डिस्क ते हाताळू शकत नाही - त्यातून कोण वाचते?

आणि तुम्ही कोणत्याही स्तंभानुसार क्रमवारी लावू शकता आणि तुम्ही आत्ता काय हाताळाल ते ठरवू शकता - प्रोसेसर किंवा डिस्कवरील भार किंवा एकूण विनंत्यांची संख्या... आम्ही ते क्रमवारी लावले, "शीर्ष" पाहिले, ते निश्चित केले आणि अनुप्रयोगाची नवीन आवृत्ती आणली.
[व्हिडिओ व्याख्यान]

आणि सारख्या विनंतीवरून तुम्ही एकाच टेम्प्लेटसह येणारे वेगवेगळे अॅप्लिकेशन लगेच पाहू शकता SELECT * FROM users WHERE login = 'Vasya'. फ्रंटएंड, बॅकएंड, प्रोसेसिंग... आणि तुम्हाला आश्चर्य वाटेल की जर वापरकर्ता त्याच्याशी संवाद साधत नसेल तर प्रक्रिया का वाचेल.

विरुद्ध मार्ग म्हणजे अनुप्रयोगातून ते काय करते ते त्वरित पहा. उदाहरणार्थ, फ्रंटएंड हे, हे, हे आणि हे तासातून एकदा आहे (टाइमलाइन मदत करते). आणि प्रश्न लगेच उद्भवतो: असे दिसते की तासातून एकदा काहीतरी करणे हे फ्रंटएंडचे काम नाही ...

काही काळानंतर, आमच्या लक्षात आले की आमच्याकडे एकत्रितपणे कमतरता आहे योजना नोड्स द्वारे आकडेवारी. आम्ही फक्त ते नोड्स प्लॅन्समधून वेगळे केले जे टेबलच्या डेटासह स्वतः काहीतरी करतात (त्यांना निर्देशांकानुसार वाचा किंवा लिहा). खरं तर, मागील चित्राच्या तुलनेत फक्त एक पैलू जोडला गेला आहे - या नोडने आम्हाला किती रेकॉर्ड आणले?, आणि किती टाकून दिले (फिल्टरद्वारे पंक्ती काढल्या).

तुमच्याकडे प्लेटवर योग्य निर्देशांक नाही, तुम्ही त्याला विनंती करता, ती निर्देशांकाच्या पुढे उडते, Seq स्कॅनमध्ये येते... तुम्ही एक सोडून सर्व रेकॉर्ड फिल्टर केले आहेत. तुम्हाला दररोज 100M फिल्टर केलेल्या रेकॉर्डची आवश्यकता का आहे? निर्देशांक रोल अप करणे चांगले नाही का?

नोडद्वारे सर्व योजनांचे विश्लेषण केल्यावर, आमच्या लक्षात आले की योजनांमध्ये काही विशिष्ट रचना आहेत ज्या संशयास्पद वाटण्याची शक्यता आहे. आणि विकसकाला सांगणे चांगले होईल: “मित्रा, येथे तुम्ही प्रथम अनुक्रमणिकेनुसार वाचा, नंतर क्रमवारी लावा आणि नंतर कट करा” - नियम म्हणून, एक रेकॉर्ड आहे.

प्रश्न लिहिणाऱ्या प्रत्येकाला कदाचित या पॅटर्नचा सामना करावा लागला असेल: "मला वस्यसाठी शेवटची ऑर्डर द्या, तिची तारीख." आणि जर तुमच्याकडे तारखेनुसार अनुक्रमणिका नसेल किंवा तुम्ही वापरलेल्या निर्देशांकात तारीख नसेल, तर तुम्ही अगदी त्याच "रेक" वर पाऊल टाका.

परंतु आम्हाला माहित आहे की हा एक "रेक" आहे - म्हणून विकसकाने काय करावे हे त्वरित का सांगू नये. त्यानुसार, आता योजना उघडताना, आमचा विकासक ताबडतोब टिपांसह एक सुंदर चित्र पाहतो, जिथे ते त्याला लगेच सांगतात: "तुम्हाला इकडे-तिकडे समस्या आहेत, परंतु त्या अशा प्रकारे सोडवल्या जातात."

परिणामी, सुरुवातीला समस्या सोडवण्यासाठी आवश्यक असलेल्या अनुभवाचे प्रमाण आणि आता लक्षणीय घट झाली आहे. आमच्याकडे हे असेच साधन आहे.

स्त्रोत: www.habr.com