نفّذت النسخة الأولى من مستودع تحليل الأسهم الخاص بي التحليلات على محرك OLTP، بينما تشغّل النسخة الثانية نفس عبء العمل على منظومة OLAP. اخترت منظومة OLAP من أجل تحسين واحد، لكنني احتجت إلى فهم مستودع البيانات الموحد بالكامل كي أستفيد منه.
يقدّم تصميم InnoDB ثلاثة ضمانات شكّلت خياراتي الأولى. فهو يخزّن جميع أعمدة الصف معًا، لذا فإن جلب شريط واحد لرمز واحد يصل إلى موضع واحد على القرص، وهذا مناسب لاستيعاب البيانات. ومع ذلك، فإن المؤشر الذي يحتاج عمودين فقط يجلب جميع الأعمدة عبر مجمع المخازن المؤقتة. تسرّع الفهارس القراءة لكنها تبطئ الكتابة، لأن كل عملية كتابة يجب أن تحدّث كل شجرة B في الجدول. هذا ممتاز للقراءات الانتقائية وسيئ جدًا لاستيعاب البيانات كثيفة الكتابة، ولهذا تحتوي جداول Raw* لديّ على مفتاح أساسي فقط.
يستخدم InnoDB أيضًا سجل التراجع (undo log) الذي يتيح القراءة والكتابة المتزامنتين. عند تحديث صف أو حذفه، تُحفظ القيمة القديمة كي تتمكن الجلسات الأخرى من قراءتها. تحصل عمليات الإدراج على سجل تراجع أصغر يُحذف عند التثبيت. وتنضم سجلات التراجع الخاصة بالتحديث والحذف إلى قائمة تاريخ عامة، يطهّرها InnoDB بعد انتهاء جميع الجلسات التي بدأت قبل التثبيت. تُعرف هذه الآلية بالتحكم في التزامن متعدد الإصدارات، أو MVCC، وهي تتيح تنفيذ الإدراج والتحديث دون حجب القراءات.
ومن دون أن أدرك ذلك، صممت قاعدة بيانات InnoDB الخاصة بي على أساس من OLAP. كان جدول financialdata يحتوي على التاريخ والوقت مع أسعار OHLC، وكان كل مؤشر فني يتطلب ربطًا به لإيجاد التاريخ. كان هذا من أسوأ تصاميم البيانات لديّ، ولم أدرك ذلك إلا بعد أن تجاوزت قاعدة البيانات 100 جيغابايت. وكان إصلاحه مرهقًا للغاية.
المصدر: Hacker News · لخّصه HeadlinesBriefing