আপনার ডেল্টা ফিড দেরিতে হওয়া কমিট মিস করে: নির্ভরযোগ্য কার্সর তৈরি করুন

এখানে একটি ব্যর্থতা আছে যা আমি দুটি ভিন্ন ইঞ্জিনে দুবার দেখেছি। একটি এক্সপোর্ট 10:00-এ চলে এবং যে সর্বোচ্চ শেষ-পরিবর্তিত টাইমস্ট্যাম্প দেখে তা রেকর্ড করে। 09:58-এ শুরু হওয়া একটি লেনদেন এখনও খোলা, 10:03-এ কমিট হয় এবং শুরুর সময়ের একটি টাইমস্ট্যাম্প বহন করে। পরের এক্সপোর্ট কেবল 10:00-এর চেয়ে নতুন সারি চায় এবং এটিকে কখনও দেখে না। স্থানান্তরের আকার চমৎকার ছিল আর তথ্য ছিল ভুল।

যে এক্সপোর্ট একটি সারি হারাল তা অনুসরণ করুন

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

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

ক্রম-সংখ্যাগুলোরও ভিন্ন কারণে একই ধরনের ত্রুটি আছে। একটি একঘেয়ে ID আপনাকে বলে মানগুলো কোন ক্রমে বরাদ্দ হয়েছে, লেনদেনগুলো কোন ক্রমে কমিট হয়েছে তা নয়। কম সংখ্যা নেওয়া একটি লেনদেন বেশি সংখ্যা নেওয়া লেনদেনের পরে কমিট হতে পারে, তাই বরাদ্দ-ক্রমভিত্তিক কার্সরও ফাঁক রেখে যেতে পারে।

ফিডকে যে পাঁচটি প্রতিশ্রুতি দিতে হবে

পরিবহন বাছাই করার আগে উৎস সিস্টেমের কাছে পাঁচটি ধারার একটি চুক্তি চান। কোনো ধারা অনুপস্থিত থাকলে আপনার হাতে পরিবর্তন-ফিড নয়, একটি হিউরিস্টিক।

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

একটি সমর্থিত ব্যবস্থা পাঁচটিই পূরণ করতে পারে। SQL Server-এর পরিবর্তন-ট্র্যাকিং ডকুমেন্টেশন একটি নির্দিষ্ট প্রকাশিত উদাহরণ: এটি একটি ন্যূনতম বৈধ সংস্করণ সংজ্ঞায়িত করে, পরিবর্তনের পাশাপাশি মুছে ফেলাও রেকর্ড করে, এবং এমন একটি স্ন্যাপশট লেনদেন বর্ণনা করে যা যাচাই, সংস্করণ-ধারণ ও সংশ্লিষ্ট পরিবর্তন-কোয়েরিগুলোকে একসঙ্গে ধরে। এটি উৎসের কাছে কী দাবি করবেন তার উদাহরণ, অন্য ইঞ্জিনে পেস্ট করার সিনট্যাক্স নয়।

চেকপয়েন্টকে পাইপলাইনের অংশ হিসেবে নকশা করুন

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

cursor  = durable_checkpoint()          # last fully applied position
batch   = extract(cursor, upper_bound)  # one consistent batch
apply(batch)                            # idempotent at the target
commit()
checkpoint(batch.upper_bound)           # only now

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

মুছে ফেলার জন্য সিদ্ধান্ত নয়, রেকর্ড দরকার

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

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

তারপর মাপুন ডেল্টাটি কি সার্থক ছিল

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

শেষ-পরিবর্তিত কলাম একটি ইঙ্গিত। যে কার্সর দেরি হওয়া কমিট, মুছে ফেলা ও দীর্ঘ বন্ধ সহ্য করে তা একটি চুক্তি।