আমার স্টক বিশ্লেষণ রিপোজিটরির প্রথম সংস্করণ একটি OLTP ইঞ্জিনে বিশ্লেষণ চালাত, আর দ্বিতীয় সংস্করণ একই কাজ একটি OLAP স্ট্যাকে চালায়। আমি একটিমাত্র অপ্টিমাইজেশনের জন্য OLAP স্ট্যাক বেছে নিয়েছিলাম, কিন্তু এর সুবিধা নিতে আমাকে পুরো লেকহাউসটি বুঝতে হয়েছিল।
InnoDB-র নকশা তিনটি নিশ্চয়তা দেয়, যা আমার প্রাথমিক সিদ্ধান্তগুলোকে রূপ দিয়েছে। এটি একটি সারির সব কলাম একসঙ্গে সংরক্ষণ করে, তাই একটি প্রতীকের একটি বার আনতে ডিস্কের একটিমাত্র স্থান স্পর্শ করতে হয়, যা ডেটা গ্রহণের জন্য উপযুক্ত। তবে যে সূচকের মাত্র দুটি কলাম দরকার, সেও বাফার পুলের মাধ্যমে সব কলাম পড়ে। সূচক পড়াকে দ্রুত করে কিন্তু লেখাকে ধীর করে, কারণ প্রতিটি লেখায় টেবিলের প্রতিটি B-tree আপডেট করতে হয়। নির্বাচনী পড়ার জন্য এটি চমৎকার, কিন্তু লেখা-নির্ভর ডেটা গ্রহণের জন্য খুবই খারাপ, এ কারণেই আমার Raw* টেবিলে শুধু প্রাইমারি কি আছে।
InnoDB একটি undo log-ও ব্যবহার করে, যা একই সময়ে পড়া ও লেখার সুযোগ দেয়। কোনো সারি আপডেট বা মুছে ফেলা হলে পুরনো মান সংরক্ষিত থাকে, যাতে অন্য সেশন এখনও তা পড়তে পারে। ইনসার্টের জন্য একটি ছোট undo log তৈরি হয়, যা কমিটের সময় মুছে ফেলা হয়। আপডেট ও ডিলিটের undo log একটি বৈশ্বিক ইতিহাস তালিকায় যুক্ত হয়, যা InnoDB তখনই পরিষ্কার করে যখন কমিটের আগে শুরু হওয়া সব সেশন শেষ হয়। এই প্রক্রিয়াকে বলে Multi-Version Concurrency Control, বা MVCC, যা পড়াকে আটকে না রেখে ইনসার্ট ও আপডেট করার সুযোগ দেয়।
বুঝতে না পেরে আমি আমার InnoDB ডেটাবেসটিকে একটি OLAP ভিত্তির উপর নকশা করে ফেলেছিলাম। আমার financialdata টেবিলে তারিখ-সময়ের সঙ্গে OHLC মূল্য ছিল, এবং প্রতিটি প্রযুক্তিগত সূচককে তারিখ খুঁজতে এর সঙ্গে জয়েন করতে হতো। এটি ছিল আমার সবচেয়ে খারাপ ডেটা নকশাগুলোর একটি, এবং ডেটাবেসে ১০০GB-এর বেশি ডেটা জমার পর আমি তা বুঝতে পারি। এটি ঠিক করা ছিল অত্যন্ত কষ্টকর।
উৎস: Hacker News · সারাংশ: HeadlinesBriefing