"කේතය ලෙස දත්ත සමුදාය" පළපුරුද්ද

SQL, වඩා සරල විය හැක්කේ කුමක් ද? අප සෑම කෙනෙකුටම සරල ඉල්ලීමක් ලිවිය හැකිය - අපි ටයිප් කරන්නෙමු තෝරන්න, අවශ්‍ය තීරු ලැයිස්තුගත කරන්න, ඉන්පසු සිට, වගුවේ නම, සමහර කොන්දේසි වල එහිදී සහ එපමණයි - ප්‍රයෝජනවත් දත්ත අපගේ සාක්කුවේ ඇත, සහ (පාහේ) එම අවස්ථාවේ කුමන DBMS තොප්පිය යටතේ තිබුණත් (හෝ සමහර විට) කිසිසේත්ම DBMS නොවේ) එහි ප්‍රතිඵලයක් වශයෙන්, ඕනෑම දත්ත ප්‍රභවයක් සමඟ වැඩ කිරීම (සම්බන්ධතා සහ එසේ නොවේ) සාමාන්‍ය කේතයේ දෘෂ්ටි කෝණයෙන් සලකා බැලිය හැකිය (එය ඇඟවුම් කරන සියල්ල සමඟ - අනුවාද පාලනය, කේත සමාලෝචනය, ස්ථිතික විශ්ලේෂණය, ස්වයං පරීක්ෂණ සහ එපමණයි). තවද මෙය දත්ත, යෝජනා ක්‍රම සහ සංක්‍රමණ වලට පමණක් නොව, පොදුවේ ගබඩාවේ මුළු ජීවිතයටම අදාළ වේ. මෙම ලිපියෙන් අපි "කේතය ලෙස දත්ත සමුදාය" කාචය යටතේ විවිධ දත්ත සමුදායන් සමඟ වැඩ කිරීමේ එදිනෙදා කාර්යයන් සහ ගැටළු ගැන කතා කරමු.

හා අපි කෙලින්ම පටන් ගමු ඕආර්එම්. "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

... ඉන්පසු මෙම ගොනුව කියවන්න, එය සාමාන්‍ය 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 වලට ඔබ ඔබේ Clojure ව්‍යාපෘතියේ භාවිතා කරන SQL කියවීමට සහ ලිවීමට හැකිය.
• පහසු කාර්ය සාධන සුසර කිරීම. ගැටළු සහගත විමසුමක් සඳහා සැලැස්මක් ගොඩනගා ගැනීමට අවශ්‍යද? ඔබගේ විමසුම සාමාන්‍ය SQL වන විට මෙය ගැටළුවක් නොවේ.
• විමසුම් නැවත භාවිතා කිරීම. එම SQL ගොනු වෙනත් ව්‍යාපෘතිවලට ඇද දමන්න, මන්ද එය හුදෙක් පැරණි SQL නිසා - එය බෙදාගන්න.

මගේ මතය අනුව, අදහස ඉතා සිසිල් වන අතර ඒ සමඟම ඉතා සරල ය, ව්‍යාපෘතියට බොහෝ දේ ලබා ගැනීමට ස්තූතියි අනුගාමිකයින් විවිධ භාෂාවලින්. තවද අපි මීළඟට ORM වලින් ඔබ්බට ඇති අනෙක් සියල්ලෙන් SQL කේතය වෙන් කිරීමේ සමාන දර්ශනයක් යෙදීමට උත්සාහ කරමු.

IDE සහ DB කළමනාකරුවන්

අපි සරල එදිනෙදා කාර්යයකින් පටන් ගනිමු. බොහෝ විට අපට දත්ත සමුදායේ සමහර වස්තූන් සෙවීමට සිදුවේ, උදාහරණයක් ලෙස, ස්කීමා හි වගුවක් සොයාගෙන එහි ව්‍යුහය අධ්‍යයනය කරන්න (භාවිතා කරන තීරු, යතුරු, දර්ශක, සීමාවන් ආදිය). ඕනෑම චිත්‍රක IDE හෝ කුඩා DB-කළමනාකරුවෙකුගෙන්, පළමුව, අපි මෙම හැකියාවන් හරියටම අපේක්ෂා කරමු. එබැවින් එය වේගවත් වන අතර අවශ්‍ය තොරතුරු සහිත කවුළුවක් අඳින තෙක් ඔබට පැය භාගයක් බලා සිටීමට සිදු නොවේ (විශේෂයෙන් දුරස්ථ දත්ත ගබඩාවකට මන්දගාමී සම්බන්ධතාවයක් සමඟ), ඒ සමඟම, ලැබුණු තොරතුරු නැවුම් සහ අදාළ වේ, සහ කෑෂ් කළ කුණු නොවේ. එපමණක් නොව, වඩාත් සංකීර්ණ හා විශාල දත්ත සමුදාය සහ ඒවායේ සංඛ්යාව වැඩි වන තරමට මෙය සිදු කිරීම වඩාත් අපහසු වේ.

නමුත් සාමාන්‍යයෙන් මම මූසිකය ඉවතට විසි කර කේතය ලියන්නෙමි. "HR" ක්‍රමලේඛනයේ අඩංගු වන වගු (සහ කුමන ගුණාංග සමඟ)දැයි ඔබ සොයා බැලිය යුතු යැයි සිතමු. බොහෝ DBMS වල, 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'

ඔරකල් තොරතුරු_ක්‍රමය දන්නේ නැත, නමුත් එයට තිබේ ඔරකල් පාරදත්ත, සහ විශාල ගැටළු මතු නොවේ:

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'

අනෙකුත් බොහෝ දත්ත සමුදායන් සඳහා, ඔබට සමාන විමසුම් ඉදිරිපත් කළ හැකිය (Mongo පවා ඇත විශේෂ පද්ධති එකතුව, පද්ධතියේ සියලුම එකතු කිරීම් පිළිබඳ තොරතුරු අඩංගු වේ).

ඇත්ත වශයෙන්ම, මේ ආකාරයෙන් ඔබට වගු ගැන පමණක් නොව, සාමාන්යයෙන් ඕනෑම වස්තුවක් ගැන තොරතුරු ලබා ගත හැකිය. වරින් වර, කාරුණික පුද්ගලයින් විවිධ දත්ත සමුදායන් සඳහා එවැනි කේතයක් බෙදා ගනී, උදාහරණයක් ලෙස, හබ්රා ලිපි මාලාවේ “PostgreSQL දත්ත සමුදායන් ලේඛනගත කිරීමේ කාර්යයන්” (අයිබ්, බෙන්, ජිම්) ඇත්ත වශයෙන්ම, මෙම සම්පූර්ණ විමසුම් කන්ද මගේ හිසෙහි තබාගෙන ඒවා නිරන්තරයෙන් ටයිප් කිරීම එතරම් සතුටක්, එබැවින් මගේ ප්‍රියතම IDE/editor හි නිතර භාවිතා කරන විමසුම් සඳහා පෙර සූදානම් කළ කොටස් කට්ටලයක් මා සතුව ඇති අතර ඉතිරිව ඇත්තේ ටයිප් කිරීම පමණි. සැකිල්ලට වස්තුවේ නම්.

එහි ප්‍රතිඵලයක් වශයෙන්, මෙම සංචාලනය සහ වස්තූන් සෙවීමේ ක්‍රමය වඩාත් නම්‍යශීලී වන අතර, බොහෝ කාලයක් ඉතිරි කරයි, සහ දැන් අවශ්‍ය පෝරමයේ තොරතුරු හරියටම ලබා ගැනීමට ඔබට ඉඩ සලසයි (නිදසුනක් ලෙස, ලිපියේ විස්තර කර ඇති පරිදි "ඕනෑම ආකෘතියකින් දත්ත සමුදායකින් දත්ත අපනයනය කිරීම: IntelliJ වේදිකාව මත IDE වලට කළ හැකි දේ").

වස්තූන් සමඟ මෙහෙයුම්

අපි අවශ්‍ය වස්තූන් සොයාගෙන අධ්‍යයනය කිරීමෙන් පසුව, ඒවා සමඟ ප්‍රයෝජනවත් දෙයක් කිරීමට කාලයයි. ස්වාභාවිකවම, ඔබේ ඇඟිලි යතුරු පුවරුවෙන් ඉවතට නොගෙන.

වගුවක් මකා දැමීම සෑම දත්ත සමුදායකම පාහේ සමාන වන බව රහසක් නොවේ:

drop table hr.persons

නමුත් මේසය නිර්මාණය කිරීමත් සමඟ එය වඩාත් රසවත් වේ. ඕනෑම DBMS (බොහෝ NoSQL ඇතුළුව) පාහේ එක් ආකාරයකින් හෝ වෙනත් ආකාරයකින් “වගුව නිර්මාණය” කළ හැකි අතර, එහි ප්‍රධාන කොටස තරමක් වෙනස් වේ (නම, තීරු ලැයිස්තුව, දත්ත වර්ග), නමුත් අනෙකුත් විස්තර නාටකාකාර ලෙස වෙනස් විය හැකි අතර ඒවා මත රඳා පවතී අභ්යන්තර උපාංගය සහ විශේෂිත DBMS හි හැකියාවන්. මගේ ප්‍රියතම උදාහරණය නම් ඔරකල් ප්‍රලේඛනයේ ඇත්තේ "වගුව සාදන්න" වාක්‍ය ඛණ්ඩය සඳහා "නිරුවත්" BNF පමණි. පිටු 31 ක් අල්ලා ගන්න. අනෙකුත් DBMS වලට වඩා නිහතමානී හැකියාවන් ඇත, නමුත් ඒ සෑම එකක්ම වගු නිර්මාණය කිරීම සඳහා බොහෝ රසවත් සහ අද්විතීය විශේෂාංග ඇත (postgres, mysql, කැරපොත්තා, කassandra) වෙනත් IDE (විශේෂයෙන් විශ්වීය එකක්) වෙතින් වන කිසිදු චිත්‍රක “විශාරදයෙකුට” මෙම සියලු හැකියාවන් සම්පූර්ණයෙන් ආවරණය කිරීමට හැකි වනු ඇතැයි සිතිය නොහැකි අතර, එය කළ හැකි වුවද, ක්ලාන්ත හදවත් ඇති අයට එය දර්ශනයක් නොවනු ඇත. ඒ අතරම, නිවැරදිව හා කාලෝචිත ලෙස ලිඛිත ප්රකාශයක් වගුව සාදන්න ඔබට ඒවා සියල්ලම පහසුවෙන් භාවිතා කිරීමට, ගබඩා කිරීමට සහ ඔබේ දත්ත වෙත ප්‍රවේශ වීමට විශ්වාසදායක, ප්‍රශස්ත සහ හැකි තරම් සුවපහසු කිරීමට ඉඩ සලසයි.

එසේම, බොහෝ DBMS වලට වෙනත් DBMS වල නොමැති ඔවුන්ගේම විශේෂිත වස්තූන් ඇත. එපමනක් නොව, අපට දත්ත සමුදා වස්තු මත පමණක් නොව, DBMS මතම මෙහෙයුම් සිදු කළ හැකිය, උදාහරණයක් ලෙස, ක්රියාවලියක් "මරන්න", යම් මතක ප්රදේශයක් නිදහස් කිරීම, ලුහුබැඳීම සක්රිය කිරීම, "කියවීමට පමණක්" මාදිලිය වෙත මාරු වීම සහ තවත් බොහෝ දේ.

දැන් අපි ටිකක් අඳිමු

වඩාත් පොදු කාර්යයක් වන්නේ දත්ත සමුදා වස්තූන් සමඟ රූප සටහනක් තැනීම සහ ඒවා අතර ඇති වස්තූන් සහ සම්බන්ධතා අලංකාර පින්තූරයකින් බැලීමයි. ඕනෑම චිත්රක IDE, වෙනම "විධාන රේඛා" උපයෝගිතා, විශේෂිත චිත්රක මෙවලම් සහ ආකෘති නිර්මාණකරුවන්ට මෙය කළ හැකිය. ඔවුන් "ඔවුන්ට හැකි උපරිමයෙන්" ඔබ වෙනුවෙන් යමක් අඳිනු ඇති අතර, ඔබට මෙම ක්‍රියාවලියට ටිකක් බලපෑම් කළ හැක්කේ වින්‍යාස ගොනුවේ හෝ අතුරු මුහුණතේ ඇති පිරික්සුම් පෙට්ටිවල පරාමිති කිහිපයක ආධාරයෙන් පමණි.

නමුත් මෙම ගැටළුව වඩාත් සරල, වඩාත් නම්යශීලී සහ අලංකාර ලෙස විසඳා ගත හැකි අතර, ඇත්ත වශයෙන්ම කේතයේ උපකාරයෙන්. ඕනෑම සංකීර්ණතාවයක රූප සටහන් නිර්මාණය කිරීම සඳහා, අප සතුව විශේෂිත සලකුණු භාෂා කිහිපයක් (DOT, GraphML ආදිය) ඇති අතර, ඔවුන් සඳහා එවැනි උපදෙස් කියවා විවිධ ආකෘතිවලින් ඒවා දෘශ්‍යමාන කළ හැකි යෙදුම් (GraphViz, PlantUML, Mermaid) සම්පූර්ණයෙන් විසිරී ඇත. . හොඳයි, වස්තූන් සහ ඒවා අතර සම්බන්ධතා පිළිබඳ තොරතුරු ලබා ගන්නේ කෙසේදැයි අපි දැනටමත් දනිමු.

PlantUML සහ භාවිතයෙන් මෙය කෙබඳු විය හැකිද යන්න පිළිබඳ කුඩා උදාහරණයක් මෙන්න PostgreSQL සඳහා demo දත්ත සමුදාය (වමේ 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” පැයේදී, විශාල සිල්ලර වෙළෙන්දෙකුගේ නිෂ්පාදන ක්‍රමය නැවත වරක් “නරක දැනීමට” පටන් ගත් විට, ඔහු නිහඬව Oracle Enterprise Manager වෙතින් ප්‍රස්ථාරවල තිරපිටපත් යවා, එහි “අවබෝධය” සඳහා රතු සලකුණක් සහිත තීරණාත්මක ස්ථාන ප්‍රවේශමෙන් ඉස්මතු කළේය ( මෙය, මෘදු ලෙස පැවසීමට, බොහෝ සෙයින් උදව් කළේ නැත). සහ මෙම "ඡායාරූප කාඩ්පත" මත පදනම්ව මට ප්රතිකාර කිරීමට සිදු විය. ඒ අතරම, කිසිවකුට වටිනා (වචනයේ අර්ථ දෙකෙන්ම) ව්‍යවසාය කළමනාකරු වෙත ප්‍රවේශය නොතිබුණි, මන්ද පද්ධතිය සංකීර්ණ හා මිල අධික ය, හදිසියේම "සංවර්ධකයින් යමක් මත පැකිලී සියල්ල බිඳ දමයි." එමනිසා, සංවර්ධකයින් "ආනුභවිකව" තිරිංග වල පිහිටීම සහ හේතුව සොයාගෙන පැච් එකක් නිකුත් කළේය. නුදුරු අනාගතයේ දී DBA වෙතින් තර්ජනාත්මක ලිපිය නැවත නොපැමිණියේ නම්, සෑම කෙනෙකුම සැනසුම් සුසුමක් හෙළා ඔවුන්ගේ වර්තමාන කාර්යයන් වෙත ආපසු යනු ඇත (නව ලිපිය දක්වා).

නමුත් අධීක්ෂණ ක්‍රියාවලිය වඩාත් විනෝදජනක සහ මිත්‍රශීලී ලෙස පෙනෙන අතර වඩාත්ම වැදගත් දෙය නම් සෑම කෙනෙකුටම ප්‍රවේශ විය හැකි සහ විනිවිද පෙනෙන බවයි. අවම වශයෙන් එහි මූලික කොටස, ප්‍රධාන අධීක්ෂණ පද්ධතිවලට එකතු කිරීමක් ලෙස (ඒවා නිසැකවම ප්‍රයෝජනවත් වන අතර බොහෝ අවස්ථාවන්හිදී ප්‍රතිස්ථාපනය කළ නොහැක). ඕනෑම DBMS එහි වත්මන් තත්ත්වය සහ කාර්ය සාධනය පිළිබඳ තොරතුරු බෙදා ගැනීමට නොමිලේ සහ සම්පූර්ණයෙන්ම නොමිලේ. එකම "ලේවැකි" Oracle DB හි, ක්‍රියාවලි සහ සැසිවල සිට බෆර හැඹිලියේ තත්වය දක්වා ක්‍රියාකාරීත්වය පිළිබඳ ඕනෑම තොරතුරක් පද්ධති දර්ශන වලින් ලබා ගත හැක (උදාහරණයක් ලෙස, DBA ස්ක්‍රිප්ට්, කොටස "අධීක්ෂණය"). Postgresql හි සම්පූර්ණ පද්ධති දසුන් ද ඇත දත්ත සමුදා අධීක්ෂණය, විශේෂයෙන්ම ඕනෑම DBA එකක දෛනික ජීවිතයට අත්‍යවශ්‍ය වන, වැනි pg_stat_activity, pg_stat_database, pg_stat_bgwriter. MySQL වලට මේකට වෙනම schema එකක් පවා තියෙනවා. කාර්ය සාධන_ක්‍රමය. A In Mongo බිල්ට්-ඉන් පැතිකඩකරු පද්ධති එකතුවකට කාර්ය සාධන දත්ත එකතු කරයි system.profile.

මේ අනුව, අභිරුචි sql විමසුම් සිදු කළ හැකි යම් ආකාරයක මෙට්‍රික් එකතු කරන්නෙකු (Telegraf, Metricbeat, Collectd) සමඟ සන්නද්ධව, මෙම ප්‍රමිතික ගබඩා කිරීම (InfluxDB, Elasticsearch, Timescaledb) සහ දෘශ්‍යකරණයක් (Grafana, Kibana), ඔබට තරමක් පහසු ලබා ගත හැක. සහ නම්‍යශීලී අධීක්ෂණ පද්ධතියක් වන අතර එය වෙනත් පද්ධති-පුළුල් ප්‍රමිතික සමඟ සමීපව ඒකාබද්ධ වේ (උදාහරණයක් ලෙස, යෙදුම් සේවාදායකයෙන්, OS වෙතින්, ආදිය). උදාහරණයක් ලෙස, මෙය සිදු කරනු ලබන්නේ pgwatch2 හි වන අතර, එය InfluxDB + Grafana සංයෝජනය සහ පද්ධති දර්ශන සඳහා විමසුම් කට්ටලයක් භාවිතා කරයි, ඒවාට ද ප්‍රවේශ විය හැකිය. අභිරුචි විමසුම් එකතු කරන්න.

එකතුව

මෙය සාමාන්‍ය SQL කේතය භාවිතයෙන් අපගේ දත්ත සමුදාය සමඟ කළ හැකි දේ පිළිබඳ දළ ලැයිස්තුවක් පමණි. ඔබට තවත් බොහෝ භාවිතයන් සොයාගත හැකි බව මට විශ්වාසයි, අදහස් දැක්වීමේදී ලියන්න. අපි මේ සියල්ල ස්වයංක්‍රීය කරන්නේ කෙසේද (සහ වඩාත්ම වැදගත් වන්නේ ඇයි) සහ ඊළඟ වතාවේ එය ඔබේ CI/CD නල මාර්ගයට ඇතුළත් කරන්නේ කෙසේද යන්න ගැන අපි කතා කරමු.

මූලාශ්රය: www.habr.com