NoSQL چیست؟ پایگاه های داده برای آینده ای در مقیاس ابری

پایگاه های داده SQL دارای محدودیت هایی در انواع داده ها و سازگاری هستند. NoSQL آنها را به خاطر سرعت، انعطاف پذیری و مقیاس حذف می کند.

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

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

مزایای NoSQL بدون هزینه نیست. سیستم‌های NoSQL سرعت و مقیاس‌پذیری را نسبت به ویژگی های ACID پشت تراکنش های قابل اعتمادی که توسط پایگاه های داده SQL وعده داده شده است. و استعاره‌های مورد استفاده برای کار با داده‌ها در سیستم‌های NoSQL نیز نسبتاً جدید هستند، در مقایسه با دهه‌ها دانش سازمانی ایجاد شده پیرامون SQL.

پایگاه داده های SQL و NoSQL مبادلات مختلفی را ارائه می دهند. در حالی که آنها ممکن است در زمینه یک پروژه خاص رقابت کنند – مانند اینکه کدام یک را برای این برنامه یا برنامه آن انتخاب کنید، آنها در تصویر بزرگتر مکمل یکدیگر هستند. هر کدام برای موارد استفاده متفاوت مناسب است. تصمیم آنقدر مربوط به یکی/یا نیست، بلکه این است که کدام ابزار برای کار مناسب است.

NoSQL در مقابل SQL

تفاوت اساسی بین SQL و NoSQL آنقدرها هم پیچیده نیست. هر کدام فلسفه متفاوتی برای نحوه ذخیره و بازیابی داده ها دارند.

با پایگاه داده های SQL، همه داده ها دارای ساختار ذاتی هستند. یک پایگاه داده معمولی مانند مایکروسافت SQL Server، MySQL، PostgreSQL یا Oracle Database از طرحواره استفاده می‌کند – یک تعریف رسمی از نحوه ترکیب داده‌های درج شده در پایگاه داده. به عنوان مثال، یک ستون خاص در یک جدول ممکن است فقط به اعداد صحیح محدود شود. در نتیجه داده های ثبت شده در ستون دارای درجه نرمال سازی بالایی خواهند بود. طرح سفت و سخت یک پایگاه داده SQL همچنین انجام تجمیع بر روی داده ها را نسبتاً آسان می کند، به عنوان مثال با ترکیب داده ها از دو جدول با استفاده از دستور SQL JOIN

.

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

1. پایگاه‌های اطلاعاتی سند (به عنوان مثال MongoDB). داده‌های درج‌شده به شکل ساختارهای JSON بدون طرحواره یا «اسناد» ذخیره می‌شوند، جایی که داده‌ها می‌توانند هر چیزی از اعداد صحیح گرفته تا رشته‌ها و متن‌های آزاد باشند. نیازی به تعیین فیلدهایی که یک سند JSON در صورت وجود دارد، وجود ندارد.
2. فروشگاه‌های ارزش کلیدی (به عنوان مثال Redis). مقادیر فرم آزاد، از اعداد صحیح یا رشته‌ها تا اسناد پیچیده JSON، در پایگاه داده از طریق کلیدهایی مانند رشته‌ها قابل دسترسی هستند.
3. ذخیره‌های ستون گسترده (به عنوان مثال Cassandra). داده ها مانند یک سیستم SQL معمولی به جای ردیف در ستون ها ذخیره می شوند. هر تعداد ستون (و بنابراین بسیاری از انواع مختلف داده) را می توان در صورت نیاز برای پرس و جوها یا نمایش داده ها گروه بندی یا تجمیع کرد.
4. پایگاه‌های اطلاعاتی نمودار (به عنوان مثال Neo4j). داده ها به عنوان یک شبکه یا نمودار از موجودیت ها و روابط آنها نشان داده می شود، که در آن هر گره در نمودار یک تکه داده به شکل آزاد است.

ذخیره‌سازی داده بدون طرحواره در سناریوهای زیر مفید است:

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

پرس و جو از پایگاه داده NoSQL

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

در مقابل، هر پایگاه داده NoSQL تمایل دارد تا سینتکس خاص خود را برای پرس و جو و مدیریت داده ها داشته باشد. برای مثال، CouchDB از درخواست‌هایی به شکل JSON که از طریق HTTP ارسال می‌شوند به ایجاد یا اسناد را از پایگاه داده خود بازیابی کنید. MongoDB اشیاء JSON را از طریق یک رابط خط فرمان یا یک کتابخانه زبان از طریق یک پروتکل باینری ارسال می کند.

برخی از محصولات NoSQL می‌توانند از نحوی شبیه به SQL برای کار با داده‌ها استفاده کنند، اما فقط به میزان محدود. به عنوان مثال، Apache Cassandra، یک فروشگاه ستون گسترده، دارای زبان SQL مانند خود است، زبان پرس و جو کاساندرا یا CQL. برخی از نحو CQL مستقیماً از کتاب بازی SQL خارج شده است، مانند کلمات کلیدی SELECT یا INSERT. اما هیچ راه بومی برای انجام JOIN یا پرس و جوی فرعی در Cassandra وجود ندارد و بنابراین کلمات کلیدی مرتبط در CQL وجود ندارند.

معماری مشترک هیچ

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

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

توجه داشته باشید که طراحی اشتراک‌گذاری شده برای پایگاه‌های داده NoSQL انحصاری نیست. بسیاری از سیستم‌های SQL معمولی را می‌توان به روشی به اشتراک گذاشته شده راه‌اندازی کرد، مانند MySQL، اگرچه این معمولاً شامل قربانی کردن ثبات در سراسر خوشه برای عملکرد است.

محدودیت های NoSQL

اگر NoSQL آزادی و انعطاف زیادی را فراهم می کند، چرا SQL را به طور کامل رها نکنیم؟ پاسخ ساده این است که بسیاری از برنامه‌ها همچنان به انواع محدودیت‌ها، سازگاری و حفاظتی نیاز دارند که پایگاه‌های داده SQL ارائه می‌کنند. در این موارد، برخی از “مزایای” NoSQL ممکن است به معایب تبدیل شوند. محدودیت‌های دیگر از این واقعیت ناشی می‌شوند که سیستم‌های NoSQL فاقد ویژگی‌های خاصی هستند که در فضای SQL مسلم می‌باشند.

بدون طرح

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

برخی راه حل های NoSQL مکانیسم های اختیاری تایپ و اعتبارسنجی داده را برای داده ها ارائه می کنند. به عنوان مثال، آپاچی کاساندرا دارای تعداد زیادی انواع داده های بومی است. یادآور موارد موجود در SQL معمولی است.

ثبات نهایی

سیستم‌های NoSQL برای در دسترس بودن و عملکرد بهتر، گزینه معامله با ثبات قوی یا فوری را ارائه می‌دهند. پایگاه‌های داده متعارف تضمین می‌کنند که عملیات اتمی (همه بخش‌های تراکنش موفق می‌شوند یا هیچ کدام موفق نمی‌شوند)، سازگار (همه کاربران دیدگاه یکسانی نسبت به داده‌ها دارند)، ایزوله (معاملات رقابت نمی کنند)، و بادوام (پس از تکمیل، از خرابی سرور جان سالم به در خواهند برد).

این چهار ویژگی که مجموعاً به آنها ACID گفته می‌شود، می‌توانند در سیستم‌های NoSQL به طور متفاوتی مدیریت شوند. به جای درخواست سازگاری قوی در سراسر خوشه، که لزوماً پاسخ به درخواست‌ها را به تأخیر می‌اندازد، می‌توانید سازگاری حتی را انتخاب کنید، که اجازه می‌دهد درخواست‌ها بدون انتظار برای کپی کردن آخرین نوشته‌ها در گره‌های دیگر ارائه شوند. خوشه داده‌های درج‌شده در خوشه در نهایت در همه جا در دسترس هستند، اما نمی‌توانید زمان آن را تضمین کنید.

برای برخی از سیستم‌های NoSQL، می‌توانید یکی از چندین مورد مصالحه بین ثبات و سرعت را انتخاب کنید، اگرچه آنچه در دسترس است بین محصولات متفاوت است. برای مثال Azure Cosmos DB مایکروسافت به شما امکان می‌دهد سطح سازگاری را برای هر درخواست انتخاب کنید، بنابراین می‌توانید رفتاری را انتخاب کنید که متناسب با مورد استفاده شما باشد. معنای تراکنش، که در یک سیستم SQL تضمین می‌کند که تمام مراحل یک تراکنش (مانند اجرای فروش و کاهش موجودی) یا تکمیل شده یا برگشت داده می‌شود، در برخی از سیستم‌های NoSQL موجود است، مانند MongoDB.

NoSQL lock-in

بیشتر سیستم های NoSQL از لحاظ مفهومی مشابه هستند، اما اجرا شده متفاوتی دارند. هر کدام استعاره ها و مکانیسم های خاص خود را برای نحوه پرس و جو و مدیریت داده ها دارند.

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

اگر مثلاً از MongoDB به CouchDB (یا بالعکس) مهاجرت می کنید، باید کاری بیش از انتقال داده ها انجام دهید. همچنین باید تفاوت‌های موجود در دسترسی به داده‌ها و استعاره‌های برنامه‌ای را بررسی کنید. به عبارت دیگر، شما باید قسمت هایی از برنامه خود را که به پایگاه داده دسترسی دارند، بازنویسی کنید.

مهارت های NoSQL

یکی دیگر از نقاط ضعف NoSQL، کمبود نسبی تخصص است. در جایی که بازار استعدادهای SQL معمولی بسیار بزرگ است، بازار مهارت های NoSQL نوپا است.

برای مرجع، Indeed.com گزارش می‌دهد که تا سال ۲۰۲۲، حجم فهرست‌های شغلی برای پایگاه‌های داده SQL معمولی – MySQL، Microsoft SQL Server، Oracle Database، و غیره – بیشتر از حجم مشاغل برای MongoDB، Couchbase باقی مانده است. و کاساندرا تقاضا برای تخصص NoSQL بخش کوچکی از بازار برای مهارت های SQL است.

ادغام SQL و NoSQL

می‌توان انتظار داشت که برخی از تفاوت‌های بین سیستم‌های SQL و NoSQL در طول زمان ناپدید شوند. در حال حاضر بسیاری از پایگاه های داده SQL اکنون اسناد JSON را به عنوان یک نوع داده بومی می پذیرند و می توانند پرس و جوهایی را در برابر آن داده ها انجام دهند. برخی حتی روش‌های بومی برای اعمال محدودیت‌ها بر داده‌های JSON دارند، به طوری که با همان سختی داده‌های سطر و ستون معمولی رفتار می‌شود.

از طرف دیگر، پایگاه‌های داده NoSQL نه تنها زبان‌های پرس و جوی شبیه به SQL، بلکه سایر ویژگی‌های پایگاه‌های داده سنتی SQL، مانند ویژگی‌های ACID MongoDB را نیز اضافه می‌کنند.

یک مسیر محتمل این است که نسل‌های آینده پایگاه داده، و همچنین نسخه‌های آینده سیستم‌های پایگاه داده فعلی، پارادایم‌ها را در بر گیرند و عملکردهای SQL و NoSQL را ارائه دهند و به تجزیه‌تر کردن دنیای پایگاه داده کمک کنند. . به عنوان مثال، Azure Cosmos DB مایکروسافت از مجموعه ای از موارد اولیه در زیر کاپوت استفاده می کند تا رفتارهای هر دو نوع سیستم را به صورت متقابل بازتولید کند. Google Cloud Spanner SQL و سازگاری قوی را با مقیاس‌پذیری افقی سیستم‌های NoSQL ترکیب می‌کند.

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