"कोडको रूपमा डाटाबेस" अनुभव

SQL, के सरल हुन सक्छ? हामी प्रत्येकले साधारण अनुरोध लेख्न सक्छौं - हामी टाइप गर्छौं चयनआवश्यक स्तम्भहरू सूचीबद्ध गर्नुहोस्, त्यसपछि बाट, तालिका नाम, केही सर्तहरू जहाँ र यो सबै हो - उपयोगी डेटा हाम्रो खल्तीमा छ, र (लगभग) जुनसुकै बेला DBMS हुड अन्तर्गत छ (वा हुनसक्छ। कुनै DBMS होइन)। नतिजाको रूपमा, लगभग कुनै पनि डेटा स्रोतसँग काम गर्ने (सम्बन्धित र त्यसो होइन) सामान्य कोडको दृष्टिकोणबाट विचार गर्न सकिन्छ (यसले संकेत गर्दछ - संस्करण नियन्त्रण, कोड समीक्षा, स्थिर विश्लेषण, अटोटेस्टहरू, र यो सबै)। र यो न केवल डाटा, स्कीमा र माइग्रेसनमा लागू हुन्छ, तर सामान्यतया भण्डारणको सम्पूर्ण जीवनमा। यस लेखमा हामी दैनिक कार्यहरू र "कोडको रूपमा डाटाबेस" को लेन्स अन्तर्गत विभिन्न डाटाबेसहरूसँग काम गर्ने समस्याहरूको बारेमा कुरा गर्नेछौं।

र बाट सुरु गरौं ORM। "SQL बनाम ORM" प्रकारको पहिलो लडाइहरू फिर्ता देखिए प्रि-पेट्रिन रस'.

वस्तु-सम्बन्धित म्यापिङ

ORM समर्थकहरूले परम्परागत रूपमा गति र विकासको सहजता, DBMS बाट स्वतन्त्रता र सफा कोडलाई महत्त्व दिन्छन्। हामी मध्ये धेरैको लागि, डाटाबेससँग काम गर्ने कोड (र प्राय: डाटाबेस नै)

यो सामान्यतया केहि यस्तो देखिन्छ ...

@Entity
@Table(name = "stock", catalog = "maindb", uniqueConstraints = {
        @UniqueConstraint(columnNames = "STOCK_NAME"),
        @UniqueConstraint(columnNames = "STOCK_CODE") })
public class Stock implements java.io.Serializable {

    @Id
    @GeneratedValue(strategy = IDENTITY)
    @Column(name = "STOCK_ID", unique = true, nullable = false)
    public Integer getStockId() {
        return this.stockId;
    }
  ...

मोडेल चतुर एनोटेसनहरू संग झुण्डिएको छ, र कतै पर्दा पछाडि एक बहादुर ORM ले केहि SQL कोड को टन उत्पन्न गर्दछ र कार्यान्वयन गर्दछ। वैसे, विकासकर्ताहरूले आफ्नो डाटाबेसबाट आफूलाई किलोमिटर एब्स्ट्र्याक्सनबाट अलग गर्न सक्दो प्रयास गरिरहेका छन्, जसले केही संकेत गर्दछ। "SQL घृणा".

ब्यारिकेड्सको अर्को छेउमा, शुद्ध "हातले बनाएको" SQL को अनुयायीहरूले अतिरिक्त तहहरू र एब्स्ट्र्याक्सनहरू बिना तिनीहरूको DBMS बाट सबै रस निचोड गर्ने क्षमतालाई नोट गर्छन्। नतिजाको रूपमा, "डेटा-केन्द्रित" परियोजनाहरू देखा पर्दछ, जहाँ विशेष रूपमा प्रशिक्षित व्यक्तिहरू डाटाबेसमा संलग्न हुन्छन् (तिनीहरू "आधारवादीहरू" पनि हुन्, तिनीहरू पनि "आधारवादीहरू" हुन्, तिनीहरू पनि "बेसडेनरहरू" आदि हुन्), र विकासकर्ताहरू। विवरणहरूमा नगईकन तयार भ्यूहरू र भण्डारण गरिएका प्रक्रियाहरू मात्र "पुल" गर्नुपर्छ।

के हुन्छ यदि हामीसँग दुवै संसारको सर्वश्रेष्ठ थियो? यो कसरी जीवन-पुष्टि गर्ने नामको साथ अद्भुत उपकरणमा गरिन्छ Yesql। म मेरो नि: शुल्क अनुवादमा सामान्य अवधारणाबाट केही लाइनहरू दिनेछु, र तपाइँ यसलाई थप विवरणमा परिचित गर्न सक्नुहुन्छ। यहाँ.

Clojure DSL हरू सिर्जना गर्नको लागि एक राम्रो भाषा हो, तर SQL आफैमा एक राम्रो DSL हो, र हामीलाई अर्को आवश्यक छैन। S-अभिव्यक्तिहरू उत्कृष्ट छन्, तर तिनीहरूले यहाँ केही नयाँ थप्दैनन्। नतिजाको रूपमा, हामी कोष्ठकको खातिर कोष्ठकहरू पाउँछौं। सहमत हुनुहुन्न? त्यसोभए त्यो क्षणको लागि पर्खनुहोस् जब डाटाबेसमा एब्स्ट्र्याक्शन लीक हुन थाल्छ र तपाइँ प्रकार्यसँग लड्न थाल्नुहुन्छ। (कच्चा-sql)

त्यसोभए मैले के गर्नुपर्छ? नियमित SQL को रूपमा SQL छोडौं - प्रति अनुरोध एक फाइल:

-- name: users-by-country
select *
  from users
 where country_code = :country_code

... र त्यसपछि यो फाइल पढ्नुहोस्, यसलाई नियमित क्लोजर प्रकार्यमा परिणत गर्दै:

(defqueries "some/where/users_by_country.sql"
   {:connection db-spec})

;;; A function with the name `users-by-country` has been created.
;;; Let's use it:
(users-by-country {:country_code "GB"})
;=> ({:name "Kris" :country_code "GB" ...} ...)

"SQL आफैं, क्लोजर आफैं" सिद्धान्तको पालना गरेर, तपाइँ प्राप्त गर्नुहुन्छ:

• कुनै सिन्ट्याक्टिक आश्चर्य छैन। तपाईको डाटाबेस (कुनै अन्य जस्तै) SQL मानकसँग १००% अनुरूप छैन - तर यसले Yesql को लागि फरक पर्दैन। तपाईले SQL समतुल्य वाक्य रचनाको साथ कार्यहरूको लागि शिकार गर्न समय बर्बाद गर्नुहुने छैन। तपाईंले कहिल्यै समारोहमा फर्किनु पर्दैन (raw-sql "some('funky'::SYNTAX)")).
• उत्तम सम्पादक समर्थन। तपाईंको सम्पादकसँग पहिले नै उत्कृष्ट SQL समर्थन छ। SQL को रूपमा SQL बचत गरेर तपाईं यसलाई प्रयोग गर्न सक्नुहुन्छ।
• टोली अनुकूलता। तपाईंका DBA ले तपाईंले आफ्नो Clojure परियोजनामा ​​प्रयोग गर्नुभएको SQL पढ्न र लेख्न सक्नुहुन्छ।
• सजिलो प्रदर्शन ट्युनिंग। समस्याग्रस्त प्रश्नको लागि योजना निर्माण गर्न आवश्यक छ? तपाईको क्वेरी नियमित SQL हुँदा यो समस्या होइन।
• प्रश्नहरू पुन: प्रयोग गर्दै। ती समान SQL फाइलहरूलाई अन्य परियोजनाहरूमा तान्नुहोस् र छोड्नुहोस् किनभने यो केवल सादा पुरानो SQL हो - यसलाई साझेदारी गर्नुहोस्।

मेरो विचारमा, विचार धेरै राम्रो छ र एकै समयमा धेरै सरल छ, जसको लागि परियोजनाले धेरै कमाएको छ अनुयायीहरू विभिन्न भाषाहरूमा। र हामी अर्को पटक ORM भन्दा टाढाको सबै कुराबाट SQL कोड अलग गर्ने समान दर्शन लागू गर्ने प्रयास गर्नेछौं।

IDE र DB प्रबन्धकहरू

एक साधारण दैनिक कार्य संग सुरु गरौं। प्रायः हामीले डाटाबेसमा केही वस्तुहरू खोज्नुपर्छ, उदाहरणका लागि, स्कीमामा तालिका फेला पार्नुहोस् र यसको संरचना अध्ययन गर्नुहोस् (कुन स्तम्भहरू, कुञ्जीहरू, अनुक्रमणिकाहरू, अवरोधहरू, आदि प्रयोग गरिन्छ)। र कुनै पनि ग्राफिकल IDE वा सानो DB-प्रबन्धकबाट, सबै भन्दा पहिले, हामी यी क्षमताहरू ठ्याक्कै आशा गर्छौं। ताकि यो छिटो छ र आवश्यक जानकारी सहितको सञ्झ्याल (विशेष गरी रिमोट डाटाबेसमा ढिलो जडानको साथ) नआएसम्म तपाईले आधा घण्टा पर्खनु पर्दैन, र एकै समयमा, प्राप्त जानकारी ताजा र सान्दर्भिक छ, र क्यास गरिएको जंक होइन। यसबाहेक, डाटाबेस जति जटिल र ठुलो हुन्छ र तिनीहरूको संख्या जति धेरै हुन्छ, यो गर्न त्यति नै गाह्रो हुन्छ।

तर सामान्यतया म माउस टाढा फाल्छु र कोड लेख्छु। मानौं कि तपाईंले "HR" योजनामा ​​कुन तालिकाहरू (र कुन गुणहरू) समावेश छन् भनेर पत्ता लगाउन आवश्यक छ। धेरै जसो DBMSs मा, जानकारी_schema बाट यो सरल प्रश्नको साथ इच्छित परिणाम प्राप्त गर्न सकिन्छ:

select table_name
     , ...
  from information_schema.tables
 where schema = 'HR'

डाटाबेसबाट डाटाबेसमा, त्यस्ता सन्दर्भ तालिकाहरूको सामग्रीहरू प्रत्येक DBMS को क्षमताहरूको आधारमा भिन्न हुन्छन्। र, उदाहरणका लागि, MySQL को लागि, उही सन्दर्भ पुस्तकबाट तपाईंले यो DBMS को लागि निर्दिष्ट तालिका प्यारामिटरहरू प्राप्त गर्न सक्नुहुन्छ:

select table_name
     , storage_engine -- Используемый "движок" ("MyISAM", "InnoDB" etc)
     , row_format     -- Формат строки ("Fixed", "Dynamic" etc)
     , ...
  from information_schema.tables
 where schema = 'HR'

Oracle लाई information_schema थाहा छैन, तर यो छ ओरेकल मेटाडेटा, र कुनै ठूलो समस्या उत्पन्न हुँदैन:

select table_name
     , pct_free       -- Минимум свободного места в блоке данных (%)
     , pct_used       -- Минимум используемого места в блоке данных (%)
     , last_analyzed  -- Дата последнего сбора статистики
     , ...
  from all_tables
 where owner = 'HR'

ClickHouse कुनै अपवाद छैन:

select name
     , engine -- Используемый "движок" ("MergeTree", "Dictionary" etc)
     , ...
  from system.tables
 where database = 'HR'

क्यासान्ड्रा (जसमा तालिकाको सट्टा स्तम्भ परिवारहरू र स्कीमाको सट्टा कुञ्जी स्थानहरू छन्) मा पनि त्यस्तै गर्न सकिन्छ:

select columnfamily_name
     , compaction_strategy_class  -- Стратегия сборки мусора
     , gc_grace_seconds           -- Время жизни мусора
     , ...
  from system.schema_columnfamilies
 where keyspace_name = 'HR'

धेरै जसो अन्य डाटाबेसहरूको लागि, तपाईं समान प्रश्नहरू पनि ल्याउन सक्नुहुन्छ (मंगोसँग पनि छ विशेष प्रणाली संग्रह, जसले प्रणालीमा भएका सबै सङ्कलनहरूको बारेमा जानकारी समावेश गर्दछ)।

निस्सन्देह, यस तरिकाले तपाईले टेबलको बारेमा मात्र होइन, तर सामान्य रूपमा कुनै पनि वस्तुको बारेमा जानकारी प्राप्त गर्न सक्नुहुन्छ। समय-समयमा, दयालु व्यक्तिहरूले विभिन्न डाटाबेसहरूको लागि त्यस्ता कोडहरू साझेदारी गर्छन्, उदाहरणका लागि, habra लेखहरूको श्रृंखलामा "PostgreSQL डाटाबेसहरू कागजात गर्नका लागि कार्यहरू" (आइब, बेन, जिम)। निस्सन्देह, प्रश्नहरूको यो सम्पूर्ण पहाड मेरो टाउकोमा राख्नु र तिनीहरूलाई लगातार टाइप गर्नु एक खुशीको कुरा हो, त्यसैले मेरो मनपर्ने IDE/सम्पादकमा मसँग प्राय: प्रयोग हुने प्रश्नहरूको लागि स्निपेटहरूको पूर्व-तयार सेट छ, र बाँकी सबै टाइप गर्न हो। टेम्प्लेटमा वस्तु नामहरू।

नतिजाको रूपमा, नेभिगेट गर्ने र वस्तुहरूको खोजी गर्ने यो विधि धेरै लचिलो छ, धेरै समय बचत गर्दछ, र तपाईंलाई अहिले आवश्यक भएको फारममा जानकारी प्राप्त गर्न अनुमति दिन्छ (उदाहरणका लागि, पोष्टमा वर्णन गरिएको। "कुनै पनि ढाँचामा डाटाबेसबाट डाटा निर्यात गर्दै: IntelliJ प्लेटफर्ममा IDE ले के गर्न सक्छ").

वस्तुहरु संग सञ्चालन

हामीले आवश्यक वस्तुहरू फेला पारेपछि र अध्ययन गरिसकेपछि, तिनीहरूसँग उपयोगी केही गर्ने समय हो। स्वाभाविक रूपमा, किबोर्डबाट आफ्नो औंलाहरू नलिई पनि।

यो कुनै गोप्य कुरा छैन कि केवल तालिका मेटाउँदा लगभग सबै डाटाबेसमा समान देखिन्छ:

drop table hr.persons

तर तालिकाको निर्माण संग यो थप रोचक हुन्छ। लगभग कुनै पनि DBMS (धेरै NoSQL सहित) ले एक वा अर्को रूपमा "तालिका सिर्जना" गर्न सक्छ, र यसको मुख्य भाग पनि थोरै फरक हुनेछ (नाम, स्तम्भहरूको सूची, डेटा प्रकारहरू), तर अन्य विवरणहरू नाटकीय रूपमा फरक हुन सक्छ र निर्भर गर्दछ। आन्तरिक उपकरण र विशिष्ट DBMS को क्षमताहरू। मेरो मनपर्ने उदाहरण यो हो कि ओरेकल कागजातमा "तालिका सिर्जना गर्नुहोस्" सिन्ट्याक्सको लागि केवल "नग्न" BNF हरू छन्। 31 पृष्ठहरू कब्जा। अन्य DBMS हरूमा धेरै सामान्य क्षमताहरू छन्, तर तिनीहरूमध्ये प्रत्येकसँग तालिकाहरू सिर्जना गर्नका लागि धेरै रोचक र अद्वितीय सुविधाहरू छन् (पोस्टगेज, MySQL, काकरोच, क्यासान्ड्रा)। यो सम्भव छैन कि अर्को IDE (विशेष गरी एक विश्वव्यापी) को कुनै पनि ग्राफिकल "विजार्ड" ले यी सबै क्षमताहरूलाई पूर्ण रूपमा कभर गर्न सक्षम हुनेछ, र यदि यो सम्भव छ भने, यो हृदयको बेहोशको लागि तमाशा हुनेछैन। एकै समयमा, सही र समयमै लिखित कथन तालिका सिर्जना गर्नुहोस् तपाईंलाई ती सबै सजिलै प्रयोग गर्न, भण्डारण र तपाईंको डाटामा पहुँचलाई भरपर्दो, इष्टतम र सम्भव भएसम्म सहज बनाउन अनुमति दिनेछ।

साथै, धेरै DBMS हरूको आफ्नै विशिष्ट प्रकारका वस्तुहरू छन् जुन अन्य DBMS मा उपलब्ध छैनन्। यसबाहेक, हामी डाटाबेस वस्तुहरूमा मात्र नभई DBMS मा पनि कार्यहरू गर्न सक्छौं, उदाहरणका लागि, कुनै प्रक्रियालाई "मार्नुहोस्", केही मेमोरी क्षेत्र खाली गर्नुहोस्, ट्रेसिङ सक्षम गर्नुहोस्, "पढ्ने मात्र" मोडमा स्विच गर्नुहोस्, र धेरै धेरै।

अब थोरै कोर्न गरौं

सबै भन्दा साधारण कार्यहरू मध्ये एक डाटाबेस वस्तुहरु संग एक रेखाचित्र निर्माण गर्न र एक सुन्दर तस्वीर मा वस्तुहरु र उनीहरु बीच जडान हेर्न को लागी छ। लगभग कुनै पनि ग्राफिकल IDE, अलग "कमांड लाइन" उपयोगिताहरू, विशेष ग्राफिकल उपकरणहरू र मोडेलरहरूले यो गर्न सक्छन्। तिनीहरूले तपाइँको लागि "उनीहरूले सकेसम्म राम्रो" केहि कोर्नेछन्, र तपाइँ कन्फिगरेसन फाइल वा इन्टरफेसमा चेकबक्सहरूमा केही प्यारामिटरहरूको मद्दतले मात्र यो प्रक्रियालाई प्रभाव पार्न सक्नुहुन्छ।

तर यो समस्या धेरै सरल, थप लचिलो र सुरुचिपूर्ण, र पक्कै पनि कोड को मद्दतले हल गर्न सकिन्छ। कुनै पनि जटिलताको रेखाचित्रहरू सिर्जना गर्न, हामीसँग धेरै विशेष मार्कअप भाषाहरू (DOT, GraphML आदि) छन्, र तिनीहरूका लागि अनुप्रयोगहरूको सम्पूर्ण बिखर्ने (GraphViz, PlantUML, Mermaid) जसले त्यस्ता निर्देशनहरू पढ्न र तिनीहरूलाई विभिन्न ढाँचाहरूमा कल्पना गर्न सक्छ। । ठिक छ, हामीलाई पहिले नै थाहा छ कि कसरी वस्तुहरू र तिनीहरू बीचको जडानहरूको बारेमा जानकारी प्राप्त गर्ने।

PlantUML प्रयोग गरेर यो कस्तो देखिन सक्छ भन्ने एउटा सानो उदाहरण यहाँ छ PostgreSQL को लागि डेमो डाटाबेस (बाँयामा SQL क्वेरी हो जसले PlantUML को लागि आवश्यक निर्देशनहरू उत्पन्न गर्नेछ, र दायाँमा परिणाम छ):

select '@startuml'||chr(10)||'hide methods'||chr(10)||'hide stereotypes' union all
select distinct ccu.table_name || ' --|> ' ||
       tc.table_name as val
  from table_constraints as tc
  join key_column_usage as kcu
    on tc.constraint_name = kcu.constraint_name
  join constraint_column_usage as ccu
    on ccu.constraint_name = tc.constraint_name
 where tc.constraint_type = 'FOREIGN KEY'
   and tc.table_name ~ '.*' union all
select '@enduml'

र यदि तपाइँ एक सानो प्रयास गर्नुहुन्छ, त्यसपछि आधारित PlantUML को लागि ER टेम्प्लेट तपाईले वास्तविक ER रेखाचित्र जस्तै केहि प्राप्त गर्न सक्नुहुन्छ:

SQL क्वेरी अलि बढी जटिल छ

-- Шапка
select '@startuml
        !define Table(name,desc) class name as "desc" << (T,#FFAAAA) >>
        !define primary_key(x) <b>x</b>
        !define unique(x) <color:green>x</color>
        !define not_null(x) <u>x</u>
        hide methods
        hide stereotypes'
 union all
-- Таблицы
select format('Table(%s, "%s n information about %s") {'||chr(10), table_name, table_name, table_name) ||
       (select string_agg(column_name || ' ' || upper(udt_name), chr(10))
          from information_schema.columns
         where table_schema = 'public'
           and table_name = t.table_name) || chr(10) || '}'
  from information_schema.tables t
 where table_schema = 'public'
 union all
-- Связи между таблицами
select distinct ccu.table_name || ' "1" --> "0..N" ' || tc.table_name || format(' : "A %s may haven many %s"', ccu.table_name, tc.table_name)
  from information_schema.table_constraints as tc
  join information_schema.key_column_usage as kcu on tc.constraint_name = kcu.constraint_name
  join information_schema.constraint_column_usage as ccu on ccu.constraint_name = tc.constraint_name
 where tc.constraint_type = 'FOREIGN KEY'
   and ccu.constraint_schema = 'public'
   and tc.table_name ~ '.*'
 union all
-- Подвал
select '@enduml'

यदि तपाइँ नजिकबाट हेर्नुभयो भने, हुड अन्तर्गत धेरै दृश्य उपकरणहरूले पनि समान प्रश्नहरू प्रयोग गर्छन्। हो, यी अनुरोधहरू सामान्यतया गहिरो हुन्छन् अनुप्रयोगको कोडमा "हार्डवायर" र बुझ्न गाह्रो छ, तिनीहरूको कुनै परिमार्जन उल्लेख नगर्नुहोस्।

मेट्रिक्स र निगरानी

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

तर अनुगमन प्रक्रिया धेरै रमाइलो र मैत्रीपूर्ण देखिन सक्छ, र सबैभन्दा महत्त्वपूर्ण, सबैका लागि पहुँचयोग्य र पारदर्शी। कम्तिमा यसको आधारभूत भाग, मुख्य अनुगमन प्रणालीहरूमा थपको रूपमा (जुन निश्चित रूपमा उपयोगी छन् र धेरै अवस्थामा अपरिवर्तनीय छन्)। कुनै पनि DBMS यसको हालको अवस्था र कार्यसम्पादनको बारेमा जानकारी साझा गर्न स्वतन्त्र रूपमा र बिल्कुल नि: शुल्क छ। उही "रक्तरूपी" ओरेकल DB मा, कार्यसम्पादनको बारेमा लगभग कुनै पनि जानकारी प्रणाली दृश्यहरूबाट प्राप्त गर्न सकिन्छ, प्रक्रियाहरू र सत्रहरूदेखि बफर क्यासको अवस्थासम्म (उदाहरणका लागि, DBA लिपिहरू, खण्ड "निगरानी")। Postgresql सँग पनि प्रणाली दृश्यहरूको सम्पूर्ण गुच्छा छ डाटाबेस निगरानी, विशेष गरी जुन कुनै पनि DBA को दैनिक जीवनमा अपरिहार्य छ, जस्तै pg_stat_activity, pg_stat_database, pg_stat_bgwriter। MySQL सँग यसको लागि छुट्टै स्कीमा पनि छ। प्रदर्शन_स्कीमा। A In Mongo बिल्ट-इन प्रोफाइलर प्रणाली सङ्कलनमा कार्यसम्पादन डेटा जम्मा गर्छ system.profile.

यसरी, कस्टम sql क्वेरीहरू प्रदर्शन गर्न सक्ने मेट्रिक्स कलेक्टर (Telegraf, Metricbeat, Collectd) को केही प्रकारले सशस्त्र, यी मेट्रिक्सको भण्डारण (InfluxDB, Elasticsearch, Timescaledb) र एक भिजुअलाइजर (Grafana, Kibana), तपाईं एकदम सजिलो प्राप्त गर्न सक्नुहुन्छ। र एक लचिलो निगरानी प्रणाली जुन अन्य प्रणाली-व्यापी मेट्रिक्स (उदाहरणका लागि, अनुप्रयोग सर्भरबाट, OS बाट, इत्यादि प्राप्त गरिएको) सँग नजिकबाट एकीकृत हुनेछ। जस्तै, उदाहरणका लागि, यो pgwatch2 मा गरिन्छ, जसले InfluxDB + Grafana संयोजन र प्रणाली दृश्यहरूमा प्रश्नहरूको सेट प्रयोग गर्दछ, जुन पहुँच गर्न सकिन्छ। अनुकूलन प्रश्नहरू थप्नुहोस्.

कुल

र यो नियमित SQL कोड प्रयोग गरेर हाम्रो डाटाबेससँग के गर्न सकिन्छ भन्ने अनुमानित सूची मात्र हो। म पक्का छु कि तपाईले धेरै प्रयोगहरू फेला पार्न सक्नुहुन्छ, टिप्पणीहरूमा लेख्नुहोस्। र हामी कसरी (र सबैभन्दा महत्त्वपूर्ण कुरा किन) यी सबैलाई स्वचालित गर्ने र अर्को पटक तपाईंको CI/CD पाइपलाइनमा समावेश गर्ने बारे कुरा गर्नेछौं।

स्रोत: www.habr.com