برنامه نویسی

NOSQL در مقابل RDB: انتخاب پایگاه داده ، متفاوت است و چه زمانی باید انتخاب کنم؟

سلام! امروز ، ما در مورد بانک اطلاعاتی ، پایگاه داده ای که از توسعه وب جدا نیست صحبت خواهیم کرد. مخصوصاً در سالهای اخیر عیاشیقوی ترین سنت RDB (پایگاه داده رابطه ای)آیا تا به حال فکر کرده اید که بین این دو پایگاه داده چه چیزی را انتخاب کنید؟

در این پست ، ما به وضوح به تفاوت های بین NOSQL و RDB اشاره خواهیم کرد و هر ویژگی و مزایا و مضرات را برای سهولت در انتخاب پایگاه داده خود مقایسه خواهیم کرد. حال ، آیا باید به دنیای Nosql و RDB برویم؟

1. RDB (پایگاه داده رابطه ای) -حد مدیریت داده های سنتی؟

RDB به مدت چندین دهه به عنوان استاندارد برای مدیریت داده ها ایجاد شده است. اما محیط سرویس وب به سرعت در حال تغییر شروع به درخواست RDB برای چالش های جدید کرد. حد ساختاری RDB چقدر است؟

1.1 عدم مقیاس پذیری: تغییر مدل های داده غیر انعطاف پذیر

یکی از بزرگترین نقاط ضعف RDB است مقیاس پذیریبدون دیدن RDB کاملاً تعریف شده است طرحبر اساس داده ها این در افزایش یکپارچگی داده ها مؤثر است ، اما برعکس ، تغییر مدل داده را بسیار دشوار می کند.

وضعیتی را تصور کنید که باید یک ستون جدید به یک جدول با میلیون ها داده و ده ها میلیون داده اضافه کنید. کار تغییر طرحواره زمان و منابع زیادی را مصرف می کند و حتی می تواند منجر به وقفه خدمات شود. مقابله با نیازهای سریع در حال تغییر کار سخت است.

1.2 به جهنم بپیوندید: مقصر اصلی عملکرد ضعیف

یکی دیگر از ویژگی های RDB است عادی سازیبدون دیدن عادی سازی یک روش مؤثر برای به حداقل رساندن همپوشانی داده ها و امنیت یکپارچگی داده ها است. اما عادی سازی بیش از حد ناگزیر به عملیات پیوستنافزایش را افزایش دهید.

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

1.3 محدودیت های مقیاس: مشکل در رسیدگی به ترافیک بار زیاد

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

البته البته تکرار (کلونینگ) همین فناوری را می توان از طریق ترافیک خواندن توزیع کرد. با این حال ، در محیطی با بسیاری از ترافیک های نوشتن ، ماکت نیز تحمل بار دشوار است. RDB چند استاد ، Sharding یک فناوری مقیاس مانند این وجود دارد ، اما درست است که پیچیده و انعطاف پذیر از NOSQL است. RDB ذاتاً یک پایگاه داده بهینه برای مقیاس نیست.

1.4 ویژگی اسید: تجارت با عملکرد

RDB اسید (اتمی ، قوام ، انزوا ، دوام) ما سعی می کنیم از ویژگی های دقیق اطمینان حاصل کنیم. این مقدار اصلی RDB است که یکپارچگی داده ها را در ابتدا قرار می دهد. اما برای تضمین خصوصیات اسید مدیریت معامله این فرایند همچنین بر عملکرد سرور پایگاه داده تأثیر می گذارد. به خصوص در محیطی با همزمانی بالا ، فرآیند پیچیده برای حفظ خاصیت اسید می تواند منجر به وخامت عملکرد شود.

2. پیشینه ظاهر Nosql: فراتر از حد RDB

در اوایل و اواسط دهه 2000 ، اینترنت انفجاری رشد کرد و محیط خدمات وب به سرعت تغییر کرده است. انواع جدیدی از خدمات که با RDBM های موجود ، مانند رسانه های اجتماعی ، تجارت الکترونیکی و بازی های آنلاین بزرگ ، با آنها سخت است ، شروع به ظهور کرده اند. این خدمات شرایط جدید زیر را ارائه داده اند:

  • با توان بالا: دسترسی همزمان بسیاری از کاربران و تعداد زیادی درخواست پردازش داده ها
  • زمان پاسخ کم: سرعت پاسخ سریع برای بهبود تجربه کاربر
  • پردازش داده های غیر نوع: افزایش داده های غیر عادی در اشکال مختلف مانند متن ، تصویر و فیلم

RDB موجود برای برآورده کردن این الزامات جدید کافی نبود. در این پس زمینه NOSQL (نه تنها SQL) الگوی جدید پایگاه داده پدید آمده است. NOSQL به معنای “جایگزینی SQL” نیست ، اما “ما به انواع روشهای مدیریت داده و همچنین SQL نیاز داریم” معنی دار است

3. ویژگی اصلی NOSQL: با RDB چه تفاوتی دارد؟

NOSQL بر محدودیت های RDB غلبه می کند و ویژگی های متنوعی را برای یک محیط خدمات وب مدرن بهینه می کند. بیایید نگاهی به ویژگی های اصلی یک به یک بیندازیم.

3.1 طرح انعطاف پذیر: مدل سازی داده های رایگان

بزرگترین ویژگی NOSQL است انعطاف پذیربدون دیدن بر خلاف RDB ، پایگاه داده NOSQL نیازی به تعریف طرحواره از قبل ندارد. داده مدرک ذخیره در فرم ، هر سند می تواند زمینه های مختلفی داشته باشد.

منگولهبیایید مثال بزنیم. منگوله مجموعه (مشابه جدول RDB) هنگام ایجاد تعریف نمی شود. زیر insertOne() شما می توانید آزادانه اسناد را از طریق دستور وارد کنید.

db.createCollection("student")

db.student.insertOne({
  name: "john"
})

db.student.insertOne({
  name: "jay",
  address: {
    country: "Korea",
    state: "Seoul"
  },
  certificate: ["AWS solution architect"]
})
حالت تمام صفحه را وارد کنید

از حالت تمام صفحه خارج شوید

[Image of MongoDB flexible schema example]

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

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

3.2 نابسامانی

دومین ویژگی NOSQL است نابسامانی بدون دیدن پایگاه داده NOSQL به عملیات پیوستنبرای به حداقل رساندن همپوشانی داده ها بن یونگ کیووا به طور فعال از تکنیک استفاده کنید.

RDB همچنین از Semi -Silicon برای بهبود عملکرد استفاده می کند ، اما در NOSQL بیشتر است. اطلاعات سفارشبیایید مثال بزنیم. RDB ordersبا productsبا users اطلاعاتی که توسط جدول از هم جدا شده است در یک سند در NOSQL گنجانده شده است.

db.getCollection("order").find({})
حالت تمام صفحه را وارد کنید

از حالت تمام صفحه خارج شوید

/**
{
    "_id": ObjectId("..."),
    // 프로덕트 정보도 저장 (RDB였다면 테이블 분리)
    "product_name": "아이폰 16e",
    "price_per_product": 2000000,
    "count": 5.0,
    "total_price": 1000000,
    // 주문한 사용자 정보도 저장 (RDB였다면 테이블 분리)
    "user_name": "john",
    "phone_number": "010-1234-1234"
}
*/
حالت تمام صفحه را وارد کنید

از حالت تمام صفحه خارج شوید

[Image of NoSQL denormalization example]

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

اما داده های تکراری حفظ قواممسئولیت برنامه است هنگام به روزرسانی داده ها ، باید منطق را توسعه دهید تا تمام داده های تکراری را به روز نگه دارید. این مهم است که در نظر داشته باشید که توسعه دهندگان مسئول مدیریت یکپارچگی داده ها هستند.

3.3 Scale-out Easure: بهینه سازی برای گسترش افقی

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

داده های مربوط به سرورهای متعدد توری آن را ذخیره کرده و داده ها را به طور مستقل در هر قطعه پردازش کنید. پایگاه داده NOSQL چندین سرور را به هم می پیوندد خوشهدر رسیدگی به داده های بزرگ و تأمین در دسترس بودن بالا مؤثر است. مقیاس خارج از RDBMS به لطف کاهش عملکرد پیوستن و سهولت در اشتراک گذاری بسیار ساده تر است.

[Image of NoSQL sharding example]

3.4 اولویت عملکرد: تسکین ویژگی اسید

NOSQL برخلاف RDB است برخی از خصوصیات اسید را تسکین دهیدانجام دادن عملتمایل به اولویت بندی وجود دارد. به خصوص ثبات اموال را تسکین دهید توان بالا (توان بالا) طبقه با تأخیر کم (زمان پاسخ کم) روی حداکثر عملکرد تمرکز کنید.

CAP 이론 (قوام ، در دسترس بودن ، تحمل پارتیشن) از دیدگاه ، NOSQL معمولاً است قوام نهایی مدل را اتخاذ کنید. این بدان معنی است که “داده ها روزی سازگار خواهند بود” ، و به جای تضمین در دسترس بودن و عملکرد بالا ، تضمین های دقیق از قوام داده ها را می دهد.

[Image of CAP Theorem]

البته در سیستمی که قوام دقیق داده ها ، مانند سیستم مالی یا سیستم تجارت ، باید برای استفاده از NOSQL مراقب باشد. در این سیستم ها ، RDBMS هنوز هم می تواند یک انتخاب مناسب باشد.

4. نماینده NOSQL -نگاه کردن به Redis

بانکهای اطلاعاتی NOSQL بسیار متنوع هستند ، اما در اینجا یکی از پایگاه داده های نماینده NOSQL وجود دارد. مجدداًبیایید نگاهی سریع بیندازیم.

مجدداًاست ، پایگاه داده در حافظهبا پایگاه داده با ارزش کلیدیبا سیستم حافظه نهان این یک بانک اطلاعاتی NOSQL است که برای اهداف مختلف استفاده می شود. فراتر از حافظه نهان ساده ، در طیف گسترده ای از جلسات ، تجزیه و تحلیل زمان واقعی ، تابلوهای رهبر و پیام ها استفاده می شود.

هسته redis است ساختار ارزش کلیدیبدون دیدن تمام داده ها در جفت های کلید و مقدار و هر کلید ذخیره می شوند رشته ، لیست ، مجموعه ، هش ، مرتب شده می توانید انواع مقادیر را ذخیره کنید.

redis> SET name ppap
"OK"

redis> GET name
"ppap"
حالت تمام صفحه را وارد کنید

از حالت تمام صفحه خارج شوید

[Image of Redis Key-Value example]

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

[Image of Redis cluster architecture]

نماینده ترین مورد Redis است لایه حافظهبدون دیدن شما می توانید با قرار دادن REDIS در قسمت جلوی پایگاه داده و ذخیره اطلاعات متداول در حافظه ، سرعت پاسخ پایگاه داده را به طور قابل توجهی بهبود بخشید. این مبتنی بر حافظه در حافظه است ، بنابراین عملکرد بسیار سریع تری نسبت به یک پایگاه داده مبتنی بر دیسک ارائه می دهد.

[Image of Redis cache layer example]

علاوه بر این ، Redis می تواند برای اهداف مختلفی مانند مدیریت جلسه ، جمع بندی رتبه بندی زمان واقعی ، صف پیام و سیستم میخانه/زیر استفاده شود.

5. NOSQL ، RDB -کدام پایگاه داده باید انتخاب کنید؟

تاکنون ، ما از نزدیک به تفاوت ها و ویژگی های NOSQL و RDB نگاه کرده ایم. چه نوع بانک اطلاعاتی را انتخاب کنید؟

RDB برای موارد زیر مناسب است:

  • یکپارچگی داده ها اولویت اصلی است: سیستمی که برای صحت و قابلیت اطمینان داده ها مانند معاملات مالی و سیستم های پرداخت بسیار مهم است
  • پردازش معامله پیچیده: معاملات پیچیده و خصوصیات اسیدی که چندین مرحله را طی می کنند
  • داده های تشکیل: اگر ساختار داده مشخص باشد و رابطه مهم باشد و رابطه مهم باشد

NOSQL برای موارد زیر مناسب است:

  • عملکرد بالا و مقیاس پذیری: پردازش داده های بزرگ ، تجزیه و تحلیل داده های زمان واقعی و خدماتی که نیاز به پردازش ترافیک زیاد دارند
  • مدل داده انعطاف پذیر: اگر ساختار داده ها به طور مکرر تغییر می کنند یا وقتی با داده های بدون ساختار سر و کار دارند
  • توسعه ماریس اسکی: محیطی که باید به سرعت با تغییرات روبرو شود ، مانند مرحله اولیه توسعه و توسعه توسعه چابک

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

نوع پایگاه داده NOSQL:

  • ارزش کلیدی: redis ، memcached
  • سند: MongoDB ، Couchbase
  • ستون-خانواده: کاساندرا ، Hbase
  • نمودار: نئو 4J

مدل داده NOSQL:

  • مدل ارزش کلیدی: مناسب برای ذخیره سازی داده ها ، ذخیره سازی ، مدیریت جلسه و غیره
  • مدل سند: JSON ، داده های ذخیره سازی اسناد XML به شکل XML ، طرح انعطاف پذیر ، مناسب برای پردازش داده های بدون ساختار
  • مدل ستون-خانواده: مناسب برای ذخیره داده ها ، مقدار زیادی از داده ها و پردازش توزیع شده بر اساس خانواده ستون
  • مدل نمودار: گره و روابط برای تجزیه و تحلیل روابط مانند روابط داده ، شبکه های اجتماعی و سیستم های توصیه ای مناسب است
[Image of NoSQL database types and data models]

پایان

NOSQL و RDB دارای مزایا و معایب متمایز هستند و آنها را نمی توان به عنوان یک پایگاه داده نتیجه گرفت که برای یک وضعیت خاص مناسب تر است. نکته مهم این است که ویژگی ها و الزامات سرویس را به طور دقیق مشخص می کند و مزایا و مضرات هر بانک اطلاعاتی را در نظر می گیرد. پایگاه داده بهینه را انتخاب کنیداین است

امیدوارم این پست به شما در درک NOSQL و RDB کمک کند و به شما در حل کمی انتخاب پایگاه داده کمک کند. اگر سؤال یا نظر دارید ، لطفاً با ما تماس بگیرید!

برای خواندن بیشتر بخوانید:

با تشکر از شما برای خواندن پست های طولانی!

نوشته های مشابه

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *

دکمه بازگشت به بالا