تفاوت بنیادین SQL و NoSQL: سازگاری، در دسترس بودن و تحمل تقسیمبندی در قضیه CAP
قضیه CAP حکم میکند که پایگاههای داده توزیعشده هنگام قطع شدن اتصالات شبکه، باید بین سازگاری کامل و در دسترس بودن مطلق یکی را انتخاب کنند. درک این بدهبستان ریاضی نشان میدهد که چرا برنامههای کاربردی مدرن برای عملکرد خود از هر دو سیستم SQL و NoSQL استفاده میکنند.
به قلم آیدا امینی
این خبر را به اشتراک بگذارید
- طرفداران سازگاری سختگیرانه
- مهندسانی که سیستمهای دفتر کل مالی، سیستمهای موجودی و برنامههای کاربردی اصلی سازمانی را میسازند و استدلال میکنند که ارائه دادههای قدیمی یا متناقض بدتر از از کار افتادگی موقت است.
- حامیان در دسترس بودن بالا
- توسعهدهندگان شبکههای اجتماعی، پلتفرمهای استریم و سیستمهای محاسبات لبه که آنلاین و پاسخگو نگه داشتن برنامه را به هر قیمتی در اولویت قرار میدهند و سازگاری نهایی را به عنوان یک بدهبستان ضروری میپذیرند.
- نوآوران NewSQL
- معمارانی که تلاش میکنند با استفاده از ساعتهای اتمی و الگوریتمهای اجماع پیشرفته، شکاف را پر کنند تا در دسترس بودن بالا را بدون قربانی کردن سازگاری سختگیرانه فراهم کنند.
در اصل، تفاوت بین پایگاههای داده SQL و NoSQL نه در مورد جداول در مقابل اسناد JSON است و نه در مورد زبان پرسوجوی خاصی که برای استخراج دادهها استفاده میشود. بلکه یک انتخاب معماری بنیادین در مورد این است که یک سیستم در مواجهه با قطع شدن اجتنابناپذیر شبکه فیزیکی متصلکننده سرورهایش، چه واکنشی باید نشان دهد.[7][8]
سالهاست که صنعت فناوری مملو از ادعاهای بازاریابی درباره پایگاههای داده NoSQL «با قابلیت مقیاسپذیری نامحدود» و دفتر کلهای توزیعشده «ناگسستنی» بوده است. با این حال، زیر هیاهوی تکرار سراسری و بیدرز دادهها، یک مرز ریاضی سختگیرانه نهفته است که هیچ میزان سرمایه خطرپذیر یا کدنویسی هوشمندانهای نمیتواند آن را دور بزند.[1][6]
این مرز همان قضیه CAP است. این قضیه که در سال ۲۰۰۰ توسط دانشمند علوم کامپیوتر، اریک بروئر (Eric Brewer)، تدوین شد، حکم میکند که یک ذخیرهساز داده توزیعشده تنها میتواند دو مورد از سه تضمین زیر را به طور همزمان ارائه دهد: سازگاری (Consistency)، در دسترس بودن (Availability) و تحمل تقسیمبندی (Partition Tolerance).[2][7]
برای درک این سازوکار، ابتدا باید تعاریف عامیانه این اصطلاحات را کنار بگذاریم. در چارچوب CAP، «سازگاری» به قوانین پایگاه داده مانند کلیدهای خارجی یا محدودیتهای یکتا اشاره ندارد. بلکه به این معنی است که هر درخواست خواندن، جدیدترین داده نوشتهشده را دریافت کند، یا یک خطا دریافت نماید.[3][7]
در همین حال، «در دسترس بودن» به این معناست که هر درخواست، پاسخی غیر از خطا دریافت کند. نکته حیاتی این است که این تضمین، وعده نمیدهد که پاسخ حاوی جدیدترین داده نوشتهشده باشد. یک سیستم در دسترس، آنلاین میماند و به کاربر پاسخ میدهد، حتی اگر مجبور باشد دادههای کمی قدیمی را ارائه کند.[3][8]
در نهایت، «تحمل تقسیمبندی» به این معناست که سیستم به کار خود ادامه دهد، با وجود اینکه تعداد نامشخصی از پیامها توسط شبکه متصلکننده گرهها، از دست رفته یا به تأخیر افتاده باشند. در یک سیستم توزیعشده که در چندین سرور فیزیکی گسترده شده است، تقسیمبندیهای شبکه یک احتمال نیستند؛ بلکه یک امر اجتنابناپذیرند.[2][3]
از آنجا که شبکههای فیزیکی همیشه با از دست دادن بستهها، قطع شدن کابلها یا خرابیهای مسیریابی مواجه خواهند شد، تحمل تقسیمبندی عملاً برای هر سیستم توزیعشدهای اجباری است. بنابراین، انتخاب واقعی که مهندسان باید انجام دهند، انتخاب دو مورد از سه مورد نیست، بلکه انتخاب بین سازگاری و در دسترس بودن در هنگام وقوع تقسیمبندی است.[4][6]
بنابراین، انتخاب واقعی که مهندسان باید انجام دهند، انتخاب دو مورد از سه مورد نیست، بلکه انتخاب بین سازگاری و در دسترس بودن در هنگام وقوع تقسیمبندی است.
اینجاست که شکاف تعریفی بین SQL و NoSQL پدیدار میشود. پایگاههای داده رابطهای سنتی، که اغلب از SQL استفاده میکنند، از لحاظ تاریخی برای اجرا روی یک گره عظیم واحد طراحی شده بودند. هنگامی که این سیستمها مجبور به استفاده از معماری توزیعشده میشوند، معمولاً به طور پیشفرض سازگاری را بر در دسترس بودن اولویت میدهند و یک سیستم CP (سازگاری و تحمل تقسیمبندی) ایجاد میکنند.[7][8]
اگر تقسیمبندی شبکه در یک سیستم CP رخ دهد، پایگاه داده از پذیرش دادههای جدید خودداری میکند تا از ایجاد وضعیتهای متناقض در گرههای جدا شده جلوگیری کند. سیستم از دقت مطلق دادهها محافظت میکند، اما به بهای بازگرداندن خطا به کاربرانی که قصد بهروزرسانی اطلاعات خود را دارند.[7]
در مقابل، جنبش NoSQL از نیاز به در دسترس بودن در مقیاس عظیم وب متولد شد. سیستمهایی مانند داینامو (Dynamo) آمازون یا آپاچی کاساندرا (Apache Cassandra) عموماً به عنوان سیستمهای AP (در دسترس بودن و تحمل تقسیمبندی) طراحی شدهاند. آنها در دسترس بودن را بر سازگاری اولویت میدهند.[8][9]
هنگامی که شبکه در یک سیستم AP تقسیم میشود، هر دو طرف تقسیمبندی به پذیرش دادههای جدید ادامه میدهند. سیستم برای کاربران بسیار در دسترس باقی میماند، اما سناریویی ایجاد میکند که در آن دادهها از هم واگرا میشوند. پایگاه داده برای ادغام این دادههای متناقض، پس از ترمیم شبکه، به «سازگاری نهایی» (eventual consistency) متکی است.[6][9]
زبان بازاریابی پیرامون NoSQL اغلب این واقعیت را نادیده میگیرد و سازگاری نهایی را به عنوان یک فرآیند جزئی در پسزمینه معرفی میکند. در عمل، این بدان معناست که ممکن است کاربر کالایی را به سبد خرید خود اضافه کند، صفحه را بهروزرسانی کند و برای مدت کوتاهی سبد خرید خالی ببیند، زیرا درخواست خواندن او به گرهای هدایت شده که هنوز بهروزرسانی را دریافت نکرده است.[1][6]
با این حال، تفسیر سختگیرانه «انتخاب دو مورد» از قضیه CAP به طور فزایندهای به عنوان یک سادهسازی بیش از حد تلقی میشود. دوازده سال پس از حدس اولیه خود، خود بروئر توضیح داد که انتخاب بین سازگاری و در دسترس بودن یک تنظیم دائمی و سراسری برای سیستم نیست.[4][5]
این بدهبستان تنها در همان میلیثانیههایی وجود دارد که تقسیمبندی شبکه به طور فعال در حال وقوع است. هنگامی که شبکه سالم است – که زیرساخت ابری مدرن تضمین میکند در اکثریت قریب به اتفاق مواقع چنین است – یک سیستم توزیعشده با طراحی مناسب میتواند هم سازگاری عالی و هم در دسترس بودن بالا را به طور همزمان فراهم کند.[4][6]
در نهایت، ارزیابی SQL در مقابل NoSQL مستلزم فراتر رفتن از نحو پرسوجو و بررسی حالتهای شکست است. یک دفتر کل مالی نمیتواند سازگاری نهایی را تحمل کند؛ باید CP باشد. یک فید جهانی شبکههای اجتماعی نمیتواند از کار افتادگی را تحمل کند؛ باید AP باشد. چالش مهندسی واقعی، شکست دادن قضیه CAP نیست، بلکه انتخاب مصالحه صحیح برای الزامات خاص آن برنامه کاربردی است.[1][8]
نکات کلیدی
- قضیه CAP بیان میکند که سیستمهای توزیعشده تنها میتوانند دو مورد از سه ویژگی: سازگاری، در دسترس بودن و تحمل تقسیمبندی را تضمین کنند.
- از آنجا که خرابیهای شبکه اجتنابناپذیر هستند، تحمل تقسیمبندی اجباری است و این امر انتخاب بین سازگاری و در دسترس بودن را تحمیل میکند.
- پایگاههای داده SQL سنتی معمولاً سازگاری (CP) را در اولویت قرار میدهند و برای جلوگیری از تضاد دادهها، در طول خرابی شبکه از پذیرش دادههای جدید خودداری میکنند.
- پایگاههای داده NoSQL اغلب در دسترس بودن (AP) را در اولویت قرار میدهند، دادههای جدید را در طول خرابی میپذیرند و برای ادغام دادهها در آینده به سازگاری نهایی متکی هستند.
- بدهبستان بین سازگاری و در دسترس بودن دائمی نیست؛ بلکه فقط در لحظاتی که تقسیمبندی شبکه رخ میدهد، اعمال میشود.
بررسی عمیق دیدگاهها
طرفداران سازگاری سختگیرانه
مهندسانی که سیستمهای مالی میسازند استدلال میکنند که ارائه دادههای متناقض بدتر از از کار افتادگی موقت است.
برای توسعهدهندگانی که روی دفتر کلهای بانکی، مدیریت موجودی یا نرمافزار اصلی برنامهریزی منابع سازمانی (ERP) کار میکنند، دقت مطلق دادهها غیرقابل مذاکره است. این دیدگاه استدلال میکند که یک سیستم AP (در دسترس و تحملکننده تقسیمبندی) ریسک تجاری غیرقابل قبولی را معرفی میکند. اگر تقسیمبندی شبکه رخ دهد، آنها ترجیح میدهند سیستم خطا برگرداند تا اینکه خطر سناریویی را بپذیرند که در آن کاربر وجوهی را برداشت کند که قبلاً در یک گره قطعشده خرج شده است. برای این گروه، پیچیدگی حل دادههای متناقض پس از ترمیم تقسیمبندی، بسیار بیشتر از هزینه یک وقفه موقت در سرویس است.
حامیان در دسترس بودن بالا
توسعهدهندگان برنامههای کاربردی مصرفکننده در مقیاس وب، آنلاین نگه داشتن سیستم را به هر قیمتی در اولویت قرار میدهند.
معمارانی که فیدهای شبکههای اجتماعی، پلتفرمهای استریم و سبدهای خرید دیجیتال را میسازند، تحت مجموعهای متفاوت از انگیزهها عمل میکنند. در فناوری مصرفکننده، از کار افتادگی مستقیماً به معنای از دست دادن درآمد و رها کردن کاربر است. این گروه معماریهای NoSQL و AP را میپذیرند و «سازگاری نهایی» را به عنوان یک بدهبستان ضروری و قابل مدیریت قبول میکنند. آنها استدلال میکنند که اگر کاربری در طول تقسیمبندی شبکه پستی را «لایک» کند، بهتر است که این عمل فوراً پذیرفته شود – حتی اگر کاربران دیگر برای چند ثانیه آن «لایک» را نبینند – تا اینکه یک پیام خطا نمایش داده شود که کاربر را ناامید کند.
نوآوران NewSQL
نسل جدیدی از معماران پایگاه داده تلاش میکنند با استفاده از سختافزار و الگوریتمهای پیشرفته، این شکاف را پر کنند.
توسعهدهندگان سیستمهای «NewSQL» که از انتخاب دوگانه تحمیل شده توسط تفاسیر سنتی CAP ناراضی هستند، از زیرساختهای مدرن برای به حداقل رساندن پنجره تقسیمبندی استفاده میکنند. با بهرهگیری از فناوریهایی مانند ساعتهای اتمی برای زمانسنجی دقیق جهانی و الگوریتمهای اجماع پیشرفته (مانند Raft یا Paxos)، این سیستمها تلاش میکنند مقیاسپذیری افقی NoSQL را فراهم کنند در حالی که تضمینهای سختگیرانه ACID پایگاه دادههای سنتی SQL را حفظ میکنند. اگرچه آنها نمیتوانند قضیه CAP را از نظر ریاضی شکست دهند، اما این دیدگاه بر مهندسی شبکه و سختافزار تمرکز دارد تا تقسیمبندیها آنقدر نادر و کوتاه باشند که سیستم عملاً طوری رفتار کند که گویی هر سه تضمین را دارد.
چرا مهم است
هر بار که فید شبکههای اجتماعی را بهروز میکنید، موجودی بانکی را بررسی میکنید یا کالایی را به سبد خرید دیجیتال اضافه میکنید، یک پایگاه داده توزیعشده در کسری از ثانیه تصمیم میگیرد که سرعت را در اولویت قرار دهد یا دقت را. درک نحوه شکست این سیستمها نشان میدهد که چرا برخی برنامهها دچار اختلال میشوند، چرا برخی دیگر به طور کامل از دسترس خارج میشوند و معماری نرمافزاری مدرن واقعاً در پشت صحنه چگونه کار میکند.
اصطلاحات کلیدی
- ACID
- اتمیسیته (Atomicity)، سازگاری (Consistency)، ایزولهسازی (Isolation)، و دوام (Durability)؛ مجموعهای از ویژگیها که تضمین میکنند تراکنشهای پایگاه داده به طور قابل اعتماد پردازش میشوند و به طور سنتی توسط پایگاههای داده SQL اولویت داده میشوند.
- BASE
- اساساً در دسترس (Basically Available)، حالت نرم (Soft state)، سازگاری نهایی (Eventual consistency)؛ فلسفهای در طراحی پایگاه داده که در دسترس بودن را بر سازگاری سختگیرانه اولویت میدهد و در سیستمهای NoSQL رایج است.
- Network Partition
- خرابیای که در آن یک شبکه تقسیم میشود و باعث میشود برخی از سرورها در یک سیستم توزیعشده نتوانند با سرورهای دیگر ارتباط برقرار کنند.
- Eventual Consistency
- تضمینی که اگر زمان کافی بدون بهروزرسانی جدید سپری شود، همه سرورها در یک سیستم توزیعشده در نهایت دادههای یکسانی را منعکس خواهند کرد.
- Distributed System
- یک محیط محاسباتی که در آن اجزای مختلف در چندین کامپیوتر در یک شبکه پخش شدهاند و اقدامات خود را با ارسال پیام هماهنگ میکنند.
منابع
پوشش منابع
9 منبع
3 دیدگاه شناساییشده
- [1]تیم سردبیری کوهستان
تحلیل تیم سردبیری کوهستان
مطالعه در تیم سردبیری کوهستان → - [2]UC Berkeley / PODCنوآوران NewSQL
Towards Robust Distributed Systems
مطالعه در UC Berkeley / PODC → - [3]ACM SIGACT News
Brewer's conjecture and the feasibility of consistent, available, partition-tolerant web services
مطالعه در ACM SIGACT News → - [4]IEEE Computerنوآوران NewSQL
CAP twelve years later: How the "rules" have changed
مطالعه در IEEE Computer → - [5]SE Radio
SE Radio 227: Eric Brewer: The CAP Theorem, Then and Now
مطالعه در SE Radio → - [6]ResearchGateحامیان در دسترس بودن بالا
A Critique of the CAP Theorem
مطالعه در ResearchGate → - [7]IBMطرفداران سازگاری سختگیرانه
What Is the CAP Theorem?
مطالعه در IBM → - [8]Dataversityطرفداران سازگاری سختگیرانه
No Database Is Perfect: Applying CAP Theorem to Database Choice
مطالعه در Dataversity → - [9]IJSATحامیان در دسترس بودن بالا
Data Consistency Models in Distributed Systems: CAP Theorem Revisited
مطالعه در IJSAT →
نظرات
هر زاویه. هر روز.
دریافت فناوری اخبار همراه با پوشش کامل منابع و تحلیل دیدگاهها، مستقیم در صندوق ورودی شما.