ประสบการณ์ "ฐานข้อมูลเป็นรหัส"

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 ของตนโดยไม่ต้องเพิ่มเลเยอร์หรือการแยกส่วนเพิ่มเติม สิ่งนี้นำไปสู่การเกิดขึ้นของโครงการ "เน้นข้อมูล" ซึ่งฐานข้อมูลได้รับการจัดการโดยบุคลากรที่ผ่านการฝึกอบรมมาเป็นพิเศษ (เช่น "ผู้เชี่ยวชาญด้านฐานข้อมูล" "คนฐานข้อมูล" "นักพัฒนาฐานข้อมูล" และอื่นๆ) ส่วนนักพัฒนาก็ปล่อยให้ปรับแต่งวิวสำเร็จรูปและกระบวนการจัดเก็บโดยไม่ต้องลงลึกในรายละเอียด

จะเป็นอย่างไรหากคุณได้นำสิ่งที่ดีที่สุดของทั้งสองโลกมารวมกัน? เหมือนกับที่มันทำในเครื่องดนตรีอันวิเศษที่มีชื่อที่ให้กำลังใจชีวิต? เยสคิวลฉันจะยกตัวอย่างแนวคิดทั่วไปสองสามข้อในการแปลฟรีของฉัน แต่คุณสามารถอ่านเพิ่มเติมเกี่ยวกับเรื่องนี้ได้ ที่นี่.

Clojure เป็นภาษาที่ยอดเยี่ยมสำหรับการสร้าง DSL แต่ SQL ก็เป็น DSL ที่ยอดเยี่ยมอยู่แล้ว และเราไม่ต้องการ DSL ตัวอื่นอีก นิพจน์ S นั้นยอดเยี่ยม แต่มันไม่ได้เพิ่มอะไรใหม่ๆ ตรงนี้ เราเลยต้องใส่วงเล็บเพื่อประโยชน์ของวงเล็บ ไม่เห็นด้วยเหรอ? งั้นก็รอจนกว่าการแยกส่วนของฐานข้อมูลจะเริ่มรั่วไหล แล้วคุณก็เริ่มต่อสู้กับฟังก์ชันนั้น (raw-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 เป็น SQL
• ความเข้ากันได้ของคำสั่ง ผู้ดูแลฐานข้อมูลของคุณสามารถอ่านและเขียน SQL ที่คุณใช้ในโครงการ Clojure ได้
• ปรับแต่งประสิทธิภาพได้ง่ายขึ้น ต้องการสร้างแผนสำหรับคิวรีที่มีปัญหาใช่ไหม? ไม่มีปัญหาเลยถ้าคิวรีของคุณเป็น SQL มาตรฐาน
• ใช้คิวรีซ้ำ ลากและวางไฟล์ SQL เดียวกันนี้ลงในโปรเจ็กต์อื่น เพราะมันเป็น SQL แบบเดิมๆ แค่แชร์มันก็พอ

ในความคิดของฉัน แนวคิดนี้เจ๋งมากและในเวลาเดียวกันก็เรียบง่ายมาก ซึ่งทำให้โครงการนี้ได้รับความนิยมอย่างมาก ผู้ติดตาม ในหลากหลายภาษา และเราจะพยายามใช้ปรัชญาที่คล้ายคลึงกันนี้ โดยแยกโค้ด SQL ออกจากสิ่งอื่น ๆ ที่อยู่นอกเหนือจาก ORM ให้ไกลออกไป

ผู้จัดการ IDE และ DB

เริ่มต้นด้วยงานง่ายๆ ในชีวิตประจำวัน เรามักต้องค้นหาวัตถุในฐานข้อมูล เช่น ค้นหาตารางใน schema และตรวจสอบโครงสร้างของมัน (คอลัมน์ คีย์ ดัชนี ข้อจำกัด และอื่นๆ ที่ใช้) และนี่คือความสามารถที่เราคาดหวังจาก IDE แบบกราฟิกหรือแม้แต่ตัวจัดการฐานข้อมูล เราต้องการให้มันทำงานได้อย่างรวดเร็ว เพื่อไม่ให้ต้องรอครึ่งชั่วโมงกว่าหน้าต่างที่มีข้อมูลที่ต้องการจะปรากฏขึ้น (โดยเฉพาะอย่างยิ่งเมื่อเชื่อมต่อกับฐานข้อมูลระยะไกลที่ช้า) และเราต้องการให้ข้อมูลที่ดึงมามีความสดใหม่และเกี่ยวข้อง ไม่ใช่ข้อมูลขยะที่ถูกแคชไว้ ยิ่งไปกว่านั้น ยิ่งฐานข้อมูลมีความซับซ้อนและมีขนาดใหญ่มากเท่าไหร่ และมีจำนวนมากขึ้นเท่าไหร่ ก็ยิ่งยากขึ้นเท่านั้น

แต่ปกติแล้วผมจะวางเมาส์ลงแล้วเขียนโค้ด สมมติว่าผมต้องการค้นหาว่าตารางใด (และมีคุณสมบัติใดบ้าง) อยู่ใน schema "HR" ใน DBMS ส่วนใหญ่ ผลลัพธ์ที่ต้องการสามารถทำได้ด้วยคำสั่ง Query ง่ายๆ แบบนี้จาก information_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 แต่ก็มี เมตาดาต้าของ 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'

สามารถทำสิ่งที่คล้ายกันได้ใน Cassandra (ซึ่งมี columnfamilies แทนตารางและ keyspaces แทน schema):

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

สำหรับฐานข้อมูลอื่นๆ ส่วนใหญ่ คุณสามารถสร้างแบบสอบถามที่คล้ายกันได้ (แม้แต่ Mongo ก็มี) ระบบรวบรวมพิเศษซึ่งมีข้อมูลเกี่ยวกับคอลเลกชันทั้งหมดในระบบ)

แน่นอนว่าวิธีนี้สามารถใช้เพื่อรับข้อมูลได้ไม่เพียงแต่เกี่ยวกับตารางเท่านั้น แต่ยังรวมถึงข้อมูลของออบเจ็กต์อื่นๆ โดยทั่วไปด้วย เป็นครั้งคราวที่ผู้คนใจดีจะแบ่งปันโค้ดดังกล่าวสำหรับฐานข้อมูลต่างๆ เช่นในบทความชุด Habr เรื่อง "ฟังก์ชันสำหรับการบันทึกฐานข้อมูล PostgreSQL" (เอยบ, เบ็น, โรงยิม) แน่นอนว่าการเก็บคำถามมากมายไว้ในหัวและพิมพ์ออกมาอย่างต่อเนื่องนั้นไม่ใช่เรื่องน่าพอใจนัก ดังนั้น ใน IDE/โปรแกรมแก้ไขที่ฉันชื่นชอบ ฉันจึงมีชุดคำสั่งสั้นๆ ที่เตรียมไว้ล่วงหน้าสำหรับคำถามที่ใช้บ่อยๆ และสิ่งที่เหลือให้ทำคือพิมพ์ชื่ออ็อบเจ็กต์ลงในเทมเพลต

ด้วยเหตุนี้ วิธีการนำทางและค้นหาวัตถุจึงมีความยืดหยุ่นมากขึ้น ประหยัดเวลาได้มาก และทำให้คุณได้รับข้อมูลได้อย่างแม่นยำและอยู่ในรูปแบบที่คุณต้องการ (ดังที่อธิบายไว้ในโพสต์) การส่งออกข้อมูลฐานข้อมูลในรูปแบบใดก็ได้: IDE ที่ใช้ IntelliJ สามารถทำอะไรได้บ้าง).

การดำเนินการกับวัตถุ

เมื่อเราพบและตรวจสอบวัตถุที่จำเป็นแล้ว ก็ถึงเวลาที่เราจะลงมือทำอะไรบางอย่างที่มีประโยชน์กับวัตถุเหล่านั้น โดยไม่ต้องละนิ้วจากแป้นพิมพ์

ไม่ใช่ความลับเลยที่การลบตารางเพียงอย่างเดียวจะมีลักษณะเหมือนกันในฐานข้อมูลเกือบทั้งหมด:

drop table hr.persons

การสร้างตารางนั้นน่าสนใจกว่าเล็กน้อย DBMS เกือบทุกตัว (รวมถึง NoSQL หลายตัว) จะมีรูปแบบ "สร้างตาราง" อยู่บ้าง และส่วนพื้นฐานจะแตกต่างกันเพียงเล็กน้อย (ชื่อ, รายการคอลัมน์, ชนิดข้อมูล) แต่รายละเอียดอื่นๆ อาจแตกต่างกันไปอย่างมาก และขึ้นอยู่กับการออกแบบภายในและความสามารถของ DBMS นั้นๆ ตัวอย่างที่ผมชอบคือเอกสารของ Oracle มีเพียงไวยากรณ์ BNF ธรรมดาสำหรับไวยากรณ์ "สร้างตาราง" เท่านั้น ครอบคลุม 31 หน้าDBMS อื่นๆ มีขีดความสามารถที่เรียบง่ายกว่า แต่แต่ละ DBMS ก็มีคุณลักษณะที่น่าสนใจและเป็นเอกลักษณ์เฉพาะตัวมากมายสำหรับการสร้างตารางเช่นกันpostgres, 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'

และถ้าลองสักหน่อยก็เป็นไปตามพื้นฐาน เทมเพลต 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 มาให้เงียบๆ โดยเน้นจุดสำคัญๆ ด้วยสีแดงเพื่อความชัดเจน (พูดอย่างสุภาพก็คือ แทบจะไม่ช่วยอะไรเลย) ดังนั้น จาก "ภาพถ่าย" นี้ เราจึงต้องแก้ไขปัญหานี้ ในขณะเดียวกัน ไม่มีใครสามารถเข้าถึง Enterprise Manager อันทรงคุณค่า (ในทั้งสองความหมาย) ได้ เพราะระบบมีความซับซ้อนและมีค่าใช้จ่ายสูง แล้วถ้า "นักพัฒนาบังเอิญเจออะไรบางอย่างแล้วทุกอย่างพัง" ล่ะ นักพัฒนาจึงได้ระบุต้นตอและสาเหตุของความล่าช้าและปล่อยแพตช์ออกมา หากจดหมายลางร้ายจาก DBA ไม่มาถึงอีกในเร็วๆ นี้ ทุกคนก็ถอนหายใจด้วยความโล่งใจและกลับไปทำหน้าที่ของตนต่อไป (จนกระทั่งจดหมายฉบับต่อไปมาถึง)

แต่กระบวนการตรวจสอบสามารถสนุกสนานและเป็นมิตรมากขึ้น และที่สำคัญที่สุดคือเข้าถึงได้และโปร่งใสสำหรับทุกคน อย่างน้อยส่วนพื้นฐานก็สามารถเป็นส่วนเสริมของระบบตรวจสอบหลัก (ซึ่งแน่นอนว่ามีประโยชน์และในหลายกรณีก็ขาดไม่ได้) DBMS ใดๆ ก็ยินดีที่จะแบ่งปันข้อมูลเกี่ยวกับสถานะและประสิทธิภาพปัจจุบันได้อย่างอิสระและไม่มีค่าใช้จ่ายใดๆ ทั้งสิ้น ใน Oracle DB ที่ "เดือดดาล" เดียวกันนี้ ข้อมูลประสิทธิภาพแทบทุกอย่างสามารถได้รับจากมุมมองระบบ ตั้งแต่กระบวนการและเซสชันไปจนถึงสถานะของแคชบัฟเฟอร์ (ตัวอย่างเช่น สคริปต์ DBAส่วน "การตรวจสอบ") Postgresql ยังมีมุมมองระบบมากมายสำหรับ การติดตามการทำงานของฐานข้อมูลโดยเฉพาะอย่างยิ่งสิ่งที่ขาดไม่ได้ในชีวิตประจำวันของ DBA เช่น pg_stat_activity, ฐานข้อมูล pg_stat, pg_stat_bgwriterMySQL ยังมีรูปแบบแยกต่างหากสำหรับจุดประสงค์นี้ด้วย ประสิทธิภาพ_สคีมา. และ Mongo ก็มีในตัว โปรไฟเลอร์ รวบรวมข้อมูลประสิทธิภาพการทำงานลงในระบบคอลเลกชัน ระบบ.โปรไฟล์.

ดังนั้น หากมีตัวรวบรวมเมตริก (Telegraf, Metricbeat, Collectd) ที่สามารถดำเนินการคิวรี SQL แบบกำหนดเองได้ พื้นที่จัดเก็บสำหรับเมตริกเหล่านี้ (InfluxDB, Elasticsearch, Timescaledb) และตัวแสดงภาพ (Grafana, Kibana) คุณก็จะได้รับระบบตรวจสอบที่ค่อนข้างเบาและยืดหยุ่น ซึ่งจะผสานรวมเข้ากับเมตริกอื่นๆ ทั่วทั้งระบบได้อย่างแนบแน่น (เช่น ดึงมาจากเซิร์ฟเวอร์แอปพลิเคชัน จากระบบปฏิบัติการ เป็นต้น) ดังตัวอย่างที่ดำเนินการใน pgwatch2 ซึ่งใช้การผสมผสานระหว่าง InfluxDB + Grafana และชุดคิวรีสำหรับมุมมองระบบ ซึ่งสามารถเข้าถึงได้เช่นกัน เพิ่มแบบสอบถามที่กำหนดเอง.

เบ็ดเสร็จ

และนี่เป็นเพียงรายการคร่าวๆ ของสิ่งที่สามารถทำได้กับฐานข้อมูลของเราโดยใช้โค้ด SQL ทั่วไป ผมมั่นใจว่ายังมีแอปพลิเคชันอื่นๆ อีกมากมาย โปรดแจ้งให้ผมทราบในคอมเมนต์ เราจะมาพูดคุยกันถึงวิธี (และที่สำคัญที่สุดคือเหตุผล) ที่จะทำให้สิ่งเหล่านี้เป็นระบบอัตโนมัติและนำไปรวมไว้ในขั้นตอน CI/CD ของคุณในครั้งหน้า

ที่มา: will.com