"მონაცემთა ბაზა როგორც კოდი" გამოცდილება

SQL, რა შეიძლება იყოს უფრო მარტივი? თითოეულ ჩვენგანს შეუძლია დაწეროს მარტივი მოთხოვნა - ჩვენ ვბეჭდავთ აირჩიეთ, ჩამოთვალეთ საჭირო სვეტები, შემდეგ საწყისი, ცხრილის დასახელება, გარკვეული პირობები სადაც და ეს ყველაფერი - სასარგებლო მონაცემები ჩვენს ჯიბეშია და (თითქმის) იმისდა მიუხედავად, თუ რომელი DBMS არის ამ დროს კაპოტის ქვეშ (ან შესაძლოა საერთოდ არ არის DBMS). შედეგად, თითქმის ნებისმიერ მონაცემთა წყაროსთან მუშაობა (რელატიური და არც ისე) შეიძლება ჩაითვალოს ჩვეულებრივი კოდის თვალსაზრისით (ყველაფერს, რაც გულისხმობს - ვერსიის კონტროლი, კოდის მიმოხილვა, სტატიკური ანალიზი, ავტოტესტები და ეს ყველაფერი). და ეს ეხება არა მხოლოდ თავად მონაცემებს, სქემებსა და მიგრაციას, არამედ ზოგადად შენახვის მთელ სიცოცხლეს. ამ სტატიაში ვისაუბრებთ ყოველდღიურ ამოცანებზე და სხვადასხვა მონაცემთა ბაზებთან მუშაობის პრობლემებზე „მონაცემთა ბაზა როგორც კოდის“ ქვეშ.

და დავიწყოთ პირდაპირ ORM. "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. ჩემს თავისუფალ თარგმანში ზოგადი კონცეფციიდან რამდენიმე სტრიქონს მოგცემთ და შეგიძლიათ უფრო დეტალურად გაეცნოთ მას აქ.

Clojure მაგარი ენაა DSL-ების შესაქმნელად, მაგრამ თავად SQL არის მაგარი DSL და სხვა არ გვჭირდება. S-გამონათქვამები შესანიშნავია, მაგრამ ისინი აქ ახალს არ ამატებენ. შედეგად ვიღებთ ფრჩხილებს ფრჩხილების გულისთვის. Არ ვეთანხმები? შემდეგ დაელოდეთ მომენტს, როდესაც მონაცემთა ბაზის აბსტრაქცია დაიწყებს გაჟონვას და დაიწყებთ ბრძოლას ფუნქციასთან (raw-sql)

მერე რა უნდა გავაკეთო? მოდით დავტოვოთ SQL, როგორც ჩვეულებრივი SQL - ერთი ფაილი თითო მოთხოვნაზე:

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

... და შემდეგ წაიკითხეთ ეს ფაილი, გადააქციეთ ის ჩვეულებრივ Clojure ფუნქციად:

(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 თავისთავად, Clojure თავისთავად" პრინციპის დაცვით, თქვენ მიიღებთ:

• არანაირი სინტაქსური სიურპრიზები. თქვენი მონაცემთა ბაზა (როგორც ნებისმიერი სხვა) არ შეესაბამება SQL სტანდარტს 100%-ით - მაგრამ Yesql-სთვის ამას მნიშვნელობა არ აქვს. თქვენ არასოდეს დაკარგავთ დროს SQL ექვივალენტური სინტაქსით ფუნქციებზე ნადირობისთვის. თქვენ არასოდეს მოგიწევთ ფუნქციაზე დაბრუნება (raw-sql "some('funky'::SYNTAX)")).
• საუკეთესო რედაქტორის მხარდაჭერა. თქვენს რედაქტორს უკვე აქვს შესანიშნავი SQL მხარდაჭერა. SQL-ის SQL-ად შენახვით შეგიძლიათ უბრალოდ გამოიყენოთ იგი.
• გუნდის თავსებადობა. თქვენს DBA-ებს შეუძლიათ წაიკითხონ და დაწერონ SQL, რომელსაც იყენებთ Clojure პროექტში.
• შესრულების უფრო მარტივი რეგულირება. გჭირდებათ გეგმის შედგენა პრობლემური შეკითხვისთვის? ეს არ არის პრობლემა, როდესაც თქვენი მოთხოვნა არის რეგულარული SQL.
• შეკითხვის ხელახლა გამოყენება. გადაათრიეთ და ჩამოაგდეთ იგივე SQL ფაილები სხვა პროექტებში, რადგან ის უბრალოდ ძველი SQLა - უბრალოდ გააზიარეთ.

ჩემი აზრით, იდეა ძალიან მაგარი და ამავდროულად ძალიან მარტივია, რის წყალობითაც პროექტმა ბევრი მოიპოვა მიმდევრები სხვადასხვა ენაზე. შემდეგ ჩვენ შევეცდებით გამოვიყენოთ SQL კოდის გამოყოფის მსგავსი ფილოსოფია ყველაფრისგან ORM-ის მიღმა.

IDE & DB მენეჯერები

დავიწყოთ მარტივი ყოველდღიური დავალებით. ხშირად გვიწევს მონაცემთა ბაზაში ზოგიერთი ობიექტის ძებნა, მაგალითად, სქემაში ცხრილის პოვნა და მისი სტრუქტურის შესწავლა (რა სვეტები, კლავიშები, ინდექსები, შეზღუდვები და ა.შ. გამოიყენება). და ნებისმიერი გრაფიკული IDE ან პატარა DB-მენეჯერისგან, პირველ რიგში, ჩვენ ველით ზუსტად ამ შესაძლებლობებს. ისე, რომ ეს იყოს სწრაფი და არ დაგჭირდეთ ნახევარი საათის ლოდინი საჭირო ინფორმაციის ფანჯრის დახატვამდე (განსაკუთრებით დისტანციურ მონაცემთა ბაზასთან ნელი კავშირით) და ამავდროულად, მიღებული ინფორმაცია იყოს ახალი და შესაბამისი, და არა ქეშირებული უსარგებლო. უფრო მეტიც, რაც უფრო რთული და დიდია მონაცემთა ბაზა და რაც უფრო დიდია მათი რაოდენობა, მით უფრო რთულია ამის გაკეთება.

მაგრამ, როგორც წესი, მაუსს ვყრი და მხოლოდ კოდს ვწერ. ვთქვათ, თქვენ უნდა გაარკვიოთ, რომელი ცხრილები (და რომელი თვისებებით) შეიცავს "HR" სქემას. უმეტეს 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'

Oracle-მა არ იცის information_schema, მაგრამ აქვს Oracle-ის მეტამონაცემებიდა დიდი პრობლემები არ წარმოიქმნება:

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'

სხვა მონაცემთა ბაზების უმეტესობისთვის, თქვენ ასევე შეგიძლიათ მსგავსი მოთხოვნების დაყენება (მონგოსაც კი აქვს სპეციალური სისტემის კოლექცია, რომელიც შეიცავს ინფორმაციას სისტემის ყველა კოლექციის შესახებ).

რა თქმა უნდა, ამ გზით შეგიძლიათ მიიღოთ ინფორმაცია არა მხოლოდ ცხრილების, არამედ ზოგადად ნებისმიერი ობიექტის შესახებ. დროდადრო, კეთილი ადამიანები იზიარებენ ისეთ კოდს სხვადასხვა მონაცემთა ბაზებისთვის, როგორიცაა, მაგალითად, ჰაბრა სტატიების სერიაში "PostgreSQL მონაცემთა ბაზების დოკუმენტაციის ფუნქციები" (აიბ, ბინ, სპორტ - დარბაზი). რა თქმა უნდა, მთელი ამ მთის შეკითხვის თავში შენარჩუნება და მათი გამუდმებით აკრეფა დიდი სიამოვნებაა, ამიტომ ჩემს საყვარელ IDE/რედაქტორში მაქვს წინასწარ მომზადებული ფრაგმენტების ნაკრები ხშირად გამოყენებული შეკითხვებისთვის, და რჩება მხოლოდ აკრიფეთ ობიექტების სახელები შაბლონში.

შედეგად, ობიექტების ნავიგაციისა და ძიების ეს მეთოდი ბევრად უფრო მოქნილია, დაზოგავს დიდ დროს და საშუალებას გაძლევთ მიიღოთ ზუსტად ინფორმაცია იმ ფორმით, რომელშიც ეს ახლა აუცილებელია (როგორც, მაგალითად, აღწერილია პოსტში "მონაცემების ექსპორტი მონაცემთა ბაზიდან ნებისმიერი ფორმატით: რისი გაკეთება შეუძლიათ IDE-ებს IntelliJ პლატფორმაზე").

ოპერაციები ობიექტებთან

მას შემდეგ რაც ვიპოვნეთ და შევისწავლეთ საჭირო ობიექტები, დროა გავაკეთოთ რაიმე სასარგებლო მათთან. ბუნებრივია, ასევე კლავიატურაზე თითების მოხსნის გარეშე.

საიდუმლო არ არის, რომ ცხრილის უბრალოდ წაშლა ერთნაირად გამოიყურება თითქმის ყველა მონაცემთა ბაზაში:

drop table hr.persons

მაგრამ ცხრილის შექმნით ის უფრო საინტერესო ხდება. თითქმის ნებისმიერ DBMS-ს (მათ შორის ბევრი NoSQL) შეუძლია „შექმნას ცხრილი“ ამა თუ იმ ფორმით და მისი ძირითადი ნაწილი ოდნავ განსხვავდება (სახელი, სვეტების სია, მონაცემთა ტიპები), მაგრამ სხვა დეტალები შეიძლება მკვეთრად განსხვავდებოდეს და დამოკიდებულია იმაზე. შიდა მოწყობილობა და კონკრეტული DBMS-ის შესაძლებლობები. ჩემი საყვარელი მაგალითია ის, რომ Oracle-ის დოკუმენტაციაში არის მხოლოდ „შიშველი“ BNF-ები „შექმნა ცხრილის“ სინტაქსისთვის. იკავებს 31 გვერდს. სხვა DBMS-ებს აქვთ უფრო მოკრძალებული შესაძლებლობები, მაგრამ თითოეულ მათგანს ასევე აქვს მრავალი საინტერესო და უნიკალური თვისება ცხრილების შესაქმნელად (პოსტგრამა, mysql, ტარაკანი, cassandra). ნაკლებად სავარაუდოა, რომ რომელიმე გრაფიკულმა „ოსტატმა“ სხვა 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'

და თუ ცოტას ცდილობ, მაშინ საფუძველზე ER შაბლონი 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'

თუ კარგად დააკვირდებით, ვიზუალიზაციის მრავალი ინსტრუმენტი ასევე იყენებს მსგავს შეკითხვებს. მართალია, ეს მოთხოვნები ჩვეულებრივ ღრმაა "მყარად ჩართული" თავად აპლიკაციის კოდში და ძნელი გასაგებია, რომ აღარაფერი ვთქვათ მათ რაიმე ცვლილებაზე.

მეტრიკა და მონიტორინგი

გადავიდეთ ტრადიციულად რთულ თემაზე - მონაცემთა ბაზის მუშაობის მონიტორინგი. მახსოვს პატარა ნამდვილი ამბავი, რომელიც მომიყვა „ერთმა ჩემმა მეგობარმა“. სხვა პროექტზე ცხოვრობდა გარკვეული ძლიერი DBA და რამდენიმე დეველოპერმა მას პირადად იცნობდა ან ოდესმე უნახავს პირადად (მიუხედავად იმისა, რომ, ჭორების თანახმად, ის მუშაობდა სადღაც შემდეგ კორპუსში). "X" საათზე, როდესაც დიდი საცალო ვაჭრობის საწარმოს სისტემამ კიდევ ერთხელ დაიწყო "ცუდად გრძნობა", მან ჩუმად გამოაგზავნა გრაფიკების სკრინშოტები Oracle Enterprise Manager-ისგან, რომლებზეც მან ყურადღებით ხაზგასმით ხაზგასმით ხაზგასმით ხაზგასმით აღნიშნა კრიტიკული ადგილები წითელი მარკერით "გასაგებად" ( ეს, რბილად რომ ვთქვათ, დიდად არ დაეხმარა). და ამ "ფოტო ბარათის" საფუძველზე მომიწია მკურნალობა. ამავდროულად, არავის ჰქონდა წვდომა ძვირფას (ამ სიტყვის ორივე მნიშვნელობით) საწარმოს მენეჯერთან, რადგან სისტემა რთული და ძვირია, უცებ „დეველოპერები რაღაცას წააწყდებიან და ყველაფერს არღვევენ“. ამიტომ, დეველოპერებმა "ემპირიულად" იპოვეს მუხრუჭების ადგილმდებარეობა და მიზეზი და გამოუშვეს პაჩი. თუ DBA-ს მუქარის წერილი უახლოეს მომავალში აღარ ჩამოვიდოდა, მაშინ ყველა შვებით ამოისუნთქავდა და დაუბრუნდებოდა თავის ამჟამინდელ ამოცანებს (ახალ წერილამდე).

მაგრამ მონიტორინგის პროცესი შეიძლება გამოიყურებოდეს უფრო სახალისო და მეგობრული, და რაც მთავარია, ყველასთვის ხელმისაწვდომი და გამჭვირვალე. მისი ძირითადი ნაწილი მაინც, როგორც ძირითადი მონიტორინგის სისტემების დამატება (რაც რა თქმა უნდა სასარგებლო და ხშირ შემთხვევაში შეუცვლელია). ნებისმიერი DBMS თავისუფლად და აბსოლუტურად უფასოა ინფორმაციის გასაზიარებლად მისი ამჟამინდელი მდგომარეობისა და მუშაობის შესახებ. იმავე „სისხლიან“ Oracle DB-ში, მუშაობის შესახებ თითქმის ნებისმიერი ინფორმაციის მიღება შესაძლებელია სისტემის ხედებიდან, დაწყებული პროცესებიდან და სესიებიდან ბუფერული ქეშის მდგომარეობამდე (მაგალითად, DBA სკრიპტებიგანყოფილება "მონიტორინგი"). Postgresql-ს ასევე აქვს სისტემის ნახვების მთელი თაიგული მონაცემთა ბაზის მონიტორინგი, კერძოდ ის, რაც შეუცვლელია ნებისმიერი DBA-ის ყოველდღიურ ცხოვრებაში, მაგალითად pg_stat_activity, pg_stat_database, pg_stat_bgwriter. MySQL-ს ამისათვის ცალკე სქემაც კი აქვს. შესრულების_სქემა. In Mongo ჩაშენებული პროფილერი აერთიანებს შესრულების მონაცემებს სისტემის კოლექციაში სისტემა.პროფილი.

ამგვარად, შეიარაღებული მეტრიკის გარკვეული კოლექციონერით (Telegraf, Metricbeat, Collectd), რომელსაც შეუძლია შეასრულოს მორგებული sql მოთხოვნები, ამ მეტრიკის შენახვა (InfluxDB, Elasticsearch, Timescaledb) და ვიზუალიზატორი (Grafana, Kibana), შეგიძლიათ მიიღოთ საკმაოდ მარტივი და მოქნილი მონიტორინგის სისტემა, რომელიც მჭიდროდ იქნება ინტეგრირებული სხვა სისტემურ მეტრიკასთან (მიღებული, მაგალითად, აპლიკაციის სერვერიდან, OS-დან და ა.შ.). როგორც, მაგალითად, ეს კეთდება pgwatch2-ში, რომელიც იყენებს InfluxDB + Grafana კომბინაციას და მოთხოვნების ერთობლიობას სისტემის ხედებზე, რომლებზეც ასევე შესაძლებელია წვდომა. საბაჟო მოთხოვნების დამატება.

საერთო ჯამში

და ეს მხოლოდ მიახლოებითი ჩამონათვალია იმისა, თუ რა შეიძლება გაკეთდეს ჩვენს მონაცემთა ბაზასთან რეგულარული SQL კოდის გამოყენებით. დარწმუნებული ვარ, შეგიძლიათ იპოვოთ მრავალი სხვა გამოყენება, დაწერეთ კომენტარებში. და ჩვენ ვისაუბრებთ იმაზე, თუ როგორ (და რაც მთავარია რატომ) ამ ყველაფრის ავტომატიზაცია და შემდეგ ჯერზე ჩართვა თქვენს CI/CD მილსადენში.

წყარო: www.habr.com