"কোড হিসাবে ডেটাবেস" অভিজ্ঞতা

এসকিউএল, কি সহজ হতে পারে? আমরা প্রত্যেকে একটি সাধারণ অনুরোধ লিখতে পারি - আমরা টাইপ করি নির্বাচন করা, তারপর প্রয়োজনীয় কলাম তালিকা করুন থেকে, টেবিলের নাম, কিছু শর্ত কোথায় এবং এটিই সব - দরকারী ডেটা আমাদের পকেটে রয়েছে এবং (প্রায়) নির্বিশেষে যে 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;
    }
  ...

মডেলটি চতুর টীকা দিয়ে ঝুলানো হয়েছে, এবং পর্দার আড়ালে কোথাও একটি সাহসী ওআরএম কিছু এসকিউএল কোড তৈরি করে এবং চালায়। যাইহোক, বিকাশকারীরা তাদের ডাটাবেস থেকে বিচ্ছিন্ন করার জন্য তাদের সর্বোচ্চ চেষ্টা করছে কিলোমিটারের বিমূর্ততা সহ, যা কিছু নির্দেশ করে "এসকিউএল ঘৃণা".

ব্যারিকেডের অন্য দিকে, খাঁটি "হস্তনির্মিত" এসকিউএল-এর অনুগামীরা অতিরিক্ত স্তর এবং বিমূর্ততা ছাড়াই তাদের ডিবিএমএস থেকে সমস্ত রস বের করে নেওয়ার ক্ষমতা নোট করে। ফলস্বরূপ, "ডেটা-কেন্দ্রিক" প্রকল্পগুলি উপস্থিত হয়, যেখানে বিশেষভাবে প্রশিক্ষিত ব্যক্তিরা ডাটাবেসের সাথে জড়িত থাকে (তারা "মৌলিকবাদী"ও হয়, তারা "মৌলিকবাদী"ও হয়, তারা "ব্যাসডেনার" ইত্যাদি) এবং বিকাশকারীরা বিস্তারিত না গিয়ে শুধুমাত্র রেডিমেড ভিউ এবং সঞ্চিত পদ্ধতিগুলিকে "টান" দিতে হবে।

আমরা যদি উভয় জগতের সেরা থাকতাম? এটি একটি জীবন-নিশ্চিত নাম সহ একটি দুর্দান্ত সরঞ্জামে কীভাবে করা হয় Yesql. আমি আমার বিনামূল্যে অনুবাদে সাধারণ ধারণা থেকে কয়েকটি লাইন দেব, এবং আপনি আরও বিস্তারিতভাবে এটির সাথে পরিচিত হতে পারেন এখানে.

Clojure হল DSL ​​তৈরির জন্য একটি দুর্দান্ত ভাষা, কিন্তু SQL নিজেই একটি দুর্দান্ত DSL, এবং আমাদের আর একটির প্রয়োজন নেই। এস-এক্সপ্রেশনগুলি দুর্দান্ত, তবে তারা এখানে নতুন কিছু যোগ করে না। ফলস্বরূপ, আমরা বন্ধনীর খাতিরে বন্ধনী পাই। একমত নই? তারপর সেই মুহুর্তের জন্য অপেক্ষা করুন যখন ডাটাবেসের উপর বিমূর্ততা ফাঁস হতে শুরু করে এবং আপনি ফাংশনের সাথে লড়াই শুরু করেন (raw-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" ...} ...)

"নিজেই এসকিউএল, নিজেই ক্লোজার" নীতি মেনে চলার মাধ্যমে, আপনি পাবেন:

• কোন সিনট্যাকটিক চমক নেই। আপনার ডাটাবেস (অন্য যে কোন মত) এসকিউএল স্ট্যান্ডার্ডের সাথে 100% সঙ্গতিপূর্ণ নয় - তবে এটি Yesql এর জন্য কোন ব্যাপার নয়। আপনি SQL সমতুল্য সিনট্যাক্সের সাথে ফাংশনগুলির জন্য শিকারের সময় নষ্ট করবেন না। আপনাকে কখনই একটি ফাংশনে ফিরে যেতে হবে না (raw-sql "some('Funky'::SYNTAX)")).
• সেরা সম্পাদক সমর্থন। আপনার সম্পাদক ইতিমধ্যে চমৎকার SQL সমর্থন আছে. SQL হিসাবে SQL সংরক্ষণ করে আপনি সহজভাবে এটি ব্যবহার করতে পারেন।
• দলের সামঞ্জস্য। আপনার DBAs আপনি আপনার Clojure প্রকল্পে যে SQL ব্যবহার করেন তা পড়তে এবং লিখতে পারে।
• সহজ কর্মক্ষমতা টিউনিং. একটি সমস্যাযুক্ত প্রশ্নের জন্য একটি পরিকল্পনা তৈরি করতে হবে? আপনার ক্যোয়ারী নিয়মিত SQL হলে এটি কোন সমস্যা নয়।
• প্রশ্ন পুনরায় ব্যবহার করা হচ্ছে। সেই একই SQL ফাইলগুলিকে অন্যান্য প্রকল্পে টেনে আনুন এবং ড্রপ করুন কারণ এটি কেবল সাধারণ পুরানো SQL - শুধু এটি ভাগ করুন৷

আমার মতে, ধারণাটি খুব শান্ত এবং একই সময়ে খুব সহজ, ধন্যবাদ যা প্রকল্পটি অনেক অর্জন করেছে অনুসারী বিভিন্ন ভাষায়। এবং আমরা পরবর্তীতে ওআরএম-এর বাইরে অন্য সব কিছু থেকে এসকিউএল কোড আলাদা করার অনুরূপ দর্শন প্রয়োগ করার চেষ্টা করব।

আইডিই এবং ডিবি ম্যানেজার

একটি সাধারণ দৈনন্দিন কাজ দিয়ে শুরু করা যাক। প্রায়শই আমাদের ডাটাবেসের কিছু বস্তুর জন্য অনুসন্ধান করতে হয়, উদাহরণস্বরূপ, স্কিমাতে একটি টেবিল খুঁজে বের করতে হবে এবং এর গঠন অধ্যয়ন করতে হবে (কোন কলাম, কী, সূচক, সীমাবদ্ধতা ইত্যাদি ব্যবহার করা হয়)। এবং যেকোনো গ্রাফিকাল IDE বা সামান্য DB-ম্যানেজার থেকে, প্রথমত, আমরা ঠিক এই ক্ষমতাগুলি আশা করি। যাতে এটি দ্রুত হয় এবং প্রয়োজনীয় তথ্য সহ একটি উইন্ডো আঁকা না হওয়া পর্যন্ত আপনাকে আধা ঘন্টা অপেক্ষা করতে হবে না (বিশেষত দূরবর্তী ডাটাবেসের সাথে একটি ধীর সংযোগের সাথে), এবং একই সময়ে, প্রাপ্ত তথ্যটি তাজা এবং প্রাসঙ্গিক, এবং ক্যাশে আবর্জনা না. তদুপরি, ডাটাবেস যত বেশি জটিল এবং বৃহত্তর এবং তাদের সংখ্যা তত বেশি, এটি করা তত বেশি কঠিন।

কিন্তু সাধারণত আমি মাউস দূরে ফেলে দিয়ে শুধু কোড লিখি। ধরা যাক আপনি "এইচআর" স্কিমাতে কোন টেবিল (এবং কোন বৈশিষ্ট্য সহ) রয়েছে তা খুঁজে বের করতে হবে। বেশিরভাগ 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'

বেশিরভাগ অন্যান্য ডাটাবেসের জন্য, আপনি একই ধরনের প্রশ্ন নিয়ে আসতে পারেন (এমনকি মঙ্গোতেও আছে বিশেষ সিস্টেম সংগ্রহ, যা সিস্টেমের সমস্ত সংগ্রহ সম্পর্কে তথ্য ধারণ করে)।

অবশ্যই, এইভাবে আপনি কেবল টেবিল সম্পর্কে নয়, সাধারণভাবে যে কোনও বস্তু সম্পর্কে তথ্য পেতে পারেন। সময়ে সময়ে, সদয় লোকেরা বিভিন্ন ডাটাবেসের জন্য এই জাতীয় কোড ভাগ করে, যেমন, হাবরা নিবন্ধগুলির সিরিজে "পোস্টগ্রেএসকিউএল ডাটাবেসগুলি নথিভুক্ত করার জন্য কার্যাবলী" (আইবি, বেন, জিম) অবশ্যই, এই সমস্ত প্রশ্নের পর্বতটি আমার মাথায় রাখা এবং ক্রমাগত সেগুলি টাইপ করা একটি আনন্দের বিষয়, তাই আমার প্রিয় IDE/সম্পাদকটিতে আমার কাছে প্রায়শই ব্যবহৃত প্রশ্নের জন্য স্নিপেটগুলির একটি পূর্ব-প্রস্তুত সেট রয়েছে এবং যা অবশিষ্ট থাকে তা হল টাইপ করা টেমপ্লেটে বস্তুর নাম।

ফলস্বরূপ, নেভিগেট করার এবং বস্তুগুলি অনুসন্ধান করার এই পদ্ধতিটি অনেক বেশি নমনীয়, অনেক সময় সাশ্রয় করে এবং আপনাকে এখন প্রয়োজনীয় ফর্মটিতে সঠিক তথ্য পেতে দেয় (উদাহরণস্বরূপ, পোস্টে বর্ণিত "যেকোন বিন্যাসে একটি ডাটাবেস থেকে ডেটা রপ্তানি করা: IntelliJ প্ল্যাটফর্মে IDE গুলি কী করতে পারে").

বস্তুর সঙ্গে অপারেশন

আমরা প্রয়োজনীয় বস্তুগুলি খুঁজে পাওয়ার এবং অধ্যয়ন করার পরে, তাদের সাথে দরকারী কিছু করার সময় এসেছে। স্বাভাবিকভাবেই, কীবোর্ড থেকে আপনার আঙ্গুলগুলি না নিয়েও।

এটি কোনও গোপন বিষয় নয় যে কেবল একটি টেবিল মুছে ফেলা প্রায় সমস্ত ডাটাবেসে একই দেখাবে:

drop table hr.persons

তবে টেবিল তৈরির সাথে সাথে এটি আরও আকর্ষণীয় হয়ে ওঠে। প্রায় যেকোনো ডিবিএমএস (অনেক নোএসকিউএল সহ) এক বা অন্য আকারে "টেবিল তৈরি" করতে পারে এবং এর মূল অংশটি এমনকি সামান্য ভিন্ন হতে পারে (নাম, কলামের তালিকা, ডেটা টাইপ), তবে অন্যান্য বিবরণ নাটকীয়ভাবে ভিন্ন হতে পারে এবং নির্ভর করে অভ্যন্তরীণ ডিভাইস এবং একটি নির্দিষ্ট DBMS এর ক্ষমতা। আমার প্রিয় উদাহরণ হল ওরাকল ডকুমেন্টেশনে "টেবিল তৈরি করুন" সিনট্যাক্সের জন্য শুধুমাত্র "নগ্ন" BNF আছে 31 পৃষ্ঠা দখল. অন্যান্য ডিবিএমএসগুলির আরও শালীন ক্ষমতা রয়েছে, তবে তাদের প্রত্যেকটিতে টেবিল তৈরি করার জন্য অনেক আকর্ষণীয় এবং অনন্য বৈশিষ্ট্য রয়েছে (postgres, মাইএসকিউএল, তেলাপোকা, Cassandra) এটি অসম্ভাব্য যে অন্য আইডিই (বিশেষত একটি সার্বজনীন একটি) থেকে কোন গ্রাফিকাল "উইজার্ড" এই সমস্ত ক্ষমতা সম্পূর্ণরূপে কভার করতে সক্ষম হবে, এবং এমনকি যদি এটি করতে পারে তবে এটি হৃদয়ের অজ্ঞানদের জন্য একটি দর্শন হবে না। একই সময়ে, একটি সঠিকভাবে এবং সময়মত লিখিত বক্তব্য ছক তৈরি কর আপনাকে সহজেই সেগুলির সবগুলি ব্যবহার করতে, স্টোরেজ এবং আপনার ডেটাতে অ্যাক্সেসকে নির্ভরযোগ্য, সর্বোত্তম এবং যতটা সম্ভব আরামদায়ক করার অনুমতি দেবে।

এছাড়াও, অনেক DBMS-এর নিজস্ব নির্দিষ্ট ধরনের অবজেক্ট রয়েছে যা অন্যান্য DBMS-এ পাওয়া যায় না। তদুপরি, আমরা কেবল ডাটাবেস অবজেক্টেই নয়, ডিবিএমএস নিজেই অপারেশন করতে পারি, উদাহরণস্বরূপ, একটি প্রক্রিয়া "হত্যা" করতে, কিছু মেমরি এলাকা খালি করতে, ট্রেসিং সক্ষম করতে, "শুধুমাত্র পড়ার" মোডে স্যুইচ করতে এবং আরও অনেক কিছু।

এবার একটু আঁকা যাক

সবচেয়ে সাধারণ কাজগুলির মধ্যে একটি হল ডাটাবেস অবজেক্টের সাথে একটি ডায়াগ্রাম তৈরি করা এবং একটি সুন্দর ছবিতে বস্তু এবং তাদের মধ্যে সংযোগগুলি দেখা। প্রায় যেকোনো গ্রাফিকাল IDE, আলাদা "কমান্ড লাইন" ইউটিলিটি, বিশেষায়িত গ্রাফিকাল টুল এবং মডেলাররা এটি করতে পারে। তারা আপনার জন্য কিছু আঁকবে "যতটা তারা পারে" এবং আপনি এই প্রক্রিয়াটিকে শুধুমাত্র কনফিগারেশন ফাইলের কয়েকটি প্যারামিটার বা ইন্টারফেসের চেকবক্সের সাহায্যে কিছুটা প্রভাবিত করতে পারেন।

তবে এই সমস্যাটি আরও সহজ, আরও নমনীয় এবং মার্জিত এবং অবশ্যই কোডের সাহায্যে সমাধান করা যেতে পারে। যেকোন জটিলতার ডায়াগ্রাম তৈরি করার জন্য, আমাদের কাছে বেশ কিছু বিশেষায়িত মার্কআপ ভাষা (DOT, GraphML ইত্যাদি) রয়েছে এবং তাদের জন্য অ্যাপ্লিকেশনগুলির একটি সম্পূর্ণ বিক্ষিপ্তকরণ (GraphViz, PlantUML, Mermaid) যা এই ধরনের নির্দেশাবলী পড়তে পারে এবং বিভিন্ন ফর্ম্যাটে তাদের কল্পনা করতে পারে। . ওয়েল, আমরা ইতিমধ্যে জানি কিভাবে বস্তু এবং তাদের মধ্যে সংযোগ সম্পর্কে তথ্য পেতে.

PlantUML এবং ব্যবহার করে এটি দেখতে কেমন হতে পারে তার একটি ছোট উদাহরণ এখানে PostgreSQL এর জন্য ডেমো ডাটাবেস (বাম দিকে একটি এসকিউএল কোয়েরি যা 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 ডায়াগ্রামের অনুরূপ কিছু পেতে পারেন:

এসকিউএল ক্যোয়ারী একটু বেশি জটিল

-- Шапка
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" এ, যখন একটি বড় খুচরা বিক্রেতার পডাকশন সিস্টেমটি আবার "খারাপ" হতে শুরু করে, তখন তিনি নিঃশব্দে ওরাকল এন্টারপ্রাইজ ম্যানেজার থেকে গ্রাফের স্ক্রিনশট পাঠিয়েছিলেন, যার উপর তিনি "বোধগম্যতার" জন্য একটি লাল মার্কার দিয়ে গুরুতর স্থানগুলিকে সাবধানে হাইলাইট করেছিলেন ( এটি, হালকাভাবে বলতে গেলে, খুব বেশি সাহায্য করেনি)। এবং এই "ফটো কার্ড" এর উপর ভিত্তি করে আমাকে চিকিত্সা করতে হয়েছিল। একই সময়ে, মূল্যবান (শব্দের উভয় অর্থেই) এন্টারপ্রাইজ ম্যানেজারে কারও অ্যাক্সেস ছিল না, কারণ সিস্টেমটি জটিল এবং ব্যয়বহুল, হঠাৎ "ডেভেলপাররা কিছুতে হোঁচট খায় এবং সবকিছু ভেঙে দেয়।" অতএব, বিকাশকারীরা "অভিজ্ঞতার সাথে" ব্রেকগুলির অবস্থান এবং কারণ খুঁজে পেয়েছে এবং একটি প্যাচ প্রকাশ করেছে। যদি অদূর ভবিষ্যতে ডিবিএ থেকে ভয়ঙ্কর চিঠি না আসে, তবে সবাই স্বস্তির নিঃশ্বাস ফেলবে এবং তাদের বর্তমান কাজগুলিতে ফিরে যাবে (নতুন চিঠি না হওয়া পর্যন্ত)।

তবে পর্যবেক্ষণ প্রক্রিয়াটি আরও মজাদার এবং বন্ধুত্বপূর্ণ দেখতে পারে এবং সবচেয়ে গুরুত্বপূর্ণভাবে, সবার জন্য অ্যাক্সেসযোগ্য এবং স্বচ্ছ। অন্তত এর মৌলিক অংশ, প্রধান পর্যবেক্ষণ সিস্টেমের সংযোজন হিসাবে (যা অবশ্যই দরকারী এবং অনেক ক্ষেত্রে অপরিবর্তনীয়)। যেকোনো ডিবিএমএস তার বর্তমান অবস্থা এবং কর্মক্ষমতা সম্পর্কে তথ্য শেয়ার করার জন্য অবাধে এবং একেবারে বিনামূল্যে। একই "রক্তাক্ত" ওরাকল ডিবিতে, কার্যক্ষমতা সম্পর্কে প্রায় যেকোন তথ্য সিস্টেম ভিউ থেকে পাওয়া যেতে পারে, প্রক্রিয়া এবং সেশন থেকে শুরু করে বাফার ক্যাশের অবস্থা পর্যন্ত (উদাহরণস্বরূপ, ডিবিএ স্ক্রিপ্ট, বিভাগ "মনিটরিং")। Postgresql এর জন্য সিস্টেম ভিউগুলির একটি সম্পূর্ণ গুচ্ছ রয়েছে ডাটাবেস পর্যবেক্ষণ, বিশেষ করে যেগুলি যে কোনও ডিবিএর দৈনন্দিন জীবনে অপরিহার্য, যেমন pg_stat_activity, pg_stat_database, pg_stat_bgwriter. MySQL এর এমনকি এর জন্য একটি পৃথক স্কিমা রয়েছে। কর্মক্ষমতা_স্কিমা. A In Mongo অন্তর্নির্মিত প্রোফাইলার একটি সিস্টেম সংগ্রহে কর্মক্ষমতা ডেটা একত্রিত করে system.profile.

এইভাবে, কিছু ধরণের মেট্রিক্স সংগ্রাহক (টেলিগ্রাফ, মেট্রিকবিট, সংগৃহীত) দিয়ে সজ্জিত যা কাস্টম sql প্রশ্নগুলি সম্পাদন করতে পারে, এই মেট্রিকগুলির একটি স্টোরেজ (ইনফ্লাক্সডিবি, ইলাস্টিকসার্চ, টাইমস্কেলডবি) এবং একটি ভিজ্যুয়ালাইজার (গ্রাফানা, কিবানা), আপনি মোটামুটি সহজে পেতে পারেন। এবং একটি নমনীয় মনিটরিং সিস্টেম যা অন্যান্য সিস্টেম-ব্যাপী মেট্রিক্সের সাথে ঘনিষ্ঠভাবে একত্রিত হবে (প্রাপ্ত, উদাহরণস্বরূপ, অ্যাপ্লিকেশন সার্ভার থেকে, OS থেকে, ইত্যাদি)। যেমন, উদাহরণস্বরূপ, এটি pgwatch2 এ করা হয়, যা InfluxDB + Grafana সংমিশ্রণ ব্যবহার করে এবং সিস্টেম ভিউতে প্রশ্নের একটি সেট ব্যবহার করে, যা অ্যাক্সেস করা যেতে পারে কাস্টম প্রশ্ন যোগ করুন.

মোটে

এবং নিয়মিত এসকিউএল কোড ব্যবহার করে আমাদের ডাটাবেস দিয়ে কী করা যেতে পারে তার এটি শুধুমাত্র একটি আনুমানিক তালিকা। আমি নিশ্চিত আপনি আরো অনেক ব্যবহার খুঁজে পেতে পারেন, মন্তব্য লিখুন. এবং আমরা কীভাবে (এবং সবচেয়ে গুরুত্বপূর্ণভাবে কেন) এই সমস্তগুলিকে স্বয়ংক্রিয় করতে এবং পরের বার এটিকে আপনার CI/CD পাইপলাইনে অন্তর্ভুক্ত করতে হবে সে সম্পর্কে কথা বলব।

উত্স: www.habr.com