חוויית "מסד נתונים כקוד".

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 בפני עצמו", אתה מקבל:

• אין הפתעות תחביריות. מסד הנתונים שלך (כמו כל בסיס אחר) אינו תואם ב-100% לתקן SQL - אבל זה לא משנה עבור Yesql. לעולם לא תבזבז זמן בחיפוש אחר פונקציות עם תחביר מקביל ל-SQL. לעולם לא תצטרך לחזור לפונקציה (raw-sql "some('funky'::SYNTAX)")).
• התמיכה הטובה ביותר בעורך. לעורך שלך כבר יש תמיכה מצוינת ב-SQL. על ידי שמירת SQL בתור SQL אתה יכול פשוט להשתמש בו.
• תאימות לצוות. ה-DBAs שלך יכולים לקרוא ולכתוב את ה-SQL שאתה משתמש בפרויקט Clojure שלך.
• כוונון ביצועים קל יותר. צריכים לבנות תוכנית לשאילתה בעייתית? זו לא בעיה כאשר השאילתה שלך היא SQL רגילה.
• שימוש חוזר בשאילתות. גרור ושחרר את אותם קבצי SQL לפרויקטים אחרים כי זה פשוט SQL ישן - פשוט שתף אותו.

לדעתי הרעיון מאוד מגניב ויחד עם זאת פשוט מאוד, שבזכותו הפרויקט צבר רבים עוקבים במגוון שפות. ובהמשך ננסה ליישם פילוסופיה דומה של הפרדת קוד SQL מכל דבר אחר הרבה מעבר ל-ORM.

מנהלי IDE ו-DB

נתחיל במשימה יומיומית פשוטה. לעתים קרובות עלינו לחפש אובייקטים מסוימים במסד הנתונים, למשל, למצוא טבלה בסכמה וללמוד את המבנה שלה (אילו עמודות, מפתחות, אינדקסים, אילוצים וכו' משמשים). ומכל IDE גרפי או קצת DB-manager, קודם כל, אנחנו מצפים בדיוק ליכולות האלה. כדי שזה יהיה מהיר ולא תצטרכו לחכות חצי שעה עד שיצויר חלון עם המידע הדרוש (במיוחד בחיבור איטי למאגר מידע מרוחק), ויחד עם זאת, המידע המתקבל טרי ורלוונטי, ולא זבל שמור. יתרה מכך, ככל שבסיס הנתונים מורכב וגדול יותר וככל שמספרם גדול יותר, כך קשה יותר לעשות זאת.

אבל בדרך כלל אני זורק את העכבר ופשוט כותב קוד. נניח שאתה צריך לברר אילו טבלאות (ועם אילו מאפיינים) כלולים בסכימת "HR". ברוב ה-DBMSs, ניתן להשיג את התוצאה הרצויה באמצעות שאילתה פשוטה זו מ-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'

אורקל לא מכירה info_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'

עבור רוב מסדי הנתונים האחרים, אתה יכול גם להמציא שאילתות דומות (אפילו למונגו יש איסוף מערכת מיוחד, המכיל מידע על כל האוספים במערכת).

כמובן שבדרך זו ניתן לקבל מידע לא רק על טבלאות, אלא על כל אובייקט באופן כללי. מעת לעת, אנשים אדיבים חולקים קוד כזה עבור מסדי נתונים שונים, כמו, למשל, בסדרת מאמרי הברה "פונקציות לתיעוד מאגרי PostgreSQL" (אייב, בן, חדר כושר). כמובן, לשמור את כל הר השאילתות הזה בראש שלי ולהקליד אותן כל הזמן זה תענוג כזה, אז ב-IDE/עורך האהוב עליי יש לי קבוצה מוכנה מראש של קטעים לשאילתות בשימוש תכוף, וכל מה שנשאר זה להקליד את שמות אובייקטים לתוך התבנית.

כתוצאה מכך, שיטה זו של ניווט וחיפוש אובייקטים גמישה הרבה יותר, חוסכת זמן רב ומאפשרת לקבל בדיוק את המידע בצורה שבה הוא נחוץ כעת (כפי שמתואר למשל בפוסט "ייצוא נתונים ממסד נתונים בכל פורמט: מה IDEs יכולים לעשות בפלטפורמת IntelliJ").

פעולות עם חפצים

אחרי שמצאנו ולמדנו את החפצים הדרושים, הגיע הזמן לעשות איתם משהו שימושי. באופן טבעי, גם בלי להוריד את האצבעות מהמקלדת.

זה לא סוד שפשוט מחיקת טבלה תיראה אותו הדבר כמעט בכל מסדי הנתונים:

drop table hr.persons

אבל עם יצירת השולחן זה הופך למעניין יותר. כמעט כל DBMS (כולל NoSQL רבים) יכול "ליצור טבלה" בצורה כזו או אחרת, והחלק העיקרי שלה אפילו יהיה שונה מעט (שם, רשימת עמודות, סוגי נתונים), אבל פרטים אחרים יכולים להיות שונים באופן דרמטי ותלויים ב- התקן פנימי ויכולות של DBMS ספציפי. הדוגמה האהובה עלי היא שבתיעוד של אורקל יש רק BNFs "עירומים" עבור תחביר "צור טבלה" תופסים 31 עמודים. למערכות 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, עליהם הדגיש בקפידה מקומות קריטיים עם סמן אדום ל"מובנות" ( זה, בלשון המעטה, לא עזר הרבה). ועל סמך "כרטיס הצילום" הזה הייתי צריך לטפל. יחד עם זאת, לאף אחד לא הייתה גישה למנהל הארגוני היקר (בשני מובנים של המילה), כי המערכת מורכבת ויקרה, פתאום "המפתחים נתקלים במשהו ושוברים הכל". לכן, המפתחים מצאו באופן "אמפירי" את המיקום והגורם לבלמים ושחררו תיקון. אם המכתב המאיים מה-DBA לא יגיע שוב בזמן הקרוב, אז כולם היו נושמים לרווחה וחוזרים למשימות הנוכחיות שלהם (עד המכתב החדש).

אבל תהליך הניטור יכול להיראות מהנה וידידותי יותר, והכי חשוב, נגיש ושקוף לכולם. לפחות החלק הבסיסי שלו, כתוספת למערכות הניטור הראשיות (שהן בהחלט שימושיות ובמקרים רבים שאין להם תחליף). כל DBMS הוא בחינם וללא תשלום לחלוטין כדי לשתף מידע על מצבו וביצועיו הנוכחיים. באותו Oracle DB "עקוב מדם", ניתן לקבל כמעט כל מידע על ביצועים מתצוגות מערכת, החל מתהליכים והפעלות ועד למצב של מטמון המאגר (לדוגמה, סקריפטים של DBA, סעיף "ניטור"). ל-Postgresql יש גם חבורה שלמה של תצוגות מערכת עבור ניטור מסדי נתונים, במיוחד אלה הכרחיים בחיי היומיום של כל DBA, כגון pg_stat_activity, pg_stat_database, pg_stat_bgwriter. ל-MySQL יש אפילו סכמה נפרדת לכך. performance_schema. A In Mongo מובנה מאפיין אוסף נתוני ביצועים לאוסף מערכת system.profile.

כך, חמוש בסוג של אספן מדדים (Telegraf, Metricbeat, Collectd) שיכול לבצע שאילתות sql מותאמות אישית, אחסון של מדדים אלה (InfluxDB, Elasticsearch, Timescaledb) ו-Visualizer (Grafana, Kibana), אתה יכול לקבל גישה קלה למדי. ומערכת ניטור גמישה שתשולב באופן הדוק עם מדדים נוספים כלל-מערכתיים (שמתקבלים, למשל, משרת האפליקציות, ממערכת ההפעלה וכו'). כמו, למשל, זה נעשה ב-pgwatch2, שמשתמש בשילוב InfluxDB + Grafana ובסט של שאילתות לתצוגות מערכת, שאליהן ניתן לגשת גם הוסף שאילתות מותאמות אישית.

בסך הכל

וזו רק רשימה משוערת של מה שניתן לעשות עם מסד הנתונים שלנו באמצעות קוד SQL רגיל. אני בטוח שתוכלו למצוא עוד הרבה שימושים, כתבו בתגובות. ואנחנו נדבר על איך (והכי חשוב למה) להפוך את כל זה לאוטומטי ולכלול אותו בצינור ה-CI/CD שלך בפעם הבאה.

מקור: www.habr.com