প্রিয় DELETE. নিকোলাই সামোখভালভ (Postgres.ai)

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

ভিডিও:

• আমি হাইলোড প্রোগ্রাম কমিটিতে ছিলাম প্রথম বছর থেকে, অর্থাৎ 2007 সাল থেকে।

• এবং আমি 2005 সাল থেকে পোস্টগ্রেসের সাথে আছি। অনেক প্রকল্পে এটি ব্যবহার করা হয়েছে।

• RuPostges এর সাথেও 2007 সাল থেকে গ্রুপ।

• আমরা Meetup-এ 2100+ অংশগ্রহণকারী হয়েছি। এটি নিউইয়র্কের পরে বিশ্বের দ্বিতীয়, দীর্ঘ সময়ের জন্য সান ফ্রান্সিসকোকে ছাড়িয়ে গেছে।

• আমি কয়েক বছর ধরে ক্যালিফোর্নিয়ায় বসবাস করছি। আমি বড় কোম্পানি সহ আমেরিকান কোম্পানিগুলির সাথে আরও বেশি ডিল করি। তারা পোস্টগ্রেসের সক্রিয় ব্যবহারকারী। এবং আকর্ষণীয় জিনিস সব ধরণের আছে.

https://postgres.ai/ আমার কোম্পানি আমরা স্বয়ংক্রিয় কাজের ব্যবসায় রয়েছি যা উন্নয়নের মন্দা দূর করে।

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

https://www.seagate.com/files/www-content/our-story/trends/files/idc-seagate-dataage-whitepaper.pdf

আমি সম্প্রতি লস এঞ্জেলেসের ভিএলডিবিতে ছিলাম। এটি ডাটাবেস নিয়ে সবচেয়ে বড় সম্মেলন। এবং একটি রিপোর্ট ছিল যে ভবিষ্যতে DBMS শুধুমাত্র সংরক্ষণ করবে না, কিন্তু স্বয়ংক্রিয়ভাবে ডেটা মুছে ফেলবে। এটি একটি নতুন বিষয়।

জেটাবাইটের বিশ্বে আরও বেশি বেশি ডেটা রয়েছে - এটি 1 পেটাবাইট। এবং এখন এটি ইতিমধ্যে অনুমান করা হয়েছে যে আমাদের কাছে বিশ্বে 000 জেটাবাইটের বেশি ডেটা সংরক্ষিত রয়েছে। এবং তাদের মধ্যে আরো এবং আরো আছে.

https://vldb2019.github.io/files/VLDB19-keynote-2-slides.pdf

এবং এটা দিয়ে কি করতে হবে? স্পষ্টতই এটি অপসারণ করা প্রয়োজন। এখানে এই আকর্ষণীয় প্রতিবেদনের একটি লিঙ্ক। কিন্তু এখন পর্যন্ত এটি ডিবিএমএসে বাস্তবায়িত হয়নি।

যারা টাকা গুনতে পারে তারা দুটো জিনিস চায়। তারা আমাদের মুছে দিতে চায়, তাই প্রযুক্তিগতভাবে আমাদের এটি করতে সক্ষম হওয়া উচিত।

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

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

সাধারণভাবে, কাজটি কিছু টেবিলে নির্দিষ্ট জিনিস, নির্দিষ্ট লাইনগুলিকে স্বয়ংক্রিয়ভাবে মুছে ফেলা হয়।

এবং আমাদের এমন একটি অনুরোধ রয়েছে, যা আমরা আজকে কথা বলব, অর্থাৎ আবর্জনা অপসারণ সম্পর্কে।

আমরা একজন অভিজ্ঞ ডেভেলপারকে এটা করতে বলেছি। তিনি এই অনুরোধটি নিয়েছেন, নিজের জন্য এটি পরীক্ষা করেছেন - সবকিছু কাজ করে। মঞ্চে পরীক্ষা করা হয়েছে - সবকিছু ঠিক আছে। রোল আউট - সবকিছু কাজ করে। দিনে একবার আমরা এটি চালাই - সবকিছু ঠিক আছে।

ডাটাবেস বৃদ্ধি পায় এবং বৃদ্ধি পায়। দৈনিক DELETE একটু ধীরে ধীরে কাজ শুরু করে।

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

কয়েক মাস পরে তাদের মনে পড়ে। এবং সেই বিকাশকারী প্রস্থান করেছেন বা অন্য কিছু নিয়ে ব্যস্ত আছেন, অন্যকে এটি ফেরত দেওয়ার নির্দেশ দিয়েছেন।

তিনি dev এ চেক করেছেন, মঞ্চে - সবকিছু ঠিক আছে। স্বাভাবিকভাবেই, আপনাকে এখনও যা জমা হয়েছে তা পরিষ্কার করতে হবে। তিনি সবকিছু কাজ করে চেক.

এরপরে কি হবে? তারপর আমাদের জন্য সবকিছু ভেঙ্গে পড়ে। এটি এমনভাবে পড়ে যে এক পর্যায়ে সবকিছু নিচে পড়ে যায়। সবাই হতবাক, কেউ বুঝতে পারছে না কি হচ্ছে। এবং তারপর দেখা যাচ্ছে ব্যাপারটা এই ডিলিটেই ছিল।

কিছু ভুল হয়েছে? এখানে কি ভুল হতে পারে তার একটি তালিকা রয়েছে। এর মধ্যে কোনটি সবচেয়ে গুরুত্বপূর্ণ?

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

• হয়তো তারা কিছু ভুল পরীক্ষা করেছে.

• হয়তো হার্ডওয়্যারটি পুরানো এবং আপনাকে এই বেস আপগ্রেড করতে হবে।

• অথবা ডাটাবেসের সাথে কিছু ভুল আছে, এবং আমাদের Postgres থেকে MySQL এ যেতে হবে।

• অথবা অপারেশনে কিছু ভুল হতে পারে।

• হয়তো কাজের সংগঠনে কিছু ভুল আছে এবং আপনি কাউকে বহিস্কার করতে হবে এবং সেরা লোক নিয়োগ করতে হবে?

কোন DBA চেক ছিল না. যদি একটি ডিবিএ থাকত, তবে তিনি এই কয়েক মিলিয়ন লাইন দেখতেন এবং এমনকি কোনও পরীক্ষা ছাড়াই বলতেন: "তারা তা করে না।" ধরুন যদি এই কোডটি GitLab, GitHub-এ থাকত এবং একটি কোড পর্যালোচনার প্রক্রিয়া থাকত এবং এমন কোন জিনিস না থাকত যে DBA-এর অনুমোদন ছাড়া এই অপারেশনটি প্রোডের উপর হবে, তাহলে অবশ্যই DBA বলবে: "এটি করা যাবে না। "

এবং তিনি বলবেন যে আপনার ডিস্ক আইও-তে সমস্যা হবে এবং সমস্ত প্রক্রিয়া পাগল হয়ে যাবে, লক থাকতে পারে এবং আপনি কয়েক মিনিটের জন্য অটোভ্যাকুয়াম ব্লক করবেন, তাই এটি ভাল নয়।

http://bit.ly/nancy-hl2018-2

দ্বিতীয় ভুল- তারা ভুল জায়গায় চেক করেছে। আমরা দেখেছি যে প্রোডে প্রচুর জাঙ্ক ডেটা জমা হয়েছে, কিন্তু ডেভেলপারের কাছে এই ডাটাবেসে ডেটা জমা হয়নি এবং স্টেজিংয়ের সময় কেউ এই জাঙ্ক তৈরি করেনি। তদনুসারে, 1টি লাইন ছিল যা দ্রুত কাজ করে।

আমরা বুঝতে পারি যে আমাদের পরীক্ষাগুলি দুর্বল, অর্থাৎ যে প্রক্রিয়াটি তৈরি করা হয় তাতে সমস্যা হয় না। একটি পর্যাপ্ত ডিবি পরীক্ষা করা হয়নি।

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

হয়তো আমাদের যন্ত্রপাতি খারাপ? যদি দেখেন, তাহলে লেটেন্সি লাফিয়ে উঠল। আমরা দেখেছি যে ব্যবহার 100%। অবশ্যই, যদি এইগুলি আধুনিক NVMe ড্রাইভ হয়, তাহলে সম্ভবত এটি আমাদের জন্য অনেক সহজ হবে। এবং সম্ভবত আমরা এটি থেকে শুয়ে থাকব না।

আপনার যদি মেঘ থাকে তবে সেখানে আপগ্রেড করা সহজ। নতুন হার্ডওয়্যারে নতুন প্রতিলিপি উত্থাপন করা হয়েছে। সুইচওভার এবং সব ঠিক আছে. বেশ সহজ.

এটা কি কোনোভাবে ছোট ডিস্ক স্পর্শ করা সম্ভব? এবং এখানে, শুধু DBA এর সাহায্যে, আমরা চেকপয়েন্ট টিউনিং নামক একটি নির্দিষ্ট বিষয়ে ডুব দিই। দেখা যাচ্ছে যে আমাদের চেকপয়েন্ট টিউনিং ছিল না।

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

পোস্টগ্রেসে সেটিংস পিছিয়ে আছে। এগুলি 10-15 বছরের পুরানো ডেটা এবং লেনদেনের জন্য ডিজাইন করা হয়েছে৷ এবং চেকপয়েন্ট কোন ব্যতিক্রম নয়।

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

এর মানে কী? সেখানে দুটি সেটিংস আছে। চেকপয়েন্ট টাইমআউট দ্বারা আসতে পারে, উদাহরণস্বরূপ, 10 মিনিটের মধ্যে। অথবা এটি আসতে পারে যখন অনেক ডেটা পূরণ করা হয়েছে।

এবং ডিফল্টভাবে max_wal_saze 1 গিগাবাইটে সেট করা আছে। আসলে, 300-400 মেগাবাইটের পরে পোস্টগ্রেসে এটি সত্যিই ঘটে। আপনি অনেক ডেটা পরিবর্তন করেছেন এবং আপনার চেকপয়েন্ট ঘটে।

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

এবং আমাদের নিশ্চিত করতে হবে যে এটি প্রায়ই কম আসে। অর্থাৎ, আমরা max_wal_size বাড়াতে পারি। এবং এটি ঘন ঘন কম আসবে।

তবে আমরা কীভাবে এটি আরও সঠিকভাবে করতে হবে তার জন্য একটি সম্পূর্ণ পদ্ধতি তৈরি করেছি, অর্থাৎ, নির্দিষ্ট ডেটার উপর ভিত্তি করে স্পষ্টভাবে সেটিংস বেছে নেওয়ার বিষয়ে কীভাবে সিদ্ধান্ত নেওয়া যায়।

তদনুসারে, আমরা ডাটাবেসের উপর দুটি সিরিজ পরীক্ষা করছি।

প্রথম সিরিজ - আমরা max_wal_size পরিবর্তন করি। এবং আমরা একটি ব্যাপক অপারেশন করছি. প্রথমত, আমরা এটি 1 গিগাবাইটের ডিফল্ট সেটিংয়ে করি। এবং আমরা অনেক মিলিয়ন লাইনের একটি বিশাল ডিলিট করি।

আপনি দেখতে পাচ্ছেন এটা আমাদের জন্য কতটা কঠিন। আমরা দেখি যে ডিস্ক আইও খুব খারাপ। আমরা কতগুলি ওয়াল তৈরি করেছি তা আমরা দেখি, কারণ এটি খুবই গুরুত্বপূর্ণ। দেখি কতবার চেকপয়েন্ট হয়েছে। এবং আমরা দেখতে পাই যে এটি ভাল নয়।

এরপর আমরা max_wal_size বাড়াই। আমরা পুনরাবৃত্তি করি। আমরা বৃদ্ধি, আমরা পুনরাবৃত্তি। এবং তাই অনেক বার. নীতিগতভাবে, 10 পয়েন্ট ভাল, যেখানে 1, 2, 4, 8 গিগাবাইট। এবং আমরা একটি নির্দিষ্ট সিস্টেমের আচরণ দেখি। এটা স্পষ্ট যে এখানে সরঞ্জামগুলি প্রোডের মতো হওয়া উচিত। আপনার অবশ্যই একই ডিস্ক, একই পরিমাণ মেমরি এবং একই পোস্টগ্রেস সেটিংস থাকতে হবে।

এবং এইভাবে আমরা আমাদের সিস্টেম বিনিময় করব, এবং আমরা জানি DBMS একটি খারাপ ভর ডিলেটের ক্ষেত্রে কীভাবে আচরণ করবে, কীভাবে এটি চেকপয়েন্ট করবে।

রাশিয়ান ভাষায় চেকপয়েন্ট হল চেকপয়েন্ট।

উদাহরণ: সূচী অনুসারে কয়েক মিলিয়ন সারি মুছুন, পৃষ্ঠাগুলি জুড়ে সারিগুলি "বিক্ষিপ্ত"।

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

যদি প্রোডে এই ধরনের অপারেশনের অনুমতি দেওয়া হয়, তাহলে আমরা শুধু শুয়ে থাকব, কারণ এটা স্পষ্ট যে রেজিমেন্টে একজন DELETE আমাদের মেরে ফেলবে।

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

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

কেন এটা তাই?

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

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

এবং আমরা চেকপয়েন্টকে অনেকবার সংরক্ষণ করতে বাধ্য করব। কিভাবে তার জন্য অপ্রয়োজনীয় অপারেশন হবে.

কিন্তু যে সব হয় না। পোস্টগ্রেসে পৃষ্ঠাগুলি 8 কিলোবাইট এবং লিনাক্সে 4 কিলোবাইট। এবং একটি full_page_writes সেটিং আছে। এটি ডিফল্টরূপে সক্রিয় করা হয়. এবং এটি সঠিক, কারণ আমরা যদি এটি বন্ধ করে দিই, তবে একটি বিপদ রয়েছে যে এটি ক্র্যাশ হলে কেবলমাত্র অর্ধেক পৃষ্ঠা সংরক্ষণ করা হবে।

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

পরবর্তী পরিবর্তনগুলিতে, শুধুমাত্র একটি নির্দিষ্ট টিপল থাকবে, তবে প্রথমবারের মতো আমরা সবকিছু লিখে রাখি।

এবং, তদনুসারে, যদি চেকপয়েন্টটি আবার ঘটে থাকে, তবে আমাদের আবার স্ক্র্যাচ থেকে সবকিছু শুরু করতে হবে এবং পুরো পৃষ্ঠাটি ধাক্কা দিতে হবে। ঘন ঘন চেকপয়েন্টের সাথে, যখন আমরা একই পৃষ্ঠাগুলি দিয়ে হাঁটছি, full_page_writes = on হতে পারে তার চেয়ে বেশি হবে, অর্থাৎ আমরা আরও WAL তৈরি করি। আরো পাঠানো হয় প্রতিলিপিতে, সংরক্ষণাগারে, ডিস্কে।

এবং, সেই অনুযায়ী, আমাদের দুটি অপ্রয়োজনীয়তা আছে।

যদি আমরা max_wal_size বাড়াই, তাহলে দেখা যাচ্ছে যে আমরা চেকপয়েন্ট এবং ওয়াল লেখক উভয়ের জন্যই এটাকে সহজ করে তুলব। এবং এটা মহান.

এর একটি টেরাবাইট রাখা যাক এবং এটি সঙ্গে বাস. এটা সম্পর্কে খারাপ কি? এটি খারাপ, কারণ একটি ব্যর্থতার ক্ষেত্রে, আমরা ঘন্টার জন্য আরোহণ করব, কারণ চেকপয়েন্টটি অনেক আগে ছিল এবং ইতিমধ্যে অনেক পরিবর্তন হয়েছে। এবং আমরা এই সব REDO করতে হবে. এবং তাই আমরা পরীক্ষা দ্বিতীয় সিরিজ না.

আমরা একটি অপারেশন করি এবং দেখি কখন চেকপয়েন্টটি সম্পূর্ণ হতে চলেছে, আমরা উদ্দেশ্যমূলকভাবে -9 পোস্টগ্রেসকে হত্যা করি।

এবং এর পরে আমরা এটি আবার শুরু করি, এবং দেখুন কতক্ষণ এটি এই সরঞ্জামের উপরে উঠবে, অর্থাৎ এই খারাপ পরিস্থিতিতে এটি কতটা REDO করবে।

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

আমরা বিভিন্ন max_wal_size আকারের জন্য এই ধরনের পরিস্থিতি পরিমাপ করি এবং বুঝতে পারি যে max_wal_size যদি 64 গিগাবাইট হয়, তাহলে একটি দ্বিগুণ খারাপ ক্ষেত্রে আমরা 10 মিনিটের জন্য আরোহণ করব। এবং আমরা মনে করি এটি আমাদের জন্য উপযুক্ত কিনা। এটি একটি ব্যবসায়িক প্রশ্ন। ব্যবসায়িক সিদ্ধান্তের জন্য দায়ীদের কাছে আমাদের এই ছবিটি দেখাতে হবে এবং জিজ্ঞাসা করতে হবে, “কোন সমস্যা হলে আমরা কতক্ষণ শুয়ে থাকতে পারি? আমরা কি সবচেয়ে খারাপ অবস্থায় 3-5 মিনিট শুয়ে থাকতে পারি? এবং আপনি একটি সিদ্ধান্ত নিন.

এবং এখানে একটি আকর্ষণীয় পয়েন্ট. আমাদের সম্মেলনে Patroni সম্পর্কে রিপোর্ট একটি দম্পতি আছে. এবং সম্ভবত আপনি এটি ব্যবহার করছেন। এটি পোস্টগ্রেসের জন্য একটি অটোফেইলওভার। GitLab এবং Data Egret এ বিষয়ে কথা বলেছেন।

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

একটি ব্যর্থতার পরে যদি আমাদের দীর্ঘ পুনরুদ্ধার হয়, তবে আমরা অন্যান্য অনেক পরিস্থিতিতে অস্বস্তিকর হব। উদাহরণস্বরূপ, একই পরীক্ষায়, যখন আমরা কিছু করি এবং কখনও কখনও 10 মিনিট অপেক্ষা করতে হয়।

আমি এখনও খুব বেশি যেতে পারব না, এমনকি যদি আমাদের একটি অটোফেইলওভার থাকে। একটি নিয়ম হিসাবে, 64, 100 গিগাবাইটের মতো মানগুলি ভাল মান। কখনও কখনও এটি এমনকি কম নির্বাচন করা মূল্যবান। সাধারণভাবে, এটি একটি সূক্ষ্ম বিজ্ঞান।

পুনরাবৃত্তি করতে, উদাহরণস্বরূপ, max_wal_size =1, 8, আপনাকে অনেকবার ভর অপারেশন পুনরাবৃত্তি করতে হবে। তুমি পেরেছো. এবং একই ভিত্তিতে আপনি আবার এটি করতে চান, কিন্তু আপনি ইতিমধ্যে সবকিছু মুছে ফেলেছেন। কি করো?

আমি আমাদের সমাধান সম্পর্কে পরে কথা বলব, এই ধরনের পরিস্থিতিতে পুনরাবৃত্তি করার জন্য আমরা কী করি। এবং এটি সবচেয়ে সঠিক পদ্ধতি।

কিন্তু এই ক্ষেত্রে, আমরা ভাগ্যবান ছিল. যদি, এখানে যেমন বলা হয় "BEGIN, DELETE, ROLLBACK", তাহলে আমরা DELETE পুনরাবৃত্তি করতে পারি। অর্থাৎ, যদি আমরা নিজেরাই এটি বাতিল করি, তবে আমরা এটি পুনরাবৃত্তি করতে পারি। এবং শারীরিকভাবে আপনার ডেটা একই জায়গায় পড়ে থাকবে। এমনকি আপনি কোন ফোলা পেতে না. আপনি এই ধরনের DELETEs উপর পুনরাবৃত্তি করতে পারেন.

রোলব্যাক সহ এই ডিলিট চেকপয়েন্ট টিউনিংয়ের জন্য আদর্শ, এমনকি যদি আপনার কাছে সঠিকভাবে স্থাপন করা ডাটাবেস ল্যাব না থাকে।

আমরা একটি কলাম "i" দিয়ে একটি প্লেট তৈরি করেছি। Postgres এর ইউটিলিটি কলাম আছে। বিশেষভাবে জিজ্ঞাসা না করা পর্যন্ত তারা অদৃশ্য। এগুলো হল: ctid, xmid, xmax।

Ctid হল একটি প্রকৃত ঠিকানা। শূন্য পাতা, পৃষ্ঠায় প্রথম টিপল।

এটি দেখা যায় যে রুলব্যাকের পরে টিপলটি একই জায়গায় রয়ে গেছে। অর্থাৎ, আমরা আবার চেষ্টা করতে পারি, এটি একইভাবে আচরণ করবে। এটাই মূল বিষয়।

Xmax হল টুপলের মৃত্যুর সময়। এটি স্ট্যাম্প করা হয়েছিল, কিন্তু পোস্টগ্রেস জানে যে লেনদেনটি রোল ব্যাক করা হয়েছিল, তাই এটি 0 বা এটি একটি রোলড ব্যাক লেনদেন কিনা তা বিবেচ্য নয়। এটি পরামর্শ দেয় যে DELETE এর উপর পুনরাবৃত্তি করা এবং সিস্টেমের আচরণের বাল্ক অপারেশনগুলি পরীক্ষা করা সম্ভব। আপনি গরীবদের জন্য ডাটাবেস ল্যাব তৈরি করতে পারেন।

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

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

কেন এটা ভাঙ্গা গুরুত্বপূর্ণ?

• আমরা যদি দেখি যে ডিস্কটি শক্ত, তাহলে এর গতি কমিয়ে দেই। এবং যদি আমরা ভেঙ্গে যাই, তাহলে আমরা বিরতি যোগ করতে পারি, আমরা থ্রটলিংকে মন্থর করতে পারি।

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

https://postgres.ai/products/joe/

এটা মজার. আমি প্রায়ই দেখি যে বিকাশকারীরা জিজ্ঞাসা করে: "আমি কোন প্যাক আকার নির্বাচন করব?"।

এটা স্পষ্ট যে বান্ডেলের আকার যত বড় হবে, লেনদেনের ওভারহেড তত ছোট হবে, অর্থাৎ, লেনদেন থেকে অতিরিক্ত ওভারহেড। কিন্তু একই সময়ে, এই লেনদেনের জন্য সময় বৃদ্ধি পায়।

আমার একটি খুব সহজ নিয়ম আছে: আপনি যতটা পারেন নিতে পারেন, কিন্তু প্রতি সেকেন্ডে এক্সিকিউটেবলের উপরে যাবেন না।

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

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

আমরা প্যাকের আকার নির্বাচন করি। প্রতিটি ক্ষেত্রে, আমরা এটি ভিন্নভাবে করতে পারি। স্বয়ংক্রিয় হতে পারে। এবং আমরা এক প্যাকের প্রক্রিয়াকরণের দক্ষতা সম্পর্কে নিশ্চিত। অর্থাৎ, আমরা একটি প্যাক ডিলিট বা আপডেট করি।

যাইহোক, আমি যা বলছি তা কেবল মুছে ফেলার বিষয়ে নয়। আপনি যেমন অনুমান করেছেন, এগুলি ডেটার উপর কোন বাল্ক অপারেশন।

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

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

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

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

https://docs.gitlab.com/ee/development/background_migrations.html

বিভাজন কৌশল কি? আমি 3টি আলাদা পার্টিশনিং কৌশল দেখতে পাচ্ছি যা প্যাকের বিকাশকারীরা ব্যবহার করছে।

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

দ্বিতীয় কৌশলটি একটি ভারসাম্যপূর্ণ পদ্ধতি। এটি গিটল্যাবে ব্যবহৃত হয়। তারা টেবিল স্ক্যান করে নিয়ে গেল। আমরা আইডি প্যাকগুলির সীমানা খুঁজে পেয়েছি যাতে প্রতিটি প্যাকে ঠিক 10 রেকর্ড থাকে৷ এবং তাদের একটি সারিতে রাখুন। এবং তারপর আমরা প্রক্রিয়া. আপনি একাধিক থ্রেডে এটি করতে পারেন।

প্রথম কৌশলেও, যাইহোক, আপনি বেশ কয়েকটি থ্রেডে এটি করতে পারেন। এটা কঠিন নয়.

https://medium.com/@samokhvalov/how-partial-indexes-affect-update-performance-in-postgres-d05e0052abc

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

সাধারণত, ইনডেক্স স্ক্যানের চেয়ে শুধুমাত্র সূচক স্ক্যান দ্রুত হয়।

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

কেন এটা আমাদের দরকার? এই আমরা ফিরে রিপোর্ট করতে হবে কি. আমরা এখন আসলে অনেক লাইন মুছে ফেলেছি। এবং আমরা আইডি দ্বারা বা এই মত create_at দ্বারা সীমানা আছে. আপনি সর্বনিম্ন, সর্বোচ্চ করতে পারেন. অন্য কিছু করা যেতে পারে। আপনি এখানে অনেক কিছু করতে পারেন. এবং এটি নিরীক্ষণের জন্য খুব সুবিধাজনক।

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

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

তবে এটি সবচেয়ে অনুকূল কৌশল, কিভাবে ব্যাচে বিভক্ত করা যায় এবং একটি অনুরোধের সাথে ব্যাচগুলিতে গুলি করা, কিছুটা মুছে ফেলা ইত্যাদি।

দীর্ঘ লেনদেন https://gitlab.com/snippets/1890447

অবরুদ্ধ অটোভ্যাকুয়াম - https://gitlab.com/snippets/1889668

ব্লকিং সমস্যা - https://gitlab.com/snippets/1890428

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

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

যদি একটি বড় IO থাকে, তবে এটি পরিষ্কার যে এটি ভাল নয়।

দীর্ঘ লেনদেনও। OLTP-তে দীর্ঘ লেনদেনের অনুমতি দেওয়া উচিত নয়। এবং এখানে একটি স্নিপেটের একটি লিঙ্ক যা আপনাকে এই স্নিপেটটি নিতে এবং ইতিমধ্যেই দীর্ঘ লেনদেনের কিছু ট্র্যাকিং করতে দেয়৷

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

যদি আমাদের অনেক টেবিল থাকে যা ভ্যাকুয়াম করা হয় না, তাহলে আমাদের একটি সতর্কতা থাকা দরকার। এখানে এমন পরিস্থিতি সম্ভব। আমরা পরোক্ষভাবে autovacuum অপারেশন প্রভাবিত করতে পারেন. এটি অ্যাভিটোর একটি স্নিপেট, যা আমি কিছুটা উন্নত করেছি। এবং অটোভ্যাকুয়ামের সাথে আমাদের কী আছে তা দেখার জন্য এটি একটি আকর্ষণীয় সরঞ্জাম হিসাবে পরিণত হয়েছে। উদাহরণস্বরূপ, কিছু টেবিল সেখানে অপেক্ষা করছে এবং তাদের পালা পর্যন্ত অপেক্ষা করবে না। আপনাকে এটিকে পর্যবেক্ষণে রাখতে হবে এবং একটি সতর্কতা থাকতে হবে।

এবং সমস্যা ব্লক. ব্লক গাছের বন। আমি কারো কাছ থেকে কিছু নিতে এবং এটি উন্নত করতে পছন্দ করি। এখানে আমি ডেটা ইগ্রেট থেকে একটি দুর্দান্ত পুনরাবৃত্তিমূলক CTE নিয়েছি যা লক গাছের বন দেখায়। এটি একটি ভাল ডায়াগনস্টিক টুল। এবং এর ভিত্তিতে, আপনি মনিটরিং তৈরি করতে পারেন। কিন্তু এই সাবধানে করা আবশ্যক. আপনার নিজের জন্য একটি ছোট বিবৃতি_টাইমআউট করতে হবে। এবং লক_টাইমআউট বাঞ্ছনীয়।

কখনও কখনও এই সমস্ত ত্রুটি যোগফল ঘটতে.

আমার মতে এখানে মূল ভুল সাংগঠনিক। এটা সাংগঠনিক, কারণ কৌশল টান না. এটি নম্বর 2 - তারা ভুল জায়গায় চেক করেছে।

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

এবং আমরা সেখানে না চেক. আমরা যদি সেখানে চেক করতাম তবে আমরা নিজেরাই এটি দেখতে পেতাম। ডেভেলপার একটি ভাল পরিবেশে চেক করলেও DBA ছাড়াই সব দেখেছেন, যেখানে একই পরিমাণ ডেটা এবং একটি অভিন্ন অবস্থান রয়েছে৷ তিনি এই সমস্ত অধঃপতন দেখেন এবং তিনি লজ্জিত হতেন।

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

এবং যদি আপনি প্রতিদিনের পরিচ্ছন্নতার কাজ ফিরিয়ে আনতে চান, তবে আমি এটি আরও প্রায়ই করার পরামর্শ দেব, তবে ছোট। এটি এক মিনিটে একবার বা আরও প্রায়ই হতে পারে। এবং আপনাকে দুটি জিনিস নিরীক্ষণ করতে হবে: এই জিনিসটির কোনও ত্রুটি নেই এবং এটি পিছিয়ে নেই। আমি যে কৌশলটি দেখিয়েছি তা এই সমাধান করবে।

আমরা যা করি তা হল ওপেন সোর্স। এটি গিটল্যাবে পোস্ট করা হয়েছে। এবং আমরা এটি তৈরি করি যাতে লোকেরা ডিবিএ ছাড়াও পরীক্ষা করতে পারে। আমরা একটি ডাটাবেস ল্যাব করছি, অর্থাৎ, আমরা বেস কম্পোনেন্টকে বলি যেটিতে জো বর্তমানে কাজ করছে। এবং আপনি উত্পাদন একটি অনুলিপি দখল করতে পারেন. এখন স্ল্যাকের জন্য জো এর একটি বাস্তবায়ন রয়েছে, আপনি সেখানে বলতে পারেন: "অমুক এবং এমন একটি অনুরোধ ব্যাখ্যা করুন" এবং অবিলম্বে আপনার ডাটাবেসের অনুলিপির ফলাফল পান। এমনকি আপনি সেখানে মুছে ফেলতে পারেন, এবং কেউ এটি লক্ষ্য করবে না।

ধরুন আপনার কাছে 10 টেরাবাইট আছে, আমরা ডাটাবেস ল্যাবও 10 টেরাবাইট তৈরি করি। এবং একই সাথে 10 টেরাবাইট ডেটাবেস সহ, 10 জন বিকাশকারী একসাথে কাজ করতে পারে। সবাই যা চায় তাই করতে পারে। মুছে ফেলতে পারেন, ড্রপ করতে পারেন ইত্যাদি। আমরা আগামীকাল এ বিষয়ে কথা বলব।

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

উদাহরণ: 5 টেরাবাইট ডাটাবেস, 30 সেকেন্ডেরও কম সময়ে একটি কপি পাওয়া। এবং এটি আকারের উপরও নির্ভর করে না, অর্থাৎ, কত টেরাবাইট তা বিবেচ্য নয়।

আজ আপনি যেতে পারেন postgres.ai এবং আমাদের সরঞ্জামগুলিতে খনন করুন। সেখানে কী আছে তা দেখতে আপনি নিবন্ধন করতে পারেন। আপনি এই বট ইনস্টল করতে পারেন. এটা বিনামূল্যে. লিখুন।

প্রশ্ন

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

এটি একটি খুব ভাল পদ্ধতি এবং একটি খুব ভাল কাজ. এটি pg_repack যা করে তার সাথে খুব মিল, আপনি আইডি 4 বাইট তৈরি করার সময় আপনাকে যা করতে হবে তার সাথে এটি খুব মিল। অনেক ফ্রেমওয়ার্ক কয়েক বছর আগে এটি করেছিল, এবং কেবল প্লেটগুলি বড় হয়েছে এবং তাদের 8 বাইটে রূপান্তর করা দরকার।

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

আপনি যদি গিটহাবে pg_repack দেখেন, তাহলে সেখানে, যখন একটি আইডিকে int 4 থেকে int 8 এ রূপান্তর করার একটি কাজ ছিল, তখন pg_repack নিজেই ব্যবহার করার একটি ধারণা ছিল। এটিও সম্ভব, তবে এটি কিছুটা হ্যাক, তবে এটি এর জন্যও কাজ করবে। আপনি pg_repack যে ট্রিগারটি ব্যবহার করেন তাতে হস্তক্ষেপ করতে পারেন এবং সেখানে বলতে পারেন: "আমাদের এই ডেটার প্রয়োজন নেই", অর্থাৎ আমরা কেবল আমাদের যা প্রয়োজন তা স্থানান্তর করি। এবং তারপর তিনি শুধু সুইচ এবং যে এটি.

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

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

আমি MySQL এর দুনিয়া থেকে একটু দূরে, তাই শুনতে এসেছি। এবং আমরা এই পদ্ধতি ব্যবহার.

কিন্তু এটা শুধুমাত্র যদি আমাদের 90% থাকে। যদি আমাদের 5% থাকে তবে এটি ব্যবহার করা খুব ভাল নয়।

প্রতিবেদনের জন্য ধন্যবাদ! প্রোডের সম্পূর্ণ অনুলিপি তৈরি করার জন্য কোন সংস্থান না থাকলে, লোড বা আকার গণনা করার জন্য কোন অ্যালগরিদম বা সূত্র আছে কি?

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

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

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

সূচী দিয়ে সম্পন্ন.

আমি অনুমান করতে পারি যে একই চেকপয়েন্ট টিউনিং স্বয়ংক্রিয় হতে পারে। কোন একদিন এটা হতে পারে। কিন্তু তারপর আমি সত্যিই প্রশ্ন বুঝতে পারছি না.

প্রশ্ন হল, উন্নয়নের এমন একটি ভেক্টর আছে যা এখানে এবং সেখানে যায় এবং এখানে আপনার সমান্তরাল হয়? সেগুলো. তারা কি এখনো চিন্তা করেনি?

আমি এখন ব্যবহার করা যেতে পারে যে নীতি সম্পর্কে কথা বললাম. আরেকটি বট আছে ন্যান্সি, এটি দিয়ে আপনি স্বয়ংক্রিয় চেকপয়েন্ট টিউনিং করতে পারেন। এটা কি কোন দিন Postgres এ হবে? আমি জানি না, এটি এখনও আলোচনা করা হয়নি. আমরা এখনও সেই থেকে অনেক দূরে। কিন্তু বিজ্ঞানীরা আছেন যারা নতুন সিস্টেম তৈরি করেন। এবং তারা আমাদের স্বয়ংক্রিয় সূচকে ঠেলে দেয়। উন্নয়ন আছে। উদাহরণস্বরূপ, আপনি অটো টিউনিং দেখতে পারেন। এটি স্বয়ংক্রিয়ভাবে পরামিতি নির্বাচন করে। কিন্তু তিনি এখনও আপনার জন্য চেকপয়েন্ট টিউনিং করবেন না। অর্থাৎ, এটি কর্মক্ষমতা, শেল বাফার ইত্যাদির জন্য বাছাই করবে।

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

শুভ অপরাহ্ন আপনি দীর্ঘ লেনদেনের বিপদের কথা বলেছেন। আপনি বলেছেন যে অটোভ্যাকুয়াম মুছে ফেলার ক্ষেত্রে ব্লক করা হয়েছে। এটা আমাদের আর কিভাবে ক্ষতি করে? কারণ আমরা স্থান খালি করা এবং এটি ব্যবহার করতে সক্ষম হওয়ার বিষয়ে আরও কথা বলছি। আমরা আর কি অনুপস্থিত?

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

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

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

যখন আমরা ইতিমধ্যে একটি আবর্জনা নির্বাচন করছি এবং আমাদের আছে, উদাহরণস্বরূপ, একটি মুছে ফেলা পতাকা

পোস্টগ্রেসে স্বয়ংক্রিয়ভাবে অটোভ্যাকুয়াম এটি করে।

ওহ, সে কি এটা করে?

অটোভ্যাকুয়াম হল আবর্জনা সংগ্রহকারী।

ধন্যবাদ!

প্রতিবেদনের জন্য ধন্যবাদ! বিভাজন করার সাথে সাথেই এমনভাবে একটি ডাটাবেস ডিজাইন করার বিকল্প আছে যাতে সমস্ত আবর্জনা মূল টেবিল থেকে পাশের কোথাও নোংরা হয়ে যায়?

অবশ্যই আছে.

তাহলে কি আমাদের রক্ষা করা সম্ভব যদি আমরা এমন একটি টেবিল লক করে থাকি যা ব্যবহার করা উচিত নয়?

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

উত্স: www.habr.com