"कोड म्हणून डेटाबेस" अनुभव

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

आणि आतापासून सुरुवात करूया ओआरएम. "SQL vs 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. मी माझ्या विनामूल्य भाषांतरात सामान्य संकल्पनेतील काही ओळी देईन आणि आपण त्याबद्दल अधिक तपशीलवार परिचित होऊ शकता येथे.

DSL तयार करण्यासाठी Clojure ही एक छान भाषा आहे, परंतु SQL स्वतःच एक छान DSL आहे आणि आम्हाला दुसरी गरज नाही. एस-अभिव्यक्ती उत्तम आहेत, परंतु ते येथे काहीही नवीन जोडत नाहीत. परिणामी, आम्हाला कंसाच्या फायद्यासाठी कंस मिळतात. मान्य नाही? मग त्या क्षणाची प्रतीक्षा करा जेव्हा डेटाबेसवरील अ‍ॅब्स्ट्रॅक्शन लीक होण्यास सुरुवात होते आणि तुम्ही फंक्शनशी लढायला सुरुवात करता. (raw-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 मानकाशी १००% अनुरूप नाही - परंतु Yesql साठी हे काही फरक पडत नाही. SQL समतुल्य वाक्यरचना असलेल्या फंक्शन्सच्या शोधात तुम्ही कधीही वेळ वाया घालवणार नाही. तुम्हाला कधीही फंक्शनवर परत जावे लागणार नाही (raw-sql "some('funky'::SYNTAX)")).
• सर्वोत्तम संपादक समर्थन. तुमच्या संपादकाला आधीपासूनच उत्कृष्ट SQL सपोर्ट आहे. SQL म्हणून SQL सेव्ह करून तुम्ही ते सहजपणे वापरू शकता.
• संघ सुसंगतता. तुमचे DBA तुम्ही तुमच्या Clojure प्रोजेक्टमध्ये वापरत असलेले SQL वाचू आणि लिहू शकतात.
• सोपे कार्यप्रदर्शन ट्यूनिंग. समस्याप्रधान क्वेरीसाठी योजना तयार करण्याची आवश्यकता आहे? तुमची क्वेरी नियमित SQL असते तेव्हा ही समस्या नसते.
• क्वेरी पुन्हा वापरत आहे. त्याच SQL फाइल्स इतर प्रोजेक्टमध्ये ड्रॅग करा आणि ड्रॉप करा कारण ते अगदी साधे जुने SQL आहे - फक्त ते शेअर करा.

माझ्या मते, कल्पना खूप छान आहे आणि त्याच वेळी अगदी सोपी आहे, ज्यामुळे प्रकल्पाने बरेच काही मिळवले आहे अनुयायी विविध भाषांमध्ये. आणि आम्ही पुढे ORM च्या पलीकडे असलेल्या इतर सर्व गोष्टींपासून SQL कोड वेगळे करण्याचे समान तत्वज्ञान लागू करण्याचा प्रयत्न करू.

IDE आणि DB व्यवस्थापक

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

पण सहसा मी उंदीर फेकून देतो आणि फक्त कोड लिहितो. समजा तुम्हाला "एचआर" स्कीमामध्ये कोणती टेबल्स (आणि कोणत्या गुणधर्मांसह) आहेत हे शोधण्याची आवश्यकता आहे. बर्‍याच DBMS मध्ये, माहिती_स्कीमाच्या या सोप्या क्वेरीसह इच्छित परिणाम प्राप्त केला जाऊ शकतो:

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'

ओरॅकलला ​​माहिती_स्कीमा माहित नाही, परंतु त्याच्याकडे आहे ओरॅकल मेटाडेटा, आणि कोणतीही मोठी समस्या उद्भवत नाही:

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

क्लिकहाऊस अपवाद नाही:

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'

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

अर्थात, अशा प्रकारे आपण केवळ सारण्यांबद्दलच नाही तर सर्वसाधारणपणे कोणत्याही वस्तूबद्दल माहिती मिळवू शकता. वेळोवेळी, दयाळू लोक वेगवेगळ्या डेटाबेससाठी असे कोड सामायिक करतात, उदाहरणार्थ, हॅब्रा लेखांच्या मालिकेत "पोस्टग्रेएसक्यूएल डेटाबेसेसचे दस्तऐवजीकरण करण्यासाठी कार्ये" (आयबी, बेन, व्यायामशाळा). अर्थात, प्रश्नांचा हा संपूर्ण डोंगर माझ्या डोक्यात ठेवणे आणि ते सतत टाइप करणे खूप आनंददायक आहे, म्हणून माझ्या आवडत्या IDE/संपादकांमध्ये माझ्याकडे वारंवार वापरल्या जाणार्‍या प्रश्नांसाठी स्निपेट्सचा एक पूर्व-तयार संच आहे आणि बाकी फक्त टाईप करणे आहे. टेम्प्लेटमध्ये ऑब्जेक्टची नावे.

परिणामी, नेव्हिगेट करण्याची आणि ऑब्जेक्ट्स शोधण्याची ही पद्धत अधिक लवचिक आहे, बराच वेळ वाचवते आणि आपल्याला आता आवश्यक असलेल्या फॉर्ममध्ये अचूक माहिती मिळविण्याची परवानगी देते (उदाहरणार्थ, पोस्टमध्ये वर्णन केल्याप्रमाणे "कोणत्याही स्वरूपात डेटाबेसमधून डेटा निर्यात करणे: IntelliJ प्लॅटफॉर्मवर IDE काय करू शकतात").

ऑब्जेक्ट्ससह ऑपरेशन्स

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

हे गुपित नाही की फक्त सारणी हटवणे जवळजवळ सर्व डेटाबेसमध्ये समान दिसेल:

drop table hr.persons

परंतु टेबलच्या निर्मितीसह ते अधिक मनोरंजक बनते. जवळजवळ कोणताही DBMS (अनेक NoSQL सह) एका किंवा दुसर्‍या स्वरूपात "टेबल तयार" करू शकतो आणि त्याचा मुख्य भाग अगदी थोडा वेगळा असेल (नाव, स्तंभांची सूची, डेटा प्रकार), परंतु इतर तपशील नाटकीयरित्या भिन्न असू शकतात आणि त्यावर अवलंबून असतात. अंतर्गत डिव्हाइस आणि विशिष्ट DBMS च्या क्षमता. माझे आवडते उदाहरण म्हणजे ओरॅकल डॉक्युमेंटेशनमध्ये "टेबल तयार करा" सिंटॅक्ससाठी फक्त "नग्न" BNF आहेत 31 पृष्ठे व्यापा. इतर डीबीएमएसमध्ये अधिक माफक क्षमता आहेत, परंतु त्या प्रत्येकामध्ये टेबल तयार करण्यासाठी अनेक मनोरंजक आणि अद्वितीय वैशिष्ट्ये देखील आहेत (पोस्टग्रेस, mysql, झुरळ, कॅसॅन्ड्रा). दुसर्‍या IDE (विशेषत: एक सार्वत्रिक) मधील कोणताही ग्राफिकल “विझार्ड” या सर्व क्षमता पूर्णपणे कव्हर करण्यास सक्षम असेल, आणि जरी ते शक्य असले तरी, हृदयाच्या अशक्तांसाठी ते एक तमाशा होणार नाही. त्याच वेळी, योग्य आणि वेळेवर लिखित विधान टेबल तयार करा तुम्हाला ते सर्व सहजपणे वापरण्याची, स्टोरेज आणि तुमच्या डेटामध्ये प्रवेश करण्यासाठी विश्वसनीय, इष्टतम आणि शक्य तितक्या आरामदायी बनविण्याची अनुमती देईल.

तसेच, अनेक 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 टेम्पलेट आपण वास्तविक ईआर आकृतीसारखे काहीतरी मिळवू शकता:

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'

आपण बारकाईने पाहिल्यास, हुड अंतर्गत अनेक व्हिज्युअलायझेशन साधने देखील समान क्वेरी वापरतात. खरे आहे, या विनंत्या सहसा सखोल असतात अनुप्रयोगाच्या कोडमध्येच "हार्डवायर्ड" आणि समजणे कठीण आहे, त्यांच्यातील कोणत्याही बदलाचा उल्लेख नाही.

मेट्रिक्स आणि मॉनिटरिंग

चला पारंपारिकरित्या जटिल विषयाकडे जाऊया - डेटाबेस कार्यप्रदर्शन मॉनिटरिंग. मला "माझ्या एका मित्राने" सांगितलेली एक छोटीशी सत्यकथा आठवते. दुसर्‍या प्रोजेक्टवर एक विशिष्ट शक्तिशाली डीबीए राहत होता आणि काही विकसकांनी त्याला वैयक्तिकरित्या ओळखले होते किंवा त्याने कधीही त्याला वैयक्तिकरित्या पाहिले होते (अफवांनुसार, त्याने पुढच्या इमारतीत कुठेतरी काम केले असले तरीही). “X” वाजता, जेव्हा मोठ्या किरकोळ विक्रेत्याची पॉडक्शन सिस्टम पुन्हा एकदा “वाईट वाटू लागली” तेव्हा त्याने शांतपणे ओरॅकल एंटरप्राइझ मॅनेजरकडून आलेखांचे स्क्रीनशॉट पाठवले, ज्यावर त्याने गंभीर ठिकाणे “समजण्यायोग्यता” साठी लाल मार्करने काळजीपूर्वक हायलाइट केली ( हे, सौम्यपणे सांगायचे तर, जास्त मदत झाली नाही). आणि या "फोटो कार्ड" च्या आधारे मला उपचार करावे लागले. त्याच वेळी, मौल्यवान (शब्दाच्या दोन्ही अर्थाने) एंटरप्राइज मॅनेजरमध्ये कोणालाही प्रवेश नव्हता, कारण प्रणाली जटिल आणि महाग आहे, अचानक "विकासक काहीतरी अडखळतात आणि सर्वकाही खंडित करतात." म्हणून, विकसकांना "अनुभवाने" ब्रेकचे स्थान आणि कारण सापडले आणि एक पॅच सोडला. नजीकच्या भविष्यात डीबीएचे धोकादायक पत्र पुन्हा आले नाही, तर प्रत्येकजण सुटकेचा नि:श्वास टाकेल आणि त्यांच्या सध्याच्या कामांवर परत येईल (नवीन पत्र येईपर्यंत).

परंतु निरीक्षण प्रक्रिया अधिक मनोरंजक आणि अनुकूल दिसू शकते आणि सर्वात महत्त्वाचे म्हणजे प्रत्येकासाठी प्रवेशयोग्य आणि पारदर्शक असू शकते. कमीत कमी त्याचा मूलभूत भाग, मुख्य मॉनिटरिंग सिस्टीममध्ये एक जोड म्हणून (जे नक्कीच उपयुक्त आहेत आणि बर्याच बाबतीत न भरता येणारे). कोणतीही DBMS त्याच्या वर्तमान स्थितीबद्दल आणि कार्यप्रदर्शनाबद्दल माहिती सामायिक करण्यासाठी विनामूल्य आणि पूर्णपणे विनामूल्य आहे. त्याच "रक्तरंजित" ओरॅकल डीबीमध्ये, कार्यप्रदर्शनाबद्दल जवळजवळ कोणतीही माहिती सिस्टम दृश्यांमधून प्राप्त केली जाऊ शकते, प्रक्रिया आणि सत्रांपासून बफर कॅशेच्या स्थितीपर्यंत (उदाहरणार्थ, DBA स्क्रिप्ट, विभाग "निरीक्षण"). Postgresql मध्ये सिस्टम दृश्यांचा संपूर्ण समूह देखील आहे डेटाबेस निरीक्षण, विशेषतः जे कोणत्याही DBA च्या दैनंदिन जीवनात अपरिहार्य आहेत, जसे की pg_stat_activity, pg_stat_database, pg_stat_bgwriter. MySQL कडे यासाठी वेगळा स्कीमा देखील आहे. कामगिरी_स्कीमा. ए इन मोंगो अंगभूत प्रोफाइलर कार्यप्रदर्शन डेटा सिस्टम संग्रहामध्ये एकत्रित करते system.profile.

अशाप्रकारे, काही प्रकारचे मेट्रिक्स कलेक्टर (टेलीग्राफ, मेट्रिकबीट, कलेक्टेड) ​​जे सानुकूल sql क्वेरी करू शकतात, या मेट्रिक्सचे स्टोरेज (InfluxDB, Elasticsearch, Timescaledb) आणि व्हिज्युअलायझर (Grafana, Kibana) सह सशस्त्र, तुम्ही अगदी सहज मिळवू शकता. आणि एक लवचिक मॉनिटरिंग सिस्टम जी इतर सिस्टम-व्यापी मेट्रिक्ससह जवळून एकत्रित केली जाईल (मिळवलेले, उदाहरणार्थ, ऍप्लिकेशन सर्व्हरवरून, OS वरून इ.). उदाहरणार्थ, हे pgwatch2 मध्ये केले जाते, जे InfluxDB + Grafana संयोजन वापरते आणि सिस्टम दृश्यांसाठी प्रश्नांचा संच, ज्यामध्ये प्रवेश देखील केला जाऊ शकतो. सानुकूल क्वेरी जोडा.

एकूण

आणि नियमित SQL कोड वापरून आमच्या डेटाबेससह काय केले जाऊ शकते याची ही फक्त अंदाजे यादी आहे. मला खात्री आहे की तुम्हाला आणखी बरेच उपयोग सापडतील, टिप्पण्यांमध्ये लिहा. आणि हे सर्व कसे स्वयंचलित करायचे आणि पुढच्या वेळी ते तुमच्या CI/CD पाइपलाइनमध्ये कसे समाविष्ट करायचे (आणि सर्वात महत्त्वाचे का) याबद्दल आम्ही बोलू.

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