خواص ACID در مقابل BASE

مطلب زیر تماما از نشریه اینترنتی سلام دنیا بازنشر میشود.

در علم شیمی pH یک کمیت برای مشخص کردن نسبت اسیدی یا بازی بودن یک محلول در آب است. تغییرات pH در بازه ۰ تا ۱۴ قرار دارد و محلول بشدت اسیدی مانند اسید باطری عدد ۰ و محلول بشدت بازی مثل lie عدد ۱۴ را کسب می‌کند. این در حالی است که آب در دمای ۲۵ درجه سلسیوس دارای pH ۷ است و این حالت را خنثی می‌نامند.

مهندسین داده با هوشمندی این استعاره را از شیمی‌دان‌ها وام گرفتند و آن را به یک اختصار تبدیل کرده‌اند. البته شاید معنی واقعی خود را نداشته باشد، اما زمانی که بحث درباره قابلیت اطمینان پردازش کردن تراکنش است همچنان نشان‌دهنده رویداد‌های مربوط به  یک سیستم  پایگاده داده است.  برای گسترش دادن بیشتر این استعاره مفید اجازه بدهید اول نگاهی به ایده pH بکنیم.

اولین بار «سورنسن» در حالی که در آزمایشگاه کارلسبرگ در ۱۹۹۰ در حال کار بود، این مفهموم  را توسعه داد. بنابراین ایده مربوط به زمان حاظر نیست. در اینجا حرف «H» به اتم‌های هیدروژن اشاره دارد و در مورد حرف «p» بحث و اختلاف فراوانی وجود دارد. برخی آن را از واژه فرانسوی «puissance»، برخی آن را از واژه آلمانی «potenz» و برخی دیگر آن را از واژه لاتین «pondus» یا «potentia» می‌دانند. اما هرچه باشد همه این‌ها به معنی پتانسیل یا توان (power) است. بنابراین pH به معنای قدرت، پتانسیل یا فعالیت اتم‌های هیدروژن در محلول است. محلول‌های اسیدی فعالیت بیشتری دارند و محلول‌های قلیایی کمتر فعالند.

در پردازش کردن تراکنش‌ پایگاه‌داده‌ها، داده‌ها اتم هیدروژن هستند که در سیستم جریان دارند و حرف «p» ویژگی‌هایی است که پردازش شدن این تراکنش‌ها را باداشتن قابلیت اطمینان تضمین می کند.

خواص ACID چیست؟

اگر از هر کسی که در حوزه داده‌ها حرفه‌ای است این سوال را کنید، احتمالا به خوبی می‌تواند ACID (Atomicity, Consistency, Isolation, و Durability) را شرح دهد.  مفهموم ACID برای سالیان وجود داشته است و تا همین اواخر نیز یک معیار اصلی بود که همه پایگاه‌های داده در تلاش برای کسب کردن آن بودند.  آگر پایگاه‌داده‌ای ACID را نمی‌داشت، قابلیت اطمینان آن زیر سوال می‌رفت.

جیم گری اولین بار در سال ۱۹۷۰ این ایده را به تصویر کشید و پس از آن مقاله بدیع «مفهمو تراکنش: خواص و محدودیت‌ها» را در ژوئن ۱۹۸۱ منتشر کرد. در این مقاله تنها اصطلاحات تمامیت (یا همه یا هیچ)، یکپارچگی و پایائی مورد بحث قرار گرفته بودند و پس از آن بود که اصطلاح انزوا نیز اضافه شد.

در آن مقاله بر روی سطح تراکنش تمرکز شده بود و تراکنش را به عنوان قرارداد یا هر تعداد از «تراکنش‌های حالت سیستم» که مجبور به داشتن CAD به عنوان خواص ذاتی یا «محدودیت‌های قابلیت اطمینان سیستم» بودند، مشخص کرده بود.

«بروس لیندی» و همکاران مقاله «یادداشت‌هایی بر پایگاه داده‌های توزیعی» را در ۱۹۷۹ منتشر کردند که بر روی کار‌ «گری» ایجاد شده بود. او اصول را برای دستیابی به قابلیت اطمینان و استاندار‌های اولیه تکرار پایگاه داده ایجاد کرد. در سال ۱۹۸۳ «آندریاس روتر» و «تئو هاردر» مقاله «مفاهیم بازیابی پایگاه‌داده‌های تراکنش‌گرا» را منتشر کرد و به طور رسمی اصطلاح  ACID را به کار برد. این اصطلاح دو دهه بعد به صورت زیر معنی شد:

تمامیت: هیچ وظیفه (یا همه وظایف) درون یک تراکنش اجرا نمی‌شوند مگر اینکه همه آنها انجام شوند. این اصل «همه یا هیچکس» است، اگر یکی از اجزای تراکنش با شکست روبرو شد همه تراکنش‌ها با شکست روبرو می‌شود.

قابلیت اطمینان: تراکنش باید تمام پروتکل‌ها یا قوانین تعریف شده توسط سیستم در تمام زمان‌ها را تامین کند. تراکنش نباید آن پروتکل‌ها را نقض کند و پایگاه‌داده‌ها باید در یک حالت پایدار در آغاز و پایان تراکنش بمانید. هرگز هیچ گونه تراکنش نیمه انجام شده‌ای وجود ندارد

انزوا: هیچ تراکنشی به تراکنش دیگر که در یک حالت میانی و ناتمام است دسترسی ندارد. بنابراین هر تراکنش به خودی خود مستقل است. این موضوع برای کارایی و انزوای تراکنش‌ها در یک پایگاه‌داده‌ها نیاز است.

پایائی: زمانی که یک تراکنش کامل شد، در حالت انجام شده باقی می‌ماند و امکان بازگشت آن وجود ندارد. این تراکنش از شکست سیستم، قطع شدن برق و انواع دیگر از کارافتادگی سیستم مصون خواهد بود.

جنبه‌های بسیار دیگری برای این تعاریف وجود دارد و تامین نیازمندی‌های واقعی ACID مختص به هر پایگاه‌داده‌ها خاص است. اما در کل در دنیای RDMS همه چیز ACID است و بدون ACID قابلیت پایداری زیر سوال می‌رود.

عدد pH مربوط به ACID پایین است، تقریبا چیزی شبیه به اسید باطری (۰) و یا شاید سرکه (۲)، در این حالت داده و محدودیت‌های آن بسیار فعال هستند. بنابراین در هر میکروثانیه از یک پایگاه‌داده‌ها که از ACID به عنوان سیستم محدودیت استفاده می‌کند، همه داده‌ها (اتم‌های هیدروژن) تحت بررسی ثابت هستند تا از این برآورده شدن محدودیت‌ها اطمینان حاصل کنند. چنین محدودیت‌هایی برای سالیان در دنیای رابطه‌ای،‌نرمال، طرح واره محور، مقیاس پذیر افقی و کوچک پیش از شبکه‌های اجتماعی به خوبی کار می‌کرد.

این بدیهیات گذشته دیگر مطرح نیستند و اکنون داده بدون ساختار، بزرگ‌داده، ساختار‌های داده غیر رابطه‌ای، سیستم‌های محاسباتی توزیع شده و قابلیت اطمینان نهان اکنون متداول شده‌اند. این نیازمندی‌های جدید به کلمات اختصاری جدید و pH جدید نیاز دارد.

قضیه CAP:

در سال ۲۰۰۰ «اریک بروور» (Eric Brewer) سخنرانی خود را در همایش ACM که در مورد مفاهیم محاسبات توزیع شده بود ارائه داد و آنجا بود که قضیه CAP متداول شد.

اکثر مردم در جهان خارج هیچ‌گاه حتی اسم این قضیه را نشنیده‌اند و اهمیتی هم برایشان ندارد. آن‌ها فقط می‌خواهند رایانه‌شان کار کند، اینترنت کار کند، شبکه‌های اجتماعی کار کنند و البته همه این‌ها  با در دسترس بودن قابلیت اطمینان فایل‌هایشان.

قضیه CAP، که با نام قضیه بروور هم شناخته می‌شود، بعد‌ها تجدید نظر شد و از طریق کار «شیت گیلبرت» و «نانسی لیچ» از MIT در سال ۲۰۰۲  تغییر کرد.

اصل اساسی قضیه می‌گوید که سه نیازمندی اساسی در سیستم وجود دارد که این اصول برای یک طراحی، پیاده‌سازی و استقرار موفق برنامه‌ها در سیستم‌های محاسباتی توزیع شده ضروری هستند. این نیازمندی‌ها قابلیت اطمینان، دسترس‌پذیری و تحمل قسمت‌بندی است، که به اختصار CAP نامیده می‌شود.

قابلیت اطمینان به این مساله اشاره می‌کند که آیا یک سیستم کاملا عمل می‌کند یا نه؟ آیا قابلت اعتماد سیستم از قوانین مشخص شده در برنامه‌نویسی‌اش با توجه به این مقررات تعریف شده پیروی می‌کند؟ آیا همه گره‌ها در یک خوشه، همه داده‌های مفروض برایشان را می‌بینند؟ این همان ایده معرفی شده در ACID است.

دسترس‌پذیری به معنای همان چیزی است که انتظارش می‌رود. آیا سیستم یا سرویس داده شده زمانی که درخواستی به آن ارسال می‌شود، حاضر است؟ آیا هر درخواست پاسخی خارج از شکست یا موفقیت را دریافت می‌کند؟

تحمل قسمت‌بندی، نشان‌دهنده این حقیقت است که یک سیستم داده شده، در شرایط از دست رفتن اطلاعات یا خرابی سیستم به عمل کردن ادامه می‌دهد. شکست یک گره نباید باعث سقوط کل سیستم شود.

این‌ها تنها تعاریف ساده‌ای از سه جنبه قضیه CAP بودند. مقالات فراوانی در این باره وجود دارد که بسیاری از تفاسیر، تحلیل‌ها و مشکلات پیچیده موجود در کاربرد‌های دنیای واقعی این قضیه را بحث کرده‌اند. دلیل اصلی معرفی قضیه این نکته است که در اکثر نمونه‌ها و سیستم‌های توزیع شده تنها می‌توانند دو ویژگی از این ویژگی‌ها را تضمین کند. در اینجا چشم‌پوشی می‌تواند نتایج فاجعه باری داشته باشد که شامل احتمال شکست خوردن تمام سه عامل به صورت همزمان و جداگانه است.

محدودیت‌های قضیه CAP با قابلیت اطمینان پایگاه‌داده‌ها برای سیستم‌های بزرگ مقیاس، توزیع‌شده، غیررابطه‌ای همچنان پابرجا است. بیشتر اوقات آن‌ها به دسترس‌پذیری و تحمل قسمت‌بندی نیاز دارند. بنابراین قابلیت اطمینان فدا می‌شود و ACID سقوط می‌کند. یک عبارت مناسب اینجا این است که «برای تپه‌ها بران» (هرچه می‌توانی برو، سریع برو)

خواص BASE خودش را معرفی می‌کند

خوشبختانه در دنیای سیستم‌های محاسباتی توزیع شده، مهندسین باهوش وجود دارند. چگونه سیستم‌های گسترده جهانی مانند بیگ‌تیبل گوگل (Google’s BigTable)، آمازون دینامو و کاساندرای فیسبوک با از دست دادن قابلیت اطمینان سر و کله می‌زنند و قابلیت اطمینان سیستم را نیز حفظ می‌کنند؟

پاسخ این سوال در حالی که قطعا ساده نیست، اما جواب BASE (Basically Available, Soft state, Eventual consistency) است.

در یک سیستم در حالی که BASE نیازمندی اصلی برای قابلیت اطمینان است، فعالیت یا پتانسل (p) از تغییرات داده (H) اساسا آرام کردن آن است. در مقیاس گذاری pH، یک BASE نردیک‌تر به آب صابونی است (۱۲) یا شاید نمک دریاچه بزرگ (۱۰).

ادعای چنین اظهار نظری این نیست که میلیون‌ها تراکنش به سرعت رخ نمی‌دهند، بلکه رخ می‌دهند و تنها محدودیت‌های اعمال شده بر آن‌ها تغییر کرده است. آن محدودیت‌ها در زمان‌های متفاوت با قوانین متفاوت رخ می‌دهند.

اساسا در دسترس: این محدودیت بیان می‌کند که این سیستم آماده بودن داده‌ها را با توجه به قضیه CAP تضمین می‌کند و یک پاسخ به هر درخواستی وجود دارد. اما این پاسخ می‌تواند «شکست» برای داده درخواست شده باشد، و یا ممکن است این داده‌ها در یک وضعیت نامناسب یا در حال تغییر باشد. این مساله مشابه اتفاقاتی است که برای پاس شدن یک چک ممکن است اتفاق بیفتد.

حالت نرم: حالت سیستم می‌تواند در طول زمان تغییر کند. حتی در طول زمانی که هیچ ورودی وجود ندارد ممکن است تغییرات برای رسیدن به «قابلیت اطمینان نهایی» انجام شود. بنابراین این حالت از سیستم همیشه «نرم» است.

قابلیت اطمینان نهایی: سیستم در نهایت قابلیت اطمینان خواهد شد، پس از آن که دریافت ورودی به پایان برسد. دیر یا زود داده به همه‌جا گسترش پیدا می‌کند، اما سیستم به دریافت ورودی ادامه می‌دهد و قابلیت اطمینان هر تراکنش را پیش از آغاز تراکنش بعدی بررسی می‌کند. جزئیات کامل این موضوع در مقاله «قابلیت اطمینان نهایی- بازبینی شده» آمده است.

نتیجه‌گیری: حرکت به جلو

میزان pH جدید پردازش کردن تراکنش پایگاه‌داده‌ها، امکان مقیاس‌گذاری عمومی را با سطوح مقرون به صرفه کارآمد می‌کند. بررسی قابلیت اطمینان هر تراکنش منفرد در هر لحظه از هر تغییر هزینه‌ عظیمی را به یک سیستم که دارای ترلیون‌ها تراکنش است اضافه می‌کند. نیازمندی‌های محاسباتی حتی بیشتر نجومی هستند.

«قابلیت اطمینان نهایی» این امکان را به سازمان‌هایی چون یاهو!، گوگل، توییتر، آمازون و صدها یا میلیون‌ها سازمان دیگر می‌دهد تا با کاربرانشان در سراسر جهان تعامل داشته باشند، در حالی که هزینه‌های خود را پایین نگه می‌دارند، سیستم‌هایشان کار می‌کند و کاربرانشان خوشحال هستند. علاوه بر این‌ها خواهان داشتن قابلیت اطمینان کامل همیشگی هستند. اما همان طور که «دن پری‌چت» در مقاله «BASE یک جایگزین برای ACID» بیان کرده است، باید توازنی وجود داشته باشد و قابلیت اطمینان نهایی برای توسعه موثر سیستم‌ها با وجود افزایش نمایی داده حاصل از، شبکه‌های اجتماعی، محاسبات ابری و سایر پروژه‌های بزرگ داده وجود داشته باشند.