"કોડ તરીકે ડેટાબેઝ" અનુભવ

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માંથી તમામ રસને સ્ક્વિઝ કરવાની ક્ષમતાને નોંધે છે. પરિણામે, "ડેટા-સેન્ટ્રીક" પ્રોજેક્ટ્સ દેખાય છે, જ્યાં ખાસ પ્રશિક્ષિત લોકો ડેટાબેઝમાં સામેલ હોય છે (તેઓ "મૂળવાદી" પણ છે, તેઓ "મૂળવાદી" પણ છે, તેઓ "બેઝડેનર" વગેરે પણ છે), અને વિકાસકર્તાઓ વિગતોમાં ગયા વિના, ફક્ત તૈયાર વ્યૂ અને સંગ્રહિત પ્રક્રિયાઓને "ખેંચવા" પડશે.

જો આપણી પાસે બંને વિશ્વનું શ્રેષ્ઠ હોત તો? જીવનને સમર્થન આપતા નામ સાથે અદ્ભુત સાધનમાં આ કેવી રીતે થાય છે Yesql. હું મારા મફત અનુવાદમાં સામાન્ય ખ્યાલમાંથી બે લીટીઓ આપીશ, અને તમે તેની સાથે વધુ વિગતવાર પરિચિત થઈ શકો છો અહીં.

DSL બનાવવા માટે Clojure એ એક સરસ ભાષા છે, પરંતુ SQL પોતે એક સરસ DSL છે, અને અમને બીજાની જરૂર નથી. એસ-અભિવ્યક્તિઓ મહાન છે, પરંતુ તેઓ અહીં કંઈપણ નવું ઉમેરતા નથી. પરિણામે, અમે કૌંસની ખાતર કૌંસ મેળવીએ છીએ. સંમત નથી? પછી તે ક્ષણની રાહ જુઓ જ્યારે ડેટાબેઝ પરનું એબ્સ્ટ્રેક્શન લીક થવાનું શરૂ થાય અને તમે ફંક્શન સાથે લડવાનું શરૂ કરો. (ra-sql)

તો મારે શું કરવું જોઈએ? ચાલો 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 સપોર્ટ છે. એસક્યુએલને એસક્યુએલ તરીકે સાચવીને તમે તેનો ઉપયોગ કરી શકો છો.
• ટીમ સુસંગતતા. તમારા DBAs તમે તમારા Clojure પ્રોજેક્ટમાં ઉપયોગ કરો છો તે SQL વાંચી અને લખી શકે છે.
• સરળ પ્રદર્શન ટ્યુનિંગ. સમસ્યારૂપ ક્વેરી માટે યોજના બનાવવાની જરૂર છે? જ્યારે તમારી ક્વેરી નિયમિત SQL હોય ત્યારે આ કોઈ સમસ્યા નથી.
• ક્વેરીનો ફરીથી ઉપયોગ કરી રહ્યાં છીએ. તે જ SQL ફાઇલોને અન્ય પ્રોજેક્ટ્સમાં ખેંચો અને છોડો કારણ કે તે માત્ર સાદા જૂના SQL છે - ફક્ત તેને શેર કરો.

મારા મતે, આ વિચાર ખૂબ જ સરસ છે અને તે જ સમયે ખૂબ જ સરળ છે, જેના કારણે પ્રોજેક્ટને ઘણા લાભ મળ્યા છે અનુયાયીઓ વિવિધ ભાષાઓમાં. અને અમે આગળ ઓઆરએમથી આગળની દરેક વસ્તુથી SQL કોડને અલગ કરવાની સમાન ફિલસૂફી લાગુ કરવાનો પ્રયાસ કરીશું.

IDE અને DB મેનેજર

ચાલો એક સરળ રોજિંદા કાર્યથી શરૂઆત કરીએ. ઘણી વાર આપણે ડેટાબેઝમાં અમુક ઑબ્જેક્ટ્સ શોધવાના હોય છે, ઉદાહરણ તરીકે, સ્કીમામાં ટેબલ શોધો અને તેની રચનાનો અભ્યાસ કરો (કયા કૉલમ, કી, ઇન્ડેક્સ, અવરોધો વગેરેનો ઉપયોગ થાય છે). અને કોઈપણ ગ્રાફિકલ IDE અથવા થોડા DB-મેનેજર પાસેથી, સૌ પ્રથમ, અમે આ ક્ષમતાઓની બરાબર અપેક્ષા રાખીએ છીએ. જેથી તે ઝડપી હોય અને જરૂરી માહિતી સાથેની વિન્ડો દોરવામાં ન આવે ત્યાં સુધી તમારે અડધો કલાક રાહ જોવી ન પડે (ખાસ કરીને રિમોટ ડેટાબેઝ સાથે ધીમા જોડાણ સાથે), અને તે જ સમયે, પ્રાપ્ત માહિતી તાજી અને સુસંગત હોય, અને કેશ્ડ જંક નથી. તદુપરાંત, વધુ જટિલ અને વિશાળ ડેટાબેઝ અને તેમની સંખ્યા જેટલી વધારે છે, આ કરવાનું વધુ મુશ્કેલ છે.

પરંતુ સામાન્ય રીતે હું માઉસને ફેંકી દઉં છું અને માત્ર કોડ લખું છું. ચાલો કહીએ કે તમારે "HR" સ્કીમામાં કયા કોષ્ટકો (અને કયા ગુણધર્મો સાથે) સમાયેલ છે તે શોધવાની જરૂર છે. મોટાભાગના DBMS માં, માહિતી_સ્કેમાની આ સરળ ક્વેરી દ્વારા ઇચ્છિત પરિણામ પ્રાપ્ત કરી શકાય છે:

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'

ક્લિકહાઉસ કોઈ અપવાદ નથી:

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 ની ક્ષમતાઓ. મારું મનપસંદ ઉદાહરણ એ છે કે ઓરેકલ દસ્તાવેજીકરણમાં "ટેબલ બનાવો" વાક્યરચના માટે માત્ર "નગ્ન" BNF છે 31 પૃષ્ઠો ફાળવો. અન્ય ડીબીએમએસમાં વધુ સાધારણ ક્ષમતાઓ છે, પરંતુ તેમાંના દરેકમાં કોષ્ટકો બનાવવા માટે ઘણી રસપ્રદ અને અનન્ય સુવિધાઓ પણ છે (પોસ્ટગ્રેસ, 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'

અને જો તમે થોડો પ્રયાસ કરો છો, તો પછી તેના આધારે 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'

જો તમે નજીકથી જુઓ, તો હૂડ હેઠળ ઘણા વિઝ્યુલાઇઝેશન ટૂલ્સ પણ સમાન પ્રશ્નોનો ઉપયોગ કરે છે. સાચું, આ વિનંતીઓ સામાન્ય રીતે ઊંડે છે એપ્લિકેશનના કોડમાં જ "હાર્ડવાયર" અને સમજવું મુશ્કેલ છે, તેમાંના કોઈપણ ફેરફારનો ઉલ્લેખ ન કરવો.

મેટ્રિક્સ અને મોનીટરીંગ

ચાલો પરંપરાગત રીતે જટિલ વિષય પર આગળ વધીએ - ડેટાબેઝ પ્રદર્શન મોનીટરીંગ. મને "મારા એક મિત્ર" દ્વારા કહેલી એક નાની સત્ય ઘટના યાદ છે. અન્ય પ્રોજેક્ટ પર ત્યાં એક ચોક્કસ શક્તિશાળી ડીબીએ રહેતો હતો, અને કેટલાક વિકાસકર્તાઓ તેમને વ્યક્તિગત રૂપે જાણતા હતા, અથવા તેમને ક્યારેય રૂબરૂમાં જોયા હતા (તે હકીકત હોવા છતાં કે, અફવાઓ અનુસાર, તેણે આગલી બિલ્ડિંગમાં ક્યાંક કામ કર્યું હતું). કલાક “X” પર, જ્યારે મોટા રિટેલરની પોડક્શન સિસ્ટમ ફરી એકવાર “ખરાબ લાગવા લાગી”, ત્યારે તેણે શાંતિપૂર્વક ઓરેકલ એન્ટરપ્રાઇઝ મેનેજર પાસેથી ગ્રાફના સ્ક્રીનશૉટ્સ મોકલ્યા, જેના પર તેણે “સમજણક્ષમતા” માટે લાલ માર્કર સાથે મહત્વપૂર્ણ સ્થાનોને કાળજીપૂર્વક પ્રકાશિત કર્યા ( આ, તેને હળવાશથી કહીએ તો, બહુ મદદ કરી નથી). અને આ "ફોટો કાર્ડ" ના આધારે મારે સારવાર કરવી પડી. તે જ સમયે, કિંમતી (શબ્દના બંને અર્થમાં) એન્ટરપ્રાઇઝ મેનેજર સુધી કોઈની પહોંચ નહોતી, કારણ કે સિસ્ટમ જટિલ અને ખર્ચાળ છે, અચાનક "વિકાસકર્તાઓ કંઈક પર ઠોકર ખાય છે અને બધું તોડી નાખે છે." તેથી, વિકાસકર્તાઓએ "અનુભાવિક રીતે" બ્રેક્સનું સ્થાન અને કારણ શોધી કાઢ્યું અને પેચ બહાર પાડ્યો. જો નજીકના ભવિષ્યમાં DBA તરફથી ભયજનક પત્ર ફરીથી ન આવે, તો દરેક વ્યક્તિ રાહતનો શ્વાસ લેશે અને તેમના વર્તમાન કાર્યો પર પાછા ફરશે (નવા પત્ર સુધી).

પરંતુ મોનિટરિંગ પ્રક્રિયા વધુ મનોરંજક અને મૈત્રીપૂર્ણ દેખાઈ શકે છે, અને સૌથી અગત્યનું, દરેક માટે સુલભ અને પારદર્શક છે. ઓછામાં ઓછું તેનો મૂળભૂત ભાગ, મુખ્ય મોનિટરિંગ સિસ્ટમ્સમાં વધારા તરીકે (જે ચોક્કસપણે ઉપયોગી છે અને ઘણા કિસ્સાઓમાં બદલી ન શકાય તેવું છે). કોઈપણ DBMS તેની વર્તમાન સ્થિતિ અને કામગીરી વિશેની માહિતી શેર કરવા માટે મુક્તપણે અને સંપૂર્ણપણે મફત છે. સમાન "લોહિયાળ" ઓરેકલ ડીબીમાં, કાર્યક્ષમતા વિશેની લગભગ કોઈપણ માહિતી સિસ્ટમ દૃશ્યોમાંથી મેળવી શકાય છે, પ્રક્રિયાઓ અને સત્રોથી લઈને બફર કેશની સ્થિતિ સુધી (ઉદાહરણ તરીકે, DBA સ્ક્રિપ્ટ્સ, વિભાગ "મોનિટરિંગ"). Postgresql પણ માટે સિસ્ટમ દૃશ્યોનો સંપૂર્ણ સમૂહ ધરાવે છે ડેટાબેઝ મોનીટરીંગ, ખાસ કરીને જે કોઈપણ DBA ના રોજિંદા જીવનમાં અનિવાર્ય છે, જેમ કે pg_stat_activity, pg_stat_database, pg_stat_bgwriter. MySQL પાસે આ માટે એક અલગ સ્કીમા પણ છે. પ્રદર્શન_સ્કીમા. A In Mongo બિલ્ટ-ઇન પ્રોફાઇલર સિસ્ટમ સંગ્રહમાં પ્રદર્શન ડેટાને એકીકૃત કરે છે system.profile.

આમ, અમુક પ્રકારના મેટ્રિક્સ કલેક્ટર (ટેલિગ્રાફ, મેટ્રિકબીટ, કલેક્ટેડ)થી સજ્જ કે જે કસ્ટમ sql ક્વેરી કરી શકે, આ મેટ્રિક્સનો સંગ્રહ (InfluxDB, Elasticsearch, Timescaledb) અને વિઝ્યુલાઈઝર (Grafana, Kibana), તમે એકદમ સરળ રીતે મેળવી શકો છો. અને એક લવચીક મોનિટરિંગ સિસ્ટમ કે જે અન્ય સિસ્ટમ-વ્યાપી મેટ્રિક્સ સાથે નજીકથી સંકલિત હશે (ઉદાહરણ તરીકે, એપ્લિકેશન સર્વરમાંથી, OS, વગેરેમાંથી મેળવેલ). જેમ કે, ઉદાહરણ તરીકે, આ pgwatch2 માં કરવામાં આવે છે, જે InfluxDB + Grafana કોમ્બિનેશનનો ઉપયોગ કરે છે અને સિસ્ટમ વ્યૂ માટે ક્વેરીનો સમૂહ વાપરે છે, જેને એક્સેસ પણ કરી શકાય છે. કસ્ટમ પ્રશ્નો ઉમેરો.

કુલ

અને નિયમિત SQL કોડનો ઉપયોગ કરીને અમારા ડેટાબેઝ સાથે શું કરી શકાય તેની આ માત્ર અંદાજિત સૂચિ છે. મને ખાતરી છે કે તમે ઘણા વધુ ઉપયોગો શોધી શકશો, ટિપ્પણીઓમાં લખો. અને અમે આ બધું કેવી રીતે (અને સૌથી અગત્યનું શા માટે) સ્વચાલિત કરવું અને તેને આગલી વખતે તમારી CI/CD પાઇપલાઇનમાં શામેલ કરવું તે વિશે વાત કરીશું.

સોર્સ: www.habr.com