منظور از Journaling در فایل سیستم چیست؟ Journal در Database چیست؟ Journal چه خصوصیاتی دارد؟ چه تفاوتی بین Journaling در Database و Journaling در File System وجود دارد؟ در این مقاله به تحلیل و بررسی Journaling در مفاهیم فایل سیستم و بحث دیتا خواهیم پرداخت و ویژگی های آن را بررسی و تحلیل خواهیم کرد.
اگر با SQL و مباحث Database آشنایی دارید و یا اگر با فایل سیستم های XFS ، ZFS و یاext3,4 کار کرده اید تا به حال با اصطلاح Journal برخورد داشته اید. هدف اصلی Journal چه درDatabase و چه در File System این است که در هنگام Disaster از خراب شدن ساختار داده و خود داده جلوگیری کند و این نقطه مشترک مفهوم Journaling در Database و File System است. اما در این مقاله ابتدا به بررسی این مفهوم در فایل سیستم پرداخته و سپس آن را در دیتابیس نیز بررسی می کنیم.
بررسی مفهوم File System Journaling
یک Journaling Filesystem در حقیقت فایل سیستمی است که؛ ورودی هایی که هنوز به شکل کامل در قسمت اصلی دیسک ذخیره نشده اند را زیر نظر می گیرد، ازData Structure آنها برای خودشMetadata و Log بر می دارد و در محلی به عنوان Journal ذخیره می کند تا جلوی corrupt شدن اطلاعات موجود در فایل سیستم را بگیرد. به عبارت دیگر یک Journaling Filesystem پیش از ذخیره کردن اصل تغییرات به صورت Random، یک Log Record به صورت Sequential می نویسد که این Log Record به شکلی کامل اصل تغییرات را تشریح می کند.
قابلیت Journaling همانند fsck نیست ، بلکه به نوعی جایگزین آن شده است؛ در فایل سیستم هایی که قابلیت Journaling را ندارند (به عنوان مثال) به هنگام Power Loss زمانی که مجدد اقدام بهboot سیستم عامل خود می کنید بایدCheck Utility بر رویFile System اجرا شود که فرآیندی زمانبر است و ممکن است بی نتیجه باشد. اما زمانی که قابلیت Journaling در فایل سیستم موجود باشد سیستم ابتدا اقدام به خواندنMetadata موجود درFilesystem کرده و از طریقLog هایی که درون قسمتJournaling ذخیره شده در زمان کوتاهی اقدام به تعمیر ساختار دیتای موجود در فایل سیستم کرده و کمک می کند تا دیتا به وضعیت پایدار خود باز گردد. همچنین باید در نظر داشت که Journaling به معنای Redundancy نیست. در واقع Journaling باعث می شود که یک فایل سیستم Recover-able باشد. Journal در فایل سیستم یک بخش جداگانه ولی مرتبط با بخش اصلی دیسک است که عملیات نوشتن بر روی دیسک را کارآمدتر می کند. همچنین Journaling باعث می شوند که I/O های Random پیش از نوشته شدن روی دیسک به Sequential تبدیل شوند.
اما هم اکنون به چالش ها و نیاز هایی که پیش از Journaling در دنیایFile System وجود داشته و مطرح بوده نگاهی کوتاه کنیم؛ موارد و انتظاراتی که به مرور زمان از File System ها می رفته مثل نیاز به داشتن پارتیشن هایی با اندازه بزرگ روی سرور، لزوم ریکاوری سریع پس از Crash یا Power Loss ، افزایش I/O و ... که همه ی این نیازها لزوم ایجاد تکنیک های جدیدی را می طلبید که بتواند این دغدغه ها را پوشش دهد.
در همین زمان فایل سیستم هایی از قبیل XFS و ext3 با مطرح کردن ویژگی هایی مثل Journaling سعی در برطرف کردن این چالش ها کردند. چرا کهJournal در واقع یکLog mode در فایل سیستم است که دیتا به هنگام ذخیره سازی ابتدا بر روی آن قرار می گیرد و سپس در محل اصلی خود ذخیره می شود تا از بروز Delay به هنگامWrite جلوگیری کند. برای مثال زمانی که یک دیسک با فایل سیستم XFS فرمت بشود به دو Partition با نام های data و همچنین journal تقسیم می شود. در نظر داشته باشید که Journaling File System بعد از اینکه دیتا وارد فایل سیستم می شود عملیات Journaling را زمانی انجام می دهد که بخواهد دیتا را بر روی دیسک ها بنویسد. Journal در لبه ی دیسک قرار دارد و وجود این مکانیسم باعث افزایش Performance در مواردی از قبیلrandom write می شود.
مفهوم Journaling در Ceph
اما نرم افزار های ذخیره سازی ای نیز هستند که از قابلیت Journaling استفاده می کند و Journaling در سطح نرم افزار ذخیره سازی با Journaling File System نباید اشتباه گرفته شود. یکی از این نرم افزار های Ceph است. نرم افزارCeph به عنوان یک Software Defined Storage ای که Open Source است به صورت یک مجموعه راهکار قابلیت های فراوانی دارد که یکی از آنها Journaling است. بینCeph journaling و مفهوم filesystem journaling تفاوت بسیاری وجود دارد. کلاستر Ceph پیش از اینکه دیتا را بخواهد به فایل سیستم بدهد عملیات Journaling را قبل از دادن دیتا به فایل سیستم انجام می دهد ولیJournaling File System گام بعدی و یک لایه پایین تر است و زمانی که دیتا را می خواهد بر روی دیسک فیزیکی بنویسد عملیاتJournaling در فایل سیستم انجام می شود.
از این رو در کلاسترCeph از Journaling File System استفاده نمی شود چرا که باعث می شود یک دیتا دوبار نوشته شود و Overhead ایجاد می کند. دقت کنید که اینجا Ceph یک فایل سیستم نیست بلکه یک SDS و یک نرم افزار ذخیره سازی است که بدون هیچ ارتباطی با فایل سیستم از قابلیت و مفهوم Journaling استفاده می کند. زمانی که در Ceph از Journaling استفاده می کنیم می توان Journal Part را بر روی یک دیسک مجزا قرار داد. یعنی اگر یک هارد دیسکHDD داریم می توانیم تعریف کنیم که Journal این هارد بر روی یک دیسک SSD مجزا قرار بگیرد. همچنین می توان Journal های چند دیسک اصلی را بر روی یک SSD واحد قرار داد یعنی یکSSD را به چند پارتیشن تقسیم کرده و درون هر پارتیشن مجزای آن Journal File مخصوص دیسک دیگری را جای داد. در این مورد نسبت 1 به 4 توصیه می شود یعنی به ازای 4 عدد دیسک HDD می تواند یک SSD را مدنظر گرفت و Journal های آن چهار عدد HDD را روی آن ذخیره کرد. این موضوع باعث افزایشThroughput شده، میزانCPU Wait یا access time را کاهش داده و در عین حال باعث کاهش write Latency هم می شود. همچنین این موضوع می تواند منجر به کاهش هزینه کلاستر ذخیره سازی نیز بشود چرا که به جای اینکه تمام دیسک های ذخیره سازی را از جنس SSD تهیه کنیم می توانیم در تنها از چند دیسک SSD استفاده کنیم و سایر دیسک ها همان HDD باقی بماند. اما یکی از معایبش آن است که اگر دیسک مجزای Journal ازبین برود ممکن است تمام دیتاهای موجود بر روی دیسک های اصلی نیز دچار آسیب می شوند. به همین دلیل در مواقعی که Journal را در دیسک مجزا قرار می دهند برای آن دیسک مجزا یکRAID 1 نیز در نظر میگیرند. همچنین در کلاستر Ceph اگر دیسک های اصلی خودشان SSD باشند با همین تناسب می توان به ازای 18 عدد SSD یک عدد NVMe در نظر گرفت و Journal های 18 عددSSD را بر روی یک NVMe ذخیره کرد. از این رو به طور معمول در کلاستر هایCeph که در سطح نرم افزار ذخیره سازی Journaling فعال است؛ دیگر در لایه فایل سیستم از فایل سیستمی استفاده می کنند که Journaling در آن به صورت پیشفرض فعال نباشد و یا بتوان Journaling File System را غیرفعال کرد چرا که منجر به دوباره کاری و ایجاد بار اضافه می شود.
اما باید در نظر داشت کهJournaling با Caching در Storage متفاوت است چرا که در Caching با هدف افزایش سرعت اصل دیتا در Caching Tier ذخیره می شود ولی در Journaling با هدف حفاظت از اصل دیتا یک سری Log و Metadata ذخیره می شود که می توان از آن به دیتای اصلی رسید. همچنین Journaling به معنایintent log نیست بلکه خود یک نوعی از intent log هست و برخی قابلیت های آن بسته به فایل سیستمی که Journaling را ارایه می کند تفاوت دارد.
بررسی مفهوم Database Journaling
اما بعد از بیان تفاوتCeph Journaling با مفهوم filesystem journaling هم اکنون به بیان تفاوتی دیگر می پردازیم؛ باید در نظر داشت که Journaling در فایل سیستم با Journaling در Database هم تفاوت دارد و یکی بودن اصطلاح آنها و همچنین شباهت سازوکارشان نباید باعث جابجا در نظر گرفتن آنها شود.
فایل سیستمی که قابلیتJournaling دارد باعث می شود که دیتای ذخیره شده در دیسک بعد از یک آسیب بتواند زودتر به ثبات و پایداری برسد اما این موضوع تنها در سطح دیسک است و یک Journal File System نمی تواند آسیب هایی که به ساختار اپلیکیشن وارد شده را برطرف کند. به عبارت دیگر بعد از تعمیراتی که توسط Journal در دیسک انجام می شود باز هم از دید اپلیکیشن خطا هایی در درون Database دیده می شود و باز هم فایل دیتابیس corrupt است.
منظور از Journaling در Database شبیه DB Transaction Log است و با آنچه که در فایل سیستم هست تفاوت هایی دارد. DB Journaling باعث می شود که اگر در هنگام اعمال تغییر و یا ذخیره داده ای در دیتابیس خللی ایجاد شود (برق سیستم قطع بشود و یا اپلیکیشن کرش کند) داده ای که تا نصفه ذخیره شده از بین نرود و ساختار پایگاه داده به هم نریزد. یعنی DB Journaling لزوم نوشته شدن کامل داده در دیتابیس را از بین می برد و(ضمن ایجاد بازدهی وPerformance بیشتر) تضمین می کند که تمام داده ها و تغییرات را تحت نظر داشته و بعد از یکDisaster می تواند به ریکاوری یک دیتابیس از بین رفته کمک کند.
به عبارت دیگر به جای این که تراکنش ها و Update ها (به صورت Random ) از همان ابتدا مستقیم درون دیتابیس ذخیره شوند، DB Journaling باعث می شود از داده Log هایی درون Journal File (به صورت Sequential ) جای داده شوند تا امکان rollback بعد از یک Disaster وجود داشته باشد. در واقع Database Journal File نقطه مقابل همان Database Core Data File است، و باعث می شود تا یک transaction log ابتدا در Journal ذخیره شده و سپس سر فرصت دیتا به Core Data File ها یا محل اصلی شان منتقل می شوند.
اما در متن فوق اشاره کردیم کهDatabase Journaling باعث افزایشPerformance نیزمی شود، ولی چگونه؟ تصور کنید زمانی را که یک Database قابلیت Journaling را نداشت در آن زمان اگر تراکنشی می بایست بر روی دیتابیس انجام می شد باید تغییرات در نهایت به صورت کامل درون Database ذخیره می شد و ذخیره در Database از جنس Random است به صورت Random Write انجام می شود و باعث ایجاد بار سنگینی بر روی دیسک می شود. ولی زمانی که Journaling فعال باشدTransaction Log هایی از تراکنش ها و تغییرات دیتابیس به صورت Sequential Write و به شکل موقت درون Journal File ذخیره می شود و از آنجایی که Sequential بار سبک تری نسبت به Random دارد در لحظه لود کلی و میزان تاخیر کاهش یافته و بازدهی (سرویسی که از آن دیتابیس استفاده می کند) افزایش می یابد.
