"ڈیٹا بیس بطور کوڈ" کا تجربہ

SQL، کیا آسان ہو سکتا ہے؟ ہم میں سے ہر ایک سادہ درخواست لکھ سکتا ہے - ہم ٹائپ کرتے ہیں۔ منتخب، پھر مطلوبہ کالموں کی فہرست بنائیں سےٹیبل کا نام، کچھ شرائط میں کہاں اور بس اتنا ہے - مفید ڈیٹا ہماری جیب میں ہے، اور (تقریباً) اس بات سے قطع نظر کہ اس وقت ڈی بی ایم ایس کس کے زیر اثر ہے (یا شاید بالکل بھی DBMS نہیں ہے۔)۔ نتیجے کے طور پر، تقریباً کسی بھی ڈیٹا سورس کے ساتھ کام کرنا (متعلقہ اور ایسا نہیں) کو عام کوڈ کے نقطہ نظر سے سمجھا جا سکتا ہے (اس سب کے ساتھ - ورژن کنٹرول، کوڈ کا جائزہ، جامد تجزیہ، آٹو ٹیسٹ، اور بس)۔ اور یہ نہ صرف خود ڈیٹا، اسکیموں اور منتقلی پر لاگو ہوتا ہے، بلکہ عام طور پر اسٹوریج کی پوری زندگی پر ہوتا ہے۔ اس مضمون میں ہم روزمرہ کے کاموں اور مختلف ڈیٹا بیس کے ساتھ کام کرنے کے مسائل کے بارے میں بات کریں گے "ڈیٹا بیس بطور کوڈ"۔

اور آئیے شروع کرتے ہیں۔ ORM. "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 کے پیروکار اضافی تہوں اور تجریدوں کے بغیر اپنے DBMS سے تمام رس نچوڑ لینے کی صلاحیت کو نوٹ کرتے ہیں۔ نتیجے کے طور پر، "ڈیٹا سینٹرک" پروجیکٹس ظاہر ہوتے ہیں، جہاں خاص طور پر تربیت یافتہ لوگ ڈیٹا بیس میں شامل ہوتے ہیں (وہ "بنیاد پرست" بھی ہوتے ہیں، وہ "بنیاد پرست" بھی ہوتے ہیں، وہ "باسڈینرز" وغیرہ بھی ہوتے ہیں)، اور ڈویلپر تفصیلات میں جانے کے بغیر، صرف تیار شدہ خیالات اور ذخیرہ شدہ طریقہ کار کو "کھینچنا" ہے۔

کیا ہوگا اگر ہمارے پاس دونوں جہانوں میں سے بہترین ہو؟ یہ زندگی کی تصدیق کرنے والے نام کے ساتھ ایک حیرت انگیز ٹول میں کیسے کیا جاتا ہے۔ یس کیو ایل. میں اپنے مفت ترجمہ میں عام تصور سے چند سطریں دوں گا، اور آپ اس سے مزید تفصیل سے واقف ہو سکتے ہیں۔ یہاں.

Clojure DSLs بنانے کے لیے ایک عمدہ زبان ہے، لیکن SQL بذات خود ایک ٹھنڈا DSL ہے، اور ہمیں کسی اور کی ضرورت نہیں ہے۔ ایس ایکسپریشنز بہت اچھے ہیں، لیکن وہ یہاں کوئی نئی چیز شامل نہیں کرتے ہیں۔ نتیجے کے طور پر، ہمیں بریکٹ کی خاطر بریکٹ ملتے ہیں۔ اتفاق نہیں کرتا؟ پھر اس لمحے کا انتظار کریں جب ڈیٹا بیس پر خلاصہ لیک ہونا شروع ہوجائے اور آپ فنکشن سے لڑنا شروع کردیں۔ (raw-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" ...} ...)

"خود ہی سے ایس کیو ایل، خود سے کلوجور" اصول پر عمل کرتے ہوئے، آپ کو ملتا ہے:

• کوئی نحوی حیرت نہیں۔ آپ کا ڈیٹا بیس (کسی دوسرے کی طرح) ایس کیو ایل کے معیار کے مطابق 100٪ نہیں ہے - لیکن اس سے Yesql کے لیے کوئی فرق نہیں پڑتا۔ آپ SQL مساوی نحو کے ساتھ فنکشنز کی تلاش میں وقت ضائع نہیں کریں گے۔ آپ کو کبھی بھی کسی فنکشن میں واپس نہیں جانا پڑے گا۔ (raw-sql "some('funky'::SYNTAX)")).
• بہترین ایڈیٹر سپورٹ۔ آپ کے ایڈیٹر کو پہلے ہی بہترین SQL سپورٹ حاصل ہے۔ ایس کیو ایل کو بطور SQL محفوظ کرکے آپ اسے آسانی سے استعمال کرسکتے ہیں۔
• ٹیم کی مطابقت۔ آپ کے DBAs وہ SQL پڑھ اور لکھ سکتے ہیں جسے آپ اپنے Clojure پروجیکٹ میں استعمال کرتے ہیں۔
• آسان کارکردگی ٹیوننگ. ایک مشکل سوال کے لیے ایک منصوبہ بنانے کی ضرورت ہے؟ جب آپ کا استفسار باقاعدہ SQL ہے تو یہ کوئی مسئلہ نہیں ہے۔
• استفسارات کو دوبارہ استعمال کرنا۔ ان ہی SQL فائلوں کو دوسرے پروجیکٹس میں گھسیٹیں اور چھوڑیں کیونکہ یہ بالکل سادہ پرانا SQL ہے - بس اسے شیئر کریں۔

میری رائے میں، خیال بہت ٹھنڈا ہے اور ایک ہی وقت میں بہت آسان ہے، جس کی بدولت اس منصوبے کو بہت کچھ حاصل ہوا ہے۔ پیروکار مختلف زبانوں میں۔ اور ہم اگلی کوشش کریں گے کہ ایس کیو ایل کوڈ کو ORM سے آگے کی ہر چیز سے الگ کرنے کے اسی طرح کے فلسفے کو لاگو کریں۔

IDE اور DB مینیجرز

آئیے ایک آسان روزمرہ کے کام سے شروع کرتے ہیں۔ اکثر ہمیں ڈیٹا بیس میں کچھ اشیاء تلاش کرنا پڑتی ہیں، مثال کے طور پر، اسکیما میں ایک ٹیبل تلاش کرنا اور اس کی ساخت کا مطالعہ کرنا پڑتا ہے (کون سے کالم، کیز، انڈیکس، رکاوٹیں وغیرہ استعمال ہوتے ہیں)۔ اور کسی بھی گرافیکل IDE یا چھوٹے DB-مینیجر سے، سب سے پہلے، ہم بالکل ان صلاحیتوں کی توقع کرتے ہیں۔ تاکہ یہ تیز ہو اور آپ کو آدھے گھنٹے تک انتظار نہیں کرنا پڑے گا جب تک کہ ضروری معلومات والی ونڈو تیار نہ ہو جائے (خاص طور پر ریموٹ ڈیٹا بیس سے سست روابط کے ساتھ)، اور ساتھ ہی، موصول ہونے والی معلومات تازہ اور متعلقہ ہوں، اور کیش شدہ ردی نہیں۔ مزید یہ کہ ڈیٹا بیس جتنا زیادہ پیچیدہ اور بڑا ہوگا اور ان کی تعداد جتنی زیادہ ہوگی، یہ کرنا اتنا ہی مشکل ہوگا۔

لیکن عام طور پر میں ماؤس کو پھینک دیتا ہوں اور صرف کوڈ لکھتا ہوں۔ ہم کہتے ہیں کہ آپ کو یہ معلوم کرنے کی ضرورت ہے کہ "HR" اسکیما میں کون سی میزیں (اور کن خصوصیات کے ساتھ) موجود ہیں۔ زیادہ تر DBMSs میں، معلومات_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'

کلک ہاؤس کوئی استثنا نہیں ہے:

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'

زیادہ تر دوسرے ڈیٹا بیس کے لیے، آپ اسی طرح کے سوالات کے ساتھ بھی آ سکتے ہیں (یہاں تک کہ مونگو کے پاس بھی ہے۔ خصوصی نظام مجموعہ، جس میں سسٹم میں موجود تمام مجموعوں کے بارے میں معلومات موجود ہیں)۔

بلاشبہ، اس طرح آپ نہ صرف میزوں کے بارے میں، بلکہ عام طور پر کسی بھی چیز کے بارے میں معلومات حاصل کر سکتے ہیں۔ وقتاً فوقتاً، مہربان لوگ مختلف ڈیٹا بیس کے لیے اس طرح کے کوڈ کا اشتراک کرتے ہیں، جیسا کہ، مثال کے طور پر، ہابرا آرٹیکلز کی سیریز میں "پوسٹگری ایس کیو ایل ڈیٹا بیسز کو دستاویز کرنے کے لیے کام" (ایب, بین, جم)۔ بلاشبہ، سوالات کے اس پورے پہاڑ کو میرے سر میں رکھنا اور انہیں مسلسل ٹائپ کرنا بہت خوشی کی بات ہے، اس لیے میرے پسندیدہ IDE/ایڈیٹر میں میرے پاس اکثر استعمال ہونے والے سوالات کے لیے پہلے سے تیار کردہ ٹکڑوں کا سیٹ ہے، اور جو کچھ باقی ہے وہ ٹائپ کرنا ہے۔ ٹیمپلیٹ میں آبجیکٹ کے نام۔

نتیجے کے طور پر، اشیاء کو تلاش کرنے اور تلاش کرنے کا یہ طریقہ بہت زیادہ لچکدار ہے، بہت زیادہ وقت بچاتا ہے، اور آپ کو بالکل وہی معلومات حاصل کرنے کی اجازت دیتا ہے جس شکل میں یہ اب ضروری ہے (جیسا کہ، مثال کے طور پر، پوسٹ میں بیان کیا گیا ہے) "کسی بھی فارمیٹ میں ڈیٹا بیس سے ڈیٹا ایکسپورٹ کرنا: IDEs IntelliJ پلیٹ فارم پر کیا کر سکتے ہیں").

اشیاء کے ساتھ آپریشنز

ضروری اشیاء تلاش کرنے اور ان کا مطالعہ کرنے کے بعد، ان کے ساتھ کچھ مفید کام کرنے کا وقت آگیا ہے۔ قدرتی طور پر، کی بورڈ سے اپنی انگلیاں اتارے بغیر بھی۔

یہ کوئی راز نہیں ہے کہ صرف ٹیبل کو حذف کرنا تقریبا تمام ڈیٹا بیس میں ایک جیسا نظر آئے گا۔

drop table hr.persons

لیکن میز کی تخلیق کے ساتھ یہ زیادہ دلچسپ ہو جاتا ہے. تقریباً کوئی بھی DBMS (بشمول بہت سے NoSQL) کسی نہ کسی شکل میں "ٹیبل بنا سکتا ہے"، اور اس کا مرکزی حصہ بھی تھوڑا سا مختلف ہوگا (نام، کالموں کی فہرست، ڈیٹا کی اقسام)، لیکن دیگر تفصیلات ڈرامائی طور پر مختلف ہو سکتی ہیں اور اس پر منحصر ہیں۔ اندرونی ڈیوائس اور مخصوص DBMS کی صلاحیتیں۔ میری پسندیدہ مثال یہ ہے کہ اوریکل دستاویزات میں "ٹیبل بنائیں" نحو کے لیے صرف "ننگے" BNFs ہیں۔ 31 صفحات پر قبضہ. دیگر DBMSs میں زیادہ معمولی صلاحیتیں ہیں، لیکن ان میں سے ہر ایک میں میزیں بنانے کے لیے بہت سی دلچسپ اور منفرد خصوصیات بھی ہیں (پوسٹ گریڈ, ایس کیو ایل, کاکروچ, کیسینڈرا)۔ اس بات کا امکان نہیں ہے کہ کسی دوسرے IDE (خاص طور پر ایک عالمگیر) کا کوئی بھی گرافیکل "وزرڈ" ان تمام صلاحیتوں کا مکمل احاطہ کر سکے، اور اگر ہو بھی سکے تو یہ دل کے بیہوش لوگوں کے لیے تماشا نہیں ہو گا۔ ایک ہی وقت میں، ایک درست اور بروقت تحریری بیان ٹیبل بنائیں آپ کو ان سب کو آسانی سے استعمال کرنے، ذخیرہ کرنے اور آپ کے ڈیٹا تک رسائی کو قابل بھروسہ، بہترین اور ہر ممکن حد تک آرام دہ بنانے کی اجازت دے گا۔

نیز، بہت سے DBMSs کی اپنی مخصوص قسم کی اشیاء ہوتی ہیں جو دوسرے DBMSs میں دستیاب نہیں ہوتی ہیں۔ مزید برآں، ہم نہ صرف ڈیٹابیس اشیاء پر بلکہ خود DBMS پر بھی آپریشن کر سکتے ہیں، مثال کے طور پر، کسی عمل کو "قتل" کرنا، کچھ میموری ایریا خالی کرنا، ٹریسنگ کو فعال کرنا، "صرف پڑھنے" موڈ پر سوئچ کرنا، اور بہت کچھ۔

اب تھوڑا ڈرا کرتے ہیں۔

سب سے عام کاموں میں سے ایک ڈیٹابیس آبجیکٹ کے ساتھ ایک خاکہ بنانا اور اشیاء اور ان کے درمیان کنکشن کو ایک خوبصورت تصویر میں دیکھنا ہے۔ تقریباً کوئی بھی گرافیکل IDE، علیحدہ "کمانڈ لائن" یوٹیلیٹیز، خصوصی گرافیکل ٹولز اور ماڈلرز ایسا کر سکتے ہیں۔ وہ آپ کے لیے "جتنا بہتر وہ کر سکتے ہیں" کچھ کھینچیں گے، اور آپ اس عمل کو صرف کنفیگریشن فائل میں چند پیرامیٹرز یا انٹرفیس میں چیک باکسز کی مدد سے تھوڑا سا متاثر کر سکتے ہیں۔

لیکن یہ مسئلہ بہت آسان، زیادہ لچکدار اور خوبصورت اور یقیناً کوڈ کی مدد سے حل کیا جا سکتا ہے۔ کسی بھی پیچیدگی کے خاکے بنانے کے لیے، ہمارے پاس متعدد مخصوص مارک اپ لینگوئجز (DOT، GraphML وغیرہ) ہیں، اور ان کے لیے ایپلی کیشنز (GraphViz، PlantUML، Mermaid) کی ایک مکمل بکھری ہوئی ہے جو اس طرح کی ہدایات کو پڑھ سکتی ہے اور انہیں مختلف فارمیٹس میں دیکھ سکتی ہے۔ . ٹھیک ہے، ہم پہلے ہی جانتے ہیں کہ اشیاء اور ان کے درمیان کنکشن کے بارے میں معلومات کیسے حاصل کی جاتی ہیں۔

پلانٹ یو ایم ایل اور استعمال کرتے ہوئے یہ کیسا نظر آسکتا ہے اس کی ایک چھوٹی سی مثال یہ ہے۔ PostgreSQL کے لیے ڈیمو ڈیٹا بیس (بائیں طرف ایک 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'

اور اگر آپ تھوڑی سی کوشش کریں تو اس کی بنیاد پر PlantUML کے لیے ER ٹیمپلیٹ آپ کو ایک حقیقی ER ڈایاگرام سے ملتا جلتا کچھ مل سکتا ہے:

ایس کیو ایل کا استفسار کچھ زیادہ ہی پیچیدہ ہے۔

-- Шапка
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" پر، جب ایک بڑے خوردہ فروش کا پوڈکشن سسٹم ایک بار پھر "برا محسوس کرنے" لگا، تو اس نے خاموشی سے اوریکل انٹرپرائز مینیجر سے گراف کے اسکرین شاٹس بھیجے، جس پر اس نے "فہم" کے لیے سرخ مارکر کے ساتھ اہم جگہوں کو احتیاط سے اجاگر کیا۔ اس کو ہلکے سے کہیں، زیادہ مدد نہیں ملی)۔ اور اس "فوٹو کارڈ" کی بنیاد پر مجھے علاج کرنا پڑا۔ ایک ہی وقت میں، کسی کو قیمتی (لفظ کے دونوں معنوں میں) انٹرپرائز مینیجر تک رسائی نہیں تھی، کیونکہ نظام پیچیدہ اور مہنگا ہے، اچانک "ڈویلپر کسی چیز سے ٹھوکر کھاتے ہیں اور سب کچھ توڑ دیتے ہیں۔" لہذا، ڈویلپرز نے "تجرباتی طور پر" بریکوں کی جگہ اور وجہ کا پتہ لگایا اور ایک پیچ جاری کیا۔ اگر مستقبل قریب میں ڈی بی اے کی طرف سے خطرناک خط دوبارہ نہ آیا، تو ہر کوئی سکون کی سانس لے گا اور اپنے موجودہ کاموں پر واپس آ جائے گا (نئے خط تک)۔

لیکن نگرانی کا عمل زیادہ پرلطف اور دوستانہ، اور سب سے اہم بات، ہر کسی کے لیے قابل رسائی اور شفاف نظر آتا ہے۔ کم از کم اس کا بنیادی حصہ، مرکزی نگرانی کے نظام میں اضافے کے طور پر (جو یقیناً مفید اور بہت سے معاملات میں ناقابل تلافی ہیں)۔ کوئی بھی DBMS اپنی موجودہ حالت اور کارکردگی کے بارے میں معلومات بانٹنے کے لیے آزادانہ اور بالکل مفت ہے۔ اسی "خونی" اوریکل ڈی بی میں، کارکردگی کے بارے میں تقریباً کوئی بھی معلومات سسٹم ویوز سے حاصل کی جا سکتی ہیں، جس میں عمل اور سیشنز سے لے کر بفر کیش کی حالت تک (مثال کے طور پر، ڈی بی اے اسکرپٹس، سیکشن "مانیٹرنگ")۔ Postgresql کے پاس سسٹم کے خیالات کا ایک پورا گروپ بھی ہے۔ ڈیٹا بیس کی نگرانی، خاص طور پر وہ جو کسی بھی DBA کی روزمرہ کی زندگی میں ناگزیر ہیں، جیسے pg_stat_activity, pg_stat_database, pg_stat_bgwriter. مائی ایس کیو ایل کے پاس اس کے لیے ایک الگ اسکیما بھی ہے۔ کارکردگی_سکیما۔. A ان منگو بلٹ ان پروفائلر کارکردگی کے ڈیٹا کو سسٹم کلیکشن میں جمع کرتا ہے۔ system.profile.

اس طرح، کسی قسم کے میٹرکس کلیکٹر (ٹیلی گراف، میٹرک بیٹ، جمع) سے لیس جو حسب ضرورت sql سوالات کر سکتے ہیں، ان میٹرکس کا ذخیرہ (InfluxDB، Elasticsearch، Timescaledb) اور ایک visualizer (Grafana، Kibana)، آپ کافی آسانی سے حاصل کر سکتے ہیں۔ اور ایک لچکدار نگرانی کا نظام جو نظام کے وسیع پیمانے پر دیگر میٹرکس کے ساتھ قریب سے مربوط ہو گا (مثلاً ایپلیکیشن سرور سے، OS سے، وغیرہ)۔ جیسا کہ، مثال کے طور پر، یہ pgwatch2 میں کیا جاتا ہے، جو InfluxDB + Grafana مجموعہ اور سسٹم ویوز کے لیے سوالات کا ایک سیٹ استعمال کرتا ہے، جس تک رسائی بھی کی جا سکتی ہے۔ اپنی مرضی کے سوالات شامل کریں.

مجموعی طور پر

اور یہ صرف ایک تخمینی فہرست ہے جو ہمارے ڈیٹا بیس کے ساتھ باقاعدہ ایس کیو ایل کوڈ کا استعمال کرتے ہوئے کیا جا سکتا ہے۔ مجھے یقین ہے کہ آپ کو اور بھی بہت سے استعمال مل سکتے ہیں، تبصرے میں لکھیں۔ اور ہم اس کے بارے میں بات کریں گے کہ کس طرح (اور سب سے اہم بات یہ ہے کہ) ان سب کو خودکار کیا جائے اور اسے اگلی بار اپنی CI/CD پائپ لائن میں شامل کریں۔

ماخذ: www.habr.com