PostgreSQL প্রশ্নগুলির ব্যাপক অপ্টিমাইজেশন। কিরিল বোরোভিকভ (টেনসর)

প্রতিবেদনে কিছু পন্থা উপস্থাপন করা হয়েছে যা অনুমতি দেয় এসকিউএল কোয়েরির কর্মক্ষমতা নিরীক্ষণ করুন যখন সেগুলি প্রতিদিন লক্ষ লক্ষ থাকে, এবং সেখানে শত শত নিরীক্ষণ করা PostgreSQL সার্ভার রয়েছে।

কোন প্রযুক্তিগত সমাধানগুলি আমাদেরকে দক্ষতার সাথে এত পরিমাণ তথ্য প্রক্রিয়া করার অনুমতি দেয় এবং এটি কীভাবে একজন সাধারণ বিকাশকারীর জীবনকে সহজ করে তোলে?

কে আগ্রহী? নির্দিষ্ট সমস্যা এবং বিভিন্ন অপ্টিমাইজেশান কৌশল বিশ্লেষণ SQL প্রশ্ন এবং PostgreSQL-এ সাধারণ DBA সমস্যার সমাধান - আপনিও করতে পারেন নিবন্ধের একটি সিরিজ পড়ুন এই বিষয়ে।


আমার নাম কিরিল বোরোভিকভ, আমি প্রতিনিধিত্ব করি টেনসর কোম্পানি. বিশেষ করে, আমি আমাদের কোম্পানির ডাটাবেসের সাথে কাজ করতে পারদর্শী।

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

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

তারা যাতে স্বাভাবিকভাবে কাজ করে এবং বিকাশ করে তা নিশ্চিত করার জন্য, সারা দেশে আমাদের 10টি উন্নয়ন কেন্দ্র রয়েছে, যার মধ্যে আরও বেশি 1000 ডেভেলপার.

আমরা 2008 সাল থেকে PostgreSQL এর সাথে কাজ করছি এবং আমরা যা প্রক্রিয়া করি তার একটি বড় পরিমাণ জমা করেছি - ক্লায়েন্ট ডেটা, পরিসংখ্যানগত, বিশ্লেষণাত্মক, বহিরাগত তথ্য সিস্টেম থেকে ডেটা - 400TB এর বেশি. শুধুমাত্র উৎপাদনে প্রায় 250 সার্ভার রয়েছে এবং মোট প্রায় 1000 ডাটাবেস সার্ভার রয়েছে যা আমরা পর্যবেক্ষণ করি।

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

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

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

সাধারণভাবে, একজন বিকাশকারী [একটি ডিবিএতে] সাধারণত কোন ক্লাসিক সমস্যা নিয়ে আসে? “এখানে আমরা অনুরোধটি পূরণ করেছি, এবং আমাদের সাথে সবকিছু ধীর, সবকিছু ঝুলে আছে, কিছু একটা ঘটছে... একরকম ঝামেলা!”

কারণ প্রায় সবসময় একই:

• অদক্ষ কোয়েরি অ্যালগরিদম
  বিকাশকারী: "এখন আমি তাকে যোগদানের মাধ্যমে SQL এ 10টি টেবিল দিচ্ছি..." - এবং আশা করে যে তার শর্তগুলি অলৌকিকভাবে কার্যকরভাবে "মুক্ত" হবে এবং সে দ্রুত সবকিছু পাবে। কিন্তু অলৌকিক ঘটনা ঘটবে না, এবং এই ধরনের পরিবর্তনশীলতা সহ যে কোনও সিস্টেম (একটি থেকে 10 টেবিল) সর্বদা কিছু ধরণের ত্রুটি দেয়। [একটি নিবন্ধ]
• অপ্রাসঙ্গিক পরিসংখ্যান
  এই পয়েন্টটি বিশেষভাবে PostgreSQL-এর জন্য খুবই প্রাসঙ্গিক, যখন আপনি সার্ভারে একটি বড় ডেটাসেট "ঢেলে" দেন, একটি অনুরোধ করেন এবং এটি আপনার ট্যাবলেটকে "সেক্সকানিটিস" করে। কারণ গতকাল সেখানে 10টি রেকর্ড ছিল, এবং আজ 10 মিলিয়ন আছে, কিন্তু PostgreSQL এখনও এই বিষয়ে সচেতন নয়, এবং আমাদের এটি সম্পর্কে বলা দরকার। [একটি নিবন্ধ]
• সম্পদের উপর "প্লাগ"
  আপনি একটি দুর্বল সার্ভারে একটি বড় এবং ভারী লোড করা ডাটাবেস ইনস্টল করেছেন যেটিতে যথেষ্ট ডিস্ক, মেমরি বা প্রসেসরের কার্যকারিতা নেই। এবং এটিই সব... কোথাও একটি পারফরম্যান্স সিলিং রয়েছে যার উপরে আপনি আর লাফ দিতে পারবেন না।
• ব্লক করা
  এটি একটি কঠিন বিন্দু, কিন্তু তারা বিভিন্ন পরিবর্তনকারী প্রশ্নের জন্য সবচেয়ে প্রাসঙ্গিক (ঢোকান, আপডেট করুন, মুছুন) - এটি একটি পৃথক বড় বিষয়।

একটি পরিকল্পনা হচ্ছে

...আর সব কিছুর জন্য আমরা একটি পরিকল্পনা প্রয়োজন! আমাদের সার্ভারের ভিতরে কী ঘটছে তা দেখতে হবে।

PostgreSQL-এর জন্য একটি ক্যোয়ারী এক্সিকিউশন প্ল্যান হল টেক্সট রিপ্রেজেন্টেশনে কোয়েরি এক্সিকিউশন অ্যালগরিদমের একটি ট্রি। এটি সঠিকভাবে অ্যালগরিদম যা, পরিকল্পনাকারী দ্বারা বিশ্লেষণের ফলস্বরূপ, সবচেয়ে কার্যকর বলে পাওয়া গেছে।

প্রতিটি ট্রি নোড একটি অপারেশন: একটি টেবিল বা সূচক থেকে ডেটা পুনরুদ্ধার করা, একটি বিটম্যাপ তৈরি করা, দুটি টেবিলে যোগদান করা, যোগদান করা, ছেদ করা বা নির্বাচন বাদ দেওয়া। একটি অনুসন্ধান চালানোর জন্য এই গাছের নোডের মধ্য দিয়ে হাঁটা জড়িত।

ক্যোয়ারী পরিকল্পনা পেতে, সবচেয়ে সহজ উপায় হল বিবৃতিটি কার্যকর করা EXPLAIN. সমস্ত বাস্তব বৈশিষ্ট্যের সাথে পেতে, অর্থাৎ, আসলে বেসে একটি ক্যোয়ারী চালানো - EXPLAIN (ANALYZE, BUFFERS) SELECT ....

খারাপ অংশ: আপনি যখন এটি চালান, এটি "এখানে এবং এখন" ঘটে, তাই এটি শুধুমাত্র স্থানীয় ডিবাগিংয়ের জন্য উপযুক্ত। আপনি যদি একটি অত্যন্ত লোড সার্ভার গ্রহণ করেন যা ডেটা পরিবর্তনের একটি শক্তিশালী প্রবাহের অধীনে থাকে এবং আপনি দেখতে পান: "ওহ! এখানে আমরা একটি ধীর মৃত্যুদন্ড আছেXia থেকে অনুরোধ।" আধা ঘন্টা, এক ঘন্টা আগে - আপনি যখন দৌড়াচ্ছিলেন এবং লগগুলি থেকে এই অনুরোধটি পেয়েছিলেন, এটিকে সার্ভারে ফিরিয়ে আনছিলেন, তখন আপনার সম্পূর্ণ ডেটাসেট এবং পরিসংখ্যান পরিবর্তিত হয়েছিল৷ আপনি এটি ডিবাগ করতে চালান - এবং এটি দ্রুত চলে! এবং আপনি বুঝতে পারবেন না কেন, কেন এটি ছিল ধীরে ধীরে

সার্ভারে অনুরোধটি কার্যকর করার মুহুর্তে ঠিক কী ঘটেছে তা বোঝার জন্য, স্মার্ট ব্যক্তিরা লিখেছেন auto_explain মডিউল. এটি প্রায় সব সাধারণ PostgreSQL ডিস্ট্রিবিউশনে উপস্থিত থাকে এবং কনফিগার ফাইলে এটি সক্রিয় করা যেতে পারে।

যদি এটি বুঝতে পারে যে কিছু অনুরোধ আপনার বলা সীমার চেয়ে বেশি সময় ধরে চলছে, তবে তা করে এই অনুরোধের পরিকল্পনার "স্ন্যাপশট" এবং লগে সেগুলি একসাথে লেখে.

এখন সবকিছু ঠিক আছে বলে মনে হচ্ছে, আমরা লগে গিয়ে দেখি... [টেক্সট ফুটক্লথ]। তবে আমরা এটি সম্পর্কে কিছু বলতে পারি না, এটি একটি দুর্দান্ত পরিকল্পনা কারণ এটি কার্যকর করতে 11ms লেগেছিল।

সবকিছু ঠিক আছে বলে মনে হচ্ছে - কিন্তু আসলে কি ঘটেছে কিছুই স্পষ্ট নয়। সাধারণ সময় ছাড়া, আমরা আসলে কিছুই দেখতে পাই না। কারণ প্লেইন টেক্সটের এমন একটি "মেষশাবক" দেখা সাধারণত দৃশ্যমান নয়।

তবে এটি সুস্পষ্ট না হলেও, অসুবিধাজনক হলেও, আরও মৌলিক সমস্যা রয়েছে:

• নোড নির্দেশ করে সমগ্র সাবট্রির সম্পদের যোগফল তার অধীনে অর্থাৎ, আপনি এই নির্দিষ্ট সূচক স্ক্যানে কতটা সময় ব্যয় করেছেন তা খুঁজে বের করতে পারবেন না যদি এর অধীনে কিছু নেস্টেড অবস্থা থাকে। আমাদের অবশ্যই গতিশীলভাবে দেখতে হবে যে ভিতরে "শিশু" এবং শর্তসাপেক্ষ ভেরিয়েবল, CTE আছে কিনা - এবং "আমাদের মনে" এই সমস্ত বিয়োগ করতে হবে।
• দ্বিতীয় পয়েন্ট: নোডে নির্দেশিত সময় হল একক নোড কার্যকর করার সময়. যদি এই নোডটি কার্যকর করা হয়, উদাহরণস্বরূপ, টেবিল রেকর্ডের মাধ্যমে একটি লুপ বেশ কয়েকবার, তাহলে লুপের সংখ্যা—এই নোডের চক্র—প্ল্যানে বৃদ্ধি পায়। কিন্তু পরমাণু কার্যকর করার সময় নিজেই পরিকল্পনার পরিপ্রেক্ষিতে একই থাকে। অর্থাৎ, এই নোডটি মোট কতক্ষণ সঞ্চালিত হয়েছিল তা বোঝার জন্য, আপনাকে একটি জিনিসকে অন্য দ্বারা গুণ করতে হবে - আবার, "আপনার মাথায়।"

এই ধরনের পরিস্থিতিতে, "সবচেয়ে দুর্বল লিঙ্ক কে?" প্রায় অসম্ভব. অতএব, এমনকি বিকাশকারীরা নিজেরাই "ম্যানুয়াল" এ লিখেন "একটি পরিকল্পনা বোঝা একটি শিল্প যা অবশ্যই শিখতে হবে, অভিজ্ঞতা...".

কিন্তু আমাদের 1000 জন ডেভেলপার আছে এবং আপনি তাদের প্রত্যেকের কাছে এই অভিজ্ঞতা জানাতে পারবেন না। আমি, তুমি, সে জানি, কিন্তু ওখানকার কেউ আর জানে না। হয়তো সে শিখবে, বা নাও পারে, কিন্তু তার এখন কাজ করা দরকার - এবং এই অভিজ্ঞতা সে কোথায় পাবে?

পরিকল্পনা ভিজ্যুয়ালাইজেশন

অতএব, আমরা বুঝতে পেরেছি যে এই সমস্যাগুলি মোকাবেলা করার জন্য আমাদের প্রয়োজন পরিকল্পনার ভাল ভিজ্যুয়ালাইজেশন. [নিবন্ধ]

আমরা প্রথমে "বাজারের মধ্য দিয়ে" গিয়েছিলাম - আসুন ইন্টারনেটে তাকাই দেখুন কি আছে।

তবে দেখা গেল যে তুলনামূলকভাবে খুব কম "লাইভ" সমাধান রয়েছে যা কমবেশি বিকাশমান - আক্ষরিক অর্থে, শুধুমাত্র একটি: ব্যাখ্যা.depesz.com Hubert Lubaczewski দ্বারা। আপনি যখন "ফিড" ফিল্ডে প্ল্যানের একটি পাঠ্য উপস্থাপনা প্রবেশ করেন, তখন এটি আপনাকে পার্স করা ডেটা সহ একটি টেবিল দেখায়:

• নোডের নিজস্ব প্রক্রিয়াকরণ সময়
• পুরো সাবট্রির জন্য মোট সময়
• পুনরুদ্ধার করা রেকর্ডের সংখ্যা যা পরিসংখ্যানগতভাবে প্রত্যাশিত ছিল
• নোড শরীর নিজেই

এই পরিষেবাটিতে লিঙ্কগুলির একটি সংরক্ষণাগার ভাগ করার ক্ষমতাও রয়েছে। আপনি আপনার পরিকল্পনাটি সেখানে ফেলে দিয়েছিলেন এবং বলেছিলেন: "আরে, ভাস্য, এখানে একটি লিঙ্ক, সেখানে কিছু ভুল আছে।"

তবে ছোটখাটো সমস্যাও আছে।

প্রথমত, বিপুল পরিমাণ “কপি-পেস্ট”। আপনি লগের একটি টুকরো নিন, সেখানে এটি আটকান, এবং আবার, এবং আবার।

দ্বিতীয়ত, পঠিত ডেটা পরিমাণের কোন বিশ্লেষণ নেই — একই বাফার যে আউটপুট EXPLAIN (ANALYZE, BUFFERS), আমরা এখানে এটি দেখতে পাচ্ছি না। তিনি কেবল তাদের বিচ্ছিন্ন করতে, তাদের বুঝতে এবং তাদের সাথে কাজ করতে জানেন না। আপনি যখন প্রচুর ডেটা পড়ছেন এবং বুঝতে পারেন যে আপনি ডিস্ক এবং মেমরি ক্যাশে ভুল বরাদ্দ করছেন, এই তথ্যটি খুবই গুরুত্বপূর্ণ।

তৃতীয় নেতিবাচক পয়েন্ট এই প্রকল্পের খুব দুর্বল উন্নয়ন. কমিটগুলি খুব ছোট, প্রতি ছয় মাসে একবার হলে ভাল হয় এবং কোডটি পার্লে থাকে।

তবে এটি সমস্ত "গীতি", আমরা কোনওভাবে এটির সাথে বাঁচতে পারি, তবে একটি জিনিস রয়েছে যা আমাদের এই পরিষেবা থেকে ব্যাপকভাবে দূরে সরিয়ে দিয়েছে। এগুলি হল কমন টেবিল এক্সপ্রেশন (CTE) এবং InitPlan/SubPlan এর মত বিভিন্ন গতিশীল নোডের বিশ্লেষণে ত্রুটি।

আপনি যদি এই ছবিটি বিশ্বাস করেন, তাহলে প্রতিটি পৃথক নোডের মোট এক্সিকিউশন সময় সমগ্র অনুরোধের মোট এক্সিকিউশন সময়ের চেয়ে বেশি। ইহা সহজ - এই CTE এর প্রজন্মের সময় CTE স্ক্যান নোড থেকে বিয়োগ করা হয়নি. অতএব, CTE স্ক্যান করতে কতক্ষণ সময় লেগেছে তার সঠিক উত্তর আমরা আর জানি না।

তখন আমরা বুঝতে পেরেছিলাম যে আমাদের নিজেদের লেখার সময় এসেছে - হুররে! প্রতিটি বিকাশকারী বলেছেন: "এখন আমরা আমাদের নিজস্ব লিখব, এটি খুব সহজ হবে!"

আমরা ওয়েব পরিষেবাগুলির জন্য সাধারণ একটি স্ট্যাক নিয়েছি: Node.js + Express এর উপর ভিত্তি করে একটি কোর, সুন্দর ডায়াগ্রামের জন্য ব্যবহৃত বুটস্ট্র্যাপ এবং D3.js। এবং আমাদের প্রত্যাশা সম্পূর্ণরূপে ন্যায়সঙ্গত ছিল - আমরা 2 সপ্তাহের মধ্যে প্রথম প্রোটোটাইপ পেয়েছি:

• কাস্টম প্ল্যান পার্সার
  অর্থাৎ, এখন আমরা PostgreSQL দ্বারা উত্পন্ন যেকোন পরিকল্পনা পার্স করতে পারি।
• ডায়নামিক নোডের সঠিক বিশ্লেষণ - CTE স্ক্যান, InitPlan, SubPlan
• বাফার বিতরণের বিশ্লেষণ - যেখানে ডেটা পৃষ্ঠাগুলি মেমরি থেকে পড়া হয়, কোথায় স্থানীয় ক্যাশে থেকে, কোথায় ডিস্ক থেকে
• স্বচ্ছতা পেয়েছি
  যাতে লগে এই সমস্ত "খনন" না করা যায়, তবে ছবিতে এখনই "দুর্বল লিঙ্ক" দেখতে।

আমরা এই মত কিছু পেয়েছিলাম, সিনট্যাক্স হাইলাইট অন্তর্ভুক্ত সঙ্গে. কিন্তু সাধারণত আমাদের ডেভেলপাররা আর প্ল্যানের সম্পূর্ণ উপস্থাপনা নিয়ে কাজ করে না, কিন্তু একটি ছোট করে। সর্বোপরি, আমরা ইতিমধ্যে সমস্ত সংখ্যা পার্স করেছি এবং তাদের বাম এবং ডানে ফেলেছি এবং মাঝখানে আমরা কেবল প্রথম লাইনটি রেখেছি, এটি কী ধরণের নোড: কিছু চিহ্ন অনুসারে CTE স্ক্যান, CTE প্রজন্ম বা Seq স্ক্যান।

এই সংক্ষিপ্ত প্রতিনিধিত্ব আমরা কল পরিকল্পনা টেমপ্লেট.

আর কি সুবিধা হবে? আমাদের মোট সময়ের কত ভাগ কোন নোডে বরাদ্দ করা হয়েছে তা দেখতে সুবিধাজনক হবে - এবং কেবল এটিকে পাশে রাখুন পাই চিত্র.

আমরা নোডের দিকে নির্দেশ করি এবং দেখি - দেখা যাচ্ছে যে সেক স্ক্যানটি মোট সময়ের এক চতুর্থাংশেরও কম সময় নিয়েছে এবং বাকি 3/4টি CTE স্ক্যান দ্বারা নেওয়া হয়েছে। বিভীষিকা ! এটি CTE স্ক্যানের "আগুনের হার" সম্পর্কে একটি ছোট নোট যদি আপনি সক্রিয়ভাবে আপনার প্রশ্নগুলিতে ব্যবহার করেন। তারা খুব দ্রুত নয় - তারা এমনকি নিয়মিত টেবিল স্ক্যানিং থেকে নিকৃষ্ট। [নিবন্ধ] [নিবন্ধ]

কিন্তু সাধারণত এই জাতীয় চিত্রগুলি আরও আকর্ষণীয়, আরও জটিল হয়, যখন আমরা অবিলম্বে একটি সেগমেন্টের দিকে নির্দেশ করি এবং দেখি, উদাহরণস্বরূপ, অর্ধেকেরও বেশি সময় কিছু Seq স্ক্যান "খেয়েছে"৷ তদুপরি, ভিতরে এক ধরণের ফিল্টার ছিল, এটি অনুসারে প্রচুর রেকর্ড বাতিল করা হয়েছিল... আপনি এই ছবিটি সরাসরি বিকাশকারীকে ফেলে দিতে পারেন এবং বলতে পারেন: "ভাস্যা, এখানে আপনার জন্য সবকিছু খারাপ! এটি খুঁজে বের করুন, দেখুন - কিছু ভুল হয়েছে!"

স্বাভাবিকভাবেই, কিছু "রেক" জড়িত ছিল।

আমরা প্রথম যে জিনিসটি পেয়েছি তা হল রাউন্ডিং সমস্যা। পরিকল্পনায় প্রতিটি পৃথক নোডের সময় 1 μs এর নির্ভুলতার সাথে নির্দেশিত হয়। এবং যখন নোড চক্রের সংখ্যা অতিক্রম করে, উদাহরণস্বরূপ, 1000 - সম্পাদনের পরে PostgreSQL "নির্ভুলতার মধ্যে" বিভক্ত হয়, তখন আবার গণনা করার সময় আমরা "0.95ms এবং 1.05ms এর মধ্যে কোথাও" মোট সময় পাই। যখন গণনা মাইক্রোসেকেন্ডে যায়, তখন ঠিক আছে, কিন্তু যখন এটি ইতিমধ্যেই [মিলি] সেকেন্ড হয়ে যায়, তখন আপনাকে এই তথ্যটি বিবেচনায় নিতে হবে যখন "কে কতটা খরচ করেছে" পরিকল্পনার নোডগুলিতে সংস্থানগুলি "খোলা"।

দ্বিতীয় পয়েন্ট, আরও জটিল, হ'ল গতিশীল নোডগুলির মধ্যে সংস্থানগুলির (ওই বাফারগুলি) বিতরণ। এতে আমাদের প্রোটোটাইপের প্রথম 2 সপ্তাহ এবং আরও 4 সপ্তাহ খরচ হয়েছে।

এই ধরনের সমস্যা পাওয়া বেশ সহজ - আমরা একটি CTE করি এবং অনুমিতভাবে এতে কিছু পড়ি। আসলে, PostgreSQL "স্মার্ট" এবং সেখানে সরাসরি কিছু পড়বে না। তারপরে আমরা এটি থেকে প্রথম রেকর্ডটি নিই, এবং এটিতে একই CTE থেকে একশত প্রথমটি।

আমরা পরিকল্পনাটি দেখেছি এবং বুঝতে পেরেছি - এটি অদ্ভুত, আমাদের Seq স্ক্যানে 3টি বাফার (ডেটা পৃষ্ঠা) "গ্রাহ্য" আছে, CTE স্ক্যানে আরও 1টি, এবং দ্বিতীয় CTE স্ক্যানে আরও 2টি। অর্থাৎ, আমরা যদি সব কিছুকে সহজভাবে যোগ করি, তাহলে আমরা 6 পাব, কিন্তু ট্যাবলেট থেকে আমরা পড়ি মাত্র 3! CTE স্ক্যান কোথাও থেকে কিছু পড়ে না, তবে প্রক্রিয়া মেমরির সাথে সরাসরি কাজ করে। অর্থাৎ এখানে স্পষ্টতই কিছু ভুল!

প্রকৃতপক্ষে, দেখা যাচ্ছে যে এখানে সেই সব 3 পৃষ্ঠার ডেটা রয়েছে যা Seq স্ক্যান থেকে অনুরোধ করা হয়েছিল, প্রথমে 1টি 1ম CTE স্ক্যানের জন্য জিজ্ঞাসা করেছিল, তারপর 2য় এবং আরও 2টি তাকে পড়া হয়েছিল৷ অর্থাৎ, মোট 3 পৃষ্ঠা পঠিত ডেটা, 6 নয়।

এবং এই চিত্রটি আমাদের বোঝার দিকে নিয়ে গেছে যে একটি পরিকল্পনার বাস্তবায়ন আর একটি গাছ নয়, তবে কেবল এক ধরণের অ্যাসাইক্লিক গ্রাফ। এবং আমরা এইরকম একটি ডায়াগ্রাম পেয়েছি, যাতে আমরা বুঝতে পারি "প্রথম স্থান থেকে কী এসেছে।" অর্থাৎ, এখানে আমরা pg_class থেকে একটি CTE তৈরি করেছি, এবং এটি দুইবার চেয়েছি, এবং আমরা যখন ২য় বার জিজ্ঞাসা করেছি তখন আমাদের প্রায় পুরো সময় শাখায় ব্যয় হয়েছিল। এটা স্পষ্ট যে 2 তম এন্ট্রি পড়া ট্যাবলেট থেকে শুধুমাত্র 101 ম এন্ট্রি পড়ার চেয়ে অনেক বেশি ব্যয়বহুল।

আমরা কিছুক্ষণ নিঃশ্বাস ছাড়লাম। তারা বলল: “এখন, নিও, তুমি কুংফু জানো! এখন আমাদের অভিজ্ঞতা আপনার স্ক্রিনে ঠিক আছে। এখন আপনি এটি ব্যবহার করতে পারেন।" [নিবন্ধ]

লগ একত্রীকরণ

আমাদের 1000 ডেভেলপাররা স্বস্তির নিঃশ্বাস ফেলেছে। কিন্তু আমরা বুঝতে পেরেছি যে আমাদের কাছে কেবল শত শত "কমব্যাট" সার্ভার রয়েছে এবং বিকাশকারীদের পক্ষ থেকে এই সমস্ত "কপি-পেস্ট" মোটেও সুবিধাজনক নয়। আমরা বুঝতে পেরেছিলাম যে এটি আমাদের নিজেদের সংগ্রহ করতে হবে।

সাধারণভাবে, একটি স্ট্যান্ডার্ড মডিউল রয়েছে যা পরিসংখ্যান সংগ্রহ করতে পারে, তবে, এটি কনফিগারে সক্রিয় করা দরকার - এটি pg_stat_statements মডিউল. কিন্তু সে আমাদের মানায়নি।

প্রথমত, এটি একই ডাটাবেসের মধ্যে বিভিন্ন স্কিম ব্যবহার করে একই প্রশ্নের জন্য বরাদ্দ করে বিভিন্ন QueryIds. অর্থাৎ, আপনি যদি প্রথমে করেন SET search_path = '01'; SELECT * FROM user LIMIT 1;এবং তারপর SET search_path = '02'; এবং একই অনুরোধ, তাহলে এই মডিউলের পরিসংখ্যানের বিভিন্ন রেকর্ড থাকবে, এবং আমি স্কিমগুলিকে বিবেচনায় না নিয়ে বিশেষভাবে এই অনুরোধ প্রোফাইলের প্রসঙ্গে সাধারণ পরিসংখ্যান সংগ্রহ করতে সক্ষম হব না।

দ্বিতীয় পয়েন্ট যা আমাদের এটি ব্যবহার করতে বাধা দেয় পরিকল্পনার অভাব. অর্থাৎ কোনো পরিকল্পনা নেই, আছে শুধু অনুরোধ নিজেই। আমরা দেখি কি ধীরগতি ছিল, কিন্তু কেন আমরা বুঝতে পারি না। এবং এখানে আমরা দ্রুত পরিবর্তনশীল ডেটাসেটের সমস্যায় ফিরে আসি।

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

তাই আমরা কপি-পেস্টের বিরুদ্ধে লড়াই করার সিদ্ধান্ত নিয়ে লিখতে শুরু করি সংগ্রাহক.

সংগ্রাহক SSH এর মাধ্যমে সংযোগ স্থাপন করে, একটি সার্টিফিকেট ব্যবহার করে ডাটাবেসের সাথে সার্ভারের সাথে একটি সুরক্ষিত সংযোগ স্থাপন করে এবং tail -F লগ ফাইলে এটিকে "ক্লিংস" করে। তাই এই অধিবেশনে আমরা সম্পূর্ণ লগ ফাইলের একটি সম্পূর্ণ "মিরর" পাই, যা সার্ভার তৈরি করে। সার্ভারে লোড নিজেই ন্যূনতম, কারণ আমরা সেখানে কিছু পার্স করি না, আমরা কেবল ট্র্যাফিক মিরর করি।

যেহেতু আমরা ইতিমধ্যেই Node.js-এ ইন্টারফেস লেখা শুরু করেছি, আমরা এতে সংগ্রাহক লিখতে থাকি। এবং এই প্রযুক্তিটি নিজেকে ন্যায্যতা দিয়েছে, কারণ এটি জাভাস্ক্রিপ্ট ব্যবহার করার জন্য দুর্বলভাবে ফর্ম্যাট করা টেক্সট ডেটার সাথে কাজ করা খুব সুবিধাজনক, যা লগ। এবং ব্যাকএন্ড প্ল্যাটফর্ম হিসাবে Node.js পরিকাঠামো আপনাকে সহজেই এবং সুবিধাজনকভাবে নেটওয়ার্ক সংযোগের সাথে এবং প্রকৃতপক্ষে যেকোনো ডেটা স্ট্রিমের সাথে কাজ করতে দেয়।

তদনুসারে, আমরা দুটি সংযোগ "প্রসারিত" করি: প্রথমটি লগটি নিজেই "শুনতে" এবং এটি নিজের কাছে নিয়ে যায় এবং দ্বিতীয়টি পর্যায়ক্রমে বেসটিকে জিজ্ঞাসা করে। "কিন্তু লগটি দেখায় যে oid 123 সহ চিহ্নটি ব্লক করা হয়েছে," তবে এটি বিকাশকারীর কাছে কিছু বোঝায় না এবং ডাটাবেসকে জিজ্ঞাসা করা ভাল হবে, "OID = 123 যাইহোক?" এবং তাই আমরা পর্যায়ক্রমে বেসকে জিজ্ঞাসা করি যে আমরা এখনও নিজেদের সম্পর্কে জানি না।

"এখানে শুধুমাত্র একটি জিনিস আছে যা আপনি বিবেচনায় নেননি, হাতির মতো মৌমাছির একটি প্রজাতি আছে!..." আমরা যখন 10টি সার্ভার নিরীক্ষণ করতে চেয়েছিলাম তখন আমরা এই সিস্টেমটি বিকাশ শুরু করি৷ আমাদের বোধগম্যতায় সবচেয়ে সমালোচনামূলক, যেখানে কিছু সমস্যা দেখা দিয়েছে যেগুলো মোকাবেলা করা কঠিন ছিল। কিন্তু প্রথম ত্রৈমাসিকের সময়, আমরা পর্যবেক্ষণের জন্য একশো পেয়েছি - কারণ সিস্টেমটি কাজ করেছিল, সবাই এটি চেয়েছিল, সবাই আরামদায়ক ছিল।

এই সব যোগ করা প্রয়োজন, তথ্য প্রবাহ বড় এবং সক্রিয়. আসলে, আমরা যা নিরীক্ষণ করি, আমরা যা মোকাবেলা করতে পারি, তা আমরা ব্যবহার করি। আমরা PostgreSQL ডাটা স্টোরেজ হিসেবে ব্যবহার করি। এবং অপারেটরের চেয়ে এতে ডেটা "ঢালা" করার জন্য কিছুই দ্রুত নয় COPY এখনো না.

কিন্তু সহজভাবে "ঢালা" তথ্য আসলে আমাদের প্রযুক্তি নয়। কারণ আপনার যদি একশত সার্ভারে প্রতি সেকেন্ডে আনুমানিক 50k অনুরোধ থাকে, তাহলে এটি প্রতিদিন 100-150GB লগ তৈরি করবে। অতএব, আমাদের সাবধানে বেসটি "কাট" করতে হয়েছিল।

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

দ্বিতীয়ত, আমরা শিখেছি (বাধ্য করা হয়েছিল) ব্যবহার করে লিখতে খুব, খুব দ্রুত COPY. অর্থাৎ শুধু নয় COPYকারণ সে তার চেয়ে দ্রুত INSERT, এবং এমনকি দ্রুত।

তৃতীয় পয়েন্ট - আমাকে করতে হয়েছিল যথাক্রমে ট্রিগার এবং বিদেশী কী পরিত্যাগ করুন. অর্থাৎ, আমাদের কোনো রেফারেন্সিয়াল সততা নেই। কারণ আপনার যদি একটি টেবিল থাকে যাতে এক জোড়া FK আছে, এবং আপনি ডাটাবেস কাঠামোতে বলেন যে "এখানে একটি লগ রেকর্ড আছে যা FK দ্বারা উল্লেখ করা হয়েছে, উদাহরণস্বরূপ, রেকর্ডের একটি গ্রুপে," তাহলে আপনি যখন এটি সন্নিবেশ করেন, পোস্টগ্রেএসকিউএল কিছুই অবশিষ্ট নেই কিন্তু কিভাবে এটা নিতে এবং সৎভাবে এটা করতে SELECT 1 FROM master_fk1_table WHERE ... আপনি যে শনাক্তকারীর সাথে সন্নিবেশ করার চেষ্টা করছেন - শুধুমাত্র এই রেকর্ডটি সেখানে উপস্থিত আছে কিনা তা পরীক্ষা করার জন্য, আপনি আপনার সন্নিবেশের সাথে এই বিদেশী কীটিকে "ভাঙ্গা" করবেন না।

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

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

এখন কল্পনা করুন যে আপনার কাছে একটি টেবিল রয়েছে যেখানে আপনি একটি নির্দিষ্ট হোস্টের মাধ্যমে পাস করা অনুরোধের সংখ্যা গণনা করেন: +1, +1, +1, ..., +1. এবং আপনার, নীতিগতভাবে, এটির প্রয়োজন নেই - এটি সবই সম্ভব সংগ্রাহকের মেমরির যোগফল এবং একবারে ডাটাবেসে পাঠান +10.

হ্যাঁ, কিছু সমস্যার ক্ষেত্রে, আপনার যৌক্তিক সততা "বিচ্ছিন্ন" হতে পারে, তবে এটি একটি প্রায় অবাস্তব কেস - কারণ আপনার একটি সাধারণ সার্ভার রয়েছে, এটির কন্ট্রোলারে একটি ব্যাটারি রয়েছে, আপনার একটি লেনদেন লগ আছে, একটি লগ ফাইল সিস্টেম... সাধারণভাবে, এটা মূল্যবান নয়। ট্রিগার/FK চালানোর ফলে আপনি যে উৎপাদনশীলতা হারান তা আপনার খরচের মূল্য নয়।

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

পাঠ্য থেকে MD5 ব্যবহার করা আমাদের জন্য নিখুঁত ছিল - অনুরোধ, পরিকল্পনা, টেমপ্লেট,... আমরা এটি সংগ্রাহকের দিক থেকে গণনা করি এবং ডাটাবেসে তৈরি আইডি "ঢালা" করি৷ MD5 এর দৈর্ঘ্য এবং দৈনিক বিভাজন আমাদের সম্ভাব্য সংঘর্ষের বিষয়ে চিন্তা করার অনুমতি দেয় না।

কিন্তু এই সব দ্রুত রেকর্ড করার জন্য, আমাদের রেকর্ডিং পদ্ধতি নিজেই পরিবর্তন করতে হবে।

আপনি সাধারণত তথ্য কিভাবে লিখবেন? আমাদের কিছু ধরণের ডেটাসেট আছে, আমরা এটিকে কয়েকটি টেবিলে বিভক্ত করি এবং তারপরে এটি কপি করি - প্রথমে প্রথমটিতে, তারপরে দ্বিতীয়টিতে, তৃতীয়টিতে... এটি অসুবিধাজনক, কারণ আমরা তিনটি ধাপে একটি ডেটা স্ট্রিম লিখছি বলে মনে হচ্ছে ক্রমানুসারে অপ্রীতিকর। এটা কি দ্রুত করা যাবে? করতে পারা!

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

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

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

এই ধরনের অসঙ্গতিগুলি থেকে পরিত্রাণ পেতে, কেবল কিছু একত্রিত করবেন না, মোটেও বাফার করবেন না. এবং যদি ডিস্কে বাফারিং ঘটে থাকে (সৌভাগ্যবশত, Node.js-এ স্ট্রিম API আপনাকে খুঁজে বের করতে দেয়) - এই সংযোগটি স্থগিত করুন। যখন আপনি একটি ইভেন্ট পাবেন যে এটি আবার বিনামূল্যে, জমা সারি থেকে এটি লিখুন। এবং এটি ব্যস্ত থাকাকালীন, পুল থেকে পরবর্তী বিনামূল্যে নিন এবং এটিতে লিখুন।

ডেটা রেকর্ডিংয়ের এই পদ্ধতিটি প্রবর্তন করার আগে, আমাদের প্রায় 4K রাইট অপ্স ছিল, এবং এইভাবে আমরা 4 বার লোড কমিয়েছি। এখন তারা নতুন মনিটর করা ডাটাবেসের কারণে আরও 6 গুণ বেড়েছে - 100MB/s পর্যন্ত। এবং এখন আমরা প্রায় 3-10TB ভলিউমে গত 15 মাসের লগ সঞ্চয় করি, আশা করি যে মাত্র তিন মাসের মধ্যে যে কোনও বিকাশকারী যে কোনও সমস্যা সমাধান করতে সক্ষম হবে।

আমরা সমস্যাগুলো বুঝি

কিন্তু কেবল এই সমস্ত ডেটা সংগ্রহ করা ভাল, দরকারী, প্রাসঙ্গিক, তবে যথেষ্ট নয় - এটি বোঝা দরকার। কারণ এগুলি প্রতিদিন লক্ষ লক্ষ বিভিন্ন পরিকল্পনা।

কিন্তু লক্ষ লক্ষ অব্যবস্থাপিত, আমাদের প্রথমে "ছোট" করতে হবে। এবং, প্রথমত, আপনাকে সিদ্ধান্ত নিতে হবে যে আপনি কীভাবে এই "ছোট" জিনিসটি সংগঠিত করবেন।

আমরা তিনটি মূল পয়েন্ট চিহ্নিত করেছি:

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

"কে" আমাদের একটি অনুরোধ পাঠিয়েছে তা বোঝার জন্য, আমরা একটি সাধারণ টুল ব্যবহার করি - একটি সেশন ভেরিয়েবল সেট করি: SET application_name = '{bl-host}:{bl-method}'; — আমরা যে ব্যবসায়িক লজিক হোস্টের নাম পাঠাই যেখান থেকে অনুরোধ আসে, এবং যে পদ্ধতি বা অ্যাপ্লিকেশন এটি শুরু করেছে তার নাম।

আমরা অনুরোধের "মালিক" পাস করার পরে, এটি অবশ্যই লগে আউটপুট হতে হবে - এর জন্য আমরা ভেরিয়েবলটি কনফিগার করি log_line_prefix = ' %m [%p:%v] [%d] %r %a'. আগ্রহীদের জন্য, হতে পারে ম্যানুয়াল দেখুনএসবের অর্থ কি. দেখা যাচ্ছে যে আমরা লগটিতে দেখতে পাচ্ছি:

• время
• প্রক্রিয়া এবং লেনদেন শনাক্তকারী
• ডাটাবেসের নাম
• যিনি এই অনুরোধ পাঠিয়েছেন তার আইপি
• এবং পদ্ধতির নাম

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

তাই এখানে কাটা "এক সার্ভার - একদিন" এটা কোন বিশ্লেষণের জন্য আমাদের জন্য যথেষ্ট হতে পরিণত.

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

যখন আমরা নির্দিষ্ট দৃষ্টান্ত থেকে টেমপ্লেটে চলে আসি, তখন আমরা একসাথে দুটি সুবিধা পেয়েছি:

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

অবশিষ্ট পদ্ধতিগুলি আমরা পরিকল্পনা থেকে যে সূচকগুলি বের করি তার উপর ভিত্তি করে: কতবার এই ধরনের প্যাটার্ন ঘটেছে, মোট এবং গড় সময়, ডিস্ক থেকে কত ডেটা পড়া হয়েছিল এবং মেমরি থেকে কতটা...

কারণ, উদাহরণস্বরূপ, আপনি হোস্টের জন্য বিশ্লেষণ পৃষ্ঠায় আসেন, দেখুন - কিছু ডিস্কে খুব বেশি পড়তে শুরু করছে। সার্ভারের ডিস্ক এটি পরিচালনা করতে পারে না - কে এটি থেকে পড়ে?

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

এবং অবিলম্বে আপনি একটি অনুরোধ থেকে একই টেমপ্লেট সঙ্গে আসা বিভিন্ন অ্যাপ্লিকেশন দেখতে পারেন SELECT * FROM users WHERE login = 'Vasya'. ফ্রন্টএন্ড, ব্যাকএন্ড, প্রসেসিং... এবং আপনি ভাবছেন কেন প্রসেসিং ব্যবহারকারীকে পড়বে যদি সে তার সাথে ইন্টারঅ্যাক্ট না করে।

বিপরীত উপায় হল অ্যাপ্লিকেশন থেকে অবিলম্বে দেখতে এটি কি করে। উদাহরণস্বরূপ, ফ্রন্টএন্ড হল এই, এই, এই, এবং এই ঘন্টায় একবার (টাইমলাইন সাহায্য করে)। এবং প্রশ্নটি অবিলম্বে উত্থাপিত হয়: মনে হচ্ছে ঘন্টায় একবার কিছু করা ফ্রন্টএন্ডের কাজ নয় ...

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

আপনার প্লেটে একটি উপযুক্ত সূচক নেই, আপনি এটির জন্য একটি অনুরোধ করেন, এটি সূচী ছাড়িয়ে যায়, সেক স্ক্যানে পড়ে... আপনি একটি বাদে সমস্ত রেকর্ড ফিল্টার করে ফেলেছেন। কেন আপনার প্রতিদিন 100M ফিল্টার করা রেকর্ড দরকার? সূচকটি রোল আপ করা কি ভাল নয়?

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

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

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

ফলে শুরুতে সমস্যা সমাধানের জন্য যে পরিমাণ অভিজ্ঞতার প্রয়োজন ছিল এবং এখন তা উল্লেখযোগ্যভাবে কমে গেছে। এই ধরনের হাতিয়ার আমরা আছে.

উত্স: www.habr.com