پایگاه داده NoSQL نام یک خانواده از سامانه‌های ذخیره‌سازی داده است، نه یک محصول واحد. عبارت Not only SQL نشان می‌دهد انتخاب‌ها به مدل رابطه‌ای محدود نیستند. بااین‌حال، همهٔ این سامانه‌ها داده را در سند JSON ذخیره نمی‌کنند و هیچ قاعده‌ای نمی‌گوید در هر پروژه از SQL سریع‌ترند.
مدل‌های رایج پایگاه داده NoSQL
- کلیدـمقدار: مقدار را با یک کلید مشخص می‌خوانید؛ برای الگوهای دسترسی ساده و روشن مناسب است.
- سندی: داده‌های مرتبط را در سند نگه می‌دارد. MongoDB نمونه‌ای شناخته‌شده است و از BSON استفاده می‌کند.
- ستون‌گسترده: داده را با کلید سطر و خانواده‌های ستون سازمان می‌دهد؛ با هر پایگاه تحلیلیِ ستون‌محور یکسان نیست.
- گراف: موجودیت‌ها و ارتباط میان آن‌ها محور مدل‌اند؛ پیمایش رابطه‌ها کاربرد اصلی آن است.
دسته‌بندی رسمی AWS این تفاوت مدل‌ها را توضیح می‌دهد. نام خانواده، به‌تنهایی زبان پرس‌وجو یا ضمانت‌های هر محصول را مشخص نمی‌کند.
آیا NoSQL بدون ساختار است؟
انعطاف در Schema به معنای بی‌نیازی از طراحی نیست. مثلاً در کاتالوگ، محصول کتاب و لپ‌تاپ ویژگی‌های متفاوت دارند؛ مدل سندی می‌تواند این تفاوت را ساده‌تر نشان دهد. بااین‌حال، نوع قیمت، شناسه و قواعد اعتبارسنجی همچنان مهم‌اند. MongoDB امکان Schema Validation دارد؛ بنابراین ادعای نبود هرگونه کنترل ساختار دقیق نیست.
تراکنش و سازگاری داده
نباید همهٔ محصولات NoSQL را فاقد ACID یا صرفاً دارای سازگاری نهایی معرفی کرد. برای نمونه، MongoDB از تراکنش‌های چندسندی پشتیبانی می‌کند. ضمانت واقعی به موتور، شیوهٔ استقرار و تنظیم خواندن و نوشتن وابسته است. وجود قابلیت تراکنش نیز جای مدل‌سازی درست و آزمون خطا را نمی‌گیرد.
مقیاس‌پذیری و سرعت
مقیاس عمودی یعنی افزایش توان یک ماشین و مقیاس افقی یعنی توزیع کار میان چند ماشین. مرز «SQL فقط عمودی، NoSQL فقط افقی» درست نیست. قابلیت توزیع به محصول و معماری بستگی دارد. کلید پارتیشن نامناسب یا پرس‌وجوی بدون ایندکس می‌تواند حتی سامانهٔ توزیع‌شده را کند کند.
چه زمانی کدام مدل را انتخاب کنیم؟
اگر ارتباط‌های جدولی، گزارش‌های ترکیبی و قیود داده بخش اصلی پروژه‌اند، پایگاه رابطه‌ای می‌تواند انتخاب مناسبی باشد. اگر دسترسی‌ها حول سند یا کلید مشخص‌اند، گزینهٔ غیررابطه‌ای را هم آزمایش کنید. گراف برای مسئلهٔ رابطه‌محور ارزش دارد، نه صرفاً به‌دلیل بزرگ‌بودن داده. این پیشنهادها نقطهٔ شروع ارزیابی‌اند، نه حکم قطعی برای همهٔ سایت‌ها.
اثر انتخاب روی هاست و نگهداری
پیش از خرید سرویس، موتور و نسخهٔ پشتیبانی‌شده، محدودیت منابع، بکاپ، روش بازیابی و مسئولیت مدیریت را بررسی کنید. وجود MySQL در هاست به معنای وجود MongoDB یا Cassandra نیست. هیچ قابلیت خاصی را بدون تأیید مشخصات همان پلن به میزبان نسبت ندهید.
برای تصمیم نهایی، یک نمونه با دادهٔ نزدیک به واقعیت بسازید؛ زمان پاسخ، هزینه، بازیابی و رفتار هنگام قطع یک جزء را بسنجید. مهارت تیم و قابلیت نگهداری به اندازهٔ نمودار سرعت اهمیت دارند. انتخاب درست، پاسخی به نیاز برنامه است، نه مسابقهٔ نام فناوری‌ها.
مطالعهٔ مرتبط
بازبینی فنی: ۲۷ مهر ۱۴۰۵. تاریخ انتشار اولیه و نشانی قبلی حفظ شده‌اند.
