"ഡാറ്റാബേസ് കോഡ്" അനുഭവം

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. എന്റെ സ്വതന്ത്ര വിവർത്തനത്തിൽ പൊതുവായ ആശയത്തിൽ നിന്ന് ഞാൻ രണ്ട് വരികൾ നൽകും, നിങ്ങൾക്ക് ഇത് കൂടുതൽ വിശദമായി പരിചയപ്പെടാം. ഇവിടെ.

DSL-കൾ സൃഷ്ടിക്കുന്നതിനുള്ള ഒരു രസകരമായ ഭാഷയാണ് Clojure, എന്നാൽ 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 "some('funky'::SYNTAX)")).
• മികച്ച എഡിറ്റർ പിന്തുണ. നിങ്ങളുടെ എഡിറ്റർക്ക് ഇതിനകം തന്നെ മികച്ച SQL പിന്തുണയുണ്ട്. SQL-നെ SQL ആയി സേവ് ചെയ്യുന്നതിലൂടെ നിങ്ങൾക്ക് അത് ഉപയോഗിക്കാൻ കഴിയും.
• ടീം അനുയോജ്യത. നിങ്ങളുടെ ക്ലോജൂർ പ്രോജക്റ്റിൽ നിങ്ങൾ ഉപയോഗിക്കുന്ന SQL വായിക്കാനും എഴുതാനും നിങ്ങളുടെ DBA-കൾക്ക് കഴിയും.
• എളുപ്പത്തിലുള്ള പ്രകടന ട്യൂണിംഗ്. പ്രശ്നമുള്ള ഒരു ചോദ്യത്തിന് ഒരു പ്ലാൻ നിർമ്മിക്കേണ്ടതുണ്ടോ? നിങ്ങളുടെ അന്വേഷണം സാധാരണ SQL ആയിരിക്കുമ്പോൾ ഇത് ഒരു പ്രശ്നമല്ല.
• ചോദ്യങ്ങൾ വീണ്ടും ഉപയോഗിക്കുന്നു. അതേ SQL ഫയലുകൾ മറ്റ് പ്രോജക്റ്റുകളിലേക്ക് വലിച്ചിടുക, കാരണം ഇത് വെറും പഴയ SQL ആണ് - അത് പങ്കിടുക.

എന്റെ അഭിപ്രായത്തിൽ, ആശയം വളരെ രസകരവും അതേ സമയം വളരെ ലളിതവുമാണ്, പ്രോജക്റ്റ് പലരെയും നേടിയതിന് നന്ദി അനുയായികൾ വിവിധ ഭാഷകളിൽ. ORM-ന് അപ്പുറത്തുള്ള എല്ലാത്തിൽ നിന്നും SQL കോഡ് വേർതിരിക്കുന്ന സമാനമായ ഒരു തത്വശാസ്ത്രം പ്രയോഗിക്കാൻ ഞങ്ങൾ അടുത്തതായി ശ്രമിക്കും.

IDE & DB മാനേജർമാർ

ലളിതമായ ദൈനംദിന ജോലിയിൽ നിന്ന് നമുക്ക് ആരംഭിക്കാം. പലപ്പോഴും നമ്മൾ ഡാറ്റാബേസിൽ ചില ഒബ്ജക്റ്റുകൾക്കായി തിരയേണ്ടതുണ്ട്, ഉദാഹരണത്തിന്, സ്കീമയിൽ ഒരു പട്ടിക കണ്ടെത്തി അതിന്റെ ഘടന പഠിക്കുക (ഏത് നിരകൾ, കീകൾ, സൂചികകൾ, നിയന്ത്രണങ്ങൾ മുതലായവ ഉപയോഗിക്കുന്നു). ഏതെങ്കിലും ഗ്രാഫിക്കൽ IDE അല്ലെങ്കിൽ ഒരു ചെറിയ DB-മാനേജറിൽ നിന്ന്, ഒന്നാമതായി, ഈ കഴിവുകൾ ഞങ്ങൾ പ്രതീക്ഷിക്കുന്നു. അതിനാൽ ഇത് വേഗതയുള്ളതും ആവശ്യമായ വിവരങ്ങളുള്ള ഒരു വിൻഡോ വരുന്നതുവരെ നിങ്ങൾ അര മണിക്കൂർ കാത്തിരിക്കേണ്ടതില്ല (പ്രത്യേകിച്ച് ഒരു റിമോട്ട് ഡാറ്റാബേസിലേക്കുള്ള വേഗത കുറഞ്ഞ കണക്ഷൻ), അതേ സമയം, ലഭിച്ച വിവരങ്ങൾ പുതിയതും പ്രസക്തവുമാണ്, കൂടാതെ കാഷെ ചെയ്ത ജങ്ക് അല്ല. മാത്രമല്ല, കൂടുതൽ സങ്കീർണ്ണവും വലുതുമായ ഡാറ്റാബേസും അവയുടെ എണ്ണം കൂടുന്നതിനനുസരിച്ച് ഇത് ചെയ്യുന്നത് കൂടുതൽ ബുദ്ധിമുട്ടാണ്.

എന്നാൽ സാധാരണയായി ഞാൻ മൗസ് വലിച്ചെറിഞ്ഞ് കോഡ് എഴുതുന്നു. "HR" സ്കീമയിൽ അടങ്ങിയിരിക്കുന്ന പട്ടികകൾ (ഏതൊക്കെ പ്രോപ്പർട്ടികൾ ഉള്ളത്) നിങ്ങൾ കണ്ടെത്തേണ്ടതുണ്ടെന്ന് നമുക്ക് പറയാം. മിക്ക DBMS-കളിലും, information_schema-യിൽ നിന്നുള്ള ഈ ലളിതമായ ചോദ്യം ഉപയോഗിച്ച് ആവശ്യമുള്ള ഫലം നേടാനാകും:

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

ഡാറ്റാബേസ് മുതൽ ഡാറ്റാബേസ് വരെ, അത്തരം റഫറൻസ് ടേബിളുകളുടെ ഉള്ളടക്കങ്ങൾ ഓരോ ഡിബിഎംഎസിന്റെയും കഴിവുകളെ ആശ്രയിച്ച് വ്യത്യാസപ്പെടുന്നു. കൂടാതെ, ഉദാഹരണത്തിന്, 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 അറിയില്ല, പക്ഷേ അതിനുണ്ട് ഒറാക്കിൾ മെറ്റാഡാറ്റ, വലിയ പ്രശ്നങ്ങളൊന്നും ഉണ്ടാകില്ല:

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 പ്ലാറ്റ്‌ഫോമിൽ IDE-കൾക്ക് എന്തുചെയ്യാൻ കഴിയും").

വസ്തുക്കളുമായുള്ള പ്രവർത്തനങ്ങൾ

ആവശ്യമായ വസ്തുക്കൾ ഞങ്ങൾ കണ്ടെത്തി പഠിച്ച ശേഷം, അവ ഉപയോഗിച്ച് ഉപയോഗപ്രദമായ എന്തെങ്കിലും ചെയ്യാൻ സമയമായി. സ്വാഭാവികമായും, കീബോർഡിൽ നിന്ന് വിരലുകൾ എടുക്കാതെ തന്നെ.

ഒരു പട്ടിക ഇല്ലാതാക്കുന്നത് മിക്കവാറും എല്ലാ ഡാറ്റാബേസുകളിലും ഒരുപോലെ കാണപ്പെടുമെന്നത് രഹസ്യമല്ല:

drop table hr.persons

എന്നാൽ പട്ടികയുടെ സൃഷ്ടിയോടെ അത് കൂടുതൽ രസകരമാണ്. മിക്കവാറും എല്ലാ DBMS-നും (നിരവധി NoSQL ഉൾപ്പെടെ) ഒരു രൂപത്തിൽ അല്ലെങ്കിൽ മറ്റൊന്നിൽ "പട്ടിക സൃഷ്‌ടിക്കാൻ" കഴിയും, മാത്രമല്ല അതിന്റെ പ്രധാന ഭാഗം അല്പം പോലും വ്യത്യാസപ്പെട്ടിരിക്കും (പേര്, നിരകളുടെ പട്ടിക, ഡാറ്റ തരങ്ങൾ), എന്നാൽ മറ്റ് വിശദാംശങ്ങൾ നാടകീയമായി വ്യത്യാസപ്പെട്ടിരിക്കും ഒരു പ്രത്യേക ഡിബിഎംഎസിന്റെ ആന്തരിക ഉപകരണവും കഴിവുകളും. ഒറാക്കിൾ ഡോക്യുമെന്റേഷനിൽ "ടേബിൾ സൃഷ്‌ടിക്കുക" എന്ന വാക്യഘടനയ്‌ക്കായി "നഗ്ന" BNF-കൾ മാത്രമേ ഉള്ളൂ എന്നതാണ് എന്റെ പ്രിയപ്പെട്ട ഉദാഹരണം. 31 പേജുകൾ ഉൾക്കൊള്ളുന്നു. മറ്റ് DBMS-കൾക്ക് കൂടുതൽ മിതമായ കഴിവുകളുണ്ട്, എന്നാൽ അവയിൽ ഓരോന്നിനും പട്ടികകൾ സൃഷ്ടിക്കുന്നതിന് രസകരവും അതുല്യവുമായ നിരവധി സവിശേഷതകൾ ഉണ്ട് (പോസ്റ്റ്ഗ്രെസ്, ക്യു, പാറ്റ, കാസന്ദ്ര). മറ്റൊരു ഐഡിഇയിൽ നിന്നുള്ള (പ്രത്യേകിച്ച് സാർവത്രികമായത്) ഏതെങ്കിലും ഗ്രാഫിക്കൽ "വിസാർഡിന്" ഈ കഴിവുകളെല്ലാം പൂർണ്ണമായി ഉൾക്കൊള്ളാൻ കഴിയാൻ സാധ്യതയില്ല, അതിന് കഴിയുമെങ്കിലും, അത് ഹൃദയത്തിന്റെ തളർച്ചയ്ക്ക് ഒരു കാഴ്ചയല്ല. അതേ സമയം, കൃത്യവും സമയബന്ധിതവുമായ രേഖാമൂലമുള്ള പ്രസ്താവന പട്ടിക സൃഷ്ടിക്കുക അവയെല്ലാം എളുപ്പത്തിൽ ഉപയോഗിക്കാനും സംഭരണവും നിങ്ങളുടെ ഡാറ്റയിലേക്കുള്ള പ്രവേശനവും വിശ്വസനീയവും ഒപ്റ്റിമലും കഴിയുന്നത്ര സൗകര്യപ്രദവുമാക്കാൻ നിങ്ങളെ അനുവദിക്കും.

കൂടാതെ, പല 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'

നിങ്ങൾ അൽപ്പം ശ്രമിച്ചാൽ, അടിസ്ഥാനമാക്കി 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" മണിക്കൂറിൽ, ഒരു വലിയ ചില്ലറ വ്യാപാരിയുടെ പോഡക്ഷൻ സിസ്റ്റം ഒരിക്കൽ കൂടി "മോശം" അനുഭവിക്കാൻ തുടങ്ങിയപ്പോൾ, അദ്ദേഹം ഒറാക്കിൾ എന്റർപ്രൈസ് മാനേജരിൽ നിന്ന് ഗ്രാഫുകളുടെ സ്ക്രീൻഷോട്ടുകൾ നിശബ്ദമായി അയച്ചു, അതിൽ "ഗ്രഹണക്ഷമത" എന്നതിനായി ചുവന്ന മാർക്കർ ഉപയോഗിച്ച് നിർണായക സ്ഥലങ്ങൾ ശ്രദ്ധാപൂർവ്വം ഹൈലൈറ്റ് ചെയ്തു ( ഇത്, മിതമായ രീതിയിൽ പറഞ്ഞാൽ, അധികം സഹായിച്ചില്ല). ഈ "ഫോട്ടോ കാർഡ്" അടിസ്ഥാനമാക്കി എനിക്ക് ചികിത്സിക്കേണ്ടി വന്നു. അതേ സമയം, വിലയേറിയ (വാക്കിന്റെ രണ്ട് അർത്ഥത്തിലും) എന്റർപ്രൈസ് മാനേജരിലേക്ക് ആർക്കും പ്രവേശനമില്ല, കാരണം സിസ്റ്റം സങ്കീർണ്ണവും ചെലവേറിയതുമാണ്, പെട്ടെന്ന് "ഡെവലപ്പർമാർ എന്തെങ്കിലും ഇടറുകയും എല്ലാം തകർക്കുകയും ചെയ്യുന്നു." അതിനാൽ, ഡവലപ്പർമാർ "അനുഭവപരമായി" ബ്രേക്കുകളുടെ സ്ഥാനവും കാരണവും കണ്ടെത്തി ഒരു പാച്ച് പുറത്തിറക്കി. DBA-യിൽ നിന്നുള്ള ഭീഷണിപ്പെടുത്തുന്ന കത്ത് സമീപഭാവിയിൽ വീണ്ടും വന്നില്ലെങ്കിൽ, എല്ലാവരും ആശ്വാസത്തിന്റെ നെടുവീർപ്പിട്ട് അവരുടെ നിലവിലെ ജോലികളിലേക്ക് മടങ്ങും (പുതിയ കത്ത് വരെ).

എന്നാൽ മോണിറ്ററിംഗ് പ്രക്രിയ കൂടുതൽ രസകരവും സൗഹൃദപരവും, ഏറ്റവും പ്രധാനമായി, എല്ലാവർക്കും ആക്സസ് ചെയ്യാവുന്നതും സുതാര്യവുമാണ്. പ്രധാന മോണിറ്ററിംഗ് സിസ്റ്റങ്ങൾക്ക് ഒരു അധികമായി അതിന്റെ അടിസ്ഥാന ഭാഗമെങ്കിലും (തീർച്ചയായും ഉപയോഗപ്രദവും പല കേസുകളിലും മാറ്റാനാകാത്തതുമാണ്). ഏതൊരു ഡിബിഎംഎസും അതിന്റെ നിലവിലെ അവസ്ഥയെയും പ്രകടനത്തെയും കുറിച്ചുള്ള വിവരങ്ങൾ പങ്കിടുന്നതിന് സൗജന്യമായും തികച്ചും സൗജന്യവുമാണ്. അതേ "ബ്ലഡി" ഒറാക്കിൾ ഡിബിയിൽ, പ്രോസസ്സുകളും സെഷനുകളും മുതൽ ബഫർ കാഷെയുടെ അവസ്ഥ വരെ (ഉദാഹരണത്തിന്, സിസ്റ്റം കാഴ്ചകളിൽ നിന്ന് പ്രകടനത്തെക്കുറിച്ചുള്ള മിക്കവാറും എല്ലാ വിവരങ്ങളും ലഭിക്കും. DBA സ്ക്രിപ്റ്റുകൾ, വിഭാഗം "മോണിറ്ററിംഗ്"). Postgresql-ന് ഒരു കൂട്ടം സിസ്റ്റം കാഴ്ചകളും ഉണ്ട് ഡാറ്റാബേസ് നിരീക്ഷണം, പ്രത്യേകിച്ച് ഏതെങ്കിലും DBA-യുടെ ദൈനംദിന ജീവിതത്തിൽ ഒഴിച്ചുകൂടാനാവാത്തവ pg_stat_activity, pg_stat_database, pg_stat_bgwriter. MySQL-ന് ഇതിനായി ഒരു പ്രത്യേക സ്കീമ പോലും ഉണ്ട്. പ്രകടനം_സ്‌കീമ. എ ഇൻ മോംഗോ ബിൽറ്റ്-ഇൻ പ്രൊഫൈലർ ഒരു സിസ്റ്റം ശേഖരത്തിലേക്ക് പ്രകടന ഡാറ്റ സമാഹരിക്കുന്നു system.profile.

അതിനാൽ, ഇഷ്‌ടാനുസൃത sql അന്വേഷണങ്ങൾ നടത്താൻ കഴിയുന്ന ചിലതരം മെട്രിക്‌സ് കളക്ടർ (ടെലിഗ്രാഫ്, മെട്രിക്‌ബീറ്റ്, കളക്‌റ്റഡ്), ഈ മെട്രിക്കുകളുടെ സംഭരണം (ഇൻഫ്‌ലക്‌സ് ഡിബി, ഇലാസ്റ്റിക്‌സെർച്ച്, ടൈംസ്‌കെലെഡ്‌ബി), ഒരു വിഷ്വലൈസർ (ഗ്രാഫാന, കിബാന) എന്നിവ ഉപയോഗിച്ച് നിങ്ങൾക്ക് വളരെ എളുപ്പത്തിൽ ലഭിക്കും. മറ്റ് സിസ്റ്റം-വൈഡ് മെട്രിക്കുകളുമായി (ഉദാഹരണത്തിന്, ആപ്ലിക്കേഷൻ സെർവറിൽ നിന്ന്, OS-ൽ നിന്ന് മുതലായവ) അടുത്ത് സംയോജിപ്പിച്ചിരിക്കുന്ന ഒരു ഫ്ലെക്സിബിൾ മോണിറ്ററിംഗ് സിസ്റ്റവും. ഉദാഹരണത്തിന്, ഇത് pgwatch2-ലാണ് ചെയ്യുന്നത്, ഇത് InfluxDB + Grafana കോമ്പിനേഷനും സിസ്റ്റം കാഴ്‌ചകളിലേക്കുള്ള ഒരു കൂട്ടം അന്വേഷണങ്ങളും ഉപയോഗിക്കുന്നു, അവയും ആക്‌സസ് ചെയ്യാൻ കഴിയും. ഇഷ്‌ടാനുസൃത ചോദ്യങ്ങൾ ചേർക്കുക.

ആകെ

സാധാരണ SQL കോഡ് ഉപയോഗിച്ച് ഞങ്ങളുടെ ഡാറ്റാബേസിൽ എന്തുചെയ്യാനാകുമെന്നതിന്റെ ഏകദേശ ലിസ്റ്റ് മാത്രമാണിത്. നിങ്ങൾക്ക് കൂടുതൽ ഉപയോഗങ്ങൾ കണ്ടെത്താൻ കഴിയുമെന്ന് എനിക്ക് ഉറപ്പുണ്ട്, അഭിപ്രായങ്ങളിൽ എഴുതുക. ഇതെല്ലാം എങ്ങനെ (ഏറ്റവും പ്രധാനമായി എന്തുകൊണ്ട്) ഓട്ടോമേറ്റ് ചെയ്യാമെന്നും അടുത്ത തവണ നിങ്ങളുടെ CI/CD പൈപ്പ്‌ലൈനിൽ ഉൾപ്പെടുത്താമെന്നും ഞങ്ങൾ സംസാരിക്കും.

അവലംബം: www.habr.com