از این پس مطالبم رو در سایت خودم هم منتشر می کنم. خوشحال می شم اونجا رو هم ببینید. https://salmana.ir
چند سال قبل به طور کلی یا باید اطلاعات رو توی فایل ذخیره می کردی یا از سیستم های پایگاه داده مثل mysql و mssql و یا حتی بعضا access استفاده می کردی. با ظهور nosql و تضعیف برخی قواعد ACID حالا دیگه انبوهی از سیستم های پایگاه داده وجود دارند که بعضی موقع ها تو اینکه از کدوم باید استفاده کنیم می مونیم. باید توجه داشت هر سیستم پایگاه داده برای هدف خاصی طراحی شده و نوع داده ورودی و روش پرس و جوی متفاوتی ممکنه داشته باشه.
توی این مجموعه مطالب سعی می کنیم لیست پایگاه داده ها رو بیاریم و ببینیم هر کدوم چه نوع ذخیره سازی دارن و برای چه کاری مناسب هستند. البته که با توجه به انبوه سیستم ها ممکنه بعضی از اون ها از قلم افتاده باشند که به مرور با کمک شما تکمیل می کنیم.
اصول ACID چیه و چرا باید رعایت بشن؟
این قواعد در پایگاه های داده سنتی الزاما باید رعایت بشوند تا پایگاه داده به درستی وظیفه خودش رو انجام بده و معمولا پایگاه های داده noSQL همین قواعد رو تضعیف می کنن تا به عملکرد بهتری برسند.
وقتی شما یک سامانه بانکی دارید که باید در مقابل خرابی بسیار مقاوم باشه و امنیت و صحت اطلاعات خیلی مهم هستن، نمی تونیم هیچ کدوم از قواعد ACID شامل اتمیک بودن، سازگاری، تفکیک تراکنش ها و پایداری رو تضعیف کنیم.
اتمیک بودن (Atomic): یعنی یا کار انجام بشه یا نشه. یعنی مثلا وقتی شما 100 تومن از حساب علی به حساب حسن ریختی یا نباید 100 تومن از حساب علی کم بشه یا اینکه باید این 100 تومن به حساب حسن بره. نمی شه از حساب نفر اول بره بیرون ولی به حساب نفر دوم نره.
سازگاری (Consistency): یعنی باید قواعد جامعیتی که توی سیستم تعریف کردیم یا منطقا وجود دارند حتما روی داده اعمال بشه. مثلا حداقل انتقال وجه باید 10000 تومان باشه و نباید تراکنشی که کمتر از این منتقل می کنه داشته باشیم. یا اینکه مثلا جدول الف با کلید خارجی به جدول ب وصل هست و حتما هر سطری در جدول ب باید به سطری در جدول آ وصل باشه. مثلا هر مشتری حداقل باید یک حساب بانکی داشته باشه. اگر حساب بانکی داشته باشیم که به هیچ مشتری وصل نیست اینجا صحت سامانه نقض شده.
تفکیک (Isolation): یعنی تراکنش ها وسط کار نتونن محتوای همدیگه رو ببینن. مثلا شما داری صد تومن از حساب علی بر میداری که به حساب حسن بریزی. وقتی صد تومن از حساب علی برداشتی یه تراکنش دیگه میاد موجودی علی رو می گیره می بینه صد تومن کم شده و روی همون حساب کارش رو جلو می بره. در حالی که در ادامه تراکنش اول موفق نمی شه پول رو به حساب حسن بریزه و صد تومن رو به حساب علی بر می گردونه. اینجا هست که محاسبات سامانه کلا اشتباه می شه.
پایداری (Durability): یعنی وقتی کار یک تراکنش تموم شد دیگه تا موقعی که ما خودمون تغییری توی داده ها ندادیم باید تغییرات تراکنش توی سیستم بمونه. یعنی اگر توسط تراکنش ما موجودی علی شد 900 تومن، فردا اومدیم موجودی گرفتیم باید همون 900 تومن بمونه مگر اینکه تا فردا یه تراکنش دیگه ای بزنه و موجودی خودش رو کم یا زیاد کنه.
آیا رعایت این اصول سخته؟
رعایت این قواعد برای پایگاه داده بار زیادی داره. مثلا هر بر که شما در پایگاه تغییری می دهید سیستم باید توی رکوردهای لاگ این کار شما رو ثبت کنه تا اگر به هر دلیلی مثلا قطعی برق خرابی اتفاق افتاد بتونه بعد از بالا اومدن، لیست کارهای نیمه انجام شده رو استخراج کنه و همه چیز رو به شرایط قبل خرابی برگردونه.
حالا یه پایگاه داده رو فرض کنید که هزاران رکورد در لحظه توی اون درج می شه.
یا برای اینکه تراکنش ها توی کار هم دخالت نکنن معمولا از قفل کردن استفاده می شه اینطوری که شما وقتی می خوای روی یک رکورد بنویسی این رکورد قفل می شه و هر تراکنش دیگه ای که بخواد این رکورد رو بخونه باید صبر کنه تا شما کار نوشتنت تموم بشه. مدیریت این تعداد قفل و بن بست هایی که این وسط رخ می ده کار بسیار هزینه بر و سختیه. (یعنی دو تراکنش یا بیشتر منتظر هستن که کار طرف مقابل تموم بشه و اینطوری هیچ کدوم کارشون تموم نمیشه و سیستم گیر می کنه. برای مدیریت این حالت کلی روش های مدیریت بن بست پیاده سازی شده)
اما آیا واقعا اینقدر حساسیت لازمه؟ توی بعضی سامانه ها مثل بانک و ... بله ولی خیلی جاها میشه از بعضی از این خواسته ها کوتاه بیاییم و در عوضش بتونیم کارایی بیشتری از سیستم بگیریم. اینجاست که پای سیستم های noSql به سامانه ها باز می شه.
