পোস্টগ্রেএসকিউএল অ্যান্টিপ্যাটার্নস: "মৃতদের" সৈন্যদের সাথে লড়াই করা

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

থেকে সংক্ষিপ্ত গল্প মহান নিবন্ধ:

যখন একটি সারি একটি UPDATE কমান্ড দ্বারা পরিবর্তিত হয়, তখন দুটি ক্রিয়াকলাপ বাস্তবে সঞ্চালিত হয়: DELETE এবং INSERT৷ ভিতরে স্ট্রিং এর বর্তমান সংস্করণ xmax আপডেট করা লেনদেনের সংখ্যার সমান সেট করা হয়েছে। তারপর তৈরি হয় версия версия একই লাইন; এর xmin মান পূর্ববর্তী সংস্করণের xmax মানের সাথে মিলে যায়।

এই লেনদেন শেষ হওয়ার কিছু সময় পরে, পুরানো বা নতুন সংস্করণের উপর নির্ভর করে COMMIT/ROOLBACK, স্বীকৃত হবে "মৃত" (মৃত টিপল) পাস করার সময় VACUUM টেবিল এবং সাফ অনুযায়ী.

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

#1: আমি এটি সরাতে পছন্দ করি

ধরা যাক আপনার পদ্ধতিটি ব্যবসায়িক যুক্তিতে কাজ করছে, এবং হঠাৎ এটি বুঝতে পারে যে কিছু রেকর্ডে এক্স ফিল্ড আপডেট করা প্রয়োজন:

UPDATE tbl SET X = <newX> WHERE pk = $1;

তারপরে, কার্য সম্পাদনের অগ্রগতির সাথে সাথে দেখা যাচ্ছে যে Y ক্ষেত্রটিও আপডেট করা উচিত:

UPDATE tbl SET Y = <newY> WHERE pk = $1;

... এবং তারপরও Z - কেন তুচ্ছ বিষয়ে সময় নষ্ট করবেন?

UPDATE tbl SET Z = <newZ> WHERE pk = $1;

এই রেকর্ডের কয়টি সংস্করণ এখন আমাদের ডাটাবেসে আছে? হ্যাঁ, 4 টুকরা! এর মধ্যে, একটি প্রাসঙ্গিক, এবং 3টি আপনার পরে [অটো]ভ্যাকুয়াম দ্বারা পরিষ্কার করতে হবে৷

এভাবে করবেন না! ব্যবহার করুন এক অনুরোধে সমস্ত ক্ষেত্র আপডেট করা হচ্ছে - প্রায় সবসময় পদ্ধতির যুক্তি এই মত পরিবর্তন করা যেতে পারে:

UPDATE tbl SET X = <newX>, Y = <newY>, Z = <newZ> WHERE pk = $1;

#2: ব্যবহার করুন থেকে আলাদা, লুক!

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

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2;

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

UPDATE tbl SET X = <newX> WHERE pk BETWEEN $1 AND $2 AND X IS DISTINCT FROM <newX>;

অনেক মানুষ যেমন একটি বিস্ময়কর অপারেটরের অস্তিত্ব সম্পর্কে সচেতন নয়, তাই এখানে একটি প্রতারণার শীট রয়েছে IS DISTINCT FROM এবং অন্যান্য যৌক্তিক অপারেটর সাহায্য করতে:

... এবং জটিল অপারেশন সম্পর্কে একটু ROW()- অভিব্যক্তি:

#3: আমি আমার প্রিয়তমাকে... ব্লক করে চিনতে পেরেছি

চালু করা হচ্ছে দুটি অভিন্ন সমান্তরাল প্রক্রিয়া, যার প্রত্যেকটি এন্ট্রি চিহ্নিত করার চেষ্টা করে যে এটি "প্রগতিতে আছে":

UPDATE tbl SET processing = TRUE WHERE pk = $1;

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

সমাধান # 1: টাস্কটি আগেরটিতে কমে গেছে

এর শুধু এটা আবার যোগ করা যাক IS DISTINCT FROM:

UPDATE tbl SET processing = TRUE WHERE pk = $1 AND processing IS DISTINCT FROM TRUE;

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

সমাধান # 2: উপদেষ্টা লক

একটি পৃথক নিবন্ধের জন্য একটি বড় বিষয়, যার মধ্যে আপনি পড়তে পারেন আবেদনের পদ্ধতি এবং সুপারিশমূলক ব্লকিং এর "রেক".

সমাধান # 3: বোকা কল

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

উত্স: www.habr.com