"የውሂብ ጎታ እንደ ኮድ" ልምድ

SQL፣ ምን ቀላል ሊሆን ይችላል? እያንዳንዳችን ቀላል ጥያቄን መጻፍ እንችላለን - እንጽፋለን ይምረጡ, የሚፈለጉትን ዓምዶች ይዘርዝሩ, ከዚያ ከ, ሰንጠረዥ ስም, አንዳንድ ሁኔታዎች ውስጥ የት እና ያ ብቻ ነው - ጠቃሚ መረጃ በኪሳችን ውስጥ አለ ፣ እና (ከሞላ ጎደል) ምንም ይሁን ምን DBMS በዚያ ጊዜ (ወይም ምናልባት) በጭራሽ DBMS አይደለም።). በውጤቱም ፣ ከማንኛውም የመረጃ ምንጭ (ተዛማጅ እና እንደዚህ አይደለም) ጋር መስራት ከመደበኛ ኮድ እይታ አንጻር ሊታሰብ ይችላል (ከዚህም ሁሉ ጋር - የስሪት ቁጥጥር ፣ የኮድ ግምገማ ፣ የማይንቀሳቀስ ትንታኔ ፣ አውቶሜትስ ፣ እና ያ ብቻ ነው)። እና ይሄ ለመረጃው እራሱ, ንድፎችን እና ፍልሰትን ብቻ ሳይሆን በአጠቃላይ የማከማቻውን ህይወት በሙሉ ይመለከታል. በዚህ ጽሑፍ ውስጥ ስለ "የውሂብ ጎታ እንደ ኮድ" ሌንስ ውስጥ ስለ ዕለታዊ ተግባራት እና ከተለያዩ የውሂብ ጎታዎች ጋር የመሥራት ችግሮች እንነጋገራለን.

እና ወዲያውኑ እንጀምር ORM. የ"SQL vs ORM" አይነት የመጀመሪያዎቹ ጦርነቶች ተመልሰው ተስተውለዋል። ቅድመ-ፔትሪን ሩስ.

የነገር-ግንኙነት ካርታ

የ ORM ደጋፊዎች የፍጥነት እና የዕድገት ቀላልነት፣ ከዲቢኤምኤስ ነፃ መውጣት እና ንጹህ ኮድን በተለምዶ ዋጋ ይሰጣሉ። ለብዙዎቻችን ከመረጃ ቋቱ (እና ብዙ ጊዜ የመረጃ ቋቱ ራሱ) ጋር ለመስራት የሚያስችል ኮድ

ብዙውን ጊዜ እንደዚህ ያለ ነገር ይመስላል…

@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 ተከታዮች ሁሉንም ጭማቂ ከዲቢኤምኤስ ውስጥ ያለ ተጨማሪ ሽፋኖች እና ማጠቃለያዎች የመጭመቅ ችሎታን ያስተውላሉ። በውጤቱም, "መረጃን ያማከለ" ፕሮጀክቶች ይታያሉ, በልዩ ሁኔታ የሰለጠኑ ሰዎች በመረጃ ቋቱ ውስጥ የሚሳተፉበት (እነሱም "መሰረታዊ" ናቸው, "መሠረታዊ" ናቸው, እነሱ ደግሞ "ባስደንስ", ወዘተ) እና ገንቢዎች ናቸው. ወደ ዝርዝሮች ሳይገቡ ዝግጁ የሆኑትን እይታዎች እና የተከማቹ ሂደቶችን "መሳብ" ብቻ ያስፈልግዎታል።

ከሁለቱም ዓለማት ምርጦች ብንሆንስ? ይህ ሕይወትን የሚያረጋግጥ ስም ባለው አስደናቂ መሣሪያ ውስጥ እንዴት እንደሚደረግ Yesql. በነጻ ትርጉሜ ውስጥ ከአጠቃላይ ፅንሰ-ሀሳብ ሁለት መስመሮችን እሰጣለሁ, እና ከእሱ ጋር በበለጠ ዝርዝር ውስጥ መተዋወቅ ይችላሉ. እዚህ.

ክሎጁር DSLs ለመፍጠር አሪፍ ቋንቋ ነው፣ ግን SQL ራሱ አሪፍ DSL ነው፣ እና ሌላ አያስፈልገንም። ኤስ-አገላለጾች በጣም ጥሩ ናቸው፣ ግን እዚህ ምንም አዲስ ነገር አይጨምሩም። በውጤቱም, ለቅንብሮች ሲባል ቅንፎችን እናገኛለን. አይስማሙም? ከዚያ በመረጃ ቋቱ ላይ ያለው ረቂቅ መፍሰስ ሲጀምር እና ከተግባሩ ጋር መዋጋት እስከሚጀምሩበት ጊዜ ድረስ ይጠብቁ (ጥሬ-ስኩዌር)

ታዲያ ምን ማድረግ አለብኝ? SQLን እንደ መደበኛ 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 በራሱ፣ ክሎጁር በራሱ" የሚለውን መርህ በማክበር የሚከተለውን ያገኛሉ፡-

• ምንም የአገባብ አስገራሚ ነገሮች የሉም። የውሂብ ጎታህ (እንደ ማንኛውም ሌላ) ከSQL መስፈርት ጋር 100% አያከብርም - ይህ ግን Yesql ምንም አይደለም። በSQL አቻ አገባብ ለአደን ጊዜ አታባክኑም። ወደ ተግባር በጭራሽ መመለስ የለብዎትም (raw-sql "አንዳንድ ('funky':: SYNTAX)"))).
• ምርጥ የአርታዒ ድጋፍ። የእርስዎ አርታዒ አስቀድሞ በጣም ጥሩ የSQL ድጋፍ አለው። SQL እንደ SQL በማስቀመጥ በቀላሉ ሊጠቀሙበት ይችላሉ።
• የቡድን ተኳሃኝነት. የእርስዎ ዲቢኤዎች በClojure ፕሮጀክትዎ ውስጥ የሚጠቀሙበትን SQL ማንበብ እና መፃፍ ይችላሉ።
• ቀላል የአፈጻጸም ማስተካከያ. ችግር ላለበት ጥያቄ እቅድ መገንባት ይፈልጋሉ? ጥያቄዎ መደበኛ SQL ሲሆን ይህ ችግር አይደለም።
• መጠይቆችን እንደገና መጠቀም። እነዚያን ተመሳሳይ SQL ፋይሎች ወደ ሌሎች ፕሮጀክቶች ይጎትቷቸው ምክንያቱም ልክ ያረጀ SQL - በቃ ያጋሩት።

በእኔ አስተያየት ሀሳቡ በጣም አሪፍ እና በተመሳሳይ ጊዜ በጣም ቀላል ነው, ለዚህም ምስጋና ይግባውና ፕሮጀክቱ ብዙዎችን አግኝቷል ተከታዮች በተለያዩ ቋንቋዎች. እና በመቀጠል የ SQL ኮድን ከ ORM በላይ ካሉት ነገሮች ሁሉ የመለየት ተመሳሳይ ፍልስፍናን ለመተግበር እንሞክራለን።

አይዲኢ እና ዲቢ አስተዳዳሪዎች

በቀላል የዕለት ተዕለት ተግባር እንጀምር። ብዙውን ጊዜ በመረጃ ቋቱ ውስጥ አንዳንድ ዕቃዎችን መፈለግ አለብን ፣ ለምሳሌ ፣ በፕሮግራሙ ውስጥ ሰንጠረዥ ይፈልጉ እና አወቃቀሩን (ምን ዓይነት ዓምዶች ፣ ቁልፎች ፣ ኢንዴክሶች ፣ ገደቦች ፣ ወዘተ ጥቅም ላይ ይውላሉ)። እና ከማንኛውም ግራፊክ አይዲኢ ወይም ትንሽ ዲቢ-አስተዳዳሪ፣ በመጀመሪያ፣ በትክክል እነዚህን ችሎታዎች እንጠብቃለን። ስለዚህ ፈጣን እንዲሆን እና አስፈላጊውን መረጃ የያዘ መስኮት እስኪወጣ ድረስ (በተለይ ከርቀት ዳታቤዝ ጋር በዝግታ ግንኙነት) እና በተመሳሳይ ጊዜ የተቀበሉት መረጃዎች ትኩስ እና ጠቃሚ ናቸው ። እና የተሸጎጠ ቆሻሻ አይደለም. ከዚህም በላይ, የበለጠ ውስብስብ እና ትልቅ የውሂብ ጎታ እና ቁጥራቸው እየጨመረ በሄደ መጠን ይህን ለማድረግ የበለጠ አስቸጋሪ ነው.

ግን ብዙውን ጊዜ አይጤን እጥላለሁ እና ኮድን ብቻ ​​እጽፋለሁ። በ "HR" እቅድ ውስጥ የትኞቹ ሰንጠረዦች (እና ከየትኞቹ ንብረቶች ጋር) እንደሚገኙ ማወቅ ያስፈልግዎታል እንበል. በአብዛኛዎቹ ዲቢኤምኤስዎች፣ የሚፈለገውን ውጤት በዚህ ቀላል ከመረጃ_schema ማግኘት ይቻላል፡-

select table_name
     , ...
  from information_schema.tables
 where schema = 'HR'

ከመረጃ ቋት ወደ ዳታቤዝ፣ የእንደዚህ አይነት የማጣቀሻ ሠንጠረዦች ይዘቶች እንደ እያንዳንዱ ዲቢኤምኤስ አቅም ይለያያሉ። እና ለምሳሌ፣ ለ MySQL፣ ከተመሳሳዩ የማመሳከሪያ መጽሐፍ ለዚህ ዲቢኤምኤስ የተለየ የሰንጠረዥ መለኪያዎችን ማግኘት ይችላሉ።

select table_name
     , storage_engine -- Используемый "движок" ("MyISAM", "InnoDB" etc)
     , row_format     -- Формат строки ("Fixed", "Dynamic" etc)
     , ...
  from information_schema.tables
 where schema = 'HR'

Oracle የመረጃ_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 የውሂብ ጎታዎችን ለመመዝገብ ተግባራት” (አይብ, ቤን, ጂም). በእርግጥ ይህን አጠቃላይ የጥያቄዎች ተራራ በጭንቅላቴ ውስጥ ማቆየት እና እነሱን ሁልጊዜ መተየብ በጣም አስደሳች ነው ፣ ስለሆነም በምወደው አይዲኢ/አርታኢ ውስጥ በተደጋጋሚ ለሚጠቀሙት መጠይቆች ቅድመ ዝግጅት የተደረገ ቅንጣቢ አለኝ እና የቀረው ግን መተየብ ብቻ ነው። የነገር ስሞች ወደ አብነት.

በውጤቱም, ይህ ቁሳቁሶችን የማሰስ እና የመፈለግ ዘዴ የበለጠ ተለዋዋጭ ነው, ብዙ ጊዜ ይቆጥባል, እና መረጃውን አሁን አስፈላጊ በሆነበት መልክ በትክክል እንዲያገኙ ያስችልዎታል (ለምሳሌ, በፖስታ ውስጥ እንደተገለጸው). "መረጃን ከውሂብ ጎታ በማንኛውም መልኩ ወደ ውጭ መላክ፡ አይዲኢዎች በIntelliJ መድረክ ላይ ምን ሊያደርጉ ይችላሉ").

ከዕቃዎች ጋር ክዋኔዎች

አስፈላጊዎቹን ነገሮች ካገኘን እና ካጠናን በኋላ, ከእነሱ ጋር አንድ ጠቃሚ ነገር ለማድረግ ጊዜው አሁን ነው. በተፈጥሮ ፣ እንዲሁም ጣቶችዎን ከቁልፍ ሰሌዳው ላይ ሳያነሱ።

በቀላሉ ሠንጠረዥን መሰረዝ በሁሉም የመረጃ ቋቶች ውስጥ አንድ አይነት እንደሚሆን ምስጢር አይደለም፡

drop table hr.persons

ነገር ግን የጠረጴዛው መፈጠር የበለጠ አስደሳች ይሆናል. ማንኛውም ዲቢኤምኤስ (ብዙ ኖኤስኪኤልን ጨምሮ) በአንድ ወይም በሌላ መልኩ “ሠንጠረዥ መፍጠር” ይችላል፣ እና የእሱ ዋና ክፍል ትንሽ እንኳን ሊለያይ ይችላል (ስም ፣ የአምዶች ዝርዝር ፣ የውሂብ ዓይነቶች) ፣ ግን ሌሎች ዝርዝሮች በከፍተኛ ሁኔታ ሊለያዩ እና በ የውስጥ መሣሪያ እና የአንድ የተወሰነ ዲቢኤምኤስ ችሎታዎች። በጣም የምወደው ምሳሌ በ Oracle ሰነድ ውስጥ ለ"ጠረጴዛ ፍጠር" አገባብ "ራቁት" BNFs ብቻ ነው ያለው። 31 ገጾችን ይያዙ. ሌሎች ዲቢኤምኤስዎች የበለጠ መጠነኛ ችሎታዎች አሏቸው፣ ነገር ግን እያንዳንዳቸው ሰንጠረዦችን ለመፍጠር ብዙ አስደሳች እና ልዩ ባህሪያት አሏቸው (ፖስትጋሮች, MySQL, በረሮ, ካሳንድራ). ከሌላ IDE (በተለይም ሁለንተናዊ) ማንኛውም ስዕላዊ “ጠንቋይ” እነዚህን ሁሉ ችሎታዎች ሙሉ በሙሉ ሊሸፍን ይችላል ብሎ ማሰብ የማይመስል ነገር ነው ፣ እና ቢቻል እንኳን ፣ ለልብ ደካማዎች ትርኢት አይሆንም ። በተመሳሳይ ጊዜ, ትክክለኛ እና ወቅታዊ የጽሁፍ መግለጫ ጠረጴዛ ፍጠር ሁሉንም በቀላሉ እንዲጠቀሙ ይፈቅድልዎታል ፣ ማከማቻዎን እና የውሂብዎን ተደራሽነት አስተማማኝ ፣ ምርጥ እና በተቻለ መጠን ምቹ ያድርጉት።

እንዲሁም፣ ብዙ ዲቢኤምኤስዎች በሌሎች ዲቢኤምኤስ ውስጥ የማይገኙ የራሳቸው ልዩ ዓይነት ነገሮች አሏቸው። ከዚህም በላይ በዳታቤዝ ዕቃዎች ላይ ብቻ ሳይሆን በዲቢኤምኤስ በራሱ ላይም ክንዋኔዎችን ማከናወን እንችላለን ለምሳሌ አንድን ሂደት “መግደል”፣ አንዳንድ የማስታወሻ ቦታዎችን ነፃ ማድረግ፣ ፍለጋን ማንቃት፣ ወደ “ማንበብ ብቻ” ሁነታ መቀየር እና ሌሎችንም ማድረግ እንችላለን።

አሁን ትንሽ እንሳል

ከተለመዱት ተግባራት አንዱ ከዳታቤዝ ዕቃዎች ጋር ንድፍ መገንባት እና በመካከላቸው ያሉትን ነገሮች እና ግንኙነቶች በሚያምር ምስል ማየት ነው ። ማንኛውም ማለት ይቻላል ግራፊክ አይዲኢ፣ የተለየ “የትእዛዝ መስመር” መገልገያዎች፣ ልዩ የግራፊክ መሳሪያዎች እና ሞዴለሮች ይህንን ማድረግ ይችላሉ። አንድ ነገር "በተቻለ መጠን" ይሳሉልዎታል, እና በዚህ ሂደት ላይ ትንሽ ተጽእኖ ሊያደርጉት የሚችሉት በማዋቀሪያው ፋይል ወይም በበይነገጹ ውስጥ ባሉ አመልካች ሳጥኖች ውስጥ ባሉት ጥቂት መለኪያዎች እገዛ ብቻ ነው.

ግን ይህ ችግር በጣም ቀላል ፣ የበለጠ ተለዋዋጭ እና የሚያምር ፣ እና በእርግጥ በኮድ እገዛ ሊፈታ ይችላል። የማንኛውም ውስብስብነት ሥዕላዊ መግለጫዎችን ለመፍጠር ብዙ ልዩ የማርክ አፕሊኬሽን ቋንቋዎች (DOT ፣ GraphML ወዘተ) አሉን እና ለእነሱ እንደዚህ ያሉትን መመሪያዎች ማንበብ እና በተለያዩ ቅርፀቶች ሊታዩ የሚችሉ አጠቃላይ አፕሊኬሽኖች (ግራፍቪዝ ፣ ፕላንትዩኤምኤል ፣ ሜርሜይድ) አሉን ። . ደህና, ስለ እቃዎች እና በመካከላቸው ያለውን ግንኙነት እንዴት መረጃ ማግኘት እንደሚቻል አስቀድመን አውቀናል.

PlantUML እና በመጠቀም ይህ ምን ሊመስል እንደሚችል የሚያሳይ ትንሽ ምሳሌ እዚህ አለ። የማሳያ ዳታቤዝ ለ PostgreSQL (በግራ በኩል ለ PlantUML አስፈላጊውን መመሪያ የሚያመነጭ የSQL ጥያቄ አለ ፣ እና በቀኝ በኩል ውጤቱ አለ)

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'

በቅርበት የምትመለከቱ ከሆነ፣ ብዙ የእይታ መሳሪያዎች እንዲሁ ተመሳሳይ መጠይቆችን ይጠቀማሉ። እውነት ነው፣ እነዚህ ጥያቄዎች አብዛኛውን ጊዜ ጥልቅ ናቸው። በመተግበሪያው ኮድ ውስጥ "ሃርድዌር የተደረገ" እና ለመረዳት አስቸጋሪ ናቸው, ምንም ዓይነት ማሻሻያዎችን መጥቀስ አይደለም.

መለኪያዎች እና ክትትል

ወደ ባህላዊ ውስብስብ ርዕስ እንሂድ - የውሂብ ጎታ አፈፃፀም ክትትል። “ከጓደኞቼ አንዱ” የነገረኝ ትንሽ እውነተኛ ታሪክ አስታውሳለሁ። በሌላ ፕሮጀክት ላይ አንድ ኃይለኛ ዲቢኤ ይኖር ነበር ፣ እና ጥቂት ገንቢዎች እሱን በግል ያውቁታል ፣ ወይም በአካል አይተውት የማያውቁ (ምንም እንኳን በወሬው መሠረት ፣ በሚቀጥለው ሕንፃ ውስጥ አንድ ቦታ ሠርቷል) . በሰዓት “X” ፣ የአንድ ትልቅ ቸርቻሪ የመግዛት ስርዓት እንደገና “መጥፎ ስሜት” መሰማት ሲጀምር ፣ ከኦራክል ኢንተርፕራይዝ ሥራ አስኪያጅ የግራፍ ምስሎችን በፀጥታ ላከ ፣ በዚህ ላይ “ለመረዳት” በቀይ ምልክት ማድረጊያ ወሳኝ ቦታዎችን በጥንቃቄ ገልጿል ( ይህ, በትንሹ ለማስቀመጥ, ብዙ አልረዳም). እና በዚህ "የፎቶ ካርድ" ላይ በመመስረት ማከም ነበረብኝ. በተመሳሳይ ጊዜ ማንም ሰው ውድ የሆነውን (በሁለቱም የቃሉ ትርጉም) የኢንተርፕራይዝ ሥራ አስኪያጅን ማግኘት አልቻለም, ምክንያቱም ስርዓቱ ውስብስብ እና ውድ ነው, በድንገት "ገንቢዎቹ በአንድ ነገር ይሰናከላሉ እና ሁሉንም ነገር ይሰብራሉ." ስለዚህ, ገንቢዎቹ "በተጨባጭ" የፍሬን ቦታን እና መንስኤን አግኝተው አንድ ንጣፍ ለቀቁ. የዲቢኤ አስጊ ደብዳቤ በቅርብ ጊዜ ውስጥ እንደገና ካልደረሰ፣ ሁሉም ሰው እፎይታ ተነፈሰ እና ወደ አሁን ተግባራቸው ይመለሱ ነበር (እስከ አዲሱ ደብዳቤ)።

ነገር ግን የክትትል ሂደቱ የበለጠ አስደሳች እና ተግባቢ ሊመስል ይችላል, እና ከሁሉም በላይ, ለሁሉም ሰው ተደራሽ እና ግልጽነት ያለው. ቢያንስ መሠረታዊው ክፍል, ከዋናው የክትትል ስርዓቶች በተጨማሪ (በእርግጥ ጠቃሚ እና በብዙ ሁኔታዎች የማይተኩ). ማንኛውም DBMS አሁን ስላለው ሁኔታ እና አፈፃፀሙ መረጃን ለማጋራት በነጻ እና በፍጹም ከክፍያ ነጻ ነው። በተመሳሳዩ “ደም አፍሳሽ” Oracle DB ውስጥ ፣ ስለ አፈፃፀም ማንኛውም መረጃ ከስርዓት እይታዎች ሊገኝ ይችላል ፣ ከሂደቶች እና ክፍለ-ጊዜዎች እስከ የቋት መሸጎጫ ሁኔታ (ለምሳሌ ፣ DBA ስክሪፕቶች, ክፍል "ክትትል"). Postgresql እንዲሁም አጠቃላይ የስርዓት እይታዎች አሉት የውሂብ ጎታ ክትትልበተለይም በማንኛውም ዲቢኤ የዕለት ተዕለት ሕይወት ውስጥ አስፈላጊ የሆኑትን እንደ pg_stat_እንቅስቃሴ, pg_stat_ዳታቤዝ, pg_stat_bgwriter. MySQL እንኳን ለዚህ የተለየ እቅድ አለው። የአፈጻጸም_መርሃግብር. ሞንጎ ውስጥ አብሮ የተሰራ ፕሮፋይለር የአፈጻጸም መረጃን ወደ የስርዓት ስብስብ ይሰበስባል ስርዓት.መገለጫ.

ስለዚህ፣ ብጁ sql መጠይቆችን ሊፈጽም የሚችል ሜትሪክ ሰብሳቢ (Telegraf፣ Metricbeat፣ የተሰበሰበ)፣ የእነዚህን መለኪያዎች ማከማቻ (InfluxDB፣ Elasticsearch፣ Timescaledb) እና ቪዛይዘር (ግራፋና፣ ኪባና)፣ በቀላሉ ማግኘት ይችላሉ። እና ተለዋዋጭ የክትትል ስርዓት ከሌሎች የስርዓተ-ሰፊ ልኬቶች (ለምሳሌ ከመተግበሪያው አገልጋይ ፣ ከስርዓተ ክወናው ፣ ወዘተ. የተገኘ) ጋር በቅርበት ይጣመራል። ለምሳሌ፣ ይህ የሚደረገው በpgwatch2 ውስጥ ነው፣ እሱም የ InfluxDB + Grafana ጥምርን እና የስርዓት እይታዎችን የሚጠቀም፣ እንዲሁም ሊደረስበት ይችላል ብጁ መጠይቆችን ያክሉ.

ԸՆԴՀԱՆՈՒՐ ԳԻՆ

እና ይሄ በመደበኛ የ SQL ኮድ በመጠቀም በእኛ የውሂብ ጎታ ምን ሊደረግ የሚችል ግምታዊ ዝርዝር ብቻ ነው። ብዙ ተጨማሪ አጠቃቀሞችን ማግኘት እንደሚችሉ እርግጠኛ ነኝ, በአስተያየቶቹ ውስጥ ይፃፉ. እና እንዴት (እና ከሁሉም በላይ ለምን) ይህንን ሁሉ በራስ-ሰር እንደማስኬድ እና በሚቀጥለው ጊዜ በ CI/CD ቧንቧዎ ውስጥ እንደሚያካትተው እንነጋገራለን.

ምንጭ: hab.com